From abakhtin at openjdk.org  Thu Feb  1 00:23:26 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 1 Feb 2024 00:23:26 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@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.

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

  Update CheckMacOSKeyChainTrust test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/15a28d9a..f6fd4ef8

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

  Stats: 58 lines in 2 files changed: 30 ins; 16 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 abakhtin at openjdk.org  Thu Feb  1 00:23:26 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 1 Feb 2024 00:23:26 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v4]
In-Reply-To: <KSy-VMJ8H2dAr5QvxxckT3jI4EG5rwKsbytkkzqg84Y=.31d24060-6c40-4b21-914f-b0c78cb378f1@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>
 <KSy-VMJ8H2dAr5QvxxckT3jI4EG5rwKsbytkkzqg84Y=.31d24060-6c40-4b21-914f-b0c78cb378f1@github.com>
Message-ID: <jhzoeqfUFTNreL6bfNFg6epz8hUhBjrdbSOGO4tnEMw=.0e20d02c-5bf0-460a-8865-b643b1d11130@github.com>

On Wed, 31 Jan 2024 15:33:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Do you intend to call `addIdentitiesToKeystore` for both store types?

Yes, you are right. Thank you. We do not need private identities in the root keystore. Updated

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1920238811


From abakhtin at openjdk.org  Thu Feb  1 00:27:07 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 1 Feb 2024 00:27:07 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v4]
In-Reply-To: <irPToO57s4rSyEez3VWBV0awcL4sOo-5UvSW3kpTPvA=.ac819c0c-4e05-42f6-a6eb-c7e16c9e2b15@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4nzE0-YJVB-LZ8fDWwfdF6pARayy2GaF-OBq1YnyLY=.b615fde6-0fd7-45ce-a1f4-478af7d6534f@github.com>
 <irPToO57s4rSyEez3VWBV0awcL4sOo-5UvSW3kpTPvA=.ac819c0c-4e05-42f6-a6eb-c7e16c9e2b15@github.com>
Message-ID: <rOf2Cmcx4pAuQ52DawjRMMoc1eqK5NWXVXpkYarXNlY=.3804f5f6-fc1e-4feb-b35c-40435ddd69fd@github.com>

On Wed, 31 Jan 2024 15:08:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Great! The change looks good. Can you manage to add a test? Maybe try to load both store types. Make sure they have different contents and not empty (?).

Thank you. I have updated `java/security/KeyStore/CheckMacOSKeyChainTrust.java` test to load system root certificates and compare it with the content of the `KEYCHAINSTORE-ROOT` keystore.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1920243396


From valeriep at openjdk.org  Thu Feb  1 00:31:04 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 1 Feb 2024 00:31:04 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider [v2]
In-Reply-To: <Hl14JG3s6-iiUtUV5Ue8SDkIkxqSODFC_N_3V2Kgwcs=.c9c52513-2490-4abd-a937-af914a0e1952@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
 <Hl14JG3s6-iiUtUV5Ue8SDkIkxqSODFC_N_3V2Kgwcs=.c9c52513-2490-4abd-a937-af914a0e1952@github.com>
Message-ID: <5tvLJVsPfZ5vQZjm2HGwLN5lLOMb4LVXuH7udUlQ7-g=.75f97a97-59e7-46c4-ad9d-a3ced063f00b@github.com>

On Wed, 31 Jan 2024 10:23:22 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
>> 
>> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
>> 
>> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
>> 
>> All sun/security/pkcs11 tests still pass with NSS ~3.35 and~ 3.91. All tier1-3 tests still pass.
>> 
>> EDIT:
>> Some sun/security/pkcs11 tests fail with NSS 3.64 and older, see [comment](https://github.com/openjdk/jdk/pull/17584#issuecomment-1914665234)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable RSA-PSS in known bad NSS versions

Just a minor wording suggestion. 
Disabling older NSS releases due to known issue is the best that we can do to work with multiple NSS releases out there.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1311:

> 1309:             if (brokenMechanisms.contains(longMech)) {
> 1310:                 if (showInfo) {
> 1311:                     System.out.println("DISABLED due to broken provider");

nit: how about changing "broken provider" to "known issue with NSS"?

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17584#pullrequestreview-1855140171
PR Review Comment: https://git.openjdk.org/jdk/pull/17584#discussion_r1473648397


From syan at openjdk.org  Thu Feb  1 02:10:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 1 Feb 2024 02:10:09 GMT
Subject: RFR: 8325024:
 java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment
 information
In-Reply-To: <0kZiSxrq44Kpv-wTeiQK4rvfd-VCfgTfvPFf6Ti0_ls=.b07f7065-e5c0-49c0-b4d3-8ba12d96e4af@github.com>
References: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
 <0kZiSxrq44Kpv-wTeiQK4rvfd-VCfgTfvPFf6Ti0_ls=.b07f7065-e5c0-49c0-b4d3-8ba12d96e4af@github.com>
Message-ID: <2yKug-S6s6P6hzSQUav62Ynd4j7dZ_1e8pTFXAeGCAY=.b87cbe03-a056-46da-b9da-eda6294bce87@github.com>

On Wed, 31 Jan 2024 17:48:19 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> Looks good, but please label the JBS bug with noreg-trivial.

Done

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

PR Comment: https://git.openjdk.org/jdk/pull/17646#issuecomment-1920357757


From jjiang at openjdk.org  Thu Feb  1 02:39:06 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 1 Feb 2024 02:39:06 GMT
Subject: RFR: 8325022: Incorrect error message on client authentication
 [v2]
In-Reply-To: <HRihQ6pucIpvL35XXDlBfWr9alvv1uPMmi0vAEL1NV8=.0d93579a-1e6c-4920-8c94-80e469f8995d@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
 <C9CJeK6lAAgs4vB2UdV2DU6cLHofKTXuL5SyAzG14G4=.74e47b49-781e-41d8-96e4-3bba992ebdd9@github.com>
 <HRihQ6pucIpvL35XXDlBfWr9alvv1uPMmi0vAEL1NV8=.0d93579a-1e6c-4920-8c94-80e469f8995d@github.com>
Message-ID: <lPSRC_XE-q52OJXTvK5GF7jz29xSmjfjUvJkz7SCzXM=.e00869df-c450-4f5b-9b70-7e2ab229d292@github.com>

On Wed, 31 Jan 2024 20:43:31 GMT, Bernd <duke at openjdk.org> wrote:

>> John Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix more error messages
>
> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 389:
> 
>> 387:                     // unexpected or require client authentication
>> 388:                     throw shc.conContext.fatal(Alert.BAD_CERTIFICATE,
>> 389:                         "Empty client certificate chain");
> 
> Hm, in tls1.3 it should be certificate_required and in 1.2 handshake_failure for required auth.
> 
> rfc8446 6.2 ?certificate_required:  Sent by servers when a client certificate is
>       desired but none was provided by the client.?
> rfc5246 7.4.6 ? If the client does not send any certificates, the
>       server MAY at its discretion either continue the handshake without
>       client authentication, or respond with a fatal handshake_failure
>       alert.?

Thanks for raising this point.
I just filed a JBS issue: https://bugs.openjdk.org/browse/JDK-8325079

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17645#discussion_r1473724754


From jjiang at openjdk.org  Thu Feb  1 02:39:07 2024
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 1 Feb 2024 02:39:07 GMT
Subject: Integrated: 8325022: Incorrect error message on client authentication
In-Reply-To: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
References: <LpOrfakOv5GSOKKyrfDylSiOdHUBeQfyH4VK7VH67nU=.5b1394ae-46bf-4719-9146-90399ab6935f@github.com>
Message-ID: <Txpz0G8ImYx_646awnDvp0xiNT1RoDAI_ogCvXAH3r8=.65dc86fa-4935-45e5-98fe-d27273c4896d@github.com>

On Wed, 31 Jan 2024 07:42:32 GMT, John Jiang <jjiang at openjdk.org> wrote:

> If the server doesn't receive the client certificate for required client authentication, it should raise error `Empty client certificate chain`.

This pull request has now been integrated.

Changeset: fe78c0f1
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe78c0f1911c9fdc1d30e23847d102748dfa2063
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8325022: Incorrect error message on client authentication

Reviewed-by: jnimeh, hchao, djelinski

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

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


From fyang at openjdk.org  Thu Feb  1 03:11:07 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 1 Feb 2024 03:11:07 GMT
Subject: RFR: 8325024:
 java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment
 information
In-Reply-To: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
References: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
Message-ID: <_bu7qQoTh4z_CgIRK7JGAjkP9FP_Tlfh0P8xuMU94sU=.732acd7f-216f-482c-bcd4-e52f7d932566@github.com>

On Wed, 31 Jan 2024 08:19:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> 8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information

Marked as reviewed by fyang (Reviewer).

Looks good and trivial.

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

PR Review: https://git.openjdk.org/jdk/pull/17646#pullrequestreview-1855293906
PR Comment: https://git.openjdk.org/jdk/pull/17646#issuecomment-1920417025


From syan at openjdk.org  Thu Feb  1 03:11:07 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 1 Feb 2024 03:11:07 GMT
Subject: Integrated: 8325024:
 java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment
 information
In-Reply-To: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
References: <1155yerxboO9qOuscb-MQLKKU2QvXFcesuTn0rnTzR8=.29e23d7c-ab7e-4e5b-ab81-9cb935373322@github.com>
Message-ID: <mpekwo8Z5PcPtFeilKgc3VTXkbsWXxCr2mBkVvKk-HQ=.7a12aedb-92a9-4525-a738-f5072d76d180@github.com>

On Wed, 31 Jan 2024 08:19:55 GMT, SendaoYan <syan at openjdk.org> wrote:

> 8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information

This pull request has now been integrated.

Changeset: 432756b6
Author:    SendaoYan <syan at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/432756b6e51c903e2bff8b9c3028a4f2ea8973f4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information

Reviewed-by: jnimeh, fyang

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

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


From djelinski at openjdk.org  Thu Feb  1 08:33:13 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 1 Feb 2024 08:33:13 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider [v3]
In-Reply-To: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
Message-ID: <ENBPzkIMbfs9G3oDoFbPTCufN5K-7nCQ-YueDH8HfeI=.ef400bc2-b284-496b-8585-31d7546e3679@github.com>

> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
> 
> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
> 
> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
> 
> All sun/security/pkcs11 tests still pass with NSS ~3.35 and~ 3.91. All tier1-3 tests still pass.
> 
> EDIT:
> Some sun/security/pkcs11 tests fail with NSS 3.64 and older, see [comment](https://github.com/openjdk/jdk/pull/17584#issuecomment-1914665234)

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Improve wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17584/files
  - new: https://git.openjdk.org/jdk/pull/17584/files/87edba10..5a2390d4

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

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

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


From djelinski at openjdk.org  Thu Feb  1 08:40:11 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 1 Feb 2024 08:40:11 GMT
Subject: RFR: 8324585: JVM native memory leak in PCKS11-NSS security
 provider [v3]
In-Reply-To: <ENBPzkIMbfs9G3oDoFbPTCufN5K-7nCQ-YueDH8HfeI=.ef400bc2-b284-496b-8585-31d7546e3679@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
 <ENBPzkIMbfs9G3oDoFbPTCufN5K-7nCQ-YueDH8HfeI=.ef400bc2-b284-496b-8585-31d7546e3679@github.com>
Message-ID: <B2yf3gl9reW4Zg00M1n3mxLLs_t0r1pkcnTvSd58jI0=.4f59b9b4-f8fa-455e-9c65-e62699a6f708@github.com>

On Thu, 1 Feb 2024 08:33:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
>> 
>> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
>> 
>> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
>> 
>> All sun/security/pkcs11 tests still pass with NSS ~3.35 and~ 3.91. All tier1-3 tests still pass.
>> 
>> EDIT:
>> Some sun/security/pkcs11 tests fail with NSS 3.64 and older, see [comment](https://github.com/openjdk/jdk/pull/17584#issuecomment-1914665234)
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve wording

I applied your suggestion. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17584#issuecomment-1920773619


From djelinski at openjdk.org  Thu Feb  1 08:40:12 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 1 Feb 2024 08:40:12 GMT
Subject: Integrated: 8324585: JVM native memory leak in PCKS11-NSS security
 provider
In-Reply-To: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
References: <evLFtP_T8MLQDY3_-ddNMYh06Bg1xCrF9XTJUnW7CWc=.34300201-5830-4530-bf34-b9c013cea2f7@github.com>
Message-ID: <isDAh2GuTqKxzTdjvQ3h6jjLt2jNAQDb4_4XR1a60q4=.60b7d528-ff22-4b26-8bec-bc85124a9b9b@github.com>

On Fri, 26 Jan 2024 10:04:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that fixes a memory leak in P11TlsPrfGenerator, which is triggered during TLS1.2 Finished message generation and verification.
> 
> The patch changes C_SignInit JNI method to free the mechanism data immediately after use. This matches the behavior of other Init methods (like C_EncryptInit). The patch also fixes a similar issue in other signature-related methods.
> 
> The change essentially reverts part of [JDK-8080462](https://bugs.openjdk.org/browse/JDK-8080462).
> 
> All sun/security/pkcs11 tests still pass with NSS ~3.35 and~ 3.91. All tier1-3 tests still pass.
> 
> EDIT:
> Some sun/security/pkcs11 tests fail with NSS 3.64 and older, see [comment](https://github.com/openjdk/jdk/pull/17584#issuecomment-1914665234)

This pull request has now been integrated.

Changeset: 68206b53
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68206b533b09e07e4d556df794414ed4538889c0
Stats:     109 lines in 7 files changed: 25 ins; 65 del; 19 mod

8324585: JVM native memory leak in PCKS11-NSS security provider

Reviewed-by: valeriep

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

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


From ogillespie at openjdk.org  Thu Feb  1 10:39:27 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 1 Feb 2024 10:39:27 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v3]
In-Reply-To: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
Message-ID: <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>

> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
> 
> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
> 
> 
> Before
> newSecureRandom  avgt  2930 ? 50  ns/op
> 
> After
> newSecureRandom  avgt  2400 ? 33  ns/op
> 
> 
> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.

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

  Use class literals instead of forName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17559/files
  - new: https://git.openjdk.org/jdk/pull/17559/files/8d8f2d0b..45da78f9

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

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

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


From ogillespie at openjdk.org  Thu Feb  1 10:39:27 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 1 Feb 2024 10:39:27 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v2]
In-Reply-To: <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <k9VQ7Mm3GwHRKdS8KpUlb42ZeitjBIrzrQFRIXgCClY=.cef9698a-f08a-441e-9a9c-b84b24c5e565@github.com>
Message-ID: <hepo-U5bodHrfrTdXX-30-bUpbBWxFXB8ksYUc-9FfM=.d24c99fd-6f43-414f-94d3-e3ab210c5aed@github.com>

On Wed, 24 Jan 2024 18:05:50 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename newSecureRandom -> create
>  - Add copyright header to new file

Updated with class literals, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1921013218


From ogillespie at openjdk.org  Thu Feb  1 11:26:01 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 1 Feb 2024 11:26:01 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <ESrSJgcJlrpVImvPFZZejBX19xwIjk5ahpXa-13Obl0=.28dc0042-54d8-451a-bb9d-c4628e40eced@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

The more I think about it, adding a new public constructor seems a bit ugly and potentially confusing.

So I'll offer a few more ideas. Which do you think is best?

1. New public constructor with IllegalArgumentException if params != null


// constructor, unused argument to speed up lookups from Provider
public NativePRNG(SecureRandomParameters params) {
    this();
    if (params != null) {
        throw new IllegalArgumentException("Unsupported params: " + params.getClass());
    }
}


2. Use `getConstructors()` instead of `getConstructor(...)`, and manually look for the match (basically implement our own `tryGetConstructor`). This way, we avoid the exception which is the main cost of the current approach, but don't need to add any special cases. Benchmark says this is only a little slower than 1. (550ns vs 510ns).


// new style with params
for (Constructor<?> c : getImplClass().getConstructors()) {
    Class<?>[] args = c.getParameterTypes();
    if (args.length == 1 && args[0].equals(ctrParamClz)) {
        // found match
        return c.newInstance(ctorParamObj);
    }
}
// old style without params
if (ctorParamObj == null) {
    return newInstanceOf();
} else {
    throw new NoSuchMethodException("...");
}


3. Add explicit handling of NativePRNG inside Provider.


static HashSet<String> NO_ARG_SECURE_RANDOMS = new HashSet<>();
static {
    NO_ARG_SECURE_RANDOMS.add("sun.security.provider.NativePRNG");
    NO_ARG_SECURE_RANDOMS.add("sun.security.provider.NativePRNG$Blocking");
    NO_ARG_SECURE_RANDOMS.add("sun.security.provider.NativePRNG$NonBlocking");
};

private Object newInstanceUtil(Class<?> ctrParamClz, Object ctorParamObj)
        throws Exception {
    if (ctrParamClz == null) {
        return newInstanceOf();
    } else if (ctorParamObj == null && NO_ARG_SECURE_RANDOMS.contains(getImplClass().getName())) {
        return newInstanceOf();
    } else {


4. Add some kind of caching in Provider to only pay the cost once (not coded up yet, potentially a bit annoying to also save the NSME if we want to keep that behaviour).

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1921098319


From coffeys at openjdk.org  Thu Feb  1 11:42:11 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 1 Feb 2024 11:42:11 GMT
Subject: RFR: 8325096: Test
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
Message-ID: <KJcCcjs1Zo7pR_4DX_UpZG1Yjx3XQk6esuXsrs1vCSQ=.53f9672a-b9cc-4c29-99cd-d5e95137c28d@github.com>

Update the testcase to run certificate checks at a time before the certs expired

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

Commit messages:
 - Update copyright year
 - 8325096

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

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


From ihse at openjdk.org  Thu Feb  1 12:02:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 12:02:12 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
Message-ID: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>

This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.

Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.

I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

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

Commit messages:
 - 8325109: Sort method modifiers in canonical order

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

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


From dfuchs at openjdk.org  Thu Feb  1 13:43:00 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 Feb 2024 13:43:00 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <8VqjbOBjkNCr7PmXABZ1xmQqvF0jidmGyIMNUdKQDww=.8ffdc2ac-023f-4b79-ac5a-9ef541af68a7@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Changes to IPAdressUtil look fine. I eyeballed the rest and didn't spot any issue.

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

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856519410


From weijun at openjdk.org  Thu Feb  1 13:57:19 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Feb 2024 13:57:19 GMT
Subject: RFR: 8325096: Test
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
In-Reply-To: <KJcCcjs1Zo7pR_4DX_UpZG1Yjx3XQk6esuXsrs1vCSQ=.53f9672a-b9cc-4c29-99cd-d5e95137c28d@github.com>
References: <KJcCcjs1Zo7pR_4DX_UpZG1Yjx3XQk6esuXsrs1vCSQ=.53f9672a-b9cc-4c29-99cd-d5e95137c28d@github.com>
Message-ID: <Gob5VB17dA0knvI_y79oYzG46PpBTnE64sfmz5cgeB0=.19d5416b-5317-407d-8e8d-07d52a6cbc68@github.com>

On Thu, 1 Feb 2024 11:37:33 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Update the testcase to run certificate checks at a time before the certs expired

Looks good to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17668#pullrequestreview-1856549409


From coffeys at openjdk.org  Thu Feb  1 13:57:19 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 1 Feb 2024 13:57:19 GMT
Subject: Integrated: 8325096: Test
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
In-Reply-To: <KJcCcjs1Zo7pR_4DX_UpZG1Yjx3XQk6esuXsrs1vCSQ=.53f9672a-b9cc-4c29-99cd-d5e95137c28d@github.com>
References: <KJcCcjs1Zo7pR_4DX_UpZG1Yjx3XQk6esuXsrs1vCSQ=.53f9672a-b9cc-4c29-99cd-d5e95137c28d@github.com>
Message-ID: <hcM5gC95Bi6hK7XILDdilpOP_4sBwQcHbPeSexxE7vI=.e34a77d5-7907-46e6-bcbd-c0925f3b2097@github.com>

On Thu, 1 Feb 2024 11:37:33 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Update the testcase to run certificate checks at a time before the certs expired

This pull request has now been integrated.

Changeset: ac1cd319
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac1cd3194910793b02e86c2c0dedaa321f137d4e
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8325096: Test java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing

Reviewed-by: weijun

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

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


From coffeys at openjdk.org  Thu Feb  1 14:04:20 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 1 Feb 2024 14:04:20 GMT
Subject: [jdk22] RFR: 8325096: Test
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
Message-ID: <X3zdZk-lqpkyID1lzCd-VdDTpeb-fqjhOXfwnWjlJ5s=.3e73cbae-28b4-43da-b3a6-e2584895a475@github.com>

Test case fix up for cert expiration issue. Should be clean port from JDK 23

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

Commit messages:
 - Backport ac1cd3194910793b02e86c2c0dedaa321f137d4e

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

PR: https://git.openjdk.org/jdk22/pull/101


From weijun at openjdk.org  Thu Feb  1 14:11:13 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Feb 2024 14:11:13 GMT
Subject: [jdk22] RFR: 8325096: Test
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
In-Reply-To: <X3zdZk-lqpkyID1lzCd-VdDTpeb-fqjhOXfwnWjlJ5s=.3e73cbae-28b4-43da-b3a6-e2584895a475@github.com>
References: <X3zdZk-lqpkyID1lzCd-VdDTpeb-fqjhOXfwnWjlJ5s=.3e73cbae-28b4-43da-b3a6-e2584895a475@github.com>
Message-ID: <qXjWwSkgvfOKaJD7O9nAgkAjoyhfPurz6cNunB1ygEM=.85939791-090c-4184-9060-abc98f518cc7@github.com>

On Thu, 1 Feb 2024 13:58:29 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Test case fix up for cert expiration issue. Should be clean port from JDK 23

LGTM. Thanks!

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/101#pullrequestreview-1856597085


From coffeys at openjdk.org  Thu Feb  1 14:14:13 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 1 Feb 2024 14:14:13 GMT
Subject: [jdk22] Integrated: 8325096: Test
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
In-Reply-To: <X3zdZk-lqpkyID1lzCd-VdDTpeb-fqjhOXfwnWjlJ5s=.3e73cbae-28b4-43da-b3a6-e2584895a475@github.com>
References: <X3zdZk-lqpkyID1lzCd-VdDTpeb-fqjhOXfwnWjlJ5s=.3e73cbae-28b4-43da-b3a6-e2584895a475@github.com>
Message-ID: <8Jm0k6GjS_Trdz6edj24YVQPabMwodxSXxFQHoiZaWk=.366a5234-c3ab-4aa0-a984-1c1ba5642e46@github.com>

On Thu, 1 Feb 2024 13:58:29 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Test case fix up for cert expiration issue. Should be clean port from JDK 23

This pull request has now been integrated.

Changeset: 306e364f
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/306e364ffd838c7a53e1133595ddc979966829ea
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8325096: Test java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing

Reviewed-by: weijun
Backport-of: ac1cd3194910793b02e86c2c0dedaa321f137d4e

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

PR: https://git.openjdk.org/jdk22/pull/101


From aivanov at openjdk.org  Thu Feb  1 14:44:02 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Feb 2024 14:44:02 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <uj6X0EkJ7Id9yviBJdcfrEINU46lON8sZkDN2xF5OB4=.bd123c3f-d79e-46e8-8a5f-241b4a50390e@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Looks good to me.

I looked through all the changes.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856683827


From rriggs at openjdk.org  Thu Feb  1 17:02:01 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Feb 2024 17:02:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <E28xCC3i0n7CBNbkZDdvbd8kDHlZdAfF0o_OrhT88ng=.79424bfe-ea1d-4015-a15b-de98635b7d05@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

lgtm; all look good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857031136


From ascarpino at openjdk.org  Thu Feb  1 17:10:10 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 1 Feb 2024 17:10:10 GMT
Subject: RFR: JDK-8318105 [jmh] the test java.security.HSS failed with 2
 active threads [v2]
In-Reply-To: <HtK9FYC7BbRWm5XRY83Rc9XHf3iMVlzfSjSICEVISNg=.a15cacce-6047-47cf-bfb7-62dc6945e7f4@github.com>
References: <5G6-wapay_2Jpy5DWejpM33406bl-VvbZXAP9_4QMTo=.794ae67e-b4c3-47bb-a961-6e50ab0793ad@github.com>
 <HtK9FYC7BbRWm5XRY83Rc9XHf3iMVlzfSjSICEVISNg=.a15cacce-6047-47cf-bfb7-62dc6945e7f4@github.com>
Message-ID: <2DX9PpMGqw-W3WcMHjmwpD8Jj9W4LdZwTfsXcIMhNyI=.78cf0a73-dc98-4d5a-a9b6-c6d0e5be48e6@github.com>

On Thu, 11 Jan 2024 16:34:37 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8318105
>
> Mark Powers has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Copyright
>  - reworked to use Benchmark and Thread State

look good

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16435#pullrequestreview-1857056963


From darcy at openjdk.org  Thu Feb  1 17:24:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Feb 2024 17:24:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Looks fine; I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857088376


From weijun at openjdk.org  Thu Feb  1 21:15:05 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Feb 2024 21:15:05 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
Message-ID: <cYoBtXp0mU8sCu3eNaL6V2TxDZCQUfMZR1MqEMo4nnY=.1ae7b075-1f3a-4337-9963-e6144893dac8@github.com>

On Thu, 1 Feb 2024 00:23:26 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.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CheckMacOSKeyChainTrust test

test/jdk/java/security/KeyStore/CheckMacOSKeyChainTrust.java line 41:

> 39:  *          honors trust settings
> 40:  * @run main CheckMacOSKeyChainTrust KEYCHAINSTORE
> 41:  * @run main CheckMacOSKeyChainTrust KEYCHAINSTORE-ROOT

Can we do both in a single test run?

test/jdk/java/security/KeyStore/CheckMacOSKeyChainTrust.java line 55:

> 53:             // check user and admin trustsettings to find distrusted certs
> 54:             loadUser(false);
> 55:             loadAdmin(false);

Not sure what the 2 lines above are for? Is it possible a cert is distrusted in user/admin store but trusted in root store and you want to make it sure it does not appear in KEYCHAINSTORE-ROOT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1475150824
PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1475154375


From weijun at openjdk.org  Thu Feb  1 21:39:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Feb 2024 21:39:03 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
Message-ID: <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>

On Thu, 1 Feb 2024 00:23:26 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.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CheckMacOSKeyChainTrust test

Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I tried on my machine and there are some items not in `security dump-trust-settings -s`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1922289031


From abakhtin at openjdk.org  Thu Feb  1 22:11:05 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 1 Feb 2024 22:11:05 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <cYoBtXp0mU8sCu3eNaL6V2TxDZCQUfMZR1MqEMo4nnY=.1ae7b075-1f3a-4337-9963-e6144893dac8@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <cYoBtXp0mU8sCu3eNaL6V2TxDZCQUfMZR1MqEMo4nnY=.1ae7b075-1f3a-4337-9963-e6144893dac8@github.com>
Message-ID: <Unt7hAJBre7i2_YxQN2qRLd4ABU2s-T3CnStaQMbFKY=.16c18648-c586-4ad3-b8c0-dcd27abeea8a@github.com>

On Thu, 1 Feb 2024 21:11:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update CheckMacOSKeyChainTrust test
>
> test/jdk/java/security/KeyStore/CheckMacOSKeyChainTrust.java line 55:
> 
>> 53:             // check user and admin trustsettings to find distrusted certs
>> 54:             loadUser(false);
>> 55:             loadAdmin(false);
> 
> Not sure what the 2 lines above are for? Is it possible a cert is distrusted in user/admin store but trusted in root store and you want to make it sure it does not appear in KEYCHAINSTORE-ROOT?

Yes. Exactly. The trusted cert can be distrusted in the user/admin domain, so It should not be available in the KEYCHAINSTORE-ROOT

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1475214596


From prappo at openjdk.org  Thu Feb  1 23:07:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 1 Feb 2024 23:07:08 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <zBTvQPjpQKoxxj5CsUlaOfJkO0EyJy-lUfF8Zg6FQRQ=.132947bd-1b7a-4809-af69-e3d9ba962099@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Changes to jdk.javadoc look fine.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131


From ihse at openjdk.org  Fri Feb  2 06:40:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 06:40:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
 <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>
Message-ID: <c1A2_JMyhmgyx8N0-IvYuVxJ-uK43gJZ-qQRWUYtBbk=.aee9ccc3-254c-41e8-b839-e61c21ca7fae@github.com>

On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>  I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code.

@jddarcy Any idea how to do that? I tried searching for JSR-166 and java.util.concurrent, but all I could find was talk about a now-deleted mailing list concurrency-interest, and a link to a [CVS repo for JDK8](http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/jsr166/src/jdk8/java/util/).

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1923018074


From mpowers at openjdk.org  Fri Feb  2 16:33:09 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 2 Feb 2024 16:33:09 GMT
Subject: Integrated: 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: <52jCLm3rpbIviXg8OvJJkIjgf9u3xqXDI2ptkQCMAJ4=.8146d7ab-283a-49ff-bb88-25be082fcb5e@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

This pull request has now been integrated.

Changeset: 38c01971
Author:    Mark Powers <mpowers at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38c01971ff1c440d8c7ef4bc3432e5b9797ae708
Stats:     224 lines in 1 file changed: 171 ins; 38 del; 15 mod

8318105: [jmh] the test java.security.HSS failed with 2 active threads

Reviewed-by: ascarpino

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

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


From weijun at openjdk.org  Fri Feb  2 18:45:04 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Feb 2024 18:45:04 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <Unt7hAJBre7i2_YxQN2qRLd4ABU2s-T3CnStaQMbFKY=.16c18648-c586-4ad3-b8c0-dcd27abeea8a@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <cYoBtXp0mU8sCu3eNaL6V2TxDZCQUfMZR1MqEMo4nnY=.1ae7b075-1f3a-4337-9963-e6144893dac8@github.com>
 <Unt7hAJBre7i2_YxQN2qRLd4ABU2s-T3CnStaQMbFKY=.16c18648-c586-4ad3-b8c0-dcd27abeea8a@github.com>
Message-ID: <9qV05drxT7j9Ha991y10HRkkJTPvET1wdCSarT1C4_Y=.dc91a398-29e5-41d8-b4df-e9f361e59a5d@github.com>

On Thu, 1 Feb 2024 22:08:16 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> test/jdk/java/security/KeyStore/CheckMacOSKeyChainTrust.java line 55:
>> 
>>> 53:             // check user and admin trustsettings to find distrusted certs
>>> 54:             loadUser(false);
>>> 55:             loadAdmin(false);
>> 
>> Not sure what the 2 lines above are for? Is it possible a cert is distrusted in user/admin store but trusted in root store and you want to make it sure it does not appear in KEYCHAINSTORE-ROOT?
>
> Yes. Exactly. The trusted cert can be distrusted in the user/admin domain, so It should not be available in the KEYCHAINSTORE-ROOT

This is OK. Although it means different people will see different root CA certs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1476527798


From weijun at openjdk.org  Fri Feb  2 18:55:01 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Feb 2024 18:55:01 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <RxJkP1l17LzfBnB0EftVdW0yx9reEIMsOGphUAMslEc=.4eaa739e-b87d-4fed-8a4e-6a541ad6ea5b@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

No matter if we touch the `Provider` class, I think we can remove the old constructors. With the params class defined for `SecureRandom`, those old constructors should be useless. And they step 3 above is not needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1924488756


From abakhtin at openjdk.org  Fri Feb  2 19:40:03 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 2 Feb 2024 19:40:03 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>
Message-ID: <iZwXZl-JKTLXb2A4JC1pRHur9ukAcJoyUq3PvK3L_yA=.21848030-bfcc-46f7-b3bd-7cc9aa14381b@github.com>

On Thu, 1 Feb 2024 21:36:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I tried on my machine and there are some items not in `security dump-trust-settings -s`.

I've found an issue in the original implementation that prevents adding different certificates with the same CN. I am going to fix it as part of this PR because it affects the scope of root certificates in the KEYCHAINSTORE-ROOT

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1924560154


From lancea at openjdk.org  Fri Feb  2 19:58:05 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 2 Feb 2024 19:58:05 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v2]
In-Reply-To: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com>
Message-ID: <J38tb6Yh9NrbtUG9BHQnOMKfDSztmQnS8C-y0pNqlwg=.b3a137e6-8d7d-40b2-8592-e4072023b679@github.com>

On Tue, 30 Jan 2024 16:17:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

I think the change is OK, any reason to not make it `externalFileAttributes`?

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-1860228844


From eirbjo at openjdk.org  Fri Feb  2 20:22:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 2 Feb 2024 20:22:03 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v2]
In-Reply-To: <J38tb6Yh9NrbtUG9BHQnOMKfDSztmQnS8C-y0pNqlwg=.b3a137e6-8d7d-40b2-8592-e4072023b679@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com>
 <J38tb6Yh9NrbtUG9BHQnOMKfDSztmQnS8C-y0pNqlwg=.b3a137e6-8d7d-40b2-8592-e4072023b679@github.com>
Message-ID: <udIGk2tax-D_7zchVTKqEolbKx7MEXTsGK8Bki4rU60=.26375c15-9639-437a-8e3c-964f51b052d1@github.com>

On Fri, 2 Feb 2024 19:55:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think the change is OK, any reason to not make it `externalFileAttributes`?

None other than length / verbosity.  But since this refers to the _attributes of the external file_, dropping any name element also loses some semantics, introducing a potential for confusion. Perhaps verbosity is the sensible choice here.

If you agree to the above, I can update the PR to rename to the following names instead:

- `ZipFile.externalFileAttributes`
- `JavaUtilZipFileAccess.java.[set|get]ExternalFileAttributes`
- `JarSigner.externalFileAttributesDetected`
- `jarsigner/Main.externalFileAttributesDetected`
- `external.file.attributes.detected` in `Resources.java`

WDYT?

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1924638322


From abakhtin at openjdk.org  Fri Feb  2 20:32:01 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 2 Feb 2024 20:32:01 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <iZwXZl-JKTLXb2A4JC1pRHur9ukAcJoyUq3PvK3L_yA=.21848030-bfcc-46f7-b3bd-7cc9aa14381b@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>
 <iZwXZl-JKTLXb2A4JC1pRHur9ukAcJoyUq3PvK3L_yA=.21848030-bfcc-46f7-b3bd-7cc9aa14381b@github.com>
Message-ID: <pWiI8p1UCqL6qR2T972Z0HbvAMXxfVwmaxx_OlPlSck=.10058ab2-ee28-4215-880a-dcd3faa42a21@github.com>

On Fri, 2 Feb 2024 19:37:18 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I tried on my machine and there are some items not in `security dump-trust-settings -s`.
`security dump-trust-settings -s` returns only predefined root certificates. KEYCHAINSTORE-ROOT additionally contains installed root trusted certificates in the system domain

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1924651647


From abakhtin at openjdk.org  Fri Feb  2 20:39:16 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 2 Feb 2024 20:39:16 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v6]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <G8cMKM3dpTLONQ57JAvUCxEteAXuWr-uwCTDs6-UzfY=.afcbd270-0c85-45ec-b719-c23e62e7b4ef@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.

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

  Add different certificates with the same alias

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/f6fd4ef8..595903f6

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 abakhtin at openjdk.org  Fri Feb  2 20:42:03 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 2 Feb 2024 20:42:03 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <cYoBtXp0mU8sCu3eNaL6V2TxDZCQUfMZR1MqEMo4nnY=.1ae7b075-1f3a-4337-9963-e6144893dac8@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <cYoBtXp0mU8sCu3eNaL6V2TxDZCQUfMZR1MqEMo4nnY=.1ae7b075-1f3a-4337-9963-e6144893dac8@github.com>
Message-ID: <928dgKMaROUYiJ3vqMU_WkX4ckkAcNMFtqqoTeSpmqw=.989825b4-6bd4-4336-bb59-420cdd30f671@github.com>

On Thu, 1 Feb 2024 21:07:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update CheckMacOSKeyChainTrust test
>
> test/jdk/java/security/KeyStore/CheckMacOSKeyChainTrust.java line 41:
> 
>> 39:  *          honors trust settings
>> 40:  * @run main CheckMacOSKeyChainTrust KEYCHAINSTORE
>> 41:  * @run main CheckMacOSKeyChainTrust KEYCHAINSTORE-ROOT
> 
> Can we do both in a single test run?

Yes, we can, but it looks like not required until we compare the contents of these stores

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16722#discussion_r1476707596


From lancea at openjdk.org  Fri Feb  2 20:46:02 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 2 Feb 2024 20:46:02 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v2]
In-Reply-To: <udIGk2tax-D_7zchVTKqEolbKx7MEXTsGK8Bki4rU60=.26375c15-9639-437a-8e3c-964f51b052d1@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com>
 <J38tb6Yh9NrbtUG9BHQnOMKfDSztmQnS8C-y0pNqlwg=.b3a137e6-8d7d-40b2-8592-e4072023b679@github.com>
 <udIGk2tax-D_7zchVTKqEolbKx7MEXTsGK8Bki4rU60=.26375c15-9639-437a-8e3c-964f51b052d1@github.com>
Message-ID: <MEK1VnDN7TNVFZIFOXjbz1uumsnX4KG5jDJHKf7dDwg=.62aa368a-2cac-484d-b57e-ad411d510b84@github.com>

On Fri, 2 Feb 2024 20:19:51 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> > I think the change is OK, any reason to not make it `externalFileAttributes`?
> 
> None other than length / verbosity. But since this refers to the _attributes of the external file_, dropping any name element also loses some semantics, introducing a potential for confusion. Perhaps verbosity is the sensible choice here.
> 
> If you agree to the above, I can update the PR to rename to the following names instead:
> 
> * `ZipFile.externalFileAttributes`
> * `JavaUtilZipFileAccess.java.[set|get]ExternalFileAttributes`
> * `JarSigner.externalFileAttributesDetected`
> * `jarsigner/Main.externalFileAttributesDetected`
> * `external.file.attributes.detected` in `Resources.java`
> 
> WDYT?

I think the proposed change above makes things clearer.  Perhaps also make the same change in zipfs as well while you are at it?

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1924670785


From darcy at openjdk.org  Fri Feb  2 23:41:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Feb 2024 23:41:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
Message-ID: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>

After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

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

Commit messages:
 - JDK-8325189: Enable this-escape javac warning in java.base

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

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


From darcy at openjdk.org  Fri Feb  2 23:41:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Feb 2024 23:41:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well.

I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1924907536


From darcy at openjdk.org  Sat Feb  3 01:37:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Feb 2024 01:37:03 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
Message-ID: <hmsbB5ZziJeSbUENbG-vzzu9kLVUFI9-UBCDJiWMy1w=.ec5c78db-223d-42ee-bc1c-f7f3a01af31f@github.com>

On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well.
> 

PS Builds pass on all platforms (linux, mac, and windows) on Oracle's internal build system.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1925001815


From eirbjo at openjdk.org  Sat Feb  3 17:28:29 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 3 Feb 2024 17:28:29 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v3]
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <JwZxCNT0ulu-RLMOQ5P65OG5cR5QjqzOKtJ-rMswuTY=.f1ec3dff-081b-4485-b8e7-f580a4709ff6@github.com>

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

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

 - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
 - For clarity, use "externalFileAttributes" instead of "externalAttributes"
 - Merge branch 'master' into zipentry-external-attributes
 - Update copyright years for 2024
 - Merge branch 'master' into zipentry-external-attributes
 - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16952/files
  - new: https://git.openjdk.org/jdk/pull/16952/files/481ae754..10db9803

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

  Stats: 44114 lines in 1909 files changed: 21144 ins; 10053 del; 12917 mod
  Patch: https://git.openjdk.org/jdk/pull/16952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952

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


From eirbjo at openjdk.org  Sat Feb  3 17:31:00 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 3 Feb 2024 17:31:00 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalAttributes [v2]
In-Reply-To: <MEK1VnDN7TNVFZIFOXjbz1uumsnX4KG5jDJHKf7dDwg=.62aa368a-2cac-484d-b57e-ad411d510b84@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com>
 <J38tb6Yh9NrbtUG9BHQnOMKfDSztmQnS8C-y0pNqlwg=.b3a137e6-8d7d-40b2-8592-e4072023b679@github.com>
 <udIGk2tax-D_7zchVTKqEolbKx7MEXTsGK8Bki4rU60=.26375c15-9639-437a-8e3c-964f51b052d1@github.com>
 <MEK1VnDN7TNVFZIFOXjbz1uumsnX4KG5jDJHKf7dDwg=.62aa368a-2cac-484d-b57e-ad411d510b84@github.com>
Message-ID: <5vVA_gN2SdDN8XtWtebLuVD8zvUy6_0haF5Gs4tOBX4=.0b16f411-81f3-4255-9867-6d9918a80dcb@github.com>

On Fri, 2 Feb 2024 20:43:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think the proposed change above makes things clearer. Perhaps also make the same change in zipfs as well while you are at it?

I have pushed the rename to "ZipEntry.externalFileAttributes". Also renamed `ZipFileSystem.Entry.posixPerms` to `ZipFileSystem.Entry.externalFileAttributes`. Hopefully this makes things clearer.

A side note: The Posix support in `ZipFileSystem` is somewhat odd in that it supports the notion of a `null` permission set. So setting the permissions attribute to `null` clears all the attributes, not just the permisson ones.  But even so, I think using the full name here is also an improvement, since it signals that the field may also carry preexisting file type, setuid, setgid, sticky bits.

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1925403883


From alanb at openjdk.org  Sun Feb  4 06:58:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Feb 2024 06:58:03 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <LEnAFb3hUSyQMp4opFV1q8aiMDKd21r7C9OyADn11Ik=.c4fa23c1-ebca-451f-b799-eab90d03a2d9@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

I skimmed through the use sites and don't see any issues. There is one bucket of escaping "this" that will go away once the support for running with the SM goes away.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1861282672


From dholmes at openjdk.org  Sun Feb  4 22:50:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 4 Feb 2024 22:50:17 GMT
Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC
Message-ID: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>

This update drops the "ea" from the version string.

We also propagate the following fixes from the markdown sources to the troff manpage file:

JDK-8322478: Update java manpage for multi-file source-code launcher
JDK-8302233: HSS/LMS: keytool and jarsigner changes
JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files


Thanks.

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

Commit messages:
 - 8322066: Update troff pages in JDK 22 before RC

Changes: https://git.openjdk.org/jdk22/pull/104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322066
  Stats: 160 lines in 28 files changed: 63 ins; 15 del; 82 mod
  Patch: https://git.openjdk.org/jdk22/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/104/head:pull/104

PR: https://git.openjdk.org/jdk22/pull/104


From erikj at openjdk.org  Mon Feb  5 15:12:01 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 Feb 2024 15:12:01 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <qpu0rr5ib5ZvRO6hylKRD5KO0rfmUO1gNNemxhXv-eU=.dfc31d2c-4623-4a51-8234-c1858b792cb8@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863050713


From naoto at openjdk.org  Mon Feb  5 23:49:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Feb 2024 23:49:48 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <SZHlwkWLaMVo8BYNpOoPoaiQpxadXA3LfEfG219Hp-o=.5e93abfb-bd13-4b72-8dd6-4fa5a41fce8c@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863359999


From darcy at openjdk.org  Mon Feb  5 23:49:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Feb 2024 23:49:58 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
Message-ID: <fE8yWz13Mf_WGqTZ1gE7MpJespk8nc06W-xVbWXeZVA=.d63183bb-fddc-47f2-8ff4-1258c10d7337@github.com>

On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well.
> 
> I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated.

Filed [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263) .

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1928049947


From smarks at openjdk.org  Mon Feb  5 23:49:52 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 5 Feb 2024 23:49:52 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <3ItCUEGtxTObo5TxNsOIPfMr15fWdQPm3CAi7eNcOv4=.506a52bb-ad1a-429a-9906-5ae1dccfdad2@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Changes in java.util and java.util.concurrent look fine.

There are a startling number of places where `this` is potentially leaked to a subclass. It would be interesting to analyze the pathologies and have a discussion of potential fixes. There may also be compatibility issues with potential fixes (nothing in this PR that I can see) because the behavior can change from the point of view of subclasses.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863853251


From mbalao at openjdk.org  Mon Feb  5 23:50:45 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 5 Feb 2024 23:50:45 GMT
Subject: RFR: 8325254: CKA_TOKEN private and secret keys are not necessarily
 sensitive
Message-ID: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>

Hi,

May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?

With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.

No regressions observed in jdk/sun/security/pkcs11.

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

Commit messages:
 - 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive

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

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


From darcy at openjdk.org  Mon Feb  5 23:56:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Feb 2024 23:56:08 GMT
Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC
In-Reply-To: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
References: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
Message-ID: <JpJ7fBK_scQD13UZdtIO_B5ibXDQos_iDrQ8dro_YgM=.6ae9d6c5-1def-4108-a275-7f5bf4c7fc2b@github.com>

On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This update drops the "ea" from the version string.
> 
> We also propagate the following fixes from the markdown sources to the troff manpage file:
> 
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233: HSS/LMS: keytool and jarsigner changes
> JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
> 
> 
> Thanks.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/104#pullrequestreview-1863882694


From iris at openjdk.org  Tue Feb  6 03:11:03 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 6 Feb 2024 03:11:03 GMT
Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC
In-Reply-To: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
References: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
Message-ID: <4cRyPED3qle_BVYZkKe7WqzTTTypo6nFookYaFGeCDw=.a49cec00-d0b4-4f09-85f0-e5c2ce730792@github.com>

On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This update drops the "ea" from the version string.
> 
> We also propagate the following fixes from the markdown sources to the troff manpage file:
> 
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233: HSS/LMS: keytool and jarsigner changes
> JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
> 
> 
> Thanks.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/104#pullrequestreview-1864200734


From dholmes at openjdk.org  Tue Feb  6 04:58:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Feb 2024 04:58:53 GMT
Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC
In-Reply-To: <JpJ7fBK_scQD13UZdtIO_B5ibXDQos_iDrQ8dro_YgM=.6ae9d6c5-1def-4108-a275-7f5bf4c7fc2b@github.com>
References: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
 <JpJ7fBK_scQD13UZdtIO_B5ibXDQos_iDrQ8dro_YgM=.6ae9d6c5-1def-4108-a275-7f5bf4c7fc2b@github.com>
Message-ID: <FSy9f973gXj84Ajd9__EnOKfPyXHbbWaFo1NRR8MeKM=.6f57bddd-83fb-4f1f-8c50-e5fb7089586d@github.com>

On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This update drops the "ea" from the version string.
>> 
>> We also propagate the following fixes from the markdown sources to the troff manpage file:
>> 
>> JDK-8322478: Update java manpage for multi-file source-code launcher
>> JDK-8302233: HSS/LMS: keytool and jarsigner changes
>> JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
>> 
>> 
>> Thanks.
>
> Marked as reviewed by darcy (Reviewer).

Thanks for the reviews @jddarcy  and @irisclark !

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

PR Comment: https://git.openjdk.org/jdk22/pull/104#issuecomment-1928783920


From dholmes at openjdk.org  Tue Feb  6 04:58:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Feb 2024 04:58:54 GMT
Subject: [jdk22] Integrated: 8322066: Update troff manpages in JDK 22 before RC
In-Reply-To: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
References: <Bn2yaD_18c678eQYCUsUyuwOAHSiVkwu2AK6aMB7FNA=.d21f35d6-bbab-400c-a420-54d8098bddde@github.com>
Message-ID: <43aREZ6MAFvrQojZi3ALfLy7yqlrS76R3HUs5lil8xE=.2471360a-6946-4dbc-91e8-386b5d31df58@github.com>

On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This update drops the "ea" from the version string.
> 
> We also propagate the following fixes from the markdown sources to the troff manpage file:
> 
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233: HSS/LMS: keytool and jarsigner changes
> JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
> 
> 
> Thanks.

This pull request has now been integrated.

Changeset: ac7a3c00
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/ac7a3c00bbfde173ced08d8745b308bc0ac9649b
Stats:     160 lines in 28 files changed: 63 ins; 15 del; 82 mod

8322066: Update troff manpages in JDK 22 before RC

Reviewed-by: darcy, iris

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

PR: https://git.openjdk.org/jdk22/pull/104


From jpai at openjdk.org  Tue Feb  6 10:11:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Feb 2024 10:11:15 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't
 specify the behaviour for null arguments
Message-ID: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>

Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?

For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

Commit messages:
 - 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments

Changes: https://git.openjdk.org/jdk/pull/17728/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325304
  Stats: 75 lines in 15 files changed: 53 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/17728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728

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


From jpai at openjdk.org  Tue Feb  6 10:11:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Feb 2024 10:11:15 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <iVTpppBiadJaAgofQYkdgQGks4tNHTNzi2zdm0lBNWw=.52ef5e6c-b804-4a48-8c19-d69f8ae6b850@github.com>

On Tue, 6 Feb 2024 10:05:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

A CSR has been created for this change https://bugs.openjdk.org/browse/JDK-8325305

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1929174410


From jpai at openjdk.org  Tue Feb  6 10:31:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Feb 2024 10:31:06 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v2]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <zxWSQDN2IPaaKiOcH_MbVx2VkikLG8r7009QzUHZSOc=.b82aba2a-8a63-410b-9b8b-d7588ea9a6f5@github.com>

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  include CheckedInputStream and CheckedOutputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/298d0a0a..e4c724fc

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

  Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728

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


From ogillespie at openjdk.org  Tue Feb  6 10:41:55 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 6 Feb 2024 10:41:55 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v2]
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <5Zme6CJoXxyGFf1GnL35BvU5xkTl7BGgEo7elUlGAvs=.6593072f-8e41-4d9b-bb89-6bb6856c6cb0@github.com>

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

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

  Throw exception if params non-null, remove original constructors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17560/files
  - new: https://git.openjdk.org/jdk/pull/17560/files/d537b80c..de4d83ac

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

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

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


From ogillespie at openjdk.org  Tue Feb  6 10:41:56 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 6 Feb 2024 10:41:56 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <nOzWnG2SovnxfbjfrXRSSm51L_m9Uj8EUGLPo3jsMzk=.d5a33dbd-7bc7-4af5-a011-453ca1442cd7@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

Thanks. Updated with option 1 and removed old constructors.

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1929231445


From lancea at openjdk.org  Tue Feb  6 11:27:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 6 Feb 2024 11:27:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v2]
In-Reply-To: <zxWSQDN2IPaaKiOcH_MbVx2VkikLG8r7009QzUHZSOc=.b82aba2a-8a63-410b-9b8b-d7588ea9a6f5@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <zxWSQDN2IPaaKiOcH_MbVx2VkikLG8r7009QzUHZSOc=.b82aba2a-8a63-410b-9b8b-d7588ea9a6f5@github.com>
Message-ID: <7UNzPvlv7CNUQ5kWN9RCnrcxLDfjLzGk6bfYxPL-uhI=.e1846f96-6ad8-4e48-95c3-18d940ef599b@github.com>

On Tue, 6 Feb 2024 10:31:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include CheckedInputStream and CheckedOutputStream

Hi Jai,

Thank you for tackling this.  An initial comment on a quick read

I noticed you use "can cause" here and later use "will cause".  I think we should try to be consistent.

Perhaps we should use "will result in a..."

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1864907969


From ihse at openjdk.org  Tue Feb  6 11:39:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 11:39:57 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <hMv74_Mz6j4w5HMKHfGqeYuSNKUfu3ywR8Zdxv3nUBQ=.8965f0fa-9ea6-467b-b8a3-4a1dc59c2d76@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

@DougLea Doug, do you have anything to say about the changes in `java.util.concurrent`?

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1929336942


From shade at openjdk.org  Tue Feb  6 11:39:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Feb 2024 11:39:57 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v3]
In-Reply-To: <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>
Message-ID: <werMIYnBAJF49fkAF-ZwkyryyRRjCzt8FvAprRWxEMM=.bb8adf85-a9d6-4a17-8db5-b63fffb9dc0e@github.com>

On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use class literals instead of forName

I like it even more with class literals.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17559#pullrequestreview-1864928935


From ihse at openjdk.org  Tue Feb  6 12:27:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 12:27:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <XSGj9zsG14OM3pa1GR8qlZmOC6bp0pMb3bMj8UOCFF4=.7880f388-3caf-49d4-95ec-f5405974ba53@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Build changes look fine, but there is really a *lot* of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :(

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865022402


From jpai at openjdk.org  Tue Feb  6 12:30:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Feb 2024 12:30:10 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v3]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <hIzfRDULchcW2MqDkLs9S7gJzgzXPeWY2KO31o2pBUA=.56c7305e-a919-4d24-99bd-ccd85dee6539@github.com>

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  Lance's review - replace can cause with will cause

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/e4c724fc..f92c5726

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

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

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


From jpai at openjdk.org  Tue Feb  6 12:36:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Feb 2024 12:36:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v3]
In-Reply-To: <hIzfRDULchcW2MqDkLs9S7gJzgzXPeWY2KO31o2pBUA=.56c7305e-a919-4d24-99bd-ccd85dee6539@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <hIzfRDULchcW2MqDkLs9S7gJzgzXPeWY2KO31o2pBUA=.56c7305e-a919-4d24-99bd-ccd85dee6539@github.com>
Message-ID: <PYy3Nr54u2nhCSL0RADUl4PR3BYyl1yws3MiKE50JbE=.783e7cd0-6c27-463d-908f-b5c2faf217ee@github.com>

On Tue, 6 Feb 2024 12:30:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - replace can cause with will cause

Hello Lance,

> I noticed you use "can cause" here and later use "will cause". I think we should try to be consistent.
> Perhaps we should use "will result in a..."

My use of "can cause" was indeed inconsistent. I had used it in a couple of places. I have now updated the PR to replace with "will cause".

I decided to use this "will cause" for consistency, since the text:

> "Unless otherwise noted, passing a {@code null} argument to a constructor or method in this class will cause a {@link NullPointerException} to be thrown." 

has been already in use in various other classes (for example `JarFile`'s javadoc) in the JDK even before the proposed changes in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1929434263


From alanb at openjdk.org  Tue Feb  6 12:57:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Feb 2024 12:57:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v3]
In-Reply-To: <hIzfRDULchcW2MqDkLs9S7gJzgzXPeWY2KO31o2pBUA=.56c7305e-a919-4d24-99bd-ccd85dee6539@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <hIzfRDULchcW2MqDkLs9S7gJzgzXPeWY2KO31o2pBUA=.56c7305e-a919-4d24-99bd-ccd85dee6539@github.com>
Message-ID: <4NPhNHLZWM18ESOdPe-C3fuIKs5WVi104LZIipFvizQ=.ff9040d5-2b46-4688-ad75-787c8eaaf4a0@github.com>

On Tue, 6 Feb 2024 12:30:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's review - replace can cause with will cause

The changes means that NPE is specified in both the class description and method descriptions in some cases, e.g. JarInputStream. I assume you meant to remove the NPE from methods where you've added a statement in the class description.

Minor nit is some of the usages of `<p>` in the change are inconsistent with the usages close by, you probably want to keep them consistent if you can.

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1929465055


From weijun at openjdk.org  Tue Feb  6 13:07:55 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Feb 2024 13:07:55 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v3]
In-Reply-To: <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>
Message-ID: <bdHYqchU3kEWHCIaFHG8ESxX63y28-Dgzd0JFkbkw2w=.9fdabad2-8a41-4f70-8487-8193ab9d0f6f@github.com>

On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use class literals instead of forName

LGTM.

BTW, is there any change in benchmark scores?

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17559#pullrequestreview-1865113779


From ogillespie at openjdk.org  Tue Feb  6 13:42:54 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 6 Feb 2024 13:42:54 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v3]
In-Reply-To: <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <YLxAsPHVWKvDZ7Xo4lSx6xLJntNYA1Czwtn1ocpjNq0=.b4948693-ff67-4371-8cfe-7e50b90da52d@github.com>
Message-ID: <5BiHX1xffS8xhWXfo_5ilJh4QyO6s4gFNPnQjxCYvBY=.0a3a166e-18c2-4384-b228-2677308ff438@github.com>

On Thu, 1 Feb 2024 10:39:27 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use class literals instead of forName

Thank you :) No change in benchmark score, or perhaps slight improvement. There seem to be two modes, one at 2400ns/op (same as original change) and one around 2200ns/op.


# Fork: 1 of 3
# Warmup Iteration   1: 3552.303 ns/op
# Warmup Iteration   2: 2906.823 ns/op
# Warmup Iteration   3: 2404.065 ns/op
# Warmup Iteration   4: 2396.532 ns/op
# Warmup Iteration   5: 2416.137 ns/op
Iteration   1: 2418.132 ns/op
Iteration   2: 2410.748 ns/op
Iteration   3: 2396.958 ns/op
Iteration   4: 2410.428 ns/op
Iteration   5: 2403.168 ns/op

# Fork: 2 of 3
# Warmup Iteration   1: 3156.931 ns/op
# Warmup Iteration   2: 2606.873 ns/op
# Warmup Iteration   3: 2175.693 ns/op
# Warmup Iteration   4: 2250.570 ns/op
# Warmup Iteration   5: 2152.489 ns/op
Iteration   1: 2190.243 ns/op
Iteration   2: 2153.819 ns/op
Iteration   3: 2175.183 ns/op
Iteration   4: 2179.866 ns/op
Iteration   5: 2150.761 ns/op


# Fork: 3 of 3
# Warmup Iteration   1: 3489.428 ns/op
# Warmup Iteration   2: 2851.548 ns/op
# Warmup Iteration   3: 2410.677 ns/op
# Warmup Iteration   4: 2427.988 ns/op
# Warmup Iteration   5: 2414.204 ns/op
Iteration   1: 2412.798 ns/op
Iteration   2: 2417.093 ns/op
Iteration   3: 2414.075 ns/op
Iteration   4: 2442.164 ns/op
Iteration   5: 2410.162 ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1929648313


From weijun at openjdk.org  Tue Feb  6 13:47:55 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Feb 2024 13:47:55 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v2]
In-Reply-To: <5Zme6CJoXxyGFf1GnL35BvU5xkTl7BGgEo7elUlGAvs=.6593072f-8e41-4d9b-bb89-6bb6856c6cb0@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <5Zme6CJoXxyGFf1GnL35BvU5xkTl7BGgEo7elUlGAvs=.6593072f-8e41-4d9b-bb89-6bb6856c6cb0@github.com>
Message-ID: <ao_FeYDXaOa2ffhTDH_vtzF75a4gKawLjtnMLxlvNFk=.fb070aaf-2732-4b0c-860f-144affcc7cca@github.com>

On Tue, 6 Feb 2024 10:41:55 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
>> 
>> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
>> 
>> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
>> 
>> 
>> Before
>> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
>> 
>> After
>> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw exception if params non-null, remove original constructors

Looks good to me.

Please update the copyright year. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17560#pullrequestreview-1865224021


From ogillespie at openjdk.org  Tue Feb  6 13:52:09 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 6 Feb 2024 13:52:09 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v4]
In-Reply-To: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
Message-ID: <Sdzv2rkZRVx1YxIELOe8qqq_mIRDXUDdCM0fHePWR7w=.9080f880-959b-4567-ba53-535376c0a01c@github.com>

> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
> 
> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
> 
> 
> Before
> newSecureRandom  avgt  2930 ? 50  ns/op
> 
> After
> newSecureRandom  avgt  2400 ? 33  ns/op
> 
> 
> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17559/files
  - new: https://git.openjdk.org/jdk/pull/17559/files/45da78f9..719d3219

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

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

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


From ogillespie at openjdk.org  Tue Feb  6 13:54:10 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Tue, 6 Feb 2024 13:54:10 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v3]
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <ezXzUqbsE76Kn2q1TvzYTBHDwVltJJanCYlk9yaYPys=.a3847546-ef9a-4983-868f-73abeb093975@github.com>

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17560/files
  - new: https://git.openjdk.org/jdk/pull/17560/files/de4d83ac..44958eff

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

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

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


From dfuchs at openjdk.org  Tue Feb  6 14:41:56 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Feb 2024 14:41:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

I looked at the modifications in java.net / sun.net. Looks generally good though I have some comments.

src/java.base/share/classes/java/net/Socket.java line 323:

> 321:      * @see        SecurityManager#checkConnect
> 322:      */
> 323:     @SuppressWarnings("this-escape")

This is a weird one. I guess the issue here is that the escape happens in the chained constructor, and is propagated recursively up the constructor chain. Is the suppress warning here still needed after disabling this-escape warning at line 358?

Actually - these are all weird since the only place where the escape happens is in the private constructor at line 548 - and it doesn't even get flagged there (presumably because it's a private constructor?) 

I guess that the rationale is that subclasses cannot override the private constructor (where the escape happen), but can override the public constructor that calls the private constructor where the escape happen. I can't help feeling that the warning would be better placed on the private constructor though. Seeing it here confused me a lot.

src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:

> 51:     }
> 52: 
> 53:     @SuppressWarnings("this-escape")

An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865378355
PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479922189
PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479936447


From mpowers at openjdk.org  Tue Feb  6 17:11:53 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 6 Feb 2024 17:11:53 GMT
Subject: RFR: 8325254: CKA_TOKEN private and secret keys are not
 necessarily sensitive
In-Reply-To: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
References: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
Message-ID: <IHyOHBNn2dxmaiTjtZAY9LfI7sSvhkBBn40Ynd15ZYo=.d352e70a-2668-4b4d-9e13-f43de3755733@github.com>

On Mon, 5 Feb 2024 18:23:30 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
> 
> With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.
> 
> No regressions observed in jdk/sun/security/pkcs11.

Your change looks good to me. It makes sense. What testing has been done?

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

PR Comment: https://git.openjdk.org/jdk/pull/17712#issuecomment-1930387881


From darcy at openjdk.org  Tue Feb  6 17:31:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 17:31:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>
Message-ID: <DcnnBx1j3OpugEZ32t_a6c5TtUXihl7TW6W4A1c7wfc=.750d04e1-f9c0-4c58-ac83-6fd387ec00ac@github.com>

On Tue, 6 Feb 2024 14:35:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.
>
> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
> 
>> 51:     }
>> 52: 
>> 53:     @SuppressWarnings("this-escape")
> 
> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?

I'd prefer if that kind of change were done as a subtask of

[JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480307107


From darcy at openjdk.org  Tue Feb  6 17:43:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 17:43:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <ZI2YqS40yBOAxgajCExkdG7NcOpPjvYywu25NZcw104=.6da918fc-c28d-42a8-b28d-b40c674c3b11@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

> Build changes look fine, but there is really a _lot_ of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :(

I deliberately choose to suppress the warning at each constructor location rather than at the class level so there are more SuppressWarnings annotations than strictly needed to get the build to be clean. However, I thought limiting the scope of the annotations was preferable for several reasons, including more precisely indicating where any code updates are needed.

This is a new warning run over old code, in some cases very old code. I don't find it surprising that there were several hundred instances of this warning in java.base given the amount of code there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1930451875


From joehw at openjdk.org  Tue Feb  6 18:07:56 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 6 Feb 2024 18:07:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <AUmgRDOc_xd5B0oFZboOpaE1TMccN4gf-IKkfcmJUyk=.c00e299e-b04b-4688-816c-e1e89693e466@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

The two XML changes look good to me. There would be a lot of warnings in the java.xml module as well, if we had to do it in the future.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866004351


From lancea at openjdk.org  Tue Feb  6 18:13:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 6 Feb 2024 18:13:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <cRl8n_pGXA3YeoIGsx-i4W2PXqLckhyZDGcW_QkH8og=.6a6c38d6-be24-4087-abcd-fbff9ffa4d62@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866015274


From dfuchs at openjdk.org  Tue Feb  6 18:20:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Feb 2024 18:20:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <DcnnBx1j3OpugEZ32t_a6c5TtUXihl7TW6W4A1c7wfc=.750d04e1-f9c0-4c58-ac83-6fd387ec00ac@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>
 <DcnnBx1j3OpugEZ32t_a6c5TtUXihl7TW6W4A1c7wfc=.750d04e1-f9c0-4c58-ac83-6fd387ec00ac@github.com>
Message-ID: <bGEDEinASOI1ApbLv_K_WXRu3iHlLb5usSo_gMfQwWc=.dd721bf7-052b-4d9f-9ca3-3f46a171302c@github.com>

On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
>> 
>>> 51:     }
>>> 52: 
>>> 53:     @SuppressWarnings("this-escape")
>> 
>> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?
>
> I'd prefer if that kind of change were done as a subtask of
> 
> [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella)

Thanks Joe. I logged [JDK-8325361](https://bugs.openjdk.org/browse/JDK-8325361): Make sun.net.www.MessageHeader final

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480362736


From mbalao at openjdk.org  Tue Feb  6 18:24:54 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 6 Feb 2024 18:24:54 GMT
Subject: RFR: 8325254: CKA_TOKEN private and secret keys are not
 necessarily sensitive
In-Reply-To: <IHyOHBNn2dxmaiTjtZAY9LfI7sSvhkBBn40Ynd15ZYo=.d352e70a-2668-4b4d-9e13-f43de3755733@github.com>
References: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
 <IHyOHBNn2dxmaiTjtZAY9LfI7sSvhkBBn40Ynd15ZYo=.d352e70a-2668-4b4d-9e13-f43de3755733@github.com>
Message-ID: <L9ilmLUbMD6RKbbVrWHYe6cHc_QkTzvjsIgts_Qs2m0=.40db68ec-e2f9-4f3b-beda-0267a2e52856@github.com>

On Tue, 6 Feb 2024 17:09:26 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Hi,
>> 
>> May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
>> 
>> With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>
> Your change looks good to me. It makes sense. What testing has been done?

Hi @mcpowers ,

Thanks for having a look at this proposal. I ran a regression over jdk/sun/security/pkcs11 which exercises the code with the NSS Software Token, and all 111 tests passed. In addition, I asked the people who originally reported this bug to me to do some tests to confirm that JDK-8271566 introduced an observable change in behavior for the KeyStore::getKey public API. These tests included a CKA_TOKEN = TRUE, CKA_SENSITIVE = FALSE, CKA_EXTRACTABLE = TRUE case where we could see how 8271566 made their hardware token to return an opaque key instead of one with all the information. I am personally confident about this change, which does nothing more than returning to pre-8271566 behavior for non-NSS tokens and keeping the new behavior for NSS.  If someone has more hardware tokens to test, I'd appreciate any additional feedback.

Martin.-

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

PR Comment: https://git.openjdk.org/jdk/pull/17712#issuecomment-1930516127


From liach at openjdk.org  Tue Feb  6 18:33:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Feb 2024 18:33:56 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v3]
In-Reply-To: <ezXzUqbsE76Kn2q1TvzYTBHDwVltJJanCYlk9yaYPys=.a3847546-ef9a-4983-868f-73abeb093975@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <ezXzUqbsE76Kn2q1TvzYTBHDwVltJJanCYlk9yaYPys=.a3847546-ef9a-4983-868f-73abeb093975@github.com>
Message-ID: <_QvrIM8o1YKG1PMUGCSCNrtqyfWtXVnAXf3fPMUtiGc=.e3bcf079-61b6-4766-a841-2a424917bfe1@github.com>

On Tue, 6 Feb 2024 13:54:10 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
>> 
>> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
>> 
>> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
>> 
>> 
>> Before
>> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
>> 
>> After
>> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/17560#pullrequestreview-1866049371


From valeriep at openjdk.org  Tue Feb  6 18:35:53 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Feb 2024 18:35:53 GMT
Subject: RFR: 8325254: CKA_TOKEN private and secret keys are not
 necessarily sensitive
In-Reply-To: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
References: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
Message-ID: <n0MeUCmRqtRJN6WMao6lTWy2RhGYSjEFOeCFzt77B4Q=.93497754-8002-44ef-a554-d2d04256e642@github.com>

On Mon, 5 Feb 2024 18:23:30 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
> 
> With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.
> 
> No regressions observed in jdk/sun/security/pkcs11.

Marked as reviewed by valeriep (Reviewer).

Since the existing tests use NSS, the change should not cause any difference. Just curious,  do you know what PKCS11 library/impl the reporter uses? Would be nice to include it into the bug record as additional information.

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

PR Review: https://git.openjdk.org/jdk/pull/17712#pullrequestreview-1866052205
PR Comment: https://git.openjdk.org/jdk/pull/17712#issuecomment-1930532518


From valeriep at openjdk.org  Tue Feb  6 18:49:54 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 6 Feb 2024 18:49:54 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v3]
In-Reply-To: <ezXzUqbsE76Kn2q1TvzYTBHDwVltJJanCYlk9yaYPys=.a3847546-ef9a-4983-868f-73abeb093975@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <ezXzUqbsE76Kn2q1TvzYTBHDwVltJJanCYlk9yaYPys=.a3847546-ef9a-4983-868f-73abeb093975@github.com>
Message-ID: <N54SMnAn6pj1_pxwKr34qubKqCfDvSbHnWB1cGCqaGI=.0555ec17-7c8f-4417-86b6-a7eecc172d47@github.com>

On Tue, 6 Feb 2024 13:54:10 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
>> 
>> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
>> 
>> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
>> 
>> 
>> Before
>> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
>> 
>> After
>> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 207:

> 205:     // constructor, called by the JCA framework
> 206:     public NativePRNG(SecureRandomParameters params) {
> 207:         super();

nit: maybe super() not needed? Same goes for the Blocking and NonBlocking ctors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17560#discussion_r1480394162


From mbalao at openjdk.org  Tue Feb  6 19:51:58 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 6 Feb 2024 19:51:58 GMT
Subject: RFR: 8325254: CKA_TOKEN private and secret keys are not
 necessarily sensitive
In-Reply-To: <n0MeUCmRqtRJN6WMao6lTWy2RhGYSjEFOeCFzt77B4Q=.93497754-8002-44ef-a554-d2d04256e642@github.com>
References: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
 <n0MeUCmRqtRJN6WMao6lTWy2RhGYSjEFOeCFzt77B4Q=.93497754-8002-44ef-a554-d2d04256e642@github.com>
Message-ID: <JvGpIsAGBp32wZwoA4o4nKf2NK-wgx0_4ah1sofVud8=.1787f4af-6530-4066-9aa4-e1522350f896@github.com>

On Tue, 6 Feb 2024 18:32:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Hi,
>> 
>> May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
>> 
>> With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.
>> 
>> No regressions observed in jdk/sun/security/pkcs11.
>
> Since the existing tests use NSS, the change should not cause any difference. Just curious,  do you know what PKCS11 library/impl the reporter uses? Would be nice to include it into the bug record as additional information.

Hi @valeriepeng ,

Thanks for having a look at this.

> Since the existing tests use NSS, the change should not cause any difference. Just curious, do you know what PKCS11 library/impl the reporter uses? Would be nice to include it into the bug record as additional information.

Yes, good idea. I'll add it to the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/17712#issuecomment-1930641723


From mbalao at openjdk.org  Tue Feb  6 19:51:59 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 6 Feb 2024 19:51:59 GMT
Subject: Integrated: 8325254: CKA_TOKEN private and secret keys are not
 necessarily sensitive
In-Reply-To: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
References: <3qpwNB4CsH62r2dcEaHv7lqslRY0tIvNEHy5Z1NJlM0=.8fbbf31c-9372-4fa4-8475-349997da7d10@github.com>
Message-ID: <6rhSlYC2a6YVI-KTUgJA1rlykhCavl9_QsDnlEUkWII=.65db5eb0-96e6-4f2a-8a0f-21e94c76f270@github.com>

On Mon, 5 Feb 2024 18:23:30 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
> 
> With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.
> 
> No regressions observed in jdk/sun/security/pkcs11.

This pull request has now been integrated.

Changeset: 0f5f3c9b
Author:    Martin Balao <mbalao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f5f3c9b9718c610406088327401210486447462
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8325254: CKA_TOKEN private and secret keys are not necessarily sensitive

Reviewed-by: valeriep

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

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


From jpai at openjdk.org  Wed Feb  7 01:38:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 01:38:09 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v4]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <S5DYviFCeCMjyqCzHA3zUNd7yQoO68W7zUn_T8MlbVc=.828adb3b-2de3-4de9-bd65-9eb87a8ef688@github.com>

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  Alan's review - don't repeat NullPointerException specification within same class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/f92c5726..59d4df6b

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

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

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


From jpai at openjdk.org  Wed Feb  7 01:52:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 01:52:06 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  make <p> usage consistent with other similar usages in the file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/59d4df6b..93bccb00

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

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

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


From jpai at openjdk.org  Wed Feb  7 01:57:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 01:57:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
Message-ID: <JODZVhnTlp7Lw_t-LuuzVh6Fv5iacDAmwVYZu7a4LJc=.c06bf747-ddb9-4dea-9cf3-c86716c20579@github.com>

On Wed, 7 Feb 2024 01:52:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make <p> usage consistent with other similar usages in the file

Hello Alan,

> The changes means that NPE is specified in both the class description and method descriptions in some cases, e.g. JarInputStream. I assume you meant to remove the NPE from methods where you've added a statement in the class description.

I wasn't sure if I should remove them from the pre-existing method javadocs, so I had left them without changes. I have now updated the PR to remove them from the method level javadoc where we have now added the class level specification.

> 
> Minor nit is some of the usages of `<p>` in the change are inconsistent with the usages close by, you probably want to keep them consistent if you can.

Updated the PR to address this as well. I have updated it to match whatever the existing style (if any) was in that particular file.

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1931109866


From pkumaraswamy at openjdk.org  Wed Feb  7 06:43:05 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Wed, 7 Feb 2024 06:43:05 GMT
Subject: RFR: 8312383: Improve SSL debug log
Message-ID: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>

During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.

I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
The screen shots are attached here.
[x509_screen_shot_testing.zip](https://github.com/openjdk/jdk/files/14189852/x509_screen_shot_testing.zip)

Also, the internal test runs against this fix are green

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

Commit messages:
 - 8312383: Improve SSL debug log

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

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


From alanb at openjdk.org  Wed Feb  7 09:47:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 09:47:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
Message-ID: <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>

On Wed, 7 Feb 2024 01:52:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make <p> usage consistent with other similar usages in the file

This mostly looks okay, just a few comments.

src/java.base/share/classes/java/util/zip/CheckedOutputStream.java line 48:

> 46:      * value to either {@code out} or {@code cksum} will cause
> 47:      * a {@link NullPointerException} to be thrown from the
> 48:      * {@code write} methods of this {@code CheckedOutputStream}.

What is the reason for specifying the NPE in the method description rather than a throws?

src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 80:

> 78:         // "in" being null isn't allowed. we use a null check for "in"
> 79:         // merely to avoid an unnecessary instance creation of the Deflater
> 80:         // for such erroneous cases.

I see this same comment has been added in 3 places but it's not easy to read and I don't think is needed.

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1867349428
PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481197701
PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481189478


From ogillespie at openjdk.org  Wed Feb  7 09:49:10 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 7 Feb 2024 09:49:10 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v4]
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <Jj65-Z4-HwEtX3iPHGBCNGmXHReO2KisDSg6c219ZAE=.13c9b95f-df03-4f05-b43b-a20c2ca65149@github.com>

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

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

  Remove super() calls

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17560/files
  - new: https://git.openjdk.org/jdk/pull/17560/files/44958eff..e51350b7

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

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

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


From ogillespie at openjdk.org  Wed Feb  7 09:49:10 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 7 Feb 2024 09:49:10 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v3]
In-Reply-To: <N54SMnAn6pj1_pxwKr34qubKqCfDvSbHnWB1cGCqaGI=.0555ec17-7c8f-4417-86b6-a7eecc172d47@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <ezXzUqbsE76Kn2q1TvzYTBHDwVltJJanCYlk9yaYPys=.a3847546-ef9a-4983-868f-73abeb093975@github.com>
 <N54SMnAn6pj1_pxwKr34qubKqCfDvSbHnWB1cGCqaGI=.0555ec17-7c8f-4417-86b6-a7eecc172d47@github.com>
Message-ID: <dFdXjgVZM9TY7I9mPH9ig4ZALbQwPTPyu1jSTocbdLM=.3b154f7b-7482-42c6-8ea7-d6db15d7d107@github.com>

On Tue, 6 Feb 2024 18:46:30 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 207:
> 
>> 205:     // constructor, called by the JCA framework
>> 206:     public NativePRNG(SecureRandomParameters params) {
>> 207:         super();
> 
> nit: maybe super() not needed? Same goes for the Blocking and NonBlocking ctors.

It was already there before, but yes it doesn't do anything useful. The other impls I've checked don't use it, so I'll remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17560#discussion_r1481196524


From jpai at openjdk.org  Wed Feb  7 10:05:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 10:05:08 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v6]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <KYXbJcYq6ZzZrSsMmQKw7Q9-0Pzat46gSwV_TVprm6E=.d9f0e68a-1de4-4302-9915-95f80101ae2f@github.com>

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  no need for code comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/93bccb00..6a9a59c8

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

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

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


From jpai at openjdk.org  Wed Feb  7 10:10:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 10:10:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
 <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
Message-ID: <hOwrgLN-lJNFayelDLKGD3FnK9LbjsQuzyX1McsoYa0=.221535fe-8ee5-4f35-aa91-1e11ec90fe59@github.com>

On Wed, 7 Feb 2024 09:41:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make <p> usage consistent with other similar usages in the file
>
> src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 80:
> 
>> 78:         // "in" being null isn't allowed. we use a null check for "in"
>> 79:         // merely to avoid an unnecessary instance creation of the Deflater
>> 80:         // for such erroneous cases.
> 
> I see this same comment has been added in 3 places but it's not easy to read and I don't think is needed.

I've now updated the PR to remove this code comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481231121


From jpai at openjdk.org  Wed Feb  7 10:16:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 10:16:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
 <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
Message-ID: <xknJyWXNnIYD2UkkGKps-MHm6cs7L-xsW2fc8JvC4nk=.b827131e-e8f2-4137-947e-a8f91e460572@github.com>

On Wed, 7 Feb 2024 09:44:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make <p> usage consistent with other similar usages in the file
>
> src/java.base/share/classes/java/util/zip/CheckedOutputStream.java line 48:
> 
>> 46:      * value to either {@code out} or {@code cksum} will cause
>> 47:      * a {@link NullPointerException} to be thrown from the
>> 48:      * {@code write} methods of this {@code CheckedOutputStream}.
> 
> What is the reason for specifying the NPE in the method description rather than a throws?

These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). So the constructor isn't throwing any `NullPointerException` here and thus adding a `@throws` here would be incorrect. In theory, we could just change the implementation of this constructor to throw a `NullPointerException` if either of these arguments were null, but that might mean a potential breakage of some weird usage of the CheckedInputStream. So I decided to add the `NullPointerException` detail to the constructor description.

Do you think we should instead do something like this for this class and the `CheckedOutputStream` class:


diff --git a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
index 10f72b416d1..76cba26986e 100644
--- a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
+++ b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
@@ -41,10 +41,7 @@ public class CheckedInputStream extends FilterInputStream {
     private final Checksum cksum;
 
     /**
-     * Creates an input stream using the specified Checksum. A null
-     * value to either {@code in} or {@code cksum} will cause
-     * a {@link NullPointerException} to be thrown from the
-     * {@code read} methods of this {@code CheckedInputStream}.
+     * Creates an input stream using the specified Checksum.
      * @param in the input stream
      * @param cksum the Checksum
      */
@@ -57,6 +54,8 @@ public CheckedInputStream(InputStream in, Checksum cksum) {
      * Reads a byte. Will block if no input is available.
      * @return the byte read, or -1 if the end of the stream is reached.
      * @throws    IOException if an I/O error has occurred
+     * @throws    NullPointerException if this {@code CheckedInputStream} was
+     *            constructed with a {@code null} value for {@code in} or {@code cksum}
      */
     public int read() throws IOException {
         int b = in.read();
@@ -75,7 +74,9 @@ public int read() throws IOException {
      * @param len the maximum number of bytes read
      * @return    the actual number of bytes read, or -1 if the end
      *            of the stream is reached.
-     * @throws     NullPointerException If {@code buf} is {@code null}.
+     * @throws     NullPointerException If {@code buf} is {@code null} or
+     *             if this {@code CheckedInputStream} was
+     *             constructed with a {@code null} value for {@code in} or {@code cksum}.
      * @throws     IndexOutOfBoundsException If {@code off} is negative,
      * {@code len} is negative, or {@code len} is greater than
      * {@code buf.length - off}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481237216


From alanb at openjdk.org  Wed Feb  7 10:50:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 10:50:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <xknJyWXNnIYD2UkkGKps-MHm6cs7L-xsW2fc8JvC4nk=.b827131e-e8f2-4137-947e-a8f91e460572@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
 <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
 <xknJyWXNnIYD2UkkGKps-MHm6cs7L-xsW2fc8JvC4nk=.b827131e-e8f2-4137-947e-a8f91e460572@github.com>
Message-ID: <ghIEC451MbDCp1-iSjv3U_Hv75y8iqmWaai7vfUayuk=.b5654881-95a8-40c1-b159-84a3110f9292@github.com>

On Wed, 7 Feb 2024 10:13:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). 

The superclasses FilterInputStream and FilterOutputStream have a a protected field for the underlying stream so it's possible for a subclass to set the underlying stream lazily. I can't recall seeing code in the wild availing of that but it is possible.

CheckedInputStream and CheckedOutputStream date from JDK 1.1 and it's not clear what the intention was. My guess is that it was an oversight/bug to not check for null when constructing directly. Fixing this will help catch buggy code but it does mean a behavior change. I think we have to keep existing behavior for the subclassing case because it is possible for the subclass to set the stream lazily.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481280976


From jpai at openjdk.org  Wed Feb  7 11:16:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 11:16:58 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <ghIEC451MbDCp1-iSjv3U_Hv75y8iqmWaai7vfUayuk=.b5654881-95a8-40c1-b159-84a3110f9292@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
 <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
 <xknJyWXNnIYD2UkkGKps-MHm6cs7L-xsW2fc8JvC4nk=.b827131e-e8f2-4137-947e-a8f91e460572@github.com>
 <ghIEC451MbDCp1-iSjv3U_Hv75y8iqmWaai7vfUayuk=.b5654881-95a8-40c1-b159-84a3110f9292@github.com>
Message-ID: <HAmdIJWsR_OQjeKMnpc0XIWrwzauM7XQP3A-dE6muq0=.6be1bbaf-6a6b-40df-b1d9-73c82626ec04@github.com>

On Wed, 7 Feb 2024 10:47:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). So the constructor isn't throwing any `NullPointerException` here and thus adding a `@throws` here would be incorrect. In theory, we could just change the implementation of this constructor to throw a `NullPointerException` if either of these arguments were null, but that might mean a potential breakage of some weird usage of the CheckedInputStream. So I decided to add the `NullPointerException` detail to the constructor description.
>> 
>> Do you think we should instead do something like this for this class and the `CheckedOutputStream` class:
>> 
>> 
>> diff --git a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
>> index 10f72b416d1..76cba26986e 100644
>> --- a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
>> +++ b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
>> @@ -41,10 +41,7 @@ public class CheckedInputStream extends FilterInputStream {
>>      private final Checksum cksum;
>>  
>>      /**
>> -     * Creates an input stream using the specified Checksum. A null
>> -     * value to either {@code in} or {@code cksum} will cause
>> -     * a {@link NullPointerException} to be thrown from the
>> -     * {@code read} methods of this {@code CheckedInputStream}.
>> +     * Creates an input stream using the specified Checksum.
>>       * @param in the input stream
>>       * @param cksum the Checksum
>>       */
>> @@ -57,6 +54,8 @@ public CheckedInputStream(InputStream in, Checksum cksum) {
>>       * Reads a byte. Will block if no input is available.
>>       * @return the byte read, or -1 if the end of the stream is reached.
>>       * @throws    IOException if an I/O error has occurred
>> +     * @throws    NullPointerException if this {@code CheckedInputStream} was
>> +     *            constructed with a {@code null} value for {@code in} or {@code cksum}
>>       */
>>      public int read() throws IOException {
>>          int b = in.read();
>> @@ -75,7 +74,9 @@ public int read() thro...
>
>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). 
> 
> The superclasses FilterInputStream and FilterOutputStream have a a protected field for the underlying stream so it's possible for a subclass to set the underlying stream lazily. I can't recall seeing code in the wild availing of that but it is possible.
> 
> CheckedInputStream and CheckedOutputStream date from JDK 1.1 and it's not clear what the intention was. My guess is that it was an oversight/bug to not check for null when constructing directly. Fixing this will help catch buggy code but it does mean a behavior change. I think we have to keep existing behavior for the subclassing case because it is possible for the subclass to set the stream lazily.

Given that subclasses could set these fields lazily (however remote the case might be), do you think we should then not specify the `NullPointerException` for the read methods on these 2 classes. In which case I can exclude these 2 classes from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481314236


From alanb at openjdk.org  Wed Feb  7 11:33:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 11:33:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <HAmdIJWsR_OQjeKMnpc0XIWrwzauM7XQP3A-dE6muq0=.6be1bbaf-6a6b-40df-b1d9-73c82626ec04@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
 <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
 <xknJyWXNnIYD2UkkGKps-MHm6cs7L-xsW2fc8JvC4nk=.b827131e-e8f2-4137-947e-a8f91e460572@github.com>
 <ghIEC451MbDCp1-iSjv3U_Hv75y8iqmWaai7vfUayuk=.b5654881-95a8-40c1-b159-84a3110f9292@github.com>
 <HAmdIJWsR_OQjeKMnpc0XIWrwzauM7XQP3A-dE6muq0=.6be1bbaf-6a6b-40df-b1d9-73c82626ec04@github.com>
Message-ID: <pbGjx0hABiwmZEikifN7uPcZqdT4zLegLZSRtFEIXmM=.505beaf5-56b9-4e4d-bfd7-bdb76370290c@github.com>

On Wed, 7 Feb 2024 11:14:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). 
>> 
>> The superclasses FilterInputStream and FilterOutputStream have a a protected field for the underlying stream so it's possible for a subclass to set the underlying stream lazily. I can't recall seeing code in the wild availing of that but it is possible.
>> 
>> CheckedInputStream and CheckedOutputStream date from JDK 1.1 and it's not clear what the intention was. My guess is that it was an oversight/bug to not check for null when constructing directly. Fixing this will help catch buggy code but it does mean a behavior change. I think we have to keep existing behavior for the subclassing case because it is possible for the subclass to set the stream lazily.
>
> Given that subclasses could set these fields lazily (however remote the case might be), do you think we should then not specify the `NullPointerException` for the read methods on these 2 classes. In which case I can exclude these 2 classes from this PR.

It would be simpler to drop CheckedInputStream and CheckedOutputStream and deal with them separately. It's unfortunate that this current effort has run into this but that comes with touching some of the JDK 1.0/1.1 era classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481333286


From jpai at openjdk.org  Wed Feb  7 12:37:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 12:37:23 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  undo changes to CheckedInputStream and CheckedOutputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/6a9a59c8..251e7c85

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

  Stats: 13 lines in 2 files changed: 0 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728

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


From jpai at openjdk.org  Wed Feb  7 12:40:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 12:40:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <pbGjx0hABiwmZEikifN7uPcZqdT4zLegLZSRtFEIXmM=.505beaf5-56b9-4e4d-bfd7-bdb76370290c@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <f_WyeY2-vM4nfpa1GVfX6mO55YN5Ro_Ii1sEbb0gId8=.78df9379-a419-4e73-85ce-c7b4ecb6433c@github.com>
 <xVdwa6a-uaF5D_1vfriOVk3Ip-xWJWcpECxfaucJQxQ=.98d8b61a-8b43-4bd4-b9d4-60184d6b82d2@github.com>
 <xknJyWXNnIYD2UkkGKps-MHm6cs7L-xsW2fc8JvC4nk=.b827131e-e8f2-4137-947e-a8f91e460572@github.com>
 <ghIEC451MbDCp1-iSjv3U_Hv75y8iqmWaai7vfUayuk=.b5654881-95a8-40c1-b159-84a3110f9292@github.com>
 <HAmdIJWsR_OQjeKMnpc0XIWrwzauM7XQP3A-dE6muq0=.6be1bbaf-6a6b-40df-b1d9-73c82626ec04@github.com>
 <pbGjx0hABiwmZEikifN7uPcZqdT4zLegLZSRtFEIXmM=.505beaf5-56b9-4e4d-bfd7-bdb76370290c@github.com>
Message-ID: <X_5qhE0qBtPxSnas19DVMj3OQkOGCneeG4zQzU4Dg78=.4553f81d-f614-4fb4-a9ba-72d2b2aa70a6@github.com>

On Wed, 7 Feb 2024 11:31:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Given that subclasses could set these fields lazily (however remote the case might be), do you think we should then not specify the `NullPointerException` for the read methods on these 2 classes. In which case I can exclude these 2 classes from this PR.
>
> It would be simpler to drop CheckedInputStream and CheckedOutputStream and deal with them separately. It's unfortunate that this current effort has run into this but that comes with touching some of the JDK 1.0/1.1 era classes.

Done. I've updated the PR to undo the changes that were proposed for `CheckedOutputStream` and `CheckedInputStream`. I've also updated the CSR with the latest specification diff from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481410044


From alanb at openjdk.org  Wed Feb  7 12:55:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 12:55:57 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>
Message-ID: <M7kXMNzfpXySDhLkMGMdRGcmmV8HyOtHSPDgtRMzEnI=.466a0ecd-34ed-40c2-b03d-fbb6484e9dd8@github.com>

On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to CheckedInputStream and CheckedOutputStream

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1867740148


From lancea at openjdk.org  Wed Feb  7 13:26:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 7 Feb 2024 13:26:55 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>
Message-ID: <bJULFCYWKaNf2_OB-BuZ2SevI4ftzLy8FAUx4B58CT0=.1e24f594-21af-4511-9c71-f6611d2ba59a@github.com>

On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to CheckedInputStream and CheckedOutputStream

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1867805176


From coffeys at openjdk.org  Wed Feb  7 14:21:53 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 7 Feb 2024 14:21:53 GMT
Subject: RFR: 8312383: Improve SSL debug log
In-Reply-To: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
Message-ID: <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>

On Wed, 7 Feb 2024 06:36:10 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
> 
> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
> The screen shots are attached here.
> [x509_screen_shot_testing.zip](https://github.com/openjdk/jdk/files/14189852/x509_screen_shot_testing.zip)
> 
> Also, the internal test runs against this fix are green



src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 205:

> 203:         X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager();
> 204:         if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
> 205:             SSLLogger.finest("X509ExtendedKeyManager being used: " +

Could the JBS title be made more descriptive ? It's quite vague.

I wonder if "X509KeyManager class: " would be better for displaying.

`createServerPossession` would also benefit from this logging enhancement. I wonder if this belongs in logging during SSLContext creation time instead. Other security-dev engineers may have opinion on that.

IIRC, there's another issue open where we iterate over the certificate contexts of custom tm/km types. The JDK src does it at the moment for the default tm/km but no output given for custom impl. Will be good to have that tied up at some stage also.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 206:

> 204:         if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
> 205:             SSLLogger.finest("X509ExtendedKeyManager being used: " +
> 206:                     (km == null ? "null" : km.getClass().getName()));

do you need to cater for null ? I thought a Dummy manager is returned in such scenarios.

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

PR Review: https://git.openjdk.org/jdk/pull/17742#pullrequestreview-1867928511
PR Review Comment: https://git.openjdk.org/jdk/pull/17742#discussion_r1481545987
PR Review Comment: https://git.openjdk.org/jdk/pull/17742#discussion_r1481546624


From pkumaraswamy at openjdk.org  Wed Feb  7 14:38:53 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Wed, 7 Feb 2024 14:38:53 GMT
Subject: RFR: 8312383: Improve SSL debug log
In-Reply-To: <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>
Message-ID: <C-ojnRL5Sg_T-GXk4sGMa1K9OHeO02EG-QP8WU10ugo=.d5add6dc-6658-469f-8c9f-ad47e3882af1@github.com>

On Wed, 7 Feb 2024 14:19:27 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
>> 
>> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
>> The screen shots are attached here.
>> [x509_screen_shot_testing.zip](https://github.com/openjdk/jdk/files/14189852/x509_screen_shot_testing.zip)
>> 
>> Also, the internal test runs against this fix are green
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 206:
> 
>> 204:         if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
>> 205:             SSLLogger.finest("X509ExtendedKeyManager being used: " +
>> 206:                     (km == null ? "null" : km.getClass().getName()));
> 
> do you need to cater for null ? I thought a Dummy manager is returned in such scenarios.

No, I did verify that it always returns Dummy Manager even when key manager is initialized as null. I have added this as a safety net. I'll remove this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17742#discussion_r1481572517


From pkumaraswamy at openjdk.org  Wed Feb  7 15:29:53 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Wed, 7 Feb 2024 15:29:53 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection
In-Reply-To: <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>
Message-ID: <0gxlpmwKCNsek-I3DTVBtsFOXixxCTtHSg4UBUYrOcg=.364f5af5-9fdb-412f-96b7-01f136382ae0@github.com>

On Wed, 7 Feb 2024 14:19:03 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
>> 
>> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
>> The screen shots are attached here.
>> [x509_screen_shot_testing.zip](https://github.com/openjdk/jdk/files/14189852/x509_screen_shot_testing.zip)
>> 
>> Also, the internal test runs against this fix are green
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 205:
> 
>> 203:         X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager();
>> 204:         if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
>> 205:             SSLLogger.finest("X509ExtendedKeyManager being used: " +
> 
> Could the JBS title be made more descriptive ? It's quite vague.
> 
> I wonder if "X509KeyManager class: " would be better for displaying.
> 
> `createServerPossession` would also benefit from this logging enhancement. I wonder if this belongs in logging during SSLContext creation time instead. Other security-dev engineers may have opinion on that.
> 
> IIRC, there's another issue open where we iterate over the certificate contexts of custom tm/km types. The JDK src does it at the moment for the default tm/km but no output given for custom impl. Will be good to have that tied up at some stage also.

I have changed the title to reflect the specific change made here.
I'll make changes in createServerPossession as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17742#discussion_r1481655887


From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <AbyHgk1wHchuCkp0snusjEkqPmCzyc_IRaEbP8f9tNE=.eb528716-b511-4d83-a3a9-480f8487ff6d@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Just to confirm publicly, there is no need for any special handling of `java.util.concurrent` any longer; the JDK repo is the single source of truth nowadays.

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1932335281


From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: Integrated: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <xk3ADOyZQDY-sxr5Ph7VYQTzRabzGFg0kBCsVxThQro=.b8764313-7ea0-4939-93a5-8e9501b63756@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

This pull request has now been integrated.

Changeset: 18e24d06
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18e24d0619ffef7c6dbfc419105faba9f7ba1874
Stats:     61 lines in 39 files changed: 0 ins; 0 del; 61 mod

8325109: Sort method modifiers in canonical order

Reviewed-by: aivanov, rriggs, darcy, prappo

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

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


From valeriep at openjdk.org  Wed Feb  7 18:40:02 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 Feb 2024 18:40:02 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v4]
In-Reply-To: <Jj65-Z4-HwEtX3iPHGBCNGmXHReO2KisDSg6c219ZAE=.13c9b95f-df03-4f05-b43b-a20c2ca65149@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <Jj65-Z4-HwEtX3iPHGBCNGmXHReO2KisDSg6c219ZAE=.13c9b95f-df03-4f05-b43b-a20c2ca65149@github.com>
Message-ID: <RqS6B1bfAfEsp-vRw0PlNtKtg6FXlE5p_wzsCTlNRbk=.318d8248-ac30-4cad-bd16-6a0a7b566eec@github.com>

On Wed, 7 Feb 2024 09:49:10 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
>> 
>> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
>> 
>> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
>> 
>> 
>> Before
>> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
>> 
>> After
>> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove super() calls

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17560#pullrequestreview-1868524507


From weijun at openjdk.org  Wed Feb  7 19:08:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Feb 2024 19:08:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1868572210


From darcy at openjdk.org  Wed Feb  7 19:28:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 19:28:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v2]
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <jp74YWXh1wYnLIE5t-LxJvXUc6CNAs7O-EL_7gAPITw=.cd1f7fff-6c06-4a36-8b45-7277ff553e91@github.com>

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

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

 - Merge branch 'master' into JDK-8325189
 - JDK-8325189: Enable this-escape javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17692/files
  - new: https://git.openjdk.org/jdk/pull/17692/files/8a160a7c..e1d56388

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

  Stats: 5575 lines in 160 files changed: 3404 ins; 1290 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/17692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692

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


From darcy at openjdk.org  Wed Feb  7 20:08:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:18 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v3]
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <L7nEoVs-6ael9bm5bVO8_DaOxMprSmoQGJSdqdPgs58=.f1307b51-c620-438d-bab7-894500bb991d@github.com>

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

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

 - Merge branch 'master' into JDK-8325189
 - Merge branch 'master' into JDK-8325189
 - JDK-8325189: Enable this-escape javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17692/files
  - new: https://git.openjdk.org/jdk/pull/17692/files/e1d56388..bc6cdfc8

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

  Stats: 1057 lines in 91 files changed: 598 ins; 167 del; 292 mod
  Patch: https://git.openjdk.org/jdk/pull/17692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692

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


From darcy at openjdk.org  Wed Feb  7 20:08:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:19 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v2]
In-Reply-To: <jp74YWXh1wYnLIE5t-LxJvXUc6CNAs7O-EL_7gAPITw=.cd1f7fff-6c06-4a36-8b45-7277ff553e91@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <jp74YWXh1wYnLIE5t-LxJvXUc6CNAs7O-EL_7gAPITw=.cd1f7fff-6c06-4a36-8b45-7277ff553e91@github.com>
Message-ID: <FYWvDDXgiscOfzZp5HB6c8ynDIJsRaDOjkzxtgbaPjo=.fde686ba-c4aa-4857-8d70-d77e3fcbd25a@github.com>

On Wed, 7 Feb 2024 19:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8325189
>  - JDK-8325189: Enable this-escape javac warning in java.base

Thanks all for the reviews. Will integrate now after a sync with mainline and successful cross-platform build run.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932778005


From darcy at openjdk.org  Wed Feb  7 20:08:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:19 GMT
Subject: Integrated: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <LkBQc7hq4weFI6vUgKm3EZehMXS9-BzY-Gc9rhFAu-I=.84d1d82b-7522-484d-a48d-256f3c0ce5c2@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

This pull request has now been integrated.

Changeset: fbd15b20
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbd15b20878b276ccd41128116f73b91b6d4c159
Stats:     151 lines in 93 files changed: 149 ins; 0 del; 2 mod

8325189: Enable this-escape javac warning in java.base

Reviewed-by: alanb, erikj, naoto, smarks, ihse, joehw, lancea, weijun

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

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


From darcy at openjdk.org  Wed Feb  7 20:40:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:40:59 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v3]
In-Reply-To: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>
Message-ID: <WhC6zrDWuc-eTsDycVlO2KbUhPUjwWssLrAxlRlntSw=.5dc6d8e1-06b8-48ef-b2b1-c75a602ba6d7@github.com>

On Wed, 7 Feb 2024 19:06:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact.

In case you didn't see it, the warning message are listed in an attachment on [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263).

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932829588


From jpai at openjdk.org  Thu Feb  8 06:37:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Feb 2024 06:37:57 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 <azH-sHNZXg4L6noi6fub4SrsF68b2DjevaxGy7D5ejQ=.86b0ea41-13d6-4d26-aee1-209f8a21e603@github.com>
Message-ID: <Xq6QmiSSGVBatLHVgqKuKfVuElTBt0ZgdluyG31wPF4=.85f3d0f6-7081-4c5f-b19a-9a098339b62e@github.com>

On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to CheckedInputStream and CheckedOutputStream

Thank you Alan and Lance for the reviews. tier1, tier2 and tier3 testing went fine for this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1933441364


From jpai at openjdk.org  Thu Feb  8 06:37:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Feb 2024 06:37:57 GMT
Subject: Integrated: 8325304: Several classes in java.util.jar and
 java.util.zip don't specify the behaviour for null arguments
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: <Z0KDtv7AJDdHNPa6TUdHuq8e_fPR54JAd2UpN_SReYo=.7cff29d9-ff3f-4cae-a4a1-e529a09daaff@github.com>

On Tue, 6 Feb 2024 10:05:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

This pull request has now been integrated.

Changeset: 1fb9e3d6
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fb9e3d674229a2f1b464a09986ad055191966fe
Stats:     63 lines in 14 files changed: 36 ins; 6 del; 21 mod

8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments

Reviewed-by: lancea, alanb

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

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


From pkumaraswamy at openjdk.org  Thu Feb  8 09:11:14 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Thu, 8 Feb 2024 09:11:14 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v2]
In-Reply-To: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
Message-ID: <8MmQ5TjiSC4kgS1fnxNDVetKWHRJtL7z2mGqyW7jSlU=.dfa25656-67e5-4bec-984f-e9e3f5784ebd@github.com>

> During the time of server certificate validation, users have the flexibility to use a custom X509 Key Manager implementation by extending "X509ExtendedKeyManager.".
> In such cases, printing the class name in X509Authentication.java will be helpful to trace any failure of the SSL connection due to a certificate issue.
> 
> I've tested the code by running the custom X509 manager, the default X509 manager, and passing the null key manager.
> The screen shots are attached here.
> [x509_screen_shot_testing.zip](https://github.com/openjdk/jdk/files/14189852/x509_screen_shot_testing.zip)
> 
> Also, the internal test runs against this fix are green

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

 - Add log for client auth
 - Merge remote-tracking branch 'origin/master' into JDK-8312383
 - 8312383: Improve SSL debug log

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17742/files
  - new: https://git.openjdk.org/jdk/pull/17742/files/75b6ed4b..bd8449bd

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

  Stats: 1356 lines in 203 files changed: 844 ins; 179 del; 333 mod
  Patch: https://git.openjdk.org/jdk/pull/17742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17742/head:pull/17742

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


From pkumaraswamy at openjdk.org  Thu Feb  8 09:15:56 2024
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Thu, 8 Feb 2024 09:15:56 GMT
Subject: RFR: 8312383: Log X509ExtendedKeyManager implementation class name
 in TLS/SSL connection [v2]
In-Reply-To: <0gxlpmwKCNsek-I3DTVBtsFOXixxCTtHSg4UBUYrOcg=.364f5af5-9fdb-412f-96b7-01f136382ae0@github.com>
References: <tFkViawAtp_ZQotx3wZ-lz7q-aJ0dB3Ms3EfPyERmA8=.de2a84f9-1b36-42e0-96eb-7dc04e430eb8@github.com>
 <9JdCwKOWBdW4oBqwVbjQbDdexepvokVGuk7-yb02jzk=.e6bd9c32-23d7-41c5-9ff7-a9f01c06ac1c@github.com>
 <0gxlpmwKCNsek-I3DTVBtsFOXixxCTtHSg4UBUYrOcg=.364f5af5-9fdb-412f-96b7-01f136382ae0@github.com>
Message-ID: <ZtBxseoBjP4DEhqppmQpUGB2fmGGta74NsezFm_Kv-A=.00508fa7-8aeb-4b83-98ba-4d08d2adf49d@github.com>

On Wed, 7 Feb 2024 15:27:46 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 205:
>> 
>>> 203:         X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager();
>>> 204:         if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
>>> 205:             SSLLogger.finest("X509ExtendedKeyManager being used: " +
>> 
>> Could the JBS title be made more descriptive ? It's quite vague.
>> 
>> I wonder if "X509KeyManager class: " would be better for displaying.
>> 
>> `createServerPossession` would also benefit from this logging enhancement. I wonder if this belongs in logging during SSLContext creation time instead. Other security-dev engineers may have opinion on that.
>> 
>> IIRC, there's another issue open where we iterate over the certificate contexts of custom tm/km types. The JDK src does it at the moment for the default tm/km but no output given for custom impl. Will be good to have that tied up at some stage also.
>
> I have changed the title to reflect the specific change made here.
> I'll make changes in createServerPossession as well.

I have made changes and attached the testing snapshots in a zip file attached in bug description

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17742#discussion_r1482639556


From weijun at openjdk.org  Thu Feb  8 16:38:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Feb 2024 16:38:22 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object
Message-ID: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>

Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

Commit messages:
 - initial change

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

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


From kdriver at openjdk.org  Thu Feb  8 20:56:02 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 8 Feb 2024 20:56:02 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object
In-Reply-To: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
Message-ID: <wD8S0hYcARbo6SO0eVuOBcW6FXzg-kJt3jdcFaz2kEM=.f52017b9-acb1-4d21-a219-275cab7e79aa@github.com>

On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

See above comment, but otherwise, this looks solid.

test/lib/jdk/test/lib/security/SeededSecureRandom.java line 36:

> 34:  * system property to this recorded seed to reproduce the failure.
> 35:  */
> 36: public class SeededSecureRandom extends SecureRandom {

Do you see any value in bringing this "helper class" from test over to the actual public API? Just a suggestion.

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

Marked as reviewed by kdriver (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17776#pullrequestreview-1871237962
PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1483577625


From weijun at openjdk.org  Fri Feb  9 01:02:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 Feb 2024 01:02:54 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object
In-Reply-To: <wD8S0hYcARbo6SO0eVuOBcW6FXzg-kJt3jdcFaz2kEM=.f52017b9-acb1-4d21-a219-275cab7e79aa@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
 <wD8S0hYcARbo6SO0eVuOBcW6FXzg-kJt3jdcFaz2kEM=.f52017b9-acb1-4d21-a219-275cab7e79aa@github.com>
Message-ID: <Uzq6o9JDAncbaWJ7crwc1tJ4j-TCzEOQJGFOwcGGNTc=.92db1b4d-f913-4cb5-b59a-f5895d5576d9@github.com>

On Thu, 8 Feb 2024 20:53:03 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> test/lib/jdk/test/lib/security/SeededSecureRandom.java line 36:
> 
>> 34:  * system property to this recorded seed to reproduce the failure.
>> 35:  */
>> 36: public class SeededSecureRandom extends SecureRandom {
> 
> Do you see any value in bringing this "helper class" from test over to the actual public API? Just a suggestion.

Where do you want to use it other than in a test? Besides, it's based on `java.util.Random` and not cryptographically random enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1483753416


From weijun at openjdk.org  Fri Feb  9 01:21:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 Feb 2024 01:21:22 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v2]
In-Reply-To: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
Message-ID: <4kUBwfJdhEPgt58b6yM4ItyxyqPNG32cHk_2ThV_-xs=.b418fa7a-148c-4054-8a7c-4e5d5423f0a1@github.com>

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

  cannot control randomness for SunMSCAPI provider

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17776/files
  - new: https://git.openjdk.org/jdk/pull/17776/files/4e7fc6a5..a1715f04

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

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

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


From mbalao at openjdk.org  Fri Feb  9 03:08:15 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 9 Feb 2024 03:08:15 GMT
Subject: RFR: 8315487: Security Providers Filter [v8]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <Q2ZgoovH3IO4wxUs4rLgVTWaklMdnHngekGWKm0cP94=.bf06c7aa-fb3d-42a0-9e22-e9fbf0ac36fe@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:

  Minor changes to align with the JEP.
  
  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/b231a75d..e553cfd1

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

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 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 dclarke at openjdk.org  Fri Feb  9 11:43:22 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Fri, 9 Feb 2024 11:43:22 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start java
 process
Message-ID: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>

Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.

`test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.

I've ran these changes against tiers 1-3 and everything seems stable

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

Commit messages:
 - merge master into branch
 - fixed library use and copyright
 - merge master into branch
 - update tests to use process tools or ignore flags

Changes: https://git.openjdk.org/jdk/pull/17787/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319651
  Stats: 122 lines in 14 files changed: 27 ins; 35 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/17787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17787/head:pull/17787

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


From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
Message-ID: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>

This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 

With Skara jcheck, it is possible to increase the coverage of the whitespace checks.

However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

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

Commit messages:
 - 8325558: Add jcheck whitespace checking for properties files

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

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


From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <vjpYKJQJffU8Erjfn6uucPoPpWriBq1VQhvkztNZ5yg=.834ae963-240f-4bbf-8110-2278d7e17cec@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

I'll add some specific comments/reasoning to individual files, where I think a remark might be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935947566


From dfuchs at openjdk.org  Fri Feb  9 13:55:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Feb 2024 13:55:06 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>

On Fri, 9 Feb 2024 11:38:07 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

test/jdk/java/net/URLClassLoader/getresourceasstream/TestDriver.java line 63:

> 61:                 ),
> 62:                 ProcessTools.createTestJavaProcessBuilder(
> 63:                         "-cp", ".",

If I'm not mistaken, this will result in the `-cp` option being passed twice, with different values, to the `java` sub process. I believe that `ProcessTools.createTestJavaProcessBuilder` will end up passing "-cp <java.class.path>" to the subprocess, unless -Dtest.noclasspath=false is defined in the parent process.
Tough I could not find what would happen if -cp is passed twice in `man java` - it appears that the long standing behaviour is that the last one wins - so I guess that's OK, as I doubt this behaviour (last one wins) could be changed...

An alternative could be to create a new method in ProcessTools that would allow to pass a flag to prevent the addition of -cp <java.class.path> when that's not desiravle, and call that here - and in all other places where -cp is passed to `ProcessTools.createTestJavaProcessBuilder`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1484276695


From ihse at openjdk.org  Fri Feb  9 13:55:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:55:09 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

src/java.base/unix/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.base/windows/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties line 11:

> 9: ImageUtil0=The supplied Raster does not represent a binary data set.
> 10: ImageUtil1=The provided sample model is null.
> 11: ImageUtil2=The provided image cannot be encoded using: 

While it seems like this could have been significant, the code that uses it looks like this:

 throw new IIOException(I18N.getString("ImageUtil2")+" "+
                                   writer.getClass().getName());

so it will end up with a double space right now.

src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling 

This sounded like it could potentially be followed by a name, but this is not the case.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0} 
> 127: crswriter.params2 = Value of params2 : {0} 
> 128: crswriter.conflictsno =  conflicts while synchronizing 

This sounded like it could potentially be followed by a string, but this is not the case.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  

At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties line 20:

> 18: # Messages for message reporting
> 19: BadMessageKey = The error message corresponding to the message key can not be found.
> 20: FormatFailed = An internal error occurred while formatting the following message:\n

At first glance, it might look like something should follow the :, but note that there is a \n so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 27:

> 25: 
> 26:         BadMessageKey = The error message corresponding to the message key can not be found.
> 27:         FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:

> 22: # Messages for message reporting
> 23: BadMessageKey = The error message corresponding to the message key can not be found.
> 24: FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/jdk.compiler/share/classes/sun/tools/serialver/resources/serialver.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 49:

> 47:         'u' flag requires manifest, 'e' flag or input files to be specified!
> 48: error.bad.eflag=\
> 49: 	'e' flag and manifest with the 'Main-Class' attribute cannot be specified \n\

Here were two lines that used tab instead of space; I converted them to 8 spaces.

test/jaxp/javax/xml/jaxp/unittest/common/config/files/catalog2.properties line 4:

> 2: #       XML Library (java.xml) Configuration File
> 3: #
> 4: # This file is in java.util.Properties format and typically located in the conf 

These spaces at the end of comment lines has crept in since I cleaned all such out in [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047). It's a good example of why we need the jcheck verification to keep this from regressing once more.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 12:

> 10: 
> 11: TableDemo.noDataStatusLabel=No data loaded
> 12: TableDemo.loadingStatusLabel=Loading data:\u0020

According to https://github.com/openjdk/jdk/pull/11488/files#r1038605801 the latter two are actually needed as spaces, and the first might be; so keeping it as well seems to be the safe choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326435
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326568
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327614
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327859
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329632
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329770
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484330650
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332081
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332649
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334629
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334259
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335061
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335669
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484337306
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484338418
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484339114
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484341847
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484345466


From dfuchs at openjdk.org  Fri Feb  9 14:10:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Feb 2024 14:10:57 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <MAPhOTYtvVaNcWCFKbDS-_1DUpWDjk7QPxjKCqRkcMU=.6138cf57-eec3-47fd-9932-3ab1d538e789@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

changes to sun/net content-types.properties look OK

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935996382


From ogillespie at openjdk.org  Fri Feb  9 14:21:58 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 9 Feb 2024 14:21:58 GMT
Subject: RFR: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG [v4]
In-Reply-To: <Jj65-Z4-HwEtX3iPHGBCNGmXHReO2KisDSg6c219ZAE=.13c9b95f-df03-4f05-b43b-a20c2ca65149@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
 <Jj65-Z4-HwEtX3iPHGBCNGmXHReO2KisDSg6c219ZAE=.13c9b95f-df03-4f05-b43b-a20c2ca65149@github.com>
Message-ID: <DdCSQ9QB7pHv_6H1k0KPqA1cdxKdtDl4ZLu0cElcPx4=.5e4b2d71-e646-418b-8b81-c935d8e6717c@github.com>

On Wed, 7 Feb 2024 09:49:10 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
>> 
>> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
>> 
>> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
>> 
>> 
>> Before
>> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
>> 
>> After
>> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove super() calls

Thanks for the reviews, all!

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

PR Comment: https://git.openjdk.org/jdk/pull/17560#issuecomment-1936014077


From ogillespie at openjdk.org  Fri Feb  9 14:23:05 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 9 Feb 2024 14:23:05 GMT
Subject: RFR: 8324646: Avoid Class.forName in SecureRandom constructor [v4]
In-Reply-To: <Sdzv2rkZRVx1YxIELOe8qqq_mIRDXUDdCM0fHePWR7w=.9080f880-959b-4567-ba53-535376c0a01c@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
 <Sdzv2rkZRVx1YxIELOe8qqq_mIRDXUDdCM0fHePWR7w=.9080f880-959b-4567-ba53-535376c0a01c@github.com>
Message-ID: <01IIdzQmAYr4OXxG1knDldek1OTbVv_OCBv6x_wVD0c=.0b4cbde7-7b91-4ae3-97f4-f6a454c23c2a@github.com>

On Tue, 6 Feb 2024 13:52:09 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
>> 
>> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
>> 
>> 
>> Before
>> newSecureRandom  avgt  2930 ? 50  ns/op
>> 
>> After
>> newSecureRandom  avgt  2400 ? 33  ns/op
>> 
>> 
>> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Assuming the approvals still hold after the trivial copyright change, I think this is ready to go. Thanks all.

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

PR Comment: https://git.openjdk.org/jdk/pull/17559#issuecomment-1936017246


From ogillespie at openjdk.org  Fri Feb  9 14:40:06 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 9 Feb 2024 14:40:06 GMT
Subject: Integrated: 8324648: Avoid NoSuchMethodError when instantiating
 NativePRNG
In-Reply-To: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
References: <A6RKC6ISph6ZGvS9phITu7QoCsw4cHlMycpkhBW4Pb0=.e59d8c99-6962-4837-b501-0d4c74d983ed@github.com>
Message-ID: <VO3Hn2ygwVvQ--X-qJHPRLPFIFcVvtdbqPTnDleGMnI=.bd458ded-5f06-462b-9f6f-1520470f2af0@github.com>

On Wed, 24 Jan 2024 15:42:05 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> A typical call to `new SecureRandom()` is slowed down by looking for a constructor in NativePRNG which takes `java.security.SecureRandomParameters`. NativePRNG does not have such a constructor, so the search fails [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/security/Provider.java#L1951-L1957), incurring all the cost of the lookup and creating a subsequent exception.
> 
> Creating a dummy constructor which takes and ignores this parameter will speed up `new SecureRandom()` calls significantly. 
> 
> The benchmark from https://github.com/openjdk/jdk/pull/17559 shows around 80% reduction in time taken to create a new SecureRandom with NativePRNG (default on my machine).
> 
> 
> Before
> SecureRandomBench.newSecureRandom  avgt  2930 ? 50 ns/op
> 
> After
> SecureRandomBench.newSecureRandom  avgt  510 ? 16 ns/op

This pull request has now been integrated.

Changeset: 69b2674c
Author:    Oli Gillespie <ogillespie at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69b2674c6861fdb7d9f9cb39e07d50515c73e33a
Stats:     16 lines in 1 file changed: 9 ins; 3 del; 4 mod

8324648: Avoid NoSuchMethodError when instantiating NativePRNG

Reviewed-by: shade, weijun, liach, valeriep

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

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


From ogillespie at openjdk.org  Fri Feb  9 14:41:10 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 9 Feb 2024 14:41:10 GMT
Subject: Integrated: 8324646: Avoid Class.forName in SecureRandom constructor
In-Reply-To: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
References: <uessRL0Gme9TA2OAxktkDRagG97Y1hA6lV4YUWSiPik=.2421a7a4-c566-469f-ba2e-a204733f6bc6@github.com>
Message-ID: <KB-R1ZeIxbI7RCPU9euyKdHXFfjunoJBsbByw_H7_lI=.775ecd1f-ac93-494e-a678-b276ba2072f6@github.com>

On Wed, 24 Jan 2024 15:25:28 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Avoid expensive `Class.forName` call when constructing Providers such as `SecureRandom` which take constructor parameters. This can easily be cached in EngineDescription (this cache already existed before, it was removed in [JDK-8280970](https://bugs.openjdk.org/browse/JDK-8280970) as unused, I'm bringing it back unchanged to support this new usage).
> 
> Benchmark results on my Linux x86 host show around a 20% reduction in time to create a new `SecureRandom` instance. Most of the remaining overhead is due to a failing constructor lookup - see [JDK-8324648](https://bugs.openjdk.org/browse/JDK-8324648).
> 
> 
> Before
> newSecureRandom  avgt  2930 ? 50  ns/op
> 
> After
> newSecureRandom  avgt  2400 ? 33  ns/op
> 
> 
> I have seen multiple real-world applications which call `new SecureRandom()` on the hot path, so I believe efficiency here is important.

This pull request has now been integrated.

Changeset: 8ef918d6
Author:    Oli Gillespie <ogillespie at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ef918d6678437a5b351b172bb4cf144eeaa975f
Stats:     61 lines in 2 files changed: 47 ins; 1 del; 13 mod

8324646: Avoid Class.forName in SecureRandom constructor

Reviewed-by: shade, weijun

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

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


From erikj at openjdk.org  Fri Feb  9 14:56:57 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Feb 2024 14:56:57 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
Message-ID: <nhpBrqfBtPnWkJykz1_einfiy1GazMV7NLU1-ukdtiw=.c2e3123b-9bc5-418e-9785-62a078ab9466@github.com>

On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:
> 
>> 22: 
>> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
>> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  
> 
> At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

That could have been intentional though. Not sure if it was a good idea, but indenting something is a way of making something stand out as a quote. But looking at every use site, there is an extra space added anyway, so this seems fine. If we wanted to preserve the exact same behavior, all use sites should be updated to add 3 spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484416962


From naoto at openjdk.org  Fri Feb  9 18:12:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Feb 2024 18:12:06 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

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

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1872951198


From weijun at openjdk.org  Sat Feb 10 02:21:07 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 10 Feb 2024 02:21:07 GMT
Subject: RFR: 8265372: Simplify PKCS9Attribute [v8]
In-Reply-To: <xJd2eHaQoZv2N-bJF_Kzc0ZNC1iiNzlDztBlZx8nqcE=.b4f76cef-36a4-4f72-90be-5e572134a0e1@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
 <xJd2eHaQoZv2N-bJF_Kzc0ZNC1iiNzlDztBlZx8nqcE=.b4f76cef-36a4-4f72-90be-5e572134a0e1@github.com>
Message-ID: <FTHmuzE6iu_HT8PUncP_92AE90HF2ykXrLxqe_eT2WA=.fa1ca608-7e11-4a92-a613-e4c1002605a8@github.com>

On Wed, 31 Jan 2024 20:47:20 GMT, Ben Perez <duke at openjdk.org> wrote:

>> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
>> 
>> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
>> 
>> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to EncodeDecode test

Looks good to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17132#pullrequestreview-1873381382


From ihse at openjdk.org  Mon Feb 12 08:11:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:11:03 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>
Message-ID: <8BLLuuu7gTj4P8bDZ40PWRJDT7668CSSqMiywzlPrIs=.1f188e66-2327-43e3-b30e-16798937eefe@github.com>

On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

@naotoj Thanks! Would you care to also submit a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1938204446


From djelinski at openjdk.org  Mon Feb 12 10:48:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 12 Feb 2024 10:48:09 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
Message-ID: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>

Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.

This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.

As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.

No new tests. Tier1-3 tests continue to pass.

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

Commit messages:
 - Remove duplicate GCMParameters class

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

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


From dclarke at openjdk.org  Mon Feb 12 11:01:07 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 12 Feb 2024 11:01:07 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
 <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>
Message-ID: <pOPFMkW514Tx4a-etkrjBLEPclnVLPjYwhQhp16nSkE=.41a66da3-6134-4d56-ab6c-1a929fec88a9@github.com>

On Fri, 9 Feb 2024 12:48:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
>> 
>> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
>> 
>> I've ran these changes against tiers 1-3 and everything seems stable
>
> test/jdk/java/net/URLClassLoader/getresourceasstream/TestDriver.java line 63:
> 
>> 61:                 ),
>> 62:                 ProcessTools.createTestJavaProcessBuilder(
>> 63:                         "-cp", ".",
> 
> If I'm not mistaken, this will result in the `-cp` option being passed twice, with different values, to the `java` sub process. I believe that `ProcessTools.createTestJavaProcessBuilder` will end up passing "-cp <java.class.path>" to the subprocess, unless -Dtest.noclasspath=false is defined in the parent process.
> Tough I could not find what would happen if -cp is passed twice in `man java` - it appears that the long standing behaviour is that the last one wins - so I guess that's OK, as I doubt this behaviour (last one wins) could be changed...
> 
> An alternative could be to create a new method in ProcessTools that would allow to pass a flag to prevent the addition of -cp <java.class.path> when that's not desiravle, and call that here - and in all other places where -cp is passed to `ProcessTools.createTestJavaProcessBuilder`.

Would it be possible to change the `createJavaProcessBuilder` method in ProcessTools to include something to check if -cp is already an argument being passed?

maybe something like this?


if (!noCP && !args.contains("-cp")) {
            args.add("-cp");
            args.add(System.getProperty("java.class.path"));
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1486023544


From dfuchs at openjdk.org  Mon Feb 12 12:55:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Feb 2024 12:55:05 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <pOPFMkW514Tx4a-etkrjBLEPclnVLPjYwhQhp16nSkE=.41a66da3-6134-4d56-ab6c-1a929fec88a9@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
 <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>
 <pOPFMkW514Tx4a-etkrjBLEPclnVLPjYwhQhp16nSkE=.41a66da3-6134-4d56-ab6c-1a929fec88a9@github.com>
Message-ID: <NpEUnlpc3rRQU_szdCYeCkFkyUERH8JQ-NcOmL23BVw=.84e6fa34-5f78-4d78-b7ba-58f7096e0b71@github.com>

On Mon, 12 Feb 2024 10:58:45 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> test/jdk/java/net/URLClassLoader/getresourceasstream/TestDriver.java line 63:
>> 
>>> 61:                 ),
>>> 62:                 ProcessTools.createTestJavaProcessBuilder(
>>> 63:                         "-cp", ".",
>> 
>> If I'm not mistaken, this will result in the `-cp` option being passed twice, with different values, to the `java` sub process. I believe that `ProcessTools.createTestJavaProcessBuilder` will end up passing "-cp <java.class.path>" to the subprocess, unless -Dtest.noclasspath=false is defined in the parent process.
>> Tough I could not find what would happen if -cp is passed twice in `man java` - it appears that the long standing behaviour is that the last one wins - so I guess that's OK, as I doubt this behaviour (last one wins) could be changed...
>> 
>> An alternative could be to create a new method in ProcessTools that would allow to pass a flag to prevent the addition of -cp <java.class.path> when that's not desiravle, and call that here - and in all other places where -cp is passed to `ProcessTools.createTestJavaProcessBuilder`.
>
> Would it be possible to change the `createJavaProcessBuilder` method in ProcessTools to include something to check if -cp is already an argument being passed?
> 
> maybe something like this?
> 
> 
> if (!noCP && !args.contains("-cp")) {
>             args.add("-cp");
>             args.add(System.getProperty("java.class.path"));
>         }

That's not a bad idea. What I would recommend in that case would be to not do anything here - but rather log another issue against `ProcessTools.createTestJavaProcessBuilder`. 
Then proceed with this PR without changing anything...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1486141211


From naoto at openjdk.org  Mon Feb 12 17:37:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Feb 2024 17:37:56 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <NscNVRE66ok6SSHmMGQaeVZSxYEnWS_WzhLMve54xbU=.5ecae045-37aa-45aa-86c3-926bfb04599e@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

> @naotoj Thanks! Would you care to also submit a review?

My bad. I thought I approved this PR.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875811619


From dfuchs at openjdk.org  Mon Feb 12 17:42:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Feb 2024 17:42:06 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <aP9GcIjHZudg8GUlGYhOK4kUlFo5m6aWU4_adCeIIU8=.8634bdeb-198c-4827-b90f-bdee1a94e0f4@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Approving the sun.net changes.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875818676


From joehw at openjdk.org  Mon Feb 12 20:25:59 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:25:59 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <o8ZfKM3dvC-eD-ryNHYogkK94Ha8ArlUiw1qb9Bw51U=.bc0a293b-0dff-43d9-98d0-a798b2ba2dc7@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

java.xml changes look fine to me.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1876181019


From joehw at openjdk.org  Mon Feb 12 20:26:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:26:00 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
Message-ID: <xLIVBeMz0nzp8xjs9ukxIJ1CAe4Aflvz0mtCgDL3RU4=.61371bf6-7719-4bc5-9537-df645d3fa640@github.com>

On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:
> 
>> 22: # Messages for message reporting
>> 23: BadMessageKey = The error message corresponding to the message key can not be found.
>> 24: FormatFailed = An internal error occurred while formatting the following message:\n
> 
> Same here with `:\n`...

It's done with the code (that is, a key is appended with the code). In fact, the whole Xerces stack was implemented this way. I'd leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1486731927


From ascarpino at openjdk.org  Mon Feb 12 22:40:14 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 12 Feb 2024 22:40:14 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert when
 the client does not send any certificates
Message-ID: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>

Hi,

I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.

Tony

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

Commit messages:
 - extra msgs for test
 - Merge branch 'master' into tlscertmsg
 - change old tests to use endWith()
 - merge
 - Change exception to add alert
 - merge
 - changed alert status

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

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


From djelinski at openjdk.org  Tue Feb 13 06:21:24 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Feb 2024 06:21:24 GMT
Subject: RFR: 8325164: Named groups and signature schemes unavailable with
 SunPKCS11 in FIPS mode
Message-ID: <Sx-IG8_I8kz3gBULF9bVtYwzV-izmnva-8nL6ee-n1E=.e7585ee3-c9e5-4fb4-81ff-12511c715d46@github.com>

Currently the SunPKCS11 provider requires other providers in order to offer ECDHE, FFDHE and RSA-PSS in TLS handshakes:
- FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
- ECDHE requires the SunEC provider to be installed
- RSA-PSS requires RSASSA-PSS AlgorithmParameters from SunRsaSign

This PR removes these dependencies: 
- SunPKCS11 is modified to offer the PSS and DH AlgorithmParameters (using the same implementation classes as the original providers)
- Elliptic curve code is modified to remove the dependency on SunEC provider where possible

Two existing tests were modified to verify the changes:
- SigInteropPSS2 test was modified to install SunPKCS11 provider and remove SunRsaSign provider
- FipsModeTLS12 test was modified to verify the list of NamedGroups available on a SSLEngine.

Both modified tests fail without the changes, pass with them. Other tier1-3 tests continue to pass.

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

Commit messages:
 - Update remaining ECUtil usages
 - Update copyright and bugids
 - Reduce SunEC dependencies
 - Add DiffieHellman parameters
 - Add RSASSA-PSS AlgorithmParameters

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

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


From ssahoo at openjdk.org  Tue Feb 13 06:48:53 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Tue, 13 Feb 2024 06:48:53 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <iEBWlZxFXspyAN-jvvfLfIz8tL28xjPFmrqGGBR-grI=.48fdd78e-5396-4e88-bd56-2991850dbdf4@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

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

> 49:                     pass = true;
> 50:                     System.out.println("Found correct exception: " + args[0] +
> 51:                     " in " + e.getMessage());

break; required?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487284287


From djelinski at openjdk.org  Tue Feb 13 07:47:02 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Feb 2024 07:47:02 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <QIE8fbV-1spQWS2P6JWpC8b3BSMNv7FM1kLGeDAqRLo=.d98f2608-6052-46c9-b743-87f6c0e73ee4@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17717#pullrequestreview-1877046190


From ihse at openjdk.org  Tue Feb 13 10:03:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 10:03:08 GMT
Subject: Integrated: 8325558: Add jcheck whitespace checking for properties
 files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <1_5f_JhU7k2LuEKn7w-rn3FkkBpaBDiz3o_uBy-uKiw=.7ed5bef7-6484-435f-8d87-12dadc4d9e9d@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

This pull request has now been integrated.

Changeset: c266800a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c266800a3a7dd44416b0b4df3bdd78410241d74b
Stats:     761 lines in 95 files changed: 0 ins; 5 del; 756 mod

8325558: Add jcheck whitespace checking for properties files

Reviewed-by: naoto, dfuchs, joehw

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

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


From jjiang at openjdk.org  Tue Feb 13 12:12:05 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 13 Feb 2024 12:12:05 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <2MFtoeV97oaw8u-OjNtJZmjCyMnNqQpF54II2rPekys=.414bb15f-9f32-4859-89d9-2afb1a2009d8@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

src/java.base/share/classes/sun/security/ssl/Alert.java line 126:

> 124: 
> 125:         if (cause instanceof IOException) {
> 126:             return new SSLException("("+ description + ") " + reason, cause);

It should need a space between `"("` and `+`.

Could you please define a new local variable for this expression?
This variable can be reused by the below exceptions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487739265


From jjiang at openjdk.org  Tue Feb 13 12:21:53 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 13 Feb 2024 12:21:53 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <4EiXZAx0vSNOnWJDyYvSnEAe5GCbwC7gTrBeCV3tKfY=.07ca6556-fa75-4196-98e3-30b11362e641@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

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

> 65:     TLSBase() {
> 66:         String keyFilename =
> 67:             System.getProperty("test.src", "./") + "/" + pathToStores +

It looks you prefer to 4-spaces indent for these cases.
But line 67 and  71 should have the same indent.
This same to line 68 and 71.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487751390


From jjiang at openjdk.org  Tue Feb 13 12:34:54 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 13 Feb 2024 12:34:54 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <RiWgHXjSDJ0Ui0FPIATW3XEkDBCK0laDVky9H7Bzus8=.a005d6b4-1962-434e-bfaa-7a3f31cf8168@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

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

> 103:         char[] pwd = passwd.toCharArray();
> 104:         KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
> 105:         ks.load(fis, pwd);

Should this input stream be closed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487769746


From jjiang at openjdk.org  Tue Feb 13 12:42:07 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 13 Feb 2024 12:42:07 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <rmdAP8NWW5GMM4MmCVGoxWBuqRbnp1DJpZVVhbi_YdE=.4fc24230-ddd0-415c-8e52-9ad8ac2f8223@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

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

> 259: 
> 260:         // Write to the client
> 261:         void write(Client client, byte[] data)  throws Exception {

May not need two spaces between `)` and `throws`.

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

> 296: 
> 297:         ServerBuilder setTM(boolean b) {
> 298:             km = b;

tm?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487778806
PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487777320


From jjiang at openjdk.org  Tue Feb 13 12:54:54 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 13 Feb 2024 12:54:54 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <VCwXi0OTyZDpDDIQ0r_rJEHwjDTrKa5B32ckQkgn-XQ=.d92e2805-4647-489b-b591-80e0325c4f2c@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

test/jdk/javax/net/ssl/SSLSession/CheckSessionContext.java line 59:

> 57:         byte[] id = ss.getId();
> 58:         System.out.print("id = ");
> 59:         System.out.println(hex.formatHex(id));

Similar to the change at line 63, it may also use a single print statement,

System.out.println("id = " + hex.formatHex(id));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487796879


From jjiang at openjdk.org  Tue Feb 13 13:06:04 2024
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 13 Feb 2024 13:06:04 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <BObl1fjMEpg1-KgmSFaVfHSzkxtg7OIgvMMjn54F3UA=.81c69223-3c16-4875-8ef0-93cea405e843@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

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

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

`2020` should not be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1487812232


From weijun at openjdk.org  Tue Feb 13 14:24:02 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 14:24:02 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <Azz9dtgDfsWHFggSYojEGIncoFtUJN_OC-VMO-Bru8k=.63c1cc98-8a00-4e19-b154-66572788588d@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

Since the one in `sun.security.util` is more complete, why not use it?

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1941625531


From djelinski at openjdk.org  Tue Feb 13 14:33:03 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Feb 2024 14:33:03 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <L3ntHtiCdw8nHRWUdEBPxVsIm01_i3kzThyFlli9zP0=.00e5f0b0-bce8-4023-99af-71f8107e5a13@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

mostly because the com.sun.crypto.provider was older (copyright 2013 vs 2019 on the other one). but I don't have a strong preference. I can keep the other one if you think it makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1941642540


From weijun at openjdk.org  Tue Feb 13 15:07:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 15:07:03 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <tsJOGXTMkn3bO-7eZ39-Frbfr1neEDj2RwrzhqEyi2s=.533c19cf-bb96-47a2-b2b2-935460d5de16@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

I would think the newer one is still maintained and the old one is obsolete.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1941714443


From djelinski at openjdk.org  Tue Feb 13 15:49:03 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Feb 2024 15:49:03 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <BwhUMJ36fDXs1_eroMhCbM2cdceA8RfeymTKuabw-rw=.7284b836-c59d-4b65-a451-9523fc25682d@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

They are both used. The old one is used by [SunJCE](https://github.com/openjdk/jdk/blob/13d9e8ff38536287b82c54bb63bd2d20f65615dc/src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java#L552), and the new one is used by PKCS11.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1941831340


From weijun at openjdk.org  Tue Feb 13 15:57:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 15:57:03 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <VOq0ex7QN7Y35FH-tkG7qdX8GpwMtBYtfnrhzfyoQrw=.fc94b9a3-8f28-4484-9b9a-d826f224c595@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

I should say, the old one is almost forgotten. Anyway, I prefer the one in `sun.security.util` because it's more correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1941855465


From djelinski at openjdk.org  Tue Feb 13 17:14:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Feb 2024 17:14:53 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <xhVis62sfBUoG7XBKQ49_okC0ijsDwV7imvFbuU3NDk=.0eb41988-b085-4d0a-8bda-788b09821a3c@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

alright then, I'll make the changes shortly.

Should I change the copyright and the `@since 13` tag? Given that the files are almost identical, it feels wrong to have 2 different copyrights, and `@since` doesn't make much sense on a non-public SPI class.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1942032930


From weijun at openjdk.org  Tue Feb 13 18:32:04 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 18:32:04 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <1oBDFFVYX2RqPkfqnVvJnpvrrhE87YPROY9MP8uHjNE=.18835b17-f8f6-4252-b92b-3e0007d533f8@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

If you make any edit to a file, then the copyright year should be updated. I don't think you can (or need to) touch the `@since` tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1942154384


From djelinski at openjdk.org  Tue Feb 13 20:58:17 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 13 Feb 2024 20:58:17 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Remove the other GCMParameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17802/files
  - new: https://git.openjdk.org/jdk/pull/17802/files/2b076a96..d210a047

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

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

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


From weijun at openjdk.org  Tue Feb 13 21:32:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 21:32:03 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
 <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
Message-ID: <3EUKXVitEPh_SCYDhOGtzsdbuaUTZf0MuxN-z-JCtRA=.18af5523-8f26-4f65-ad3b-a4f5f94cb639@github.com>

On Tue, 13 Feb 2024 20:58:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
>> 
>> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
>> 
>> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
>> 
>> No new tests. Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the other GCMParameters

Marked as reviewed by weijun (Reviewer).

This looks clean. @valeriepeng, what do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/17802#pullrequestreview-1878960573
PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1942605501


From weijun at openjdk.org  Tue Feb 13 22:30:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 22:30:28 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
Message-ID: <TeTA6dTcFy4xwBQRyMIlS_eUkdjNz0Uwb5ZR7CJdTVU=.ebf727fa-d776-41e0-8e44-1882b10c5af7@github.com>

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

  assertNotEqualsByteArray

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17776/files
  - new: https://git.openjdk.org/jdk/pull/17776/files/a1715f04..96e09a5d

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

  Stats: 69 lines in 2 files changed: 55 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17776/head:pull/17776

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


From jjiang at openjdk.org  Wed Feb 14 02:53:03 2024
From: jjiang at openjdk.org (John Jiang)
Date: Wed, 14 Feb 2024 02:53:03 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
 <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
Message-ID: <adW7DwgiQdtQUvQjRSlx_OGiV2sfFUVgrK7vu4p0rrY=.3fe394b5-2dad-4126-87ec-a34c9bf9b9b5@github.com>

On Tue, 13 Feb 2024 20:58:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
>> 
>> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
>> 
>> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
>> 
>> No new tests. Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the other GCMParameters

Not review this change, but just a thought.

GCMParameters is a SPI implementation.
`com.sun.crypto.provider.GCMParameters` implies that class is a part of `SunJCE` provider, however `sun.security.util.GCMParameters` looks not.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1943006367


From djelinski at openjdk.org  Wed Feb 14 07:14:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 14 Feb 2024 07:14:53 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <adW7DwgiQdtQUvQjRSlx_OGiV2sfFUVgrK7vu4p0rrY=.3fe394b5-2dad-4126-87ec-a34c9bf9b9b5@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
 <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
 <adW7DwgiQdtQUvQjRSlx_OGiV2sfFUVgrK7vu4p0rrY=.3fe394b5-2dad-4126-87ec-a34c9bf9b9b5@github.com>
Message-ID: <kigftZqhU7nkHV5GA7WnabrTn7WFGB7fzIzQODhIVJU=.75ca6b54-fa18-46a9-8e3c-0400eada4a38@github.com>

On Wed, 14 Feb 2024 02:50:21 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `com.sun.crypto.provider.GCMParameters` implies that class is a part of `SunJCE` provider, however `sun.security.util.GCMParameters` looks not.

True. Also, the only other Parameters class in `sun.security.util` is `ECParameters`, which was moved to that package in 3d60beae0d773ba2f626a213e952fbf0e9f1db2b to avoid exporting `sun.security.ec` package to `jdk.crypto.cryptoki` module.

SunPKCS11 is already importing [com.sun.crypto.provider.ChaCha20Poly1305Parameters](https://github.com/openjdk/jdk/blob/ea4193222f36b0663a8bcbf45db86def9e645945/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java#L707), and in #17816 I'm proposing to import another parameters class from `com.sun.crypto.provider`.

I guess it would make sense to decide here if we want to move parameters shared between SunPKCS11 and some other provider to `sun.security.util`, or if we want to keep them in their original location.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1943198182


From aturbanov at openjdk.org  Wed Feb 14 09:08:54 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 14 Feb 2024 09:08:54 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <B6D48mbXh91O9XwLjKCWxL8P6-rBcsVi5TOlBNk9sZM=.84f8ecb2-598f-4be6-88b5-dc534bffeec4@github.com>

On Fri, 9 Feb 2024 11:38:07 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

test/jdk/java/net/ServerSocket/AcceptInheritHandle.java line 105:

> 103: 
> 104:         System.out.println("Executing: "+ commands);
> 105:         ProcessBuilder pb =  ProcessTools.createTestJavaProcessBuilder(commands);

Suggestion:

        ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(commands);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1489135734


From minfrin at sharp.fm  Wed Feb 14 10:16:55 2024
From: minfrin at sharp.fm (Graham Leggett)
Date: Wed, 14 Feb 2024 10:16:55 +0000
Subject: Apple KeychainStore: Can it be used to access the MacOS trust store?
Message-ID: <51FED901-657B-4910-8F53-64FBF654AED3@sharp.fm>

Hi all,

I am trying to make life easier for Apple and Windows users by providing functionality to use Window-MY and Windows-ROOT, however I got stuck with KeychainStore.

keyStore = KeyStore.getInstance("KeychainStore", "Apple");
keyStore.load(null, null);
keyManagerFactory = KeyManagerFactory
.getInstance("PKIX");
keyManagerFactory.init(keyStore, keyPassphrase);
trustStore = KeyStore.getInstance("KeychainStore", "Apple");
trustStore.load(null, null);
trustManagerFactory = TrustManagerFactory
.getInstance("PKIX");
trustManagerFactory.init(trustStore);
ctx = SSLContext.getInstance("TLS");
ctx.init(keyManagerFactory.getKeyManagers(), trustManagerFactory.getTrustManagers(), null);
factory = ctx.getSocketFactory();

The problem is that when connecting to an TLS endpoint with a publicly issued certificate, Java cannot validate the server?s certificate as follows;

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

It looks like the functionality to access the MacOS trust store is missing, which is counterintuitive and makes it seem like I doing something wrong.

Digging into the JDK code it leads us here:

https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m

Specifically, what I don?t see is a call to SecTrustCopyAnchorCertificates:

https://developer.apple.com/documentation/security/1401507-sectrustcopyanchorcertificates?language=objc

Am I right in understanding that java can access certificates in a keychain, but not certificates in the trust store?

Does it make sense to amend ?KeychainStore? to allow access to the trust store, or does macos need a dedicated keystore like Windows-ROOT?

Regards,
Graham
?



From alexey at azul.com  Wed Feb 14 14:43:44 2024
From: alexey at azul.com (Alexey Bakhtin)
Date: Wed, 14 Feb 2024 14:43:44 +0000
Subject: Apple KeychainStore: Can it be used to access the MacOS trust
 store?
In-Reply-To: <51FED901-657B-4910-8F53-64FBF654AED3@sharp.fm>
References: <51FED901-657B-4910-8F53-64FBF654AED3@sharp.fm>
Message-ID: <52173DCA-9A3F-469B-8EC3-A8519DAA753D@azul.com>

Hello Graham,

This functionality is under review now at https://github.com/openjdk/jdk/pull/16722
This patch proposes access to the MacOS trust store using new java KeychainStore-Root keystore.
Feel free to review and comment.

Regards
Aleksei

> On 14 Feb 2024, at 02:16, Graham Leggett <minfrin at sharp.fm> wrote:
> 
> Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Hi all,
> 
> I am trying to make life easier for Apple and Windows users by providing functionality to use Window-MY and Windows-ROOT, however I got stuck with KeychainStore.
> 
> keyStore = KeyStore.getInstance("KeychainStore", "Apple");
> keyStore.load(null, null);
> keyManagerFactory = KeyManagerFactory
> .getInstance("PKIX");
> keyManagerFactory.init(keyStore, keyPassphrase);
> trustStore = KeyStore.getInstance("KeychainStore", "Apple");
> trustStore.load(null, null);
> trustManagerFactory = TrustManagerFactory
> .getInstance("PKIX");
> trustManagerFactory.init(trustStore);
> ctx = SSLContext.getInstance("TLS");
> ctx.init(keyManagerFactory.getKeyManagers(), trustManagerFactory.getTrustManagers(), null);
> factory = ctx.getSocketFactory();
> 
> The problem is that when connecting to an TLS endpoint with a publicly issued certificate, Java cannot validate the server?s certificate as follows;
> 
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> 
> It looks like the functionality to access the MacOS trust store is missing, which is counterintuitive and makes it seem like I doing something wrong.
> 
> Digging into the JDK code it leads us here:
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m
> 
> Specifically, what I don?t see is a call to SecTrustCopyAnchorCertificates:
> 
> https://developer.apple.com/documentation/security/1401507-sectrustcopyanchorcertificates?language=objc
> 
> Am I right in understanding that java can access certificates in a keychain, but not certificates in the trust store?
> 
> Does it make sense to amend ?KeychainStore? to allow access to the trust store, or does macos need a dedicated keystore like Windows-ROOT?
> 
> Regards,
> Graham
> ?
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240214/41f3fe6b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240214/41f3fe6b/signature.asc>

From dfuchs at openjdk.org  Wed Feb 14 15:25:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Feb 2024 15:25:05 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <iBS2mGkjs4I-IbqdCZ23EAj-ZioEzZcpY4z7g2V-EEc=.09bcbbec-3e19-4e50-b3b0-5b7cd01a65f1@github.com>

On Fri, 9 Feb 2024 11:38:07 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

Given the latest suggestions I'm good with this.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17787#pullrequestreview-1880591978


From valeriep at openjdk.org  Wed Feb 14 19:00:53 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 14 Feb 2024 19:00:53 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
 <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
Message-ID: <_0g65AZ6zh3SYtz-D5pFec99TQaab1FVpI6GJCyOQqg=.beffd28a-0956-4d74-a014-a81ff59eb321@github.com>

On Tue, 13 Feb 2024 20:58:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
>> 
>> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
>> 
>> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
>> 
>> No new tests. Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the other GCMParameters

It's nice to consolidate and have only one impl for each algorithm. SunPKCS11 provider relies on other default JDK providers for algorithm parameters implementations. Having the spi impl under a specific provider's package implies the main ownership. Having the spi impl under sun.security.util implies that it's a shared utility class or library. Both has merits. I tend to go with majority since it minimizes the needed changes. As for GCMParameters, sun.security.util version contains newer changes, so we should keep that one (regardless of the package discussion).

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1944418118


From valeriep at openjdk.org  Wed Feb 14 19:45:53 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 14 Feb 2024 19:45:53 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
 <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
Message-ID: <DnV1oY6SoSl_uilbggJwSQK4DucF97zVL9ZJDlg1FV8=.dbf1d216-eaf4-4e5b-a33a-62857e7bec4f@github.com>

On Tue, 13 Feb 2024 20:58:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
>> 
>> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
>> 
>> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
>> 
>> No new tests. Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the other GCMParameters

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17802#pullrequestreview-1881115715


From minfrin at sharp.fm  Thu Feb 15 09:57:45 2024
From: minfrin at sharp.fm (Graham Leggett)
Date: Thu, 15 Feb 2024 09:57:45 +0000
Subject: Apple KeychainStore: Can it be used to access the MacOS trust
 store?
In-Reply-To: <52173DCA-9A3F-469B-8EC3-A8519DAA753D@azul.com>
References: <51FED901-657B-4910-8F53-64FBF654AED3@sharp.fm>
 <52173DCA-9A3F-469B-8EC3-A8519DAA753D@azul.com>
Message-ID: <95D5E31D-70CF-478B-A50D-22FAF9BBA35E@sharp.fm>

On 14 Feb 2024, at 14:43, Alexey Bakhtin <alexey at azul.com> wrote:

> This functionality is under review now at https://github.com/openjdk/jdk/pull/16722
> This patch proposes access to the MacOS trust store using new java KeychainStore-Root keystore.
> Feel free to review and comment.

This is excellent news.

I am teaching the postgresql-jdbc driver to be nice to people on Windows and Mac by not having a twenty seven step setup process to use SSL. Will post the PR here when I have one.

Regards,
Graham
?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240215/50f7c720/attachment.htm>

From djelinski at openjdk.org  Thu Feb 15 11:29:59 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Feb 2024 11:29:59 GMT
Subject: Integrated: 8325162: Remove duplicate GCMParameters class
In-Reply-To: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
Message-ID: <TmOTtEiaLMWcPZED25XPxNRrPHO78oXxOfW7qqIPf3A=.f22374cf-bd53-405f-9730-517d1fca9999@github.com>

On Mon, 12 Feb 2024 08:34:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
> 
> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
> 
> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
> 
> No new tests. Tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: a0e5e16a
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0e5e16afbd19f6396f0af2cba954225a357eca8
Stats:     148 lines in 2 files changed: 0 ins; 146 del; 2 mod

8325162: Remove duplicate GCMParameters class

Reviewed-by: weijun, valeriep

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

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


From djelinski at openjdk.org  Thu Feb 15 11:29:58 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Feb 2024 11:29:58 GMT
Subject: RFR: 8325162: Remove duplicate GCMParameters class [v2]
In-Reply-To: <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
References: <VoPQFZWzhr_y0RtQ3pU04Um1M5SzD7HbsP1e6d1sX04=.a6097577-56c2-47cb-aa35-f30347074f31@github.com>
 <Pa0w5R8lg7x9HInEqpaagFqLg_uE2BKMrg4aboIqIXA=.27f138a2-93bb-4b29-b7aa-d0ccd58e003f@github.com>
Message-ID: <BQ6YHNvcEBo0al25OmJCK9O5yjG9RYp8bT6HQz7AfUA=.a6593647-6e6b-416e-9453-f4021f0ffda9@github.com>

On Tue, 13 Feb 2024 20:58:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently we have 2 GCMParameters classes in java.base, one in sun.security.util package, the other in com.sun.crypto.provider.
>> 
>> This PR merges the changes from the sun.security.util copy into com.sun.crypto.provider, and removes the sun.security.util class.
>> 
>> As far as I could tell, the sun.security.util class was added to avoid exporting com.sun.crypto.provider to jdk.crypto.cryptoki. The export was introduced later in [JDK-8259319](https://bugs.openjdk.org/browse/JDK-8259319), so there's no reason to keep both copies.
>> 
>> No new tests. Tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the other GCMParameters

Thanks for the discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/17802#issuecomment-1945903287


From djelinski at openjdk.org  Thu Feb 15 11:42:14 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 15 Feb 2024 11:42:14 GMT
Subject: RFR: 8325247: Memory leak in SessionKeyRef class def when using PKCS11
 security provider
Message-ID: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>

The reported leak was caused by the death of the `Cleanup-SunPKCS11` thread. The cleanup thread in turn died because of an exception thrown from `removeNativeKey` that resulted from 2 threads executing that method at the same time.

This PR adds a reachabilityFence to ensure that the key will only be enqueued for cleanup after the user thread is done with the `removeNativeKey` call.

No new regression test; the issue is extremely hard to reproduce in a reasonable time. Existing tier1-3 tests continue to pass.

In JBS I attached a PoC patch that changes the relative timing of operations; with that patch and without the changes from this PR I am able to reproduce the issue within a few seconds. With the changes from this PR the issue did not reproduce after 10 minutes of testing.

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

Commit messages:
 - Fix P11Key double-free

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

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


From jpai at openjdk.org  Thu Feb 15 12:08:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Feb 2024 12:08:02 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <bh_iwLJaio-fQCYm65oPp8duEnFrD1noJH6nwsdWs48=.3b8f40a7-9b59-43c6-a8c5-2fc49ada1a90@github.com>

On Fri, 9 Feb 2024 11:38:07 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

These changes look good to me.

The `TLSWontNegotiateDisabledCipherAlgos.java` would need a copyright year update.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17787#pullrequestreview-1882605013


From jpai at openjdk.org  Thu Feb 15 12:08:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Feb 2024 12:08:03 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <NpEUnlpc3rRQU_szdCYeCkFkyUERH8JQ-NcOmL23BVw=.84e6fa34-5f78-4d78-b7ba-58f7096e0b71@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
 <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>
 <pOPFMkW514Tx4a-etkrjBLEPclnVLPjYwhQhp16nSkE=.41a66da3-6134-4d56-ab6c-1a929fec88a9@github.com>
 <NpEUnlpc3rRQU_szdCYeCkFkyUERH8JQ-NcOmL23BVw=.84e6fa34-5f78-4d78-b7ba-58f7096e0b71@github.com>
Message-ID: <577ph6JRRKKrYLmKs6F0Wc9UzjCm1IK10UnfmLBsoTs=.baee6317-146c-4aa5-8327-0cf53f2cb200@github.com>

On Mon, 12 Feb 2024 12:51:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Would it be possible to change the `createJavaProcessBuilder` method in ProcessTools to include something to check if -cp is already an argument being passed?
>> 
>> maybe something like this?
>> 
>> 
>> if (!noCP && !args.contains("-cp")) {
>>             args.add("-cp");
>>             args.add(System.getProperty("java.class.path"));
>>         }
>
> That's not a bad idea. What I would recommend in that case would be to not do anything here - but rather log another issue against `ProcessTools.createTestJavaProcessBuilder`. 
> Then proceed with this PR without changing anything...

Hello Darragh, Daniel,

As for introducing a new method on `ProcessTools` class, I don't know if it's needed - I feel that the `ProcessTools` class is already getting too complex because of the various similarly named methods. I think it might be better to reuse some of those existing `/test/lib` utility methods to achieve the same, something like:


final List<String> command = new ArrayList<>();
command.add(JDKToolFinder.getJDKTool("java"));
command.addAll(jdk.test.lib.Utils.prependTestJavaOpts("-cp", classpath, className, appArgs));
final ProcessBuilder pb = new ProcessBuilder(command);
final OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(pb);


I haven't tried out this snippet to be sure this works as expected.

I am not suggesting we do this change in this current PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1490909855


From ihse at openjdk.org  Thu Feb 15 12:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:23 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
Message-ID: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>

Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).

I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

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

Commit messages:
 - 8325950: Make sure all files in the JDK pass jcheck

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

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


From ihse at openjdk.org  Thu Feb 15 12:29:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:24 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Some general remarks: The problems in .m4 files where not properly detected and fixed when I added .m4 to the list of checked files. The properties files were recently checked by me, so these suprrised me. It turned out I had misunderstood the jcheck criteria: I thought only leading tabs were disallowed, but it is actually tabs anywhere in the file that are banned.

In general, I have replaced tab characters with spaces aligning to tab stops at 8 characters distance. 

I'll leave some remarks for individual files.

src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties line 10:

> 8: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject
> 9: 
> 10: # RemoteToAttrs: Turn RMI/JRMP and RMI/IIOP object into javaMarshalledObject or

I adjusted this tab stop (with one space) so it aligned properly with the line above; I think that was the intention.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties line 41:

> 39: jdk.internal.ref.Cleaner=Use java.lang.ref.PhantomReference @since 1.2 or java.lang.ref.Cleaner @since 9
> 40: sun.awt.CausedFocusEvent=Use java.awt.event.FocusEvent::getCause @since 9
> 41: sun.font.FontUtilities=See java.awt.Font.textRequiresLayout	@since 9

This tab just looked out of place, so I replaced it with a space. (Rhyming not intentional...)

test/hotspot/jtreg/containers/docker/JfrReporter.java line 52:

> 50:             }
> 51:         }
> 52:     }

I'm not sure how a Java file ever got into the code base with trailing spaces, but a guess is that there have been a bug in jcheck that did not properly check for trailing whitespace at the end of the file, or something like that.

test/jdk/java/util/Currency/currency.properties line 18:

> 16: SB=EUR,111,2, 2099-01-01T00:00:00
> 17: US=euR,978,2,2001-01-01T00:00:00
> 18: ZZ	=	ZZZ	,	999	,	3

This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

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

PR Comment: https://git.openjdk.org/jdk/pull/17871#issuecomment-1945992837
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931378
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931979
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490933432
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490934063


From dfuchs at openjdk.org  Thu Feb 15 12:47:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 Feb 2024 12:47:03 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <577ph6JRRKKrYLmKs6F0Wc9UzjCm1IK10UnfmLBsoTs=.baee6317-146c-4aa5-8327-0cf53f2cb200@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
 <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>
 <pOPFMkW514Tx4a-etkrjBLEPclnVLPjYwhQhp16nSkE=.41a66da3-6134-4d56-ab6c-1a929fec88a9@github.com>
 <NpEUnlpc3rRQU_szdCYeCkFkyUERH8JQ-NcOmL23BVw=.84e6fa34-5f78-4d78-b7ba-58f7096e0b71@github.com>
 <577ph6JRRKKrYLmKs6F0Wc9UzjCm1IK10UnfmLBsoTs=.baee6317-146c-4aa5-8327-0cf53f2cb200@github.com>
Message-ID: <VlgV1DP3hi7tAPaV9I8wiOV3At31SHu7i2T45wVQg6U=.0dc9f878-2b52-4e73-90eb-eeeba0875fc6@github.com>

On Thu, 15 Feb 2024 12:04:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> That's not a bad idea. What I would recommend in that case would be to not do anything here - but rather log another issue against `ProcessTools.createTestJavaProcessBuilder`. 
>> Then proceed with this PR without changing anything...
>
> Hello Darragh, Daniel,
> 
> As for introducing a new method on `ProcessTools` class, I don't know if it's needed - I feel that the `ProcessTools` class is already getting too complex because of the various similarly named methods. I think it might be better to reuse some of those existing `/test/lib` utility methods to achieve the same, something like:
> 
> 
> final List<String> command = new ArrayList<>();
> command.add(JDKToolFinder.getJDKTool("java"));
> command.addAll(jdk.test.lib.Utils.prependTestJavaOpts("-cp", classpath, className, appArgs));
> final ProcessBuilder pb = new ProcessBuilder(command);
> final OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(pb);
> 
> 
> I haven't tried out this snippet to be sure this works as expected.
> 
> I am not suggesting we do this change in this current PR.

Hi Jaikiran,

What Darragh suggested was to modify the current method in ProcessTools to *not* add -cp <java.class.path> if the argument it is given already contains -cp. Since the first -cp added by the ProcessTools should be ignored anyway by the compiler (last one wins) - then I think it's a good idea, but to follow up outside of the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1490954776


From jpai at openjdk.org  Thu Feb 15 13:17:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Feb 2024 13:17:04 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <VlgV1DP3hi7tAPaV9I8wiOV3At31SHu7i2T45wVQg6U=.0dc9f878-2b52-4e73-90eb-eeeba0875fc6@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
 <v1CtcjP9KKtE93JdvDXCcRwuYSOdplmKswBHBAugNa0=.134de34c-e6fe-46f7-8150-fde16800d7ea@github.com>
 <pOPFMkW514Tx4a-etkrjBLEPclnVLPjYwhQhp16nSkE=.41a66da3-6134-4d56-ab6c-1a929fec88a9@github.com>
 <NpEUnlpc3rRQU_szdCYeCkFkyUERH8JQ-NcOmL23BVw=.84e6fa34-5f78-4d78-b7ba-58f7096e0b71@github.com>
 <577ph6JRRKKrYLmKs6F0Wc9UzjCm1IK10UnfmLBsoTs=.baee6317-146c-4aa5-8327-0cf53f2cb200@github.com>
 <VlgV1DP3hi7tAPaV9I8wiOV3At31SHu7i2T45wVQg6U=.0dc9f878-2b52-4e73-90eb-eeeba0875fc6@github.com>
Message-ID: <4sVImNwflNrA8n07DsFBhiR3OvNYU6HsYKkhn2P6j6s=.f4afb03d-9904-43b4-8668-d14ea692472f@github.com>

On Thu, 15 Feb 2024 12:44:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello Darragh, Daniel,
>> 
>> As for introducing a new method on `ProcessTools` class, I don't know if it's needed - I feel that the `ProcessTools` class is already getting too complex because of the various similarly named methods. I think it might be better to reuse some of those existing `/test/lib` utility methods to achieve the same, something like:
>> 
>> 
>> final List<String> command = new ArrayList<>();
>> command.add(JDKToolFinder.getJDKTool("java"));
>> command.addAll(jdk.test.lib.Utils.prependTestJavaOpts("-cp", classpath, className, appArgs));
>> final ProcessBuilder pb = new ProcessBuilder(command);
>> final OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(pb);
>> 
>> 
>> I haven't tried out this snippet to be sure this works as expected.
>> 
>> I am not suggesting we do this change in this current PR.
>
> Hi Jaikiran,
> 
> What Darragh suggested was to modify the current method in ProcessTools to *not* add -cp <java.class.path> if the argument it is given already contains -cp. Since the first -cp added by the ProcessTools should be ignored anyway by the compiler (last one wins) - then I think it's a good idea, but to follow up outside of the PR.

Sorry Daniel and Darragh, I misunderstood the discussion and thought it was a proposal to add a new method in that class. What you suggest about changing the implementation of that existing method, in a separate PR, sounds fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17787#discussion_r1490991807


From erikj at openjdk.org  Thu Feb 15 14:05:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 Feb 2024 14:05:12 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
Message-ID: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>

On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> test/jdk/java/util/Currency/currency.properties line 18:
> 
>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>> 17: US=euR,978,2,2001-01-01T00:00:00
>> 18: ZZ	=	ZZZ	,	999	,	3
> 
> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491056108


From ihse at openjdk.org  Thu Feb 15 15:50:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:50:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
Message-ID: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>

On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/jdk/java/util/Currency/currency.properties line 18:
>> 
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ	=	ZZZ	,	999	,	3
>> 
>> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.
>
> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491227492


From mdonovan at openjdk.org  Thu Feb 15 17:10:03 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 15 Feb 2024 17:10:03 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags
Message-ID: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>

In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.

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

Commit messages:
 - 8319673: Few security tests ignore VM flags

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

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


From naoto at openjdk.org  Thu Feb 15 17:12:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:12:55 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
Message-ID: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>

On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?
>
> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491352359


From angorya at openjdk.org  Thu Feb 15 17:31:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Feb 2024 17:31:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
Message-ID: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>

On Thu, 15 Feb 2024 17:09:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.
>
> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

`\u000b` is VT   (vertical tab)  
`\u0009` or `\t` perhaps?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491375928


From naoto at openjdk.org  Thu Feb 15 17:55:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:55:58 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
Message-ID: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>

On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)
>
> `\u000b` is VT   (vertical tab)  
> `\u0009` or `\t` perhaps?

Right. `\t` is better to avoid such a mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491403426


From rhalade at openjdk.org  Thu Feb 15 18:24:17 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 15 Feb 2024 18:24:17 GMT
Subject: RFR: 8321408: Add Certainly roots R1 and E1
Message-ID: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>

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


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

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

Commit messages:
 - 8321408: Add Certainly roots R1 and E1

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

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


From mdonovan at openjdk.org  Thu Feb 15 18:28:08 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 15 Feb 2024 18:28:08 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v2]
In-Reply-To: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
Message-ID: <JU8TyXVu1fwbR4Wp7hZohwy1NpZWu33AR2tHqSGDZuU=.c24901ae-3f01-4294-84e3-cb44cf4cf1ec@github.com>

> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.

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

  Including SignedJarWithCustomClassLoader.java which was missed in the first commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17877/files
  - new: https://git.openjdk.org/jdk/pull/17877/files/96046d79..9620377e

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

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

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


From ascarpino at openjdk.org  Thu Feb 15 18:37:53 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 15 Feb 2024 18:37:53 GMT
Subject: RFR: 8321408: Add Certainly roots R1 and E1
In-Reply-To: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>
References: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>
Message-ID: <PATKk03Z9wu69g-0AbH60TwUrHqfNew4b1J4CnMriuI=.f69b0e02-6173-41c2-bb30-23c1ce54e235@github.com>

On Thu, 15 Feb 2024 18:19:25 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

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

looks good

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17880#pullrequestreview-1883546535


From hchao at openjdk.org  Thu Feb 15 19:06:53 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Feb 2024 19:06:53 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v2]
In-Reply-To: <JU8TyXVu1fwbR4Wp7hZohwy1NpZWu33AR2tHqSGDZuU=.c24901ae-3f01-4294-84e3-cb44cf4cf1ec@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <JU8TyXVu1fwbR4Wp7hZohwy1NpZWu33AR2tHqSGDZuU=.c24901ae-3f01-4294-84e3-cb44cf4cf1ec@github.com>
Message-ID: <SEqqZzNR_Ni9nfdSzLWcYZDbBy60Wmeuwp9sQvu9BWM=.eaa9b65c-19bb-46cf-a461-65de62951b87@github.com>

On Thu, 15 Feb 2024 18:28:08 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Including SignedJarWithCustomClassLoader.java which was missed in the first commit

Test sun/security/tools/jarsigner/compatibility/SignTwice.java is listed as test needs to be updated in the bug, but not in the webrev?

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

PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1946991195


From hchao at openjdk.org  Thu Feb 15 19:13:55 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 15 Feb 2024 19:13:55 GMT
Subject: RFR: 8321408: Add Certainly roots R1 and E1
In-Reply-To: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>
References: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>
Message-ID: <KEwhOtRMWC1HSPM_svTRn8Fj2yVUUkLuNxFFHOJKXJg=.fb8a11b4-1634-4bc0-bed1-4ce57a018c63@github.com>

On Thu, 15 Feb 2024 18:19:25 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

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

Marked as reviewed by hchao (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17880#pullrequestreview-1883620135


From clanger at openjdk.org  Thu Feb 15 22:37:05 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 15 Feb 2024 22:37:05 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE
Message-ID: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>

The experimental SunJSSE FIPS compliant mode was removed in JDK13 with [JDK-8217835](https://bugs.openjdk.org/browse/JDK-8217835).
It seems the removal of some comments had been missed at that time. This could be irritating to readers of the code.

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

Commit messages:
 - JDK-8326000

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

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


From prr at openjdk.org  Thu Feb 15 22:40:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Feb 2024 22:40:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <lmqQHpQrlQkG9kFB3GhPa0530wpWgAWXrVjKeKLrezM=.8050c3cd-2143-439e-ad8d-c3b27e82e59a@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

desktop changes look fine to me.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884009342


From wetmore at openjdk.org  Fri Feb 16 01:44:57 2024
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 Feb 2024 01:44:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <AG07BfABTTmZaZhAd9jHgMMgcaGRtP_31MVSJg8LUYo=.e9355b50-d5d1-4551-a161-15712bf6b1e8@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

security properties looks ok.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884183930


From ascarpino at openjdk.org  Fri Feb 16 04:26:52 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 16 Feb 2024 04:26:52 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE
In-Reply-To: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
Message-ID: <LufA0RYPm93XD4B8A69yXof_qxQnN9Gnk_cUN1OJrYM=.57109adb-2268-41a8-a181-4990448a4d8d@github.com>

On Thu, 15 Feb 2024 22:32:58 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The experimental SunJSSE FIPS compliant mode was removed in JDK13 with [JDK-8217835](https://bugs.openjdk.org/browse/JDK-8217835).
> It seems the removal of some comments had been missed at that time. This could be irritating to readers of the code.

You will need to update the copyright on the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/17885#issuecomment-1947736214


From clanger at openjdk.org  Fri Feb 16 08:52:19 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 16 Feb 2024 08:52:19 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE [v2]
In-Reply-To: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
Message-ID: <JuMw8TN4OhioFOSv05XtBpUCcNTiO54_zPW8o_rjSxk=.7a6d7937-52f0-4b1a-8a76-dd3a0c5d37fe@github.com>

> The experimental SunJSSE FIPS compliant mode was removed in JDK13 with [JDK-8217835](https://bugs.openjdk.org/browse/JDK-8217835).
> It seems the removal of some comments had been missed at that time. This could be irritating to readers of the code.

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

 - Update copyright
 - Merge branch 'master' into JDK-8326000
 - JDK-8326000

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17885/files
  - new: https://git.openjdk.org/jdk/pull/17885/files/ae7b7388..7ba4c017

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

  Stats: 787 lines in 21 files changed: 611 ins; 94 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/17885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17885/head:pull/17885

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


From clanger at openjdk.org  Fri Feb 16 08:52:19 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 16 Feb 2024 08:52:19 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE
In-Reply-To: <LufA0RYPm93XD4B8A69yXof_qxQnN9Gnk_cUN1OJrYM=.57109adb-2268-41a8-a181-4990448a4d8d@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
 <LufA0RYPm93XD4B8A69yXof_qxQnN9Gnk_cUN1OJrYM=.57109adb-2268-41a8-a181-4990448a4d8d@github.com>
Message-ID: <ObgBRKXKlQec9jVckyRKGUMX5SKs-VIfimt5bAUhv9Q=.440a1143-b7cd-4dd0-9a63-fd30152913e9@github.com>

On Fri, 16 Feb 2024 04:24:06 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> You will need to update the copyright on the file.

Right. Updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/17885#issuecomment-1947979882


From jpai at openjdk.org  Fri Feb 16 11:31:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Feb 2024 11:31:17 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process [v2]
In-Reply-To: <R28u7P5viIRLNpI6NTxz37xtXADS-pa5Ldd7RK_EBWc=.c755d028-d9c7-4cab-9dbb-e74cb36c6ebd@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
 <R28u7P5viIRLNpI6NTxz37xtXADS-pa5Ldd7RK_EBWc=.c755d028-d9c7-4cab-9dbb-e74cb36c6ebd@github.com>
Message-ID: <E6Wfb0k2tPVuXtfCQ4ieXbZv2tCwPMBehZnngBZYBTU=.f18b9945-7308-4e55-ae3a-ae6bca97dd99@github.com>

On Fri, 16 Feb 2024 11:27:52 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
>> 
>> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
>> 
>> I've ran these changes against tiers 1-3 and everything seems stable
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/jdk/java/net/ServerSocket/AcceptInheritHandle.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - fixed copyright year

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17787#pullrequestreview-1884898745


From dclarke at openjdk.org  Fri Feb 16 11:31:17 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Fri, 16 Feb 2024 11:31:17 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <lXRmE_EJqvpICvAUUattLL7t3ge6fc1kEcGEEnaIN0Q=.54b56524-7694-4203-b7a4-67e365507dcd@github.com>

On Fri, 9 Feb 2024 11:38:07 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

Thanks for the suggestions and feedback, I think I've addressed everything now so will leave some time in case there is anything else and to rerun tests but will merge later.

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

PR Comment: https://git.openjdk.org/jdk/pull/17787#issuecomment-1948219622


From dclarke at openjdk.org  Fri Feb 16 11:31:17 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Fri, 16 Feb 2024 11:31:17 GMT
Subject: RFR: 8319651: Several network tests ignore vm flags when start
 java process [v2]
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <R28u7P5viIRLNpI6NTxz37xtXADS-pa5Ldd7RK_EBWc=.c755d028-d9c7-4cab-9dbb-e74cb36c6ebd@github.com>

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/net/ServerSocket/AcceptInheritHandle.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - fixed copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17787/files
  - new: https://git.openjdk.org/jdk/pull/17787/files/a9fcc6c2..75619936

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

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

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


From mbaesken at openjdk.org  Fri Feb 16 12:04:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Feb 2024 12:04:53 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE [v2]
In-Reply-To: <JuMw8TN4OhioFOSv05XtBpUCcNTiO54_zPW8o_rjSxk=.7a6d7937-52f0-4b1a-8a76-dd3a0c5d37fe@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
 <JuMw8TN4OhioFOSv05XtBpUCcNTiO54_zPW8o_rjSxk=.7a6d7937-52f0-4b1a-8a76-dd3a0c5d37fe@github.com>
Message-ID: <ro1P7D34FY-PHaRRVLrr2mwwXn6Ix5NSeIVYKpt3Qok=.7b45b770-3892-4a2a-9cd9-7dae495966e0@github.com>

On Fri, 16 Feb 2024 08:52:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The experimental SunJSSE FIPS compliant mode was removed in JDK13 with [JDK-8217835](https://bugs.openjdk.org/browse/JDK-8217835).
>> It seems the removal of some comments had been missed at that time. This could be irritating to readers of the code.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update copyright
>  - Merge branch 'master' into JDK-8326000
>  - JDK-8326000

Makes sense to remove the comment, it is more historical these days.
Or is there still a way to use SunJSSE FIPS compliant mode ?

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17885#pullrequestreview-1884953328


From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace spaces with \t in test properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17871/files
  - new: https://git.openjdk.org/jdk/pull/17871/files/3faa912e..e1c9c0f0

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

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

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


From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
 <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
Message-ID: <gQYN5tDVDEdGZVHhgOHMz2IvGZn4iam8xh4Xx3jKPFk=.55c92a6d-68dd-4838-a2f8-840b4a66e4c2@github.com>

On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `\u000b` is VT   (vertical tab)  
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.

Ok, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403


From minfrin at sharp.fm  Fri Feb 16 13:07:57 2024
From: minfrin at sharp.fm (Graham Leggett)
Date: Fri, 16 Feb 2024 13:07:57 +0000
Subject: Apple KeychainStore: Can it be used to access the MacOS trust
 store?
In-Reply-To: <52173DCA-9A3F-469B-8EC3-A8519DAA753D@azul.com>
References: <51FED901-657B-4910-8F53-64FBF654AED3@sharp.fm>
 <52173DCA-9A3F-469B-8EC3-A8519DAA753D@azul.com>
Message-ID: <061F9ED5-9167-49C4-82B2-B5E450DCE65B@sharp.fm>

On 14 Feb 2024, at 14:43, Alexey Bakhtin <alexey at azul.com> wrote:

> This functionality is under review now at https://github.com/openjdk/jdk/pull/16722
> This patch proposes access to the MacOS trust store using new java KeychainStore-Root keystore.
> Feel free to review and comment.

PR for postgresql-jdbc that uses the above is here:

https://github.com/pgjdbc/pgjdbc/pull/3124

Regards,
Graham
?

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

From mdonovan at openjdk.org  Fri Feb 16 13:13:05 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 16 Feb 2024 13:13:05 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v2]
In-Reply-To: <SEqqZzNR_Ni9nfdSzLWcYZDbBy60Wmeuwp9sQvu9BWM=.eaa9b65c-19bb-46cf-a461-65de62951b87@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <JU8TyXVu1fwbR4Wp7hZohwy1NpZWu33AR2tHqSGDZuU=.c24901ae-3f01-4294-84e3-cb44cf4cf1ec@github.com>
 <SEqqZzNR_Ni9nfdSzLWcYZDbBy60Wmeuwp9sQvu9BWM=.eaa9b65c-19bb-46cf-a461-65de62951b87@github.com>
Message-ID: <MuVM0YuNWQjl1ybbS4dHQaWsC5UACPy1sFvwDfF2s8w=.eadbeadf-1cb2-4fce-aae0-b31a5e8ce763@github.com>

On Thu, 15 Feb 2024 19:03:57 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Test sun/security/tools/jarsigner/compatibility/SignTwice.java is listed as test needs to be updated in the bug, but not in the webrev?

SignTwice.java just invokes `Compatibility.main()`. I updated Compatibility.java to pass VM options to subprocesses.

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

PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1948362261


From mdonovan at openjdk.org  Fri Feb 16 13:13:05 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 16 Feb 2024 13:13:05 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v3]
In-Reply-To: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
Message-ID: <T_nWi2HIJIYbF04uLgF4ZCqgpftt6-vIX8uZ7NRWfRc=.82ec6610-68a0-469f-b360-72c67b883985@github.com>

> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.

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

  Updated Compatibility.java to use newer Proctools methods to pass VM options to subprocesses.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17877/files
  - new: https://git.openjdk.org/jdk/pull/17877/files/9620377e..83955d01

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

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

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


From erikj at openjdk.org  Fri Feb 16 13:39:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Feb 2024 13:39:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <EG72V-Kg8FWuzTzqCGrfpb3fX_WIq4oybS3sljVlPGY=.400d3c9f-a361-4515-8c6f-6a465b89adc0@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885177994


From weijun at openjdk.org  Fri Feb 16 13:55:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Feb 2024 13:55:54 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v3]
In-Reply-To: <T_nWi2HIJIYbF04uLgF4ZCqgpftt6-vIX8uZ7NRWfRc=.82ec6610-68a0-469f-b360-72c67b883985@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <T_nWi2HIJIYbF04uLgF4ZCqgpftt6-vIX8uZ7NRWfRc=.82ec6610-68a0-469f-b360-72c67b883985@github.com>
Message-ID: <AdWNbvt5B1k8RBMvfXdDHbboKwml5s8F2gCcxGBMvfs=.62ca5324-872f-425c-adc2-e358001003f1@github.com>

On Fri, 16 Feb 2024 13:13:05 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated Compatibility.java to use newer Proctools methods to pass VM options to subprocesses.

The tests that used to call `createLimitedTestJavaProcessBuilder` intentionally avoid copying all the VM options so they can provide their own. Are you sure they should be modified?

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

PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1948426083


From duke at openjdk.org  Fri Feb 16 14:54:00 2024
From: duke at openjdk.org (Ben Perez)
Date: Fri, 16 Feb 2024 14:54:00 GMT
Subject: Integrated: 8265372: Simplify PKCS9Attribute
In-Reply-To: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
References: <Vcaij6qSAbiWbToJneWs6rWqU7wsDew0-VdPFKidehY=.10ddcae6-072c-4b0a-95e9-077d82ca0087@github.com>
Message-ID: <wHsiLR52IX9czbqfGsTr6bw-xmsmy_bm6ZqGycNV1iU=.7943c5ae-91b8-4698-8ae8-f480bf080417@github.com>

On Fri, 15 Dec 2023 20:34:21 GMT, Ben Perez <duke at openjdk.org> wrote:

> Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. 
> 
> It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues.
> 
> Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs.

This pull request has now been integrated.

Changeset: 244573e7
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/244573e719ddb387cb1739d3cab26b72df1e1f0a
Stats:     758 lines in 4 files changed: 226 ins; 418 del; 114 mod

8265372: Simplify PKCS9Attribute

Reviewed-by: weijun

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

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


From weijun at openjdk.org  Fri Feb 16 15:03:55 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Feb 2024 15:03:55 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <pWiI8p1UCqL6qR2T972Z0HbvAMXxfVwmaxx_OlPlSck=.10058ab2-ee28-4215-880a-dcd3faa42a21@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>
 <iZwXZl-JKTLXb2A4JC1pRHur9ukAcJoyUq3PvK3L_yA=.21848030-bfcc-46f7-b3bd-7cc9aa14381b@github.com>
 <pWiI8p1UCqL6qR2T972Z0HbvAMXxfVwmaxx_OlPlSck=.10058ab2-ee28-4215-880a-dcd3faa42a21@github.com>
Message-ID: <yPGDPz9LovJi6Zq2AujBe9wWBN98ccCtmfK6pibQKxA=.9b689fde-49aa-462c-8ab8-ab3c8ba13772@github.com>

On Fri, 2 Feb 2024 20:28:58 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> `security dump-trust-settings -s` returns only predefined root certificates. KEYCHAINSTORE-ROOT additionally contains installed root trusted certificates in the system domain

Are you sure they should be added into this keystore? It looks like all the extra certs in KEYCHAINSTORE-ROOT that are not in `security dump-trust-settings -s` are all inside KEYCHAINSTORE. Maybe that's where they should belong to?

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1948542783


From mdonovan at openjdk.org  Fri Feb 16 15:11:06 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 16 Feb 2024 15:11:06 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v4]
In-Reply-To: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
Message-ID: <XjwqZzl85voHuKMmrteSilTMZ7m3H3z4ulZwqAj6CoY=.adfc4414-7140-4655-85a0-08269c88c86b@github.com>

> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.

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

  reverted ModuleName and SignedJarWithCustomClassLoader to use createLimitedTestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17877/files
  - new: https://git.openjdk.org/jdk/pull/17877/files/83955d01..e744876c

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

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

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


From mdonovan at openjdk.org  Fri Feb 16 15:11:06 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 16 Feb 2024 15:11:06 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v3]
In-Reply-To: <AdWNbvt5B1k8RBMvfXdDHbboKwml5s8F2gCcxGBMvfs=.62ca5324-872f-425c-adc2-e358001003f1@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <T_nWi2HIJIYbF04uLgF4ZCqgpftt6-vIX8uZ7NRWfRc=.82ec6610-68a0-469f-b360-72c67b883985@github.com>
 <AdWNbvt5B1k8RBMvfXdDHbboKwml5s8F2gCcxGBMvfs=.62ca5324-872f-425c-adc2-e358001003f1@github.com>
Message-ID: <kf2USUQva0IQsdo8IMLpu0ObmbTyOmHZIQlU-kZMyQ8=.b0d16c14-aaca-4951-9665-1ee1edfd7ba9@github.com>

On Fri, 16 Feb 2024 13:53:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The tests that used to call `createLimitedTestJavaProcessBuilder` intentionally avoid copying all the VM options so they can provide their own. Are you sure they should be modified?

I reverted two tests that used `createLimitedTestJavaProcessBuilder`, the third, DKSTest.java, is ok using the other method.

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

PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1948556771


From naoto at openjdk.org  Fri Feb 16 16:55:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Feb 2024 16:55:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <fV_QpLFoKMrAxR1VvhztN6ha6WJBO8iNcPzNbP-fgAo=.25e82e1c-ed8d-4b7f-9f76-a9ed2a08e62d@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885586969


From rhalade at openjdk.org  Fri Feb 16 18:10:59 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 16 Feb 2024 18:10:59 GMT
Subject: Integrated: 8321408: Add Certainly roots R1 and E1
In-Reply-To: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>
References: <YSATQazGhqqPpOmUAWPObE5WGlk6jlL3aq95ba-2amo=.341e9f59-7c1d-4071-96b8-e0f4c52ed8aa@github.com>
Message-ID: <HLzdUhFU6j-hnJBn3Rn4UUNQtrDtAAfk4k_pChiEJ3I=.7feccf62-5a69-4ca9-b9e4-1291877003e4@github.com>

On Thu, 15 Feb 2024 18:19:25 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: f3073db4
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3073db42aa80b3ced47edea8d2e8add874fb70f
Stats:     92 lines in 4 files changed: 88 ins; 0 del; 4 mod

8321408: Add Certainly roots R1 and E1

Reviewed-by: ascarpino, hchao

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

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


From ascarpino at openjdk.org  Fri Feb 16 23:30:55 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 16 Feb 2024 23:30:55 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE [v2]
In-Reply-To: <JuMw8TN4OhioFOSv05XtBpUCcNTiO54_zPW8o_rjSxk=.7a6d7937-52f0-4b1a-8a76-dd3a0c5d37fe@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
 <JuMw8TN4OhioFOSv05XtBpUCcNTiO54_zPW8o_rjSxk=.7a6d7937-52f0-4b1a-8a76-dd3a0c5d37fe@github.com>
Message-ID: <Y35oijJGpOyVnfDCPxo0qz-L-wRVUUmt8y3IdVNQbGI=.feee05ee-9d1e-48e0-8b1a-56df687bf5e3@github.com>

On Fri, 16 Feb 2024 08:52:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The experimental SunJSSE FIPS compliant mode was removed in JDK13 with [JDK-8217835](https://bugs.openjdk.org/browse/JDK-8217835).
>> It seems the removal of some comments had been missed at that time. This could be irritating to readers of the code.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update copyright
>  - Merge branch 'master' into JDK-8326000
>  - JDK-8326000

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17885#pullrequestreview-1886223378


From ascarpino at openjdk.org  Fri Feb 16 23:30:55 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 16 Feb 2024 23:30:55 GMT
Subject: RFR: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE [v2]
In-Reply-To: <ro1P7D34FY-PHaRRVLrr2mwwXn6Ix5NSeIVYKpt3Qok=.7b45b770-3892-4a2a-9cd9-7dae495966e0@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
 <JuMw8TN4OhioFOSv05XtBpUCcNTiO54_zPW8o_rjSxk=.7a6d7937-52f0-4b1a-8a76-dd3a0c5d37fe@github.com>
 <ro1P7D34FY-PHaRRVLrr2mwwXn6Ix5NSeIVYKpt3Qok=.7b45b770-3892-4a2a-9cd9-7dae495966e0@github.com>
Message-ID: <-RMjHdKvIoK7he6Et1P6ACQisQzA1V_QAKb8jyKGUMU=.0b6f7093-c7fb-45c7-8681-d39d25909d6e@github.com>

On Fri, 16 Feb 2024 12:01:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Makes sense to remove the comment, it is more historical these days. Or is there still a way to use SunJSSE FIPS compliant mode ?

There is no FIPS compliant mode.  This was a experimental feature that was never supported.

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

PR Comment: https://git.openjdk.org/jdk/pull/17885#issuecomment-1949479369


From valeriep at openjdk.org  Sat Feb 17 00:47:57 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 17 Feb 2024 00:47:57 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: <TeTA6dTcFy4xwBQRyMIlS_eUkdjNz0Uwb5ZR7CJdTVU=.ebf727fa-d776-41e0-8e44-1882b10c5af7@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
 <TeTA6dTcFy4xwBQRyMIlS_eUkdjNz0Uwb5ZR7CJdTVU=.ebf727fa-d776-41e0-8e44-1882b10c5af7@github.com>
Message-ID: <oz63AxHlAb3BdjhUWncKhRZaRRP1vNJz5fEc_0eboIc=.44fd1750-3310-464e-bd33-b8af93458bb7@github.com>

On Tue, 13 Feb 2024 22:30:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertNotEqualsByteArray

test/lib/jdk/test/lib/Asserts.java line 290:

> 288:     public static void assertNotEqualsByteArray(byte[] lhs, byte[] rhs, String msg) {
> 289:         if (Arrays.equals(lhs, rhs)) {
> 290:             msg = Objects.toString(msg, "assertEqualsByteArray")

method name in the message not matching the method?

test/lib/jdk/test/lib/Asserts.java line 292:

> 290:             msg = Objects.toString(msg, "assertEqualsByteArray")
> 291:                     + ": expected " + HexFormat.of().formatHex(lhs)
> 292:                     + " to equal " + HexFormat.of().formatHex(rhs);

"to NOT equal"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493106466
PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493106604


From valeriep at openjdk.org  Sat Feb 17 01:05:56 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 17 Feb 2024 01:05:56 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: <TeTA6dTcFy4xwBQRyMIlS_eUkdjNz0Uwb5ZR7CJdTVU=.ebf727fa-d776-41e0-8e44-1882b10c5af7@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
 <TeTA6dTcFy4xwBQRyMIlS_eUkdjNz0Uwb5ZR7CJdTVU=.ebf727fa-d776-41e0-8e44-1882b10c5af7@github.com>
Message-ID: <zCaJuMmRbsP9Iu6u5s6Hft2hDxUFdsKprrHFgnWk7RY=.d5eab682-476a-48e6-a157-fb61622257c4@github.com>

On Tue, 13 Feb 2024 22:30:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertNotEqualsByteArray

test/lib/jdk/test/lib/Asserts.java line 285:

> 283:      * @param lhs The left hand side of the comparison.
> 284:      * @param rhs The right hand side of the comparison.
> 285:      * @param msg A description of the assumption; {@code null} for a default message.

nit: exceeds 80 chars

test/lib/jdk/test/lib/Asserts.java line 288:

> 286:      * @throws RuntimeException if the assertion is not true.
> 287:      */
> 288:     public static void assertNotEqualsByteArray(byte[] lhs, byte[] rhs, String msg) {

nit: exceeds 80 chars

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493111466
PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493111899


From weijun at openjdk.org  Sat Feb 17 14:08:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 17 Feb 2024 14:08:12 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v4]
In-Reply-To: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
Message-ID: <xJJIJ4tAErOV9AHzhDX29UxYXa6uXCj8tt-bo1C59dc=.bec6c945-d4d1-45a8-9f49-d44709ca092a@github.com>

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

  not not not

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17776/files
  - new: https://git.openjdk.org/jdk/pull/17776/files/96e09a5d..180d31ca

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

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

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


From weijun at openjdk.org  Sat Feb 17 14:08:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 17 Feb 2024 14:08:12 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: <zCaJuMmRbsP9Iu6u5s6Hft2hDxUFdsKprrHFgnWk7RY=.d5eab682-476a-48e6-a157-fb61622257c4@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
 <TeTA6dTcFy4xwBQRyMIlS_eUkdjNz0Uwb5ZR7CJdTVU=.ebf727fa-d776-41e0-8e44-1882b10c5af7@github.com>
 <zCaJuMmRbsP9Iu6u5s6Hft2hDxUFdsKprrHFgnWk7RY=.d5eab682-476a-48e6-a157-fb61622257c4@github.com>
Message-ID: <zU6-1YH_42MsnG8G6XtT-s9WOPlAPvsF3qMLjRd4qGY=.5cd247fb-6209-4551-a8c9-c69898be6ce4@github.com>

On Sat, 17 Feb 2024 01:01:49 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   assertNotEqualsByteArray
>
> test/lib/jdk/test/lib/Asserts.java line 285:
> 
>> 283:      * @param lhs The left hand side of the comparison.
>> 284:      * @param rhs The right hand side of the comparison.
>> 285:      * @param msg A description of the assumption; {@code null} for a default message.
> 
> nit: exceeds 80 chars

It has 87 chars, but there are many long lines in this file. For example, line 184 has 113 chars.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493341744


From smarks at openjdk.org  Sat Feb 17 19:22:54 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 17 Feb 2024 19:22:54 GMT
Subject: RFR: 8325247: Memory leak in SessionKeyRef class def when using
 PKCS11 security provider
In-Reply-To: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
References: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
Message-ID: <LmOiA_vAWFrjPYT6ofdkrn3I6COsTBH7r-zVVypgthI=.f2d89369-9b56-4542-8d24-72146bed1d93@github.com>

On Thu, 15 Feb 2024 11:13:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The reported leak was caused by the death of the `Cleanup-SunPKCS11` thread. The cleanup thread in turn died because of an exception thrown from `removeNativeKey` that resulted from 2 threads executing that method at the same time.
> 
> This PR adds a reachabilityFence to ensure that the key will only be enqueued for cleanup after the user thread is done with the `removeNativeKey` call.
> 
> No new regression test; the issue is extremely hard to reproduce in a reasonable time. Existing tier1-3 tests continue to pass.
> 
> In JBS I attached a PoC patch that changes the relative timing of operations; with that patch and without the changes from this PR I am able to reproduce the issue within a few seconds. With the changes from this PR the issue did not reproduce after 10 minutes of testing.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 1537:

> 1535:                     this.ref.removeNativeKey();
> 1536:                     // prevent enqueuing SessionKeyRef until removeNativeKey is done
> 1537:                     Reference.reachabilityFence(this);

The approach we are now taking is to put the reachabilityFence() call within the finally-clause of a try-finally statement. This ensures that all paths through the method will pass through the reachability fence, regardless of inlining or other JIT optimizations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17870#discussion_r1493390418


From clanger at openjdk.org  Sun Feb 18 07:00:57 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sun, 18 Feb 2024 07:00:57 GMT
Subject: Integrated: 8326000: Remove obsolete comments for class
 sun.security.ssl.SunJSSE
In-Reply-To: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
References: <Zf4rJG7sFPQNf7f9iXKq0GoqCaXXMT3y5expGFIx_1s=.21440c0b-9084-4a6a-8c0e-ac65266bb603@github.com>
Message-ID: <WGAQFHVJnzDgy6BnuN-MSIZ6G_dWmfapxKEoimN_VuI=.6df9479c-2d34-40e4-900a-fcc7bb498bdd@github.com>

On Thu, 15 Feb 2024 22:32:58 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The experimental SunJSSE FIPS compliant mode was removed in JDK13 with [JDK-8217835](https://bugs.openjdk.org/browse/JDK-8217835).
> It seems the removal of some comments had been missed at that time. This could be irritating to readers of the code.

This pull request has now been integrated.

Changeset: c2d9fa26
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2d9fa26ce903be7c86a47db5ff289cdb9de3a62
Stats:     20 lines in 1 file changed: 0 ins; 19 del; 1 mod

8326000: Remove obsolete comments for class sun.security.ssl.SunJSSE

Reviewed-by: mbaesken, ascarpino

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

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


From djelinski at openjdk.org  Mon Feb 19 10:23:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 19 Feb 2024 10:23:06 GMT
Subject: RFR: 8325247: Memory leak in SessionKeyRef class def when using
 PKCS11 security provider [v2]
In-Reply-To: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
References: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
Message-ID: <SNY9oAAiA6CMU4qRIrdTZyssPrTAYMk1aMpVj83MHiE=.b00a4f32-a66e-420c-96f5-9e60ef55b45e@github.com>

> The reported leak was caused by the death of the `Cleanup-SunPKCS11` thread. The cleanup thread in turn died because of an exception thrown from `removeNativeKey` that resulted from 2 threads executing that method at the same time.
> 
> This PR adds a reachabilityFence to ensure that the key will only be enqueued for cleanup after the user thread is done with the `removeNativeKey` call.
> 
> No new regression test; the issue is extremely hard to reproduce in a reasonable time. Existing tier1-3 tests continue to pass.
> 
> In JBS I attached a PoC patch that changes the relative timing of operations; with that patch and without the changes from this PR I am able to reproduce the issue within a few seconds. With the changes from this PR the issue did not reproduce after 10 minutes of testing.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  put reachabilityFence in a finally clause

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17870/files
  - new: https://git.openjdk.org/jdk/pull/17870/files/8c0ed164..847af1bf

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

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

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


From djelinski at openjdk.org  Mon Feb 19 10:28:57 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 19 Feb 2024 10:28:57 GMT
Subject: RFR: 8325247: Memory leak in SessionKeyRef class def when using
 PKCS11 security provider [v2]
In-Reply-To: <LmOiA_vAWFrjPYT6ofdkrn3I6COsTBH7r-zVVypgthI=.f2d89369-9b56-4542-8d24-72146bed1d93@github.com>
References: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
 <LmOiA_vAWFrjPYT6ofdkrn3I6COsTBH7r-zVVypgthI=.f2d89369-9b56-4542-8d24-72146bed1d93@github.com>
Message-ID: <Sj9NqBjy3MknolegDW-qtlou6YWWSE-UAwCoi2dKUzY=.43569f47-7353-4d35-8e9b-fb22df3cda15@github.com>

On Sat, 17 Feb 2024 19:19:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   put reachabilityFence in a finally clause
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 1537:
> 
>> 1535:                     this.ref.removeNativeKey();
>> 1536:                     // prevent enqueuing SessionKeyRef until removeNativeKey is done
>> 1537:                     Reference.reachabilityFence(this);
> 
> The approach we are now taking is to put the reachabilityFence() call within the finally-clause of a try-finally statement. This ensures that all paths through the method will pass through the reachability fence, regardless of inlining or other JIT optimizations.

Thanks for the suggestion. Try-finally added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17870#discussion_r1494333447


From ihse at openjdk.org  Mon Feb 19 16:16:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:16:00 GMT
Subject: Integrated: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <8lQWgT0JhzAP5uuraMs8UjJXJcyTacHziySbnLN9XaQ=.16d4233d-1815-4cf8-8761-368fe425a131@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

This pull request has now been integrated.

Changeset: 5c5a282f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d
Stats:     113 lines in 38 files changed: 0 ins; 10 del; 103 mod

8325950: Make sure all files in the JDK pass jcheck

Reviewed-by: prr, wetmore, erikj, naoto

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

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


From dclarke at openjdk.org  Tue Feb 20 16:03:01 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 20 Feb 2024 16:03:01 GMT
Subject: Integrated: 8319651: Several network tests ignore vm flags when start
 java process
In-Reply-To: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
References: <BmfF9IKRBg4UJ23uGonK9eb2mCutPJ2APH14e1s1yLM=.bc355a2c-a758-4714-8512-ab671eae9415@github.com>
Message-ID: <rPaaf0kUWRzjnB2XhleUBwmCV-0tLlILXGuX5AJr3FM=.13c1c434-2a00-4573-be7e-488d0ee465d7@github.com>

On Fri, 9 Feb 2024 11:38:07 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently these tests ignore vm flags, In most cases I've updated them to use `ProcessTools.createTestJavaProcessBuilder` this usually required some cleanup also.
> 
> `test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java` and `test/jdk/java/net/URLConnection/6212146/TestDriver.java` have been set to use `@require vm.flagless` because they both use `sh` commands.
> 
> I've ran these changes against tiers 1-3 and everything seems stable

This pull request has now been integrated.

Changeset: 9538f5d3
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9538f5d317972bbb82f7f2575819d35d2a5f8b91
Stats:     123 lines in 14 files changed: 27 ins; 35 del; 61 mod

8319651: Several network tests ignore vm flags when start java process

Reviewed-by: dfuchs, jpai

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

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


From weijun at openjdk.org  Wed Feb 21 15:54:55 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 21 Feb 2024 15:54:55 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v4]
In-Reply-To: <XjwqZzl85voHuKMmrteSilTMZ7m3H3z4ulZwqAj6CoY=.adfc4414-7140-4655-85a0-08269c88c86b@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <XjwqZzl85voHuKMmrteSilTMZ7m3H3z4ulZwqAj6CoY=.adfc4414-7140-4655-85a0-08269c88c86b@github.com>
Message-ID: <iitGS7M5HKjjWq82CQi22f_V7Nnl-s1QC0Eis71C--A=.553f570e-f276-4888-b6bf-a3939fc77425@github.com>

On Fri, 16 Feb 2024 15:11:06 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted ModuleName and SignedJarWithCustomClassLoader to use createLimitedTestJavaProcessBuilder

test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 1023:

> 1021:             String... args) throws Throwable {
> 1022:         String[] cmd = new String[args.length + 5];
> 1023:         cmd[0] = jdkPath + "/bin/java";

This method passed in `jdkPath` and it could be another JDK other than the one we are testing with.

test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 1045:

> 1043:             cmd[2] = "-J-Duser.country=US";
> 1044:             System.arraycopy(jvmArgs,0, cmd, 3, jvmArgs.length);
> 1045:             System.arraycopy(args, 0, cmd, 3 + jvmArgs.length, args.length);

Again, this tool might come from a previous version of JDK. it's possible that options for the current JDK do not work with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17877#discussion_r1497822289
PR Review Comment: https://git.openjdk.org/jdk/pull/17877#discussion_r1497827533


From valeriep at openjdk.org  Thu Feb 22 03:21:54 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 22 Feb 2024 03:21:54 GMT
Subject: RFR: 8325247: Memory leak in SessionKeyRef class def when using
 PKCS11 security provider [v2]
In-Reply-To: <SNY9oAAiA6CMU4qRIrdTZyssPrTAYMk1aMpVj83MHiE=.b00a4f32-a66e-420c-96f5-9e60ef55b45e@github.com>
References: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
 <SNY9oAAiA6CMU4qRIrdTZyssPrTAYMk1aMpVj83MHiE=.b00a4f32-a66e-420c-96f5-9e60ef55b45e@github.com>
Message-ID: <18j0aRti9fH7d6bPteo_luVXRmnpXMVvCHX7CTZIJTE=.3f20bdc3-3a67-420d-836e-c00beb38eefe@github.com>

On Mon, 19 Feb 2024 10:23:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> The reported leak was caused by the death of the `Cleanup-SunPKCS11` thread. The cleanup thread in turn died because of an exception thrown from `removeNativeKey` that resulted from 2 threads executing that method at the same time.
>> 
>> This PR adds a reachabilityFence to ensure that the key will only be enqueued for cleanup after the user thread is done with the `removeNativeKey` call.
>> 
>> No new regression test; the issue is extremely hard to reproduce in a reasonable time. Existing tier1-3 tests continue to pass.
>> 
>> In JBS I attached a PoC patch that changes the relative timing of operations; with that patch and without the changes from this PR I am able to reproduce the issue within a few seconds. With the changes from this PR the issue did not reproduce after 10 minutes of testing.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put reachabilityFence in a finally clause

Looks good, thanks for the fix~

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17870#pullrequestreview-1894784874


From mdonovan at openjdk.org  Thu Feb 22 12:52:19 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 22 Feb 2024 12:52:19 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v5]
In-Reply-To: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
Message-ID: <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>

> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.

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

  reverted Compatibility.java to avoid possible conflicts with VM options and older JDKs.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17877/files
  - new: https://git.openjdk.org/jdk/pull/17877/files/e744876c..4cdeb87a

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

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

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


From weijun at openjdk.org  Thu Feb 22 14:19:56 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 22 Feb 2024 14:19:56 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v5]
In-Reply-To: <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>
Message-ID: <uPvWuiBRC-sC2wEFpE-O1V6u57Q7Pert1OtZQTeA9l4=.a34b2ff2-6b50-49f4-ba6e-8f3813a6eff7@github.com>

On Thu, 22 Feb 2024 12:52:19 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted Compatibility.java to avoid possible conflicts with VM options and older JDKs.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17877#pullrequestreview-1895973591


From weijun at openjdk.org  Thu Feb 22 17:09:02 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 22 Feb 2024 17:09:02 GMT
Subject: RFR: 8311003: missing @since info in jdk.security.jgss
Message-ID: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>

Add the `@since` info. Most of the classes were introduced in https://bugs.openjdk.org/browse/JDK-6710360. `GSSUtil.java` was there since the 1st batch of JGSS classes.

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

Commit messages:
 - the fix

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

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


From weijun at openjdk.org  Thu Feb 22 18:52:01 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 22 Feb 2024 18:52:01 GMT
Subject: RFR: 8311002: missing @since info in 21 files in jdk.security.auth
Message-ID: <wc90QWTwJjCcb4DACm6UGNY7vUDXBJHyF2_FJuZ6URk=.c957ef4b-a31b-482b-95d3-82d9dfe72028@github.com>

Add `@since` info. JAAS was included in JDK 1.4 and these classes were all in the initial release.

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

Commit messages:
 - the fix

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

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


From ascarpino at openjdk.org  Thu Feb 22 22:31:56 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Feb 2024 22:31:56 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <2MFtoeV97oaw8u-OjNtJZmjCyMnNqQpF54II2rPekys=.414bb15f-9f32-4859-89d9-2afb1a2009d8@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
 <2MFtoeV97oaw8u-OjNtJZmjCyMnNqQpF54II2rPekys=.414bb15f-9f32-4859-89d9-2afb1a2009d8@github.com>
Message-ID: <MvHZYnJfX7Cky0KcDgrCKw2tcK6Pp7Ul0QVMz60b32M=.88b2a17d-4082-4eb7-abcc-41d24f195bc8@github.com>

On Tue, 13 Feb 2024 12:09:40 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
>> 
>> Tony
>
> src/java.base/share/classes/sun/security/ssl/Alert.java line 126:
> 
>> 124: 
>> 125:         if (cause instanceof IOException) {
>> 126:             return new SSLException("("+ description + ") " + reason, cause);
> 
> It should need a space between `"("` and `+`.
> 
> Could you please define a new local variable for this expression?
> This variable can be reused by the below exceptions.

Spacing yes.

Some other exception use the description too, so I wanted to limit the scope of the change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1500018025


From ascarpino at openjdk.org  Thu Feb 22 22:31:57 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Feb 2024 22:31:57 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <iEBWlZxFXspyAN-jvvfLfIz8tL28xjPFmrqGGBR-grI=.48fdd78e-5396-4e88-bd56-2991850dbdf4@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
 <iEBWlZxFXspyAN-jvvfLfIz8tL28xjPFmrqGGBR-grI=.48fdd78e-5396-4e88-bd56-2991850dbdf4@github.com>
Message-ID: <OeAIF2dnU38AIXcOSPOdsn3urFdYxAW1LWTVNSZl3rk=.8b7f4326-04a6-49c3-9cbe-5c708bc24174@github.com>

On Tue, 13 Feb 2024 06:44:30 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
>> 
>> Tony
>
> test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java line 51:
> 
>> 49:                     pass = true;
>> 50:                     System.out.println("Found correct exception: " + args[0] +
>> 51:                     " in " + e.getMessage());
> 
> break; required?

I could just return out of the method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1500017048


From ascarpino at openjdk.org  Thu Feb 22 22:34:55 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Feb 2024 22:34:55 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <RiWgHXjSDJ0Ui0FPIATW3XEkDBCK0laDVky9H7Bzus8=.a005d6b4-1962-434e-bfaa-7a3f31cf8168@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
 <RiWgHXjSDJ0Ui0FPIATW3XEkDBCK0laDVky9H7Bzus8=.a005d6b4-1962-434e-bfaa-7a3f31cf8168@github.com>
Message-ID: <OqxzEOwISgCiO87GOAtVi8v_0NEUubLiB12l_Cayrx0=.8140f64d-b2a0-43bf-b63e-e16d8dbe083f@github.com>

On Tue, 13 Feb 2024 12:32:17 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
>> 
>> Tony
>
> test/jdk/javax/net/ssl/templates/TLSBase.java line 105:
> 
>> 103:         char[] pwd = passwd.toCharArray();
>> 104:         KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
>> 105:         ks.load(fis, pwd);
> 
> Should this input stream be closed?

`fis` can be null, so I'd need a check.  Since this is just a quick test, it is not using many resources and decided to let exiting of the test close it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17717#discussion_r1500020252


From ascarpino at openjdk.org  Thu Feb 22 22:41:10 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 22 Feb 2024 22:41:10 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates [v2]
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <vfC2QcTuWW6CfbHb7nDmeW8eJRMe6YggBB3qttD3l2I=.a25e579c-719d-45af-93b3-cb0613a950a3@github.com>

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17717/files
  - new: https://git.openjdk.org/jdk/pull/17717/files/e382e9e6..24c9dd85

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

  Stats: 19 lines in 4 files changed: 1 ins; 6 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17717.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17717/head:pull/17717

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


From jjiang at openjdk.org  Fri Feb 23 02:34:54 2024
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 23 Feb 2024 02:34:54 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates [v2]
In-Reply-To: <vfC2QcTuWW6CfbHb7nDmeW8eJRMe6YggBB3qttD3l2I=.a25e579c-719d-45af-93b3-cb0613a950a3@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
 <vfC2QcTuWW6CfbHb7nDmeW8eJRMe6YggBB3qttD3l2I=.a25e579c-719d-45af-93b3-cb0613a950a3@github.com>
Message-ID: <6C0b2g9E4tkYiIaMj8SfcJGyMkY9mrHkeQ3sA95eoUc=.71567d67-10fb-4038-a187-e86eabf359b3@github.com>

On Thu, 22 Feb 2024 22:41:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Thanks for the updates!

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

Marked as reviewed by jjiang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17717#pullrequestreview-1897297466


From ssahoo at openjdk.org  Fri Feb 23 04:37:54 2024
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 23 Feb 2024 04:37:54 GMT
Subject: RFR: JDK-8311644  Server should not send bad_certificate alert
 when the client does not send any certificates [v2]
In-Reply-To: <vfC2QcTuWW6CfbHb7nDmeW8eJRMe6YggBB3qttD3l2I=.a25e579c-719d-45af-93b3-cb0613a950a3@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
 <vfC2QcTuWW6CfbHb7nDmeW8eJRMe6YggBB3qttD3l2I=.a25e579c-719d-45af-93b3-cb0613a950a3@github.com>
Message-ID: <iZb3mlj6jCXIqcVOwewvht7jeqEF0WtThirETvZAY40=.1988d76f-7906-4b06-b7f8-8781162bc97d@github.com>

On Thu, 22 Feb 2024 22:41:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by ssahoo (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17717#pullrequestreview-1897362301


From mullan at openjdk.org  Fri Feb 23 14:14:53 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Feb 2024 14:14:53 GMT
Subject: RFR: 8311003: missing @since info in jdk.security.jgss
In-Reply-To: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
References: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
Message-ID: <A06CiNjNktk3aFaunMw5XRgkWhFjGAXF8NvLDqQOOXA=.bfbd426b-d5db-43e1-bc40-08f8081ce101@github.com>

On Thu, 22 Feb 2024 16:59:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add the `@since` info. Most of the classes were introduced in https://bugs.openjdk.org/browse/JDK-6710360. `GSSUtil.java` was there since the 1st batch of JGSS classes.

I think we should also add an `@since 1.4` to the `package-info.java` file.

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

PR Comment: https://git.openjdk.org/jdk/pull/17968#issuecomment-1961396969


From weijun at openjdk.org  Fri Feb 23 15:46:18 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 Feb 2024 15:46:18 GMT
Subject: RFR: 8311003: missing @since info in jdk.security.jgss [v2]
In-Reply-To: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
References: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
Message-ID: <ZpVu6Z7Io_w7dRah34u4SNCHYQsVPaKk8g9nXEwJX8M=.5eecf061-8503-4e42-a403-e87c64a93b49@github.com>

> Add the `@since` info. Most of the classes were introduced in https://bugs.openjdk.org/browse/JDK-6710360. `GSSUtil.java` was there since the 1st batch of JGSS classes.

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

  add `@since` to `package-info.java` as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17968/files
  - new: https://git.openjdk.org/jdk/pull/17968/files/e7767eee..a7959e10

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

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

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


From mullan at openjdk.org  Fri Feb 23 15:49:53 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 23 Feb 2024 15:49:53 GMT
Subject: RFR: 8311003: missing @since info in jdk.security.jgss [v2]
In-Reply-To: <ZpVu6Z7Io_w7dRah34u4SNCHYQsVPaKk8g9nXEwJX8M=.5eecf061-8503-4e42-a403-e87c64a93b49@github.com>
References: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
 <ZpVu6Z7Io_w7dRah34u4SNCHYQsVPaKk8g9nXEwJX8M=.5eecf061-8503-4e42-a403-e87c64a93b49@github.com>
Message-ID: <QCB0ceKXNENFipEK3v1mJtL63gBQ3VM6LwCpLU_WmIg=.a1d8edbc-1c68-43d5-9137-42a8fe1df166@github.com>

On Fri, 23 Feb 2024 15:46:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add the `@since` info. Most of the classes were introduced in https://bugs.openjdk.org/browse/JDK-6710360. `GSSUtil.java` was there since the 1st batch of JGSS classes.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add `@since` to `package-info.java` as well

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17968#pullrequestreview-1898418741


From weijun at openjdk.org  Fri Feb 23 16:13:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 23 Feb 2024 16:13:58 GMT
Subject: Integrated: 8311003: missing @since info in jdk.security.jgss
In-Reply-To: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
References: <VIZQACa5rfe-O4GJJZItY2Q26xmElKTOWTUz_EdJq5Q=.2f28bfdb-beee-4b03-9273-415c23e156cd@github.com>
Message-ID: <wZmD-uSu8ff4VI9nKhkkx_dh7Bp2MJbzdRjliB780H0=.278ea2ae-bda4-4fa3-bb52-8bb435f80326@github.com>

On Thu, 22 Feb 2024 16:59:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add the `@since` info. Most of the classes were introduced in https://bugs.openjdk.org/browse/JDK-6710360. `GSSUtil.java` was there since the 1st batch of JGSS classes.

This pull request has now been integrated.

Changeset: c26c5833
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c26c5833ccd7bdfd3f8ed9da76334d5b4e6e55ca
Stats:     17 lines in 6 files changed: 12 ins; 0 del; 5 mod

8311003: missing @since info in jdk.security.jgss

Reviewed-by: mullan

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

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


From abakhtin at openjdk.org  Fri Feb 23 23:07:07 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 23 Feb 2024 23:07:07 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v7]
In-Reply-To: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
Message-ID: <xjrojmm1DJEvQEAjUxiFieXbxc0Oso4y-6fkZXh6Va0=.78af5c0f-b230-4dc0-8d88-a9a49de475d1@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.

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

  Load root certificates from SystemRootCertificates.keychain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16722/files
  - new: https://git.openjdk.org/jdk/pull/16722/files/595903f6..24ca1206

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

  Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 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 abakhtin at openjdk.org  Fri Feb 23 23:10:56 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 23 Feb 2024 23:10:56 GMT
Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v5]
In-Reply-To: <yPGDPz9LovJi6Zq2AujBe9wWBN98ccCtmfK6pibQKxA=.9b689fde-49aa-462c-8ab8-ab3c8ba13772@github.com>
References: <xEBFG1ZTKdOJMDIWZ8knSQD6RY3jJb7A2Q5N5NGNNX0=.a0f82005-5385-48c3-b96a-5fcaf534ff1f@github.com>
 <H4r_jfTP3gQpaVqUQ2bAl1AgDX5lN3P4n8oCk_Fukio=.a69c2c05-c656-4d69-bdbb-e226829f407a@github.com>
 <upJeEhGRHpC5akCsNJE-qw9wLE8JVeTbMgaF19k5XX4=.de8b5d1d-05e7-43c0-8c84-463d26e3a2ab@github.com>
 <iZwXZl-JKTLXb2A4JC1pRHur9ukAcJoyUq3PvK3L_yA=.21848030-bfcc-46f7-b3bd-7cc9aa14381b@github.com>
 <pWiI8p1UCqL6qR2T972Z0HbvAMXxfVwmaxx_OlPlSck=.10058ab2-ee28-4215-880a-dcd3faa42a21@github.com>
 <yPGDPz9LovJi6Zq2AujBe9wWBN98ccCtmfK6pibQKxA=.9b689fde-49aa-462c-8ab8-ab3c8ba13772@github.com>
Message-ID: <MG_s9HxkwKSiESwIZ5CZ2Ze6-fBBBxKMuSWvT8iHcrk=.0f8660ed-1b54-4fec-a3a8-753331dac249@github.com>

On Fri, 16 Feb 2024 15:01:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > `security dump-trust-settings -s` returns only predefined root certificates. KEYCHAINSTORE-ROOT additionally contains installed root trusted certificates in the system domain
> 
> Are you sure they should be added into this keystore? It looks like all the extra certs in KEYCHAINSTORE-ROOT that are not in `security dump-trust-settings -s` are all inside KEYCHAINSTORE. Maybe that's where they should belong to?

Thank you. You are right. It is better if KEYCHAINSTORE-ROOT contains only predefined roots. Unfortunately, SecTrustCopyAnchorCertificates can not be used in this case.

I have updated the patch to read certificates from the "/System/Library/Keychains/SystemRootCertificates.keychain" keychain

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

PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecomment-1962117463


From ascarpino at openjdk.org  Mon Feb 26 16:51:50 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 26 Feb 2024 16:51:50 GMT
Subject: Integrated: JDK-8311644 Server should not send bad_certificate alert
 when the client does not send any certificates
In-Reply-To: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
References: <ppXPCxnZ9_V6Ku6fWRTl7qX5_BZCoLqDuc3pUFj6ftY=.41d80608-6b92-4f84-9167-c45326372cf9@github.com>
Message-ID: <uYHqO4svsL7N5V1ZWyCH1pjK7WbTH3CQP7xSBzBOdlY=.34ab3ad7-7ff9-4f1c-a757-5a1a02f050da@github.com>

On Tue, 6 Feb 2024 01:23:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review of what is really a text change.  This changes the alert type returned during some TLS CertificateMessage failures to what is recommended in [RFC 8446](https://tools.ietf.org/html/rfc8446).  An additional change was to add the alert description to the thrown exception.  This makes it easier for the user to know the alert type and makes testing easier.  Two of the three changes are tested as the final one is too hard to test.  A few tests needed change as they did string comparing on exception messages.
> 
> Tony

This pull request has now been integrated.

Changeset: f62b5789
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f62b5789add23adda2634a1cfb80f48b4387be74
Stats:     270 lines in 8 files changed: 191 ins; 24 del; 55 mod

8311644: Server should not send bad_certificate alert when the client does not send any certificates

Reviewed-by: djelinski, jjiang, ssahoo

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

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


From hchao at openjdk.org  Mon Feb 26 18:07:43 2024
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 26 Feb 2024 18:07:43 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v5]
In-Reply-To: <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>
Message-ID: <UWCmvKsriHy7yj1IJGDh8B3UdvbQwCS9E25elGayfNY=.7c965b27-c626-468a-a4b2-1d0b4bbc8fa9@github.com>

On Thu, 22 Feb 2024 12:52:19 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted Compatibility.java to avoid possible conflicts with VM options and older JDKs.

Nit: Copyright year of IterationCount.java would need to be changed.

Looks good. Thanks.

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

Marked as reviewed by hchao (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17877#pullrequestreview-1901649894
PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1964804507


From lancea at openjdk.org  Mon Feb 26 20:01:08 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Feb 2024 20:01:08 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc
Message-ID: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>

This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".

In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.

It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate

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

Commit messages:
 - Initial update for JDK-8326687

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

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


From valeriep at openjdk.org  Mon Feb 26 21:50:45 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 26 Feb 2024 21:50:45 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v4]
In-Reply-To: <xJJIJ4tAErOV9AHzhDX29UxYXa6uXCj8tt-bo1C59dc=.bec6c945-d4d1-45a8-9f49-d44709ca092a@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
 <xJJIJ4tAErOV9AHzhDX29UxYXa6uXCj8tt-bo1C59dc=.bec6c945-d4d1-45a8-9f49-d44709ca092a@github.com>
Message-ID: <gWf-6pIil2itSp8dqguk4vBXUmpx81cnzLcK5nl8dP8=.7fb78746-e513-4c2c-a2ad-f80736e4e57b@github.com>

On Sat, 17 Feb 2024 14:08:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   not not not

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17776#pullrequestreview-1902105900


From weijun at openjdk.org  Mon Feb 26 21:55:48 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 26 Feb 2024 21:55:48 GMT
Subject: Integrated: 8325506: Ensure randomness is only read from provided
 SecureRandom object
In-Reply-To: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
References: <TxmBX2SLN4E8oQ6sGNe_Oz1HGb0egaJrqoCzzvra9Kc=.8467b7ac-d4af-4319-9f13-d12da8ef22d8@github.com>
Message-ID: <1AiRtHSqsZz22oxWXMGrCoyYftuafIvi9Sm1aznH3tQ=.3a5b4657-41d1-4dc5-8d65-af3c754105ad@github.com>

On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

This pull request has now been integrated.

Changeset: b87d9cf2
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b87d9cf2c9d905c15f4c957d42361b1a72974edf
Stats:     551 lines in 6 files changed: 546 ins; 0 del; 5 mod

8325506: Ensure randomness is only read from provided SecureRandom object

Reviewed-by: kdriver, valeriep

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

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


From mbalao at redhat.com  Mon Feb 26 22:12:45 2024
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 26 Feb 2024 17:12:45 -0500
Subject: RFD: Security Providers Filter (JEP)
Message-ID: <e4e2c21a-6eb5-413b-885a-114ad5496302@redhat.com>

Hello,

We would like to announce that the Security Providers Filter JEP (draft) 
is available for discussion.

  * https://openjdk.org/jeps/8325511

As a reminder, the implementation pull-request is available at 
https://github.com/openjdk/jdk/pull/15539

We look forward to any questions, comments and feedback.

Thanks,
Martin and Francisco.-



From djelinski at openjdk.org  Tue Feb 27 07:09:49 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Feb 2024 07:09:49 GMT
Subject: Integrated: 8325247: Memory leak in SessionKeyRef class def when using
 PKCS11 security provider
In-Reply-To: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
References: <efQocu6tdYckQ3tnuuAatzWU5aJnIYavxrtfQjSnpAQ=.8d323e0c-e014-499c-b585-2c7214e997f0@github.com>
Message-ID: <pRcb-J6F5WK6MQS_QcL7gHmf2HivD0rVAOdlBxNTTzI=.5e86090c-3fa0-473b-b740-fef72cb5e03a@github.com>

On Thu, 15 Feb 2024 11:13:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The reported leak was caused by the death of the `Cleanup-SunPKCS11` thread. The cleanup thread in turn died because of an exception thrown from `removeNativeKey` that resulted from 2 threads executing that method at the same time.
> 
> This PR adds a reachabilityFence to ensure that the key will only be enqueued for cleanup after the user thread is done with the `removeNativeKey` call.
> 
> No new regression test; the issue is extremely hard to reproduce in a reasonable time. Existing tier1-3 tests continue to pass.
> 
> In JBS I attached a PoC patch that changes the relative timing of operations; with that patch and without the changes from this PR I am able to reproduce the issue within a few seconds. With the changes from this PR the issue did not reproduce after 10 minutes of testing.

This pull request has now been integrated.

Changeset: ec9437db
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec9437dbcc242b62e3b099dd05b129760419f025
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8325247: Memory leak in SessionKeyRef class def when using PKCS11 security provider

Reviewed-by: valeriep

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

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


From dfuchs at openjdk.org  Tue Feb 27 12:45:50 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Feb 2024 12:45:50 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc
In-Reply-To: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
Message-ID: <xfG3xRROaj2UMnX4w_W2njdHzLwH1ulM0MJEvOm1E-E=.4327e344-0d22-4ba8-91de-63859003335c@github.com>

On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
> 
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
> 
> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate

I am not a usual Reviewer for this area but the changes LGTM Lance. I haven't seen anything unexpected given the description of the changes.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1903392981


From mdonovan at openjdk.org  Tue Feb 27 13:09:55 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 27 Feb 2024 13:09:55 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v5]
In-Reply-To: <UWCmvKsriHy7yj1IJGDh8B3UdvbQwCS9E25elGayfNY=.7c965b27-c626-468a-a4b2-1d0b4bbc8fa9@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>
 <UWCmvKsriHy7yj1IJGDh8B3UdvbQwCS9E25elGayfNY=.7c965b27-c626-468a-a4b2-1d0b4bbc8fa9@github.com>
Message-ID: <Y8OZj4YwOz7NxAQBpXDKdKQOULLjTXoPC9JS9xbRWH8=.cdd2ff42-c35d-42fb-9610-5ef3e53dfd59@github.com>

On Mon, 26 Feb 2024 18:04:18 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Nit: Copyright year of IterationCount.java would need to be changed.

That is a Red Hat copyright; should I add an Oracle copyright? The file isn't significantly changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1966508557


From weijun at openjdk.org  Tue Feb 27 14:29:11 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 14:29:11 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of GSSLibStub.c:179
Message-ID: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>

Add a `memset` after memory is successfully allocated.

No regression test, hard to write without a KDC.

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

Commit messages:
 - the fix

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

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


From eirbjo at openjdk.org  Tue Feb 27 14:47:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 27 Feb 2024 14:47:51 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc
In-Reply-To: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
Message-ID: <ycQnRxxYHmHwzkVUY9NVAqkIqdgy2KOpje-qe_uCYkI=.5f49a77e-d47f-41e3-81f2-74686b32256a@github.com>

On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
> 
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
> 
> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate

The class javadocs for `java.util.zip.ZipCoder` uses "zipfile" which is probably a reference to the `ZipFile` class.

`jdk.nio.zipfs.ZipCoder` seems to have borrowed the class javadocs, but here `ZipFile` does not make sense. Perhaps `ZipFileSystem` would be better?

Would you consider fixing this to CamelCase in this PR (although it is maybe not directly the same inconsistency the PR aims to fix)?
 
https://github.com/openjdk/jdk/blob/c5c866aafe76f51cd5386bf5052c06691c1a0e8c/src/java.base/share/classes/java/util/zip/ZipCoder.java#L41

https://github.com/openjdk/jdk/blob/c5c866aafe76f51cd5386bf5052c06691c1a0e8c/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java#L41

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

PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1966701666


From eirbjo at openjdk.org  Tue Feb 27 15:14:45 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 27 Feb 2024 15:14:45 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc
In-Reply-To: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
Message-ID: <bIadrs08xbS8jLK0_-3RPKALDR2zReJYa2EBDsBZljs=.e46fcf29-a129-4065-a980-dff391250880@github.com>

On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
> 
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
> 
> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate

Can you confirm that "zip" in `java.util.zip.ZipUtils.loadLibrary()` was intentionally left lowercase? (Presumably the native library should be referred to by lowercase "zip"):

https://github.com/openjdk/jdk/blob/c5c866aafe76f51cd5386bf5052c06691c1a0e8c/src/java.base/share/classes/java/util/zip/ZipUtils.java#L290

See separate feedback about the `ZipOutputStream.inhibitZip64` comment.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 54:

> 52:      * Whether to use ZIP64 for zip files with more than 64k entries.
> 53:      * Until ZIP64 support in zip implementations is ubiquitous, this
> 54:      * system property allows the creation of zip files which can be

Suggestion:

     * Whether to use ZIP64 for ZIP files with more than 64k entries.
     * Until ZIP64 support in ZIP implementations is ubiquitous, this
     * system property allows the creation of ZIP files which can be

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

PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1903793561
PR Review Comment: https://git.openjdk.org/jdk/pull/18011#discussion_r1504401597


From lancea at openjdk.org  Tue Feb 27 16:15:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Feb 2024 16:15:06 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
Message-ID: <EtGFsrJLB0_WSCc1QzOr4kRlMNrRxPxMsLAKUtumIhA=.a6e8ff21-1272-4d3c-8209-9fc64ce4e160@github.com>

On Tue, 27 Feb 2024 16:12:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
>> 
>> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
>> 
>> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address initial feedback for JDK-8326687

Updated ZipOutputStream.java and the other file you mentioned.  I intentionally did not update any files which were not generating javadoc.

We can certainly address any additional files and tests not related to javadoc via a separate issue.


Thank you Eirik and Daniel for the review

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

PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1903973731


From lancea at openjdk.org  Tue Feb 27 16:15:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Feb 2024 16:15:06 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
Message-ID: <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>

> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
> 
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
> 
> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate

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

  Address initial feedback for JDK-8326687

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18011/files
  - new: https://git.openjdk.org/jdk/pull/18011/files/0208b860..baa67f11

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

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

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


From lancea at openjdk.org  Tue Feb 27 16:15:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Feb 2024 16:15:06 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <bIadrs08xbS8jLK0_-3RPKALDR2zReJYa2EBDsBZljs=.e46fcf29-a129-4065-a980-dff391250880@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <bIadrs08xbS8jLK0_-3RPKALDR2zReJYa2EBDsBZljs=.e46fcf29-a129-4065-a980-dff391250880@github.com>
Message-ID: <-AFPx8rmcTtpgwzP8GpRi4wvjbMHxPiXtAfVRWNjpIY=.04064385-f142-4429-9aca-fa37e20e25be@github.com>

On Tue, 27 Feb 2024 15:08:11 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address initial feedback for JDK-8326687
>
> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 54:
> 
>> 52:      * Whether to use ZIP64 for zip files with more than 64k entries.
>> 53:      * Until ZIP64 support in zip implementations is ubiquitous, this
>> 54:      * system property allows the creation of zip files which can be
> 
> Suggestion:
> 
>      * Whether to use ZIP64 for ZIP files with more than 64k entries.
>      * Until ZIP64 support in ZIP implementations is ubiquitous, this
>      * system property allows the creation of ZIP files which can be

Fixed not sure how Missed this when updating ZipOutputStream

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18011#discussion_r1504509576


From mpowers at openjdk.org  Tue Feb 27 16:39:51 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 27 Feb 2024 16:39:51 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179
In-Reply-To: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
Message-ID: <R3292B94OI-ZNWFSgQEembZjzzR9QOZen7GlK-yF8gU=.2209d259-4517-433a-97ed-a989a0008998@github.com>

On Mon, 26 Feb 2024 22:33:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add a `memset` after memory is successfully allocated.
> 
> No regression test, hard to write without a KDC.

Why do you have to set memory to zero?
If you really need to, `calloc()` sets memory to zero.

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

PR Comment: https://git.openjdk.org/jdk/pull/18015#issuecomment-1967022066


From weijun at openjdk.org  Tue Feb 27 17:00:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 17:00:53 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179
In-Reply-To: <R3292B94OI-ZNWFSgQEembZjzzR9QOZen7GlK-yF8gU=.2209d259-4517-433a-97ed-a989a0008998@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <R3292B94OI-ZNWFSgQEembZjzzR9QOZen7GlK-yF8gU=.2209d259-4517-433a-97ed-a989a0008998@github.com>
Message-ID: <8Ug5GIqjbCSRrv0ENTX-FWhum8I0VNWzpWo4df0Dux0=.56c8bedc-a925-44df-8a09-d06361f4ffdf@github.com>

On Tue, 27 Feb 2024 16:36:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> Why do you have to set memory to zero? If you really need to, `calloc()` sets memory to zero.

Inside `newGSSCB`, if there is anything wrong before `cb->application_data` is initialized, `deleteGSSCB` will be called and it has

  if (cb->application_data.length != 0) {
    resetGSSBuffer(&(cb->application_data));
  }

Now if `length` is not zero, `resetGSSBuffer` function calls `free` on a buffer.

And yes, `calloc` should also work.

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

PR Comment: https://git.openjdk.org/jdk/pull/18015#issuecomment-1967126345


From weijun at openjdk.org  Tue Feb 27 17:08:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 17:08:54 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v2]
In-Reply-To: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
Message-ID: <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>

> Add a `memset` after memory is successfully allocated.
> 
> No regression test, hard to write without a KDC.

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

  use calloc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18015/files
  - new: https://git.openjdk.org/jdk/pull/18015/files/38e41137..9983d06b

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

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

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


From valeriep at openjdk.org  Tue Feb 27 18:41:51 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 27 Feb 2024 18:41:51 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v2]
In-Reply-To: <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
Message-ID: <RuZNBE6A4UuubQCwey8G77a4eX-wo3GfbADgx-2wxxI=.0391b3d6-119c-43ba-bcf6-a0226766f6c6@github.com>

On Tue, 27 Feb 2024 17:08:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a `memset` after memory is successfully allocated.
>> 
>> No regression test, hard to write without a KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use calloc

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18015#pullrequestreview-1904515125


From mpowers at openjdk.org  Tue Feb 27 18:41:51 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 27 Feb 2024 18:41:51 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v2]
In-Reply-To: <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
Message-ID: <dz6BE9tLSLLphG0N-3nP_4ZV1mFYjWZeYySUH73WIPU=.fd46868b-53cb-45d7-b5bd-5a7a98f7332f@github.com>

On Tue, 27 Feb 2024 17:08:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a `memset` after memory is successfully allocated.
>> 
>> No regression test, hard to write without a KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use calloc

Thanks for connecting the dots.

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

PR Comment: https://git.openjdk.org/jdk/pull/18015#issuecomment-1967369823


From djelinski at openjdk.org  Tue Feb 27 19:08:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Feb 2024 19:08:53 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v2]
In-Reply-To: <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
Message-ID: <dZ9yv5QgYpFRv4HVv0vX6Z3078jTstciGbG2uFrVUS4=.ae8980ef-93a8-4506-977d-a133cf255e08@github.com>

On Tue, 27 Feb 2024 17:08:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a `memset` after memory is successfully allocated.
>> 
>> No regression test, hard to write without a KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use calloc

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18015#pullrequestreview-1904578882


From rhalade at openjdk.org  Tue Feb 27 19:20:52 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 27 Feb 2024 19:20:52 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v2]
In-Reply-To: <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
Message-ID: <rDcxbSbMu5lva_l3LHvYR4J3LEAqiWNiRooArqn7GCI=.f6fc007e-ecf9-4e8b-89a8-76b18ed853f0@github.com>

On Tue, 27 Feb 2024 17:08:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a `memset` after memory is successfully allocated.
>> 
>> No regression test, hard to write without a KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use calloc

src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 199:

> 197:   }
> 198: 
> 199:   cb = calloc(1, sizeof(struct gss_channel_bindings_struct));

With this update, memset calls at line 220 are unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18015#discussion_r1504826217


From weijun at openjdk.org  Tue Feb 27 21:09:04 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 21:09:04 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v3]
In-Reply-To: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
Message-ID: <Rq4yVYk5jnwAVLPjq-PfpUzhItgI_CxjvoHagk7Cu7Q=.908aa596-ec40-4aef-be5c-8c6bd6e9c82b@github.com>

> Add a `memset` after memory is successfully allocated.
> 
> No regression test, hard to write without a KDC.

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

  no need to zero again for some fields

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18015/files
  - new: https://git.openjdk.org/jdk/pull/18015/files/9983d06b..49f881a4

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

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

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


From weijun at openjdk.org  Tue Feb 27 21:09:05 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 21:09:05 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v2]
In-Reply-To: <rDcxbSbMu5lva_l3LHvYR4J3LEAqiWNiRooArqn7GCI=.f6fc007e-ecf9-4e8b-89a8-76b18ed853f0@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <ov_vTCgnR9EveFFiMkm6nIgXc4pkmoVvw-7jVGXK3Bs=.8a3356af-e806-464f-8e08-47b508b47b24@github.com>
 <rDcxbSbMu5lva_l3LHvYR4J3LEAqiWNiRooArqn7GCI=.f6fc007e-ecf9-4e8b-89a8-76b18ed853f0@github.com>
Message-ID: <aTDDWOGLpsnkIGsDfjwkQlmppXn4KLKJwdj8P3tyGpc=.9c799d7b-fbe4-430d-811a-6eda6c89ece0@github.com>

On Tue, 27 Feb 2024 19:17:37 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use calloc
>
> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 199:
> 
>> 197:   }
>> 198: 
>> 199:   cb = calloc(1, sizeof(struct gss_channel_bindings_struct));
> 
> With this update, memset calls at line 220 are unnecessary.

Correct! I can remove 2 other lines as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18015#discussion_r1504989534


From rhalade at openjdk.org  Tue Feb 27 21:42:55 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 27 Feb 2024 21:42:55 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v3]
In-Reply-To: <Rq4yVYk5jnwAVLPjq-PfpUzhItgI_CxjvoHagk7Cu7Q=.908aa596-ec40-4aef-be5c-8c6bd6e9c82b@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
 <Rq4yVYk5jnwAVLPjq-PfpUzhItgI_CxjvoHagk7Cu7Q=.908aa596-ec40-4aef-be5c-8c6bd6e9c82b@github.com>
Message-ID: <aYfZ7er3xCWewcXM0Tj-XlSkYsdXFJc7XHo9gD-jDcM=.52a96bc7-649d-462b-829d-6c38e3480edb@github.com>

On Tue, 27 Feb 2024 21:09:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a `memset` after memory is successfully allocated.
>> 
>> No regression test, hard to write without a KDC.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to zero again for some fields

src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 213:

> 211:   if ((*env)->IsInstanceOf(env, jcb, tlsCBCl)) {
> 212:       // TLS Channel Binding requires unspecified addrtype=0
> 213:       cb->initiator_addrtype = GSS_C_AF_UNSPEC;

Thanks for the update. I suggest not to remove this assignment as it helps understand the flow. Or if you prefer it then invert if condition to cover else part and avoid empty if block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18015#discussion_r1505039772


From weijun at openjdk.org  Tue Feb 27 22:29:02 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 22:29:02 GMT
Subject: RFR: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179 [v4]
In-Reply-To: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
Message-ID: <blvrlXmUNSLTg4OtTSuiJ9IjwU_hzY5O0dO41IEIMWs=.cd2d818a-68d4-4d11-ac63-8f90fd5f5c09@github.com>

> Add a `memset` after memory is successfully allocated.
> 
> No regression test, hard to write without a KDC.

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

  add back 2 lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18015/files
  - new: https://git.openjdk.org/jdk/pull/18015/files/49f881a4..9f5c744c

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

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

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


From weijun at openjdk.org  Tue Feb 27 22:29:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 27 Feb 2024 22:29:03 GMT
Subject: Integrated: 8325680: Uninitialised memory in deleteGSSCB of
 GSSLibStub.c:179
In-Reply-To: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
References: <DOyQtvL8EeXxPQPSsYRUdcjkX-GzisMOqZOZY54CX5g=.bf5b83d4-fce0-4449-8107-b2ee03018f39@github.com>
Message-ID: <kqA1HWwSBw-CsZ_wp4TqhbAv9ykKDydVPMZ6lDYDbjA=.da0d6df7-b1fe-42f8-90d1-7c0b34a54f79@github.com>

On Mon, 26 Feb 2024 22:33:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add a `memset` after memory is successfully allocated.
> 
> No regression test, hard to write without a KDC.

This pull request has now been integrated.

Changeset: 419191c6
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/419191c653f787b5dc3032f9da31d8c9b9a08235
Stats:     8 lines in 1 file changed: 3 ins; 3 del; 2 mod

8325680: Uninitialised memory in deleteGSSCB of GSSLibStub.c:179

Reviewed-by: valeriep, djelinski

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

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


From jpai at openjdk.org  Wed Feb 28 14:00:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Feb 2024 14:00:53 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
Message-ID: <BSv_hUipDqLhYWu7FPgnpNz40aFpHzH_g1H-7fONgbM=.06567576-b6e4-4454-acd0-47cc1415c419@github.com>

On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
>> 
>> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
>> 
>> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address initial feedback for JDK-8326687

Hello Lance, this doc-only change looks good to me. 

These changes are merely changing the case of `zip` and aren't changing any specification of the APIs and that looks fine to me.

I had imagined that we would be changing only the public API documentations but I suspect you decided to update even code comments and internal class comments to keep everything consistent. I am not opposing it and I ask this so that I can use this decision in future when adding anything in this area or reviewing code.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1906340184


From jpai at openjdk.org  Wed Feb 28 14:06:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Feb 2024 14:06:57 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
Message-ID: <zJYpAC9Y7rJHb9DVD6K1OR0M-aWDO4ZGvVOd8F19wVE=.f42d3ab6-f607-45ef-9710-333ecc1b57a1@github.com>

On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
>> 
>> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
>> 
>> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address initial feedback for JDK-8326687

GitHub doesn't allow me to comment on unchanged lines in the PR, but while reviewing this I noticed 2 things:

- It looks like http://www.pkware.com/documents/casestudies/APPNOTE.TXT is now auto redirecting to https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.9.TXT. I'm not sure if its temporary or a permanent thing.

- The other thing is we don't seem to have a `@spec` entry in `src/java.base/share/classes/java/util/zip/package-info.java` pointing to http://www.pkware.com/documents/casestudies/APPNOTE.TXT. We are pointing to ZLIB RFC 1950. Do you think we should add a `@spec` entry to point to http://www.pkware.com/documents/casestudies/APPNOTE.TXT? Of course as a separate PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969053529


From gli at openjdk.org  Wed Feb 28 14:16:44 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 28 Feb 2024 14:16:44 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
Message-ID: <BmVDm8fO3HOLNZ9dHXjY1xyKNAF-30q7O-JdTfbC7Wc=.ed032054-de31-4358-a2fd-e10c2cf30d5d@github.com>

On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
>> 
>> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
>> 
>> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address initial feedback for JDK-8326687

I search the package `java.util.zip` and find several `zip64` in the file [ZipConstants64.java](https://github.com/openjdk/jdk/blob/baa67f1130947c7204fc12018d25bfb48528784c/src/java.base/share/classes/java/util/zip/ZipConstants64.java#L51). It seems you didn't fix all the files in the package `java.util.zip/jar`. Is it your intent? Or you miss some files?

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

PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1906378373


From lancea at openjdk.org  Wed Feb 28 14:35:53 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Feb 2024 14:35:53 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <BmVDm8fO3HOLNZ9dHXjY1xyKNAF-30q7O-JdTfbC7Wc=.ed032054-de31-4358-a2fd-e10c2cf30d5d@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
 <BmVDm8fO3HOLNZ9dHXjY1xyKNAF-30q7O-JdTfbC7Wc=.ed032054-de31-4358-a2fd-e10c2cf30d5d@github.com>
Message-ID: <6zOtUk9RRjyRQolkPdX-33nBCrH8hCk7TaGsGA92Rds=.96ed98fb-6b44-4ef7-b64e-519d102a2d02@github.com>

On Wed, 28 Feb 2024 14:13:57 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> I search the package `java.util.zip` and find several `zip64` in the file [ZipConstants64.java](https://github.com/openjdk/jdk/blob/baa67f1130947c7204fc12018d25bfb48528784c/src/java.base/share/classes/java/util/zip/ZipConstants64.java#L51). It seems you didn't fix all the files in the package `java.util.zip/jar`. Is it your intent? Or you miss some files?

The intent of the change is to make the javadoc consistent.  There were a couple of files that Eirik mentioned that I addressed but as I indicated in my reply, unless there is a missing javadoc update, I do not plan to address other areas with this PR but can/will in a following

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

PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969116524


From gli at openjdk.org  Wed Feb 28 14:40:54 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 28 Feb 2024 14:40:54 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
Message-ID: <kBpVyXHUqrntpCiIh2XA1KJNVAFkhgVIdRcA-yGJq3c=.b1a1d7ca-3932-45dd-91fc-f7f4d512b0cf@github.com>

On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
>> 
>> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
>> 
>> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address initial feedback for JDK-8326687

>  I do not plan to address other areas with this PR but can/will in a following

OK. Looks good.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1906443439


From lancea at openjdk.org  Wed Feb 28 14:40:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Feb 2024 14:40:54 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <BSv_hUipDqLhYWu7FPgnpNz40aFpHzH_g1H-7fONgbM=.06567576-b6e4-4454-acd0-47cc1415c419@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
 <BSv_hUipDqLhYWu7FPgnpNz40aFpHzH_g1H-7fONgbM=.06567576-b6e4-4454-acd0-47cc1415c419@github.com>
Message-ID: <_bJl32Vu-yAE9gVidjNGnqnw00Obc23KUt6Y4_yp7Og=.17f190aa-490d-4e95-9586-efc8a6724053@github.com>

On Wed, 28 Feb 2024 13:58:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Lance, this doc-only change looks good to me.
> 
> These changes are merely changing the case of `zip` and aren't changing any specification of the APIs and that looks fine to me.
> 
> I had imagined that we would be changing only the public API documentations but I suspect you decided to update even code comments and internal class comments to keep everything consistent. I am not opposing it and I ask this so that I can use this decision in future when adding anything in this area or reviewing code.

Hi Jai,


thank you.  As part of updating the relevant class which contained public facing javadoc, I also updated the casing for comments as you point out for consistency.  I did not want to go through all of the tests and non-public facing classes as part of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969122748


From lancea at openjdk.org  Wed Feb 28 14:53:44 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Feb 2024 14:53:44 GMT
Subject: RFR: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2]
In-Reply-To: <zJYpAC9Y7rJHb9DVD6K1OR0M-aWDO4ZGvVOd8F19wVE=.f42d3ab6-f607-45ef-9710-333ecc1b57a1@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
 <gcCpiZ_ykbNYTgc9tH4ILoIw8aWrBU9lHGVoTHIpEXc=.81b1b1f3-a6fe-49a0-8ee8-0d5c720e4aeb@github.com>
 <zJYpAC9Y7rJHb9DVD6K1OR0M-aWDO4ZGvVOd8F19wVE=.f42d3ab6-f607-45ef-9710-333ecc1b57a1@github.com>
Message-ID: <vx-w2-oStUkKbMpl47ETpBt0CPzGJ3Dm59XKBh-k4Os=.85b8f2ba-a7e8-4227-8a30-50284037956f@github.com>

On Wed, 28 Feb 2024 14:03:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> GitHub doesn't allow me to comment on unchanged lines in the PR, but while reviewing this I noticed 2 things:
> 
> * It looks like http://www.pkware.com/documents/casestudies/APPNOTE.TXT is now auto redirecting to https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.9.TXT. I'm not sure if it's temporary or a permanent thing.

I cannot answer that specifically but we need to rely on PKWARE to keep this as accurate as possible.  The link has been broken several times by PKWare so  I think the best that we can do is keep checking.


> * The other thing is we don't seem to have a `@spec` entry in `src/java.base/share/classes/java/util/zip/package-info.java` pointing to http://www.pkware.com/documents/casestudies/APPNOTE.TXT. We are pointing to ZLIB RFC 1950. Do you think we should add a `@spec` entry to point to http://www.pkware.com/documents/casestudies/APPNOTE.TXT? Of course as a separate PR.

Good Question,   let's discuss and handle separately as I don't know the history of why it was not included

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

PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969151426


From lancea at openjdk.org  Wed Feb 28 17:16:57 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Feb 2024 17:16:57 GMT
Subject: Integrated: 8326687: Inconsistent use of "ZIP",
 "Zip" and "zip" in java.util.zip/jar zipfs javadoc
In-Reply-To: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
References: <Y6K840w1D82fHB0uqcTV420MeDflttr56zzIlDBT1LQ=.bf3b055d-681c-423f-8120-65c200b406b4@github.com>
Message-ID: <_4PZwtidigoz0Ekk-XjBeseIPbvB2pD9Y3xwHPY8pH8=.a634b673-1bbd-4815-8978-2db1ead406bc@github.com>

On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP".
> 
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec.
> 
> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate

This pull request has now been integrated.

Changeset: 38ad5145
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38ad514589764d16b312152474e2446c3339da39
Stats:     123 lines in 12 files changed: 0 ins; 0 del; 123 mod

8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc

Reviewed-by: dfuchs, jpai, gli

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

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


From rhalade at openjdk.org  Wed Feb 28 18:08:44 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 28 Feb 2024 18:08:44 GMT
Subject: RFR: 8319673: Few security tests ignore VM flags [v5]
In-Reply-To: <Y8OZj4YwOz7NxAQBpXDKdKQOULLjTXoPC9JS9xbRWH8=.cdd2ff42-c35d-42fb-9610-5ef3e53dfd59@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
 <rVayw-MopnOgPH5vC-w8crFW00F4Pi2B13wS7bMEwZY=.320592b7-afc4-4c95-b6f8-532cc4fef59a@github.com>
 <UWCmvKsriHy7yj1IJGDh8B3UdvbQwCS9E25elGayfNY=.7c965b27-c626-468a-a4b2-1d0b4bbc8fa9@github.com>
 <Y8OZj4YwOz7NxAQBpXDKdKQOULLjTXoPC9JS9xbRWH8=.cdd2ff42-c35d-42fb-9610-5ef3e53dfd59@github.com>
Message-ID: <0JxsEwPD_Nj6gbPzkr64R_WdzI_NTsaB3Zt22llxErw=.606c9b26-cd53-4a11-9c30-2d2c080d72ae@github.com>

On Tue, 27 Feb 2024 13:06:57 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> > Nit: Copyright year of IterationCount.java would need to be changed.
> 
> That is a Red Hat copyright; should I add an Oracle copyright? The file isn't significantly changed.

AFAIK, no need to update with Oracle copyright for this update.

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

PR Comment: https://git.openjdk.org/jdk/pull/17877#issuecomment-1969553879


From mdonovan at openjdk.org  Thu Feb 29 12:10:56 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 29 Feb 2024 12:10:56 GMT
Subject: Integrated: 8319673: Few security tests ignore VM flags
In-Reply-To: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
References: <e8IOHz-DPh1CuKlGG3hiaJrSwBkIdstqpGaw3YMGM5U=.a46d8638-8cef-4385-880f-65531f9af6ef@github.com>
Message-ID: <nIH93z3X2P3WKrJPLZ4IUPQ3IlgIGyjxZUSLjkfJ3sk=.6c49777b-b8ed-4319-b4f9-f20e10af9e88@github.com>

On Thu, 15 Feb 2024 17:05:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder() methods to launch child processes. This method ensures that VM options are passed to subprocesses.

This pull request has now been integrated.

Changeset: 43029006
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/430290066c23d09166a84f2f6f89e770c6ba04ff
Stats:     49 lines in 3 files changed: 12 ins; 13 del; 24 mod

8319673: Few security tests ignore VM flags

Reviewed-by: weijun, hchao

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

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