From xuelei at openjdk.org Mon May 1 07:41:23 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 1 May 2023 07:41:23 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v3] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 28 Apr 2023 19:15:59 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java > > Co-authored-by: Daniel Jelinski There are two blocks called CertificateAuthoritiesSpec.getAuthorities(). Another call is in the CRCertificateAuthoritiesConsumer inner class. Did you check if both should be updated? Or Is it possible to update the getAuthorities() implementation directly? There are similar code in CertificateRequest. Did you have a chance to look at if it is impacted as well? Basically, the issue is caused by the X500Principal constructor with DER bytes. It may be good to check the call to the constructor and handle the IAE accordingly as well, for example in the CertificateAuthoritiesSpec.toString() method. ------------- Changes requested by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1407415460 From mullan at openjdk.org Mon May 1 15:37:54 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 1 May 2023 15:37:54 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver wrote: > Fix type-o and update returns message. src/java.base/share/classes/java/security/Security.java line 705: > 703: * @param key the key of the property being retrieved. > 704: * > 705: * @return the string value of the security property, or null if there I don't think saying "string" is necessary - since this method can only return a String. Put "null" in code syntax: {@code null}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13729#discussion_r1181655614 From mullan at openjdk.org Mon May 1 17:54:52 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 1 May 2023 17:54:52 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v3] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 28 Apr 2023 19:15:59 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java > > Co-authored-by: Daniel Jelinski Yes, I think we should check other calls in the TLS code to `new X500Principal()` that take the encoded bytes from the network to see if similar changes are needed. I would also pass the cause to the `fatal()` method as this will provide additional information as to the reason of the parsing failure for debugging purposes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1529997195 From duke at openjdk.org Mon May 1 17:55:59 2023 From: duke at openjdk.org (Matthew Donovan) Date: Mon, 1 May 2023 17:55:59 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException Message-ID: In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. Thanks ------------- Commit messages: - 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException Changes: https://git.openjdk.org/jdk/pull/13742/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290005 Stats: 82 lines in 3 files changed: 51 ins; 20 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13742.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13742/head:pull/13742 PR: https://git.openjdk.org/jdk/pull/13742 From mullan at openjdk.org Mon May 1 18:30:18 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 1 May 2023 18:30:18 GMT Subject: RFR: 8304760: Add 2 Microsoft TLS roots In-Reply-To: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com> References: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com> Message-ID: On Fri, 28 Apr 2023 19:04:20 GMT, Rajan Halade wrote: > This PR is to add two new TLS root certificates from Microsoft. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process. > > The release-note is at [JDK-8307129](https://bugs.openjdk.org/browse/JDK-8307129) Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13726#pullrequestreview-1407896625 From rhalade at openjdk.org Mon May 1 18:30:26 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Mon, 1 May 2023 18:30:26 GMT Subject: Integrated: 8304760: Add 2 Microsoft TLS roots In-Reply-To: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com> References: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com> Message-ID: On Fri, 28 Apr 2023 19:04:20 GMT, Rajan Halade wrote: > This PR is to add two new TLS root certificates from Microsoft. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process. > > The release-note is at [JDK-8307129](https://bugs.openjdk.org/browse/JDK-8307129) This pull request has now been integrated. Changeset: c7e1df83 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/c7e1df832837c2f19629cf0d5a5d3e65142ac208 Stats: 417 lines in 4 files changed: 414 ins; 0 del; 3 mod 8304760: Add 2 Microsoft TLS roots Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/13726 From cslucas at openjdk.org Mon May 1 18:41:26 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 1 May 2023 18:41:26 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v11] In-Reply-To: <6I1KVkFSekhMTTDq6nXQNoKPE96bycERRtsPrTnZZvU=.c1933f7f-e659-4e22-93a3-e7fbbcdf53a1@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6I1KVkFSekhMTTDq6nXQNoKPE96bycERRtsPrTnZZvU=.c1933f7f-e659-4e22-93a3-e7fbbcdf53a1@github.com> Message-ID: On Wed, 26 Apr 2023 17:28:53 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Address part of PR review 4 & fix a bug setting only_candidate I have an update to this PR to make it possible to scalar replace allocations when the Phi is used in a CmpP (not for all cases). Is there any objection to me pushing these changes? I.e., will it complicate any ongoing review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1530047937 From cslucas at openjdk.org Mon May 1 18:41:33 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 1 May 2023 18:41:33 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v10] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 27 Apr 2023 23:36:06 GMT, Vladimir Ivanov wrote: >> Can `ObjectCandidateValue` be a wrapper around a `ObjectAllocationValue`? >> >> It does make sense to separate `ObjectMergeValue` and `ObjectValue`. > > I need to to study the code in more details. Seems like I'm missing something important here. @iwanowww - how can I make it easier for you to review? Thanks for your comments so far. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1181781323 From valeriep at openjdk.org Mon May 1 19:55:38 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 1 May 2023 19:55:38 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries Message-ID: Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. Thanks, Valerie ------------- Commit messages: - JDK-8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries Changes: https://git.openjdk.org/jdk/pull/13743/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13743&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301154 Stats: 405 lines in 7 files changed: 327 ins; 45 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/13743.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13743/head:pull/13743 PR: https://git.openjdk.org/jdk/pull/13743 From cslucas at openjdk.org Mon May 1 20:20:51 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 1 May 2023 20:20:51 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address part of PR review 4 & fix a bug setting only_candidate - Catching up with master Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Fix tests. Remember previous reducible Phis. - Address PR review 3. Some comments and be able to abort compilation. - Merge with Master - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. - Add support for SR'ing some inputs of merges used for field loads - Fix some typos and do some small refactorings. - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=11 Stats: 2250 lines in 26 files changed: 1990 ins; 108 del; 152 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From valeriep at openjdk.org Mon May 1 21:24:21 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 1 May 2023 21:24:21 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver wrote: > Fix type-o and update returns message. src/java.base/share/classes/java/security/Security.java line 2: > 1: /* > 2: * Copyright (c) 1996, 2022, 2023, Oracle and/or its affiliates. All rights reserved. Seems incorrect to have 3 copyright years. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13729#discussion_r1181902336 From wetmore at openjdk.org Tue May 2 00:26:16 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 2 May 2023 00:26:16 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty In-Reply-To: References: Message-ID: On Mon, 1 May 2023 21:21:15 GMT, Valerie Peng wrote: >> Fix type-o and update returns message. > > src/java.base/share/classes/java/security/Security.java line 2: > >> 1: /* >> 2: * Copyright (c) 1996, 2022, 2023, Oracle and/or its affiliates. All rights reserved. > > Seems incorrect to have 3 copyright years. Correct, only the beginning and current year. `1996, 2023, Oracle...` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13729#discussion_r1181986205 From duke at openjdk.org Tue May 2 12:42:23 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 2 May 2023 12:42:23 GMT Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate In-Reply-To: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> Message-ID: <5bVEilLvrpWw22GYRX_9FBWdhk3tTbh4MGF_h-F5e-Q=.59ccfe4d-6b3b-4e2e-b41d-00d1aeac6b3c@github.com> On Mon, 17 Apr 2023 13:25:53 GMT, Matthew Donovan wrote: > I refactored tests in the test/jdk/javax/net/ssl directories to use the test template classes. Could someone please review this PR? This directly related to https://github.com/openjdk/jdk/pull/13495 as well. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13494#issuecomment-1531407356 From dfuchs at openjdk.org Tue May 2 13:01:21 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 2 May 2023 13:01:21 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException In-Reply-To: References: Message-ID: <5kB-OiJcwWcZcEZ209M3HwTsuychO6nWIrTCy5i1SQ0=.194f00b0-419b-4b2c-adb8-32900d2afcc1@github.com> On Mon, 1 May 2023 17:39:02 GMT, Matthew Donovan wrote: > In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. > > Thanks src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 767: > 765: if (context != null && // PRE or POST handshake > 766: !conContext.handshakeContext.taskDelegated && > 767: !conContext.handshakeContext.delegatedActions.isEmpty()) { Shouldn't you replace `conContext.handshakeContext` with `context` in those two lines as well? src/java.base/share/classes/sun/security/ssl/TransportContext.java line 461: > 459: handshakeCtxLock.lock(); > 460: handshakeContext = null; > 461: handshakeCtxLock.unlock(); The usual pattern is to use try { } finally { } with locks (even though in this particular case I don't see how the assignment would throw) - but if more things need to be done in the future here then at least the try { } finally { } will be in place. Suggestion: handshakeCtxLock.lock(); try { handshakeContext = null; } finally { handshakeCtxLock.unlock(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182510718 PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182510815 From xuelei at openjdk.org Tue May 2 13:46:21 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 2 May 2023 13:46:21 GMT Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate In-Reply-To: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> Message-ID: On Mon, 17 Apr 2023 13:25:53 GMT, Matthew Donovan wrote: > I refactored tests in the test/jdk/javax/net/ssl directories to use the test template classes. Looks good to me. The checks are not fully passed. Please double check if the failures are related to this update. ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13494#pullrequestreview-1409133989 PR Comment: https://git.openjdk.org/jdk/pull/13494#issuecomment-1531504915 From duke at openjdk.org Tue May 2 13:55:18 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 2 May 2023 13:55:18 GMT Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate In-Reply-To: References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> Message-ID: On Tue, 2 May 2023 13:43:52 GMT, Xue-Lei Andrew Fan wrote: > The checks are not fully passed. Please double check if the failures are related to this update. They are unrelated to these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13494#issuecomment-1531517933 From duke at openjdk.org Tue May 2 14:31:38 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 2 May 2023 14:31:38 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v2] In-Reply-To: References: Message-ID: <-2C5OXMu_wztFlkIwH9UPyUpLaOZMVycbBtmSxwJdGs=.c7858621-fc8d-4d2c-8428-37838c9f65d5@github.com> > In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. > > Thanks Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: using try/finally in terminateHandshakeContext and using local context variable in all places it should be ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13742/files - new: https://git.openjdk.org/jdk/pull/13742/files/fe2604aa..ce88caa0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=00-01 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13742.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13742/head:pull/13742 PR: https://git.openjdk.org/jdk/pull/13742 From duke at openjdk.org Tue May 2 14:31:40 2023 From: duke at openjdk.org (Matthew Donovan) Date: Tue, 2 May 2023 14:31:40 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v2] In-Reply-To: <5kB-OiJcwWcZcEZ209M3HwTsuychO6nWIrTCy5i1SQ0=.194f00b0-419b-4b2c-adb8-32900d2afcc1@github.com> References: <5kB-OiJcwWcZcEZ209M3HwTsuychO6nWIrTCy5i1SQ0=.194f00b0-419b-4b2c-adb8-32900d2afcc1@github.com> Message-ID: On Tue, 2 May 2023 12:56:38 GMT, Daniel Fuchs wrote: >> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: >> >> using try/finally in terminateHandshakeContext and using local context variable in all places it should be > > src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 767: > >> 765: if (context != null && // PRE or POST handshake >> 766: !conContext.handshakeContext.taskDelegated && >> 767: !conContext.handshakeContext.delegatedActions.isEmpty()) { > > Shouldn't you replace `conContext.handshakeContext` with `context` in those two lines as well? Yes, I definitely should have done that. Thanks. > src/java.base/share/classes/sun/security/ssl/TransportContext.java line 461: > >> 459: handshakeCtxLock.lock(); >> 460: handshakeContext = null; >> 461: handshakeCtxLock.unlock(); > > The usual pattern is to use try { } finally { } with locks (even though in this particular case I don't see how the assignment would throw) - but if more things need to be done in the future here then at least the try { } finally { } will be in place. > > Suggestion: > > handshakeCtxLock.lock(); > try { > handshakeContext = null; > } finally { > handshakeCtxLock.unlock(); > } I added the try/finally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182625725 PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182626923 From dfuchs at openjdk.org Tue May 2 14:32:10 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 2 May 2023 14:32:10 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v2] In-Reply-To: <-2C5OXMu_wztFlkIwH9UPyUpLaOZMVycbBtmSxwJdGs=.c7858621-fc8d-4d2c-8428-37838c9f65d5@github.com> References: <-2C5OXMu_wztFlkIwH9UPyUpLaOZMVycbBtmSxwJdGs=.c7858621-fc8d-4d2c-8428-37838c9f65d5@github.com> Message-ID: On Tue, 2 May 2023 14:31:38 GMT, Matthew Donovan wrote: >> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. >> >> Thanks > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > using try/finally in terminateHandshakeContext and using local context variable in all places it should be src/java.base/share/classes/sun/security/ssl/TransportContext.java line 91: > 89: // handshake context > 90: HandshakeContext handshakeContext = null; > 91: Lock handshakeCtxLock = new ReentrantLock(); `handshakeCtxLock` should be declared final. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182634866 From jiangli at openjdk.org Tue May 2 16:41:25 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 16:41:25 GMT Subject: RFR: 8307134: Add GTS root CAs Message-ID: This PR was requested by awarner at google.com. The updates are provided by awarner at google.com. ------------- Commit messages: - Merge branch 'master' into JDK-8307134 - 8307134: Add GTS root CAs Changes: https://git.openjdk.org/jdk/pull/13754/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307134 Stats: 140 lines in 6 files changed: 124 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13754/head:pull/13754 PR: https://git.openjdk.org/jdk/pull/13754 From mullan at openjdk.org Tue May 2 17:28:16 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 2 May 2023 17:28:16 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: References: Message-ID: On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou wrote: > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. Ideally, an infra test for testing test certs should also be added. @rhalade may be able to contribute this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531864022 From rhalade at openjdk.org Tue May 2 17:32:14 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 2 May 2023 17:32:14 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: References: Message-ID: On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou wrote: > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1 src/java.base/share/data/cacerts/globalsigneccrootcar4 line 3: > 1: Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 > 2: Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 > 3: Serial number: 203e57ef53f93fda50921b2a6 Why is this certificate changed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531868773 PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1182843649 From weijun at openjdk.org Tue May 2 17:54:31 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 May 2023 17:54:31 GMT Subject: RFR: 8297878: KEM: Implementation [v13] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: providerName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/51be3375..c2daf4e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=11-12 Stats: 13 lines in 2 files changed: 1 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From weijun at openjdk.org Tue May 2 17:55:30 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 May 2023 17:55:30 GMT Subject: RFR: 8297878: KEM: Implementation [v12] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 15:40:53 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more @since and about nulls New commit pushed. `s/provider/providerName/`. Now we can claim the `Encapsulator` and `Decapsulator` classes are immutable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13256#issuecomment-1531899641 From jiangli at openjdk.org Tue May 2 17:56:18 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 17:56:18 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:29:07 GMT, Rajan Halade wrote: >> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. > >> > > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1 > Ideally, an infra test for testing test certs should also be added. @rhalade may be able to contribute this. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531899677 From jiangli at openjdk.org Tue May 2 18:39:15 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 18:39:15 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:29:07 GMT, Rajan Halade wrote: > > > > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1 @rhalade, thanks! I have a minor comment below for your test/jdk/security/infra/java/security/cert/CertPathValidator/certification/GoogleCA.java test. I'll defer to @awarner at google.com for detailed review, as I don't have much context. Please fix the bug id, `8303394`: /* * @test * @bug 8303394 * @summary Interoperability tests with Google's GlobalSign R4 and GTS Root certificates ... Could you please also let me know your plan on committing the GoogleCA.java? Do you plan to create a PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531961102 From rhalade at openjdk.org Tue May 2 18:45:14 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 2 May 2023 18:45:14 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: References: Message-ID: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou wrote: > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. > > > > > > > > > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1 > > @rhalade, thanks! I have a minor comment below for your test/jdk/security/infra/java/security/cert/CertPathValidator/certification/GoogleCA.java test. I'll defer to @[awarner at google.com](mailto:awarner at google.com) for detailed review, as I don't have much context. > > Please fix the bug id, `8303394`: > > ``` > /* > * @test > * @bug 8303394 > * @summary Interoperability tests with Google's GlobalSign R4 and GTS Root certificates > ... > ``` > > Could you please also let me know your plan on committing the GoogleCA.java? Do you plan to create a PR? You can include this contribution in your PR. Then it will be easier to backport to JDK 20u as one changeset. I updated bug id in the changeset. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531972274 From duke at openjdk.org Tue May 2 19:02:22 2023 From: duke at openjdk.org (Andy Warner) Date: Tue, 2 May 2023 19:02:22 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> References: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> Message-ID: On Tue, 2 May 2023 18:42:36 GMT, Rajan Halade wrote: > > > > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1 Aside from the bug number @jianglizhou raised, the interop tests look good to me. > src/java.base/share/data/cacerts/globalsigneccrootcar4 line 3: > >> 1: Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 >> 2: Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 >> 3: Serial number: 203e57ef53f93fda50921b2a6 > > Why is this certificate changed? The original R4 did not have the digitalSignature keyUsage set. This root signs OCSP responses, so it needed to be reissued to comply with section 7.1.2.1 of the CA/B Forum baseline requirements. The only change between the two versions aside from the serial number is the addition of the digitalSignature key usage bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531995277 PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1182931200 From mpowers at openjdk.org Tue May 2 19:22:15 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 2 May 2023 19:22:15 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng wrote: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie The changes LGTM. Your comments helped a lot. ------------- PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1409744045 From duke at openjdk.org Tue May 2 20:39:21 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:39:21 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v3] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: addressing more review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/d1e1763c..21018dd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=01-02 Stats: 40 lines in 3 files changed: 22 ins; 7 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From duke at openjdk.org Tue May 2 20:39:30 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:39:30 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: <_0_M2Qo1v6mk0HjUPr0oOHMAurij6E0amCiF_1Pldr4=.3f590478-73e9-4180-a7b0-fae5e48f8f73@github.com> On Fri, 28 Apr 2023 19:54:42 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 423: >> >>> 421: >>> 422: default: >>> 423: throw new IllegalArgumentException("Unsupported or bad LMS type"); >> >> Could this be `InvalidParameterException` instead? > > Or should it be a `InvalidKeyException` if the method is called when creating a public key? > > Anyway, we need to make sure the correct exceptions are thrown in public APIs. This needs a lot of tests. I have caught this at the call sites and converted it to the relevant exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024501 From duke at openjdk.org Tue May 2 20:39:23 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:39:23 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v3] In-Reply-To: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com> References: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com> Message-ID: On Thu, 27 Apr 2023 17:39:14 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing more review comments > > src/java.base/share/classes/sun/security/provider/HSS.java line 66: > >> 64: if (!(publicKey instanceof HSSPublicKey pub)) { >> 65: throw new InvalidKeyException("Not an HSS public key: "); >> 66: } > > If not, we can try translating it using our `KeyFactory`. Done > src/java.base/share/classes/sun/security/provider/HSS.java line 758: > >> 756: if (key instanceof HSSPublicKey) { >> 757: return key; >> 758: } > > We need to be able to translate other HSS/LMS public keys into our own type as long as the algorithm and format are OK. > > You can try this out by duplicating your implementation with a different provider name in a different package. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183022892 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023531 From duke at openjdk.org Tue May 2 20:39:32 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:39:32 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v3] In-Reply-To: <9RRITm9kBt_cSdt_NMnOJoWpJ83acPy0Xnof8Ss7y9g=.4b23380d-1886-4925-aa8b-42ba63590045@github.com> References: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com> <9RRITm9kBt_cSdt_NMnOJoWpJ83acPy0Xnof8Ss7y9g=.4b23380d-1886-4925-aa8b-42ba63590045@github.com> Message-ID: On Fri, 28 Apr 2023 13:38:41 GMT, Weijun Wang wrote: >> I need it now, with the addWithAlias() change. > > `addWithAlias` search for an OID by its name using the `KnownOIDs` class. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023787 From duke at openjdk.org Tue May 2 20:39:30 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:39:30 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 13:52:30 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments addressed > > src/java.base/share/classes/sun/security/provider/HSS.java line 86: > >> 84: lmsPubKey = sig.pubList[i]; >> 85: } >> 86: return result & lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); > > You should probably reset `messageStream` so that it can be called in another `update/verify` sequence. This is also worth a test. Added. > src/java.base/share/classes/sun/security/provider/HSS.java line 173: > >> 171: int m = lmParams.m; >> 172: if ((inLen < (24 + m)) || (checkExactLength && (inLen != (24 + m))) || >> 173: !LMOTSParams.of(otsType).hashAlgName.equals(lmParams.hashAlgStr)) { > > This algorithm name comparison is not sufficient. You are using "SHA-256" for both M32 and M24 types. Either add a comparison on `LMParams.m` and `LMOTSParams.n`, or use "SHA-256/192" as the hash algorithm name. Changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 213: > >> 211: >> 212: static class LMSUtils { >> 213: public final static int LMS_RESERVED = 0; > > Is the `LMS_RESERVED` and `LMOTS_RESERVED` constants used anywhere? No, but they are defined in the standard so it seemed to be a good idea to document that this way. > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 274: > >> 272: store("DSA", KnownOIDs.DSA, KnownOIDs.OIW_DSA.value()); >> 273: >> 274: store("HSS/LMS", KnownOIDs.HSSLMS, KnownOIDs.HSSLMS.value()); > > This is only necessary if an non-OID alias is needed. For example, if we want to use "LMS" as an alias of "HSS/LMS". Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024118 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024398 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024209 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023989 From duke at openjdk.org Tue May 2 20:39:24 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:39:24 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v3] In-Reply-To: References: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com> Message-ID: On Tue, 2 May 2023 20:32:02 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 66: >> >>> 64: if (!(publicKey instanceof HSSPublicKey pub)) { >>> 65: throw new InvalidKeyException("Not an HSS public key: "); >>> 66: } >> >> If not, we can try translating it using our `KeyFactory`. > > Done Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023311 From jiangli at openjdk.org Tue May 2 20:43:31 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 20:43:31 GMT Subject: RFR: 8307134: Add GTS root CAs [v2] In-Reply-To: References: Message-ID: > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add GoogleCA.java test from @rhalade. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13754/files - new: https://git.openjdk.org/jdk/pull/13754/files/caedc4ed..37538f53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=00-01 Stats: 621 lines in 1 file changed: 621 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13754/head:pull/13754 PR: https://git.openjdk.org/jdk/pull/13754 From jiangli at openjdk.org Tue May 2 20:43:31 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 20:43:31 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> References: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> Message-ID: On Tue, 2 May 2023 18:42:36 GMT, Rajan Halade wrote: > You can include this contribution in your PR. Then it will be easier to backport to JDK 20u as one changeset. I updated bug id in the changeset. Done. Please double check. I ran the GoogleCA.java test with a test JDK binary built with this PR changes included. The test passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1532118040 From mullan at openjdk.org Tue May 2 20:43:32 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 2 May 2023 20:43:32 GMT Subject: RFR: 8307134: Add GTS root CAs [v2] In-Reply-To: References: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> Message-ID: <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com> On Tue, 2 May 2023 18:51:52 GMT, Andy Warner wrote: >> src/java.base/share/data/cacerts/globalsigneccrootcar4 line 3: >> >>> 1: Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 >>> 2: Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 >>> 3: Serial number: 203e57ef53f93fda50921b2a6 >> >> Why is this certificate changed? > > The original R4 did not have the digitalSignature keyUsage set. This root signs OCSP responses, so it needed to be reissued to comply with section 7.1.2.1 of the CA/B Forum baseline requirements. The only change between the two versions aside from the serial number is the addition of the digitalSignature key usage bit. Thanks for the explanation. Please file a different issue for this change, since it is outside the scope of this issue, which is to specifically add new roots that have been approved by the Java SE CA Root Program processes. Updated roots, even for small changes such as this, should be handled and approved using an equivalent process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1183027007 From duke at openjdk.org Tue May 2 20:44:27 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 20:44:27 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v4] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: addressing more review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/21018dd6..a3f809ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From weijun at openjdk.org Tue May 2 20:53:14 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 May 2023 20:53:14 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v4] In-Reply-To: References: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com> Message-ID: On Tue, 2 May 2023 20:32:33 GMT, Ferenc Rakoczi wrote: >> Done > > Done. Where? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183036679 From weijun at openjdk.org Tue May 2 20:53:19 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 May 2023 20:53:19 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v4] In-Reply-To: References: Message-ID: <4X51Yc_hE2AQwJWiO5oMG5yUz233j0ekvRtbHZ2lmvo=.fdc0f895-e169-478e-a4ff-72b5c42484b3@github.com> On Tue, 2 May 2023 20:44:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > addressing more review comments src/java.base/share/classes/sun/security/provider/HSS.java line 91: > 89: return result; > 90: } catch (Exception e) { > 91: messageStream.reset(); You can put this line in a `finally` block. src/java.base/share/classes/sun/security/provider/HSS.java line 585: > 583: params = new LMOTSParams(lmotsType, 32, 8, 0, 34, "SHA-256"); > 584: break; > 585: case LMSUtils.LMOTS_SHA256_N24_W1: Since you commented out the LMS constants for SHA-256/192. Do you want to do the same here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183034005 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183037689 From weijun at openjdk.org Tue May 2 20:53:22 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 May 2023 20:53:22 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 20:33:40 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 213: >> >>> 211: >>> 212: static class LMSUtils { >>> 213: public final static int LMS_RESERVED = 0; >> >> Is the `LMS_RESERVED` and `LMOTS_RESERVED` constants used anywhere? > > No, but they are defined in the standard so it seemed to be a good idea to document that this way. OK. No problem then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183036991 From jiangli at openjdk.org Tue May 2 21:00:04 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 21:00:04 GMT Subject: RFR: 8307134: Add GTS root CAs [v3] In-Reply-To: References: Message-ID: > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Revert the src/java.base/share/data/cacerts/globalsigneccrootcar4 change. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13754/files - new: https://git.openjdk.org/jdk/pull/13754/files/37538f53..3abe98b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=01-02 Stats: 12 lines in 1 file changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13754/head:pull/13754 PR: https://git.openjdk.org/jdk/pull/13754 From jiangli at openjdk.org Tue May 2 21:14:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 21:14:17 GMT Subject: RFR: 8307134: Add GTS root CAs [v3] In-Reply-To: <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com> References: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com> Message-ID: On Tue, 2 May 2023 20:36:57 GMT, Sean Mullan wrote: >> The original R4 did not have the digitalSignature keyUsage set. This root signs OCSP responses, so it needed to be reissued to comply with section 7.1.2.1 of the CA/B Forum baseline requirements. The only change between the two versions aside from the serial number is the addition of the digitalSignature key usage bit. > > Thanks for the explanation. Please file a different issue for this change, since it is outside the scope of this issue, which is to specifically add new roots that have been approved by the Java SE CA Root Program processes. Updated roots, even for small changes such as this, should be handled and approved using an equivalent process. Reverted src/java.base/share/data/cacerts/globalsigneccrootcar4 in this PR. Looks like the update for "globalsigneccrootcar4 [jdk]" in test/jdk/sun/security/lib/cacerts/VerifyCACerts.java also needs to be reverted, otherwise the test fails with the following error. I'll go ahead and revert that as well. ERROR: wrong checksum72:03:89:C2:7B:BF:87:87:E1:65:44:6E:43:5C:65:FF:B5:E8:F9:4C:8A:D1:63:6D:D1:91:4C:AD:1C:9A:CB:3B Expected checksum23:6E:7A:1C:37:AD:82:31:FD:32:E8:31:63:4B:1A:88:BA:1A:4D:F6:D3:91:CD:0F:B4:09:EC:55:9A:B2:01:51 ERROR: globalsigneccrootcar4 [jdk] SHA-256 fingerprint is incorrect java.lang.RuntimeException: At least one cacert test failed at VerifyCACerts.main(VerifyCACerts.java:380) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1592) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1183055459 From jiangli at openjdk.org Tue May 2 21:27:18 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 21:27:18 GMT Subject: RFR: 8307134: Add GTS root CAs [v4] In-Reply-To: References: Message-ID: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com> > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/sun/security/lib/cacerts/VerifyCACerts.java after reverting src/java.base/share/data/cacerts/globalsigneccrootcar4. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13754/files - new: https://git.openjdk.org/jdk/pull/13754/files/3abe98b2..ffc80326 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13754&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13754/head:pull/13754 PR: https://git.openjdk.org/jdk/pull/13754 From duke at openjdk.org Tue May 2 21:29:20 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 21:29:20 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v4] In-Reply-To: <4X51Yc_hE2AQwJWiO5oMG5yUz233j0ekvRtbHZ2lmvo=.fdc0f895-e169-478e-a4ff-72b5c42484b3@github.com> References: <4X51Yc_hE2AQwJWiO5oMG5yUz233j0ekvRtbHZ2lmvo=.fdc0f895-e169-478e-a4ff-72b5c42484b3@github.com> Message-ID: On Tue, 2 May 2023 20:45:38 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> addressing more review comments > > src/java.base/share/classes/sun/security/provider/HSS.java line 91: > >> 89: return result; >> 90: } catch (Exception e) { >> 91: messageStream.reset(); > > You can put this line in a `finally` block. OK. > src/java.base/share/classes/sun/security/provider/HSS.java line 585: > >> 583: params = new LMOTSParams(lmotsType, 32, 8, 0, 34, "SHA-256"); >> 584: break; >> 585: case LMSUtils.LMOTS_SHA256_N24_W1: > > Since you commented out the LMS constants for SHA-256/192. Do you want to do the same here? Oops... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183066920 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183067244 From jiangli at openjdk.org Tue May 2 21:41:19 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 2 May 2023 21:41:19 GMT Subject: RFR: 8307134: Add GTS root CAs [v4] In-Reply-To: References: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com> Message-ID: <8Q2gWi9Z-962OZbespxRsn3hhDn_Jr7P47WRydcWFuM=.b159256a-2789-4209-b8c1-cf0d575bc3b3@github.com> On Tue, 2 May 2023 21:11:09 GMT, Jiangli Zhou wrote: >> Thanks for the explanation. Please file a different issue for this change, since it is outside the scope of this issue, which is to specifically add new roots that have been approved by the Java SE CA Root Program processes. Updated roots, even for small changes such as this, should be handled and approved using an equivalent process. > > Reverted src/java.base/share/data/cacerts/globalsigneccrootcar4 in this PR. Looks like the update for "globalsigneccrootcar4 [jdk]" in test/jdk/sun/security/lib/cacerts/VerifyCACerts.java also needs to be reverted, otherwise the test fails with the following error. I'll go ahead and revert that as well. > > > ERROR: wrong checksum72:03:89:C2:7B:BF:87:87:E1:65:44:6E:43:5C:65:FF:B5:E8:F9:4C:8A:D1:63:6D:D1:91:4C:AD:1C:9A:CB:3B > Expected checksum23:6E:7A:1C:37:AD:82:31:FD:32:E8:31:63:4B:1A:88:BA:1A:4D:F6:D3:91:CD:0F:B4:09:EC:55:9A:B2:01:51 > ERROR: globalsigneccrootcar4 [jdk] SHA-256 fingerprint is incorrect > java.lang.RuntimeException: At least one cacert test failed > at VerifyCACerts.main(VerifyCACerts.java:380) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1592) Done. Also updated 'CHECKSUM' value in test/jdk/sun/security/lib/cacerts/VerifyCACerts.java reflectively. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1183075098 From duke at openjdk.org Tue May 2 21:43:20 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 21:43:20 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com> Message-ID: <9DlF2lt1GkdjkvapVg5yTno5ALNRUK8Dz5o4b5NjhGA=.47d4107f-e017-40ef-a1e8-62e022a2cbb3@github.com> On Tue, 2 May 2023 20:48:37 GMT, Weijun Wang wrote: >> Done. > > Where? Done now. Sorry about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183075152 From duke at openjdk.org Tue May 2 21:43:19 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 2 May 2023 21:43:19 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: adding key translation, finally block, removing 24-byte LMOTS parameters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/a3f809ef..b546fdf0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=03-04 Stats: 13 lines in 1 file changed: 8 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From jnimeh at openjdk.org Tue May 2 21:55:19 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 2 May 2023 21:55:19 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts Message-ID: This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). JBS: https://bugs.openjdk.org/browse/JDK-8179502 CSR: https://bugs.openjdk.org/browse/JDK-8300722 ------------- Commit messages: - Fix more whitespace errors - Fix whitespace errors - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts Changes: https://git.openjdk.org/jdk/pull/13762/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8179502 Stats: 873 lines in 7 files changed: 759 ins; 27 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/13762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762 PR: https://git.openjdk.org/jdk/pull/13762 From weijun at openjdk.org Tue May 2 22:36:15 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 May 2023 22:36:15 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:12:31 GMT, Jamil Nimeh wrote: > This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. > > This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). > > JBS: https://bugs.openjdk.org/browse/JDK-8179502 > CSR: https://bugs.openjdk.org/browse/JDK-8300722 src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 192: > 190: > 191: // Determine if "ms" is on the end of the string > 192: boolean isMillis = propVal.toLowerCase().endsWith("ms"); Shall we allow the `s` suffix as well? This makes it clear that a value is in seconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183107810 From jnimeh at openjdk.org Tue May 2 23:23:17 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 2 May 2023 23:23:17 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts In-Reply-To: References: Message-ID: On Tue, 2 May 2023 22:33:47 GMT, Weijun Wang wrote: >> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. >> >> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). >> >> JBS: https://bugs.openjdk.org/browse/JDK-8179502 >> CSR: https://bugs.openjdk.org/browse/JDK-8300722 > > src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 192: > >> 190: >> 191: // Determine if "ms" is on the end of the string >> 192: boolean isMillis = propVal.toLowerCase().endsWith("ms"); > > Shall we allow the `s` suffix as well? This makes it clear that a value is in seconds. Well, all the existing documentation already states that they are in seconds. That was why I didn't add any additional suffixes. The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183129362 From weijun at openjdk.org Wed May 3 00:30:14 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 3 May 2023 00:30:14 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts In-Reply-To: References: Message-ID: On Tue, 2 May 2023 23:20:20 GMT, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 192: >> >>> 190: >>> 191: // Determine if "ms" is on the end of the string >>> 192: boolean isMillis = propVal.toLowerCase().endsWith("ms"); >> >> Shall we allow the `s` suffix as well? This makes it clear that a value is in seconds. > > Well, all the existing documentation already states that they are in seconds. That was why I didn't add any additional suffixes. The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them. I don't mean not to support bare numbers. It's just a little unfair that millisecond has a suffix but second does not. We can support all of "1", "1s", and "1000ms". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183156016 From wetmore at openjdk.org Wed May 3 00:50:15 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 3 May 2023 00:50:15 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver wrote: > Fix type-o and update returns message. I agree with Sean/Valerie's comments. Otherwise, LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13729#pullrequestreview-1410050561 From jnimeh at openjdk.org Wed May 3 03:39:12 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 3 May 2023 03:39:12 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts In-Reply-To: References: Message-ID: On Wed, 3 May 2023 00:27:55 GMT, Weijun Wang wrote: >> Well, all the existing documentation already states that they are in seconds. That was why I didn't add any additional suffixes. The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them. > > I don't mean not to support bare numbers. It's just a little unfair that millisecond has a suffix but second does not. We can support all of "1", "1s", and "1000ms". Okay, we can make that change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183212032 From ssahoo at openjdk.org Wed May 3 09:43:40 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Wed, 3 May 2023 09:43:40 GMT Subject: RFR: 8297878: KEM: Implementation [v12] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 15:40:53 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more @since and about nulls test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 97: > 95: // Cannot detect invalid params before provider selection > 96: // Utils.runAndCheckException( > 97: // () -> KEM.getInstance("DHKEM", new KEMParameterSpec() {}), Commented code block can be removed. Signature of getInstance() doesn't exist. test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 112: > 110: ExChecker.of(InvalidKeyException.class).by(DHKEM.class)); > 111: > 112: // Not an EC key at all, rejected by framework coz SupportedClasses Do you mean UnsupportedClasses in comment section? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183247590 PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183269537 From duke at openjdk.org Wed May 3 11:26:32 2023 From: duke at openjdk.org (Matthew Donovan) Date: Wed, 3 May 2023 11:26:32 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v3] In-Reply-To: References: Message-ID: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> > In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. > > Thanks Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: made handshake context lock final ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13742/files - new: https://git.openjdk.org/jdk/pull/13742/files/ce88caa0..92a48a70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13742.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13742/head:pull/13742 PR: https://git.openjdk.org/jdk/pull/13742 From weijun at openjdk.org Wed May 3 12:43:31 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 3 May 2023 12:43:31 GMT Subject: RFR: 8297878: KEM: Implementation [v12] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 05:22:04 GMT, Sibabrata Sahoo wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more @since and about nulls > > test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 97: > >> 95: // Cannot detect invalid params before provider selection >> 96: // Utils.runAndCheckException( >> 97: // () -> KEM.getInstance("DHKEM", new KEMParameterSpec() {}), > > Commented code block can be removed. Signature of getInstance() doesn't exist. Oops. Will remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183631427 From weijun at openjdk.org Wed May 3 12:50:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 3 May 2023 12:50:40 GMT Subject: RFR: 8297878: KEM: Implementation [v14] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: Resolve Siba's comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/c2daf4e3..c9f1d8f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=12-13 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From weijun at openjdk.org Wed May 3 12:50:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 3 May 2023 12:50:40 GMT Subject: RFR: 8297878: KEM: Implementation [v12] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 06:04:51 GMT, Sibabrata Sahoo wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more @since and about nulls > > test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 112: > >> 110: ExChecker.of(InvalidKeyException.class).by(DHKEM.class)); >> 111: >> 112: // Not an EC key at all, rejected by framework coz SupportedClasses > > Do you mean UnsupportedClasses in comment section? I meant the "SupportedKeyClasses" attribute in `SunJCE.java`. Will fix the word. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183635243 From dfuchs at openjdk.org Wed May 3 12:56:16 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 3 May 2023 12:56:16 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v3] In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> Message-ID: On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan wrote: >> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. >> >> Thanks > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > made handshake context lock final LGTM. You will need approval from a security-dev Reviewer before pushing though. ------------- PR Review: https://git.openjdk.org/jdk/pull/13742#pullrequestreview-1410830133 From mullan at openjdk.org Wed May 3 13:14:19 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 May 2023 13:14:19 GMT Subject: RFR: 8307134: Add GTS root CAs [v4] In-Reply-To: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com> References: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com> Message-ID: On Tue, 2 May 2023 21:27:18 GMT, Jiangli Zhou wrote: >> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/sun/security/lib/cacerts/VerifyCACerts.java after reverting src/java.base/share/data/cacerts/globalsigneccrootcar4. Looks good. Please also wait for approval from @rhalade before integrating. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13754#pullrequestreview-1410867004 From jnimeh at openjdk.org Wed May 3 13:15:32 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 3 May 2023 13:15:32 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v2] In-Reply-To: References: Message-ID: > This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. > > This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). > > JBS: https://bugs.openjdk.org/browse/JDK-8179502 > CSR: https://bugs.openjdk.org/browse/JDK-8300722 Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Add 's' suffix to allowed syntax ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13762/files - new: https://git.openjdk.org/jdk/pull/13762/files/3e0f5822..3c524e17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=00-01 Stats: 17 lines in 4 files changed: 7 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762 PR: https://git.openjdk.org/jdk/pull/13762 From jiangli at openjdk.org Wed May 3 16:15:16 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 16:15:16 GMT Subject: RFR: 8307134: Add GTS root CAs In-Reply-To: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> References: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com> Message-ID: On Tue, 2 May 2023 18:42:36 GMT, Rajan Halade wrote: >> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. > >> > > >> > >> > >> > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1 >> >> @rhalade, thanks! I have a minor comment below for your test/jdk/security/infra/java/security/cert/CertPathValidator/certification/GoogleCA.java test. I'll defer to @[awarner at google.com](mailto:awarner at google.com) for detailed review, as I don't have much context. >> >> Please fix the bug id, `8303394`: >> >> ``` >> /* >> * @test >> * @bug 8303394 >> * @summary Interoperability tests with Google's GlobalSign R4 and GTS Root certificates >> ... >> ``` >> >> Could you please also let me know your plan on committing the GoogleCA.java? Do you plan to create a PR? > > You can include this contribution in your PR. Then it will be easier to backport to JDK 20u as one changeset. I updated bug id in the changeset. > Looks good. Please also wait for approval from @rhalade before integrating. Thanks @seanjmullan. Will wait for @rhalade's approval as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1533324346 From rhalade at openjdk.org Wed May 3 17:45:25 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 3 May 2023 17:45:25 GMT Subject: RFR: 8307134: Add GTS root CAs [v4] In-Reply-To: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com> References: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com> Message-ID: On Tue, 2 May 2023 21:27:18 GMT, Jiangli Zhou wrote: >> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/sun/security/lib/cacerts/VerifyCACerts.java after reverting src/java.base/share/data/cacerts/globalsigneccrootcar4. Looks good to me. Please don't forget to update the release note and backport to JDK 20u. ------------- Marked as reviewed by rhalade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13754#pullrequestreview-1411431127 From duke at openjdk.org Wed May 3 18:03:24 2023 From: duke at openjdk.org (Matthew Donovan) Date: Wed, 3 May 2023 18:03:24 GMT Subject: Integrated: 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate In-Reply-To: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com> Message-ID: <00r3bTPD2PRPwAHA3imWoaYaezEZ0PcK6FXVb6kp2zM=.631986ec-4c89-4c6f-b2c6-4400b29fb4b7@github.com> On Mon, 17 Apr 2023 13:25:53 GMT, Matthew Donovan wrote: > I refactored tests in the test/jdk/javax/net/ssl directories to use the test template classes. This pull request has now been integrated. Changeset: 705ad7d8 Author: Matthew Donovan Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/705ad7d829dcbf8f5e2f098275d0856f6b86db2d Stats: 1002 lines in 6 files changed: 266 ins; 693 del; 43 mod 8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/13494 From cslucas at openjdk.org Wed May 3 20:28:32 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 3 May 2023 20:28:32 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v9] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com> <8AmU_ta4meiUmO99Em5bV7XLAV4H9fAcil519yh70fU=.1a28f4a9-a992-43a7-8c4a-d1cf96835963@github.com> Message-ID: <8kDrmtWQJ9oAdm-sM916KB96TqI6HpAHrxjLFn_fRZU=.2d3d9d8e-3eb3-482e-9d1c-416908fa39ac@github.com> On Fri, 21 Apr 2023 19:23:37 GMT, Vladimir Kozlov wrote: >>> Again got failures in the test on Aarch64 running with -XX:-UseTLAB: >>> >>> ``` >>> testCmpMergeWithNull(boolean,int,int): >>> - Failed comparison: [found] 0 = 2 [given] >>> testCmpMergeWithNull_Second(boolean,int,int) >>> - Failed comparison: [found] 0 = 1 [given] >>> testMergedAccessAfterCallNoWrite(boolean,int,int) >>> - Failed comparison: [found] 2 = 3 [given] >>> testMergedAccessAfterCallWithWrite(boolean,int,int) >>> - Failed comparison: [found] 2 = 3 [given] >>> testNestedObjectsArray(boolean,int,int) >>> - Failed comparison: [found] 2 = 4 [given] >>> ``` >> >> @vnkozlov - The reason for these failures is due to an issue in the test framework ALLOC Regex: https://bugs.openjdk.org/browse/JDK-8306625 . Since only the tests added in this PR are failing due to that problem do you think I should create a separate PR to fix the Regex or just include the fix in this PR? > >> Since only the tests added in this PR are failing due to that problem do you think I should create a separate PR to fix the Regex or just include the fix in this PR? > > Create separate PR and fix it first. This PR still need review from @iwanowww and it may take time to address additional comments. @vnkozlov - Please let me know if you have further questions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1533687457 From kdriver at openjdk.org Wed May 3 20:38:21 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:38:21 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty [v2] In-Reply-To: References: Message-ID: > Fix type-o and update returns message. Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - address code review comments - JDK-8305963 fix type-o and update returns message - address code review comments - JDK-8305963 fix type-o and update returns message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13729/files - new: https://git.openjdk.org/jdk/pull/13729/files/e7046330..5241d394 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13729&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13729&range=00-01 Stats: 11603 lines in 350 files changed: 7638 ins; 1986 del; 1979 mod Patch: https://git.openjdk.org/jdk/pull/13729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13729/head:pull/13729 PR: https://git.openjdk.org/jdk/pull/13729 From kdriver at openjdk.org Wed May 3 20:45:13 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:45:13 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty [v3] In-Reply-To: References: Message-ID: <0-TfPm1uv00kCauPw3H0xiQPJ_Ixvwiwkitzs6yqa2E=.fafe2c78-2b81-4722-bd45-97e7dd192d2a@github.com> > Fix type-o and update returns message. Kevin Driver has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits: - address code review comments - JDK-8305963 fix type-o and update returns message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13729/files - new: https://git.openjdk.org/jdk/pull/13729/files/5241d394..57e7f995 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13729&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13729&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13729/head:pull/13729 PR: https://git.openjdk.org/jdk/pull/13729 From kdriver at openjdk.org Wed May 3 20:45:15 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:45:15 GMT Subject: RFR: 8305963: Typo in java.security.Security.getProperty In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver wrote: > Fix type-o and update returns message. @seanjmullan @valeriepeng : see 57e7f9951d21fe2be6466e1c10f3b3cdd53e64b4 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13729#issuecomment-1533708955 From kdriver at openjdk.org Wed May 3 20:50:25 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:50:25 GMT Subject: Integrated: 8305963: Typo in java.security.Security.getProperty In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver wrote: > Fix type-o and update returns message. This pull request has now been integrated. Changeset: db8b3cd0 Author: Kevin Driver Committer: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/db8b3cd0842c05396d74abe950a2103654519b61 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8305963: Typo in java.security.Security.getProperty Co-authored-by: Sean Coffey Reviewed-by: coffeys, wetmore ------------- PR: https://git.openjdk.org/jdk/pull/13729 From kdriver at openjdk.org Wed May 3 20:51:32 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:51:32 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v2] In-Reply-To: <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com> References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com> <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com> Message-ID: On Fri, 28 Apr 2023 21:58:04 GMT, Mark Powers wrote: >> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. > > src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2022, 2023, Oracle and/or its affiliates. All rights reserved. > > No need for 2022. @mcpowers : see 0754990b30d8f6b4bc2f977722fe5e679164d351 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13727#discussion_r1184259919 From kdriver at openjdk.org Wed May 3 20:51:30 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:51:30 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v3] In-Reply-To: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> Message-ID: > Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`. Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - address code review comment - updated copyright - set consumer to null if we're not in client mode ------------- Changes: https://git.openjdk.org/jdk/pull/13727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13727&range=02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13727/head:pull/13727 PR: https://git.openjdk.org/jdk/pull/13727 From kdriver at openjdk.org Wed May 3 20:55:16 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 20:55:16 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v2] In-Reply-To: <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com> References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com> <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com> Message-ID: <1O1K7-gg4FNOVcwG1g44zUW08CtEuCNz5qbjXNy8X6I=.9c87a9d0-52c8-4224-8e64-a6ce94efb80e@github.com> On Fri, 28 Apr 2023 21:59:41 GMT, Mark Powers wrote: >> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. > > src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 457: > >> 455: // For TLS 1.2 and prior versions, the HelloRequest message MAY >> 456: // be sent by the server at any time. >> 457: consumer = conContext.sslConfig.isClientMode ? > > This seems reasonable, but could you update the bug report to say why this fixes the problem? If we're in server mode, we want the consumer to be null so that we don't attempt to cast a Server object as a Client object further down in the stack. Having the consumer be null forces the check on the new line 463 to pass and throws the message for "unexpected handshake message". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13727#discussion_r1184268590 From jiangli at openjdk.org Wed May 3 21:12:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 21:12:27 GMT Subject: RFR: 8307134: Add GTS root CAs [v4] In-Reply-To: References: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com> Message-ID: On Wed, 3 May 2023 17:42:14 GMT, Rajan Halade wrote: > Looks good to me. Please don't forget to update the release note and backport to JDK 20u. Thanks @rhalade. Will do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1533751038 From jiangli at openjdk.org Wed May 3 21:12:29 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 21:12:29 GMT Subject: Integrated: 8307134: Add GTS root CAs In-Reply-To: References: Message-ID: <1UUewea-gbxxlJcLjUIlzC9mXWTP1kqqiW-YNgVxVwU=.4bbe0700-624a-4f14-897a-2401e5abe5af@github.com> On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou wrote: > This PR was requested by awarner at google.com. The updates were provided by awarner at google.com. This pull request has now been integrated. Changeset: 03030d47 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/03030d47ebee5c20919fe0162ec86d3d400cd955 Stats: 748 lines in 6 files changed: 745 ins; 0 del; 3 mod 8307134: Add GTS root CAs Co-authored-by: Andy Warner Co-authored-by: Rajan Halade Reviewed-by: mullan, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/13754 From kdriver at openjdk.org Wed May 3 22:14:17 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 3 May 2023 22:14:17 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v3] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 28 Apr 2023 19:15:59 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java > > Co-authored-by: Daniel Jelinski As for other examples of the `X500Principal(byte[] ..)` constructor being called in TLS packages, here are the ones that don't seem to be handled nicely currently: - `consume` in `CertificateAuthoritiesExtension.CRCertificateAuthoritiesConsumer` (could throw IAE, which is an uncaught RuntimeException) - `toString` in `CertificateAuthoritiesExtension.CertificateAuthoritiesSpec` (could throw IAE, which is an uncaught RuntimeException) - `consume` in `CertificateRequest.T10CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException) - `toString` in `CertificateRequest.T10CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException) - `consume` in `CertificateRequest.T12CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException) - `toString` in `CertificateRequest.T12CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException) I will look at making related changes in these spots as well. @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method. This may be fine, but similar changes would need to be made in all the above places anyway, I suspect, unless we can pass information about the context in order to throw an `SSL(Protocol)Exception` and have that bubble-up to where `IOException`s are usually checked. @seanjmullan @XueleiFan thoughts on that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1533818757 From wetmore at openjdk.org Thu May 4 00:21:17 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 4 May 2023 00:21:17 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v3] In-Reply-To: References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> Message-ID: On Wed, 3 May 2023 20:51:30 GMT, Kevin Driver wrote: >> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`. > > Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - address code review comment > - updated copyright > - set consumer to null if we're not in client mode Other than the comment suggestion, LGTM. Putting comment in the bug as Mark suggested requires archeology, thus I suggest it be directly in the codebase. I'm a huge proponent of comments when things aren't always obvious. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13727#pullrequestreview-1412071577 From wetmore at openjdk.org Thu May 4 00:21:19 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 4 May 2023 00:21:19 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v2] In-Reply-To: <1O1K7-gg4FNOVcwG1g44zUW08CtEuCNz5qbjXNy8X6I=.9c87a9d0-52c8-4224-8e64-a6ce94efb80e@github.com> References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com> <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com> <1O1K7-gg4FNOVcwG1g44zUW08CtEuCNz5qbjXNy8X6I=.9c87a9d0-52c8-4224-8e64-a6ce94efb80e@github.com> Message-ID: On Wed, 3 May 2023 20:52:34 GMT, Kevin Driver wrote: >> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 457: >> >>> 455: // For TLS 1.2 and prior versions, the HelloRequest message MAY >>> 456: // be sent by the server at any time. >>> 457: consumer = conContext.sslConfig.isClientMode ? >> >> This seems reasonable, but could you update the bug report to say why this fixes the problem? > > If we're in server mode, we want the consumer to be null so that we don't attempt to cast a Server object as a Client object further down in the stack. Having the consumer be null forces the check on the new line 463 to pass and throws the message for "unexpected handshake message". This would an good comment to have in the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13727#discussion_r1184417783 From valeriep at openjdk.org Thu May 4 02:07:22 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 May 2023 02:07:22 GMT Subject: RFR: 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts null argument Message-ID: Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. CSR has been filed. Thanks, Valerie ------------- Commit messages: - 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts null argument Changes: https://git.openjdk.org/jdk/pull/13788/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8155191 Stats: 138 lines in 5 files changed: 127 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13788.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13788/head:pull/13788 PR: https://git.openjdk.org/jdk/pull/13788 From xuelei at openjdk.org Thu May 4 02:33:14 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 4 May 2023 02:33:14 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v3] In-Reply-To: References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> Message-ID: On Wed, 3 May 2023 20:51:30 GMT, Kevin Driver wrote: >> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`. > > Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - address code review comment > - updated copyright > - set consumer to null if we're not in client mode Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13727#pullrequestreview-1412177409 From mullan at openjdk.org Thu May 4 13:02:17 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 May 2023 13:02:17 GMT Subject: RFR: 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts null argument In-Reply-To: References: Message-ID: On Thu, 4 May 2023 01:58:42 GMT, Valerie Peng wrote: > Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. > > Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. > > CSR has been filed. > > Thanks, > Valerie I suggest the title of this issue should be changed to better reflect the proposed change: "Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null". Also, would you consider making the same change to `SecureRandom.setSeed(byte[])` as part of this change? I'm pretty sure all JDK SR impls throw NPE if the array is null. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13788#issuecomment-1534734886 From duke at openjdk.org Thu May 4 15:18:17 2023 From: duke at openjdk.org (Sergey Chernyshev) Date: Thu, 4 May 2023 15:18:17 GMT Subject: RFR: 8168469: Memory leak in JceSecurity In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev wrote: > Hi all, > > I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME. > > The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap, Object>` instead of `IdentityHashMap`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper `objects that maintained the object identity while improved performance. > > The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called. > > `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers. > > I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test. > > Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions > > [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html > [2] https://bugs.openjdk.org/browse/JDK-8168469 > [3] https://bugs.openjdk.org/browse/JDK-7107615 > [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0 @valeriepeng Could you please take a look at this change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13658#issuecomment-1534961823 From asotona at openjdk.org Thu May 4 16:15:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 4 May 2023 16:15:12 GMT Subject: RFR: 8250596: Update remaining manpage references from "OS X" to "macOS" Message-ID: Most of the manpages were updated a few years ago but some references remain. This patch renames remaining references to "macOS". Please review. Thanks, Adam ------------- Commit messages: - 8250596: Update remaining manpage references from "OS X" to "macOS" Changes: https://git.openjdk.org/jdk/pull/13807/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13807&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8250596 Stats: 16 lines in 7 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/13807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13807/head:pull/13807 PR: https://git.openjdk.org/jdk/pull/13807 From hchao at openjdk.org Thu May 4 16:48:14 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 4 May 2023 16:48:14 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng wrote: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java line 176: > 174: > 175: // should only have "pk1" now > 176: checkEntry(ks, "pk1", pk1Chain); When the kesytore should only have "pk1? now, how would checkEntry(ks, "pk1", pk1Chain) succeed as it expects to have the ?ca.cert? in the pk1Chain? The ?ca.cert? shall not be deleted because ?pk1.cert? depends on it. I may have missed something here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1183111954 From mullan at openjdk.org Thu May 4 17:02:12 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 May 2023 17:02:12 GMT Subject: RFR: 8250596: Update remaining manpage references from "OS X" to "macOS" In-Reply-To: References: Message-ID: On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote: > Most of the manpages were updated a few years ago but some references remain. > This patch renames remaining references to "macOS". > > Please review. > > Thanks, > Adam keytool and jarsigner docs look good. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1413524329 From valeriep at openjdk.org Thu May 4 19:01:17 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 May 2023 19:01:17 GMT Subject: RFR: 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts null argument In-Reply-To: References: Message-ID: On Thu, 4 May 2023 12:59:21 GMT, Sean Mullan wrote: > I suggest the title of this issue should be changed to better reflect the proposed change: "Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null". Ok. > Also, would you consider making the same change to `SecureRandom.setSeed(byte[])` as part of this change? I'm pretty sure all JDK SR impls throw NPE if the array is null. Hmm, let me try it out. If the behavior is consistent NPE, I can include that as part of this PR/CSR as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13788#issuecomment-1535256656 From cjplummer at openjdk.org Thu May 4 19:24:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 4 May 2023 19:24:13 GMT Subject: RFR: 8250596: Update remaining manpage references from "OS X" to "macOS" In-Reply-To: References: Message-ID: On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote: > Most of the manpages were updated a few years ago but some references remain. > This patch renames remaining references to "macOS". > > Please review. > > Thanks, > Adam The jstatd.1 and jstat.1 files look good. Copyrights need updating on all the files. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1413771872 From kdriver at openjdk.org Thu May 4 19:29:05 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 4 May 2023 19:29:05 GMT Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake [v4] In-Reply-To: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> Message-ID: > Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`. Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: added explanatory comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13727/files - new: https://git.openjdk.org/jdk/pull/13727/files/0754990b..24956f70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13727&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13727&range=02-03 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13727/head:pull/13727 PR: https://git.openjdk.org/jdk/pull/13727 From kdriver at openjdk.org Thu May 4 19:29:07 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 4 May 2023 19:29:07 GMT Subject: Integrated: 8294983: SSLEngine throws ClassCastException during handshake In-Reply-To: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com> Message-ID: On Fri, 28 Apr 2023 19:28:03 GMT, Kevin Driver wrote: > Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`. This pull request has now been integrated. Changeset: 197d0cc6 Author: Kevin Driver Committer: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/197d0cc6031cb470f1bd7678796593ff1bf440ca Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod 8294983: SSLEngine throws ClassCastException during handshake Co-authored-by: Daniel Jeli?ski Reviewed-by: wetmore, xuelei ------------- PR: https://git.openjdk.org/jdk/pull/13727 From dcubed at openjdk.org Thu May 4 21:13:37 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 4 May 2023 21:13:37 GMT Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 Message-ID: Trivial fixes to ProblemList a few tests: - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 ------------- Commit messages: - get rid of extra blank line. - 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 - 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 - 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 Changes: https://git.openjdk.org/jdk/pull/13816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307489 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13816.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13816/head:pull/13816 PR: https://git.openjdk.org/jdk/pull/13816 From darcy at openjdk.org Thu May 4 21:24:14 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 4 May 2023 21:24:14 GMT Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 > - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 > - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13816#pullrequestreview-1413942638 From dcubed at openjdk.org Thu May 4 21:35:39 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 4 May 2023 21:35:39 GMT Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 4 May 2023 21:21:38 GMT, Joe Darcy wrote: >> Trivial fixes to ProblemList a few tests: >> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 >> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 >> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13816#issuecomment-1535438955 From dcubed at openjdk.org Thu May 4 21:35:40 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 4 May 2023 21:35:40 GMT Subject: Integrated: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 > - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 > - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 This pull request has now been integrated. Changeset: 111858f3 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/111858f3ff86a15666537df515375fa04ffef048 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/13816 From weijun at openjdk.org Thu May 4 21:52:28 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 May 2023 21:52:28 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters src/java.base/share/classes/sun/security/provider/HSS.java line 94: > 92: result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); > 93: return result; > 94: } catch (Exception e) { If all exceptions thrown are already `SignatureException`, we can let them thrown out instead of returning false. According to the `engineVerify` spec, any problem inside the signature should throw a `SignatureException`. False is returned when the public key cannot verify the exception. src/java.base/share/classes/sun/security/provider/HSS.java line 181: > 179: try { > 180: lmParams = new LMParams(type); > 181: lmotsParams = LMOTSParams.of(otsType); Try to code `LMParams` and `LMOTSParams` the same style by choosing from using a constructor or static `of` method. Should `LMParams` be renamed to `LMSParams`? src/java.base/share/classes/sun/security/provider/HSS.java line 294: > 292: LMOTSignature(byte[] sigArray, LMOTSParams lmotsParams) throws InvalidParameterException { > 293: int inLen = sigArray.length; > 294: if (inLen < 4) Add braces around the one-line block. Same as in lines 300, 173, 461, 472, 487, 569, 571, and 783. src/java.base/share/classes/sun/security/provider/HSS.java line 295: > 293: int inLen = sigArray.length; > 294: if (inLen < 4) > 295: throw new InvalidParameterException("Invalid LMS signature"); This is LM-OTS signature. Also, give some explanation. Same on line 301. src/java.base/share/classes/sun/security/provider/HSS.java line 357: > 355: break; > 356: > 357: /* Remove commented-out lines if they cannot be supported on time. src/java.base/share/classes/sun/security/provider/HSS.java line 459: > 457: final byte[] sigArr; > 458: > 459: public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws InvalidParameterException { How about we throw a `SignatureException` here. `new HSSSignature` and `new LMOTSignature` all throw it. src/java.base/share/classes/sun/security/provider/HSS.java line 528: > 526: // update()-digest() sequence) which is parametrized so that the digest output is copied back into this buffer. > 527: // This way, we avoid memory allocations and some computations that would have to be done otherwise. > 528: final byte[] hashBuf; I'm a little worried about the mutability of `hashBuf` and whether it's suitable to be put inside `LMOTSParams`. By using `of` to return an `LMOTSParams` object we have the chance to return cached objects in the future. There should always be one `hashBuf` for each LM-OTS verification, and this is not clear from the current code. src/java.base/share/classes/sun/security/provider/HSS.java line 659: > 657: } > 658: public byte[] lmotsPubKeyCandidate(LMSignature lmSig, byte[] message, LMSPublicKey pKey) > 659: throws NoSuchAlgorithmException, DigestException { `DigestException` should not happen because we allocate all the buffer ourselves. `NoSuchAlgorithmException` should not happen because we should have all the algorithms. If they do happen, that's not user problem at all. I think the usual way is to wrap them into a `ProviderException`. This is also true in `lmsVerify()`. src/java.base/share/classes/sun/security/provider/HSS.java line 662: > 660: LMOTSignature lmOtSig = lmSig.lmotSig; > 661: if (lmOtSig.otSigType != pKey.otsType) { > 662: throw new IllegalArgumentException("OTS public key type and OTS signature type do not match"); I'd rather throw `SignatureException`. This method is actually verifying an LM-OTS signature, right? src/java.base/share/classes/sun/security/provider/HSS.java line 736: > 734: } > 735: } > 736: throw new InvalidKeySpecException(); Give an error message. Try look at what other factories are doing. Same for lines 751, 768, 727, 44, 49, and 57. src/java.base/share/classes/sun/security/provider/HSS.java line 745: > 743: > 744: @Override > 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { Usually when `key` is null an `InvalidKeySpecException` is thrown. Here it's an NPE. src/java.base/share/classes/sun/security/provider/HSS.java line 809: > 807: HSSSignature(byte[] sigArr, int pubKeyL, String pubKeyHashAlg) throws SignatureException { > 808: if (sigArr.length < 4) { > 809: throw new SignatureException("Bad HSS signature"); Maybe you can say why it is bad. This also applies to "Invalid HSS public key", "Invalid LMS signature" and "Invalid LMS public key" messages. src/java.base/share/classes/sun/security/provider/HSS.java line 823: > 821: index += siglist[i].sigArrayLength(); > 822: pubList[i] = new LMSPublicKey(sigArr, index, false); > 823: if (!pubList[i].getDigestAlgorithm().equals(pubKeyHashAlg)) { Comparing hash algorithm is not enough. Length (`m`) should also be compared. src/java.base/share/classes/sun/security/provider/HSS.java line 829: > 827: } > 828: siglist[Nspk] = new LMSignature(sigArr, index, true); > 829: } catch (Exception E) { The `SignatureException` thrown on line 824 does not need to be wrapped into another `SignatureException`. Maybe just catch `InvalidKeyException` (if you throw `SignatureException` in `new LMSSignature`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185459409 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185523625 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185518085 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185540342 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185521512 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185512129 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185533184 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185503139 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185544334 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185546621 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185508073 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185535770 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185536879 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185497769 From weijun at openjdk.org Thu May 4 21:57:19 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 May 2023 21:57:19 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters One more comment on exceptions. src/java.base/share/classes/sun/security/provider/HSS.java line 467: > 465: qArr = Arrays.copyOfRange(sigArray, offset, offset + 4); > 466: sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4); > 467: LMOTSParams lmotsParams = LMOTSParams.of(sigOtsType); Catch `IllegalArgumentException` here and rethrow a `SignatureException`. Same on line 482. ------------- PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1413972348 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185552104 From dholmes at openjdk.org Thu May 4 22:51:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 May 2023 22:51:12 GMT Subject: RFR: 8250596: Update remaining manpage references from "OS X" to "macOS" In-Reply-To: References: Message-ID: On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote: > Most of the manpages were updated a few years ago but some references remain. > This patch renames remaining references to "macOS". > > Please review. > > Thanks, > Adam Looks good. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1414016697 From valeriep at openjdk.org Fri May 5 01:21:32 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 May 2023 01:21:32 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v2] In-Reply-To: References: Message-ID: <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com> > Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. > > Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. > > CSR has been filed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Add NPE for SecureRandom(byte[]) ctor and setSeed(byte[]) method. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13788/files - new: https://git.openjdk.org/jdk/pull/13788/files/27687285..34ebdfa7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=00-01 Stats: 39 lines in 4 files changed: 32 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13788.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13788/head:pull/13788 PR: https://git.openjdk.org/jdk/pull/13788 From sspitsyn at openjdk.org Fri May 5 07:30:14 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 5 May 2023 07:30:14 GMT Subject: RFR: 8250596: Update remaining manpage references from "OS X" to "macOS" In-Reply-To: References: Message-ID: On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote: > Most of the manpages were updated a few years ago but some references remain. > This patch renames remaining references to "macOS". > > Please review. > > Thanks, > Adam Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1414295424 From asotona at openjdk.org Fri May 5 08:40:27 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 5 May 2023 08:40:27 GMT Subject: RFR: 8250596: Update remaining manpage references from "OS X" to "macOS" [v2] In-Reply-To: References: Message-ID: > Most of the manpages were updated a few years ago but some references remain. > This patch renames remaining references to "macOS". > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13807/files - new: https://git.openjdk.org/jdk/pull/13807/files/88c2d42c..00e12f4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13807&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13807&range=00-01 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13807/head:pull/13807 PR: https://git.openjdk.org/jdk/pull/13807 From asotona at openjdk.org Fri May 5 08:58:54 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 5 May 2023 08:58:54 GMT Subject: Integrated: 8250596: Update remaining manpage references from "OS X" to "macOS" In-Reply-To: References: Message-ID: On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote: > Most of the manpages were updated a few years ago but some references remain. > This patch renames remaining references to "macOS". > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 3b430b9f Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/3b430b9f732bc94674bf598c28162e2f5e62bae6 Stats: 23 lines in 7 files changed: 0 ins; 0 del; 23 mod 8250596: Update remaining manpage references from "OS X" to "macOS" Reviewed-by: mullan, cjplummer, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13807 From duke at openjdk.org Fri May 5 11:34:27 2023 From: duke at openjdk.org (Matthew Donovan) Date: Fri, 5 May 2023 11:34:27 GMT Subject: RFR: 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner Message-ID: Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start. Thanks! ------------- Commit messages: - 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner Changes: https://git.openjdk.org/jdk/pull/13829/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13829&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305169 Stats: 28 lines in 2 files changed: 17 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13829.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13829/head:pull/13829 PR: https://git.openjdk.org/jdk/pull/13829 From ssahoo at openjdk.org Fri May 5 12:34:16 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Fri, 5 May 2023 12:34:16 GMT Subject: RFR: 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner In-Reply-To: References: Message-ID: <5nRhiX0WNvw-Yicc4OEKgTmUScfKkb3SFEYLi8c0S24=.dd818fde-0723-47a8-b249-e6dfb37289d7@github.com> On Fri, 5 May 2023 11:27:48 GMT, Matthew Donovan wrote: > Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start. > > Thanks! Please wait for a reviewer to complete the review. ------------- Marked as reviewed by ssahoo (Committer). PR Review: https://git.openjdk.org/jdk/pull/13829#pullrequestreview-1414699616 From jnimeh at openjdk.org Fri May 5 14:05:24 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 5 May 2023 14:05:24 GMT Subject: RFR: 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner In-Reply-To: References: Message-ID: On Fri, 5 May 2023 11:27:48 GMT, Matthew Donovan wrote: > Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start. > > Thanks! Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13829#pullrequestreview-1414857598 From duke at openjdk.org Fri May 5 14:20:30 2023 From: duke at openjdk.org (Matthew Donovan) Date: Fri, 5 May 2023 14:20:30 GMT Subject: Integrated: 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner In-Reply-To: References: Message-ID: <18WvSaSoJTJASLrZGZQYCJqtl9cqiXXYRofvah1cEPQ=.ce37667e-5e6e-4082-9c5c-8aa4565ae3e9@github.com> On Fri, 5 May 2023 11:27:48 GMT, Matthew Donovan wrote: > Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start. > > Thanks! This pull request has now been integrated. Changeset: 3f6a3545 Author: Matthew Donovan Committer: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/3f6a3545a255cbef3c3436ff26481f1cec4ccfc9 Stats: 28 lines in 2 files changed: 17 ins; 8 del; 3 mod 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner Reviewed-by: ssahoo, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/13829 From weijun at openjdk.org Fri May 5 14:31:17 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 May 2023 14:31:17 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com> On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons wrote: >> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback We have quite some `standard-names.html#anchorName` links (Ex: https://github.com/openjdk/jdk/blob/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94/src/java.base/share/classes/java/security/Signature.java#L111). I don't see any of them here. Is this style allowed in a `@spec` tag? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1536346418 From mullan at openjdk.org Fri May 5 14:59:24 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 May 2023 14:59:24 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters Some of the files (SunEntries, KnownOIDs, SHA2, P11Key) are missing 2023 copyright dates. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1536384833 From mullan at openjdk.org Fri May 5 15:07:18 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 May 2023 15:07:18 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: <6mj0683ApqoyzucG4pEp4c8S91Id9oyJliEJEmjKma8=.e7632576-8472-40b5-b5f1-aefe9471aeac@github.com> On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30: > 28: import java.security.spec.KeySpec; > 29: > 30: public class RawKeySpec implements KeySpec { Nit, should be one space between `RawKeySpec` and `implements`. src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30: > 28: import java.security.spec.KeySpec; > 29: > 30: public class RawKeySpec implements KeySpec { Can you add some comments describing this class? src/java.base/share/classes/sun/security/util/RawKeySpec.java line 31: > 29: > 30: public class RawKeySpec implements KeySpec { > 31: final private byte[] keyArr; Put `private` before `final`. src/java.base/share/classes/sun/security/util/RawKeySpec.java line 33: > 31: final private byte[] keyArr; > 32: /** > 33: * The sole constructor Nit: add period at end of sentence and an empty line after this (before the `@param`). src/java.base/share/classes/sun/security/util/RawKeySpec.java line 37: > 35: */ > 36: public RawKeySpec(byte[] key) { > 37: keyArr = key.clone(); Does this need to be cloned if it is an internal class? src/java.base/share/classes/sun/security/util/RawKeySpec.java line 41: > 39: > 40: /** > 41: * Getter function Nit: add period at end of sentence and an empty line after this (before the @return). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186201989 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186202683 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186205743 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186204113 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186204543 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186205020 From weijun at openjdk.org Fri May 5 17:00:17 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 May 2023 17:00:17 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng wrote: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie Is it possible to generate the keys and certs on the fly? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2031: > 2029: cert.getSubjectX500Principal() + "]"); > 2030: } > 2031: } else { If `destroyIt` is false for the 1st cert, are you going to return false? Maybe it does not matter. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2057: > 2055: currHdl = ch[0]; > 2056: } else { > 2057: currHdl = 0L; Maybe just `break`? ------------- PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1415118643 PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186303587 PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186299589 From weijun at openjdk.org Fri May 5 18:04:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 May 2023 18:04:40 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 Message-ID: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Update XML Security for Java to 3.0.2. Some change to tests: 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. ------------- Commit messages: - the change Changes: https://git.openjdk.org/jdk/pull/13840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305972 Stats: 1145 lines in 41 files changed: 845 ins; 203 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From valeriep at openjdk.org Fri May 5 19:46:18 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 May 2023 19:46:18 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Tue, 2 May 2023 22:42:13 GMT, Hai-May Chao wrote: >> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? >> >> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. >> >> Thanks, >> Valerie > > test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java line 176: > >> 174: >> 175: // should only have "pk1" now >> 176: checkEntry(ks, "pk1", pk1Chain); > > When the kesytore should only have "pk1? now, how would checkEntry(ks, "pk1", pk1Chain) succeed as it expects to have the ?ca.cert? in the pk1Chain? The ?ca.cert? shall not be deleted because ?pk1.cert? depends on it. I may have missed something here. I mean "pk1" entrry, not just "pk1" cert. As you can see, the test checks for the complete cert chain for "pk1" entry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186446763 From mullan at openjdk.org Fri May 5 19:50:22 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 May 2023 19:50:22 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters src/java.base/share/classes/sun/security/provider/HSS.java line 37: > 35: import java.util.Arrays; > 36: import java.util.Objects; > 37: Can you add some comments describing this class? src/java.base/share/classes/sun/security/provider/HSS.java line 38: > 36: import java.util.Objects; > 37: > 38: public class HSS extends SignatureSpi { Make the class `final`? src/java.base/share/classes/sun/security/provider/HSS.java line 43: > 41: > 42: @Deprecated > 43: protected void engineSetParameter(String param, Object value) { Technically, this API is not defined to throw UOE. I think throwing IPE is better and would be compliant with the specification. (I am aware that there are other JDK SignatureSpi implementations that already throw UOE for this method, but they should be fixed). src/java.base/share/classes/sun/security/provider/HSS.java line 48: > 46: > 47: @Deprecated > 48: protected AlgorithmParameters engineGetParameter(String param) { Same comment as above. src/java.base/share/classes/sun/security/provider/HSS.java line 56: > 54: } > 55: > 56: protected byte[] engineSign() throws SignatureException { This API is not defined to throw UOE. Suggest throwing `SignatureException` instead with a message "Signing is not supported". Though, technically this method should never be called, as `Signature.sign()` will throw a `SignatureException` because it has not been initialized for signing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186440423 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186448496 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186443155 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186443576 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186445307 From valeriep at openjdk.org Fri May 5 20:10:13 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 May 2023 20:10:13 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:57:56 GMT, Weijun Wang wrote: > Is it possible to generate the keys and certs on the fly? Possible. For testing things not related to generation, using existing key/certs simplifies the setup and can be reused easily. Or, do you know if there are JDK test utilities which support this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536721503 From weijun at openjdk.org Fri May 5 20:23:18 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 May 2023 20:23:18 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 20:07:18 GMT, Valerie Peng wrote: > Or, do you know if there are JDK test utilities which support this? Just `SecurityTools.keytool`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536736209 From valeriep at openjdk.org Fri May 5 20:23:20 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 May 2023 20:23:20 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:43:03 GMT, Weijun Wang wrote: >> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? >> >> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2057: > >> 2055: currHdl = ch[0]; >> 2056: } else { >> 2057: currHdl = 0L; > > Maybe just `break`? Sure, that'll work also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186470638 From kdriver at openjdk.org Fri May 5 20:33:19 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 5 May 2023 20:33:19 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v4] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java Co-authored-by: Daniel Jelinski - updated copyright - fixes JDK-8294985: throw an SSLException wrapping the IAE ------------- Changes: https://git.openjdk.org/jdk/pull/13466/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=03 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From hchao at openjdk.org Fri May 5 20:44:20 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 5 May 2023 20:44:20 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 19:43:31 GMT, Valerie Peng wrote: >> test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java line 176: >> >>> 174: >>> 175: // should only have "pk1" now >>> 176: checkEntry(ks, "pk1", pk1Chain); >> >> When the kesytore should only have "pk1? now, how would checkEntry(ks, "pk1", pk1Chain) succeed as it expects to have the ?ca.cert? in the pk1Chain? The ?ca.cert? shall not be deleted because ?pk1.cert? depends on it. I may have missed something here. > > I mean "pk1" entrry, not just "pk1" cert. As you can see, the test checks for the complete cert chain for "pk1" entry. I've the same understanding of this test. The test looks good to me. I was puzzled by its "pk1" comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186485506 From hchao at openjdk.org Fri May 5 20:51:19 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 5 May 2023 20:51:19 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng wrote: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie As Max pointed out to use SecurityTools.keytool to generate keys/certs, I'd like to suggest using it to add a test case for pk1->pk2->ca, to test when deleting an intermediate cert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536764393 From jjg at openjdk.org Fri May 5 20:55:17 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 5 May 2023 20:55:17 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com> References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com> Message-ID: <_4-xwqG0X3oF_UgPT1B5FlfCqsdtQZ21PpdXXkgSS6o=.e3747de4-d20f-4bb7-8d96-da63b668fd65@github.com> On Fri, 5 May 2023 14:28:01 GMT, Weijun Wang wrote: > We have quite some `standard-names.html#anchorName` links (Ex: > > https://github.com/openjdk/jdk/blob/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94/src/java.base/share/classes/java/security/Signature.java#L111 > > ). I don't see any of them here. Is this style allowed in a `@spec` tag? > I also see no `#anchorName` for RFC links. > > And in this case, shall I also spell out the section name in the text? 1. You can use a relative URL, relative to the `specs` directory, so something like:
`@spec security/standard-names.html Standard Names` 2. The intent of the `@spec` tag is to identify the overall/root URL for each specification, not to identify all the interesting places within that specification. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1536766590 From valeriep at openjdk.org Fri May 5 21:42:13 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 May 2023 21:42:13 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:46:16 GMT, Weijun Wang wrote: >> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? >> >> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2031: > >> 2029: cert.getSubjectX500Principal() + "]"); >> 2030: } >> 2031: } else { > > If `destroyIt` is false for the 1st cert, are you going to return false? Maybe it does not matter. Hmm, I think the rest of chain should still be checked and removed if no dependents for them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186517535 From valeriep at openjdk.org Fri May 5 22:23:33 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 May 2023 22:23:33 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 20:20:44 GMT, Weijun Wang wrote: > > Or, do you know if there are JDK test utilities which support this? > > Just `SecurityTools.keytool`. I can give it a try. But if it turns out taking much longer (time and code), then I'd prefer just to go with PEM data files as I don't see an obvious benefit for dynamically generating the key pairs for this particular test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536847770 From weijun at openjdk.org Fri May 5 22:56:13 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 May 2023 22:56:13 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng wrote: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie It's your decision. My point is that PEM data files, although in text mode, are still binary data and not human readable. You probably need some explanation on how to recreate them and that is equivalent to adding several `keytool` calls inside the test. Yes, I understand with the key generation calls the test will run much slower. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536869563 From weijun at openjdk.org Fri May 5 23:02:23 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 May 2023 23:02:23 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:39:13 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2031: >> >>> 2029: cert.getSubjectX500Principal() + "]"); >>> 2030: } >>> 2031: } else { >> >> If `destroyIt` is false for the 1st cert, are you going to return false? Maybe it does not matter. > > Hmm, I think the rest of chain should still be checked and removed if no dependents for them. Of course, I was only talking about the final return value. And, I take back my words. This method should return true no matter what `destroyIt` is. The return value is only used in `deleteEntry` and it should be true even if the.cert is used elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186547307 From liach at openjdk.org Sat May 6 17:03:13 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 May 2023 17:03:13 GMT Subject: RFR: 8307575: Migrate the serialization constructor accessors to Method Handles Message-ID: Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation. Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects. #1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation. ------------- Commit messages: - 8307575: Migrate the serialization constructor accessors to Method Handles Changes: https://git.openjdk.org/jdk/pull/13853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13853&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307575 Stats: 126 lines in 8 files changed: 53 ins; 40 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/13853.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13853/head:pull/13853 PR: https://git.openjdk.org/jdk/pull/13853 From liach at openjdk.org Sun May 7 13:36:16 2023 From: liach at openjdk.org (Chen Liang) Date: Sun, 7 May 2023 13:36:16 GMT Subject: RFR: 8307575: Migrate the serialization constructor accessors to Method Handles [v2] In-Reply-To: References: Message-ID: > Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation. > > Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects. > > #1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Remove invalid assertion (via sun.reflect.ReflectionFactory) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13853/files - new: https://git.openjdk.org/jdk/pull/13853/files/64a8f518..3a0393a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13853&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13853&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13853.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13853/head:pull/13853 PR: https://git.openjdk.org/jdk/pull/13853 From mdonovan at openjdk.org Mon May 8 12:17:25 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 8 May 2023 12:17:25 GMT Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException [v3] In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> References: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com> Message-ID: On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan wrote: >> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods. >> >> Thanks > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > made handshake context lock final Can a security-dev Reviewer take a look at this? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13742#issuecomment-1538261029 From mullan at openjdk.org Mon May 8 13:11:36 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 8 May 2023 13:11:36 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters src/java.base/share/classes/sun/security/provider/HSS.java line 746: > 744: @Override > 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { > 746: if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) { Should check if `key` is `null` and if so, throw `InvalidKeySpecExc`. src/java.base/share/classes/sun/security/provider/HSS.java line 746: > 744: @Override > 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { > 746: if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) { Standard names are case-insensitive, so should use `equalsIgnoreCase`. src/java.base/share/classes/sun/security/provider/HSS.java line 774: > 772: } > 773: > 774: public static class HSSPublicKey extends X509Key implements Length { Can this be package-private instead of `public`? src/java.base/share/classes/sun/security/provider/HSS.java line 781: > 779: > 780: @SuppressWarnings("deprecation") > 781: public HSSPublicKey(byte[] keyArray) throws InvalidKeyException { Can this be package-private instead of public? src/java.base/share/classes/sun/security/provider/HSS.java line 796: > 794: > 795: @Override > 796: @SuppressWarnings("deprecation") Why do you need the `SuppressWarnings` annotation here? `sun.util.Length.length()` is not deprecated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187417447 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187421443 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187395653 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187397466 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187402001 From duke at openjdk.org Mon May 8 13:36:39 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 13:36:39 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 19:34:32 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 37: > >> 35: import java.util.Arrays; >> 36: import java.util.Objects; >> 37: > > Can you add some comments describing this class? Comment added. > src/java.base/share/classes/sun/security/provider/HSS.java line 38: > >> 36: import java.util.Objects; >> 37: >> 38: public class HSS extends SignatureSpi { > > Make the class `final`? Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 43: > >> 41: >> 42: @Deprecated >> 43: protected void engineSetParameter(String param, Object value) { > > Technically, this API is not defined to throw UOE. I think throwing IPE is better and would be compliant with the specification. (I am aware that there are other JDK SignatureSpi implementations that already throw UOE for this method, but they should be fixed). Changed to throw InvalidParameterException. > src/java.base/share/classes/sun/security/provider/HSS.java line 48: > >> 46: >> 47: @Deprecated >> 48: protected AlgorithmParameters engineGetParameter(String param) { > > Same comment as above. Changed to throw InvalidParameterException. > src/java.base/share/classes/sun/security/provider/HSS.java line 56: > >> 54: } >> 55: >> 56: protected byte[] engineSign() throws SignatureException { > > This API is not defined to throw UOE. Suggest throwing `SignatureException` instead with a message "Signing is not supported". > > Though, technically this method should never be called, as `Signature.sign()` will throw a `SignatureException` because it has not been initialized for signing. Done. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30: > >> 28: import java.security.spec.KeySpec; >> 29: >> 30: public class RawKeySpec implements KeySpec { > > Nit, should be one space between `RawKeySpec` and `implements`. Changed. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30: > >> 28: import java.security.spec.KeySpec; >> 29: >> 30: public class RawKeySpec implements KeySpec { > > Can you add some comments describing this class? Added. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 31: > >> 29: >> 30: public class RawKeySpec implements KeySpec { >> 31: final private byte[] keyArr; > > Put `private` before `final`. Changed the order. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 33: > >> 31: final private byte[] keyArr; >> 32: /** >> 33: * The sole constructor > > Nit: add period at end of sentence and an empty line after this (before the `@param`). Added period. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 37: > >> 35: */ >> 36: public RawKeySpec(byte[] key) { >> 37: keyArr = key.clone(); > > Does this need to be cloned if it is an internal class? Yes, I think so. If someone wants to test with several different keys by first creating RawKeySpec objects from an array in which a few bytes are changed between the calls and and then use these KeySpecs to create the actual keys, without the cloning they will end up with the same keys. So an immutable object is better. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 41: > >> 39: >> 40: /** >> 41: * Getter function > > Nit: add period at end of sentence and an empty line after this (before the @return). Added period. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453794 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187454052 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453859 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453935 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453983 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453454 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453499 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453735 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453545 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453600 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453680 From duke at openjdk.org Mon May 8 13:36:43 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 13:36:43 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> On Thu, 4 May 2023 20:00:18 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 94: > >> 92: result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); >> 93: return result; >> 94: } catch (Exception e) { > > If all exceptions thrown are already `SignatureException`, we can let them thrown out instead of returning false. According to the `engineVerify` spec, any problem inside the signature should throw a `SignatureException`. False is returned when the public key cannot verify the exception. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 295: > >> 293: int inLen = sigArray.length; >> 294: if (inLen < 4) >> 295: throw new InvalidParameterException("Invalid LMS signature"); > > This is LM-OTS signature. Also, give some explanation. Same on line 301. Explained. > src/java.base/share/classes/sun/security/provider/HSS.java line 459: > >> 457: final byte[] sigArr; >> 458: >> 459: public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws InvalidParameterException { > > How about we throw a `SignatureException` here. `new HSSSignature` and `new LMOTSignature` all throw it. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 467: > >> 465: qArr = Arrays.copyOfRange(sigArray, offset, offset + 4); >> 466: sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4); >> 467: LMOTSParams lmotsParams = LMOTSParams.of(sigOtsType); > > Catch `IllegalArgumentException` here and rethrow a `SignatureException`. Same on line 482. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 659: > >> 657: } >> 658: public byte[] lmotsPubKeyCandidate(LMSignature lmSig, byte[] message, LMSPublicKey pKey) >> 659: throws NoSuchAlgorithmException, DigestException { > > `DigestException` should not happen because we allocate all the buffer ourselves. `NoSuchAlgorithmException` should not happen because we should have all the algorithms. If they do happen, that's not user problem at all. I think the usual way is to wrap them into a `ProviderException`. This is also true in `lmsVerify()`. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 662: > >> 660: LMOTSignature lmOtSig = lmSig.lmotSig; >> 661: if (lmOtSig.otSigType != pKey.otsType) { >> 662: throw new IllegalArgumentException("OTS public key type and OTS signature type do not match"); > > I'd rather throw `SignatureException`. This method is actually verifying an LM-OTS signature, right? Avoid using unchecked exceptions instead of `ProviderException` unless you can be sure they are caught nicely. Changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 736: > >> 734: } >> 735: } >> 736: throw new InvalidKeySpecException(); > > Give an error message. Try look at what other factories are doing. Same for lines 751, 768, 727, 44, 49, and 57. Added explanations. > src/java.base/share/classes/sun/security/provider/HSS.java line 745: > >> 743: >> 744: @Override >> 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { > > Usually when `key` is null an `InvalidKeySpecException` is thrown. Here it's an NPE. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 809: > >> 807: HSSSignature(byte[] sigArr, int pubKeyL, String pubKeyHashAlg) throws SignatureException { >> 808: if (sigArr.length < 4) { >> 809: throw new SignatureException("Bad HSS signature"); > > Maybe you can say why it is bad. This also applies to "Invalid HSS public key", "Invalid LMS signature" and "Invalid LMS public key" messages. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 823: > >> 821: index += siglist[i].sigArrayLength(); >> 822: pubList[i] = new LMSPublicKey(sigArr, index, false); >> 823: if (!pubList[i].getDigestAlgorithm().equals(pubKeyHashAlg)) { > > Comparing hash algorithm is not enough. Length (`m`) should also be compared. Compared. > src/java.base/share/classes/sun/security/provider/HSS.java line 829: > >> 827: } >> 828: siglist[Nspk] = new LMSignature(sigArr, index, true); >> 829: } catch (Exception E) { > > The `SignatureException` thrown on line 824 does not need to be wrapped into another `SignatureException`. Maybe just catch `InvalidKeyException` (if you throw `SignatureException` in `new LMSSignature`). Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452891 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453204 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453062 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453398 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452980 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453253 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453292 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452998 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453109 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453175 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452934 From duke at openjdk.org Mon May 8 14:17:16 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 14:17:16 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v6] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments from @wangweij and @seanjmullan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/b546fdf0..42184ff9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=04-05 Stats: 236 lines in 6 files changed: 38 ins; 125 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From duke at openjdk.org Mon May 8 14:17:21 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 14:17:21 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 12:59:05 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 746: > >> 744: @Override >> 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { >> 746: if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) { > > Should check if `key` is `null` and if so, throw `InvalidKeySpecExc`. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 746: > >> 744: @Override >> 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { >> 746: if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) { > > Standard names are case-insensitive, so should use `equalsIgnoreCase`. Changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 796: > >> 794: >> 795: @Override >> 796: @SuppressWarnings("deprecation") > > Why do you need the `SuppressWarnings` annotation here? `sun.util.Length.length()` is not deprecated. Without that, I get: /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:813: warning: [deprecation] key in X509Key has been deprecated key = new DerOutputStream().putOctetString(keyArray).toByteArray(); ^ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187496671 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187496730 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187496615 From duke at openjdk.org Mon May 8 14:22:27 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 14:22:27 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 12:38:36 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 781: > >> 779: >> 780: @SuppressWarnings("deprecation") >> 781: public HSSPublicKey(byte[] keyArray) throws InvalidKeyException { > > Can this be package-private instead of public? Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187506046 From duke at openjdk.org Mon May 8 14:58:00 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 14:58:00 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Addressing more review comments from @wangweij and @seanjmullan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/42184ff9..b8064640 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From weijun at openjdk.org Mon May 8 16:02:29 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:02:29 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> References: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> Message-ID: On Mon, 8 May 2023 13:32:21 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 94: >> >>> 92: result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); >>> 93: return result; >>> 94: } catch (Exception e) { >> >> If all exceptions thrown are already `SignatureException`, we can let them thrown out instead of returning false. According to the `engineVerify` spec, any problem inside the signature should throw a `SignatureException`. False is returned when the public key cannot verify the exception. > > Done. `new HSSSignature` and `lmsVerify` are already throwing `SignatureExceptions` and they needn't be wrapped again into a new `SignatureException`. In fact, it seems `SignatureException` is the only checked exception that can be thrown in these lines. Is your `catch (Exception e)` block trying to catch unchecked exceptions? Unchecked exceptions like `NumberFormatException` or `NullPointerException` might indicate input errors and should be rewrapped, but `ProviderException` are well-defined as internal errors and can be exposed to the final user. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187614920 From duke at openjdk.org Mon May 8 16:02:33 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 16:02:33 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: <9wLugxZEyEoThvdIC4tKP0WK_KL5Bm9l3WkZa3zd5vw=.204c9526-4a08-46cb-8221-f8329680921f@github.com> On Mon, 8 May 2023 14:10:54 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 796: >> >>> 794: >>> 795: @Override >>> 796: @SuppressWarnings("deprecation") >> >> Why do you need the `SuppressWarnings` annotation here? `sun.util.Length.length()` is not deprecated. > > Without that, I get: > > /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:813: warning: [deprecation] key in X509Key has been deprecated > key = new DerOutputStream().putOctetString(keyArray).toByteArray(); > ^ Sorry, that one is if I remove another deprecation suppression. But the root cause is the same here, without the message I get /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:705: warning: [deprecation] key in X509Key has been deprecated return key.length * 8; // length in bits ^ error: warnings found and -Werror specified ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187556505 From duke at openjdk.org Mon May 8 16:02:34 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 8 May 2023 16:02:34 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: <9wLugxZEyEoThvdIC4tKP0WK_KL5Bm9l3WkZa3zd5vw=.204c9526-4a08-46cb-8221-f8329680921f@github.com> References: <9wLugxZEyEoThvdIC4tKP0WK_KL5Bm9l3WkZa3zd5vw=.204c9526-4a08-46cb-8221-f8329680921f@github.com> Message-ID: On Mon, 8 May 2023 15:02:55 GMT, Ferenc Rakoczi wrote: >> Without that, I get: >> >> /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:813: warning: [deprecation] key in X509Key has been deprecated >> key = new DerOutputStream().putOctetString(keyArray).toByteArray(); >> ^ > > Sorry, that one is if I remove another deprecation suppression. But the root cause is the same here, without the message I get > /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:705: warning: [deprecation] key in X509Key has been deprecated > return key.length * 8; // length in bits > ^ > error: warnings found and -Werror specified Grrrrh: " without the message" -> "without suppressing the warning" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187559580 From weijun at openjdk.org Mon May 8 16:05:51 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:05:51 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> References: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> Message-ID: On Mon, 8 May 2023 13:32:29 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 745: >> >>> 743: >>> 744: @Override >>> 745: protected T engineGetKeySpec(Key key, Class keySpec) throws InvalidKeySpecException { >> >> Usually when `key` is null an `InvalidKeySpecException` is thrown. Here it's an NPE. > > Done. `key.equals(null)` would throw an NPE. Just use `key == null`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187618885 From mullan at openjdk.org Mon May 8 16:19:34 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 8 May 2023 16:19:34 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: References: Message-ID: <9oyYOfazlu7cyszP6M-EeJ1q8HrkgBwOilN_YcJPV5Y=.ccfafdc1-8262-411d-8a76-90a62c3278ff@github.com> On Mon, 8 May 2023 14:58:00 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Addressing more review comments from @wangweij and @seanjmullan src/java.base/share/classes/sun/security/provider/HSS.java line 99: > 97: result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); > 98: return result; > 99: } catch (Exception e) { Do we need this `catch`? I think only `SignatureException` can be thrown inside the `try` block. src/java.base/share/classes/sun/security/provider/HSS.java line 172: > 170: private final byte[] T1; > 171: > 172: public static LMSPublicKey of(byte[] keyArray) throws InvalidKeyException { The methods of `LMSPublicKey` can be package-private. src/java.base/share/classes/sun/security/provider/HSS.java line 383: > 381: final byte[] sigArr; > 382: > 383: public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws SignatureException { The methods of `LMSignature` can be package-private. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187628502 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187624026 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187624515 From mullan at openjdk.org Mon May 8 16:19:36 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 8 May 2023 16:19:36 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > adding key translation, finally block, removing 24-byte LMOTS parameters src/java.base/share/classes/sun/security/provider/HSS.java line 229: > 227: > 228: static class LMSUtils { > 229: public final static int LMS_RESERVED = 0; The statics and methods of `LMSUtils` can all be package-private. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187500905 From weijun at openjdk.org Mon May 8 16:19:38 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:19:38 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> References: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com> Message-ID: On Mon, 8 May 2023 13:32:38 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 823: >> >>> 821: index += siglist[i].sigArrayLength(); >>> 822: pubList[i] = new LMSPublicKey(sigArr, index, false); >>> 823: if (!pubList[i].getDigestAlgorithm().equals(pubKeyHashAlg)) { >> >> Comparing hash algorithm is not enough. Length (`m`) should also be compared. > > Compared. How about we create a dedicated method for this `hasSameHash(LMParams, LMParams)`? Looks like the `getDigestAlgorithm` methods on lines 228 and 699 have no more other usages. We can also create a new `hasSameHash(LMOTSParams, LMParams)` for the check in `new LMSPublicKey`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187628910 From mullan at openjdk.org Mon May 8 16:19:41 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 8 May 2023 16:19:41 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com> On Mon, 8 May 2023 13:33:01 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 37: >> >>> 35: */ >>> 36: public RawKeySpec(byte[] key) { >>> 37: keyArr = key.clone(); >> >> Does this need to be cloned if it is an internal class? > > Yes, I think so. If someone wants to test with several different keys by first creating RawKeySpec objects from an array in which a few bytes are changed between the calls and and then use these KeySpecs to create the actual keys, without the cloning they will end up with the same keys. So an immutable object is better. Ok. Try to keep your line lengths to about 80 chars. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187577377 From weijun at openjdk.org Mon May 8 16:19:42 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:19:42 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com> References: <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com> Message-ID: On Mon, 8 May 2023 15:22:07 GMT, Sean Mullan wrote: >> Yes, I think so. If someone wants to test with several different keys by first creating RawKeySpec objects from an array in which a few bytes are changed between the calls and and then use these KeySpecs to create the actual keys, without the cloning they will end up with the same keys. So an immutable object is better. > > Ok. Try to keep your line lengths to about 80 chars. I think so too. This class is only used by tests now so it will not have any negative performance impact on real users. If we want to move it into the public one day then we don't need to update it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187631611 From weijun at openjdk.org Mon May 8 16:27:36 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:27:36 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 14:58:00 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Addressing more review comments from @wangweij and @seanjmullan src/java.base/share/classes/sun/security/provider/HSS.java line 158: > 156: } > 157: return lmsPublicKey.isT1(tmpMsg, 22 + m); > 158: } catch (Exception e) { Avoid using `catch (Exception e)` because that's too wide. In fact, here it seems the only checked exceptions that can be caught is `NoSuchAlgorithmException | DigestException`. I think we've agreed to throw `ProviderException` for them. src/java.base/share/classes/sun/security/provider/HSS.java line 240: > 238: public final static int LMS_SHA256_M32_H20 = 8; > 239: public final static int LMS_SHA256_M32_H25 = 9; > 240: public final static int LMS_SHA256_M24_H5 = 10; Shall we remove the SHA256_M24 and SHAKE constants at the moment? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187637375 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187639689 From weijun at openjdk.org Mon May 8 16:32:34 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:32:34 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: References: Message-ID: <3kJX5uh8UxbY852mLsh2XivNSl7jfVnx6M6m3LAHvsk=.119f255f-b4bb-483f-b967-9e93550983d4@github.com> On Mon, 8 May 2023 14:58:00 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Addressing more review comments from @wangweij and @seanjmullan src/java.base/share/classes/sun/security/provider/HSS.java line 106: > 104: } > 105: > 106: protected boolean lmsVerify(LMSPublicKey lmsPublicKey, LMSignature sig, byte[] message) throws SignatureException { We probably should put this method into an inner class and make it static. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187644587 From weijun at openjdk.org Mon May 8 16:41:35 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:41:35 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 21:24:16 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 528: > >> 526: // update()-digest() sequence) which is parametrized so that the digest output is copied back into this buffer. >> 527: // This way, we avoid memory allocations and some computations that would have to be done otherwise. >> 528: final byte[] hashBuf; > > I'm a little worried about the mutability of `hashBuf` and whether it's suitable to be put inside `LMOTSParams`. By using `of` to return an `LMOTSParams` object we have the chance to return cached objects in the future. There should always be one `hashBuf` for each LM-OTS verification, and this is not clear from the current code. How will the performance change if we make `hashbufSha256_24` and `hashbufSha256_32` static and each time we want to verify an LM-OTS signature we clone one of them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187651985 From weijun at openjdk.org Mon May 8 16:51:35 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:51:35 GMT Subject: RFR: 8297878: KEM: Implementation [v14] In-Reply-To: References: <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@github.com> Message-ID: <0hPStmab_JXqCsAPhyC9Bk706LWHDMBVPn2sInf4_Uk=.8dd2ae39-faa5-40d6-a02b-41be58e002ce@github.com> On Fri, 14 Apr 2023 16:33:48 GMT, Xue-Lei Andrew Fan wrote: >> I added another proposal in you PR at https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798. > >> I added another proposal in you PR at [#13470 (comment)](https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798). > > I like the idea to use abstract class. The concerns about provider() method get addressed. I take back the proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1187661073 From weijun at openjdk.org Mon May 8 16:51:36 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 16:51:36 GMT Subject: RFR: 8297878: KEM: Implementation [v14] In-Reply-To: <0hPStmab_JXqCsAPhyC9Bk706LWHDMBVPn2sInf4_Uk=.8dd2ae39-faa5-40d6-a02b-41be58e002ce@github.com> References: <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@github.com> <0hPStmab_JXqCsAPhyC9Bk706LWHDMBVPn2sInf4_Uk=.8dd2ae39-faa5-40d6-a02b-41be58e002ce@github.com> Message-ID: On Mon, 8 May 2023 16:47:48 GMT, Weijun Wang wrote: >>> I added another proposal in you PR at [#13470 (comment)](https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798). >> >> I like the idea to use abstract class. The concerns about provider() method get addressed. > > I take back the proposal. I take back the proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1187661541 From mpowers at openjdk.org Mon May 8 16:55:42 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 8 May 2023 16:55:42 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com> Message-ID: On Mon, 8 May 2023 16:16:23 GMT, Weijun Wang wrote: >> Ok. Try to keep your line lengths to about 80 chars. > > I think so too. This class is only used by tests now so it will not have any negative performance impact on real users. If we want to move it into the public one day then we don't need to update it. The test currently converts input keys into RawKeySpec and x509 objects and performs verification on both. RawKeySpec is nice but I could live without it if I had to. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187665316 From weijun at openjdk.org Mon May 8 17:22:53 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 17:22:53 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v2] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: cleanup commented out code and unnecessary bug id ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/b99d0a1d..6cde121b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From mdonovan at openjdk.org Mon May 8 17:56:41 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 8 May 2023 17:56:41 GMT Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate [v2] In-Reply-To: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com> References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com> Message-ID: > I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes. Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into sun.security.ssl - 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate ------------- Changes: https://git.openjdk.org/jdk/pull/13495/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13495&range=01 Stats: 2221 lines in 22 files changed: 162 ins; 1724 del; 335 mod Patch: https://git.openjdk.org/jdk/pull/13495.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13495/head:pull/13495 PR: https://git.openjdk.org/jdk/pull/13495 From vlivanov at openjdk.org Mon May 8 18:02:33 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 8 May 2023 18:02:33 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <_QCxNp2slZ7n9AQvfzl_a8ftbokD6fD44f6a538jsO0=.b7c658df-5a6e-42f6-b80b-4e09398f3d79@github.com> On Mon, 1 May 2023 20:20:51 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address part of PR review 4 & fix a bug setting only_candidate > - Catching up with master > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Fix tests. Remember previous reducible Phis. > - Address PR review 3. Some comments and be able to abort compilation. > - Merge with Master > - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. > - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. > - Add support for SR'ing some inputs of merges used for field loads > - Fix some typos and do some small refactorings. > - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 It took longer than I expected, but I finished looking into debug info. A couple of minor comments first: * Please, ensure that the AllocationMergesTests.java has cases to trigger the case when SRs and NSRs meet at a merge point. I was not able to provoke it with the unit test. * diagnostic output becomes much harder to read (sample output follows). Sample output: - ordniary SR case Expression stack - @0: obj: ID=1335, only_merge_candidate=0, skip_field_assignment=0, N.Fields=4, klass: java.lang.String Fields: 0, 0, 0, nullptr ... Objects obj: ID=1335, only_merge_candidate=0, skip_field_assignment=0, N.Fields=4, klass: java.lang.String Fields: 0, 0, 0, nullptr - mixed merge case: ScopeDesc(pc=0x00000001080bc664 offset=1824): java.lang.String::substring at 8 (line 2830) Locals - l0: merge: ID=1781, N.Candidates=1 ... Objects merge: ID=1781, N.Candidates=1obj: ID=1782, only_merge_candidate=1, skip_field_assignment=0, N.Fields=4, klass: java.lang.String Fields: 0, 0, 0, reg rfp [58],oop ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1538801137 From vlivanov at openjdk.org Mon May 8 18:24:24 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 8 May 2023 18:24:24 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 1 May 2023 20:20:51 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address part of PR review 4 & fix a bug setting only_candidate > - Catching up with master > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Fix tests. Remember previous reducible Phis. > - Address PR review 3. Some comments and be able to abort compilation. > - Merge with Master > - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. > - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. > - Add support for SR'ing some inputs of merges used for field loads > - Fix some typos and do some small refactorings. > - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 Speaking of debug info design, it seems there's a need for an additional transformation step now. Originally, all the operations were performed right on the deserialized debug info representation. It was well-justified at first, but slowly accrued with special cases (nulls, autobox, vectors) and merges push it over the limit IMO. I propose to introduce an additional pass which takes original debug info and, based on current JVM state (`frame` + `RegisterMap`), transforms it into a list of objects to be materialized and a graph of `ScopeValue`s which depend on them. It would isolate preprocessing logic you have scattered across multiple places, simplify rematerialization, make it easier to find out what happens during deoptimizaiton in each particular case. Moreover, it'll enable support for more complex scenarios (e.g., nested merges) which I expect to eventually emerge in followup enhancements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1538835019 From valeriep at openjdk.org Mon May 8 18:50:25 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 8 May 2023 18:50:25 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Fri, 5 May 2023 22:59:06 GMT, Weijun Wang wrote: >> Hmm, I think the rest of chain should still be checked and removed if no dependents for them. > > Of course, I was only talking about the final return value. > > And, I take back my words. This method should return true no matter what `destroyIt` is. The return value is only used in `deleteEntry` and it should be true even if the.cert is used elsewhere. Yes, I also think that true should be returned regardless of the destroyIt value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1187775836 From valeriep at openjdk.org Mon May 8 19:02:15 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 8 May 2023 19:02:15 GMT Subject: RFR: 8168469: Memory leak in JceSecurity In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev wrote: > Hi all, > > I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME. > > The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap, Object>` instead of `IdentityHashMap`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper `objects that maintained the object identity while improved performance. > > The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called. > > `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers. > > I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test. > > Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions > > [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html > [2] https://bugs.openjdk.org/browse/JDK-8168469 > [3] https://bugs.openjdk.org/browse/JDK-7107615 > [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0 Ok, I will take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13658#issuecomment-1538884786 From mpowers at openjdk.org Mon May 8 20:16:44 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 8 May 2023 20:16:44 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 16:24:27 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing more review comments from @wangweij and @seanjmullan > > src/java.base/share/classes/sun/security/provider/HSS.java line 240: > >> 238: public final static int LMS_SHA256_M32_H20 = 8; >> 239: public final static int LMS_SHA256_M32_H25 = 9; >> 240: public final static int LMS_SHA256_M24_H5 = 10; > > Shall we remove the SHA256_M24 and SHAKE constants at the moment? I think unused code is a distraction. That said, SHA256_M24 used to work. Can't we be better than BC and support M24? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187853903 From mullan at openjdk.org Mon May 8 20:48:26 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 8 May 2023 20:48:26 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v2] In-Reply-To: References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: On Mon, 8 May 2023 17:22:53 GMT, Weijun Wang wrote: >> Update XML Security for Java to 3.0.2. Some change to tests: >> >> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. >> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > cleanup commented out code and unnecessary bug id src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java line 63: > 61: public interface SignatureMethod extends XMLStructure, AlgorithmMethod { > 62: > 63: // All methods can be found in RFC 9231. Only the ones with "xmldsig-more" in the URI, actually. src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java line 260: > 258: /** > 259: * The > 260: * ED25519 signature method algorithm URI. I think it would be beneficial to add a reference to the standards. Most of these URIs are defined in RFC 9131, but a few are from the W3C Recommendation. I suggest adding the following sentence to the class description: "The signature method algorithm URIs defined in this class are specified in the [W3C Recommendation for XML-Signature Syntax and Processing](http://www.w3.org/TR/xmldsig-core/) and [RFC 9131](https://www.rfc-editor.org/info/rfc9131)." test/jdk/javax/xml/crypto/dsig/GenerationTests.java line 105: > 103: rsaSha1mgf1, rsaSha224mgf1, rsaSha256mgf1, rsaSha384mgf1, rsaSha512mgf1, > 104: rsaShaPSS, > 105: ed25519, ed448; Nit: combine these lines. test/jdk/javax/xml/crypto/dsig/XalanTest.java line 1: > 1: /* Can you add a comment to this test with more details, something like: "This test used to be part of ValidationTests but was moved into its own test because it tests a signature that contains the `here()` function which depends on Xalan internals. The Xalan dependency has been removed from the DSig implementation but can be optionally configured ..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187870857 PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187866459 PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187845348 PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187862788 From mullan at openjdk.org Mon May 8 21:17:22 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 8 May 2023 21:17:22 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v2] In-Reply-To: <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com> References: <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com> Message-ID: <7mQCRQeIcvwi9Z6MTZeJ_yVtbW-fi_B4LnBL9bda3Uw=.df13a05f-2b45-48cb-9325-7c23a28b14e6@github.com> On Fri, 5 May 2023 01:21:32 GMT, Valerie Peng wrote: >> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. >> >> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. >> >> CSR has been filed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Add NPE for SecureRandom(byte[]) ctor and setSeed(byte[]) method. test/jdk/sun/security/pkcs11/SecureRandom/NextBytesNull.java line 1: > 1: /* Since the null checks are now all in `SecureRandom`, it doesn't seem that useful to check the individual providers. Maybe combine these tests and just check that the API methods throw NPE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1187904659 From weijun at openjdk.org Mon May 8 22:23:44 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 May 2023 22:23:44 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v3] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more comment and spec refine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/6cde121b..3854752d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=01-02 Stats: 28 lines in 4 files changed: 19 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From cslucas at openjdk.org Mon May 8 22:53:31 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 8 May 2023 22:53:31 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <4PBnXq7Eci77beY5cjMGEiuqpRfDcQF9Hwln0ADgDb4=.20c74eb7-f7f8-46be-a005-34dbfd5cdd96@github.com> On Mon, 8 May 2023 18:21:09 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Fix tests. Remember previous reducible Phis. >> - Address PR review 3. Some comments and be able to abort compilation. >> - Merge with Master >> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. >> - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. >> - Add support for SR'ing some inputs of merges used for field loads >> - Fix some typos and do some small refactorings. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 > > Speaking of debug info design, it seems there's a need for an additional transformation step now. > > Originally, all the operations were performed right on the deserialized debug info representation. It was well-justified at first, but slowly accrued with special cases (nulls, autobox, vectors) and merges push it over the limit IMO. > > I propose to introduce an additional pass which takes original debug info and, based on current JVM state (`frame` + `RegisterMap`), transforms it into a list of objects to be materialized and a graph of `ScopeValue`s which depend on them. It would isolate preprocessing logic you have scattered across multiple places, simplify rematerialization, make it easier to find out what happens during deoptimizaiton in each particular case. Moreover, it'll enable support for more complex scenarios (e.g., nested merges) which I expect to eventually emerge in followup enhancements. Thank you @iwanowww for taking the time to review this! Please let me ask you some clarifying questions. > A couple of minor comments first [...] I'll address those asap! Thanks. > I propose to introduce an additional pass which takes original debug info [...] What kind of pass are you referring to exactly? When would this pass run? By "original debug info" you mean the debug information stream? > It would isolate preprocessing logic you have scattered across multiple places [...] Which preprocessing logic are you referring to exactly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1539161396 From vlivanov at openjdk.org Tue May 9 00:06:33 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 9 May 2023 00:06:33 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 1 May 2023 20:20:51 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Address part of PR review 4 & fix a bug setting only_candidate > - Catching up with master > > Merge remote-tracking branch 'origin/master' into rematerialization-of-merges > - Fix tests. Remember previous reducible Phis. > - Address PR review 3. Some comments and be able to abort compilation. > - Merge with Master > - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. > - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. > - Add support for SR'ing some inputs of merges used for field loads > - Fix some typos and do some small refactorings. > - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 The new pass over deserialized debug info would adapt `ScopeDesc::objects()` (initialized by `decode_object_values(obj_decode_offset)` and accesses through `chunk->at(0)->scope()->objects()`) and produce 2 lists: * new list of objects which enumerates all scalarized instances which needs to be rematerialized; * complete set of objects referenced in the current scope (the purpose `chunk->at(0)->scope()->objects()` serves now). It should be performed before `rematerialize_objects`. By preprocessing I mean all the conditional checks before it is attempted to reallocate an `ObjectValue`. By the end of the new pass, it should be enough to just iterate over the new list of scalarized instances in `Deoptimization::realloc_objects`. And after `Deoptimization::realloc_objects` and `Deoptimization::reassign_fields` are over, debug info should be ready to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1539210279 From mdonovan at openjdk.org Tue May 9 11:16:16 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 9 May 2023 11:16:16 GMT Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate [v2] In-Reply-To: References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com> Message-ID: On Mon, 8 May 2023 17:56:41 GMT, Matthew Donovan wrote: >> I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into sun.security.ssl > - 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate Could someone review this, please? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13495#issuecomment-1539978310 From duke at openjdk.org Tue May 9 12:45:27 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:27 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: agreeing with the newest review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/b8064640..68ab57b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=06-07 Stats: 269 lines in 1 file changed: 84 ins; 116 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From duke at openjdk.org Tue May 9 12:45:33 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:33 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: <9oyYOfazlu7cyszP6M-EeJ1q8HrkgBwOilN_YcJPV5Y=.ccfafdc1-8262-411d-8a76-90a62c3278ff@github.com> References: <9oyYOfazlu7cyszP6M-EeJ1q8HrkgBwOilN_YcJPV5Y=.ccfafdc1-8262-411d-8a76-90a62c3278ff@github.com> Message-ID: <5za3DV_aGB2MYCgO3BGSn8ay7FKaVl2ZB_vhu5kWvzA=.e2d5b97a-517e-4fbd-9d8d-8840d3dfe9a2@github.com> On Mon, 8 May 2023 16:13:01 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing more review comments from @wangweij and @seanjmullan > > src/java.base/share/classes/sun/security/provider/HSS.java line 99: > >> 97: result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); >> 98: return result; >> 99: } catch (Exception e) { > > Do we need this `catch`? I think only `SignatureException` can be thrown inside the `try` block. No, we don't. Removed. > src/java.base/share/classes/sun/security/provider/HSS.java line 383: > >> 381: final byte[] sigArr; >> 382: >> 383: public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws SignatureException { > > The methods of `LMSignature` can be package-private. Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534132 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534269 From duke at openjdk.org Tue May 9 12:45:38 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:38 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: <3kJX5uh8UxbY852mLsh2XivNSl7jfVnx6M6m3LAHvsk=.119f255f-b4bb-483f-b967-9e93550983d4@github.com> References: <3kJX5uh8UxbY852mLsh2XivNSl7jfVnx6M6m3LAHvsk=.119f255f-b4bb-483f-b967-9e93550983d4@github.com> Message-ID: On Mon, 8 May 2023 16:29:49 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing more review comments from @wangweij and @seanjmullan > > src/java.base/share/classes/sun/security/provider/HSS.java line 106: > >> 104: } >> 105: >> 106: protected boolean lmsVerify(LMSPublicKey lmsPublicKey, LMSignature sig, byte[] message) throws SignatureException { > > We probably should put this method into an inner class and make it static. Good idea. I moved it to LMSUtils. > src/java.base/share/classes/sun/security/provider/HSS.java line 158: > >> 156: } >> 157: return lmsPublicKey.isT1(tmpMsg, 22 + m); >> 158: } catch (Exception e) { > > Avoid using `catch (Exception e)` because that's too wide. In fact, here it seems the only checked exceptions that can be caught is `NoSuchAlgorithmException | DigestException`. I think we've agreed to throw `ProviderException` for them. Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188533636 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188533908 From duke at openjdk.org Tue May 9 12:45:41 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:41 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 21:13:24 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 181: > >> 179: try { >> 180: lmParams = new LMParams(type); >> 181: lmotsParams = LMOTSParams.of(otsType); > > Try to code `LMParams` and `LMOTSParams` the same style by choosing from using a constructor or static `of` method. Should `LMParams` be renamed to `LMSParams`? Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 294: > >> 292: LMOTSignature(byte[] sigArray, LMOTSParams lmotsParams) throws InvalidParameterException { >> 293: int inLen = sigArray.length; >> 294: if (inLen < 4) > > Add braces around the one-line block. Same as in lines 300, 173, 461, 472, 487, 569, 571, and 783. Done > src/java.base/share/classes/sun/security/provider/HSS.java line 357: > >> 355: break; >> 356: >> 357: /* > > Remove commented-out lines if they cannot be supported on time. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534977 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188535603 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188535363 From duke at openjdk.org Tue May 9 12:45:47 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:47 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v7] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:14:01 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 240: >> >>> 238: public final static int LMS_SHA256_M32_H20 = 8; >>> 239: public final static int LMS_SHA256_M32_H25 = 9; >>> 240: public final static int LMS_SHA256_M24_H5 = 10; >> >> Shall we remove the SHA256_M24 and SHAKE constants at the moment? > > I think unused code is a distraction. That said, SHA256_M24 used to work. Can't we be better than BC and support M24? I have removed everything that is not SHA-256, but kept a version of the code that has all those removed things so that in case we decide to put it back, it will be there in my work tree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188533796 From duke at openjdk.org Tue May 9 12:45:48 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:48 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 16:38:01 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 528: >> >>> 526: // update()-digest() sequence) which is parametrized so that the digest output is copied back into this buffer. >>> 527: // This way, we avoid memory allocations and some computations that would have to be done otherwise. >>> 528: final byte[] hashBuf; >> >> I'm a little worried about the mutability of `hashBuf` and whether it's suitable to be put inside `LMOTSParams`. By using `of` to return an `LMOTSParams` object we have the chance to return cached objects in the future. There should always be one `hashBuf` for each LM-OTS verification, and this is not clear from the current code. > > How will the performance change if we make `hashbufSha256_24` and `hashbufSha256_32` static and each time we want to verify an LM-OTS signature we clone one of them? Changed. There should not be noticeable performance difference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534788 From duke at openjdk.org Tue May 9 12:45:44 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 9 May 2023 12:45:44 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: <-3epbCTTZfCU9BzyGqAlRmayTPkzOZhDI5dIAFp9g-M=.091cc064-30d1-408e-9d00-cf93001366aa@github.com> On Mon, 8 May 2023 14:14:42 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> adding key translation, finally block, removing 24-byte LMOTS parameters > > src/java.base/share/classes/sun/security/provider/HSS.java line 229: > >> 227: >> 228: static class LMSUtils { >> 229: public final static int LMS_RESERVED = 0; > > The statics and methods of `LMSUtils` can all be package-private. Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534400 From weijun at openjdk.org Tue May 9 13:33:34 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 13:33:34 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 97: > 95: > 96: result &= LMSUtils.lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); > 97: messageStream.reset(); We still need the `messageStream.reset()` call in a `finally` block even if there is no `catch` block. It must be called even if an exception is thrown. src/java.base/share/classes/sun/security/provider/HSS.java line 376: > 374: qArr = Arrays.copyOfRange(sigArray, offset, offset + 4); > 375: sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4); > 376: lmotsParams = LMOTSParams.of(sigOtsType); Only this single line needs to be put in the `try` block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188599102 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188603688 From mullan at openjdk.org Tue May 9 13:33:35 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 May 2023 13:33:35 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 654: > 652: } > 653: > 654: static class HSSPublicKey extends X509Key implements Length { Is there a significant value in extending `X509Key`? I think that is primarily to help in the parsing by calling `super()`, but you are not using that. You could override `toString()`, `getFormat()`, `getEncoded()`, etc and probably get the same functionality. @wangweij any thoughts on this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188605020 From weijun at openjdk.org Tue May 9 13:40:28 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 13:40:28 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 474: > 472: sha256Fix = new SHA2.SHA256(); > 473: } else { > 474: sha256Fix = null; Or, shall we throw a `ProviderException` or even an `AssertionError` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188613928 From weijun at openjdk.org Tue May 9 13:59:36 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 13:59:36 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 101: > 99: } > 100: > 101: static class LMSPublicKey implements Serializable { Add a `writeReplace` method. Look at other `PublicKey` implementations for an example. src/java.base/share/classes/sun/security/provider/HSS.java line 540: > 538: throw new ProviderException("Digest implementation not found", e); > 539: } > 540: byte[] result = new byte[md.getDigestLength()]; No need to allocate an array here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188643495 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188630397 From mullan at openjdk.org Tue May 9 13:59:37 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 May 2023 13:59:37 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 661: > 659: > 660: @SuppressWarnings("deprecation") > 661: HSSPublicKey(byte[] keyArray) throws InvalidKeyException { [I deleted my earlier comment] I am wondering why you don't call `super()` or `decode()` and override `parseKeyBits()` like other `X509Key` subclasses. You should also override `writeReplace` so that serialization uses an alternate form when serializing. It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188615922 From weijun at openjdk.org Tue May 9 14:06:34 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 14:06:34 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 114: > 112: } > 113: > 114: public LMSPublicKey(byte[] keyArray, int offset, boolean checkExactLength) throws InvalidKeyException { Two methods are still public. src/java.base/share/classes/sun/security/provider/HSS.java line 255: > 253: final int otSigType; > 254: final LMOTSParams lmotsParams; > 255: final int n; `n` and `p` can be private. src/java.base/share/classes/sun/security/provider/HSS.java line 291: > 289: > 290: static class LMSParams { > 291: final int type; `type` is actually used nowhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188651785 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188648524 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188652844 From weijun at openjdk.org Tue May 9 14:30:06 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 14:30:06 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com> On Tue, 9 May 2023 13:38:42 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> agreeing with the newest review comments > > src/java.base/share/classes/sun/security/provider/HSS.java line 661: > >> 659: >> 660: @SuppressWarnings("deprecation") >> 661: HSSPublicKey(byte[] keyArray) throws InvalidKeyException { > > [I deleted my earlier comment] > > I am wondering why you don't call `super()` or `decode()` and override `parseKeyBits()` like other `X509Key` subclasses. > > You should also override `writeReplace` so that serialization uses an alternate form when serializing. > > It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details. Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188692818 From xuelei at openjdk.org Tue May 9 14:30:09 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 9 May 2023 14:30:09 GMT Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate [v2] In-Reply-To: References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com> Message-ID: On Mon, 8 May 2023 17:56:41 GMT, Matthew Donovan wrote: >> I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into sun.security.ssl > - 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13495#pullrequestreview-1418772038 From mdonovan at openjdk.org Tue May 9 14:30:11 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 9 May 2023 14:30:11 GMT Subject: Integrated: 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate In-Reply-To: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com> References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com> Message-ID: On Mon, 17 Apr 2023 13:27:12 GMT, Matthew Donovan wrote: > I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes. This pull request has now been integrated. Changeset: 5842fd5b Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/5842fd5beb13f3458f61df7e7480a54bd2157253 Stats: 2221 lines in 22 files changed: 162 ins; 1724 del; 335 mod 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/13495 From weijun at openjdk.org Tue May 9 14:40:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 14:40:40 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > agreeing with the newest review comments src/java.base/share/classes/sun/security/provider/HSS.java line 47: > 45: > 46: @Deprecated > 47: protected void engineSetParameter(String param, Object value) { Better to add `@Override` as much as you can. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188709964 From mullan at openjdk.org Tue May 9 15:04:19 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 May 2023 15:04:19 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 13:15:32 GMT, Jamil Nimeh wrote: >> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. >> >> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). >> >> JBS: https://bugs.openjdk.org/browse/JDK-8179502 >> CSR: https://bugs.openjdk.org/browse/JDK-8300722 > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Add 's' suffix to allowed syntax I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`. src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 1: > 1: /* I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13762#issuecomment-1540310480 PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1188745318 From mullan at openjdk.org Tue May 9 15:21:29 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 May 2023 15:21:29 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v3] In-Reply-To: References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: On Mon, 8 May 2023 22:23:44 GMT, Weijun Wang wrote: >> Update XML Security for Java to 3.0.2. Some change to tests: >> >> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. >> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more comment and spec refine test/jdk/javax/xml/crypto/dsig/XalanTest.java line 105: > 103: if (!validator.validate("signature.xml", ks, new HttpURIDereferencer(), false)) { > 104: throw new Exception > 105: ("At least one signature did not validate as expected"); There's only one signature in this test now, so change message to "Signature did not validate as expected". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1188766257 From jnimeh at openjdk.org Tue May 9 15:59:34 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 9 May 2023 15:59:34 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 15:01:29 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Add 's' suffix to allowed syntax > > src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 1: > >> 1: /* > > I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set. Yes, I noticed that too. I wasn't sure if we needed to make a change there. I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of. All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values. So in practice much of the time they are all 2x. It's easy enough I think to make a separate property for `com.sun.security.ocsp.readtimeout` and then the existing `.timeout` property would be for connect timeouts (keeping in line with the other props). I don't think it will introduce significant risk but I will highlight that in the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1188816429 From jnimeh at openjdk.org Tue May 9 15:59:34 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 9 May 2023 15:59:34 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 15:55:24 GMT, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 1: >> >>> 1: /* >> >> I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set. > > Yes, I noticed that too. I wasn't sure if we needed to make a change there. I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of. All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values. So in practice much of the time they are all 2x. > > It's easy enough I think to make a separate property for `com.sun.security.ocsp.readtimeout` and then the existing `.timeout` property would be for connect timeouts (keeping in line with the other props). I don't think it will introduce significant risk but I will highlight that in the CSR. > I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`. I will look into this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1188817169 From weijun at openjdk.org Tue May 9 16:11:38 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 16:11:38 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v3] In-Reply-To: References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: On Tue, 9 May 2023 15:16:07 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more comment and spec refine > > test/jdk/javax/xml/crypto/dsig/XalanTest.java line 105: > >> 103: if (!validator.validate("signature.xml", ks, new HttpURIDereferencer(), false)) { >> 104: throw new Exception >> 105: ("At least one signature did not validate as expected"); > > There's only one signature in this test now, so change message to "Signature did not validate as expected". Oops. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1188831040 From xuelei at openjdk.org Tue May 9 16:34:11 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 9 May 2023 16:34:11 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v3] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Wed, 3 May 2023 22:11:20 GMT, Kevin Driver wrote: > I will look at making related changes in these spots as well. > OK. > @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method. Changing the signature should be fine as it is a internal method. But I'm fine if the calls to getAuthorities() have considered the impact of illegal values of X500Principal. Anyway, this is a typical example to show how hard to use runtime exception. From the viewpoint of X500Principal, and unchecked exception should be thrown for invalid input values. But for the caller, it may need to check the input values for sure everything is good. However, an unchecked exception cannot be detected by Java compiler and thus the checking of unchecked exception could be missed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1540501498 From cslucas at openjdk.org Tue May 9 19:06:36 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 9 May 2023 19:06:36 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Tue, 9 May 2023 00:03:26 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Fix tests. Remember previous reducible Phis. >> - Address PR review 3. Some comments and be able to abort compilation. >> - Merge with Master >> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. >> - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. >> - Add support for SR'ing some inputs of merges used for field loads >> - Fix some typos and do some small refactorings. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 > > The new pass over deserialized debug info would adapt `ScopeDesc::objects()` (initialized by `decode_object_values(obj_decode_offset)` and accesses through `chunk->at(0)->scope()->objects()`) and produce 2 lists: > * new list of objects which enumerates all scalarized instances which needs to be rematerialized; > * complete set of objects referenced in the current scope (the purpose `chunk->at(0)->scope()->objects()` serves now). > > It should be performed before `rematerialize_objects`. > > By preprocessing I mean all the conditional checks before it is attempted to reallocate an `ObjectValue`. By the end of the new pass, it should be enough to just iterate over the new list of scalarized instances in `Deoptimization::realloc_objects`. And after `Deoptimization::realloc_objects` and `Deoptimization::reassign_fields` are over, debug info should be ready to go. Thanks a lot for clarifying @iwanowww . I'll start working on that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1540738709 From weijun at openjdk.org Tue May 9 19:50:44 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 19:50:44 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v4] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: no more secret exports, one message change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/3854752d..e3f7f632 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=02-03 Stats: 18 lines in 2 files changed: 0 ins; 16 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From weijun at openjdk.org Tue May 9 20:48:18 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 May 2023 20:48:18 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v5] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: comment for new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/e3f7f632..b4cf0070 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From mark.reinhold at oracle.com Tue May 9 21:39:18 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 9 May 2023 21:39:18 +0000 Subject: New candidate JEP: 452: Key Encapsulation Mechanism API Message-ID: <20230509213917.1FCCA5D4CBC@eggemoggin.niobe.net> https://openjdk.org/jeps/452 Summary: Introduce an API for key encapsulation mechanisms (KEMs), an encryption technique for securing symmetric keys using public key cryptography. - Mark From valeriep at openjdk.org Tue May 9 23:41:15 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 9 May 2023 23:41:15 GMT Subject: RFR: 8168469: Memory leak in JceSecurity In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev wrote: > Hi all, > > I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME. > > The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap, Object>` instead of `IdentityHashMap`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper `objects that maintained the object identity while improved performance. > > The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called. > > `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers. > > I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test. > > Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions > > [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html > [2] https://bugs.openjdk.org/browse/JDK-8168469 > [3] https://bugs.openjdk.org/browse/JDK-7107615 > [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0 Rest looks good to me. Thanks! src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 217: > 215: // recursion; return failure now > 216: throw new IllegalStateException > 217: ("Recursion during verification"); nit: no need for repeating error message here since it's not really used in line 242 anyway. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13658#pullrequestreview-1419581596 PR Review Comment: https://git.openjdk.org/jdk/pull/13658#discussion_r1189220726 From duke at openjdk.org Wed May 10 10:03:46 2023 From: duke at openjdk.org (Sergey Chernyshev) Date: Wed, 10 May 2023 10:03:46 GMT Subject: RFR: 8168469: Memory leak in JceSecurity [v2] In-Reply-To: References: Message-ID: > Hi all, > > I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME. > > The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap, Object>` instead of `IdentityHashMap`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper `objects that maintained the object identity while improved performance. > > The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called. > > `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers. > > I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test. > > Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions > > [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html > [2] https://bugs.openjdk.org/browse/JDK-8168469 > [3] https://bugs.openjdk.org/browse/JDK-7107615 > [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0 Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: addressed review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13658/files - new: https://git.openjdk.org/jdk/pull/13658/files/f8404bd5..ffea537b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13658&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13658&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13658/head:pull/13658 PR: https://git.openjdk.org/jdk/pull/13658 From duke at openjdk.org Wed May 10 10:03:47 2023 From: duke at openjdk.org (Sergey Chernyshev) Date: Wed, 10 May 2023 10:03:47 GMT Subject: RFR: 8168469: Memory leak in JceSecurity [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 23:37:05 GMT, Valerie Peng wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed review comment > > src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 217: > >> 215: // recursion; return failure now >> 216: throw new IllegalStateException >> 217: ("Recursion during verification"); > > nit: no need for repeating error message here since it's not really used in line 242 anyway. Thank you! I updated the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13658#discussion_r1189668166 From jpai at openjdk.org Wed May 10 12:28:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 10 May 2023 12:28:30 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review comment - use SSLContextTemplate for SSLContext creation in test Looking for additional reviews on this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13669#issuecomment-1542117693 From duke at openjdk.org Wed May 10 15:20:50 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 10 May 2023 15:20:50 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: serialization fixes, more code shaping ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/68ab57b2..b363ce7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=07-08 Stats: 114 lines in 1 file changed: 61 ins; 20 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From duke at openjdk.org Wed May 10 15:20:53 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 10 May 2023 15:20:53 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 14:37:36 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> agreeing with the newest review comments > > src/java.base/share/classes/sun/security/provider/HSS.java line 47: > >> 45: >> 46: @Deprecated >> 47: protected void engineSetParameter(String param, Object value) { > > Better to add `@Override` as much as you can. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 97: > >> 95: >> 96: result &= LMSUtils.lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray()); >> 97: messageStream.reset(); > > We still need the `messageStream.reset()` call in a `finally` block even if there is no `catch` block. It must be called even if an exception is thrown. Reintroduced try/finally. > src/java.base/share/classes/sun/security/provider/HSS.java line 114: > >> 112: } >> 113: >> 114: public LMSPublicKey(byte[] keyArray, int offset, boolean checkExactLength) throws InvalidKeyException { > > Two methods are still public. One removed, the other changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 255: > >> 253: final int otSigType; >> 254: final LMOTSParams lmotsParams; >> 255: final int n; > > `n` and `p` can be private. Changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 376: > >> 374: qArr = Arrays.copyOfRange(sigArray, offset, offset + 4); >> 375: sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4); >> 376: lmotsParams = LMOTSParams.of(sigOtsType); > > Only this single line needs to be put in the `try` block. OK. > src/java.base/share/classes/sun/security/provider/HSS.java line 474: > >> 472: sha256Fix = new SHA2.SHA256(); >> 473: } else { >> 474: sha256Fix = null; > > Or, shall we throw a `ProviderException` or even an `AssertionError` here? Doesn't really matter as now it can never be null. I left in the if() in preparation of adding the SHAKE version, but I removed it now. > src/java.base/share/classes/sun/security/provider/HSS.java line 540: > >> 538: throw new ProviderException("Digest implementation not found", e); >> 539: } >> 540: byte[] result = new byte[md.getDigestLength()]; > > No need to allocate an array here. True. Removed allocation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190064400 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190060922 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190061753 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190061961 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190062147 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190062330 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190062543 From duke at openjdk.org Wed May 10 15:20:53 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 10 May 2023 15:20:53 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com> References: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com> Message-ID: <9Ul0pXZe7p6zw0tCX8G3jc8thPuLhDRaXw11QnRb1sM=.46a9281c-0568-45ef-8f37-f7124634ffaf@github.com> On Tue, 9 May 2023 14:26:46 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 661: >> >>> 659: >>> 660: @SuppressWarnings("deprecation") >>> 661: HSSPublicKey(byte[] keyArray) throws InvalidKeyException { >> >> [I deleted my earlier comment] >> >> I am wondering why you don't call `super()` or `decode()` and override `parseKeyBits()` like other `X509Key` subclasses. >> >> You should also override `writeReplace` so that serialization uses an alternate form when serializing. >> >> It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details. > > Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable. Overrided writeReplace, toString() and parseKeyBits(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190063347 From mullan at openjdk.org Wed May 10 15:55:27 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 10 May 2023 15:55:27 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v3] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Tue, 9 May 2023 16:30:22 GMT, Xue-Lei Andrew Fan wrote: >> As for other examples of the `X500Principal(byte[] ..)` constructor being called in TLS packages, here are the ones that don't seem to be handled nicely currently: >> >> - `consume` in `CertificateAuthoritiesExtension.CRCertificateAuthoritiesConsumer` (could throw IAE, which is an uncaught RuntimeException) >> - `toString` in `CertificateAuthoritiesExtension.CertificateAuthoritiesSpec` (could throw IAE, which is an uncaught RuntimeException) >> - `consume` in `CertificateRequest.T10CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException) >> - `toString` in `CertificateRequest.T10CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException) >> - `consume` in `CertificateRequest.T12CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException) >> - `toString` in `CertificateRequest.T12CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException) >> >> I will look at making related changes in these spots as well. >> >> @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method. This may be fine, but similar changes would need to be made in all the above places anyway, I suspect, unless we can pass information about the context in order to throw an `SSL(Protocol)Exception` and have that bubble-up to where `IOException`s are usually checked. >> >> @seanjmullan @XueleiFan thoughts on that? > >> I will look at making related changes in these spots as well. >> > OK. > >> @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method. > > Changing the signature should be fine as it is a internal method. But I'm fine if the calls to getAuthorities() have considered the impact of illegal values of X500Principal. > > Anyway, this is a typical example to show how hard to use runtime exception. From the viewpoint of X500Principal, and unchecked exception should be thrown for invalid input values. But for the caller, it may need to check the input values for sure everything is good. However, an unchecked exception cannot be detected by Java compiler and thus the checking of unchecked exception could be missed. I would suggest catching the IAE and rethrowing as an IOE (with the IAE as the cause) if the data is coming from the network. If it is not coming from the network, then don't necessarily rethrow as the IAE could indicate a bug in the JSSE code. I agree with @XueleiFan that it is ok to change internal method signatures, by adding more parameters or throwing exceptions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1542441464 From valeriep at openjdk.org Wed May 10 18:04:15 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 10 May 2023 18:04:15 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v2] In-Reply-To: <7mQCRQeIcvwi9Z6MTZeJ_yVtbW-fi_B4LnBL9bda3Uw=.df13a05f-2b45-48cb-9325-7c23a28b14e6@github.com> References: <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com> <7mQCRQeIcvwi9Z6MTZeJ_yVtbW-fi_B4LnBL9bda3Uw=.df13a05f-2b45-48cb-9325-7c23a28b14e6@github.com> Message-ID: On Mon, 8 May 2023 21:14:39 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Add NPE for SecureRandom(byte[]) ctor and setSeed(byte[]) method. > > test/jdk/sun/security/pkcs11/SecureRandom/NextBytesNull.java line 1: > >> 1: /* > > Since the null checks are now all in `SecureRandom`, it doesn't seem that useful to check the individual providers. Maybe combine these tests and just check that the API methods throw NPE? Sounds reasonable, I will give it a try. Thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1190241279 From weijun at openjdk.org Wed May 10 21:27:58 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 May 2023 21:27:58 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > serialization fixes, more code shaping src/java.base/share/classes/sun/security/provider/HSS.java line 672: > 670: } > 671: > 672: static class HSSPublicKey extends X509Key implements Serializable { Why not implement `Length` anymore? This is useful when you want to print out information of the key or restrict weak keys. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190408445 From weijun at openjdk.org Wed May 10 22:13:56 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 May 2023 22:13:56 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > serialization fixes, more code shaping src/java.base/share/classes/sun/security/provider/HSS.java line 571: > 569: preCandidate[21] = (byte) 0x80; > 570: > 571: byte[] preZi = hashBuf.clone(); We can just call `hashbufSha256_32.clone()` here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190437259 From weijun at openjdk.org Wed May 10 22:20:59 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 May 2023 22:20:59 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:15:55 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 47: >> >>> 45: >>> 46: @Deprecated >>> 47: protected void engineSetParameter(String param, Object value) { >> >> Better to add `@Override` as much as you can. > > Done. There are much more in this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190440987 From valeriep at openjdk.org Wed May 10 23:07:01 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 10 May 2023 23:07:01 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v3] In-Reply-To: References: Message-ID: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com> > Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. > > Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. > > CSR has been filed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: updated reg test with review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13788/files - new: https://git.openjdk.org/jdk/pull/13788/files/34ebdfa7..3ee76896 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=01-02 Stats: 163 lines in 2 files changed: 83 ins; 80 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13788.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13788/head:pull/13788 PR: https://git.openjdk.org/jdk/pull/13788 From mpowers at openjdk.org Thu May 11 04:40:05 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 11 May 2023 04:40:05 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: <84M8kxMYfOJi32Wc13yevbm-e6tAjILd0gdLhvqfF-M=.25820c77-e2cd-4a2b-9402-80b6e6ea0432@github.com> On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > serialization fixes, more code shaping You might want to look at IntelliJ's suggestions (lower left Problems button). There are about 10 of them. The enhanced switch has a more "modern" look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1543320636 From duke at openjdk.org Thu May 11 05:56:57 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 11 May 2023 05:56:57 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > serialization fixes, more code shaping Just for the more modern look I don't think we should use newer language features that might make backporting the code to older versions harder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1543378745 From duke at openjdk.org Thu May 11 06:04:57 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 11 May 2023 06:04:57 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: <6NWVBkRp6Q7t4iUk45El2XbaLlfbqEFSVrfdDZgK1HI=.c8ebc0d1-2d4d-4f83-ad30-592ec99438f2@github.com> On Wed, 10 May 2023 22:11:09 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> serialization fixes, more code shaping > > src/java.base/share/classes/sun/security/provider/HSS.java line 571: > >> 569: preCandidate[21] = (byte) 0x80; >> 570: >> 571: byte[] preZi = hashBuf.clone(); > > We can just call `hashbufSha256_32.clone()` here. We'll think about what to do when more params are supported in the future, together with the next line. hashBuf is assigned at the initialisation of the LMOTSParams object. If (when) we introduce more algorithms, the initialisation code and the digestFixedLengthPreprocessed() code needs to be changed only (its first parameter should be such that it can use the hash algorithm that the object would be initialised to use). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190671593 From xuelei at openjdk.org Thu May 11 06:16:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 11 May 2023 06:16:55 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > serialization fixes, more code shaping src/java.base/share/classes/sun/security/provider/HSS.java line 165: > 163: } > 164: > 165: static class LMSUtils { It might be simpler and more efficient to use enum for lms and lmots types. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190680173 From duke at openjdk.org Thu May 11 06:30:55 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 11 May 2023 06:30:55 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 06:14:10 GMT, Xue-Lei Andrew Fan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> serialization fixes, more code shaping > > src/java.base/share/classes/sun/security/provider/HSS.java line 165: > >> 163: } >> 164: >> 165: static class LMSUtils { > > It might be simpler and more efficient to use enum for lms and lmots types. I had considered that and decided not to use it. In my opinion, Java Enum is much more complicated than it should be for this case. Efficiency is not a concern here, but I also don't see how enum could be more efficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190690480 From xuelei at openjdk.org Thu May 11 06:38:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 11 May 2023 06:38:55 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 06:27:39 GMT, Ferenc Rakoczi wrote: > I had considered that and decided not to use it. In my opinion, Java Enum is much more complicated than it should be for this case. OK. > Efficiency is not a concern here OK. > but I also don't see how enum could be more efficient. enum switch is O(1), while if-else not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190697557 From duke at openjdk.org Thu May 11 09:22:58 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 11 May 2023 09:22:58 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 22:17:52 GMT, Weijun Wang wrote: >> Done. > > There are much more in this class. You are right. I have added many more. I hope I have found all of them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190885719 From duke at openjdk.org Thu May 11 09:36:17 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 11 May 2023 09:36:17 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Reintroduced Length for HSSPublicKey, added more @Override annotations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/b363ce7f..b3ffdfd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=08-09 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From weijun at openjdk.org Thu May 11 12:38:59 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 12:38:59 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v9] In-Reply-To: <6NWVBkRp6Q7t4iUk45El2XbaLlfbqEFSVrfdDZgK1HI=.c8ebc0d1-2d4d-4f83-ad30-592ec99438f2@github.com> References: <6NWVBkRp6Q7t4iUk45El2XbaLlfbqEFSVrfdDZgK1HI=.c8ebc0d1-2d4d-4f83-ad30-592ec99438f2@github.com> Message-ID: On Thu, 11 May 2023 06:02:01 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 571: >> >>> 569: preCandidate[21] = (byte) 0x80; >>> 570: >>> 571: byte[] preZi = hashBuf.clone(); >> >> We can just call `hashbufSha256_32.clone()` here. We'll think about what to do when more params are supported in the future, together with the next line. > > hashBuf is assigned at the initialisation of the LMOTSParams object. If (when) we introduce more algorithms, the initialisation code and the digestFixedLengthPreprocessed() code needs to be changed only (its first parameter should be such that it can use the hash algorithm that the object would be initialised to use). That's OK. I see you already had `SHA2.SHA256 sha256 = new SHA2.SHA256()` as the next line and thought the selection of `hashBuf` and optimized hash impl will be local in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191113228 From weijun at openjdk.org Thu May 11 14:03:08 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 14:03:08 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduced Length for HSSPublicKey, added more @Override annotations src/java.base/share/classes/sun/security/provider/HSS.java line 728: > 726: @Override > 727: public int length() { > 728: return getKey().length(); Debatable. `getKey` now contains 2 (OCTET STRING header) + 4 (L) + 4 (LMS type) + 4 (LM-OTS type) + 16 (I) + 32 (T) bytes. Should the 2 header bytes be included in the length? Should all fields other than T be included? The length is mainly used to compare strength and I suggest we refrain from implementing this method unless a well-known definition is accepted for HSS/LMS. Table 2 of [NIST SP 800-57 Part 1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and they are defined by modulus size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191214837 From weijun at openjdk.org Thu May 11 15:15:01 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 15:15:01 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduced Length for HSSPublicKey, added more @Override annotations src/java.base/share/classes/sun/security/provider/HSS.java line 620: > 618: if (keySpec instanceof X509EncodedKeySpec x) { > 619: try { > 620: var val = new DerValue(new ByteArrayInputStream(x.getEncoded())); Do not use `ByteArrayInputStream`, just use `new DerValue(x.getEncoded())`. Otherwise, the encoding might contain extra garbage bytes at the end and we still accept it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191332259 From weijun at openjdk.org Thu May 11 15:22:12 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 15:22:12 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: <2ehkcLfIY06iHC-3wjJDKMWlbuxGCtZMr1NmtIL4io0=.60b80bb2-fafe-4123-8ad6-942ecd17721c@github.com> On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduced Length for HSSPublicKey, added more @Override annotations src/java.base/share/classes/sun/security/provider/HSS.java line 622: > 620: var val = new DerValue(new ByteArrayInputStream(x.getEncoded())); > 621: val.data.getDerValue(); > 622: return new HSSPublicKey(new DerValue(val.data.getBitString()).getOctetString()); The 2 lines above cannot detect wrong algorithm identifier and garbage data at the end. Now that you already have `parseBits` implementation, you should follow the usual `X509Key` convention to create a new `HSSPublicKey` constructor that takes in the whole encoding and call `decode` to decode it. See `ECKeyFactory` and `ECPublicKeyImpl.java` for an example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191340263 From mullan at openjdk.org Thu May 11 16:36:48 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 May 2023 16:36:48 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduced Length for HSSPublicKey, added more @Override annotations src/java.base/share/classes/sun/security/provider/HSS.java line 39: > 37: /* > 38: * This class implements the Hierarchical Signature System using the > 39: * Leighton-Micali Signatures (LMS) as described in RFC 8554 and NIST Special publication 800-208 Nit: add period at end of sentence. src/java.base/share/classes/sun/security/provider/HSS.java line 719: > 717: > 718: @java.io.Serial > 719: protected Object writeReplace() throws java.io.ObjectStreamException { I think the serialized form of an HSSPublicKey should also be specified in the CSR since this Key is returned from a standard API. I think you can add a simple sentence such as: "The Keys returned by an "HSS/LMS" `KeyFactory` are `Serializable` and use `java.security.KeyRep` as its serialized representation." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191420316 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191436386 From kdriver at openjdk.org Thu May 11 16:40:07 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 11 May 2023 16:40:07 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v5] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java Co-authored-by: Daniel Jelinski - updated copyright - fixes JDK-8294985: throw an SSLException wrapping the IAE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/33366412..87b47a03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=03-04 Stats: 99417 lines in 1498 files changed: 79732 ins; 8161 del; 11524 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From mullan at openjdk.org Thu May 11 17:11:15 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 May 2023 17:11:15 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com> References: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com> Message-ID: On Tue, 9 May 2023 14:26:46 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/provider/HSS.java line 661: >> >>> 659: >>> 660: @SuppressWarnings("deprecation") >>> 661: HSSPublicKey(byte[] keyArray) throws InvalidKeyException { >> >> [I deleted my earlier comment] >> >> I am wondering why you don't call `super()` or `decode()` and override `parseKeyBits()` like other `X509Key` subclasses. >> >> You should also override `writeReplace` so that serialization uses an alternate form when serializing. >> >> It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details. > > Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable. `L` should be `transient` too as @wangweij noted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191465361 From mullan at openjdk.org Thu May 11 17:11:18 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 May 2023 17:11:18 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduced Length for HSSPublicKey, added more @Override annotations src/java.base/share/classes/sun/security/provider/HSS.java line 698: > 696: @Override > 697: public String toString() { > 698: HexDumpEncoder encoder = new HexDumpEncoder(); Nit: one space after `HexDumpEncoder`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191466810 From mullan at openjdk.org Thu May 11 17:20:29 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 May 2023 17:20:29 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v3] In-Reply-To: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com> References: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com> Message-ID: On Wed, 10 May 2023 23:07:01 GMT, Valerie Peng wrote: >> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. >> >> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. >> >> CSR has been filed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > updated reg test with review comments. test/jdk/java/security/SecureRandom/NextBytesNull.java line 29: > 27: * @summary check NPE is thrown for various methods of SecureRandom class, > 28: * e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]). > 29: * @run main/othervm NextBytesNull Does this need to be run in othervm mode? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1191480288 From weijun at openjdk.org Thu May 11 17:31:48 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 17:31:48 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 16:33:25 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Reintroduced Length for HSSPublicKey, added more @Override annotations > > src/java.base/share/classes/sun/security/provider/HSS.java line 719: > >> 717: >> 718: @java.io.Serial >> 719: protected Object writeReplace() throws java.io.ObjectStreamException { > > I think the serialized form of an HSSPublicKey should also be specified in the CSR since this Key is returned from a standard API. I think you can add a simple sentence such as: > > "The Keys returned by an "HSS/LMS" `KeyFactory` are `Serializable` and use `java.security.KeyRep` as its serialized representation with the fields set as follows: type = `KeyRep.Type.PUBLIC`, algorithm = "HSS/LMS", format = "X.509", and encoded = the DER encoded bytes ..." I added a paragraph to the CSR, although it's already approved several days ago. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191492222 From mullan at openjdk.org Thu May 11 17:51:36 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 May 2023 17:51:36 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v5] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 11 May 2023 16:40:07 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java > > Co-authored-by: Daniel Jelinski > - updated copyright > - fixes JDK-8294985: throw an SSLException wrapping the IAE Not sure if you have more changes coming, but there are still a few other places where IAE could be thrown. I would change `getAuthorities()` (in both CertificateRequest.java and CertificateAuthoritiesExtension.java) to catch `IllegalArgumentException` and rethrow it as an `SSLException`, as this will ensure all existing and future calls to this method are handled consistently. Also, I would change the `toString()` method to also catch IAE but not propagate it, instead print something like "unparseable X500Principal". ------------- PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1423140554 From valeriep at openjdk.org Thu May 11 19:30:34 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 11 May 2023 19:30:34 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v3] In-Reply-To: References: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com> Message-ID: On Thu, 11 May 2023 17:16:19 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> updated reg test with review comments. > > test/jdk/java/security/SecureRandom/NextBytesNull.java line 29: > >> 27: * @summary check NPE is thrown for various methods of SecureRandom class, >> 28: * e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]). >> 29: * @run main/othervm NextBytesNull > > Does this need to be run in othervm mode? Probably not. Will remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1191603458 From mullan at openjdk.org Thu May 11 19:35:39 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 May 2023 19:35:39 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v3] In-Reply-To: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com> References: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com> Message-ID: On Wed, 10 May 2023 23:07:01 GMT, Valerie Peng wrote: >> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. >> >> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. >> >> CSR has been filed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > updated reg test with review comments. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13788#pullrequestreview-1423299217 From weijun at openjdk.org Thu May 11 19:35:54 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 19:35:54 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reintroduced Length for HSSPublicKey, added more @Override annotations src/java.base/share/classes/sun/security/provider/HSS.java line 436: > 434: int sigArrLen = (12 + n * (p + 1) + m * h); > 435: if ((q >= (1 << h)) || (inLen < sigArrLen) || (checkExactLen && (inLen != sigArrLen))) { > 436: throw new InvalidParameterException("LMS signature length is incorrect"); Should be a `SignatureException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191608083 From jlu at openjdk.org Thu May 11 20:21:57 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 20:21:57 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Convert the merged master changes to UTF-8 - Merge master and fix conflicts - Close streams when finished loading into props - Adjust CF test to read in with UTF-8 to fix failing test - Reconvert CS.properties to UTF-8 - Revert all changes to CurrencySymbols.properties - Bug6204853 should not be converted - Copyright year for CompileProperties - Redo translation for CS.properties - Spot convert CurrencySymbols.properties - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a ------------- Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05 Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From kdriver at openjdk.org Thu May 11 20:43:49 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 11 May 2023 20:43:49 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: - update copyright - reworking the fix in light of encouragement to change the problematic method signature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/87b47a03..0017c094 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=04-05 Stats: 54 lines in 2 files changed: 31 ins; 5 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From weijun at openjdk.org Thu May 11 20:56:54 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 May 2023 20:56:54 GMT Subject: RFR: 8297878: KEM: Implementation [v15] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: deterministic randomness ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/c9f1d8f3..128cefe7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=13-14 Stats: 45 lines in 1 file changed: 41 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From valeriep at openjdk.org Thu May 11 21:06:37 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 11 May 2023 21:06:37 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v4] In-Reply-To: References: Message-ID: > Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. > > Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. > > CSR has been filed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: minor test update, remove pkcs11 reg test as it's covered by the other test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13788/files - new: https://git.openjdk.org/jdk/pull/13788/files/3ee76896..a2564259 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13788&range=02-03 Stats: 73 lines in 2 files changed: 0 ins; 72 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13788.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13788/head:pull/13788 PR: https://git.openjdk.org/jdk/pull/13788 From jlu at openjdk.org Thu May 11 21:39:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 21:39:50 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. Although the default file-encoding for .properties can be switched to UTF-8, it is not the default. Wondering what some solutions/thoughts to this are. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830 From naoto at openjdk.org Thu May 11 21:51:13 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 May 2023 21:51:13 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com> On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480 From clanger at openjdk.org Thu May 11 21:51:58 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 11 May 2023 21:51:58 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates Message-ID: With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. This change does the following: 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. ------------- Commit messages: - JDK-8303465 Changes: https://git.openjdk.org/jdk/pull/13945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303465 Stats: 272 lines in 3 files changed: 204 ins; 31 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/13945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945 PR: https://git.openjdk.org/jdk/pull/13945 From valeriep at openjdk.org Fri May 12 02:23:17 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 May 2023 02:23:17 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries [v2] In-Reply-To: References: Message-ID: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Changed to use keytool to generate keypairs instead of importing from data files. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13743/files - new: https://git.openjdk.org/jdk/pull/13743/files/f194733c..4c72e3a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13743&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13743&range=00-01 Stats: 277 lines in 7 files changed: 82 ins; 137 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/13743.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13743/head:pull/13743 PR: https://git.openjdk.org/jdk/pull/13743 From ssahoo at openjdk.org Fri May 12 10:29:58 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Fri, 12 May 2023 10:29:58 GMT Subject: RFR: 8297878: KEM: Implementation [v15] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:56:54 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > deterministic randomness test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 205: > 203: byte[] enc1 = e.encapsulate().encapsulation(); > 204: byte[] enc2 = e.encapsulate().encapsulation(); > 205: Asserts.assertFalse(Arrays.equals(enc1, enc2)); Another case, KEM kem = KEM.getInstance("DHKEM"); KEM.Encapsulator e1 = kem.newEncapsulator(pk, random); KEM kem1 = KEM.getInstance("DHKEM"); KEM.Encapsulator e2 = kem1.newEncapsulator(pk, random); byte[] enc1 = e1.encapsulate().encapsulation(); byte[] enc2 = e2.encapsulate().encapsulation(); Asserts.assertFalse(Arrays.equals(enc1, enc2)); Can this case be added too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1192194605 From duke at openjdk.org Fri May 12 12:43:01 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 12 May 2023 12:43:01 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 16:19:01 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Reintroduced Length for HSSPublicKey, added more @Override annotations > > src/java.base/share/classes/sun/security/provider/HSS.java line 39: > >> 37: /* >> 38: * This class implements the Hierarchical Signature System using the >> 39: * Leighton-Micali Signatures (LMS) as described in RFC 8554 and NIST Special publication 800-208 > > Nit: add period at end of sentence. Added period. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192312218 From duke at openjdk.org Fri May 12 12:43:02 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 12 May 2023 12:43:02 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v8] In-Reply-To: References: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com> Message-ID: <5-iCin1c7rUpxYSrQdafZo3sUXBiRE94Xl0ynZYH3z4=.2ddc7397-7d5c-472b-9c74-50746b2388b0@github.com> On Thu, 11 May 2023 17:01:20 GMT, Sean Mullan wrote: >> Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable. > > `L` should be `transient` too as @wangweij noted. Made L transient ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192308943 From mullan at openjdk.org Fri May 12 13:42:47 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 May 2023 13:42:47 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v4] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:06:37 GMT, Valerie Peng wrote: >> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. >> >> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. >> >> CSR has been filed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > minor test update, remove pkcs11 reg test as it's covered by the other > test test/jdk/java/security/SecureRandom/NextBytesNull.java line 29: > 27: * @summary check NPE is thrown for various methods of SecureRandom class, > 28: * e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]). > 29: * @run main NextBytesNull You don't need an `@run` line now as this is the default if no `@run` line is specified. See https://openjdk.org/jtreg/tag-spec.html#DEFAULTS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1192393216 From duke at openjdk.org Fri May 12 14:20:01 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 12 May 2023 14:20:01 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v10] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:32:50 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Reintroduced Length for HSSPublicKey, added more @Override annotations > > src/java.base/share/classes/sun/security/provider/HSS.java line 436: > >> 434: int sigArrLen = (12 + n * (p + 1) + m * h); >> 435: if ((q >= (1 << h)) || (inLen < sigArrLen) || (checkExactLen && (inLen != sigArrLen))) { >> 436: throw new InvalidParameterException("LMS signature length is incorrect"); > > Should be a `SignatureException`. Changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 622: > >> 620: var val = new DerValue(new ByteArrayInputStream(x.getEncoded())); >> 621: val.data.getDerValue(); >> 622: return new HSSPublicKey(new DerValue(val.data.getBitString()).getOctetString()); > > The 2 lines above cannot detect wrong algorithm identifier and garbage data at the end. Now that you already have `parseBits` implementation, you should follow the usual `X509Key` convention to create a new `HSSPublicKey` constructor that takes in the whole encoding and call `decode` to decode it. See `ECKeyFactory` and `ECPublicKeyImpl.java` for an example. Changed as suggested. > src/java.base/share/classes/sun/security/provider/HSS.java line 728: > >> 726: @Override >> 727: public int length() { >> 728: return getKey().length(); > > Debatable. `getKey` now contains 2 (OCTET STRING header) + 4 (L) + 4 (LMS type) + 4 (LM-OTS type) + 16 (I) + 32 (T) bytes. Should the 2 header bytes be included in the length? Should all fields other than T be included? The length is mainly used to compare strength and I suggest we refrain from implementing this method until a well-known definition is accepted for HSS/LMS. Table 2 of [NIST SP 800-57 Part 1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and they are defined by modulus size. In this sense, the size of the hash is more suitable to be defined as the size of the key. Removed length, I agree that it doesn't make much sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192438720 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192437225 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192438203 From duke at openjdk.org Fri May 12 14:27:18 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 12 May 2023 14:27:18 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v11] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Removed Length from HSSPublicKey, changed the handling of X509 encoded keys in the factory, did some more beautification. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/b3ffdfd2..1830eee7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=09-10 Stats: 36 lines in 1 file changed: 9 ins; 12 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From mbaesken at openjdk.org Fri May 12 14:30:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 12 May 2023 14:30:02 GMT Subject: Withdrawn: JDK-8303465: KeyStore of type KeychainStore, provider Apple shows different behavior after 8278449 In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken wrote: > After 8278449, we seem to ignore in the call > > ` if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) ` > > all trusted certs from admin and system domains, so a lot more certs are ignored than necessary. > Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains . This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12829 From bpb at openjdk.org Fri May 12 16:24:49 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 May 2023 16:24:49 GMT Subject: RFR: 8308016: Use snippets in java.io package Message-ID: Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...>`. ------------- Commit messages: - 8308016: Use snippets in java.io package Changes: https://git.openjdk.org/jdk/pull/13957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308016 Stats: 178 lines in 21 files changed: 27 ins; 7 del; 144 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From weijun at openjdk.org Fri May 12 16:29:52 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 May 2023 16:29:52 GMT Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end Message-ID: When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/13958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308010 Stats: 80 lines in 3 files changed: 62 ins; 9 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13958/head:pull/13958 PR: https://git.openjdk.org/jdk/pull/13958 From jlu at openjdk.org Fri May 12 17:34:47 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 May 2023 17:34:47 GMT Subject: RFR: 8308016: Use snippets in java.io package In-Reply-To: References: Message-ID: On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter wrote: > Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. src/java.base/share/classes/java/io/Console.java line 124: > 122: * if (con != null) { > 123: * Scanner sc = new Scanner(con.reader()); > 124: * ... I'm not sure how you feel about this, but when I have been converting `
` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192635740


From hchao at openjdk.org  Fri May 12 17:53:47 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 12 May 2023 17:53:47 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng  wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed to use keytool to generate keypairs instead of importing from
>   data files.

Marked as reviewed by hchao (Committer).

Changes look good to me. Nice to add the cert chain (i.e. root/ca1/pk1) to the test case. The raw file `temp.ks` is shown in the webrev (to be created by the test), so will not be part of the integration, right?

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

PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1424933567
PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1546085439


From bpb at openjdk.org  Fri May 12 17:55:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 17:55:44 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 May 2023 17:31:32 GMT, Justin Lu  wrote:

>> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. > > src/java.base/share/classes/java/io/Console.java line 124: > >> 122: * if (con != null) { >> 123: * Scanner sc = new Scanner(con.reader()); >> 124: * ... > > I'm not sure how you feel about this, but when I have been converting `
` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.

I have been just trying to keep it as similar visually as possible but what you say is reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192652789


From lancea at openjdk.org  Fri May 12 18:02:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 18:02:48 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: 
References: 
 
 
Message-ID: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>

On Fri, 12 May 2023 17:52:29 GMT, Brian Burkhalter  wrote:

>> src/java.base/share/classes/java/io/Console.java line 124:
>> 
>>> 122:      *         if (con != null) {
>>> 123:      *             Scanner sc = new Scanner(con.reader());
>>> 124:      *             ...
>> 
>> I'm not sure how you feel about this, but when I have been converting `
` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.
>
> I have been just trying to keep it as similar visually as possible but what you say is reasonable.

Agree, that I would make the code valid when using a snippet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192658575


From bpb at openjdk.org  Fri May 12 19:02:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 19:02:46 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: 
References: 
Message-ID: 

> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Remove ellipses ("...") from snippets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/8a555a76..bc5c0358 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From valeriep at openjdk.org Fri May 12 19:23:45 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 May 2023 19:23:45 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries [v2] In-Reply-To: References: Message-ID: <3z1OA2qWuiwGjP9YQbwVnqOXIEnmQVz5lF-sarQMw0E=.879ad473-4780-4116-aa28-1f48a085b8c6@github.com> On Fri, 12 May 2023 17:50:22 GMT, Hai-May Chao wrote: > Changes look good to me. Nice to add the cert chain (i.e. root/ca1/pk1) to the test case. The raw file `temp.ks` is shown in the webrev (to be created by the test), so will not be part of the integration, right? temp,ks will be part of integration to save time on key pair generation. If for any reason that it needs to be re-generated, just remove the file and test will generate one on the fly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1546176018 From valeriep at openjdk.org Fri May 12 19:27:55 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 May 2023 19:27:55 GMT Subject: RFR: 8168469: Memory leak in JceSecurity [v2] In-Reply-To: References: Message-ID: <4-_rgIDUj2_c-8NgkBtWUd4vybIfpBeBXvcn-43Zxts=.44c6f860-038e-4895-97e2-d3db8619df9d@github.com> On Wed, 10 May 2023 10:03:46 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME. >> >> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap, Object>` instead of `IdentityHashMap`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper `objects that maintained the object identity while improved performance. >> >> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called. >> >> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers. >> >> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test. >> >> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressio... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > addressed review comment Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13658#pullrequestreview-1425046189 From duke at openjdk.org Fri May 12 19:27:57 2023 From: duke at openjdk.org (Sergey Chernyshev) Date: Fri, 12 May 2023 19:27:57 GMT Subject: Integrated: 8168469: Memory leak in JceSecurity In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev wrote: > Hi all, > > I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME. > > The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap, Object>` instead of `IdentityHashMap`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper `objects that maintained the object identity while improved performance. > > The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called. > > `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers. > > I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test. > > Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions > > [1] http... This pull request has now been integrated. Changeset: a284920b Author: Sergey Chernyshev Committer: Valerie Peng URL: https://git.openjdk.org/jdk/commit/a284920b3432b00496a2a32a284a91a9bd49fb06 Stats: 111 lines in 2 files changed: 84 ins; 8 del; 19 mod 8168469: Memory leak in JceSecurity Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/13658 From mullan at openjdk.org Fri May 12 20:17:46 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 May 2023 20:17:46 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 11 May 2023 20:43:49 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: > > - update copyright > - reworking the fix in light of encouragement to change the problematic method signature Do you have any plans to write a test? If not, the bug needs a `noreg` label. src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 136: > 134: } catch (IllegalArgumentException iae) { > 135: throw new SSLException("X500Principal could not be parsed " + > 136: "successfully", iae); Is it ok to throw a general `SSLException` here? Or do you need to call `TransportContext.fatal()` so that additional cleanup happens? Perhaps @XueleiFan would know. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1546242429 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1192759621 From kdriver at openjdk.org Fri May 12 20:32:50 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 May 2023 20:32:50 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 12 May 2023 20:14:56 GMT, Sean Mullan wrote: > Do you have any plans to write a test? If not, the bug needs a `noreg` label. As discussed internally, the test that surfaced this issue will be incorporated into regular testing. > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 136: > >> 134: } catch (IllegalArgumentException iae) { >> 135: throw new SSLException("X500Principal could not be parsed " + >> 136: "successfully", iae); > > Is it ok to throw a general `SSLException` here? Or do you need to call `TransportContext.fatal()` so that additional cleanup happens? Perhaps @XueleiFan would know. Yes, let's wait for @XueleiFan ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1546257007 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1192769497 From cslucas at openjdk.org Fri May 12 21:09:01 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 12 May 2023 21:09:01 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Address PR review 5: refactor on rematerialization & add tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/542c5ef1..68694126 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=11-12 Stats: 225 lines in 10 files changed: 98 ins; 97 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From cslucas at openjdk.org Fri May 12 21:09:04 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 12 May 2023 21:09:04 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v12] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <8pyn8ASJ6-PLoNIfI9FGvA6rfZXpc3Ud4hDWpesNlxg=.de6be879-e4cf-45a2-beca-00d7f3cd7429@github.com> On Tue, 9 May 2023 00:03:26 GMT, Vladimir Ivanov wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Address part of PR review 4 & fix a bug setting only_candidate >> - Catching up with master >> >> Merge remote-tracking branch 'origin/master' into rematerialization-of-merges >> - Fix tests. Remember previous reducible Phis. >> - Address PR review 3. Some comments and be able to abort compilation. >> - Merge with Master >> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. >> - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. >> - Add support for SR'ing some inputs of merges used for field loads >> - Fix some typos and do some small refactorings. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1 > > The new pass over deserialized debug info would adapt `ScopeDesc::objects()` (initialized by `decode_object_values(obj_decode_offset)` and accesses through `chunk->at(0)->scope()->objects()`) and produce 2 lists: > * new list of objects which enumerates all scalarized instances which needs to be rematerialized; > * complete set of objects referenced in the current scope (the purpose `chunk->at(0)->scope()->objects()` serves now). > > It should be performed before `rematerialize_objects`. > > By preprocessing I mean all the conditional checks before it is attempted to reallocate an `ObjectValue`. By the end of the new pass, it should be enough to just iterate over the new list of scalarized instances in `Deoptimization::realloc_objects`. And after `Deoptimization::realloc_objects` and `Deoptimization::reassign_fields` are over, debug info should be ready to go. @iwanowww - I pushed some changes to address your feedback about the rematerialization part. I added only two more tests for now, but I'm working on adding others. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1546298856 From valeriep at openjdk.org Fri May 12 23:02:58 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 May 2023 23:02:58 GMT Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null [v4] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 13:39:35 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> minor test update, remove pkcs11 reg test as it's covered by the other >> test > > test/jdk/java/security/SecureRandom/NextBytesNull.java line 29: > >> 27: * @summary check NPE is thrown for various methods of SecureRandom class, >> 28: * e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]). >> 29: * @run main NextBytesNull > > You don't need an `@run` line now as this is the default if no `@run` line is specified. See https://openjdk.org/jtreg/tag-spec.html#DEFAULTS. Sorry, didn't see this until I integrated it... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1192853571 From valeriep at openjdk.org Fri May 12 23:03:00 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 May 2023 23:03:00 GMT Subject: Integrated: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null In-Reply-To: References: Message-ID: On Thu, 4 May 2023 01:58:42 GMT, Valerie Peng wrote: > Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method. > > Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency. > > CSR has been filed. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 46e3d24a Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/46e3d24a6ff7d52d11f441d92628669d86d8bfaf Stats: 104 lines in 4 files changed: 90 ins; 7 del; 7 mod 8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/13788 From weijun at openjdk.org Fri May 12 23:16:09 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 May 2023 23:16:09 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v11] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 14:27:18 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed Length from HSSPublicKey, changed the handling of X509 encoded keys in the factory, did some more beautification. Except for putting 3 lines into the try block for `engineVerify`, I only have some format comments. There are quite some long lines in `HSS.java`. Better make them less than 80 characters. Everything else looks fine to me. Thanks for the hard work. src/java.base/share/classes/sun/security/provider/HSS.java line 38: > 36: > 37: /* > 38: * This class implements the Hierarchical Signature System using the Add the short name "(HSS)" after the long name. src/java.base/share/classes/sun/security/provider/HSS.java line 96: > 94: HSSSignature sig = new HSSSignature(signature, pubKey); > 95: LMSPublicKey lmsPubKey = pubKey.lmsPublicKey; > 96: boolean result = true; Please put all 3 lines above into the `try` block so we make sure `messageStream.reset()` is always called. src/java.base/share/classes/sun/security/provider/SHA2.java line 51: > 49: > 50: private static final int ITERATION = 64; > 51: private static final int BLOCKSIZE = 64; I'm not sure if it's worth defining this. A lot of other numbers (like 56 and 120) are hardcoded and it's not easy to modify this number to implement a different algorithm. src/java.base/share/classes/sun/security/provider/SunEntries.java line 221: > 219: addWithAlias(p, "KeyFactory", "DSA", > 220: "sun.security.provider.DSAKeyFactory", attrs); > 221: addWithAlias(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl", attrs); This line can be shorter. Overall, it will be nice to keep lines (including comment lines) shorter than 80 chars. If the code does look really ugly, better no more than 120 chars. src/java.base/share/classes/sun/security/util/RawKeySpec.java line 32: > 30: /** > 31: * This is a KeySpec that is used to specify a key by its byte array implementation. > 32: * It is intended to be used in testing algorithms where the algorithm specification describes the key in this form. This comment line can be shorter. ------------- PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1425204741 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192829509 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192830859 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192828015 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192828938 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192829128 From tvaleev at openjdk.org Sun May 14 05:53:56 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Sun, 14 May 2023 05:53:56 GMT Subject: RFR: 8308016: Use snippets in java.io package [v2] In-Reply-To: References: Message-ID: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com> On Fri, 12 May 2023 19:02:46 GMT, Brian Burkhalter wrote: >> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8308016: Remove ellipses ("...") from snippets src/java.base/share/classes/java/io/FilePermission.java line 1033: > 1031: * > 1032: * {@snippet lang=java : > 1033: * "/tmp/scratch/foo", "read,write", This doesn't look like a valid Java code. This is not even a well-formed expression. I'm not sure whether there are any standard requirements about this (the spec is vague here), but IntelliJ IDEA assumes that the Java snippet is a member, a statement, or an expression. It's likely that parse error will be displayed here in the IDE. src/java.base/share/classes/java/io/ObjectStreamField.java line 179: > 177: * Returns character encoding of field type. The encoding is as follows: > 178: * {@snippet lang=java : > 179: * B byte This is even less Java code. I don't think that snippet is appropriate here. src/java.base/share/classes/java/io/RandomAccessFile.java line 904: > 902: * {@code b7}, and {@code b8,} where: > 903: * {@snippet lang=java : > 904: * 0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255, Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated. src/java.base/share/classes/java/io/StreamTokenizer.java line 394: > 392: * characters: > 393: * {@snippet lang=java : > 394: * 0 1 2 3 4 5 6 7 8 9 . - But Java as well src/java.base/share/classes/java/io/StreamTokenizer.java line 774: > 772: * > 773: * {@snippet lang=java : > 774: * Token['a'], line 10 Also not Java. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078718 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078810 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078975 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079002 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079017 From tvaleev at openjdk.org Sun May 14 05:58:54 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Sun, 14 May 2023 05:58:54 GMT Subject: RFR: 8308016: Use snippets in java.io package [v2] In-Reply-To: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com> References: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com> Message-ID: On Fri, 12 May 2023 17:59:32 GMT, Lance Andersen wrote: >> I have been just trying to keep it as similar visually as possible but what you say is reasonable. > > Agree, that I would make the code valid when using a snippet There's a replacement tag for this. Some people use label, e.g. code: // @replace substring="code:" replacement="..." This way, the snippet remains compilable and rendered the same as before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079515 From alanb at openjdk.org Sun May 14 06:25:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 14 May 2023 06:25:47 GMT Subject: RFR: 8308016: Use snippets in java.io package [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 19:02:46 GMT, Brian Burkhalter wrote: >> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8308016: Remove ellipses ("...") from snippets src/java.base/share/classes/java/io/Console.java line 89: > 87: * if ((cons = System.console()) != null && > 88: * (passwd = cons.readPassword("[%s]", "Password:")) != null) { > 89: * ... I assume you didn't mean to remove this, this is show that there is other code in this block before the passwd is cleared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193082310 From alanb at openjdk.org Sun May 14 06:25:48 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 14 May 2023 06:25:48 GMT Subject: RFR: 8308016: Use snippets in java.io package [v2] In-Reply-To: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com> References: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com> Message-ID: On Sun, 14 May 2023 05:47:50 GMT, Tagir F. Valeev wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8308016: Remove ellipses ("...") from snippets > > src/java.base/share/classes/java/io/FilePermission.java line 1033: > >> 1031: * >> 1032: * {@snippet lang=java : >> 1033: * "/tmp/scratch/foo", "read,write", > > This doesn't look like a valid Java code. This is not even a well-formed expression. I'm not sure whether there are any standard requirements about this (the spec is vague here), but IntelliJ IDEA assumes that the Java snippet is a member, a statement, or an expression. It's likely that parse error will be displayed here in the IDE. Indeed, maybe a script was used to replace the
 
tags, in which case it will checking for other non-code examples. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193082481 From asotona at openjdk.org Mon May 15 08:47:02 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 May 2023 08:47:02 GMT Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete Message-ID: Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: - `PackageDesc::packageName` to `PackageDesc::name` - `PackageDesc::packageInternalName` to `PackageDesc::internalName` - `ModuleDesc::moduleName` to `ModuleDesc::name`. Please review this pull request. Thanks, Adam ------------- Commit messages: - 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete Changes: https://git.openjdk.org/jdk/pull/13979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13979&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307326 Stats: 503 lines in 46 files changed: 0 ins; 446 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/13979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13979/head:pull/13979 PR: https://git.openjdk.org/jdk/pull/13979 From duke at openjdk.org Mon May 15 09:33:07 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 15 May 2023 09:33:07 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v11] In-Reply-To: References: Message-ID: <-9CaELTHAECXXB8GuQAwrK1-BotxTOO6-bPwNOxISSE=.e97b4e6d-183c-4d27-b649-51345dd25b4e@github.com> On Fri, 12 May 2023 22:11:07 GMT, Weijun Wang wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed Length from HSSPublicKey, changed the handling of X509 encoded keys in the factory, did some more beautification. > > src/java.base/share/classes/sun/security/provider/HSS.java line 38: > >> 36: >> 37: /* >> 38: * This class implements the Hierarchical Signature System using the > > Add the short name "(HSS)" after the long name. Added. > src/java.base/share/classes/sun/security/provider/HSS.java line 96: > >> 94: HSSSignature sig = new HSSSignature(signature, pubKey); >> 95: LMSPublicKey lmsPubKey = pubKey.lmsPublicKey; >> 96: boolean result = true; > > Please put all 3 lines above into the `try` block so we make sure `messageStream.reset()` is always called. Done. > src/java.base/share/classes/sun/security/provider/SHA2.java line 51: > >> 49: >> 50: private static final int ITERATION = 64; >> 51: private static final int BLOCKSIZE = 64; > > I'm not sure if it's worth defining this. A lot of other numbers (like 56 and 120) are hardcoded and it's not easy to modify this number to implement a different algorithm. This is not about modifiability but about readability. It is easier to understand the code if the constants have names. Especially when there exist constants with the same value that serve different purposes. > src/java.base/share/classes/sun/security/provider/SunEntries.java line 221: > >> 219: addWithAlias(p, "KeyFactory", "DSA", >> 220: "sun.security.provider.DSAKeyFactory", attrs); >> 221: addWithAlias(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl", attrs); > > This line can be shorter. Overall, it will be nice to keep lines (including comment lines) shorter than 80 chars. If the code does look really ugly, better no more than 120 chars. I think in the 21st century (when 80 column punch cards and 80-character wide screens are long gone) the 80 character line length is quite an unreasonable requirement for code (decreases readability in most cases). Still, I made the lines shorter. > src/java.base/share/classes/sun/security/util/RawKeySpec.java line 32: > >> 30: /** >> 31: * This is a KeySpec that is used to specify a key by its byte array implementation. >> 32: * It is intended to be used in testing algorithms where the algorithm specification describes the key in this form. > > This comment line can be shorter. Split the line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578661 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578727 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578474 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578546 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578593 From duke at openjdk.org Mon May 15 09:45:10 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 15 May 2023 09:45:10 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v12] In-Reply-To: References: Message-ID: <9A97Hr3aBDW5mwW4GEDmA_1BSfLzSKDzfuQcTciH2hc=.29ea7bac-1f2d-4332-964c-ed50b9782001@github.com> > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Shortened lines, moved two lines into the try block. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/1830eee7..1abc1d78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=10-11 Stats: 118 lines in 3 files changed: 61 ins; 1 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From weijun at openjdk.org Mon May 15 12:57:08 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 May 2023 12:57:08 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v12] In-Reply-To: <9A97Hr3aBDW5mwW4GEDmA_1BSfLzSKDzfuQcTciH2hc=.29ea7bac-1f2d-4332-964c-ed50b9782001@github.com> References: <9A97Hr3aBDW5mwW4GEDmA_1BSfLzSKDzfuQcTciH2hc=.29ea7bac-1f2d-4332-964c-ed50b9782001@github.com> Message-ID: On Mon, 15 May 2023 09:45:10 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Shortened lines, moved two lines into the try block. Everything looks fine to me now. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1426491992 From erikj at openjdk.org Mon May 15 13:20:47 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 15 May 2023 13:20:47 GMT Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete In-Reply-To: References: Message-ID: On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote: > Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). > All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. > `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. > Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. > Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: > - `PackageDesc::packageName` to `PackageDesc::name` > - `PackageDesc::packageInternalName` to `PackageDesc::internalName` > - `ModuleDesc::moduleName` to `ModuleDesc::name`. > > Please review this pull request. > > Thanks, > Adam Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1426543240 From duke at openjdk.org Mon May 15 13:44:27 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 15 May 2023 13:44:27 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v13] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Removed a comment line. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/1abc1d78..3bc2a355 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From weijun at openjdk.org Mon May 15 15:00:08 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 May 2023 15:00:08 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v13] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 13:44:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed a comment line. src/java.base/share/classes/sun/security/util/RawKeySpec.java line 29: > 27: > 28: import java.security.spec.KeySpec; > 29: //12345678901234567890123456789012345678901234567890123456789012345678901234567890 There is one extra line here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193966319 From weijun at openjdk.org Mon May 15 15:04:07 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 May 2023 15:04:07 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v11] In-Reply-To: <-9CaELTHAECXXB8GuQAwrK1-BotxTOO6-bPwNOxISSE=.e97b4e6d-183c-4d27-b649-51345dd25b4e@github.com> References: <-9CaELTHAECXXB8GuQAwrK1-BotxTOO6-bPwNOxISSE=.e97b4e6d-183c-4d27-b649-51345dd25b4e@github.com> Message-ID: On Mon, 15 May 2023 09:30:04 GMT, Ferenc Rakoczi wrote: >> src/java.base/share/classes/sun/security/provider/SHA2.java line 51: >> >>> 49: >>> 50: private static final int ITERATION = 64; >>> 51: private static final int BLOCKSIZE = 64; >> >> I'm not sure if it's worth defining this. A lot of other numbers (like 56 and 120) are hardcoded and it's not easy to modify this number to implement a different algorithm. > > This is not about modifiability but about readability. It is easier to understand the code if the constants have names. Especially when there exist constants with the same value that serve different purposes. Good. >> src/java.base/share/classes/sun/security/provider/SunEntries.java line 221: >> >>> 219: addWithAlias(p, "KeyFactory", "DSA", >>> 220: "sun.security.provider.DSAKeyFactory", attrs); >>> 221: addWithAlias(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl", attrs); >> >> This line can be shorter. Overall, it will be nice to keep lines (including comment lines) shorter than 80 chars. If the code does look really ugly, better no more than 120 chars. > > I think in the 21st century (when 80 column punch cards and 80-character wide screens are long gone) the 80 character line length is quite an unreasonable requirement for code (decreases readability in most cases). Still, I made the lines shorter. It's still useful when reviewing code with split panes. We can discuss on this rule. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193972006 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193971543 From weijun at openjdk.org Mon May 15 15:20:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 May 2023 15:20:04 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v13] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 13:44:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed a comment line. Oops, more comments: 1. `engineSetParameter(AlgorithmParameterSpec params)` should be overridden. Existing implementations that does not require parameters (RSA and DSA) succeeds if input is null. 2. `engineGetParameters()` should be overridden and return null. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1548063322 From weijun at openjdk.org Mon May 15 15:25:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 May 2023 15:25:04 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v13] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 13:44:27 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed a comment line. Oops, more comments: 1. `engineSetParameter(AlgorithmParameterSpec params)` should be overridden. Existing implementations that does not require parameters (RSA and DSA) succeeds if input is null. 2. `engineGetParameters()` should be overridden and return null. ------------- Changes requested by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1426814309 From duke at openjdk.org Mon May 15 16:14:24 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 15 May 2023 16:14:24 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v14] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Overrided engineSetParameters() and engineGetParameters(). Removed a comment line. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/3bc2a355..cf06b52a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=12-13 Stats: 13 lines in 2 files changed: 12 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From bpb at openjdk.org Mon May 15 18:44:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 15 May 2023 18:44:53 GMT Subject: RFR: 8308016: Use snippets in java.io package [v3] In-Reply-To: References: Message-ID: > Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Address reviewer comments since previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/bc5c0358..614eeda6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=01-02 Stats: 26 lines in 6 files changed: 2 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From ascarpino at openjdk.org Mon May 15 19:10:59 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 15 May 2023 19:10:59 GMT Subject: RFR: 8297878: KEM: Implementation [v15] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:56:54 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > deterministic randomness src/java.base/share/classes/javax/crypto/KEM.java line 217: > 215: *

> 216: * An implementation may choose to not support arbitrary combinations > 217: * of {@code from}, {@code to}, and {@code algorithm}. As previously discussed, I think having a code example of the `from` and `to` would be good idea. That way it's very clear going from 0 to 32 is 32 bytes and not 33. And an example would be a good idea in the SPI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1194258367 From xuelei at openjdk.org Mon May 15 19:19:47 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 May 2023 19:19:47 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com> On Fri, 12 May 2023 20:30:04 GMT, Kevin Driver wrote: >> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 136: >> >>> 134: } catch (IllegalArgumentException iae) { >>> 135: throw new SSLException("X500Principal could not be parsed " + >>> 136: "successfully", iae); >> >> Is it ok to throw a general `SSLException` here? Or do you need to call `TransportContext.fatal()` so that additional cleanup happens? Perhaps @XueleiFan would know. > > Yes, let's wait for @XueleiFan It is not easy to understand the final behavior if throwing SSLException here. I would like to call `TransportContext.fatal()` directly to make the behavior more accuracy, by using Alert.DECODE_ERROR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1194266764 From mullan at openjdk.org Mon May 15 19:40:46 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 15 May 2023 19:40:46 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com> Message-ID: On Mon, 15 May 2023 19:17:18 GMT, Xue-Lei Andrew Fan wrote: >> Yes, let's wait for @XueleiFan > > It is not easy to understand the final behavior if throwing SSLException here. I would like to call `TransportContext.fatal()` directly to make the behavior more accuracy, by using Alert.DECODE_ERROR. You will need to pass in `TransportContext` as a parameter if you do that, unless you go back changing the callers of `getAuthorities()` to catch `IllegalArgumentException`. I'm now thinking it is better for the callers of `getAuthorities()` to catch `IllegalArgumentException` and then call `fatal`. One other minor comment: - I would remove the word "successfully" as this is a failure case so it is implied. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1194286609 From kdriver at openjdk.org Mon May 15 19:48:47 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Mon, 15 May 2023 19:48:47 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com> Message-ID: On Mon, 15 May 2023 19:37:44 GMT, Sean Mullan wrote: >> It is not easy to understand the final behavior if throwing SSLException here. I would like to call `TransportContext.fatal()` directly to make the behavior more accuracy, by using Alert.DECODE_ERROR. > > You will need to pass in `TransportContext` as a parameter if you do that, unless you go back changing the callers of `getAuthorities()` to catch `IllegalArgumentException`. I'm now thinking it is better for the callers of `getAuthorities()` to catch `IllegalArgumentException` and then call `fatal`. > > One other minor comment: > > - I would remove the word "successfully" as this is a failure case so it is implied. Sean, agreed. I had considered the above previously. Also, I'll remove "successfully" with the next round of edits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1194292927 From shade at openjdk.org Mon May 15 20:28:50 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 May 2023 20:28:50 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey Message-ID: One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. Example profile is in the bug. On new benchmark and M1 Mac: Benchmark Mode Cnt Score Error Units # Before AESReinit.test avgt 15 873,842 ? 6,911 ns/op # After AESReinit.test avgt 15 533,018 ? 4,048 ns/op Additional testing: - [x] Benchmarks - [x] macos-aarch64-server-release, `jdk_security` - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` - [ ] linux-aarch64-server-fastdebug, `tier1 tier2` ------------- Commit messages: - Fix - Fix Changes: https://git.openjdk.org/jdk/pull/13996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308118 Stats: 77 lines in 2 files changed: 74 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13996/head:pull/13996 PR: https://git.openjdk.org/jdk/pull/13996 From bpb at openjdk.org Mon May 15 20:48:47 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 15 May 2023 20:48:47 GMT Subject: RFR: 8308016: Use snippets in java.io package [v4] In-Reply-To: References: Message-ID: > Replace `

{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Fix link in snippet of File::toPath ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/614eeda6..da7c2004 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From xuelei at openjdk.org Mon May 15 20:53:45 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 May 2023 20:53:45 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey In-Reply-To: References: Message-ID: On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev wrote: > One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. > > Example profile is in the bug. > > On new benchmark and M1 Mac: > > > Benchmark Mode Cnt Score Error Units > > # Before > AESReinit.test avgt 15 873,842 ? 6,911 ns/op > > # After > AESReinit.test avgt 15 533,018 ? 4,048 ns/op > > > Additional testing: > - [x] Benchmarks > - [x] macos-aarch64-server-release, `jdk_security` > - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` > - [ ] linux-aarch64-server-fastdebug, `tier1 tier2` src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372: > 1370: > 1371: // It is significantly faster to allocate individual arrays, > 1372: // instead of doing the multi-array allocation. See JDK-8308105. Alternatively, could the multi-array allocation get improved? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194351546 From weijun at openjdk.org Tue May 16 01:10:10 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 May 2023 01:10:10 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v6] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - add here() back - Merge branch 'master' into 8305972 - comment for new test - no more secret exports, one message change - more comment and spec refine - cleanup commented out code and unnecessary bug id - the change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/b4cf0070..79ad37be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=04-05 Stats: 18366 lines in 550 files changed: 13234 ins; 2765 del; 2367 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From duke at openjdk.org Tue May 16 01:54:45 2023 From: duke at openjdk.org (David Schlosnagle) Date: Tue, 16 May 2023 01:54:45 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey In-Reply-To: References: Message-ID: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com> On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev wrote: > One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. > > Example profile is in the bug. > > On new benchmark and M1 Mac: > > > Benchmark Mode Cnt Score Error Units > > # Before > AESReinit.test avgt 15 873,842 ? 6,911 ns/op > > # After > AESReinit.test avgt 15 533,018 ? 4,048 ns/op > > > Additional testing: > - [x] Benchmarks > - [x] macos-aarch64-server-release, `jdk_security` > - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` > - [ ] linux-aarch64-server-fastdebug, `tier1 tier2` src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369: > 1367: int BC = 4; > 1368: int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys > 1369: int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well? int[] Ke = new int[4 * (ROUNDS + 1)]; int[] Kd = new int[4 * (ROUNDS + 1)]; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194511682 From weijun at openjdk.org Tue May 16 02:01:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 May 2023 02:01:04 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v7] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration. > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update version in comment only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/79ad37be..e4dc75b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From shade at openjdk.org Tue May 16 06:31:45 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 May 2023 06:31:45 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey In-Reply-To: References: Message-ID: On Mon, 15 May 2023 20:51:21 GMT, Xue-Lei Andrew Fan wrote: >> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. >> >> Meanwhile, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. This workaround is straight-forward and backportable. >> >> Example profile is in the bug. >> >> On new benchmark and M1 Mac: >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Before >> AESReinit.test avgt 15 873,842 ? 6,911 ns/op >> >> # After >> AESReinit.test avgt 15 533,018 ? 4,048 ns/op >> >> >> Additional testing: >> - [x] Benchmarks >> - [x] macos-aarch64-server-release, `jdk_security` >> - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` >> - [x] linux-aarch64-server-fastdebug, `tier1 tier2` > > src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372: > >> 1370: >> 1371: // It is significantly faster to allocate individual arrays, >> 1372: // instead of doing the multi-array allocation. See JDK-8308105. > > Alternatively, could the multi-array allocation get improved? Yes, it could and it eventually would, but it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. This workaround, on the other hand, is straight-forward and backportable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194673153 From mbaesken at openjdk.org Tue May 16 07:49:46 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 16 May 2023 07:49:46 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates In-Reply-To: References: Message-ID: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com> On Thu, 11 May 2023 21:38:35 GMT, Christoph Langer wrote: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. Hi Christoph, I do not see any reference to kSecTrustSettingsDomainSystem in your coding. Handling at least kSecTrustSettingsDomainUser and kSecTrustSettingsDomainAdmin is good but I am not sure about kSecTrustSettingsDomainSystem . Did you find some documentation why it should be omitted ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1549166364 From alanb at openjdk.org Tue May 16 08:00:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 May 2023 08:00:51 GMT Subject: RFR: 8308016: Use snippets in java.io package [v4] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 20:48:47 GMT, Brian Burkhalter wrote: >> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8308016: Fix link in snippet of File::toPath src/java.base/share/classes/java/io/File.java line 2375: > 2373: * {@snippet lang=java : > 2374: * // @link substring="getDefault" target="java.nio.file.FileSystems#getDefault" @link regex="getPath(?=\(t)" target="java.nio.file.FileSystem#getPath" @link regex="getPath(?=\(\))" target="#getPath" : > 2375: * FileSystems.getDefault().getPath(this.getPath()); There is already a link to FileSystems.getDefault() in the previous paragraph so I think you can remove the linking in the snippet to: `// @link regex="getPath(?=(t)" target="java.nio.file.FileSystem#getPath" :` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1194767344 From shade at openjdk.org Tue May 16 08:32:47 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 May 2023 08:32:47 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey In-Reply-To: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com> References: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com> Message-ID: On Tue, 16 May 2023 01:44:24 GMT, David Schlosnagle wrote: >> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. >> >> Meanwhile, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. This workaround is straight-forward and backportable. >> >> Example profile is in the bug. >> >> On new benchmark and M1 Mac: >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Before >> AESReinit.test avgt 15 873,842 ? 6,911 ns/op >> >> # After >> AESReinit.test avgt 15 533,018 ? 4,048 ns/op >> >> >> Additional testing: >> - [x] Benchmarks >> - [x] macos-aarch64-server-release, `jdk_security` >> - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` >> - [x] linux-aarch64-server-fastdebug, `tier1 tier2` > > src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369: > >> 1367: int BC = 4; >> 1368: int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys >> 1369: int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys > > This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well? > > > int[] Ke = new int[4 * (ROUNDS + 1)]; > int[] Kd = new int[4 * (ROUNDS + 1)]; True, let me try that! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194807087 From mbaesken at openjdk.org Tue May 16 08:55:43 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 16 May 2023 08:55:43 GMT Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output Message-ID: In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum. ------------- Commit messages: - JDK-8308156 Changes: https://git.openjdk.org/jdk/pull/14003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308156 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14003/head:pull/14003 PR: https://git.openjdk.org/jdk/pull/14003 From mbaesken at openjdk.org Tue May 16 09:12:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 16 May 2023 09:12:48 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:38:35 GMT, Christoph Langer wrote: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. Additionally, the return value of SecTrustSettingsCopyTrustSettings (https://developer.apple.com/documentation/security/1400261-sectrustsettingscopytrustsetting) should better be checked. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1549289885 From shade at openjdk.org Tue May 16 09:18:57 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 May 2023 09:18:57 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: > One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. > > Meanwhile, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely. > > > Example profile is in the bug. > > On new benchmark and M1 Mac: > > > Benchmark Mode Cnt Score Error Units > > # Before > AESReinit.test avgt 15 873,842 ? 6,911 ns/op > > # After > AESReinit.test avgt 15 347,632 ? 8,764 ns/op > > > Additional testing: > - [x] Benchmarks > - [ ] macos-aarch64-server-release, `jdk_security` > - [ ] linux-x86_64-server-fastdebug, `tier1 tier2` > - [ ] linux-aarch64-server-fastdebug, `tier1 tier2` Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: - Micro-optimizations - Handle Kd - Handle Ke ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13996/files - new: https://git.openjdk.org/jdk/pull/13996/files/7842e0e2..bb712183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13996&range=00-01 Stats: 72 lines in 1 file changed: 9 ins; 43 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13996/head:pull/13996 PR: https://git.openjdk.org/jdk/pull/13996 From clanger at openjdk.org Tue May 16 09:19:55 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 16 May 2023 09:19:55 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v2] In-Reply-To: References: Message-ID: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Add some more initializations to avoid crashes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13945/files - new: https://git.openjdk.org/jdk/pull/13945/files/3c4424b6..22303e1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945 PR: https://git.openjdk.org/jdk/pull/13945 From shade at openjdk.org Tue May 16 09:30:45 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 May 2023 09:30:45 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com> Message-ID: On Tue, 16 May 2023 08:29:52 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369: >> >>> 1367: int BC = 4; >>> 1368: int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys >>> 1369: int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys >> >> This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well? >> >> >> int[] Ke = new int[4 * (ROUNDS + 1)]; >> int[] Kd = new int[4 * (ROUNDS + 1)]; > > True, let me try that! New commit implements this, with even more performance benefits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194883146 From shade at openjdk.org Tue May 16 09:43:50 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 16 May 2023 09:43:50 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 06:28:17 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372: >> >>> 1370: >>> 1371: // It is significantly faster to allocate individual arrays, >>> 1372: // instead of doing the multi-array allocation. See JDK-8308105. >> >> Alternatively, could the multi-array allocation get improved? > > Yes, it could and it eventually would, but it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. This workaround, on the other hand, is straight-forward and backportable. Please look again, I think we can improve this code even further, and that is where JVM optos would not help us much :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194898514 From duke at openjdk.org Tue May 16 10:46:44 2023 From: duke at openjdk.org (Darragh Clarke) Date: Tue, 16 May 2023 10:46:44 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently Message-ID: Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, I didn't add any new tests but ran tier 1-3 with no issues ------------- Commit messages: - added some case conversions missed previously - updated copyright year and cleaned up some formatting of imports - merged master into branch - Specify use of Locale.Root to avoid issues with case conversion Changes: https://git.openjdk.org/jdk/pull/14006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7065228 Stats: 76 lines in 21 files changed: 15 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/14006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006 PR: https://git.openjdk.org/jdk/pull/14006 From duke at openjdk.org Tue May 16 11:51:45 2023 From: duke at openjdk.org (David Schlosnagle) Date: Tue, 16 May 2023 11:51:45 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com> Message-ID: On Tue, 16 May 2023 09:28:11 GMT, Aleksey Shipilev wrote: >> True, let me try that! > > New commit implements this, with even more performance benefits. Excellent, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1195043072 From dfuchs at openjdk.org Tue May 16 13:35:49 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 16 May 2023 13:35:49 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently In-Reply-To: References: Message-ID: On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke wrote: > Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, > > I didn't add any new tests but ran tier 1-3 with no issues Looks generally like a good improvement. In those places `toLowerCase` is called on strings (or substrings) that are expected to be ASCII, so using Locale.ROOT looks appropriate. Would be good to get @Michael-Mc-Mahon validate these changes too. src/java.base/share/classes/java/io/StreamTokenizer.java line 632: > 630: sval = String.copyValueOf(buf, 0, i); > 631: if (forceLower) > 632: sval = sval.toLowerCase(Locale.ROOT); This one gave me pause. AFAICS it's probably OK - but it might warant a CSR and an update of the specification to explicitly state how the lower case conversion is performed (update the `lowerCaseMode` method spec). Could we handle that in a separate PR? ------------- PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428569684 PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1195156280 From naoto at openjdk.org Tue May 16 15:59:44 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 May 2023 15:59:44 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently In-Reply-To: References: Message-ID: On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke wrote: > Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, > > I didn't add any new tests but ran tier 1-3 with no issues LGTM. Nice clean-up! ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428917297 From mullan at openjdk.org Tue May 16 16:18:46 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 16 May 2023 16:18:46 GMT Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output In-Reply-To: References: Message-ID: On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken wrote: > In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum. Please add a `noreg-self` label to the bug as this is a fix to the test. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14003#pullrequestreview-1428953153 From weijun at openjdk.org Tue May 16 16:28:30 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 May 2023 16:28:30 GMT Subject: RFR: 8297878: KEM: Implementation [v15] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 19:07:59 GMT, Anthony Scarpino wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> deterministic randomness > > src/java.base/share/classes/javax/crypto/KEM.java line 217: > >> 215: *

>> 216: * An implementation may choose to not support arbitrary combinations >> 217: * of {@code from}, {@code to}, and {@code algorithm}. > > As previously discussed, I think having a code example of the `from` and `to` would be good idea. That way it's very clear going from 0 to 32 is 32 bytes and not 33. And an example would be a good idea in the SPI. Added some comments and example lines. And I found A REAL BUG in `DHKEM`!!! Having two styles of slicing an array is indeed a problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1195412465 From weijun at openjdk.org Tue May 16 16:28:26 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 May 2023 16:28:26 GMT Subject: RFR: 8297878: KEM: Implementation [v16] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: to and length and comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/128cefe7..ea8f7964 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=14-15 Stats: 35 lines in 5 files changed: 25 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From rhalade at openjdk.org Tue May 16 16:26:46 2023 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 16 May 2023 16:26:46 GMT Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output In-Reply-To: References: Message-ID: On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken wrote: > In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum. Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14003#pullrequestreview-1428965817 From bpb at openjdk.org Tue May 16 16:30:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 May 2023 16:30:08 GMT Subject: RFR: 8308016: Use snippets in java.io package [v5] In-Reply-To: References: Message-ID: > Replace `

{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Reduce linking in File::toPath snippet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/da7c2004..724a74a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From liach at openjdk.org Tue May 16 18:20:45 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 May 2023 18:20:45 GMT Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete In-Reply-To: References: Message-ID: <5CjNjAQme8BTCA-TJzjjV8Zb7e-xYvuHvQENi7nUkrs=.5c407434-4d8f-42a7-aec6-37961ea9afe3@github.com> On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote: > Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). > All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. > `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. > Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. > Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: > - `PackageDesc::packageName` to `PackageDesc::name` > - `PackageDesc::packageInternalName` to `PackageDesc::internalName` > - `ModuleDesc::moduleName` to `ModuleDesc::name`. > > Please review this pull request. > > Thanks, > Adam I think these are all the occurrences of jdk.internal.classfile.java.lang.constant package. ------------- Marked as reviewed by liach (Author). PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1429153817 From kdriver at openjdk.org Tue May 16 19:38:10 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 16 May 2023 19:38:10 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v7] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - update copyright - reworking the fix in light of encouragement to change the problematic method signature - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java Co-authored-by: Daniel Jelinski - updated copyright - fixes JDK-8294985: throw an SSLException wrapping the IAE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/0017c094..fa31ddb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=05-06 Stats: 10844 lines in 494 files changed: 6394 ins; 1103 del; 3347 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From valeriep at openjdk.org Tue May 16 23:45:00 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 16 May 2023 23:45:00 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v2] In-Reply-To: <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com> References: <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com> Message-ID: <9-eGBQs-MoQ0PUC2i1M5dCkr2KdmftuVd3qrpuyaMzs=.18aea3e5-38b0-4c2c-9303-a2c9adfc3e57@github.com> On Tue, 21 Mar 2023 20:31:44 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/java.base/share/classes/sun/security/util/PBEUtil.java line 62: > 60: * IvParameterSpec). > 61: */ > 62: public final static class PBES2Params { nit; static final? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1195785390 From mpowers at openjdk.org Tue May 16 23:50:04 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 May 2023 23:50:04 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v14] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 16:14:24 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Overrided engineSetParameters() and engineGetParameters(). Removed a comment line. src/java.base/share/classes/sun/security/provider/HSS.java line 354: > 352: final String hashAlgStr; > 353: > 354: LMSParams(int type, int m, int h, String hashAlgStr) { `type` is unused src/java.base/share/classes/sun/security/provider/HSS.java line 667: > 665: protected PublicKey engineGeneratePublic(KeySpec keySpec) > 666: throws InvalidKeySpecException { > 667: if (keySpec instanceof X509EncodedKeySpec x) { `x` does not appear to be used ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1195787655 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1195787782 From mbalao at openjdk.org Wed May 17 03:11:54 2023 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 17 May 2023 03:11:54 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: Message-ID: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> > We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. > > In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): > > * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ... Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Rebase fix after JDK-8306033. Replace called functions with their new names. - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) Co-authored-by: Francisco Ferrari Co-authored-by: Martin Balao - 8301553: Support Password-Based Cryptography in SunPKCS11 Co-authored-by: Francisco Ferrari Co-authored-by: Martin Balao ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12396/files - new: https://git.openjdk.org/jdk/pull/12396/files/f1b2006a..cd48dc20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=01-02 Stats: 888953 lines in 8327 files changed: 625265 ins; 187201 del; 76487 mod Patch: https://git.openjdk.org/jdk/pull/12396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396 PR: https://git.openjdk.org/jdk/pull/12396 From mbaesken at openjdk.org Wed May 17 06:45:53 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 06:45:53 GMT Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output In-Reply-To: References: Message-ID: <5gbs_pm0Y1zcl0-wEKWX_Kh4SkAsKxb5MALrKdEAA7c=.6200b2e5-2173-4229-ac2f-394331a37f84@github.com> On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken wrote: > In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum. Hi Rajan and Sean, thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14003#issuecomment-1550828250 From mbaesken at openjdk.org Wed May 17 06:45:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 06:45:54 GMT Subject: Integrated: JDK-8308156: VerifyCACerts.java misses blank in error output In-Reply-To: References: Message-ID: On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken wrote: > In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum. This pull request has now been integrated. Changeset: 5a92aae1 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/5a92aae1d967f5be01f05d9cc56c433a5eca61e8 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8308156: VerifyCACerts.java misses blank in error output Reviewed-by: mullan, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/14003 From duke at openjdk.org Wed May 17 07:16:02 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 17 May 2023 07:16:02 GMT Subject: RFR: 8297878: KEM: Implementation [v16] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 16:28:26 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > to and length and comments src/java.base/share/classes/javax/crypto/KEM.java line 233: > 231: * of the shared secret as a 128-bit AES key. > 232: * @throws IndexOutOfBoundsException if {@code from < 0}, > 233: * {@code from > to}, or {@code to > secretSize()} Shouldn't this say "{@code to - from > secretSize()}"? src/java.base/share/classes/javax/crypto/KEM.java line 356: > 354: * decapsulation process > 355: * @throws IndexOutOfBoundsException if {@code from < 0}, > 356: * {@code from > to}, or {@code to > secretSize()} Shouldn't this say "{@code to - from > secretSize()}"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1196042549 PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1196043626 From clanger at openjdk.org Wed May 17 07:16:47 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 May 2023 07:16:47 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates In-Reply-To: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com> References: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com> Message-ID: On Tue, 16 May 2023 07:46:37 GMT, Matthias Baesken wrote: > Hi Christoph, I do not see any reference to kSecTrustSettingsDomainSystem in your coding. Handling at least kSecTrustSettingsDomainUser and kSecTrustSettingsDomainAdmin is good but I am not sure about kSecTrustSettingsDomainSystem . Did you find some documentation why it should be omitted ? Hi Matthias, yes, I think it is not nicely documented. I've seen in testing, that kSecTrustSettingsDomainSystem merely holds information for trusted root CAs. So in theory, we could add this. However, other code in that area that we've found out in the wild doesn't do it as well. Let's see what others think about this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1550872311 From mbaesken at openjdk.org Wed May 17 07:39:45 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 07:39:45 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates In-Reply-To: References: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com> Message-ID: On Wed, 17 May 2023 07:14:06 GMT, Christoph Langer wrote: > > Hi Christoph, I do not see any reference to kSecTrustSettingsDomainSystem in your coding. Handling at least kSecTrustSettingsDomainUser and kSecTrustSettingsDomainAdmin is good but I am not sure about kSecTrustSettingsDomainSystem . Did you find some documentation why it should be omitted ? > > Hi Matthias, yes, I think it is not nicely documented. I've seen in testing, that kSecTrustSettingsDomainSystem merely holds information for trusted root CAs. So in theory, we could add this. However, other code in that area that we've found out in the wild doesn't do it as well. Let's see what others think about this. Yes this seems to be the case. Could you maybe add a one liner comment to libosxsecurity/KeystoreImpl.m (near to the user and admin domain handling) summarizing what you said? And I still prefer checking the return values of the calls to SecTrustSettingsCopyTrustSettings . ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1550901380 From clanger at openjdk.org Wed May 17 08:06:56 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 May 2023 08:06:56 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Check return code of SecTrustSettingsCopyTrustSettings and address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13945/files - new: https://git.openjdk.org/jdk/pull/13945/files/22303e1c..b14e5f2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=01-02 Stats: 10 lines in 1 file changed: 2 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945 PR: https://git.openjdk.org/jdk/pull/13945 From clanger at openjdk.org Wed May 17 08:06:57 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 May 2023 08:06:57 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates In-Reply-To: References: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com> Message-ID: On Wed, 17 May 2023 07:36:33 GMT, Matthias Baesken wrote: > Yes this seems to be the case. Could you maybe add a one liner comment to libosxsecurity/KeystoreImpl.m (near to the user and admin domain handling) summarizing what you said? And I still prefer checking the return values of the calls to SecTrustSettingsCopyTrustSettings . Done. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1550937990 From djelinski at openjdk.org Wed May 17 10:44:47 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 17 May 2023 10:44:47 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently In-Reply-To: References: Message-ID: On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke wrote: > Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, > > I didn't add any new tests but ran tier 1-3 with no issues src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516: > 514: > 515: if (nccount != -1) { > 516: ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT); Suggestion: ncstring = Integer.toHexString(nccount); `toHexString` returns lowercase string ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196296029 From duke at openjdk.org Wed May 17 11:15:41 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 17 May 2023 11:15:41 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v15] In-Reply-To: References: Message-ID: <0iVXog22Aqp-aEW4CTr8QpLyhM3Svmw2Rk1xL6M_yUc=.a9f92ff7-4c6d-41cf-a0a5-8a6c258d1183@github.com> > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Accepted suggestions from Mark Powers' code review and Intellij. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/cf06b52a..b5701a90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=13-14 Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From asemenov at openjdk.org Wed May 17 12:35:47 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 17 May 2023 12:35:47 GMT Subject: RFR: 8308286 Fix clang warnings in linux code Message-ID: When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". They can be fixed with small changes. ------------- Commit messages: - 8308286 Fix clang warnings in linux code Changes: https://git.openjdk.org/jdk/pull/14033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308286 Stats: 134 lines in 12 files changed: 126 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From mbaesken at openjdk.org Wed May 17 12:45:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 12:45:48 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. >> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. >> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Check return code of SecTrustSettingsCopyTrustSettings and address review comments src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 1: > 1: /* Regarding CFArrayGetValueAtIndex, when looking at other usages of the function in the codebase the result is NULL checked usually. Should we do this here too? I admit the old coding does not have it as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1196455175 From asotona at openjdk.org Wed May 17 12:48:53 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 May 2023 12:48:53 GMT Subject: Integrated: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete In-Reply-To: References: Message-ID: On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote: > Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). > All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. > `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. > Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. > Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: > - `PackageDesc::packageName` to `PackageDesc::name` > - `PackageDesc::packageInternalName` to `PackageDesc::internalName` > - `ModuleDesc::moduleName` to `ModuleDesc::name`. > > Please review this pull request. > > Thanks, > Adam This pull request has now been integrated. Changeset: 5763be72 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/5763be726700be322de3bbaf345d80e11936b472 Stats: 503 lines in 46 files changed: 0 ins; 446 del; 57 mod 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete Reviewed-by: erikj, liach ------------- PR: https://git.openjdk.org/jdk/pull/13979 From weijun at openjdk.org Wed May 17 12:56:11 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 May 2023 12:56:11 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v15] In-Reply-To: <0iVXog22Aqp-aEW4CTr8QpLyhM3Svmw2Rk1xL6M_yUc=.a9f92ff7-4c6d-41cf-a0a5-8a6c258d1183@github.com> References: <0iVXog22Aqp-aEW4CTr8QpLyhM3Svmw2Rk1xL6M_yUc=.a9f92ff7-4c6d-41cf-a0a5-8a6c258d1183@github.com> Message-ID: <_mqzzRAbtglasUWLo6ND-k3VZ4meqj4g7pLfEen1Imo=.7c3653f3-ed33-4b06-829b-5b94851ef116@github.com> On Wed, 17 May 2023 11:15:41 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Accepted suggestions from Mark Powers' code review and Intellij. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1430613514 From mbaesken at openjdk.org Wed May 17 12:57:47 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 12:57:47 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: <4wyu3eHMx4T_OG28OBuAHYJqLxPE_x5gIkB9-BIWiJg=.76f8fe70-600f-4c1e-a985-02b127c229a4@github.com> On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. >> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. >> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Check return code of SecTrustSettingsCopyTrustSettings and address review comments So please check the CFArrayGetValueAtIndex usage, but otherwise looks okay to me now, thanks for the adjustments. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13945#pullrequestreview-1430620036 From shade at openjdk.org Wed May 17 12:59:49 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 May 2023 12:59:49 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev wrote: >> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. >> >> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely. >> >> Example original profile is in the bug. >> >> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns. >> >> On new benchmark: >> >> >> Benchmark Mode Cnt Score Error Units >> >> ## Mac M1 >> >> # Before >> AESReinit.test avgt 15 873,842 ? 6,911 ns/op >> >> # After >> AESReinit.test avgt 15 347,632 ? 8,764 ns/op ; <--- 2.5x faster >> >> ## Xeon, c6.8xlarge >> >> # Before >> AESReinit.test avgt 15 1524.307 ? 24.231 ns/op >> >> # After >> AESReinit.test avgt 15 554.727 ? 12.876 ns/op ; <--- 2.75x faster >> >> ## Graviton, m6g.4xlarge >> >> # Before >> AESReinit.test avgt 15 1913.492 ? 23.489 ns/op >> >> # After >> AESReinit.test avgt 15 639.701 ? 5.033 ns/op ; <--- 2.99x faster >> >> >> Additional testing: >> - [x] Benchmarks >> - [x] macos-aarch64-server-release, `jdk_security` >> - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - Micro-optimizations > - Handle Kd > - Handle Ke @XueleiFan, or anyone else, please take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1551343907 From weijun at openjdk.org Wed May 17 13:11:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 May 2023 13:11:04 GMT Subject: RFR: 8297878: KEM: Implementation [v16] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 07:10:49 GMT, Ferenc Rakoczi wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> to and length and comments > > src/java.base/share/classes/javax/crypto/KEM.java line 233: > >> 231: * of the shared secret as a 128-bit AES key. >> 232: * @throws IndexOutOfBoundsException if {@code from < 0}, >> 233: * {@code from > to}, or {@code to > secretSize()} > > Shouldn't this say "{@code to - from > secretSize()}"? `from` and `to` are indexes into the secret itself, so it's indeed `to` cannot exceed `secretSize()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1196492411 From duke at openjdk.org Wed May 17 13:53:55 2023 From: duke at openjdk.org (Darragh Clarke) Date: Wed, 17 May 2023 13:53:55 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: > Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, > > I didn't add any new tests but ran tier 1-3 with no issues Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java Co-authored-by: Daniel Jelinski - removed StreamTokenizer changes, will make seperate ticket for those ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14006/files - new: https://git.openjdk.org/jdk/pull/14006/files/a79969c2..6d40e1c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006 PR: https://git.openjdk.org/jdk/pull/14006 From duke at openjdk.org Wed May 17 13:53:57 2023 From: duke at openjdk.org (Darragh Clarke) Date: Wed, 17 May 2023 13:53:57 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 10:41:57 GMT, Daniel Jeli?ski wrote: >> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java >> >> Co-authored-by: Daniel Jelinski >> - removed StreamTokenizer changes, will make seperate ticket for those > > src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516: > >> 514: >> 515: if (nccount != -1) { >> 516: ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT); > > Suggestion: > > ncstring = Integer.toHexString(nccount); > > `toHexString` returns lowercase string Thanks for pointing that out! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196555183 From kdriver at openjdk.org Wed May 17 15:10:54 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 17 May 2023 15:10:54 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v8] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - update copyright - reworking the fix in light of encouragement to change the problematic method signature - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java Co-authored-by: Daniel Jelinski - updated copyright - fixes JDK-8294985: throw an SSLException wrapping the IAE ------------- Changes: https://git.openjdk.org/jdk/pull/13466/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=07 Stats: 50 lines in 2 files changed: 32 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From rriggs at openjdk.org Wed May 17 15:52:58 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 May 2023 15:52:58 GMT Subject: RFR: 8308016: Use snippets in java.io package [v2] In-Reply-To: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com> References: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com> Message-ID: On Sun, 14 May 2023 05:50:20 GMT, Tagir F. Valeev wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8308016: Remove ellipses ("...") from snippets > > src/java.base/share/classes/java/io/RandomAccessFile.java line 904: > >> 902: * {@code b7}, and {@code b8,} where: >> 903: * {@snippet lang=java : >> 904: * 0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255, > > Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated. I would keep the snippet markup but change the language to "text"; removing the expectation of language support. The benefits of a consistent look are still desirable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1196733214 From xuelei at openjdk.org Wed May 17 15:53:05 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 15:53:05 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 12 May 2023 20:29:47 GMT, Kevin Driver wrote: >> Do you have any plans to write a test? If not, the bug needs a `noreg` label. > >> Do you have any plans to write a test? If not, the bug needs a `noreg` label. > > As discussed internally, the test that surfaced this issue will be incorporated into regular testing. I have added `noreg-other` since none of the other labels seemed quite appropriate. > @driverkt Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information. @driverkt I'm not very sure. But per this message and the webrevs, it looks like the git use for the PR request might be able to improved by working on git branches, so that you can push the commit for every little change, and avoid force-push. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1551644675 From mpowers at openjdk.org Wed May 17 16:58:07 2023 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 17 May 2023 16:58:07 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification Message-ID: https://bugs.openjdk.org/browse/JDK-8307794 ------------- Commit messages: - added more tests - remove carriage return - micro benchmark and jarsigner test - Ferenc's comments - Max's comments - iteration 2 - iteration 1 Changes: https://git.openjdk.org/jdk/pull/13940/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307794 Stats: 5726 lines in 3 files changed: 5726 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940 PR: https://git.openjdk.org/jdk/pull/13940 From bpb at openjdk.org Wed May 17 17:07:15 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 May 2023 17:07:15 GMT Subject: RFR: 8308016: Use snippets in java.io package [v6] In-Reply-To: References: Message-ID: > Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Reinstate @snippet for RandomAccessFile::readLong ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/724a74a9..8ae42cf2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From mullan at openjdk.org Wed May 17 17:37:50 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 May 2023 17:37:50 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. >> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. >> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Check return code of SecTrustSettingsCopyTrustSettings and address review comments Please don't integrate this until I or someone from my team reviews it. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1551804692 From mullan at openjdk.org Wed May 17 18:17:50 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 May 2023 18:17:50 GMT Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end In-Reply-To: References: Message-ID: On Fri, 12 May 2023 16:23:53 GMT, Weijun Wang wrote: > When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end. src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 99: > 97: } catch (IOException e) { > 98: throw new InvalidKeyException("IOException: " + > 99: e.getMessage()); How about including the cause in the IKE? Also, I suggest an error message such as "unable to decode key". Same comments for `X509Key`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13958#discussion_r1196897272 From weijun at openjdk.org Wed May 17 18:30:06 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 May 2023 18:30:06 GMT Subject: RFR: 8297878: KEM: Implementation [v17] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge branch 'master' into 8297878 - to and length and comments - deterministic randomness - Resolve Siba's comment - providerName - more @since and about nulls - Merge branch 'master' into 8297878 - no more pk/sk, AIOOBE to IOOBE - small spec change - some constants, no local reverse - ... and 7 more: https://git.openjdk.org/jdk/compare/e1e90f92...655d2523 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/ea8f7964..655d2523 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=15-16 Stats: 145061 lines in 2474 files changed: 112277 ins; 13968 del; 18816 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From xuelei at openjdk.org Wed May 17 18:52:51 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 18:52:51 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:57:15 GMT, Aleksey Shipilev wrote: > @XueleiFan, or anyone else, please take a look? I will have a look, but I may need more time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1551895053 From dfuchs at openjdk.org Wed May 17 18:54:20 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 17 May 2023 18:54:20 GMT Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within synchronized blocks Message-ID: Please find here a change that revisits usage of monitors in the HttpClient. With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream. This change aims at avoiding situations where the carrier threads might get pinned. ------------- Commit messages: - 8308310 Changes: https://git.openjdk.org/jdk/pull/14038/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308310 Stats: 886 lines in 31 files changed: 518 ins; 110 del; 258 mod Patch: https://git.openjdk.org/jdk/pull/14038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038 PR: https://git.openjdk.org/jdk/pull/14038 From mullan at openjdk.org Wed May 17 18:55:54 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 May 2023 18:55:54 GMT Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end In-Reply-To: <-ky9hEDy-CUetTuhH5uqbTjkpO81TpMz7ixudOw5bUg=.a2d78b86-0daf-4dba-98ec-a0317bafae7c@github.com> References: <-ky9hEDy-CUetTuhH5uqbTjkpO81TpMz7ixudOw5bUg=.a2d78b86-0daf-4dba-98ec-a0317bafae7c@github.com> Message-ID: On Wed, 17 May 2023 18:51:11 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 99: >> >>> 97: } catch (IOException e) { >>> 98: throw new InvalidKeyException("IOException: " + >>> 99: e.getMessage()); >> >> How about including the cause in the IKE? Also, I suggest an error message such as "unable to decode key". >> >> Same comments for `X509Key`. > > Oh, that was old behavior. Would you like the same for https://github.com/openjdk/jdk/blob/199c84a0a2b74f855d75871a26205e05bcf8dc4b/src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java#L138 as well? Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13958#discussion_r1196935852 From weijun at openjdk.org Wed May 17 18:55:53 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 May 2023 18:55:53 GMT Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end In-Reply-To: References: Message-ID: <-ky9hEDy-CUetTuhH5uqbTjkpO81TpMz7ixudOw5bUg=.a2d78b86-0daf-4dba-98ec-a0317bafae7c@github.com> On Wed, 17 May 2023 18:14:38 GMT, Sean Mullan wrote: >> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end. > > src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 99: > >> 97: } catch (IOException e) { >> 98: throw new InvalidKeyException("IOException: " + >> 99: e.getMessage()); > > How about including the cause in the IKE? Also, I suggest an error message such as "unable to decode key". > > Same comments for `X509Key`. Oh, that was old behavior. Would you like the same for https://github.com/openjdk/jdk/blob/199c84a0a2b74f855d75871a26205e05bcf8dc4b/src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java#L138 as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13958#discussion_r1196933541 From valeriep at openjdk.org Wed May 17 19:12:08 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 17 May 2023 19:12:08 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Wed, 17 May 2023 03:11:54 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Rebase fix after JDK-8306033. Replace called functions with their new names. > - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao > - 8301553: Support Password-Based Cryptography in SunPKCS11 > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 115: > 113: try { > 114: derivedKey = PKCS12PBECipherCore.derive( > 115: keySpec.getPassword(), keySpec.getSalt(), Comparing to the original impl, this new call of keySpec.getPassword() produces extra copy of password which needs to be cleared as well. src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 121: > 119: keySpec.clearPassword(); > 120: } > 121: SecretKey cipherKey = new SecretKeySpec(derivedKey, "HmacSHA1"); Can clear out the "derivedKey" bytes if no longer needed. src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 165: > 163: byte[] derivedKey = s.getEncoded(); > 164: s.clearPassword(); > 165: SecretKeySpec cipherKey = new SecretKeySpec(derivedKey, cipherAlgo); Clear out the "derivedKey" bytes if no longer needed. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 345: > 343: throw new InvalidKeyException("Encoded format must be RAW"); > 344: } > 345: byte[] encoded = key.getEncoded(); Would be nice to clear out "encoded" bytes afterwards. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 362: > 360: session = token.getObjSession(); > 361: CK_MECHANISM ckMech; > 362: char[] password = keySpec.getPassword(); Should clear out "password" afterwards. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 391: > 389: } > 390: > 391: char[] encPassword; Same, clear out "encPassword" afterwards. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 444: > 442: int keyLength = 0; > 443: if ("RAW".equalsIgnoreCase(pbeKey.getFormat())) { > 444: byte[] encoded = pbeKey.getEncoded(); Should clear out "encoded" afterwards. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 450: > 448: } > 449: int ic = pbeKey.getIterationCount(); > 450: char[] pwd = pbeKey.getPassword(); Should clear out "pwd" afterwards. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 562: > 560: } else if (algorithm.equalsIgnoreCase("DES")) { > 561: if (keySpec instanceof DESKeySpec desKeySpec) { > 562: byte[] keyBytes = desKeySpec.getKey(); Would be nice to clear out "keyBytes" afterwards. Same goes for the other "keyBytes" in the same method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196925886 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196926732 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196936604 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196940708 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196942089 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196943128 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196944774 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196946761 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196951831 From duke at openjdk.org Wed May 17 20:01:26 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 17 May 2023 20:01:26 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v16] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: More input checks. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/b5701a90..9801b158 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=14-15 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From kdriver at openjdk.org Wed May 17 20:06:08 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 17 May 2023 20:06:08 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v9] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985 - update copyright - reworking the fix in light of encouragement to change the problematic method signature - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java Co-authored-by: Daniel Jelinski - updated copyright - fixes JDK-8294985: throw an SSLException wrapping the IAE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/d02cfd1c..3ffdfd63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=07-08 Stats: 1799 lines in 11 files changed: 1789 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From xuelei at openjdk.org Wed May 17 20:12:49 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 20:12:49 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev wrote: >> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. >> >> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely. >> >> Example original profile is in the bug. >> >> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns. >> >> On new benchmark: >> >> >> Benchmark Mode Cnt Score Error Units >> >> ## Mac M1 >> >> # Before >> AESReinit.test avgt 15 873,842 ? 6,911 ns/op >> >> # After >> AESReinit.test avgt 15 347,632 ? 8,764 ns/op ; <--- 2.5x faster >> >> ## Xeon, c6.8xlarge >> >> # Before >> AESReinit.test avgt 15 1524.307 ? 24.231 ns/op >> >> # After >> AESReinit.test avgt 15 554.727 ? 12.876 ns/op ; <--- 2.75x faster >> >> ## Graviton, m6g.4xlarge >> >> # Before >> AESReinit.test avgt 15 1913.492 ? 23.489 ns/op >> >> # After >> AESReinit.test avgt 15 639.701 ? 5.033 ns/op ; <--- 2.99x faster >> >> >> Additional testing: >> - [x] Benchmarks >> - [x] macos-aarch64-server-release, `jdk_security` >> - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - Micro-optimizations > - Handle Kd > - Handle Ke Looks good to me. Please make sure the security regression testing passed. ------------- Marked as reviewed by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13996#pullrequestreview-1431510226 From duke at openjdk.org Wed May 17 20:48:52 2023 From: duke at openjdk.org (David Schlosnagle) Date: Wed, 17 May 2023 20:48:52 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev wrote: >> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. >> >> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely. >> >> Example original profile is in the bug. >> >> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns. >> >> On new benchmark: >> >> >> Benchmark Mode Cnt Score Error Units >> >> ## Mac M1 >> >> # Before >> AESReinit.test avgt 15 873,842 ? 6,911 ns/op >> >> # After >> AESReinit.test avgt 15 347,632 ? 8,764 ns/op ; <--- 2.5x faster >> >> ## Xeon, c6.8xlarge >> >> # Before >> AESReinit.test avgt 15 1524.307 ? 24.231 ns/op >> >> # After >> AESReinit.test avgt 15 554.727 ? 12.876 ns/op ; <--- 2.75x faster >> >> ## Graviton, m6g.4xlarge >> >> # Before >> AESReinit.test avgt 15 1913.492 ? 23.489 ns/op >> >> # After >> AESReinit.test avgt 15 639.701 ? 5.033 ns/op ; <--- 2.99x faster >> >> >> Additional testing: >> - [x] Benchmarks >> - [x] macos-aarch64-server-release, `jdk_security` >> - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - Micro-optimizations > - Handle Kd > - Handle Ke I don't think my review counts, but this looks good to me ------------- Marked as reviewed by schlosna at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/13996#pullrequestreview-1431597342 From bpb at openjdk.org Wed May 17 20:51:29 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 May 2023 20:51:29 GMT Subject: RFR: 8308016: Use snippets in java.io package [v7] In-Reply-To: References: Message-ID: > Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge - 8308016: Reinstate @snippet for RandomAccessFile::readLong - 8308016: Reduce linking in File::toPath snippet - 8308016: Fix link in snippet of File::toPath - 8308016: Address reviewer comments since previous commit - 8308016: Remove ellipses ("...") from snippets - 8308016: Use snippets in java.io package ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/8ae42cf2..d0dce640 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=05-06 Stats: 13770 lines in 553 files changed: 8566 ins; 1596 del; 3608 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From weijun at openjdk.org Wed May 17 20:52:51 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 May 2023 20:52:51 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: <7VtFRAbOyuD3iAwIUq0SPrylxAg4SOkjDdLKVBMytoY=.fc9dd81c-1442-4d11-a850-fcb17d64452b@github.com> On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. >> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. >> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Check return code of SecTrustSettingsCopyTrustSettings and address review comments No matter what `SecTrustSettingsCopyTrustSettings` returns, you will always call `jm_createTrustedCertEntry`. This means if I add a self-signed certificate but has not added any trusted settings onto it, it will be always trusted. Is this intended? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552066526 From clanger at openjdk.org Wed May 17 21:13:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 May 2023 21:13:49 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 17:34:42 GMT, Sean Mullan wrote: > Please don't integrate this until I or someone from my team reviews it. Thanks. Sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552088991 From clanger at openjdk.org Wed May 17 21:32:50 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 May 2023 21:32:50 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: <7VtFRAbOyuD3iAwIUq0SPrylxAg4SOkjDdLKVBMytoY=.fc9dd81c-1442-4d11-a850-fcb17d64452b@github.com> References: <7VtFRAbOyuD3iAwIUq0SPrylxAg4SOkjDdLKVBMytoY=.fc9dd81c-1442-4d11-a850-fcb17d64452b@github.com> Message-ID: On Wed, 17 May 2023 20:49:34 GMT, Weijun Wang wrote: > No matter what `SecTrustSettingsCopyTrustSettings` returns, you will always call `jm_createTrustedCertEntry`. This means if I add a self-signed certificate but has not added any trusted settings onto it, it will be always trusted. Is this intended? Yes, I will call `jm_createTrustedCertEntry` for every certificate, at least independent from the results of the `SecTrustSettingsCopyTrustSettings` calls. As I outlined in my initial PR description, point 3, the actual check whether a certificate is self-signed is done in the `createTrustedCertEntry` Java method. So, yes, when there is a self-signed certificate without explicit trust settings, it is always trusted. I thought that this was the intentional behavior even before my changes. However, the difference to the code before is that I look at the certificate and check whether it is a real plain self-signed certificate that can be used for TLS communication - which would be trusted. But what's not trusted now are CA root certificates which also means self-signed but additionally key usage 'keyCertSign' and/or 'cRLSign'. See [this code](https://github.com/RealCLanger/jdk/blob/b14e5f2c78ff4aded84410a2b58d83138349d9ab/src/java.base/macosx/classes/apple/security/KeychainStore.java#L857) Makes sense? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552107272 From clanger at openjdk.org Wed May 17 21:32:54 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 May 2023 21:32:54 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:42:32 GMT, Matthias Baesken wrote: >> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: >> >> Check return code of SecTrustSettingsCopyTrustSettings and address review comments > > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 1: > >> 1: /* > > Regarding CFArrayGetValueAtIndex, when looking at other usages of the function in the codebase the result is NULL checked usually. Should we do this here too? I admit the old coding does not have it as well. Hm, can it really be NULL? I mean before we check the array size and then iterate the valid range. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1197070738 From kdriver at openjdk.org Wed May 17 21:54:20 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 17 May 2023 21:54:20 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v10] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: rework based upon code review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/3ffdfd63..0aa93e2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=08-09 Stats: 52 lines in 2 files changed: 17 ins; 15 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From kdriver at openjdk.org Wed May 17 21:58:53 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 17 May 2023 21:58:53 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <_N61Dcd8QmAoinlIlYD3K40_78FlXVCdh513OFeq7ME=.01dae3ad-be0a-4763-9022-c03bdc534992@github.com> On Fri, 12 May 2023 20:14:56 GMT, Sean Mullan wrote: >> Kevin Driver has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > Do you have any plans to write a test? If not, the bug needs a `noreg` label. @seanjmullan @XueleiFan - ready for another round of reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1552140738 From weijun at openjdk.org Thu May 18 00:03:50 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 00:03:50 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: References: Message-ID: <2dBwm9ZtkuIaWeJdSnE-_rZdaGxLowoeuT77pdXrM_U=.10eefa2c-be1c-4b78-878a-e9bd73d7ca5c@github.com> On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. >> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. >> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Check return code of SecTrustSettingsCopyTrustSettings and address review comments Before your new change, such a certificate is not trusted, because `SecTrustSettingsCopyTrustSettings` returns `errSecItemNotFound` so `jm_createTrustedCertEntry` is not called at all. I am not sure if such a certificate is meant to be always trusted. Note that you can create such an entry with only `security add-certificates` but not `security add-trusted-cert`. macOS allows anyone to run the first command but prompts you for an administrator password when running the second. The name of the second command also implies that it's the only way to assign trust to a certificate, IMHO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552229495 From xuelei at openjdk.org Thu May 18 04:08:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 04:08:55 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v10] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Wed, 17 May 2023 21:54:20 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > rework based upon code review comments Similar comments for update in CertificateRequest.java Similar comments for update in CertificateRequest.java src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 126: > 124: } > 125: > 126: X500Principal[] getAuthorities() throws IllegalArgumentException { IAE is unchecked exception, and should not be throwing explicitly in method signature/statement. I'm not sure if this throwing is really helpful for caller to check the exception. src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 147: > 145: builder.append(principal.toString()); > 146: } catch (IllegalArgumentException iae) { > 147: builder.append("unparseable X500Principal"); I may use the iae message as well for better debugging. src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 289: > 287: shc.peerSupportedAuthorities = spec.getAuthorities(); > 288: } catch (IllegalArgumentException iae) { > 289: shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed"); To easy debugging, I may use the exception with fatal(Alert alert, String diagnostic, Throwable cause). Considering this point, I may prefer to throw SSLException in getAuthorities() method. X500Principal[] getAuthorities() throws SSLException { ... try { shc.peerSupportedAuthorities = spec.getAuthorities(); } catch (SSLException ssle) { shc.conContext.fatal(Alert.DECODE_ERROR, "Cannot parse peer supported authorities", ssle); } ------------- Changes requested by xuelei (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1431961001 PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1431970382 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197326576 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197327083 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197334523 From shade at openjdk.org Thu May 18 06:46:49 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 18 May 2023 06:46:49 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com> On Wed, 17 May 2023 20:09:50 GMT, Xue-Lei Andrew Fan wrote: > Looks good to me. Please make sure the security regression testing passed. Thanks! By "security regression testing" that you mean `jdk_security`, or something else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1552552955 From xuelei at openjdk.org Thu May 18 07:20:54 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 07:20:54 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com> References: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com> Message-ID: On Thu, 18 May 2023 06:44:10 GMT, Aleksey Shipilev wrote: > > Looks good to me. Please make sure the security regression testing passed. > > Thanks! By "security regression testing" that you mean `jdk_security`, or something else? jdk_security or tier2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1552616281 From shade at openjdk.org Thu May 18 07:20:54 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 18 May 2023 07:20:54 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com> Message-ID: On Thu, 18 May 2023 07:16:31 GMT, Xue-Lei Andrew Fan wrote: > jdk_security or tier2. Gotcha, I already tested both, see "Additional Testing" section in PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1552619095 From duke at openjdk.org Thu May 18 08:54:49 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 18 May 2023 08:54:49 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:06:59 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8307794 I suggest the following: 1. Separate the data from the code and put the data to the end of the files (e.g. create a " TestCase[] testCases;" array and let the TestCase class handle the creation of the byte arrays from the hex strings. A testCase can have expected outcome, along with the data, too, that might make the actual testing code more compact. 2. Reformat all the data similarly to the one in DisableLMS.java (about 80 character long lines) - there are some very long lines in HssLms.java and very short ones in TestLMS.java and HssLms.java . 3. Don't us simply LMS in the file names. HSS or HSSLMS would align better with what you are testing. 4. Remove the SHAKE tests (test11-13 in HssLms.java . ------------- PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1552743471 From djelinski at openjdk.org Thu May 18 09:47:52 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 18 May 2023 09:47:52 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke wrote: >> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, >> >> I didn't add any new tests but ran tier 1-3 with no issues > > Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java > > Co-authored-by: Daniel Jelinski > - removed StreamTokenizer changes, will make seperate ticket for those Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432388069 From dfuchs at openjdk.org Thu May 18 10:04:51 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 18 May 2023 10:04:51 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: <0GxhPfV9kjdGq_66qtf-4bnWOhVwd5wZKr4HVDbBvkE=.fd5017df-882c-48a8-b373-34d6204664a1@github.com> On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke wrote: >> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, >> >> I didn't add any new tests but ran tier 1-3 with no issues > > Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java > > Co-authored-by: Daniel Jelinski > - removed StreamTokenizer changes, will make seperate ticket for those LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432410653 From mullan at openjdk.org Thu May 18 12:53:57 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 12:53:57 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v10] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 03:51:55 GMT, Xue-Lei Andrew Fan wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> rework based upon code review comments > > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 126: > >> 124: } >> 125: >> 126: X500Principal[] getAuthorities() throws IllegalArgumentException { > > IAE is unchecked exception, and should not be throwing explicitly in method signature/statement. I'm not sure if this throwing is really helpful for caller to check the exception. Yes, I agree with that comment. I suggest adding a comment above the method to remind callers they may need to catch IAE, something like: // This method will throw IllegalArgumentException if the X500Principal cannot be parsed. > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 147: > >> 145: builder.append(principal.toString()); >> 146: } catch (IllegalArgumentException iae) { >> 147: builder.append("unparseable X500Principal"); > > I may use the iae message as well for better debugging. Yes, suggest: `builder.append("unparseable X500Principal: " + iae.getMessage());` > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 289: > >> 287: shc.peerSupportedAuthorities = spec.getAuthorities(); >> 288: } catch (IllegalArgumentException iae) { >> 289: shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed"); > > To easy debugging, I may use the exception with fatal(Alert alert, String diagnostic, Throwable cause). Considering this point, I may prefer to throw SSLException in getAuthorities() method. > > > X500Principal[] getAuthorities() throws SSLException { > ... > try { > shc.peerSupportedAuthorities = spec.getAuthorities(); > } catch (SSLException ssle) { > shc.conContext.fatal(Alert.DECODE_ERROR, "Cannot parse peer supported authorities", ssle); > } @XueleiFan Seems like an unnecessary wrapping of IAE when it is going to be rethrown anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197768251 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197771043 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197773420 From mullan at openjdk.org Thu May 18 12:53:59 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 12:53:59 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v10] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <2jKNqaE6Q3u17GL1X_dLvnrHkNQKbYoyzLhsSxj3Dyk=.3be8d3aa-aff3-42cd-bfb9-623d75e17918@github.com> On Wed, 17 May 2023 21:54:20 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > rework based upon code review comments src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 738: > 736: try { > 737: chc.peerSupportedAuthorities = crm.getAuthorities(); > 738: } Move the `catch` line up to line 738. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197776053 From mullan at openjdk.org Thu May 18 13:25:55 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 13:25:55 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:06:59 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8307794 test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 26: > 24: /* > 25: * @test > 26: * @bug JDK-8307794 I think the bug here should be what it is testing, which is the HSS/LMS implementation (JDK-8298127). Same comment for other tests. test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 28: > 26: * @bug JDK-8307794 > 27: * @summary verify JAR files signed with HSS/LMS > 28: * @author Wang Weijun We don't usually put `@author` labels in code/tests anymore. test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 39: > 37: import java.util.Base64; > 38: > 39: public class DisableLMS { The name of this test seems too specific, since it also tests a signed JAR when HSS/LMS is not disabled. Perhaps rename this to `VerifyHSSLMSSignedJar`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197812930 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197814003 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197818398 From weijun at openjdk.org Thu May 18 13:39:10 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 13:39:10 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v8] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: <4IiFTRwAih-0sEDpmyqSSTulbp6L4mFy93M2Ye0oWGM=.dde82a5b-de60-4148-94a6-e7acedbe29a8@github.com> > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into 8305972 - fix here - update version in comment only in patch2: unchanged: - add here() back - Merge branch 'master' into 8305972 - comment for new test - no more secret exports, one message change - more comment and spec refine - cleanup commented out code and unnecessary bug id - the change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/e4dc75b0..ba36ae3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=06-07 Stats: 110983 lines in 1856 files changed: 86609 ins; 9774 del; 14600 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From mullan at openjdk.org Thu May 18 13:45:53 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 13:45:53 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v8] In-Reply-To: <4IiFTRwAih-0sEDpmyqSSTulbp6L4mFy93M2Ye0oWGM=.dde82a5b-de60-4148-94a6-e7acedbe29a8@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> <4IiFTRwAih-0sEDpmyqSSTulbp6L4mFy93M2Ye0oWGM=.dde82a5b-de60-4148-94a6-e7acedbe29a8@github.com> Message-ID: On Thu, 18 May 2023 13:39:10 GMT, Weijun Wang wrote: >> Update XML Security for Java to 3.0.2. Some change to tests: >> >> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". >> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'master' into 8305972 > - fix here > - update version in comment > > only in patch2: > unchanged: > - add here() back > - Merge branch 'master' into 8305972 > - comment for new test > - no more secret exports, one message change > - more comment and spec refine > - cleanup commented out code and unnecessary bug id > - the change Just one wording suggestion. Otherwise looks good ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13840#pullrequestreview-1429167827 From mullan at openjdk.org Thu May 18 13:45:57 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 13:45:57 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v6] In-Reply-To: References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: On Tue, 16 May 2023 01:10:10 GMT, Weijun Wang wrote: >> Update XML Security for Java to 3.0.2. Some change to tests: >> >> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". >> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - add here() back > - Merge branch 'master' into 8305972 > - comment for new test > - no more secret exports, one message change > - more comment and spec refine > - cleanup commented out code and unnecessary bug id > - the change src/java.base/share/conf/security/java.security line 1005: > 1003: > 1004: # > 1005: # Support here() function s/Support/Support for the/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1195545852 From xuelei at openjdk.org Thu May 18 14:16:01 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 14:16:01 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v10] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <_L3NRbs51f14oTrJnV9i46E3ZhfHGjg2V2UQi90in10=.52c3d975-a656-40e7-bc11-a40a75c6eb46@github.com> On Thu, 18 May 2023 04:04:17 GMT, Xue-Lei Andrew Fan wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> rework based upon code review comments > > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 289: > >> 287: shc.peerSupportedAuthorities = spec.getAuthorities(); >> 288: } catch (IllegalArgumentException iae) { >> 289: shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed"); > > To easy debugging, I may use the exception with fatal(Alert alert, String diagnostic, Throwable cause). Considering this point, I may prefer to throw SSLException in getAuthorities() method. > > > X500Principal[] getAuthorities() throws SSLException { > ... > try { > shc.peerSupportedAuthorities = spec.getAuthorities(); > } catch (SSLException ssle) { > shc.conContext.fatal(Alert.DECODE_ERROR, "Cannot parse peer supported authorities", ssle); > } > @XueleiFan Seems like an unnecessary wrapping of IAE when it is going to be rethrown anyway. I'm fine if IAE get checked for every call to getAuthorities(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197881532 From xuelei at openjdk.org Thu May 18 14:17:51 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 14:17:51 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com> Message-ID: On Thu, 18 May 2023 07:18:04 GMT, Aleksey Shipilev wrote: > > jdk_security or tier2. > > Gotcha, I already tested both, see "Additional Testing" section in PR. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1553126729 From weijun at openjdk.org Thu May 18 14:24:02 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 14:24:02 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v9] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: <86ADeAGG-onak6Mna95bcb5ptptuiqYWXvup40EdH0M=.8ff8e417-d676-4636-9c6c-5baacde743c9@github.com> > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: title in java.security ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/ba36ae3d..407832d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From weijun at openjdk.org Thu May 18 14:48:58 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 14:48:58 GMT Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end [v2] In-Reply-To: References: Message-ID: > When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: add reasons ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13958/files - new: https://git.openjdk.org/jdk/pull/13958/files/199c84a0..65357365 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13958&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13958&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13958/head:pull/13958 PR: https://git.openjdk.org/jdk/pull/13958 From weijun at openjdk.org Thu May 18 15:15:30 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 15:15:30 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v10] In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: test modifies policy should run in othervm mode only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13840/files - new: https://git.openjdk.org/jdk/pull/13840/files/407832d0..c98e2edd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=08-09 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840 PR: https://git.openjdk.org/jdk/pull/13840 From mpowers at openjdk.org Thu May 18 15:39:53 2023 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 18 May 2023 15:39:53 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification In-Reply-To: References: Message-ID: On Thu, 18 May 2023 13:18:12 GMT, Sean Mullan wrote: >> https://bugs.openjdk.org/browse/JDK-8307794 > > test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug JDK-8307794 > > I think the bug here should be what it is testing, which is the HSS/LMS implementation (JDK-8298127). Same comment for other tests. fixed > test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 28: > >> 26: * @bug JDK-8307794 >> 27: * @summary verify JAR files signed with HSS/LMS >> 28: * @author Wang Weijun > > We don't usually put `@author` labels in code/tests anymore. removed` @author` > test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 39: > >> 37: import java.util.Base64; >> 38: >> 39: public class DisableLMS { > > The name of this test seems too specific, since it also tests a signed JAR when HSS/LMS is not disabled. Perhaps rename this to `VerifyHSSLMSSignedJar`? renamed to `VerifyHSSLMSSignedJar` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197973701 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197974502 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197975370 From kdriver at openjdk.org Thu May 18 16:07:59 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 16:07:59 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v10] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 12:42:20 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 126: >> >>> 124: } >>> 125: >>> 126: X500Principal[] getAuthorities() throws IllegalArgumentException { >> >> IAE is unchecked exception, and should not be throwing explicitly in method signature/statement. I'm not sure if this throwing is really helpful for caller to check the exception. > > Yes, I agree with that comment. I suggest adding a comment above the method to remind callers they may need to catch IAE, something like: > > // This method will throw IllegalArgumentException if the X500Principal cannot be parsed. Agreed. It's atypical (at least) to include a RuntimeException in the method signature. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198005604 From aturbanov at openjdk.org Thu May 18 16:12:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 18 May 2023 16:12:12 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v16] In-Reply-To: References: Message-ID: <6N04iO3eVgcUvVAMzFPIsKrHeTJ6FPdiKzCfhs8BDrI=.77854da9-17a3-4e96-9335-103f54412477@github.com> On Wed, 17 May 2023 20:01:26 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > More input checks. src/java.base/share/classes/sun/security/provider/HSS.java line 191: > 189: > 190: static class LMSUtils { > 191: final static int LMS_RESERVED = 0; use blessed modifiers order Suggestion: static final int LMS_RESERVED = 0; src/java.base/share/classes/sun/security/provider/HSS.java line 216: > 214: final static int LMOTS_SHA256_N32_W2 = 2; > 215: final static int LMOTS_SHA256_N32_W4 = 3; > 216: final static int LMOTS_SHA256_N32_W8 = 4; Suggestion: static final int LMOTS_RESERVED = 0; static final int LMOTS_SHA256_N32_W1 = 1; static final int LMOTS_SHA256_N32_W2 = 2; static final int LMOTS_SHA256_N32_W4 = 3; static final int LMOTS_SHA256_N32_W8 = 4; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198008506 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198009083 From kdriver at openjdk.org Thu May 18 16:15:39 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 16:15:39 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: review comments addressed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/0aa93e2a..5a20371e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=09-10 Stats: 15 lines in 2 files changed: 3 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From kdriver at openjdk.org Thu May 18 16:23:59 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 16:23:59 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v6] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Wed, 17 May 2023 15:49:27 GMT, Xue-Lei Andrew Fan wrote: >>> Do you have any plans to write a test? If not, the bug needs a `noreg` label. >> >> As discussed internally, the test that surfaced this issue will be incorporated into regular testing. I have added `noreg-other` since none of the other labels seemed quite appropriate. > >> @driverkt Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information. > > @driverkt I'm not very sure. But per this message and the webrevs, it looks like the git use for the PR request might be able to improved by working on git branches, so that you can push the commit for every little change, and avoid force-push. @XueleiFan @seanjmullan all comments have been addressed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1553300216 From aturbanov at openjdk.org Thu May 18 16:24:17 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 18 May 2023 16:24:17 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v16] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 20:01:26 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > More input checks. src/java.base/share/classes/sun/security/provider/HSS.java line 36: > 34: import java.util.Arrays; > 35: > 36: /* Can we make it a javadoc? Suggestion: /** src/java.base/share/classes/sun/security/provider/HSS.java line 410: > 408: final int sigLmType; > 409: final int sigOtsType; > 410: final private byte[] qArr; let's remove `private` to be consistent with other fields Suggestion: final byte[] qArr; src/java.base/share/classes/sun/security/provider/HSS.java line 415: > 413: final int n; // output length of the hash function used in the OTS > 414: final int p; // number of hash chains in the signature > 415: final int m; // output length of the hash fubction used in the Merkle tree typo `fubction` src/java.base/share/classes/sun/security/provider/HSS.java line 428: > 426: > 427: LMOTSParams lmotsParams; > 428: q = LMSUtils.fourBytesToInt(sigArray, offset); indentations is confusing here src/java.base/share/classes/sun/security/provider/HSS.java line 512: > 510: // Precomputed block for SHA256 when the message size is 55 bytes > 511: // (i.e. when SHA256 is used) > 512: private final static byte[] hashbufSha256_32 = { Suggestion: private static final byte[] hashbufSha256_32 = { src/java.base/share/classes/sun/security/provider/HSS.java line 711: > 709: protected Key engineTranslateKey(Key key) throws InvalidKeyException { > 710: if (key == null) { > 711: throw new InvalidKeyException("key cannot be null"); Suggestion: throw new InvalidKeyException("key cannot be null"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198023023 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198020705 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198020959 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198018892 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198018138 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198024479 From mullan at openjdk.org Thu May 18 16:46:56 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 16:46:56 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> Message-ID: On Thu, 18 May 2023 16:15:39 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > review comments addressed src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 33: > 31: import java.text.MessageFormat; > 32: import java.util.*; > 33: import javax.net.ssl.SSLException; This import is not needed anymore. src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 35: > 33: import java.util.*; > 34: import javax.net.ssl.SSLEngine; > 35: import javax.net.ssl.SSLException; This import is not needed anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198042070 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198043800 From xuelei at openjdk.org Thu May 18 16:46:58 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 16:46:58 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> Message-ID: On Thu, 18 May 2023 16:15:39 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > review comments addressed src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 148: > 146: builder.append(principal.toString()); > 147: } catch (IllegalArgumentException iae) { > 148: builder.append("unparseable X500Principal: " + iae.getMessage()); Throwable.getMessage() may return `null`. I may use iae.toString() instead. `builder.append("unparseable X500Principal: " + iae);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198044980 From djelinski at openjdk.org Thu May 18 16:57:52 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 18 May 2023 16:57:52 GMT Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> Message-ID: <55PJuNTFQVH_K3zqyzRFWCpu2L6T6BKERX0lV91_HdA=.729132f2-7533-4a3c-9965-5698f05e8991@github.com> On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh wrote: > This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE. For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior. > > - Issue: https://bugs.openjdk.org/browse/JDK-8305091 > - CSR: https://bugs.openjdk.org/browse/JDK-8305822 Thank you for that. This is actually required for decrypting QUIC packets; the QUIC specification permits dropping duplicate packets only after fully decrypting them. LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13428#pullrequestreview-1433082578 From xuelei at openjdk.org Thu May 18 16:59:40 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 16:59:40 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> Message-ID: On Thu, 18 May 2023 16:15:39 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > review comments addressed src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 290: > 288: shc.peerSupportedAuthorities = spec.getAuthorities(); > 289: } catch (IllegalArgumentException iae) { > 290: shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed", iae); In the context, it may be easier to catch the idea if the message is about the authorities, and easier to update getAuthorities() implementation, for example X500Principal is not used any longer, if needed in the future. - "X500Principal could not be parsed" + "Peer authorities could not be parsed" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198051462 From kdriver at openjdk.org Thu May 18 16:59:32 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 16:59:32 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v12] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: optimize imports and change toString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/5a20371e..e33a9b0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=10-11 Stats: 33 lines in 2 files changed: 14 ins; 5 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From kdriver at openjdk.org Thu May 18 16:59:38 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 16:59:38 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> Message-ID: <0NGU7VDtItrnf0Pu4i0afJb7e0RB-MJIQAUxMYx4WyU=.4166cd66-9872-4f7b-90ee-a34c5e77e461@github.com> On Thu, 18 May 2023 16:42:45 GMT, Xue-Lei Andrew Fan wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments addressed > > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 148: > >> 146: builder.append(principal.toString()); >> 147: } catch (IllegalArgumentException iae) { >> 148: builder.append("unparseable X500Principal: " + iae.getMessage()); > > Throwable.getMessage() may return `null`. I may use iae.toString() instead. > > `builder.append("unparseable X500Principal: " + iae);` `toString` would be called implicitly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198052098 From bpb at openjdk.org Thu May 18 17:01:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 May 2023 17:01:54 GMT Subject: RFR: 8308016: Use snippets in java.io package [v2] In-Reply-To: References: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com> Message-ID: On Wed, 17 May 2023 15:50:13 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/RandomAccessFile.java line 904: >> >>> 902: * {@code b7}, and {@code b8,} where: >>> 903: * {@snippet lang=java : >>> 904: * 0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255, >> >> Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated. > > I would keep the snippet markup but change the language to "text"; removing the expectation of language support. > The benefits of a consistent look are still desirable. Changed to unspecified language in 8ae42cf24b931d21dc643d233f33d4ccc5b32d6f. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198061816 From kdriver at openjdk.org Thu May 18 17:02:01 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 17:02:01 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> Message-ID: On Thu, 18 May 2023 16:48:34 GMT, Xue-Lei Andrew Fan wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments addressed > > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 290: > >> 288: shc.peerSupportedAuthorities = spec.getAuthorities(); >> 289: } catch (IllegalArgumentException iae) { >> 290: shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed", iae); > > In the context, it may be easier to catch the idea if the message is about the authorities, and easier to update getAuthorities() implementation, for example X500Principal is not used any longer, if needed in the future. > > - "X500Principal could not be parsed" > + "Peer authorities could not be parsed" I'm inclined to keep the current version. It seems more specific in guiding the caller to the fix needed. However, I understand your point. @seanjmullan comments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198061874 From weijun at openjdk.org Thu May 18 17:07:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 17:07:40 GMT Subject: RFR: 8297878: KEM: Implementation [v18] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Merge branch 'master' into 8297878 - Merge branch 'master' into 8297878 - to and length and comments - deterministic randomness - Resolve Siba's comment - providerName - more @since and about nulls - Merge branch 'master' into 8297878 - no more pk/sk, AIOOBE to IOOBE - small spec change - ... and 8 more: https://git.openjdk.org/jdk/compare/bccb8927...7cace182 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/655d2523..7cace182 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=16-17 Stats: 5872 lines in 78 files changed: 4595 ins; 1087 del; 190 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From mullan at openjdk.org Thu May 18 17:14:55 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 17:14:55 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v11] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com> Message-ID: <4rBEcllezxknzMpU7_41PpuAqv8K5xPuBkSmCB9yODs=.201f77bd-b055-4c15-9375-4338633dbc51@github.com> On Thu, 18 May 2023 16:58:50 GMT, Kevin Driver wrote: >> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 290: >> >>> 288: shc.peerSupportedAuthorities = spec.getAuthorities(); >>> 289: } catch (IllegalArgumentException iae) { >>> 290: shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed", iae); >> >> In the context, it may be easier to catch the idea if the message is about the authorities, and easier to update getAuthorities() implementation, for example X500Principal is not used any longer, if needed in the future. >> >> - "X500Principal could not be parsed" >> + "Peer authorities could not be parsed" > > I'm inclined to keep the current version. It seems more specific in guiding the caller to the fix needed. However, I understand your point. > > @seanjmullan comments? I tend to agree with Xuelei in that we should try to use terms as specified in the TLS RFCs in error messages as that will give a user a better indication of where the issue is. I would even be a bit more specific and suggest: "The distinguished names of the peer's certificate authorities could not be parsed" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198073492 From kdriver at openjdk.org Thu May 18 17:49:07 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 17:49:07 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: all review comments applied ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/e33a9b0b..335fb052 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=11-12 Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From mullan at openjdk.org Thu May 18 17:57:55 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 17:57:55 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 17:49:07 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > all review comments applied Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1433176661 From xuelei at openjdk.org Thu May 18 18:05:52 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 18:05:52 GMT Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM In-Reply-To: <55PJuNTFQVH_K3zqyzRFWCpu2L6T6BKERX0lV91_HdA=.729132f2-7533-4a3c-9965-5698f05e8991@github.com> References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> <55PJuNTFQVH_K3zqyzRFWCpu2L6T6BKERX0lV91_HdA=.729132f2-7533-4a3c-9965-5698f05e8991@github.com> Message-ID: On Thu, 18 May 2023 16:55:05 GMT, Daniel Jeli?ski wrote: > the QUIC specification permits dropping duplicate packets only after fully decrypting them. May I have a reference, for example the section number, of the specification? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553425386 From xuelei at openjdk.org Thu May 18 18:09:56 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 18:09:56 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 17:49:07 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > all review comments applied Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1433195956 From djelinski at openjdk.org Thu May 18 18:19:52 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 18 May 2023 18:19:52 GMT Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> Message-ID: On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh wrote: > This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE. For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior. > > - Issue: https://bugs.openjdk.org/browse/JDK-8305091 > - CSR: https://bugs.openjdk.org/browse/JDK-8305822 Here you go: https://www.rfc-editor.org/rfc/rfc9000.html#name-packet-numbers > A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same packet number space. Duplicate suppression MUST happen after removing packet protection for the reasons described in [Section 9.5](https://www.rfc-editor.org/rfc/rfc9001#section-9.5) of [[QUIC-TLS](https://www.rfc-editor.org/rfc/rfc9000.html#QUIC-TLS)]. https://www.rfc-editor.org/rfc/rfc9001#section-9.5 > If the recipient of a packet discards packets with duplicate packet numbers without attempting to remove packet protection, they could reveal through timing side channels that the packet number matches a received packet. For authentication to be free from side channels, the entire process of header protection removal, packet number recovery, and packet protection removal MUST be applied together without timing and other side channels. Additionally check out the header protection section https://www.rfc-editor.org/rfc/rfc9001#name-chacha20-based-header-prote: header_protection(hp_key, sample): counter = sample[0..3] nonce = sample[4..15] mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0}) `sample` is taken from AES-encrypted data, so basically random; there's a (minimal) chance that the sample will be the same between unrelated packets, and a 100% chance that duplicate packets will have the same sample. Without this PR, header protection fails on duplicate samples. With this PR `ChaCha20` is usable (in decrypt mode, but both modes produce identical output) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553440682 From xuelei at openjdk.org Thu May 18 18:32:51 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 18:32:51 GMT Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM In-Reply-To: References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> Message-ID: On Thu, 18 May 2023 18:16:49 GMT, Daniel Jeli?ski wrote: > Here you go: @djelinski Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553459091 From rriggs at openjdk.org Thu May 18 18:36:55 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 May 2023 18:36:55 GMT Subject: RFR: 8308016: Use snippets in java.io package [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 20:51:29 GMT, Brian Burkhalter wrote: >> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - 8308016: Reinstate @snippet for RandomAccessFile::readLong > - 8308016: Reduce linking in File::toPath snippet > - 8308016: Fix link in snippet of File::toPath > - 8308016: Address reviewer comments since previous commit > - 8308016: Remove ellipses ("...") from snippets > - 8308016: Use snippets in java.io package src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 284: > 282: * array such that: > 283: * {@snippet lang=java : > 284: * c == (char)(((hibyte & 0xff) << 8) | (b & 0xff)) I'd skip the extra indentation for just the single line example. src/java.base/share/classes/java/io/CharArrayWriter.java line 189: > 187: * > 188: * {@snippet lang=java : > 189: * out.write(csq.subSequence(start, end).toString()) a trailing ";' would be useful for copy/paste; butr that's not the existing style. Your call. src/java.base/share/classes/java/io/Console.java line 125: > 123: * Scanner sc = new Scanner(con.reader()); > 124: * code: // @replace substring="code:" replacement="..." > 125: * } 4 space indentation would be enough. src/java.base/share/classes/java/io/RandomAccessFile.java line 762: > 760: * then the result is: > 761: * {@snippet lang=java : > 762: * (byte)(b) 4 space indent is sufficient in this file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198146819 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198147802 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198151689 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198160636 From duke at openjdk.org Thu May 18 19:11:32 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 18 May 2023 19:11:32 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v17] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Removed dead code, accepted code style suggestions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/9801b158..8f14964c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=15-16 Stats: 26 lines in 1 file changed: 0 ins; 3 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From duke at openjdk.org Thu May 18 19:11:36 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 18 May 2023 19:11:36 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v16] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 16:18:02 GMT, Andrey Turbanov wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> More input checks. > > src/java.base/share/classes/sun/security/provider/HSS.java line 410: > >> 408: final int sigLmType; >> 409: final int sigOtsType; >> 410: final private byte[] qArr; > > let's remove `private` to be consistent with other fields > Suggestion: > > final byte[] qArr; I wanted to express that the array should be immutable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198201763 From bpb at openjdk.org Thu May 18 19:14:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 May 2023 19:14:02 GMT Subject: RFR: 8308016: Use snippets in java.io package [v8] In-Reply-To: References: Message-ID: > Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Address reviewer comments since previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13957/files - new: https://git.openjdk.org/jdk/pull/13957/files/d0dce640..b6abb2e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=06-07 Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957 PR: https://git.openjdk.org/jdk/pull/13957 From bpb at openjdk.org Thu May 18 19:14:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 May 2023 19:14:06 GMT Subject: RFR: 8308016: Use snippets in java.io package [v7] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 18:23:53 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge >> - 8308016: Reinstate @snippet for RandomAccessFile::readLong >> - 8308016: Reduce linking in File::toPath snippet >> - 8308016: Fix link in snippet of File::toPath >> - 8308016: Address reviewer comments since previous commit >> - 8308016: Remove ellipses ("...") from snippets >> - 8308016: Use snippets in java.io package > > src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 284: > >> 282: * array such that: >> 283: * {@snippet lang=java : >> 284: * c == (char)(((hibyte & 0xff) << 8) | (b & 0xff)) > > I'd skip the extra indentation for just the single line example. So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e. > src/java.base/share/classes/java/io/CharArrayWriter.java line 189: > >> 187: * >> 188: * {@snippet lang=java : >> 189: * out.write(csq.subSequence(start, end).toString()) > > a trailing ";' would be useful for copy/paste; butr that's not the existing style. Your call. These statements in general do not have a trailing `;`; left unchanged. > src/java.base/share/classes/java/io/Console.java line 125: > >> 123: * Scanner sc = new Scanner(con.reader()); >> 124: * code: // @replace substring="code:" replacement="..." >> 125: * } > > 4 space indentation would be enough. So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e. > src/java.base/share/classes/java/io/RandomAccessFile.java line 762: > >> 760: * then the result is: >> 761: * {@snippet lang=java : >> 762: * (byte)(b) > > 4 space indent is sufficient in this file So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203067 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203673 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198204033 PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203822 From mbalao at openjdk.org Thu May 18 19:30:57 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 18 May 2023 19:30:57 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v2] In-Reply-To: <9-eGBQs-MoQ0PUC2i1M5dCkr2KdmftuVd3qrpuyaMzs=.18aea3e5-38b0-4c2c-9303-a2c9adfc3e57@github.com> References: <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com> <9-eGBQs-MoQ0PUC2i1M5dCkr2KdmftuVd3qrpuyaMzs=.18aea3e5-38b0-4c2c-9303-a2c9adfc3e57@github.com> Message-ID: On Tue, 16 May 2023 23:42:08 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/java.base/share/classes/sun/security/util/PBEUtil.java line 62: > >> 60: * IvParameterSpec). >> 61: */ >> 62: public final static class PBES2Params { > > nit; static final? Good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198223925 From mbalao at openjdk.org Thu May 18 19:48:04 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 18 May 2023 19:48:04 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Wed, 17 May 2023 18:44:08 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Rebase fix after JDK-8306033. Replace called functions with their new names. >> - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao >> - 8301553: Support Password-Based Cryptography in SunPKCS11 >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 115: > >> 113: try { >> 114: derivedKey = PKCS12PBECipherCore.derive( >> 115: keySpec.getPassword(), keySpec.getSalt(), > > Comparing to the original impl, this new call of keySpec.getPassword() produces extra copy of password which needs to be cleared as well. Good. We have some doubts about the effectiveness of this but we will clear them anyways. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198237296 From mbalao at openjdk.org Thu May 18 20:10:10 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 18 May 2023 20:10:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Wed, 17 May 2023 18:45:06 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Rebase fix after JDK-8306033. Replace called functions with their new names. >> - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao >> - 8301553: Support Password-Based Cryptography in SunPKCS11 >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 121: > >> 119: keySpec.clearPassword(); >> 120: } >> 121: SecretKey cipherKey = new SecretKeySpec(derivedKey, "HmacSHA1"); > > Can clear out the "derivedKey" bytes if no longer needed. Good > src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 165: > >> 163: byte[] derivedKey = s.getEncoded(); >> 164: s.clearPassword(); >> 165: SecretKeySpec cipherKey = new SecretKeySpec(derivedKey, cipherAlgo); > > Clear out the "derivedKey" bytes if no longer needed. Good > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 345: > >> 343: throw new InvalidKeyException("Encoded format must be RAW"); >> 344: } >> 345: byte[] encoded = key.getEncoded(); > > Would be nice to clear out "encoded" bytes afterwards. Good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198250758 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198254721 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198256947 From mbalao at openjdk.org Thu May 18 20:16:01 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 18 May 2023 20:16:01 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com> On Wed, 17 May 2023 18:57:41 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Rebase fix after JDK-8306033. Replace called functions with their new names. >> - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao >> - 8301553: Support Password-Based Cryptography in SunPKCS11 >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 362: > >> 360: session = token.getObjSession(); >> 361: CK_MECHANISM ckMech; >> 362: char[] password = keySpec.getPassword(); > > Should clear out "password" afterwards. Good > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 391: > >> 389: } >> 390: >> 391: char[] encPassword; > > Same, clear out "encPassword" afterwards. Good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198258848 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198260824 From mbalao at openjdk.org Thu May 18 20:30:58 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 18 May 2023 20:30:58 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Wed, 17 May 2023 19:00:47 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Rebase fix after JDK-8306033. Replace called functions with their new names. >> - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao >> - 8301553: Support Password-Based Cryptography in SunPKCS11 >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 444: > >> 442: int keyLength = 0; >> 443: if ("RAW".equalsIgnoreCase(pbeKey.getFormat())) { >> 444: byte[] encoded = pbeKey.getEncoded(); > > Should clear out "encoded" afterwards. Good > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 450: > >> 448: } >> 449: int ic = pbeKey.getIterationCount(); >> 450: char[] pwd = pbeKey.getPassword(); > > Should clear out "pwd" afterwards. Good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198271443 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198273022 From mullan at openjdk.org Thu May 18 21:22:51 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 May 2023 21:22:51 GMT Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end [v2] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 14:48:58 GMT, Weijun Wang wrote: >> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > add reasons Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13958#pullrequestreview-1433473416 From weijun at openjdk.org Thu May 18 21:27:02 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 May 2023 21:27:02 GMT Subject: Integrated: 8308010: X509Key and PKCS8Key allows garbage bytes at the end In-Reply-To: References: Message-ID: On Fri, 12 May 2023 16:23:53 GMT, Weijun Wang wrote: > When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end. This pull request has now been integrated. Changeset: 148df533 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/148df533af618a959ca2f3601d9ab897c3515d77 Stats: 86 lines in 3 files changed: 60 ins; 13 del; 13 mod 8308010: X509Key and PKCS8Key allows garbage bytes at the end Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/13958 From wetmore at openjdk.org Thu May 18 21:56:54 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 18 May 2023 21:56:54 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 17:49:07 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > all review comments applied src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 385: > 383: X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager(); > 384: String clientAlias = null; > 385: Many of these lines are > 80 chars, which makes side-by-side challenging. Please keep line changes to a max of 80 chars. Didn't check the other file, but think I saw similar things there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198340417 From kdriver at openjdk.org Thu May 18 22:05:57 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 22:05:57 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 21:52:37 GMT, Bradford Wetmore wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> all review comments applied > > src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 385: > >> 383: X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager(); >> 384: String clientAlias = null; >> 385: > > Many of these lines are > 80 chars, which makes side-by-side challenging. Please keep line changes to a max of 80 chars. > > Didn't check the other file, but think I saw similar things there. This might be something on your end @bradfordwetmore. I opened this in my IDE and went to the end of the line... It was right under the "String clientAlias" capital "S". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198346964 From kdriver at openjdk.org Thu May 18 22:05:58 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 22:05:58 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 22:00:35 GMT, Kevin Driver wrote: >> src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 385: >> >>> 383: X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager(); >>> 384: String clientAlias = null; >>> 385: >> >> Many of these lines are > 80 chars, which makes side-by-side challenging. Please keep line changes to a max of 80 chars. >> >> Didn't check the other file, but think I saw similar things there. > > This might be something on your end @bradfordwetmore. I opened this in my IDE and went to the end of the line... It was right under the "String clientAlias" capital "S". image ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198348358 From wetmore at openjdk.org Thu May 18 22:36:00 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 18 May 2023 22:36:00 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 22:02:55 GMT, Kevin Driver wrote: >> This might be something on your end @bradfordwetmore. I opened this in my IDE and went to the end of the line... It was right under the "String clientAlias" capital "S". > > image Slacked with Kevin and pointed out locations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198365130 From kdriver at openjdk.org Thu May 18 23:28:24 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 18 May 2023 23:28:24 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v14] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <1P2PoVtr4zPioOQlOvqA5MRRIbmUFjINHBUdJLGlft8=.36819598-528f-4008-8792-d3477d80a669@github.com> > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: whitespace adjustments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/335fb052..cae5e1bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=12-13 Stats: 21 lines in 2 files changed: 8 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From wetmore at openjdk.org Fri May 19 00:07:55 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 19 May 2023 00:07:55 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v13] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Thu, 18 May 2023 22:33:30 GMT, Bradford Wetmore wrote: >> image > > Slacked with Kevin and pointed out locations. Slacked with Kevin and resolved my concern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198406416 From wetmore at openjdk.org Fri May 19 00:41:58 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 19 May 2023 00:41:58 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v14] In-Reply-To: <1P2PoVtr4zPioOQlOvqA5MRRIbmUFjINHBUdJLGlft8=.36819598-528f-4008-8792-d3477d80a669@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <1P2PoVtr4zPioOQlOvqA5MRRIbmUFjINHBUdJLGlft8=.36819598-528f-4008-8792-d3477d80a669@github.com> Message-ID: On Thu, 18 May 2023 23:28:24 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > whitespace adjustments New code LGTM, minus the one outstanding test issue. Pending that, I can sponsor. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1433626170 From mbalao at openjdk.org Fri May 19 02:22:05 2023 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 19 May 2023 02:22:05 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com> References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com> Message-ID: On Thu, 18 May 2023 20:10:04 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 362: >> >>> 360: session = token.getObjSession(); >>> 361: CK_MECHANISM ckMech; >>> 362: char[] password = keySpec.getPassword(); >> >> Should clear out "password" afterwards. > > Good I've just noticed that in this case in particular we can clean it up here but we need to save a copy in P11PBEKey because if the key has to be transferred to a different P11 token, we need to re-derive from the password, salt and iteration count. This case would happen for example if you have a P11 key from one token and you want to use it in a P11 service from a different token. Code is in P11SecretKeyFactory::convertKey. For safety, I'll clone the password in the P11PBEKey constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198481207 From vlivanov at openjdk.org Fri May 19 04:10:00 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 May 2023 04:10:00 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Fri, 12 May 2023 21:09:01 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Address PR review 5: refactor on rematerialization & add tests. Very nice, Cesar. I like how the code shapes now. I verified that the new test cases do trigger SR+NSR scenario. How do you test that deoptimization works as expected? Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections ("pc-bytecode offsets" and "scopes") in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code. FTR `_skip_rematerialization` flag is unused now. Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`. Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1553966589 From jpai at openjdk.org Fri May 19 05:18:50 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 May 2023 05:18:50 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke wrote: >> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, >> >> I didn't add any new tests but ran tier 1-3 with no issues > > Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java > > Co-authored-by: Daniel Jelinski > - removed StreamTokenizer changes, will make seperate ticket for those These changes look fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1433788568 From shade at openjdk.org Fri May 19 06:57:10 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 May 2023 06:57:10 GMT Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev wrote: >> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. >> >> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely. >> >> Example original profile is in the bug. >> >> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns. >> >> On new benchmark: >> >> >> Benchmark Mode Cnt Score Error Units >> >> ## Mac M1 >> >> # Before >> AESReinit.test avgt 15 873,842 ? 6,911 ns/op >> >> # After >> AESReinit.test avgt 15 347,632 ? 8,764 ns/op ; <--- 2.5x faster >> >> ## Xeon, c6.8xlarge >> >> # Before >> AESReinit.test avgt 15 1524.307 ? 24.231 ns/op >> >> # After >> AESReinit.test avgt 15 554.727 ? 12.876 ns/op ; <--- 2.75x faster >> >> ## Graviton, m6g.4xlarge >> >> # Before >> AESReinit.test avgt 15 1913.492 ? 23.489 ns/op >> >> # After >> AESReinit.test avgt 15 639.701 ? 5.033 ns/op ; <--- 2.99x faster >> >> >> Additional testing: >> - [x] Benchmarks >> - [x] macos-aarch64-server-release, `jdk_security` >> - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - Micro-optimizations > - Handle Kd > - Handle Ke Rechecked `jdk_security`, passes. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1554093536 From shade at openjdk.org Fri May 19 06:57:12 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 May 2023 06:57:12 GMT Subject: Integrated: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey In-Reply-To: References: Message-ID: On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev wrote: > One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. > > Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely. > > Example original profile is in the bug. > > There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns. > > On new benchmark: > > > Benchmark Mode Cnt Score Error Units > > ## Mac M1 > > # Before > AESReinit.test avgt 15 873,842 ? 6,911 ns/op > > # After > AESReinit.test avgt 15 347,632 ? 8,764 ns/op ; <--- 2.5x faster > > ## Xeon, c6.8xlarge > > # Before > AESReinit.test avgt 15 1524.307 ? 24.231 ns/op > > # After > AESReinit.test avgt 15 554.727 ? 12.876 ns/op ; <--- 2.75x faster > > ## Graviton, m6g.4xlarge > > # Before > AESReinit.test avgt 15 1913.492 ? 23.489 ns/op > > # After > AESReinit.test avgt 15 639.701 ? 5.033 ns/op ; <--- 2.99x faster > > > Additional testing: > - [x] Benchmarks > - [x] macos-aarch64-server-release, `jdk_security` > - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3` This pull request has now been integrated. Changeset: 67657610 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/6765761075361459f764f4f17a52ac6ecbe67f4e Stats: 133 lines in 2 files changed: 78 ins; 38 del; 17 mod 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/13996 From djelinski at openjdk.org Fri May 19 07:33:52 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 19 May 2023 07:33:52 GMT Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match resuming session [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686? >> >> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. >> >> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. >> >> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key. The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue. >> >> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted. >> >> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review comment - use SSLContextTemplate for SSLContext creation in test The changes look fine to me. On a side note, TLS 1.3 spec permits resuming sessions with a different server_name: https://www.rfc-editor.org/rfc/rfc8446.html#page-57 ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13669#pullrequestreview-1433925085 From clanger at openjdk.org Fri May 19 09:15:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 19 May 2023 09:15:49 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v3] In-Reply-To: <2dBwm9ZtkuIaWeJdSnE-_rZdaGxLowoeuT77pdXrM_U=.10eefa2c-be1c-4b78-878a-e9bd73d7ca5c@github.com> References: <2dBwm9ZtkuIaWeJdSnE-_rZdaGxLowoeuT77pdXrM_U=.10eefa2c-be1c-4b78-878a-e9bd73d7ca5c@github.com> Message-ID: <32RNMEoT0Ay7zwaTkvXnVUtAeGN5shOJ4jt9BwzLKzk=.15b1f857-0ab7-4007-8d82-127be21ddf54@github.com> On Thu, 18 May 2023 00:00:58 GMT, Weijun Wang wrote: > Before your new change, such a certificate is not trusted, because `SecTrustSettingsCopyTrustSettings` returns `errSecItemNotFound` so `jm_createTrustedCertEntry` is not called at all. > > I am not sure if such a certificate is meant to be always trusted. Note that you can create such an entry with only `security add-certificates` but not `security add-trusted-cert`. macOS allows anyone to run the first command but prompts you for an administrator password when running the second. The name of the second command also implies that it's the only way to assign trust to a certificate, IMHO. Hm, after thinking about this again and also comparing with behavior of curl, I think you're right. A self-signed certificate should only be trusted if it has a trust entry (e.g. added by `security add-trusted-cert`). Somehow I was under the impression that self-signed certificates should be trusted when they exist. But after reading comments etc. again I'm not sure why I thought so at all. ? Will update the PR... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1554278565 From michaelm at openjdk.org Fri May 19 11:26:52 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 19 May 2023 11:26:52 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke wrote: >> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, >> >> I didn't add any new tests but ran tier 1-3 with no issues > > Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java > > Co-authored-by: Daniel Jelinski > - removed StreamTokenizer changes, will make seperate ticket for those Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale. Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1554431858 From michaelm at openjdk.org Fri May 19 11:45:50 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 19 May 2023 11:45:50 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke wrote: >> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, >> >> I didn't add any new tests but ran tier 1-3 with no issues > > Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java > > Co-authored-by: Daniel Jelinski > - removed StreamTokenizer changes, will make seperate ticket for those Marked as reviewed by michaelm (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1434277855 From clanger at openjdk.org Fri May 19 12:02:27 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 19 May 2023 12:02:27 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v4] In-Reply-To: References: Message-ID: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. 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 five additional commits since the last revision: - Do not trust self signed certificates without trust settings - Merge branch 'master' into JDK-8303465 - Check return code of SecTrustSettingsCopyTrustSettings and address review comments - Add some more initializations to avoid crashes - JDK-8303465 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13945/files - new: https://git.openjdk.org/jdk/pull/13945/files/b14e5f2c..890e12bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=02-03 Stats: 19714 lines in 628 files changed: 12808 ins; 2901 del; 4005 mod Patch: https://git.openjdk.org/jdk/pull/13945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945 PR: https://git.openjdk.org/jdk/pull/13945 From clanger at openjdk.org Fri May 19 12:17:01 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 19 May 2023 12:17:01 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v5] In-Reply-To: References: Message-ID: > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Remove further unnecessary changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13945/files - new: https://git.openjdk.org/jdk/pull/13945/files/890e12bf..8085b901 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=03-04 Stats: 18 lines in 1 file changed: 1 ins; 9 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945 PR: https://git.openjdk.org/jdk/pull/13945 From clanger at openjdk.org Fri May 19 12:19:56 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 19 May 2023 12:19:56 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: References: Message-ID: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> > With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. > > The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. > > This change does the following: > 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. > 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. > 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. > 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. > 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. > > I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Remove another obsolete comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13945/files - new: https://git.openjdk.org/jdk/pull/13945/files/8085b901..023c9a76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945 PR: https://git.openjdk.org/jdk/pull/13945 From mdonovan at openjdk.org Fri May 19 12:24:05 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 19 May 2023 12:24:05 GMT Subject: RFR: 8301381: Verify DTLS 1.0 cannot be negotiated Message-ID: This PR implements a test to verify that a DTLS server running "out of the box" (i.e., DTLSv1.0 disabled in java.security) will not handshake with a client requesting DTLSv1.0. The test also implements the opposite: a client won't handshake with a server that uses DTLSv1.0. ------------- Commit messages: - 8301381: Verify DTLS 1.0 cannot be negotiated Changes: https://git.openjdk.org/jdk/pull/14059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301381 Stats: 320 lines in 1 file changed: 320 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14059/head:pull/14059 PR: https://git.openjdk.org/jdk/pull/14059 From xuelei at openjdk.org Fri May 19 14:26:51 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 19 May 2023 14:26:51 GMT Subject: RFR: 8301381: Verify DTLS 1.0 cannot be negotiated In-Reply-To: References: Message-ID: On Fri, 19 May 2023 12:03:54 GMT, Matthew Donovan wrote: > This PR implements a test to verify that a DTLS server running "out of the box" (i.e., DTLSv1.0 disabled in java.security) will not handshake with a client requesting DTLSv1.0. The test also implements the opposite: a client won't handshake with a server that uses DTLSv1.0. Marked as reviewed by xuelei (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14059#pullrequestreview-1434532784 From mpowers at openjdk.org Fri May 19 16:59:58 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 19 May 2023 16:59:58 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8307794 Mark Powers has updated the pull request incrementally with four additional commits since the last revision: - Ferenc: comments 2 and 4 - oops - Sean's comments - added @run ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13940/files - new: https://git.openjdk.org/jdk/pull/13940/files/23349514..7598bc74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=00-01 Stats: 5043 lines in 3 files changed: 1202 ins; 1948 del; 1893 mod Patch: https://git.openjdk.org/jdk/pull/13940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940 PR: https://git.openjdk.org/jdk/pull/13940 From mullan at openjdk.org Fri May 19 17:29:50 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 19 May 2023 17:29:50 GMT Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v10] In-Reply-To: References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: On Thu, 18 May 2023 15:15:30 GMT, Weijun Wang wrote: >> Update XML Security for Java to 3.0.2. Some change to tests: >> >> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". >> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > test modifies policy should run in othervm mode > > only in patch2: > unchanged: Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13840#pullrequestreview-1434822801 From kdriver at openjdk.org Fri May 19 17:49:07 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 19 May 2023 17:49:07 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v15] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com> > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: - fix bug id in test header - reworked example into a jtreg test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/cae5e1bc..d4ffde32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=13-14 Stats: 204 lines in 1 file changed: 204 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From weijun at openjdk.org Fri May 19 17:50:05 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 May 2023 17:50:05 GMT Subject: Integrated: 8305972: Update XML Security for Java to 3.0.2 In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com> Message-ID: <7r1MCM8GgB2uQHqIgpONSfAIrM7AFIxzfuNC9lvwGwI=.175a34ba-2855-41ad-849b-ce3d5b2cae28@github.com> On Fri, 5 May 2023 17:57:34 GMT, Weijun Wang wrote: > Update XML Security for Java to 3.0.2. Some change to tests: > > 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported". > 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead. This pull request has now been integrated. Changeset: f0aebc81 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/f0aebc8141de5a50c88658a40caa01967a9afc53 Stats: 1175 lines in 38 files changed: 922 ins; 142 del; 111 mod 8305972: Update XML Security for Java to 3.0.2 Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/13840 From kdriver at openjdk.org Fri May 19 19:38:09 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 19 May 2023 19:38:09 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v16] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: removing block that isn't reached ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/d4ffde32..40a35bc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=14-15 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From mullan at openjdk.org Fri May 19 19:41:11 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 19 May 2023 19:41:11 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v16] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 19 May 2023 19:38:09 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > removing block that isn't reached test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 28: > 26: * @bug 8164879 > 27: * @library /test/lib > 28: * @summary test for proper exception handling Suggest adding more details here, ex: "Check that an improperly encoded CA distinguished name causes a handshake failure" test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 45: > 43: > 44: > 45: public class Test8294985 { I would avoid putting the bug number in the test name and use something more descriptive, like InvalidEncodedCaName. test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 64: > 62: + "/../../../../javax/net/ssl/etc/keystore"; > 63: > 64: private static byte[] payload = Base64.getDecoder().decode( Can you add a comment as to what is in this payload? test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 91: > 89: } > 90: > 91: System.out.println("payload len:" + payload.length); Is this println necessary? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199282222 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199283420 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199283669 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199284615 From kdriver at openjdk.org Fri May 19 19:53:03 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 19 May 2023 19:53:03 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v17] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: rename class and remove bug id from test header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/40a35bc1..8b672b0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=15-16 Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From jnimeh at openjdk.org Fri May 19 20:05:07 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 19 May 2023 20:05:07 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v3] In-Reply-To: References: Message-ID: <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com> > This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. > > This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). > > JBS: https://bugs.openjdk.org/browse/JDK-8179502 > CSR: https://bugs.openjdk.org/browse/JDK-8300722 Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Add OCSP readtimeout property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13762/files - new: https://git.openjdk.org/jdk/pull/13762/files/3c524e17..81c7cb35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=01-02 Stats: 26 lines in 2 files changed: 14 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762 PR: https://git.openjdk.org/jdk/pull/13762 From jnimeh at openjdk.org Fri May 19 20:05:09 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 19 May 2023 20:05:09 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 15:56:02 GMT, Jamil Nimeh wrote: >> Yes, I noticed that too. I wasn't sure if we needed to make a change there. I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of. All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values. So in practice much of the time they are all 2x. >> >> It's easy enough I think to make a separate property for `com.sun.security.ocsp.readtimeout` and then the existing `.timeout` property would be for connect timeouts (keeping in line with the other props). I don't think it will introduce significant risk but I will highlight that in the CSR. > >> I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`. > > I will look into this. I've added the OCSP readtimeout property, seems to be working well. As discussed offline we'll hold off on the LDAP changes for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1199323604 From mullan at openjdk.org Fri May 19 20:15:53 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 19 May 2023 20:15:53 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 16:59:58 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8307794 > > Mark Powers has updated the pull request incrementally with four additional commits since the last revision: > > - Ferenc: comments 2 and 4 > - oops > - Sean's comments > - added @run test/jdk/sun/security/provider/lms/TestLMS.java line 30: > 28: * @summary tests for HSS/LMS provider > 29: * @modules java.base/sun.security.util > 30: * @run testng/othervm TestLMS Why is the test run with `testng`, can this just be `main/othervm`? test/jdk/sun/security/tools/jarsigner/VerifyHSSLMSSignedJar.java line 29: > 27: * @summary verify JAR files signed with HSS/LMS > 28: * @library /test/lib > 29: * @run testng/othervm VerifyHSSLMSSignedJar I don't see anything that is using testng in this test, can we just run as `main/othervm`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199329785 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199322468 From wetmore at openjdk.org Fri May 19 20:26:59 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 19 May 2023 20:26:59 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v15] In-Reply-To: <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com> Message-ID: On Fri, 19 May 2023 17:49:07 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: > > - fix bug id in test header > - reworked example into a jtreg test Mostly nits here. Take or leave... ------------- PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1435046400 From weijun at openjdk.org Fri May 19 20:31:49 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 May 2023 20:31:49 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com> On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list. >> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose. >> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove another obsolete comment Since you removed the key usage checks, can you update the PR description please? src/java.base/macosx/classes/apple/security/KeychainStore.java line 808: > 806: // Check whether a certificate with same alias already exists and is the same > 807: // If yes, we can return here - the existing entry must have the same > 808: // properties and trust settings This is always true, right? I'm not sure how this could happen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1555202314 PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1199343595 From weijun at openjdk.org Fri May 19 20:54:57 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 May 2023 20:54:57 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 20:08:08 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with four additional commits since the last revision: >> >> - Ferenc: comments 2 and 4 >> - oops >> - Sean's comments >> - added @run > > test/jdk/sun/security/provider/lms/TestLMS.java line 30: > >> 28: * @summary tests for HSS/LMS provider >> 29: * @modules java.base/sun.security.util >> 30: * @run testng/othervm TestLMS > > Why is the test run with `testng`, can this just be `main/othervm`? I think there is even no need to use `othervm`. I see no system property modification or mutable static fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199390793 From mpowers at openjdk.org Fri May 19 21:29:53 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 19 May 2023 21:29:53 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 19:58:10 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with four additional commits since the last revision: >> >> - Ferenc: comments 2 and 4 >> - oops >> - Sean's comments >> - added @run > > test/jdk/sun/security/tools/jarsigner/VerifyHSSLMSSignedJar.java line 29: > >> 27: * @summary verify JAR files signed with HSS/LMS >> 28: * @library /test/lib >> 29: * @run testng/othervm VerifyHSSLMSSignedJar > > I don't see anything that is using testng in this test, can we just run as `main/othervm`? You are right. Changed to `@run main VerifyHSSLMSSignedJar`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199416397 From mpowers at openjdk.org Fri May 19 21:29:49 2023 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 19 May 2023 21:29:49 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 20:51:31 GMT, Weijun Wang wrote: >> test/jdk/sun/security/provider/lms/TestLMS.java line 30: >> >>> 28: * @summary tests for HSS/LMS provider >>> 29: * @modules java.base/sun.security.util >>> 30: * @run testng/othervm TestLMS >> >> Why is the test run with `testng`, can this just be `main/othervm`? > > I think there is even no need to use `othervm`. I see no system property modification or mutable static fields. You are right. Changed to `@run main TestLMS`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199416586 From mbalao at openjdk.org Sat May 20 01:01:12 2023 From: mbalao at openjdk.org (Martin Balao) Date: Sat, 20 May 2023 01:01:12 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Thu, 18 May 2023 20:07:37 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 345: >> >>> 343: throw new InvalidKeyException("Encoded format must be RAW"); >>> 344: } >>> 345: byte[] encoded = key.getEncoded(); >> >> Would be nice to clear out "encoded" bytes afterwards. > > Good We discussed this change with @franferrax and have some concerns. The method Key::getEncoded does not document that a copy will be returned, and this would change the current behavior and affect non-PBE cases. In practical terms, it would mean that a key directly or indirectly converted to a P11Key would be destroyed if it does not return a clone in its getEncoded method. We suggest to make the caller responsible and keep the existing behavior. I.e.: if we call with a SecretKeySpec ?whose ::getEncoded returns a clone?, the caller will need to (optionally) clear the key. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1199513839 From mbalao at openjdk.org Sat May 20 01:10:06 2023 From: mbalao at openjdk.org (Martin Balao) Date: Sat, 20 May 2023 01:10:06 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com> Message-ID: <5vT8f4dDuNC0CGA8LxQLdu1xQfdV0wql-fUdDVSDHzk=.c6e09e8f-a0d2-4177-926f-7a79312b2819@github.com> On Fri, 19 May 2023 02:19:00 GMT, Martin Balao wrote: >> Good > > I've just noticed that in this case in particular we can clean it up here but we need to save a copy in P11PBEKey because if the key has to be transferred to a different P11 token, we need to re-derive from the password, salt and iteration count. This case would happen for example if you have a P11 key from one token and you want to use it in a P11 service from a different token. Code is in P11SecretKeyFactory::convertKey. For safety, I'll clone the password in the P11PBEKey constructor. Update: we finally decided to do what I described in my previous comment but in those PBE MAC and Cipher cases in which we know that the key was derived for the same token than the service AND the key cannot be accessed from outside ?in other words, there are strong guarantees that the key won't need to be derived again?, we will clear the password. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1199514984 From mbalao at openjdk.org Sat May 20 01:25:29 2023 From: mbalao at openjdk.org (Martin Balao) Date: Sat, 20 May 2023 01:25:29 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v4] In-Reply-To: References: Message-ID: > We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. > > In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): > > * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ... Martin Balao has updated the pull request incrementally with one additional commit since the last revision: 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #2) Co-authored-by: Francisco Ferrari Co-authored-by: Martin Balao ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12396/files - new: https://git.openjdk.org/jdk/pull/12396/files/cd48dc20..41b14723 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=02-03 Stats: 253 lines in 13 files changed: 145 ins; 53 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/12396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396 PR: https://git.openjdk.org/jdk/pull/12396 From mbalao at openjdk.org Sat May 20 01:25:29 2023 From: mbalao at openjdk.org (Martin Balao) Date: Sat, 20 May 2023 01:25:29 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Wed, 17 May 2023 19:08:26 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Rebase fix after JDK-8306033. Replace called functions with their new names. >> - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao >> - 8301553: Support Password-Based Cryptography in SunPKCS11 >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 562: > >> 560: } else if (algorithm.equalsIgnoreCase("DES")) { >> 561: if (keySpec instanceof DESKeySpec desKeySpec) { >> 562: byte[] keyBytes = desKeySpec.getKey(); > > Would be nice to clear out "keyBytes" afterwards. Same goes for the other "keyBytes" in the same method. Good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1199516764 From mbalao at openjdk.org Sat May 20 01:25:29 2023 From: mbalao at openjdk.org (Martin Balao) Date: Sat, 20 May 2023 01:25:29 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Wed, 17 May 2023 03:11:54 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Rebase fix after JDK-8306033. Replace called functions with their new names. > - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao > - 8301553: Support Password-Based Cryptography in SunPKCS11 > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel. We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument. No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1555410153 From ascarpino at openjdk.org Sat May 20 02:13:11 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Sat, 20 May 2023 02:13:11 GMT Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> Message-ID: On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh wrote: > This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE. For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior. > > - Issue: https://bugs.openjdk.org/browse/JDK-8305091 > - CSR: https://bugs.openjdk.org/browse/JDK-8305822 Marked as reviewed by ascarpino (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13428#pullrequestreview-1435312854 From clanger at openjdk.org Sun May 21 21:32:59 2023 From: clanger at openjdk.org (Christoph Langer) Date: Sun, 21 May 2023 21:32:59 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com> Message-ID: On Fri, 19 May 2023 20:28:42 GMT, Weijun Wang wrote: > Since you removed the key usage checks, can you update the PR description please? Done. > src/java.base/macosx/classes/apple/security/KeychainStore.java line 808: > >> 806: // Check whether a certificate with same alias already exists and is the same >> 807: // If yes, we can return here - the existing entry must have the same >> 808: // properties and trust settings > > This is always true, right? I'm not sure how this could happen. This handles the case, when a certificate is in both, the login (user) and system keychain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1556296651 PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1199830388 From duke at openjdk.org Mon May 22 10:22:56 2023 From: duke at openjdk.org (Darragh Clarke) Date: Mon, 22 May 2023 10:22:56 GMT Subject: RFR: 7065228: To interpret case-insensitive string locale independently [v2] In-Reply-To: References: Message-ID: <_gCEzkKMiIQiTGFQMSmpM0E4xnXPig7RaUPT3tbZNts=.e904c7f1-cf98-4987-ad0f-861689b83078@github.com> On Fri, 19 May 2023 11:24:30 GMT, Michael McMahon wrote: > Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale. > > Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see. Yes ------------- PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1556955595 From duke at openjdk.org Mon May 22 10:57:02 2023 From: duke at openjdk.org (Darragh Clarke) Date: Mon, 22 May 2023 10:57:02 GMT Subject: Integrated: 7065228: To interpret case-insensitive string locale independently In-Reply-To: References: Message-ID: On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke wrote: > Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur, > > I didn't add any new tests but ran tier 1-3 with no issues This pull request has now been integrated. Changeset: 05e99db4 Author: Darragh Clarke Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/05e99db466e7ef5c26f089db772a21cb2ca62e93 Stats: 74 lines in 20 files changed: 14 ins; 0 del; 60 mod 7065228: To interpret case-insensitive string locale independently Reviewed-by: dfuchs, naoto, djelinski, jpai, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/14006 From mdonovan at openjdk.org Mon May 22 12:06:03 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 22 May 2023 12:06:03 GMT Subject: Integrated: 8301381: Verify DTLS 1.0 cannot be negotiated In-Reply-To: References: Message-ID: On Fri, 19 May 2023 12:03:54 GMT, Matthew Donovan wrote: > This PR implements a test to verify that a DTLS server running "out of the box" (i.e., DTLSv1.0 disabled in java.security) will not handshake with a client requesting DTLSv1.0. The test also implements the opposite: a client won't handshake with a server that uses DTLSv1.0. This pull request has now been integrated. Changeset: 18e24464 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/18e2446420d3376acaa2652d70474c2d3a85e2ac Stats: 320 lines in 1 file changed: 320 ins; 0 del; 0 mod 8301381: Verify DTLS 1.0 cannot be negotiated Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/14059 From avu at openjdk.org Mon May 22 14:21:56 2023 From: avu at openjdk.org (Alexey Ushakov) Date: Mon, 22 May 2023 14:21:56 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. I would suggest either disable warnings on per file basis or rewrite problematic code. Disabling warnings per fragment of code makes it less readable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1557306893 From weijun at openjdk.org Mon May 22 15:10:14 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 May 2023 15:10:14 GMT Subject: RFR: 8308540: On Kerberos TGT referral, if krb5.conf is missing realm, bad exception message Message-ID: Add realm name to the exception message, and make it the primary exception (retry exception added suppressed). ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/14086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308540 Stats: 62 lines in 3 files changed: 33 ins; 15 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/14086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14086/head:pull/14086 PR: https://git.openjdk.org/jdk/pull/14086 From mullan at openjdk.org Mon May 22 16:02:54 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 22 May 2023 16:02:54 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v3] In-Reply-To: <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com> References: <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com> Message-ID: On Fri, 19 May 2023 20:05:07 GMT, Jamil Nimeh wrote: >> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. >> >> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). >> >> JBS: https://bugs.openjdk.org/browse/JDK-8179502 >> CSR: https://bugs.openjdk.org/browse/JDK-8300722 > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Add OCSP readtimeout property src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 186: > 184: } > 185: > 186: String propVal = System.getProperty(prop, "").trim(); You should call `privilegedGetProperty` here instead of `System.getProperty` so the call is wrapped in `doPrivileged` when an SM is active. src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 202: > 200: // Next check to make sure the string is built only from digits > 201: if (propVal.matches("^\\d+$")) { > 202: int timeout = Integer.parseInt(propVal); Is this guaranteed never to throw `NumberFormatException`? It might be safer to catch it just in case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200714709 PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200716014 From jnimeh at openjdk.org Mon May 22 16:10:59 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 22 May 2023 16:10:59 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v3] In-Reply-To: References: <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com> Message-ID: On Mon, 22 May 2023 15:58:14 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Add OCSP readtimeout property > > src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 186: > >> 184: } >> 185: >> 186: String propVal = System.getProperty(prop, "").trim(); > > You should call `privilegedGetProperty` here instead of `System.getProperty` so the call is wrapped in `doPrivileged` when an SM is active. Good catch. Will fix. > src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 202: > >> 200: // Next check to make sure the string is built only from digits >> 201: if (propVal.matches("^\\d+$")) { >> 202: int timeout = Integer.parseInt(propVal); > > Is this guaranteed never to throw `NumberFormatException`? It might be safer to catch it just in case. I'll change this to catch NFE, but I'm pretty sure the pattern will only ever return on true if the string is comprised solely of digits from start to end - I could never get a string that would pass when it shouldn't. But point taken, better safe than sorry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200729759 PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200728908 From aph at openjdk.org Mon May 22 16:20:01 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 May 2023 16:20:01 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics Message-ID: This provides a solid speedup of about 3-4x over the Java implementation. I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. Benchmarks: ThunderX (2, I think): Benchmark (dataSize) (provider) Mode Cnt Score Error Units Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s Benchmark (dataSize) (provider) Mode Cnt Score Error Units Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s Apple M1: Benchmark (dataSize) (provider) Mode Cnt Score Error Units Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s Benchmark (dataSize) (provider) Mode Cnt Score Error Units Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s Poly1305DigestBench.updateBytes 256 thrpt 3 3112536.605 ? 14436.410 ops/s Poly1305DigestBench.updateBytes 1024 thrpt 3 777184.018 ? 8774.478 ops/s Poly1305DigestBench.updateBytes 16384 thrpt 3 50224.072 ? 29.004 ops/s Poly1305DigestBench.updateBytes 1048576 thrpt 3 776.229 ? 8.086 ops/s ------------- Commit messages: - Test - Cleanup - Initial commit Changes: https://git.openjdk.org/jdk/pull/14085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296411 Stats: 171 lines in 4 files changed: 170 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085 PR: https://git.openjdk.org/jdk/pull/14085 From jnimeh at openjdk.org Mon May 22 16:59:15 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 22 May 2023 16:59:15 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v4] In-Reply-To: References: Message-ID: > This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. > > This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). > > JBS: https://bugs.openjdk.org/browse/JDK-8179502 > CSR: https://bugs.openjdk.org/browse/JDK-8300722 Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Use privilegedGetProperty, catch NFE following string match ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13762/files - new: https://git.openjdk.org/jdk/pull/13762/files/81c7cb35..e73818ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=02-03 Stats: 20 lines in 3 files changed: 12 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762 PR: https://git.openjdk.org/jdk/pull/13762 From jnimeh at openjdk.org Mon May 22 17:30:50 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 22 May 2023 17:30:50 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 14:59:36 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Add 's' suffix to allowed syntax > > I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`. @seanjmullan if you have a chance would you mind taking a quick look at the release note for this change? (https://bugs.openjdk.org/browse/JDK-8308582) It is pretty close to the CSR solution text, but I tried to trim it down a little. It's still pretty long, but there's a lot to convey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13762#issuecomment-1557618613 From mullan at openjdk.org Mon May 22 17:37:53 2023 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 22 May 2023 17:37:53 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v4] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 16:59:15 GMT, Jamil Nimeh wrote: >> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. >> >> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). >> >> JBS: https://bugs.openjdk.org/browse/JDK-8179502 >> CSR: https://bugs.openjdk.org/browse/JDK-8300722 > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Use privilegedGetProperty, catch NFE following string match src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 211: > 209: " for timeout value " + propVal + > 210: ". Using default value of " + def + " msec."); > 211: } This would also be useful debug for the else case on line 214-216 if the value is not an integer. src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java line 131: > 129: private static final int DEFAULT_CRL_READ_TIMEOUT = 15000; > 130: > 131: // Default connect and read timeouts for CA certificate fetching (15 sec) Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense. I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200805069 PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200812030 From jnimeh at openjdk.org Mon May 22 17:42:54 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 22 May 2023 17:42:54 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v4] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 17:17:26 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Use privilegedGetProperty, catch NFE following string match > > src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 211: > >> 209: " for timeout value " + propVal + >> 210: ". Using default value of " + def + " msec."); >> 211: } > > This would also be useful debug for the else case on line 214-216 if the value is not an integer. Sounds good, I can add that. > src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java line 131: > >> 129: private static final int DEFAULT_CRL_READ_TIMEOUT = 15000; >> 130: >> 131: // Default connect and read timeouts for CA certificate fetching (15 sec) > > Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense. > > I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that? Yes, I can make a follow on for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200831410 PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200832770 From cslucas at openjdk.org Mon May 22 18:00:00 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 22 May 2023 18:00:00 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Fri, 19 May 2023 04:06:47 GMT, Vladimir Ivanov wrote: > I verified that the new test cases do trigger SR+NSR scenario. > > How do you test that deoptimization works as expected? > I have a copy of the tests in AllocationMergesTests.java in a separate file (not included in this PR) and I run the tests with a tool that compares the output of the test with RAM enabled and disabled. So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled. > Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections ("pc-bytecode offsets" and "scopes") in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code. > I'll take care of that. I was testing only with PrintDebugInfo. > FTR `_skip_rematerialization` flag is unused now. > yeah, I forgot to remove that. Thanks. > Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`. > Sounds like a good idea. I'll do that. Thanks. > Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA? I don't think so. This current patch only handle Phis that don't have NULL as input. As part of the reduction process we set at least one of the reducible Phi inputs to NULL. Therefore, subsequent iterations of EA won't reduce the same Phi. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1557655811 From prr at openjdk.org Mon May 22 18:04:51 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 22 May 2023 18:04:51 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. I don't like this approach at all. if github had a "reject" button I'd be pushing it now. updating the makefiles is the normal way to do this but I don't know if we even want that. Until clang is the supported compiler for Linux then I see no reason for this to be in JDK at all. Code changes which make it so there's no warning would be the preferred way but I'd expect that to be tested properly. Also if the warning is spurious - sometimes they are - then that would NOT be appropriate. ------------- Changes requested by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1437172390 From weijun at openjdk.org Mon May 22 18:25:50 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 May 2023 18:25:50 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng wrote: >> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? >> >> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed to use keytool to generate keypairs instead of importing from > data files. test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval/temp.ks line 1: > 1: ????root??c?0??0  is this file useful? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1200876867 From weijun at openjdk.org Mon May 22 19:00:53 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 May 2023 19:00:53 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng wrote: >> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? >> >> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed to use keytool to generate keypairs instead of importing from > data files. Looks fine to me. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1437265848 From ascarpino at openjdk.org Mon May 22 19:30:12 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 22 May 2023 19:30:12 GMT Subject: RFR: 8297878: KEM: Implementation [v18] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 17:07:40 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: > > - Merge branch 'master' into 8297878 > - Merge branch 'master' into 8297878 > - to and length and comments > - deterministic randomness > - Resolve Siba's comment > - providerName > - more @since and about nulls > - Merge branch 'master' into 8297878 > - no more pk/sk, AIOOBE to IOOBE > - small spec change > - ... and 8 more: https://git.openjdk.org/jdk/compare/b1a8e951...7cace182 I'm fine with the changes ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13256#pullrequestreview-1437321126 From rriggs at openjdk.org Mon May 22 19:31:03 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 22 May 2023 19:31:03 GMT Subject: RFR: 8308016: Use snippets in java.io package [v8] In-Reply-To: References: Message-ID: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com> On Thu, 18 May 2023 19:14:02 GMT, Brian Burkhalter wrote: >> Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8308016: Address reviewer comments since previous commit Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13957#pullrequestreview-1437322626 From kdriver at openjdk.org Mon May 22 19:36:16 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Mon, 22 May 2023 19:36:16 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v18] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: additional code review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/8b672b0c..10c18fa1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=16-17 Stats: 12 lines in 1 file changed: 2 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From kdriver at openjdk.org Mon May 22 19:36:16 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Mon, 22 May 2023 19:36:16 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v18] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Fri, 19 May 2023 19:00:39 GMT, Sean Mullan wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> additional code review comments > > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 28: > >> 26: * @bug 8164879 >> 27: * @library /test/lib >> 28: * @summary test for proper exception handling > > Suggest adding more details here, ex: "Check that an improperly encoded CA distinguished name causes a handshake failure" addressed > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 45: > >> 43: >> 44: >> 45: public class Test8294985 { > > I would avoid putting the bug number in the test name and use something more descriptive, like InvalidEncodedCaName. addressed > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 64: > >> 62: + "/../../../../javax/net/ssl/etc/keystore"; >> 63: >> 64: private static byte[] payload = Base64.getDecoder().decode( > > Can you add a comment as to what is in this payload? addressed > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 91: > >> 89: } >> 90: >> 91: System.out.println("payload len:" + payload.length); > > Is this println necessary? addressed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200954942 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955022 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955117 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955187 From kdriver at openjdk.org Mon May 22 19:36:17 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Mon, 22 May 2023 19:36:17 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v15] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com> Message-ID: On Fri, 19 May 2023 20:21:16 GMT, Bradford Wetmore wrote: >> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix bug id in test header >> - reworked example into a jtreg test > > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 48: > >> 46: >> 47: // Test was originally written for TLSv1.2 >> 48: private static String proto = "TLSv1.2"; > > Many of these could final. Some of these are no longer used. addressed > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 86: > >> 84: * Main entry point for this demo. >> 85: */ >> 86: public static void main(String args[]) throws Exception { > > Nit. C Style args here instead of Java style. addressed > test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 104: > >> 102: } >> 103: >> 104: static Test8294985 fuzzdemoref = null; > > No longer used. addressed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955290 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955420 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955349 From wetmore at openjdk.org Mon May 22 19:36:17 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Mon, 22 May 2023 19:36:17 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v15] In-Reply-To: <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com> Message-ID: On Fri, 19 May 2023 17:49:07 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: > > - fix bug id in test header > - reworked example into a jtreg test test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 48: > 46: > 47: // Test was originally written for TLSv1.2 > 48: private static String proto = "TLSv1.2"; Many of these could final. Some of these are no longer used. test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 86: > 84: * Main entry point for this demo. > 85: */ > 86: public static void main(String args[]) throws Exception { Nit. C Style args here instead of Java style. test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 104: > 102: } > 103: > 104: static Test8294985 fuzzdemoref = null; No longer used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199338944 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199339757 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199339499 From kdriver at openjdk.org Mon May 22 19:41:25 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Mon, 22 May 2023 19:41:25 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v19] In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: > Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8294985 - additional code review comments - rename class and remove bug id from test header - removing block that isn't reached - fix bug id in test header - reworked example into a jtreg test - whitespace adjustments - all review comments applied - optimize imports and change toString - review comments addressed - ... and 7 more: https://git.openjdk.org/jdk/compare/bdf0d8ad...d9f0c667 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13466/files - new: https://git.openjdk.org/jdk/pull/13466/files/10c18fa1..d9f0c667 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=17-18 Stats: 21455 lines in 699 files changed: 12606 ins; 6112 del; 2737 mod Patch: https://git.openjdk.org/jdk/pull/13466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466 PR: https://git.openjdk.org/jdk/pull/13466 From bpb at openjdk.org Mon May 22 19:52:50 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 22 May 2023 19:52:50 GMT Subject: RFR: 8308016: Use snippets in java.io package [v8] In-Reply-To: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com> References: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com> Message-ID: On Mon, 22 May 2023 19:28:26 GMT, Roger Riggs wrote: > Thanks for the updates. Thanks for all the comments (and the approval). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13957#issuecomment-1557863535 From jnimeh at openjdk.org Mon May 22 21:55:12 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 22 May 2023 21:55:12 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v5] In-Reply-To: References: Message-ID: > This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. > > This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). > > JBS: https://bugs.openjdk.org/browse/JDK-8179502 > CSR: https://bugs.openjdk.org/browse/JDK-8300722 Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Add additional debug message in timeout property parser - Merge with main - Use privilegedGetProperty, catch NFE following string match - Add OCSP readtimeout property - Add 's' suffix to allowed syntax - Fix more whitespace errors - Fix whitespace errors - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13762/files - new: https://git.openjdk.org/jdk/pull/13762/files/e73818ef..659da859 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=03-04 Stats: 183453 lines in 3181 files changed: 133144 ins; 26618 del; 23691 mod Patch: https://git.openjdk.org/jdk/pull/13762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762 PR: https://git.openjdk.org/jdk/pull/13762 From valeriep at openjdk.org Mon May 22 22:20:57 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 22 May 2023 22:20:57 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Sat, 20 May 2023 00:58:05 GMT, Martin Balao wrote: >> Good > > We discussed this change with @franferrax and have some concerns. The method Key::getEncoded does not document that a copy will be returned, and this would change the current behavior and affect non-PBE cases. In practical terms, it would mean that a key directly or indirectly converted to a P11Key would be destroyed if it does not return a clone in its getEncoded method. We suggest to make the caller responsible and keep the existing behavior. I.e.: if we call with a SecretKeySpec ?whose ::getEncoded returns a clone?, the caller will need to (optionally) clear the key. What do you think? Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1201228024 From weijun at openjdk.org Mon May 22 22:45:53 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 May 2023 22:45:53 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com> Message-ID: <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com> On Sun, 21 May 2023 21:29:50 GMT, Christoph Langer wrote: >> src/java.base/macosx/classes/apple/security/KeychainStore.java line 808: >> >>> 806: // Check whether a certificate with same alias already exists and is the same >>> 807: // If yes, we can return here - the existing entry must have the same >>> 808: // properties and trust settings >> >> This is always true, right? I'm not sure how this could happen. > > This handles the case, when a certificate is in both, the login (user) and system keychain. How do you know "the existing entry must have the same properties and trust settings"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1201258508 From jnimeh at openjdk.org Mon May 22 23:54:49 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 22 May 2023 23:54:49 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v4] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 17:39:59 GMT, Jamil Nimeh wrote: >> src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java line 131: >> >>> 129: private static final int DEFAULT_CRL_READ_TIMEOUT = 15000; >>> 130: >>> 131: // Default connect and read timeouts for CA certificate fetching (15 sec) >> >> Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense. >> >> I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that? > > Yes, I can make a follow on for that. Filed https://bugs.openjdk.org/browse/JDK-8308601 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1201306717 From mpowers at openjdk.org Tue May 23 00:36:26 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 23 May 2023 00:36:26 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v3] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8307794 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: Ferenc: comments 1 and 2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13940/files - new: https://git.openjdk.org/jdk/pull/13940/files/7598bc74..eaace224 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=01-02 Stats: 1479 lines in 1 file changed: 179 ins; 664 del; 636 mod Patch: https://git.openjdk.org/jdk/pull/13940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940 PR: https://git.openjdk.org/jdk/pull/13940 From fgao at openjdk.org Tue May 23 01:59:58 2023 From: fgao at openjdk.org (Fei Gao) Date: Tue, 23 May 2023 01:59:58 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics In-Reply-To: References: Message-ID: On Mon, 22 May 2023 14:23:15 GMT, Andrew Haley wrote: > This provides a solid speedup of about 3-4x over the Java implementation. > > I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. > > Benchmarks: > > > ThunderX (2, I think): > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s > > Apple M1: > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s > Poly1305DigestBench.updateBytes 256 th... src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 573: > 571: } > 572: > 573: if (FLAG_IS_DEFAULT(UsePoly1305Intrinsics)) { Incorrect indention: extra space. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1201408065 From clanger at openjdk.org Tue May 23 06:54:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 23 May 2023 06:54:49 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com> <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com> Message-ID: On Mon, 22 May 2023 22:43:18 GMT, Weijun Wang wrote: >> This handles the case, when a certificate is in both, the login (user) and system keychain. > > How do you know "the existing entry must have the same properties and trust settings"? Trust settings are stored per certificate. That is, when you do `security add-trusted-cert`, you have to pass a certificate that the entry is created for. It does not matter then, if the certificate is actually present/loaded into any keychain. If the certificate is not in the keychain, a `security dump-trust-settings` will not show the trust entry then but after you add it, it gets visible. So, that means, if two certificates are the same, no matter if they were loaded from different keychains or under different aliases (don't know whether the latter is possible though), they will share the same trust records. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1201622626 From weijun at openjdk.org Tue May 23 15:10:50 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 23 May 2023 15:10:50 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose. >> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove another obsolete comment The code change looks fine to me. Thanks. Since this is rather a big behavior change, I think a CSR and a release note are required. The previous release note on this is at https://www.oracle.com/java/technologies/javase/19-relnote-issues.html#JDK-8278449. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559419631 From weijun at openjdk.org Tue May 23 15:10:58 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 23 May 2023 15:10:58 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com> <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com> Message-ID: On Tue, 23 May 2023 06:52:01 GMT, Christoph Langer wrote: >> How do you know "the existing entry must have the same properties and trust settings"? > > Trust settings are stored per certificate. That is, when you do `security add-trusted-cert`, you have to pass a certificate that the entry is created for. It does not matter then, if the certificate is actually present/loaded into any keychain. If the certificate is not in the keychain, a `security dump-trust-settings` will not show the trust entry then but after you add it, it gets visible. > > So, that means, if two certificates are the same, no matter if they were loaded from different keychains or under different aliases (don't know whether the latter is possible though), they will share the same trust records. I see. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1202347175 From duke at openjdk.org Tue May 23 15:11:11 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 23 May 2023 15:11:11 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v3] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 00:36:26 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8307794 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Ferenc: comments 1 and 2 The code looks good to me now. I still suggest to change the file names, though. test/jdk/sun/security/provider/lms/TestLMS.java line 59: > 57: for (TestCase t : TestCases) { > 58: if (!kat(t)) { > 59: throw new RuntimeException("test case #" +i+ " failed"); Nit: "+i+" -> "+ i +" ------------- PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1559062663 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202062133 From wetmore at openjdk.org Tue May 23 15:14:26 2023 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 23 May 2023 15:14:26 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v19] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Mon, 22 May 2023 19:41:25 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8294985 > - additional code review comments > - rename class and remove bug id from test header > - removing block that isn't reached > - fix bug id in test header > - reworked example into a jtreg test > - whitespace adjustments > - all review comments applied > - optimize imports and change toString > - review comments addressed > - ... and 7 more: https://git.openjdk.org/jdk/compare/6825bcbe...d9f0c667 test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 27: > 25: * @test > 26: * @library /test/lib > 27: * @summary verify correct exception handling in the event of an unparseable Missing @bug field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202513519 From mullan at openjdk.org Tue May 23 15:17:48 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 May 2023 15:17:48 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Sat, 20 May 2023 01:20:20 GMT, Martin Balao wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Rebase fix after JDK-8306033. Replace called functions with their new names. >> - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao >> - 8301553: Support Password-Based Cryptography in SunPKCS11 >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel. > > We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument. > > No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11. @martinuy I am adding a CSR requirement for this issue. In this Enhancement, you are adding support for new algorithms in a JCE provider. This type of change requires a CSR as you are adding support for algorithms that can be used by applications and not just inside the JDK, thus it is a type of exported interface of JDK scope. For an example of a similar issue, see [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should also include details about any behavioral changes or differences that affect use of the algorithms through the standard JCE APIs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1559447733 From jnimeh at openjdk.org Tue May 23 15:18:51 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 23 May 2023 15:18:51 GMT Subject: Integrated: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com> Message-ID: On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh wrote: > This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE. For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior. > > - Issue: https://bugs.openjdk.org/browse/JDK-8305091 > - CSR: https://bugs.openjdk.org/browse/JDK-8305822 This pull request has now been integrated. Changeset: bb0ff48a Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/bb0ff48aa94c4648a2f929226dd8d252431bcd03 Stats: 77 lines in 2 files changed: 31 ins; 14 del; 32 mod 8305091: Change ChaCha20 cipher init behavior to match AES-GCM Reviewed-by: djelinski, ascarpino ------------- PR: https://git.openjdk.org/jdk/pull/13428 From mullan at openjdk.org Tue May 23 15:30:18 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 May 2023 15:30:18 GMT Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts [v5] In-Reply-To: References: Message-ID: <432KzSlo3CzO7O7_Qy14cENyYO3JHS9T2qC4oPrt9jA=.199b454b-8506-4c2f-88a7-426ba88f43ab@github.com> On Mon, 22 May 2023 21:55:12 GMT, Jamil Nimeh wrote: >> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. >> >> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). >> >> JBS: https://bugs.openjdk.org/browse/JDK-8179502 >> CSR: https://bugs.openjdk.org/browse/JDK-8300722 > > Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Add additional debug message in timeout property parser > - Merge with main > - Use privilegedGetProperty, catch NFE following string match > - Add OCSP readtimeout property > - Add 's' suffix to allowed syntax > - Fix more whitespace errors > - Fix whitespace errors > - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts Looks good. I think there may be value in moving some of the test code into the testlibrary, like the AIA and CRL https servers so other tests can use it, but we can explore that more later if the opportunity arises. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13762#pullrequestreview-1439694604 From clanger at openjdk.org Tue May 23 15:58:04 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 23 May 2023 15:58:04 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: On Tue, 23 May 2023 13:50:48 GMT, Weijun Wang wrote: > The code change looks fine to me. Thanks. > > Since this is rather a big behavior change, I think a CSR and a release note are required. The previous release note on this is at https://www.oracle.com/java/technologies/javase/19-relnote-issues.html#JDK-8278449. Thanks for the review. As for CSR and release note, I guess one could do both, sure. However, it's quite a bit of overhead. And, for JDK-8278449, I don't see a CSR either. ? I would consider this change rather as a bugfix for JDK-8278449. So, if you really want me to do it, I'll do it. But please help me to get this processed quickly as I want to get this fix integrated ideally through this week. Please let me know your decision. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559722249 From bpb at openjdk.org Tue May 23 16:03:43 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 23 May 2023 16:03:43 GMT Subject: Integrated: 8308016: Use snippets in java.io package In-Reply-To: References: Message-ID: On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter wrote: > Replace `
{@code ...}
` patterns and the like with `{@snippet lang=java : ...}`. This pull request has now been integrated. Changeset: 710453c6 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/710453c676712d021bf856dc601d965e4e270805 Stats: 159 lines in 20 files changed: 27 ins; 7 del; 125 mod 8308016: Use snippets in java.io package Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/13957 From mpowers at openjdk.org Tue May 23 16:29:10 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 23 May 2023 16:29:10 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v4] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8307794 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: Ferenc: comment 3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13940/files - new: https://git.openjdk.org/jdk/pull/13940/files/eaace224..5a851046 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=02-03 Stats: 0 lines in 2 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940 PR: https://git.openjdk.org/jdk/pull/13940 From cslucas at openjdk.org Tue May 23 16:39:22 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 23 May 2023 16:39:22 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 22 May 2023 17:56:41 GMT, Cesar Soares Lucas wrote: > Speaking of _only_merge_candidate flag, I find it easier about the code when the property being tracked is whether the ObjectValue is referenced from corresponding JVM state or not. (Maybe call it is_root()?) So, ScopeDesc::objects_to_rematerialize() would skip everything not referenced from JVM state [...] @iwanowww - I want to make sure I understood "is_root(sv)" correctly. Are you suggesting to implement it as `ScopeDesc::is_root(ScopeValue* sv)` and the body of the method would just check if the `sv` is referenced in locals/expressions/monitor? Did I get it right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559796992 From kdriver at openjdk.org Tue May 23 16:51:45 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 May 2023 16:51:45 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v19] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: On Tue, 23 May 2023 15:09:39 GMT, Bradford Wetmore wrote: >> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8294985 >> - additional code review comments >> - rename class and remove bug id from test header >> - removing block that isn't reached >> - fix bug id in test header >> - reworked example into a jtreg test >> - whitespace adjustments >> - all review comments applied >> - optimize imports and change toString >> - review comments addressed >> - ... and 7 more: https://git.openjdk.org/jdk/compare/98f1821e...d9f0c667 > > test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 27: > >> 25: * @test >> 26: * @library /test/lib >> 27: * @summary verify correct exception handling in the event of an unparseable > > Missing @bug field. I was asked to remove it previously. I can add it back. Just looking for a consistent POV here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202704091 From weijun at openjdk.org Tue May 23 17:08:03 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 23 May 2023 17:08:03 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> Message-ID: <_aMfZRowhoTiFT0z_kZoxa7ewtoUnOqsEc12QaBrVoM=.0abd1e4f-4ac9-4bd2-95fa-ef0a1c996519@github.com> On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer wrote: >> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store. >> >> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari. >> >> This change does the following: >> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain. >> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose. >> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance. >> >> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Remove another obsolete comment I've started the CSR at https://bugs.openjdk.org/browse/JDK-8308690. Please edit if there is any issue. At the same time, please write a release note. See https://openjdk.org/guide/#release-notes for the process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559835489 From mpowers at openjdk.org Tue May 23 17:14:42 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 23 May 2023 17:14:42 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: > https://bugs.openjdk.org/browse/JDK-8307794 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: change class names and fix nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13940/files - new: https://git.openjdk.org/jdk/pull/13940/files/5a851046..a5aaeac0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940 PR: https://git.openjdk.org/jdk/pull/13940 From vlivanov at openjdk.org Tue May 23 17:15:07 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 May 2023 17:15:07 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Tue, 23 May 2023 16:36:32 GMT, Cesar Soares Lucas wrote: > Are you suggesting to implement it as ScopeDesc::is_root(ScopeValue* sv) and the body of the method would just check if the sv is referenced in locals/expressions/monitor? Did I get it right? I didn't propose exactly that, but I like your idea. I'm not against having it cached on `ScopeValue` side (and serialized in debug info), but implementing it as a query on `ScopeDesc` does look like a better alternative. (If it turns out to matter from performance POV, the check can be then turned into an assert and the cached value is used.) Maybe call it `ScopeDesc::has_reference_to(ScopeValue* sv)` then. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559844211 From mpowers at openjdk.org Tue May 23 17:17:07 2023 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 23 May 2023 17:17:07 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v3] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 10:49:17 GMT, Ferenc Rakoczi wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Ferenc: comments 1 and 2 > > test/jdk/sun/security/provider/lms/TestLMS.java line 59: > >> 57: for (TestCase t : TestCases) { >> 58: if (!kat(t)) { >> 59: throw new RuntimeException("test case #" +i+ " failed"); > > Nit: "+i+" -> "+ i +" Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202736729 From xuelei at openjdk.org Tue May 23 18:19:09 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 23 May 2023 18:19:09 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v19] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <35aaSxH44qUrq8mfvwC0Hy4xYyvWTxZaLcTSfGv5fYk=.b5b66d89-ccca-495a-b173-31a20361be1c@github.com> On Mon, 22 May 2023 19:41:25 GMT, Kevin Driver wrote: >> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985) > > Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8294985 > - additional code review comments > - rename class and remove bug id from test header > - removing block that isn't reached > - fix bug id in test header > - reworked example into a jtreg test > - whitespace adjustments > - all review comments applied > - optimize imports and change toString > - review comments addressed > - ... and 7 more: https://git.openjdk.org/jdk/compare/1950bd92...d9f0c667 Changes requested by xuelei (Reviewer). test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29: > 27: * @summary verify correct exception handling in the event of an unparseable > 28: * DN in the peer CA > 29: */ Please run tests for JSSE/TLS in othervm mode. Otherwise, the behavior may be impacted with each other, and the failure debugging is pretty hard. ------------- PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1440319320 PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202812974 From xuelei at openjdk.org Tue May 23 18:19:11 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 23 May 2023 18:19:11 GMT Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal [v19] In-Reply-To: References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com> Message-ID: <8enBn6p_vJgOD0rgn4FZ5n0ZMnMBYMlzdQ3qzxQvE34=.70497115-c1c7-497f-aaae-3548a6edc185@github.com> On Tue, 23 May 2023 16:48:52 GMT, Kevin Driver wrote: >> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 27: >> >>> 25: * @test >>> 26: * @library /test/lib >>> 27: * @summary verify correct exception handling in the event of an unparseable >> >> Missing @bug field. > > I was asked to remove it previously. I can add it back. Just looking for a consistent POV here. Generally, the @bug tag should be there to easy maintenance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202809318 From mbalao at openjdk.org Tue May 23 18:59:04 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 23 May 2023 18:59:04 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Mon, 22 May 2023 22:18:13 GMT, Valerie Peng wrote: >> We discussed this change with @franferrax and have some concerns. The method Key::getEncoded does not document that a copy will be returned, and this would change the current behavior and affect non-PBE cases. In practical terms, it would mean that a key directly or indirectly converted to a P11Key would be destroyed if it does not return a clone in its getEncoded method. We suggest to make the caller responsible and keep the existing behavior. I.e.: if we call with a SecretKeySpec ?whose ::getEncoded returns a clone?, the caller will need to (optionally) clear the key. What do you think? > > Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values? Thanks for your feedback. We've discussed this further and will move forward with the change but Just for the record let me document our conclusions here: - This affect non-PBE scenarios and will change [previous JDK behavior](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L190). - We have found one type of key in OpenJDK whose getEncoded method does not return a clone [here](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java#L86). While we acknowledge that it's unlikely, there can be more in non-OpenJDK security providers. - We find that making the callee potentially mutate the arguments without documentation explicitly stating so can be confusing. While the clone pattern is known in Java to overcome limitations in the language and keep object immutability, it's inefficient as copies of objects need to be generated. We hope that the removal of the Security Manager and the untrusted code model provides more incentives for a different approach to this problem in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1202859208 From mullan at openjdk.org Tue May 23 19:06:58 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 May 2023 19:06:58 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 17:14:42 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8307794 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > change class names and fix nit test/micro/org/openjdk/bench/java/security/HSSLMS.java line 70: > 68: public void test01_RFC_8554() throws Exception { > 69: // RFC 8554 Test Case 1 > 70: var pk = decode(""" If we are primarily interested in measuring the performance of the HSS/LMS verification, the decode parts should really be left out of that calculation and moved to `setup()` methods. Consider having separate inner/static subclasses for each test, and moving the decoding code to the `setup()` methods in each of those subclasses. See `test/micro/org/openjdk/bench/java/security/Signatures.java` for an example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202868477 From valeriep at openjdk.org Tue May 23 19:10:06 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 23 May 2023 19:10:06 GMT Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries [v2] In-Reply-To: References: Message-ID: <7rV8nQEnTG5Vv_VF7foNk35CM5OtfKGYK_SULGtGe2U=.761fcc04-47d6-465a-bd91-6be20db62eca@github.com> On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng wrote: >> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? >> >> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed to use keytool to generate keypairs instead of importing from > data files. Thanks all for review~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1559988606 From mullan at openjdk.org Tue May 23 19:19:02 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 May 2023 19:19:02 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 17:14:42 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8307794 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > change class names and fix nit test/jdk/sun/security/provider/hss/TestHSSLMS.java line 26: > 24: /* > 25: * @test > 26: * @bug JDK-8298127 Should just be `@bug 8298127`. test/jdk/sun/security/provider/hss/TestHSSLMS.java line 83: > 81: verify(t.pk, t.sig, t.msg); > 82: return false; > 83: } catch (InvalidKeySpecException | SignatureException ex) { It would be nice to test for the expected exception, either `InvalidKeySpecException` or `SignatureException`. You could add an additional field to the `TestCase` record which checks for the expected exception type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202871587 PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202877384 From weijun at openjdk.org Tue May 23 19:29:48 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 23 May 2023 19:29:48 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v3] In-Reply-To: References: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com> Message-ID: On Tue, 23 May 2023 18:55:46 GMT, Martin Balao wrote: >> Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values? > > Thanks for your feedback. We've discussed this further and will move forward with the change but Just for the record let me document our conclusions here: > > - This affect non-PBE scenarios and will change [previous JDK behavior](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L190). > - We have found one type of key in OpenJDK whose getEncoded method does not return a clone [here](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java#L86). While we acknowledge that it's unlikely, there can be more in non-OpenJDK security providers. > - We find that making the callee potentially mutate the arguments without documentation explicitly stating so can be confusing. While the clone pattern is known in Java to overcome limitations in the language and keep object immutability, it's inefficient as copies of objects need to be generated. We hope that the removal of the Security Manager and the untrusted code model provides more incentives for a different approach to this problem in the future. The SunMSCAPI `getEncoded()` returning an internal cached encoding is a bug. I'll fix it. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1202885740 From mbalao at openjdk.org Tue May 23 19:29:47 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 23 May 2023 19:29:47 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: > We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. > > In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): > > * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. > * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). > > * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) > * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ... Martin Balao has updated the pull request incrementally with one additional commit since the last revision: 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) Co-authored-by: Francisco Ferrari Co-authored-by: Martin Balao ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12396/files - new: https://git.openjdk.org/jdk/pull/12396/files/41b14723..80575ccb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=03-04 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396 PR: https://git.openjdk.org/jdk/pull/12396 From hchao at openjdk.org Tue May 23 19:37:57 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 23 May 2023 19:37:57 GMT Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 17:14:42 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8307794 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > change class names and fix nit Test VerifyHSSLMSSignedJar.java looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1560018158 From valeriep at openjdk.org Tue May 23 21:15:06 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 23 May 2023 21:15:06 GMT Subject: Integrated: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng wrote: > Could someone help review this PKCS11KeyStore fix regarding the cert chain removal? > > The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 6b27dad7 Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/6b27dad76e20131503da15119d930df17dd517d9 Stats: 348 lines in 4 files changed: 264 ins; 37 del; 47 mod 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries Reviewed-by: weijun, hchao ------------- PR: https://git.openjdk.org/jdk/pull/13743 From clanger at openjdk.org Tue May 23 21:20:57 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 23 May 2023 21:20:57 GMT Subject: RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6] In-Reply-To: <_aMfZRowhoTiFT0z_kZoxa7ewtoUnOqsEc12QaBrVoM=.0abd1e4f-4ac9-4bd2-95fa-ef0a1c996519@github.com> References: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com> <_aMfZRowhoTiFT0z_kZoxa7ewtoUnOqsEc12QaBrVoM=.0abd1e4f-4ac9-4bd2-95fa-ef0a1c996519@github.com> Message-ID: On Tue, 23 May 2023 17:05:13 GMT, Weijun Wang wrote: > I've started the CSR at https://bugs.openjdk.org/browse/JDK-8308690. Please edit if there is any issue. At the same time, please write a release note. See https://openjdk.org/guide/#release-notes for the process. Thanks. I've created a release note and Edited the CSR. Please review both. When you are fine with the CSR, I can finalize it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1560135796 From jnimeh at openjdk.org Tue May 23 21:36:09 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 23 May 2023 21:36:09 GMT Subject: Integrated: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts In-Reply-To: References: Message-ID: <-8MaW0PKCc_ysgT24jw73ETHVSAlLG1KcV-uuyjhLpM=.508b5616-5220-4dd0-80bf-af246a6c437d@github.com> On Tue, 2 May 2023 21:12:31 GMT, Jamil Nimeh wrote: > This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds. > > This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false). > > JBS: https://bugs.openjdk.org/browse/JDK-8179502 > CSR: https://bugs.openjdk.org/browse/JDK-8300722 This pull request has now been integrated. Changeset: 2836c34b Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/2836c34b64e4626e25c86a53e5bef2bf32f95d2e Stats: 913 lines in 7 files changed: 795 ins; 25 del; 93 mod 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/13762 From ssahoo at openjdk.org Wed May 24 07:10:25 2023 From: ssahoo at openjdk.org (Sibabrata Sahoo) Date: Wed, 24 May 2023 07:10:25 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation Message-ID: Additional Tests for KEM API. ------------- Commit messages: - 8308711: Develop additional Tests for KEM implementation Changes: https://git.openjdk.org/jdk/pull/14113/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308711 Stats: 540 lines in 3 files changed: 540 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14113/head:pull/14113 PR: https://git.openjdk.org/jdk/pull/14113 From aph at openjdk.org Wed May 24 09:25:06 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 May 2023 09:25:06 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2] In-Reply-To: References: Message-ID: > This provides a solid speedup of about 3-4x over the Java implementation. > > I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. > > Benchmarks: > > > ThunderX (2, I think): > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s > > Apple M1: > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s > Poly1305DigestBench.updateBytes 256 th... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14085/files - new: https://git.openjdk.org/jdk/pull/14085/files/ec0aa80d..c74ed2c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085 PR: https://git.openjdk.org/jdk/pull/14085 From redestad at openjdk.org Wed May 24 10:11:55 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 24 May 2023 10:11:55 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 09:25:06 GMT, Andrew Haley wrote: >> This provides a solid speedup of about 3-4x over the Java implementation. >> >> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. >> >> Benchmarks: >> >> >> ThunderX (2, I think): >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s >> >> Apple M1: >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s >> Poly1305DigestBench.upd... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7097: > 7095: // together partial products without any risk of needing to > 7096: // propagate a carry out. > 7097: wide_mul(U_0, U_0HI, S_0, R_0); wide_madd(U_0, U_0HI, S_1, RR_1); wide_madd(U_0, U_0HI, S_2, RR_0); What is `r` corresponding to here? This asserts that 'the top four bits of each 32-bit subword of "r" are zero'. If `r` is `R_0...R_2` it would seem broken since we're packing 26-bit values into `R_0...R_2` above in a way that would break this invariant? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1203838423 From aph at openjdk.org Wed May 24 10:21:56 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 May 2023 10:21:56 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2] In-Reply-To: References: Message-ID: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com> On Wed, 24 May 2023 10:07:47 GMT, Claes Redestad wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Whitespace > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7097: > >> 7095: // together partial products without any risk of needing to >> 7096: // propagate a carry out. >> 7097: wide_mul(U_0, U_0HI, S_0, R_0); wide_madd(U_0, U_0HI, S_1, RR_1); wide_madd(U_0, U_0HI, S_2, RR_0); > > What is `r` corresponding to here? This asserts that 'the top four bits of each 32-bit subword of "r" are zero'. If `r` is `R_0...R_2` it would seem broken since we're packing 26-bit values into `R_0...R_2` above in a way that would break this invariant? No, it doesn't break the invariants. R is the randomly-chosen 128-bit key. It is generated from an initial 128-bit-log string or random bits, then `r &= 0x0ffffffc0ffffffc0ffffffc0fffffff` This 128-bit-long string is split into 26-bit limbs before the intrinsic is called. The zero bits remain zero. When we repack R into two 64-bit registers those zero bits are still zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1203850178 From aph at openjdk.org Wed May 24 11:13:13 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 May 2023 11:13:13 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v3] In-Reply-To: References: Message-ID: <4sG1ZCZbdkhSv3YMaKNJJgeScmCHjhAQamhVloF-5EY=.359451be-9627-4aac-896e-abbb1126fde0@github.com> > This provides a solid speedup of about 3-4x over the Java implementation. > > I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. > > Benchmarks: > > > ThunderX (2, I think): > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s > > Apple M1: > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s > Poly1305DigestBench.updateBytes 256 th... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Comment change only ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14085/files - new: https://git.openjdk.org/jdk/pull/14085/files/c74ed2c6..9cc899b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085 PR: https://git.openjdk.org/jdk/pull/14085 From aph at openjdk.org Wed May 24 11:13:16 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 May 2023 11:13:16 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2] In-Reply-To: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com> References: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com> Message-ID: On Wed, 24 May 2023 10:18:39 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7097: >> >>> 7095: // together partial products without any risk of needing to >>> 7096: // propagate a carry out. >>> 7097: wide_mul(U_0, U_0HI, S_0, R_0); wide_madd(U_0, U_0HI, S_1, RR_1); wide_madd(U_0, U_0HI, S_2, RR_0); >> >> What is `r` corresponding to here? This asserts that 'the top four bits of each 32-bit subword of "r" are zero'. If `r` is `R_0...R_2` it would seem broken since we're packing 26-bit values into `R_0...R_2` above in a way that would break this invariant? > > No, it doesn't break the invariants. > > R is the randomly-chosen 128-bit key. It is generated from an initial 128-bit-log string of random bits, then > `r &= 0x0ffffffc0ffffffc0ffffffc0fffffff` > > This 128-bit-long string is split into 26-bit limbs before the intrinsic is called. The zero bits remain zero. > When we repack R into two 64-bit registers those zero bits are still zero. See https://loup-vaillant.fr/tutorials/poly1305-design for more explanation ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1203912143 From weijun at openjdk.org Wed May 24 13:24:00 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 May 2023 13:24:00 GMT Subject: RFR: 8308711: Develop additional Tests for KEM implementation In-Reply-To: References: Message-ID: On Wed, 24 May 2023 07:02:55 GMT, Sibabrata Sahoo wrote: > Additional Tests for KEM API. test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 1: > 1: /* 1. `testXDH` and `testEC` are mostly identical. Maybe you can write a single method with 2 extra arguments. 2. According to the spec, multiple keys generated from a *single* `Encapsulator` are different. The `test` method is creating a new encapsulators each time. 3. There is no guarantee that a `SecretKey` follows the `hashCode/equals` convention and can be put inside a `Set` to detect duplication. It happens that in this implementation the key is a `SecretKeySpec` object so it works. test/jdk/javax/crypto/KEM/KemInterop.java line 77: > 75: KEM.Encapsulated enc2 = encT1.encapsulate(); > 76: > 77: Asserts.assertEQ(enc.key(), enc.key()); Again, we cannot guarantee `equals` between 2 `SecretKey` objects. However, since it's a positive test here, it's OK to do this. If we really modify the implementation later and return a different kind of `SecretKey`, we can update the test later. test/jdk/javax/crypto/KEM/KemInterop.java line 81: > 79: Asserts.assertTrue(Arrays.equals(enc.encapsulation(), enc.encapsulation())); > 80: > 81: Asserts.assertNE(enc.key(), enc1.key()); This is a negative test and we should rely on `!equals` here. I think we can drop this check. If the `enc.key()` check below already shows they are different, then the key will be different too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1204090836 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1204119149 PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1204120540 From redestad at openjdk.org Wed May 24 13:41:56 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 24 May 2023 13:41:56 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2] In-Reply-To: References: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com> Message-ID: On Wed, 24 May 2023 11:08:31 GMT, Andrew Haley wrote: >> No, it doesn't break the invariants. >> >> R is the randomly-chosen 128-bit key. It is generated from an initial 128-bit-log string of random bits, then >> `r &= 0x0ffffffc0ffffffc0ffffffc0fffffff` >> >> This 128-bit-long string is split into 26-bit limbs before the intrinsic is called. The zero bits remain zero. >> When we repack R into two 64-bit registers those zero bits are still zero. > > See https://loup-vaillant.fr/tutorials/poly1305-design for more explanation Thanks for the link! So `r` refers to the value passed via `r_start` and it wasn't clear from the immediate context that `r_start` is already split into 26-bit limbs. So the `pack26` takes the 5 26-bit limbs and repacks them so that `R_0` has the low 64-bit of `r`, `R_1` the high bits. Makes sense. `R_2` is unused and could be reclaimed. Perhaps an override for `pack26` that only takes two registers and discards the last 2 bits? Might help clarify the setup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1204159348 From mullan at openjdk.org Wed May 24 15:46:24 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 24 May 2023 15:46:24 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v17] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 19:11:32 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed dead code, accepted code style suggestions. src/java.base/share/classes/sun/security/provider/HSS.java line 664: > 662: protected PublicKey engineGeneratePublic(KeySpec keySpec) > 663: throws InvalidKeySpecException { > 664: if (keySpec instanceof X509EncodedKeySpec) { Can you also use `instanceof x` here and avoid the cast on line 666? src/java.base/share/classes/sun/security/provider/HSS.java line 695: > 693: throw new InvalidKeySpecException("key should not be null"); > 694: } > 695: if (key.getFormat().equals("X.509") && Would it make sense to also check if `key` is an instance of `HSSPublicKey`? src/java.base/share/classes/sun/security/provider/HSS.java line 700: > 698: return keySpec.cast(new X509EncodedKeySpec(key.getEncoded())); > 699: } > 700: throw new InvalidKeySpecException("keySpec is not an X509 one"); Suggest saying name of class: "keySpec is not an X509EncodedKeySpec" src/java.base/share/classes/sun/security/provider/HSS.java line 787: > 785: > 786: @java.io.Serial > 787: protected Object writeReplace() throws java.io.ObjectStreamException { Make this `private` instead of `protected`. Also, add an overridden private `readObject` method that simply throws an exception, ex: `throw new InvalidObjectException("HSS public keys are not directly deserializable"); ` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204336773 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204361545 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204353785 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204415763 From aph at openjdk.org Wed May 24 16:17:14 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 May 2023 16:17:14 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: > This provides a solid speedup of about 3-4x over the Java implementation. > > I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. > > Benchmarks: > > > ThunderX (2, I think): > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s > > Apple M1: > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s > Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s > Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s > Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s > Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s > > Benchmark (dataSize) (provider) Mode Cnt Score Error Units > Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s > Poly1305DigestBench.updateBytes 256 th... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14085/files - new: https://git.openjdk.org/jdk/pull/14085/files/9cc899b9..93a03c62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=02-03 Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085 PR: https://git.openjdk.org/jdk/pull/14085 From aph at openjdk.org Wed May 24 16:17:16 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 May 2023 16:17:16 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2] In-Reply-To: References: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com> Message-ID: On Wed, 24 May 2023 13:39:10 GMT, Claes Redestad wrote: >> See https://loup-vaillant.fr/tutorials/poly1305-design for more explanation > > Thanks for the link! > > So `r` refers to the value passed via `r_start` and it wasn't clear from the immediate context that `r_start` is already split into 26-bit limbs. So the `pack26` takes the 5 26-bit limbs and repacks them so that `R_0` has the low 64-bit of `r`, `R_1` the high bits. Makes sense. > > `R_2` is unused and could be reclaimed. Perhaps an override for `pack26` that only takes two registers and discards the last 2 bits? Might help clarify the setup. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1204459514 From mullan at openjdk.org Wed May 24 16:26:20 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 24 May 2023 16:26:20 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v17] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 19:11:32 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed dead code, accepted code style suggestions. src/java.base/share/classes/sun/security/provider/HSS.java line 58: > 56: > 57: @Override > 58: protected void engineInitSign(PrivateKey privateKey) I think you should also override `engineInitSign(PrivateKey, SecureRandom)` even though the default impl. calls `engineInitSign(PrivateKey)`. It also assigns the `SecureRandom` to the protected `appRandom` field, which is probably best avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204473301 From valeriep at openjdk.org Wed May 24 18:42:10 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 May 2023 18:42:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 71: > 69: private Mac prf; > 70: @SuppressWarnings("serial") > 71: private Cleaner.Cleanable cleaner; why not directly mark "cleaner" as transient? Then you should not need `@SuppressWarnings` tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204616897 From redestad at openjdk.org Wed May 24 19:19:00 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 24 May 2023 19:19:00 GMT Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 16:17:14 GMT, Andrew Haley wrote: >> This provides a solid speedup of about 3-4x over the Java implementation. >> >> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time. >> >> Benchmarks: >> >> >> ThunderX (2, I think): >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 14078352.014 ? 4201407.966 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 5154958.794 ? 1717146.980 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 1416563.273 ? 1311809.454 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 94059.570 ? 2913.021 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 1441.024 ? 164.443 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 4516486.795 ? 419624.224 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 1228542.774 ? 202815.694 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 316051.912 ? 23066.449 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 20649.561 ? 1094.687 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 310.564 ? 31.053 ops/s >> >> Apple M1: >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 33551968.946 ? 849843.905 ops/s >> Poly1305DigestBench.updateBytes 256 thrpt 3 9911637.214 ? 63417.224 ops/s >> Poly1305DigestBench.updateBytes 1024 thrpt 3 2604370.740 ? 29208.265 ops/s >> Poly1305DigestBench.updateBytes 16384 thrpt 3 165183.633 ? 1975.998 ops/s >> Poly1305DigestBench.updateBytes 1048576 thrpt 3 2587.132 ? 40.240 ops/s >> >> Benchmark (dataSize) (provider) Mode Cnt Score Error Units >> Poly1305DigestBench.updateBytes 64 thrpt 3 12373649.589 ? 184757.721 ops/s >> Poly1305DigestBench.upd... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Thanks for your patience in answering my questions and addressing my comments. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14085#pullrequestreview-1442592376 From mbalao at openjdk.org Wed May 24 19:27:08 2023 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 24 May 2023 19:27:08 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 18:36:34 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 71: > >> 69: private Mac prf; >> 70: @SuppressWarnings("serial") >> 71: private Cleaner.Cleanable cleaner; > > why not directly mark "cleaner" as transient? Then you should not need `@SuppressWarnings` tag. We thought about transient and then changed to suppress the warning to keep consistency with ```private Mac prf```. I'll change both to transient then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204661418 From mullan at openjdk.org Wed May 24 19:36:23 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 24 May 2023 19:36:23 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v17] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 19:11:32 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Removed dead code, accepted code style suggestions. src/java.base/share/classes/sun/security/provider/HSS.java line 156: > 154: if ((inLen < (24 + m)) || (checkExactLength && (inLen != (24 + m))) || > 155: !lmsParams.hasSameHash(lmotsParams)) { > 156: throw new InvalidKeyException("Wrong LMS public Key length"); s/Key/key/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204658926 From valeriep at openjdk.org Wed May 24 20:00:06 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 May 2023 20:00:06 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 517: > 515: @Override > 516: public char[] getPassword() { > 517: return password.clone(); Would you consider throw IllegalStateException if password is cleared? This would help flag the wrong usage case of calling getPassword() after the password has been cleared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204693499 From mbalao at openjdk.org Wed May 24 20:29:15 2023 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 24 May 2023 20:29:15 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: <3mMwN6_EHlM6fQa5PQXabDEEQbIJ6ApNlnfzTUHpEG8=.9a99433d-a332-41c0-9f11-57196065e93e@github.com> On Wed, 24 May 2023 19:56:54 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 517: > >> 515: @Override >> 516: public char[] getPassword() { >> 517: return password.clone(); > > Would you consider throw IllegalStateException if password is cleared? This would help flag the wrong usage case of calling getPassword() after the password has been cleared. Sounds good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204725201 From mbalao at redhat.com Wed May 24 21:03:15 2023 From: mbalao at redhat.com (Martin Balao) Date: Wed, 24 May 2023 17:03:15 -0400 Subject: RFD: Services lockdown for security providers In-Reply-To: <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> Message-ID: Hi, Thanks Anthony for your feedback. We've been exploring the syntax and semantics for this new property further, with the goal of making it more consistent and simple while retaining expressiveness power. We understand the importance of clarity to minimize the risk of security providers, service types or algorithms being unexpectedly enabled. In this new iteration of the proposal, we explore a filter that has similarities to the serialization filter (jdk.serialFilter). We think that it could be beneficial to leverage on a specification to which the user is familiar already. General structure ==================== jdk.security.providers.filter=pattern-1; pattern-2; ...; pattern-n The property jdk.security.providers.filter is an overrideable Security property. Thus, a System property with the same name exists and, when specified, overrides any value in its Security counterpart. When not specified (value is null), filtering capabilities are completely disabled: all installed security providers, service types and algorithms are allowed. If any of these properties are set during run time, the filter could be initialized already and the new value may not take effect. When filtering capabilities are enabled, each service is checked against the filter before registration. Notice that this affects both the initial list of security providers as well as those dynamically installed during run time. Once a service is registered, instances of it can be obtained and used without any other checks that could affect performance. The registration of a service involves a combination of a security provider, service type and algorithm. Each combination is evaluated against the filter patterns, from left to right. When a pattern matches ?or, in other words, the rule concerns the service to be registered?, a decision is made: the service will be allowed or denied. When a decision is made, remaining patterns are not checked for the service under consideration. When all patterns are checked and a decision is not made, the default behavior is to deny the service registration. Contrary to the serialization filter, white spaces between patterns do not have any significance. Pattern matching ===================================================== pattern := ! security-provider.service-type.algorithm pattern := security-provider.service-type.algorithm A canonical pattern consists of 3 hierarchical levels separated by ".". From left to right in lexicographic order, these levels denote a security provider, a service type and an algorithm. If a pattern starts with "!", the decision made upon matching is to deny the service registration. Otherwise, the service registration is allowed. White spaces between "!" and the rest of the pattern do not have any significance. For a match to be successful, the security provider name, the service type and the algorithm have to match the pattern exactly (case insensitive). If the service type of a security provider interprets the algorithm as a transformation composed of different parts, the full transformation has to be specified in the pattern: the filter takes a conservative approach and does not make any assumptions of what an algorithm name means. For example, "AES" as the algorithm of a canonical filter pattern will not match an "AES/ECB/PKCS5Padding" transformation. If an algorithm alias is specified in the filter pattern, a service registering the alias will be matched. For convenience, it's possible to specify patterns in non-canonical forms: 1) At any level, the security provider, the service type or the algorithm name can contain wildcards ("*") to represent zero or more repetitions of any character; 2) The .algorithm part can be omitted to imply all algorithms under the security provider and service type; 3) The .service-type.algorithm part can be omitted to imply all service types and algorithms under the security provider; and, 4) The non-canonical form #1 can be combined with either #2 or #3. Security provider, service type and algorithm names escaping ================================================================= If the security provider, service type or algorithm name contains any of the characters "\", ".", ";" or "*", they have to be escaped by prepending the character "\". If the character "\" is found not escaping a character, it's silently discarded. White spaces are discarded at the beginning and end of names. It's worth mentioning that the described escaping rules apply to the jdk.security.providers.filter property value as read in java.lang.System::getProperty or java.security.Security::getProperty. Additional escaping might be needed depending on how the property is passed. For example, Security properties require "\" characters to be escaped. Thus, to match a provider name whose name is "\.", a filter would require the "jdk.security.providers.filter=\\\\\\." entry in the java.security file. See more about this in java.util.Properties::load [1]. Examples (correct) ==================== -- Enable all security providers, service types and algorithms: jdk.security.providers.filter= or jdk.security.providers.filter=* or jdk.security.providers.filter=*.* or jdk.security.providers.filter=*.*.* -- Enable everything except for the MD5 algorithm in MessageDigest services when implemented by the SUN security provider: jdk.security.providers.filter=!SUN.MessageDigest.MD5; * -- Enable everything except for the MD5 algorithm in MessageDigest services, irrespective of the security provider: jdk.security.providers.filter=!*.MessageDigest.MD5; * -- Enable everything except for algorithms using MD5, irrespective of the security provider and the service type: jdk.security.providers.filter=!*.*.*MD5*; * Notice that in this case there are wildcards at the beginning and end of the algorithm name. The reason is to match MD5 uses in algorithms such as HmacMD5, MD5withRSA, PBEWithMD5AndDES, etc. -- Enable everything except for the RC4 algorithm in Cipher services when implemented by the SunJCE security provider: jdk.security.providers.filter=!SunJCE.Cipher.ARCFOUR; * or jdk.security.providers.filter=!SunJCE.Cipher.RC4; * or jdk.security.providers.filter=!SunJCE.Cipher.1\.2\.840\.113549\.3\.4; * -- Enable the SUN security provider only, with all its service types and algorithms. Other security providers must be disabled. jdk.security.providers.filter=SUN -- Enable the SUN security provider only, with all its service types and algorithms except for MessageDigest. Other security providers must be disabled. jdk.security.providers.filter=!SUN.MessageDigest; SUN -- Examples (mistakes) ==================== -- Enable everything except for the MD5 algorithm, irrespective of the security provider and the service type: jdk.security.providers.filter=*; !*.*.MD5 This is wrong because the pattern "*" is matched first and a decision allowing MD5 will be made immediately after. The pattern "!*.*.MD5" will never be checked. -- Enable all SUN service types except for MessageDigest. Disable other security providers. jdk.security.providers.filter=!SUN.MessageDigest While non-SUN security providers are effectively disabled, this is wrong because SUN services other than MessageDigest will not match any pattern and, by default, the decision is to deny registration. -- Enable the SunPKCS11 security provider only. jdk.security.providers.filter=SunPKCS11 This is wrong because the SunPKCS11 provider has to be identified by its name instead of its class. A possible name would have the form of SunPKCS11-NAME. In a filter, this can be matched either by "SunPKCS11-NAME" or "SunPKCS11-*". -- Look forward to your thoughts. Thanks.- -- [1] - https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29 (?) - Thanks to Francisco Ferrari (@fferrari) for his contributions to this proposal. On 2/24/23 14:49, Anthony Scarpino wrote: > Hi Martin, > > Interesting proposal.? I think Alternative 1 is a better direction to > explore from a code structure standpoint.? If I remember correctly, > Preferred Provider is accessed when getting a service or instance of the > algorithm.? That happens on a per-operation basis.? What you describe is > something that would reshape contents of the ProviderList where > algorithms or services would not be in the list at all.? That is were I > think #2 gets too complex in trying to handle both in the same property. > ?#2 may end up putting all checks in a per-operation check, hindering > performance every time as the list grows. > > I agree this is mostly used in the FIPS situation or where someone wants > to disable an algorithm completely, say MD5.? In those cases it's best > to just prevent the algorithm from ever being available. > > On the smaller details side that you list.? I think the name ".enabled" > doesn't fit, particularly as the first thing in the example disables all > Ciphers :).? I don't have any suggestions at this time. > > As far as the syntax.? I think it maybe a bit difficult to parse in code > and mental to disable all Ciphers, then enable just for SunJCE and SUN. > The SUN '*" confused me until I realized you were enabling Ciphers. > Seems too easy to get wrong.? I know you weren't making a formal spec, > but we have to start somewhere. > > thanks > > Tony > > > On 2/17/23 10:52 AM, Martin Balao wrote: >> Hi, >> >> We would like to discuss a limitation in the current configuration >> capabilities for security providers and possible solutions that we are >> exploring (?). >> >> As you know, current configuration capabilities in java.security allow >> users to install security providers, decide their priority in a list >> (security.provider. properties) and even circumvent this priority >> for specific algorithms (jdk.security.provider.preferred property). >> However, there is no granularity in terms of what service types and >> algorithms are enabled once a security provider is installed: it's an >> all or nothing scheme. It is worth noting that security providers can >> bring with them a diverse range of service types. As an example, the >> SUN security provider comes with the following service types: >> SecureRandom, Signature, KeyPairGenerator, >> AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, >> MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, >> Configuration, CertPathBuilder and CertPathValidator [1]. >> >> In some cases, the user may need to enforce that all cryptographic >> primitives come from a specific security provider. This could happen, >> for example, when operating in a FIPS-compliant environment or under >> strict security policies. To better illustrate, let's say that the >> user requires that all cryptographic operations are performed in a >> Hardware Security Module (HSM). On the OpenJDK side, this means that >> the implementation for Cipher, Signature, Mac and other cryptographic >> services must be the one in the SunPKCS11 security provider. Let's >> also suppose that other non-cryptographic services such as those for >> certificates validation and TLS are required, and their implementation >> is in the SUN and SunJSSE security providers respectively. Setting >> SunPKCS11 at the highest priority of the list is not a strong >> guarantee to ensure that all cryptographic operations come from it: >> it's possible that an algorithm for Signature is not implemented in >> SunPKCS11 or in its underlying token but in the SUN security provider. >> Disabling the SUN security provider wouldn't be an option in this case >> because we need its certificates validation service. >> >> This problem goes beyond OpenJDK default security providers. Even if >> we come up with a new layout for service types, algorithms and >> providers ?putting backward compatibility issues aside?, there is >> always the possibility that a 3rd party security provider does not >> follow any services grouping convention. It might also be the case >> that we need to disable a specific algorithm only ?i.e. for >> cryptographic policy reasons? and TLS or JAR signing properties fall >> short. >> >> In our view, it would be beneficial to add more configuration >> flexibility and control to the existing API in which any security >> provider can be plugged in, in the form of deciding which service >> types and algorithms are enabled for each installed provider. >> >> There are 2 alternatives that we are exploring to tackle this problem. >> >> Alternative #1 >> =========================== >> >> Introduce a new security property to decide which service types and >> algorithms are enabled for each security provider. The default value >> for this property would be empty, which keeps this feature disabled >> and all services from installed security providers available. >> >> As for the new property's syntax and semantics, we've been considering >> an allow-list along the lines of: >> >> jdk.security.provider.enabled = security-provider-1 { service-type-1 : >> alg-1, ... ; ... } , ... >> >> Note: we need a formal syntax specification, this is for illustration >> only. >> >> As part of the syntax we are considering the use of wildcards (*) to >> match multiple security providers, service types and algorithms, and >> minus signs (-) to remove service types. When a service type is >> removed, the action applies to all algorithms and any attempt to >> specify them explicitly would be an error. The minus sign cannot be >> used at the algorithm level. We are also thinking that in case of a >> partial or total contradiction between conditions, the right-most >> value applies on top of the others. If a security provider, service >> type or algorithm does not exist, we can simply write a debug warning >> and ignore it. As for the name of the algorithms, we can also include >> Ciphers transformations. >> >> Example: >> >> jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : >> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature } >> >> This would be interpreted as: >> >> ??* Irrespective of the provider (*), Cipher services should be >> removed (-). This rule would be superfluous in this case because the >> property itself is an allow-list and there is nothing to the left that >> enables Cipher service types for any provider. >> ??* From the SunJCE security provider, Cipher services with >> AES/GCM/NoPadding and DES transformations are allowed, and Signature >> services with any algorithm are allowed. Notice that there is a >> shortcut here: the algorithm list that follows the service name, "': >> alg-1, ..." is optional. When omitted all the service's algorithms are >> enabled. >> ??* From the SUN security provider, every service type is allowed >> except Signature (recall that a minus sign can only apply to a >> service, removing all associated algorithms). >> >> It's not the goal of this proposal to invalidate property values that >> lead to inconsistent internal states, such as "the Cipher service of >> SunJCE depends on AlgorithmParameters from SUN". This is because the >> combinations for a check are virtually infinite: there can be 3rd >> party security providers with their own semantics and dependencies. In >> the same way, we cannot determine at start time any application >> dependencies. It's up to the user to analyze all types of dependencies >> before setting a value. >> >> >> Alternative #2 >> =========================== >> >> Introduce a boolean security property to turn the value of the >> existing jdk.security.provider.preferred property into the only >> combinations of algorithm, service and provider that are allowed: >> >> jdk.security.provider.preferredOnly = true >> >> The default value for the new property would be "false", keeping the >> current "preferred" behavior in which all algorithms and services from >> installed security providers are available. >> >> Contrary to Alternative #1, the user has to explicitly list the >> algorithms and cannot rely on wildcards to express wide categories >> such as "all Cipher algorithms from SunJCE" or "all algorithms from >> SunJCE". The use of minus signs to remove service types or algorithms >> wouldn't be available either. >> >> In order to mitigate the burden on users we can consider extending >> jdk.security.provider.preferred syntax as long as we keep >> backward-compatibility and stay within the boundaries of a "preferred" >> semantics. For example, we can accept a value of >> "jdk.security.provider.preferred=SunJCE" to mean that any service and >> any algorithm from SunJCE is either preferred or allowed, depending on >> the value of jdk.security.provider.preferredOnly. This case would be a >> service type and algorithm wildcard. We can also define an >> algorithms-only wildcard, such as Cipher.*:SunJCE. >> >> Alternative #2 has the advantage of reusing most or all of the >> existing syntax. However, it's worth noticing that it implies an >> overloaded semantic that can turn confusing or inconvenient in some >> cases. As an example, a user that relies on the prioritized security >> providers list for most of the algorithms and has only a few preferred >> exceptions, would need to express preferences by extension upon >> turning on this feature. Alternative #1 keeps preferences and >> availability as two separate concepts, in a more clear way. >> >> >> Thanks, >> Martin.- >> >> -- >> [1] - >> https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D >> (?) - Thanks to @fferrari for his contributions to this proposal. >> > From weijun.wang at oracle.com Wed May 24 22:30:56 2023 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 24 May 2023 22:30:56 +0000 Subject: RFD: Services lockdown for security providers In-Reply-To: References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> Message-ID: > On May 24, 2023, at 5:03 PM, Martin Balao wrote: > >>> To better illustrate, let's say that the user requires that all cryptographic operations are performed in a Hardware Security Module (HSM). On the OpenJDK side, this means that the implementation for Cipher, Signature, Mac and other cryptographic services must be the one in the SunPKCS11 security provider. Let's also suppose that other non-cryptographic services such as those for certificates validation and TLS are required, and their implementation is in the SUN and SunJSSE security providers respectively. Setting SunPKCS11 at the highest priority of the list is not a strong guarantee to ensure that all cryptographic operations come from it: it's possible that an algorithm for Signature is not implemented in SunPKCS11 or in its underlying token but in the SUN security provider. Disabling the SUN security provider wouldn't be an option in this case because we need its certificates validation service. You listed "Signature" as one of the "cryptographic services", but signature verification is also used in "certificates validation" which is a "non-cryptographic service". Do you mean signing must be in SunPKCS11 but verification needn't be? How do you configure that? Thanks, Max From peter.firmstone at zeus.net.au Wed May 24 22:48:43 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 25 May 2023 08:48:43 +1000 Subject: RFD: Services lockdown for security providers In-Reply-To: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> Message-ID: <00e811b6-1942-6246-2992-37e834d7aba9@zeus.net.au> These are examples of how we currently lock down the JVM, to limit providers, policy files are generated using a tool, it may do as an interim control measure, until something else is provided, it is of course a deprecated feature, subject to future removal, but it may do the job temporarily, without introducing code dependencies. https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#LL194C27-L194C27 https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L621 https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L644 https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L688 -- Regards, Peter. On 18/02/2023 4:52 am, Martin Balao wrote: > Hi, > > We would like to discuss a limitation in the current configuration > capabilities for security providers and possible solutions that we are > exploring (?). > > As you know, current configuration capabilities in java.security allow > users to install security providers, decide their priority in a list > (security.provider. properties) and even circumvent this priority > for specific algorithms (jdk.security.provider.preferred property). > However, there is no granularity in terms of what service types and > algorithms are enabled once a security provider is installed: it's an > all or nothing scheme. It is worth noting that security providers can > bring with them a diverse range of service types. As an example, the > SUN security provider comes with the following service types: > SecureRandom, Signature, KeyPairGenerator, > AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, > MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, > Configuration, CertPathBuilder and CertPathValidator [1]. > > In some cases, the user may need to enforce that all cryptographic > primitives come from a specific security provider. This could happen, > for example, when operating in a FIPS-compliant environment or under > strict security policies. To better illustrate, let's say that the > user requires that all cryptographic operations are performed in a > Hardware Security Module (HSM). On the OpenJDK side, this means that > the implementation for Cipher, Signature, Mac and other cryptographic > services must be the one in the SunPKCS11 security provider. Let's > also suppose that other non-cryptographic services such as those for > certificates validation and TLS are required, and their implementation > is in the SUN and SunJSSE security providers respectively. Setting > SunPKCS11 at the highest priority of the list is not a strong > guarantee to ensure that all cryptographic operations come from it: > it's possible that an algorithm for Signature is not implemented in > SunPKCS11 or in its underlying token but in the SUN security provider. > Disabling the SUN security provider wouldn't be an option in this case > because we need its certificates validation service. > > This problem goes beyond OpenJDK default security providers. Even if > we come up with a new layout for service types, algorithms and > providers ?putting backward compatibility issues aside?, there is > always the possibility that a 3rd party security provider does not > follow any services grouping convention. It might also be the case > that we need to disable a specific algorithm only ?i.e. for > cryptographic policy reasons? and TLS or JAR signing properties fall > short. > > In our view, it would be beneficial to add more configuration > flexibility and control to the existing API in which any security > provider can be plugged in, in the form of deciding which service > types and algorithms are enabled for each installed provider. > > There are 2 alternatives that we are exploring to tackle this problem. > > Alternative #1 > =========================== > > Introduce a new security property to decide which service types and > algorithms are enabled for each security provider. The default value > for this property would be empty, which keeps this feature disabled > and all services from installed security providers available. > > As for the new property's syntax and semantics, we've been considering > an allow-list along the lines of: > > jdk.security.provider.enabled = security-provider-1 { service-type-1 : > alg-1, ... ; ... } , ... > > Note: we need a formal syntax specification, this is for illustration > only. > > As part of the syntax we are considering the use of wildcards (*) to > match multiple security providers, service types and algorithms, and > minus signs (-) to remove service types. When a service type is > removed, the action applies to all algorithms and any attempt to > specify them explicitly would be an error. The minus sign cannot be > used at the algorithm level. We are also thinking that in case of a > partial or total contradiction between conditions, the right-most > value applies on top of the others. If a security provider, service > type or algorithm does not exist, we can simply write a debug warning > and ignore it. As for the name of the algorithms, we can also include > Ciphers transformations. > > Example: > > jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : > AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature } > > This would be interpreted as: > > ?* Irrespective of the provider (*), Cipher services should be removed > (-). This rule would be superfluous in this case because the property > itself is an allow-list and there is nothing to the left that enables > Cipher service types for any provider. > ?* From the SunJCE security provider, Cipher services with > AES/GCM/NoPadding and DES transformations are allowed, and Signature > services with any algorithm are allowed. Notice that there is a > shortcut here: the algorithm list that follows the service name, "': > alg-1, ..." is optional. When omitted all the service's algorithms are > enabled. > ?* From the SUN security provider, every service type is allowed > except Signature (recall that a minus sign can only apply to a > service, removing all associated algorithms). > > It's not the goal of this proposal to invalidate property values that > lead to inconsistent internal states, such as "the Cipher service of > SunJCE depends on AlgorithmParameters from SUN". This is because the > combinations for a check are virtually infinite: there can be 3rd > party security providers with their own semantics and dependencies. In > the same way, we cannot determine at start time any application > dependencies. It's up to the user to analyze all types of dependencies > before setting a value. > > > Alternative #2 > =========================== > > Introduce a boolean security property to turn the value of the > existing jdk.security.provider.preferred property into the only > combinations of algorithm, service and provider that are allowed: > > jdk.security.provider.preferredOnly = true > > The default value for the new property would be "false", keeping the > current "preferred" behavior in which all algorithms and services from > installed security providers are available. > > Contrary to Alternative #1, the user has to explicitly list the > algorithms and cannot rely on wildcards to express wide categories > such as "all Cipher algorithms from SunJCE" or "all algorithms from > SunJCE". The use of minus signs to remove service types or algorithms > wouldn't be available either. > > In order to mitigate the burden on users we can consider extending > jdk.security.provider.preferred syntax as long as we keep > backward-compatibility and stay within the boundaries of a "preferred" > semantics. For example, we can accept a value of > "jdk.security.provider.preferred=SunJCE" to mean that any service and > any algorithm from SunJCE is either preferred or allowed, depending on > the value of jdk.security.provider.preferredOnly. This case would be a > service type and algorithm wildcard. We can also define an > algorithms-only wildcard, such as Cipher.*:SunJCE. > > Alternative #2 has the advantage of reusing most or all of the > existing syntax. However, it's worth noticing that it implies an > overloaded semantic that can turn confusing or inconvenient in some > cases. As an example, a user that relies on the prioritized security > providers list for most of the algorithms and has only a few preferred > exceptions, would need to express preferences by extension upon > turning on this feature. Alternative #1 keeps preferences and > availability as two separate concepts, in a more clear way. > > > Thanks, > Martin.- > > -- > [1] - > https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D > (?) - Thanks to @fferrari for his contributions to this proposal. > From peter.firmstone at zeus.net.au Wed May 24 23:05:36 2023 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 25 May 2023 09:05:36 +1000 Subject: RFD: Services lockdown for security providers In-Reply-To: <00e811b6-1942-6246-2992-37e834d7aba9@zeus.net.au> References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <00e811b6-1942-6246-2992-37e834d7aba9@zeus.net.au> Message-ID: <7390f6bc-83a5-6781-5ad9-911da56feb69@zeus.net.au> Or this, which is an example of limiting a codebase by it's SHA-384 signature: https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L2241 -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. On 25/05/2023 8:48 am, Peter Firmstone wrote: > These are examples of how we currently lock down the JVM, to limit > providers, policy files are generated using a tool, it may do as an > interim control measure, until something else is provided, it is of > course a deprecated feature, subject to future removal, but it may do > the job temporarily, without introducing code dependencies. > > https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#LL194C27-L194C27 > > > https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L621 > > > https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L644 > > > https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L688 > > From valeriep at openjdk.org Wed May 24 23:39:14 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 May 2023 23:39:14 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 210: > 208: // because this is a PBE Mac service. In addition to checking > 209: // the key, check that params (if passed) are consistent. > 210: PBEUtil.checkKeyAndParams(key, params, algorithm); After this call, shouldn't you store key internally as p11Key? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204853313 From valeriep at openjdk.org Thu May 25 00:15:05 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 May 2023 00:15:05 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 112: > 110: return pbes2Params.getAlgorithmParameters( > 111: blkSize, pbeAlg, P11Util.getSunJceProvider(), > 112: JCAUtil.getSecureRandom()); The random source should be the one supplied through CipherSpi.engineInit(...) call if there is one available (see line 118). There is Cipher javadoc specifying this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204871684 From duke at openjdk.org Thu May 25 14:10:26 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 25 May 2023 14:10:26 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v17] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 16:22:55 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed dead code, accepted code style suggestions. > > src/java.base/share/classes/sun/security/provider/HSS.java line 58: > >> 56: >> 57: @Override >> 58: protected void engineInitSign(PrivateKey privateKey) > > I think you should also override `engineInitSign(PrivateKey, SecureRandom)` even though the default impl. calls `engineInitSign(PrivateKey)`. It also assigns the `SecureRandom` to the protected `appRandom` field, which is probably best avoided. Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 156: > >> 154: if ((inLen < (24 + m)) || (checkExactLength && (inLen != (24 + m))) || >> 155: !lmsParams.hasSameHash(lmotsParams)) { >> 156: throw new InvalidKeyException("Wrong LMS public Key length"); > > s/Key/key/ Changed. > src/java.base/share/classes/sun/security/provider/HSS.java line 664: > >> 662: protected PublicKey engineGeneratePublic(KeySpec keySpec) >> 663: throws InvalidKeySpecException { >> 664: if (keySpec instanceof X509EncodedKeySpec) { > > Can you also use `instanceof x` here and avoid the cast on line 666? Done. > src/java.base/share/classes/sun/security/provider/HSS.java line 700: > >> 698: return keySpec.cast(new X509EncodedKeySpec(key.getEncoded())); >> 699: } >> 700: throw new InvalidKeySpecException("keySpec is not an X509 one"); > > Suggest saying name of class: "keySpec is not an X509EncodedKeySpec" Said. > src/java.base/share/classes/sun/security/provider/HSS.java line 787: > >> 785: >> 786: @java.io.Serial >> 787: protected Object writeReplace() throws java.io.ObjectStreamException { > > Make this `private` instead of `protected`. Also, add an overridden private `readObject` method that simply throws an exception, ex: > > `throw new InvalidObjectException("HSS public keys are not directly deserializable"); > ` Privatized writeReplaced() and added readObject(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575050 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205574950 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575467 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575343 PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575158 From mbaesken at openjdk.org Thu May 25 14:37:18 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 May 2023 14:37:18 GMT Subject: RFR: JDK-8308872: enhance logging and some exception in krb5/Config.java Message-ID: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com> There exists already some logging in krb5/Config.java (enabled by -Dsun.security.krb5.debug=true), this could be enhanced for easier analysis of problems. Additionally some exception(s) might be slightly adjusted. ------------- Commit messages: - JDK-8308872 Changes: https://git.openjdk.org/jdk/pull/14151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308872 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14151/head:pull/14151 PR: https://git.openjdk.org/jdk/pull/14151 From duke at openjdk.org Thu May 25 15:52:25 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 25 May 2023 15:52:25 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v17] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 15:14:26 GMT, Sean Mullan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed dead code, accepted code style suggestions. > > src/java.base/share/classes/sun/security/provider/HSS.java line 695: > >> 693: throw new InvalidKeySpecException("key should not be null"); >> 694: } >> 695: if (key.getFormat().equals("X.509") && > > Would it make sense to also check if `key` is an instance of `HSSPublicKey`? I don't think so, the check here is not too heavy, it covers that case and it is called rarely enough that this kind of optimisation would be worthwhile ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205716056 From duke at openjdk.org Thu May 25 16:00:51 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 25 May 2023 16:00:51 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v18] In-Reply-To: References: Message-ID: > Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Addressing Sean's review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13691/files - new: https://git.openjdk.org/jdk/pull/13691/files/8f14964c..46326497 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=16-17 Stats: 22 lines in 1 file changed: 15 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691 PR: https://git.openjdk.org/jdk/pull/13691 From mullan at openjdk.org Thu May 25 16:36:19 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 May 2023 16:36:19 GMT Subject: RFR: 8298127: HSS/LMS Signature Verification [v18] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:00:51 GMT, Ferenc Rakoczi wrote: >> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Addressing Sean's review comments. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1444279703 From mullan at openjdk.org Thu May 25 19:21:15 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 May 2023 19:21:15 GMT Subject: RFR: 8297878: KEM: Implementation [v18] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 17:07:40 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: > > - Merge branch 'master' into 8297878 > - Merge branch 'master' into 8297878 > - to and length and comments > - deterministic randomness > - Resolve Siba's comment > - providerName > - more @since and about nulls > - Merge branch 'master' into 8297878 > - no more pk/sk, AIOOBE to IOOBE > - small spec change > - ... and 8 more: https://git.openjdk.org/jdk/compare/86c6bb79...7cace182 test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 62: > 60: } > 61: > 62: // Encapsulated comformance checks s/comformance/conformance/ test/jdk/javax/crypto/KEM/RSA_KEM.java line 26: > 24: /* > 25: * @test > 26: * @bug 8149417 bugid is wrong ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1205831599 PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1205918247 From valeriep at openjdk.org Thu May 25 19:33:10 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 May 2023 19:33:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 214: > 212: protected int engineGetKeySize(Key key) > 213: throws InvalidKeyException { > 214: return cipher.engineGetKeySize(key); I am not too sure that this would work for all types of key... Based on the current impl, cipher is an AES cipher, but the specified key here can be P11Key or a PBEKey object. The key algorithms for both would be PBE-related, but then you are using a AES cipher to retrieve the key size? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205929004 From valeriep at openjdk.org Thu May 25 20:29:11 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 May 2023 20:29:11 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 34: > 32: import java.nio.charset.Charset; > 33: import java.security.*; > 34: import java.util.Arrays; Not used? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 36: > 34: import java.util.Arrays; > 35: > 36: import jdk.internal.access.SharedSecrets; Not used? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 93: > 91: while (passwordBytes.hasRemaining()) { > 92: encPassword[i] = (char) (passwordBytes.get() & 0xFF); > 93: passwordBytes.put(i++, (byte) 0); nit: add a comment // for erasing bytes in 'passwordBytes' src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java line 213: > 211: sb.append(Constants.INDENT); > 212: sb.append("pParameter:"); > 213: sb.append(Constants.NEWLINE); Is this intended? It seems NEWLINE is not added beforehand for other fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205970312 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205969903 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205969334 PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205972334 From duke at openjdk.org Thu May 25 20:44:04 2023 From: duke at openjdk.org (zhurs) Date: Thu, 25 May 2023 20:44:04 GMT Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader Message-ID: When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size. If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full. ------------- Commit messages: - 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader Changes: https://git.openjdk.org/jdk/pull/14159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308144 Stats: 190 lines in 2 files changed: 188 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14159/head:pull/14159 PR: https://git.openjdk.org/jdk/pull/14159 From weijun at openjdk.org Thu May 25 20:51:55 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 25 May 2023 20:51:55 GMT Subject: RFR: 8297878: KEM: Implementation [v19] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/7cace182..b3982bdb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=17-18 Stats: 26 lines in 2 files changed: 14 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From weijun at openjdk.org Thu May 25 20:51:59 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 25 May 2023 20:51:59 GMT Subject: RFR: 8297878: KEM: Implementation [v18] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 17:07:40 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: > > - Merge branch 'master' into 8297878 > - Merge branch 'master' into 8297878 > - to and length and comments > - deterministic randomness > - Resolve Siba's comment > - providerName > - more @since and about nulls > - Merge branch 'master' into 8297878 > - no more pk/sk, AIOOBE to IOOBE > - small spec change > - ... and 8 more: https://git.openjdk.org/jdk/compare/288e6369...7cace182 New commit. Resolve Sean's comments. Make SecureRandom settable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13256#issuecomment-1563486984 From weijun at openjdk.org Thu May 25 20:52:02 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 25 May 2023 20:52:02 GMT Subject: RFR: 8297878: KEM: Implementation [v18] In-Reply-To: References: Message-ID: <4_pxCr3QWPRRMsPkicNfa1JsdKR93-l7Aonswz84cSA=.15631de8-465d-46b6-bd0e-a6ad67c1075f@github.com> On Thu, 25 May 2023 19:17:51 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: >> >> - Merge branch 'master' into 8297878 >> - Merge branch 'master' into 8297878 >> - to and length and comments >> - deterministic randomness >> - Resolve Siba's comment >> - providerName >> - more @since and about nulls >> - Merge branch 'master' into 8297878 >> - no more pk/sk, AIOOBE to IOOBE >> - small spec change >> - ... and 8 more: https://git.openjdk.org/jdk/compare/288e6369...7cace182 > > test/jdk/javax/crypto/KEM/RSA_KEM.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 8149417 > > bugid is wrong Oops, where did I copy it from? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1205987629 From mullan at openjdk.org Thu May 25 21:09:13 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 May 2023 21:09:13 GMT Subject: RFR: 8297878: KEM: Implementation [v19] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 20:51:55 GMT, Weijun Wang wrote: >> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > test update Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13256#pullrequestreview-1444650953 From valeriep at openjdk.org Thu May 25 21:33:12 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 May 2023 21:33:12 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 19:29:47 GMT, Martin Balao wrote: >> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement. >> >> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file): >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves. >> * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count). >> >> * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified) >> * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ... > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) > > Co-authored-by: Francisco Ferrari > Co-authored-by: Martin Balao src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2023, Oracle and/or its affiliates. All rights reserved. No changes in this file, should not update the year? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206022563 From mbalao at openjdk.org Thu May 25 21:39:10 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 25 May 2023 21:39:10 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 23:35:55 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 210: > >> 208: // because this is a PBE Mac service. In addition to checking >> 209: // the key, check that params (if passed) are consistent. >> 210: PBEUtil.checkKeyAndParams(key, params, algorithm); > > After this call, shouldn't you store key internally as p11Key? Not sure if this is being taken care of by the P11SecretKeyFactory.convertKey(...) call on line 248. The key is stored as in the internal field p11Key a bit later. The reason is because we need P11SecretKeyFactory::convertKey to check if the P11 key is from a different token and, eventually, re-derive it. The path taken is the same as for non-PBE Mac services. It's only in the PBE Mac case in which we had to derive the PBE key that we have absolute guarantees that calling P11SecretKeyFactory::convertKey would be useless, and we cut it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206027982 From dfuchs at openjdk.org Thu May 25 21:43:55 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 25 May 2023 21:43:55 GMT Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader In-Reply-To: References: Message-ID: On Thu, 25 May 2023 20:17:39 GMT, zhurs wrote: > When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size. > If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full. Hi, thanks a lot for the bug report and the fix. The fix looks reasonable, however the test fails quite consistently in our CI on many platform: java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1583) I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563538468 From duke at openjdk.org Thu May 25 22:10:55 2023 From: duke at openjdk.org (zhurs) Date: Thu, 25 May 2023 22:10:55 GMT Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader In-Reply-To: References: Message-ID: On Thu, 25 May 2023 21:40:41 GMT, Daniel Fuchs wrote: >> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size. >> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full. > > Hi, thanks a lot for the bug report and the fix. > > The fix looks reasonable, however the test fails quite consistently in our CI on many platform: > > > java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes > at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1583) > > > I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ? @dfuch, thanks for your lightning-fast reply. Indeed it relies on buffer sizes. The test works for me on Linux and Mac, but real life seems to be more diverse. Unfortunately, I don't know how else to reproduce the problem and test the fix - the tested logic is hidden deep. It may be possible to commit the fix without unit-test? The regression is not affected, and the behavior can be checked manually using the recipe from the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563562380 From mbalao at redhat.com Thu May 25 22:40:04 2023 From: mbalao at redhat.com (Martin Balao) Date: Thu, 25 May 2023 18:40:04 -0400 Subject: RFD: Services lockdown for security providers In-Reply-To: References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com> <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com> Message-ID: <841a0cf8-b0c4-f467-7910-0c30c6f73ecd@redhat.com> Hi Max, In this example, we want certificates validation from SUN but signature verification from SunPKCS11 (only). The problem with the current design is that there could be a signature algorithm implemented in SUN but not in SunPKCS11. If that is the case, there is no way to prevent SUN from verifying the signature: any order of security providers preference (i.e. SUN -> SunPKCS11 or SunPKCS11 -> SUN) would lead to SUN bringing the implementation. What we propose is a way to cherry-pick what we want (or what we don't) from each security provider in a configurable way. Regards, Martin.- On 5/24/23 18:30, Wei-Jun Wang wrote: > > >> On May 24, 2023, at 5:03 PM, Martin Balao wrote: >> >>>> To better illustrate, let's say that the user requires that all cryptographic operations are performed in a Hardware Security Module (HSM). On the OpenJDK side, this means that the implementation for Cipher, Signature, Mac and other cryptographic services must be the one in the SunPKCS11 security provider. Let's also suppose that other non-cryptographic services such as those for certificates validation and TLS are required, and their implementation is in the SUN and SunJSSE security providers respectively. Setting SunPKCS11 at the highest priority of the list is not a strong guarantee to ensure that all cryptographic operations come from it: it's possible that an algorithm for Signature is not implemented in SunPKCS11 or in its underlying token but in the SUN security provider. Disabling the SUN security provider wouldn't be an option in this case because we need its certificates validation service. > > You listed "Signature" as one of the "cryptographic services", but signature verification is also used in "certificates validation" which is a "non-cryptographic service". Do you mean signing must be in SunPKCS11 but verification needn't be? How do you configure that? > > Thanks, > Max > From cslucas at openjdk.org Thu May 25 22:54:15 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 25 May 2023 22:54:15 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v14] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Catching up with master branch. Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address PR review 6: refactoring around rematerialization & improve test cases. - Address PR review 5: refactor on rematerialization & add tests. - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Address part of PR review 4 & fix a bug setting only_candidate - Catching up with master Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Fix tests. Remember previous reducible Phis. - Address PR review 3. Some comments and be able to abort compilation. - Merge with Master - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. - ... and 5 more: https://git.openjdk.org/jdk/compare/46c4da7f...8f81a7c8 ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=13 Stats: 2760 lines in 25 files changed: 2508 ins; 113 del; 139 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From vlivanov at openjdk.org Thu May 25 22:54:15 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 May 2023 22:54:15 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v13] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Mon, 22 May 2023 17:56:41 GMT, Cesar Soares Lucas wrote: >> Are you sure there's no way to end up with nested ObjectMergeValues in presence of iterative EA? > I don't think so. Ok. Please, add asserts to catch such situation and a check which bails out compilation (triggering recompilation w/ ReduceAllocationMerges turned off) if it happens with product binaries. > So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled. Please, enhance `AllocationMergesTests` to cover deoptimization (e.g., using WhiteBox API or additional run w/ -XX:+DeoptimizeALot) and ensure that tests are sensitive enough to fail when wrong state is rematerialized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559847061 PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559852990 From weijun at openjdk.org Thu May 25 23:21:35 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 25 May 2023 23:21:35 GMT Subject: RFR: 8297878: KEM: Implementation [v20] In-Reply-To: References: Message-ID: > The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: comment for RSA-KEM ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13256/files - new: https://git.openjdk.org/jdk/pull/13256/files/b3982bdb..2c7ef3d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=18-19 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256 PR: https://git.openjdk.org/jdk/pull/13256 From mbalao at openjdk.org Thu May 25 23:29:09 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 25 May 2023 23:29:09 GMT Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v5] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 00:11:54 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3) >> >> Co-authored-by: Francisco Ferrari >> Co-authored-by: Martin Balao > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 112: > >> 110: return pbes2Params.getAlgorithmParameters( >> 111: blkSize, pbeAlg, P11Util.getSunJceProvider(), >> 112: JCAUtil.getSecureRandom()); > > The random source should be the one supplied through CipherSpi.engineInit(...) call if there is one available (see line 118). There is Cipher javadoc specifying this. Good point. As I see it, the problem is not in the random source itself but in the values. There are a couple of P11PBECipher::engineInit paths in which P11