From xuelei at openjdk.java.net Tue Mar 1 15:31:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Mar 2022 15:31:00 GMT Subject: RFR: 8282320: Remove case conversion for debugging log in SSLCipher In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:08:03 GMT, Xue-Lei Andrew Fan wrote: > String.toUpperCase() is used in SSLCipher.java for debugging logging, which is not necessary. See also comment in [this PR](https://github.com/openjdk/jdk/pull/7583). ping ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7600 From weijun at openjdk.java.net Tue Mar 1 16:09:12 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Mar 2022 16:09:12 GMT Subject: RFR: 8282320: Remove case conversion for debugging log in SSLCipher In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:08:03 GMT, Xue-Lei Andrew Fan wrote: > String.toUpperCase() is used in SSLCipher.java for debugging logging, which is not necessary. See also comment in [this PR](https://github.com/openjdk/jdk/pull/7583). Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7600 From xuelei at openjdk.java.net Tue Mar 1 18:14:09 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Mar 2022 18:14:09 GMT Subject: Integrated: 8282320: Remove case conversion for debugging log in SSLCipher In-Reply-To: References: Message-ID: <2D67-gsWIZzc8fAuhDyRSUCz6fIZ3fMJj9ZkDcnkBro=.929977a9-f8fa-43f6-8a23-0fdad845f9bd@github.com> On Wed, 23 Feb 2022 22:08:03 GMT, Xue-Lei Andrew Fan wrote: > String.toUpperCase() is used in SSLCipher.java for debugging logging, which is not necessary. See also comment in [this PR](https://github.com/openjdk/jdk/pull/7583). This pull request has now been integrated. Changeset: eac80214 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/eac80214aea4f5c148e859b4b163fe42e89596cd Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod 8282320: Remove case conversion for debugging log in SSLCipher Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/7600 From xuelei at openjdk.java.net Tue Mar 1 22:44:31 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Mar 2022 22:44:31 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template Message-ID: May I have this test update reviewed? The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398). It is not always easy to replace the certificates if the template has been used a lot. This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. I also did a few code clean up in this patch. ------------- Commit messages: - 8282511: Use fixed certificate validation date in SSLExampleCert template Changes: https://git.openjdk.java.net/jdk/pull/7651/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7651&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282511 Stats: 217 lines in 2 files changed: 35 ins; 2 del; 180 mod Patch: https://git.openjdk.java.net/jdk/pull/7651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7651/head:pull/7651 PR: https://git.openjdk.java.net/jdk/pull/7651 From rhalade at openjdk.java.net Tue Mar 1 23:01:03 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 1 Mar 2022 23:01:03 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 22:38:30 GMT, Xue-Lei Andrew Fan wrote: > May I have this test update reviewed? > > The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398). It is not always easy to replace the certificates if the template has been used a lot. > > This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. > > I also did a few code clean up in this patch. test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 26: > 24: /** > 25: * @test > 26: * @bug 8806542 8282511 No need to add a bug id here as this is test only change test/jdk/javax/net/ssl/templates/SSLExampleCert.java line 373: > 371: // Set the date for the verifying of certificates. > 372: @SuppressWarnings("deprecation") > 373: Date verifyingDate = new Date(123, 3, 3); can DateFormat be used instead to parse Date from a readable string representation? ------------- PR: https://git.openjdk.java.net/jdk/pull/7651 From xuelei at openjdk.java.net Tue Mar 1 23:23:53 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Mar 2022 23:23:53 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v2] In-Reply-To: References: Message-ID: > May I have this test update reviewed? > > The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not always easy to replace the certificates if the template has been used a lot. > > This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. > > I also did a few code clean up in this patch. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Chaneg to use DateFormat ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7651/files - new: https://git.openjdk.java.net/jdk/pull/7651/files/2352eea5..64c60b39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7651&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7651&range=00-01 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7651/head:pull/7651 PR: https://git.openjdk.java.net/jdk/pull/7651 From xuelei at openjdk.java.net Tue Mar 1 23:23:54 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Mar 2022 23:23:54 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v2] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 22:56:54 GMT, Rajan Halade wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Chaneg to use DateFormat > > test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 26: > >> 24: /** >> 25: * @test >> 26: * @bug 8806542 8282511 > > No need to add a bug id here as this is test only change Yep. > test/jdk/javax/net/ssl/templates/SSLExampleCert.java line 373: > >> 371: // Set the date for the verifying of certificates. >> 372: @SuppressWarnings("deprecation") >> 373: Date verifyingDate = new Date(123, 3, 3); > > can DateFormat be used instead to parse Date from a readable string representation? Good catch! Updated in the last commit. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/7651 From rhalade at openjdk.java.net Tue Mar 1 23:29:05 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 1 Mar 2022 23:29:05 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v2] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 23:23:53 GMT, Xue-Lei Andrew Fan wrote: >> May I have this test update reviewed? >> >> The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not always easy to replace the certificates if the template has been used a lot. >> >> This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. >> >> I also did a few code clean up in this patch. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Chaneg to use DateFormat test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 26: > 24: /** > 25: * @test > 26: * @bug 8806542 Missed to note earlier. 8806542 is not a valid bug number. It was updated to 8065422 so this change is not needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7651 From valeriep at openjdk.java.net Wed Mar 2 00:21:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 00:21:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA Message-ID: It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: - SHA-384 for secure hashing - AES-256 for symmetric encryption - RSA with 3072 bit keys for digital signatures and for key exchange - Diffie Hellman (DH) with 3072 bit keys for key exchange - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? Thanks! ------------- Commit messages: - 8267319: Use larger default key sizes and algorithms based on CNSA Changes: https://git.openjdk.java.net/jdk/pull/7652/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267319 Stats: 479 lines in 29 files changed: 321 ins; 6 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From ascarpino at openjdk.java.net Wed Mar 2 04:06:00 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Mar 2022 04:06:00 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From aturbanov at openjdk.java.net Wed Mar 2 08:44:31 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 2 Mar 2022 08:44:31 GMT Subject: RFR: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit Message-ID: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit ------------- Commit messages: - [PATCH] Remove redundant null check in ChaCha20Cipher.engineInit Changes: https://git.openjdk.java.net/jdk/pull/7424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282534 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7424/head:pull/7424 PR: https://git.openjdk.java.net/jdk/pull/7424 From duke at openjdk.java.net Wed Mar 2 08:44:32 2022 From: duke at openjdk.java.net (TheShermanTanker) Date: Wed, 2 Mar 2022 08:44:32 GMT Subject: RFR: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 13:20:34 GMT, Andrey Turbanov wrote: > 8282534: Remove redundant null check in ChaCha20Cipher.engineInit @turbanoff I've created an entry for you in the tracker, for your PR to be marked as ready for review please rename your PR title to 8282534 and the rest should be taken care of automatically (Do give it some time though) ------------- PR: https://git.openjdk.java.net/jdk/pull/7424 From duke at openjdk.java.net Wed Mar 2 11:56:22 2022 From: duke at openjdk.java.net (zzambers) Date: Wed, 2 Mar 2022 11:56:22 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket Message-ID: Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. [1] https://bugs.openjdk.java.net/browse/JDK-8208526 [2] https://bugs.openjdk.java.net/browse/JDK-8216326 ------------- Commit messages: - javax/net/ssl/SSLSocket: Fixed API Note in javadoc Changes: https://git.openjdk.java.net/jdk/pull/7648/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282529 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648 PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Wed Mar 2 11:56:23 2022 From: duke at openjdk.java.net (TheShermanTanker) Date: Wed, 2 Mar 2022 11:56:23 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: References: Message-ID: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com> On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 @zzambers I've created a corresponding issue for you in the tracker, please rename your PR title to 8282529 and the system should automatically mark your PR as ready for review ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Wed Mar 2 11:56:24 2022 From: duke at openjdk.java.net (zzambers) Date: Wed, 2 Mar 2022 11:56:24 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com> References: <_gpOcV6YIojpPWSY8v-Mn5SEdc1UfcNnpuG7_3FfYkU=.5c46ccc4-b9b5-43c2-9e2d-6b92559bea00@github.com> Message-ID: <1dy03NNttstKhBtGII_CDhF3h4T0zls0dhTl2S9Wbq8=.63d2ff0b-85d0-4f9a-b6ec-4533e983014a@github.com> On Wed, 2 Mar 2022 07:13:36 GMT, TheShermanTanker wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216326 > > @zzambers I've created a corresponding issue for you in the tracker, please rename your PR title to 8282529 and the system should automatically mark your PR as ready for review @TheShermanTanker thank you ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From mullan at openjdk.java.net Wed Mar 2 12:04:03 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 2 Mar 2022 12:04:03 GMT Subject: RFR: 8281234: The -protected option is not always checked in keytool and jarsigner [v2] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 01:19:51 GMT, Weijun Wang wrote: >> The option means there is no need to provide a password when loading a keystore. In some places in jarsigner and keytool, even with the option specified, password is still prompted for or warnings are still shown. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > only expand system property if it has a name Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7339 From omikhaltcova at openjdk.java.net Wed Mar 2 12:11:22 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 2 Mar 2022 12:11:22 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 Message-ID: I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. ------------- Commit messages: - 8282538: PKCS11 tests fail on CentOS Stream 9 Changes: https://git.openjdk.java.net/jdk/pull/7658/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7658&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282538 Stats: 0 lines in 2 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7658.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7658/head:pull/7658 PR: https://git.openjdk.java.net/jdk/pull/7658 From weijun at openjdk.java.net Wed Mar 2 14:11:09 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 14:11:09 GMT Subject: Integrated: 8281234: The -protected option is not always checked in keytool and jarsigner In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 18:23:55 GMT, Weijun Wang wrote: > The option means there is no need to provide a password when loading a keystore. In some places in jarsigner and keytool, even with the option specified, password is still prompted for or warnings are still shown. This pull request has now been integrated. Changeset: fc918a73 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/fc918a73d0dcc28146e60f15e978209424a32576 Stats: 198 lines in 4 files changed: 194 ins; 0 del; 4 mod 8281234: The -protected option is not always checked in keytool and jarsigner Reviewed-by: hchao, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7339 From xuelei at openjdk.java.net Wed Mar 2 15:19:01 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Mar 2022 15:19:01 GMT Subject: RFR: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 13:20:34 GMT, Andrey Turbanov wrote: > 8282534: Remove redundant null check in ChaCha20Cipher.engineInit Looks good to me. Please add a noreg-clean label in [JDK-8282534](https://bugs.openjdk.java.net/browse/JDK-8282534). ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7424 From xuelei at openjdk.java.net Wed Mar 2 15:31:08 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Mar 2022 15:31:08 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 Thank you for the nice catch. The update looks good to me. A CSR may be required for spec change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From mullan at openjdk.java.net Wed Mar 2 15:47:01 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 2 Mar 2022 15:47:01 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. Marked as reviewed by mullan (Reviewer). src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 33: > 31: import java.security.cert.CertPathValidatorException; > 32: import java.security.cert.PKIXBuilderParameters; > 33: import java.security.spec.PSSParameterSpec; I don't think you need this import, as this class does not seem to be referenced anywhere. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Wed Mar 2 16:24:04 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 16:24:04 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1414: > 1412: } catch (CertPathValidatorException e) { > 1413: disabledAlgFound = true; > 1414: return String.format(rb.getString("with.disabled"), algParams); The return value should still be the algorithm name with an optional "weak" (or "disabled") tag, something like "RSASSA-PSS (weak)". However, the updated code is now returning the string format of `algParams`, which will be "PSSParameter... (weak)". I'm not sure how to fix this nicely. Certainly you want to show the user why it is weak so the weak part should be displayed. A verbose solution could be "RSSSSA-PSS using PSSParameterSpec(SHA-256) (weak)". Hopefully the `toString()` output of `PSSParameterSpec` is not too ugly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Wed Mar 2 16:31:05 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 16:31:05 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. The return values of the 2 updated `verifyWithWeak` methods need to be fixed. ------------- Changes requested by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Wed Mar 2 16:54:00 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 16:54:00 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1438: > 1436: try { > 1437: LEGACY_CHECK.permits(algParams, jcp); > 1438: return alg; No need to return here since it will be returned on line 1445 anyway. test/jdk/sun/security/tools/jarsigner/CheckAlgParams.java line 30: > 28: * its signature algorithm use disabled or legacy algorithms > 29: * @library /test/lib > 30: * @modules java.base/sun.security.x509 Is this `@modules` line useful? ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Wed Mar 2 17:45:56 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 2 Mar 2022 17:45:56 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2] In-Reply-To: References: Message-ID: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Removed unneeded import and updated -verbose output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7582/files - new: https://git.openjdk.java.net/jdk/pull/7582/files/70da21b4..9ffda802 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=00-01 Stats: 13 lines in 2 files changed: 6 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7582/head:pull/7582 PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Wed Mar 2 17:45:57 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 2 Mar 2022 17:45:57 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 15:30:22 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unneeded import and updated -verbose output > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 33: > >> 31: import java.security.cert.CertPathValidatorException; >> 32: import java.security.cert.PKIXBuilderParameters; >> 33: import java.security.spec.PSSParameterSpec; > > I don't think you need this import, as this class does not seem to be referenced anywhere. Removed. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Wed Mar 2 17:50:07 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 2 Mar 2022 17:50:07 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 16:20:53 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unneeded import and updated -verbose output > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1414: > >> 1412: } catch (CertPathValidatorException e) { >> 1413: disabledAlgFound = true; >> 1414: return String.format(rb.getString("with.disabled"), algParams); > > The return value of this method will be shown as the "Signature algorithm" in the output. It's OK to include an optional "weak" (or "disabled") tag, but the core part still must be an algorithm name. Here, the updated code returns the string format of `algParams`, which is not an algorithm name. > > I'm not sure how to fix this nicely. Certainly you want to show the user why it is weak so the weak part should be displayed. A verbose solution could be "RSSSSA-PSS using PSSParameterSpec(...SHA-1...) (weak)", but the `toString()` output of `PSSParameterSpec` is quite long. > > Same comment to the code change below. I add "RSSSSA-PSS using ? to the `-verbose` output as suggested, and keep the remaining output as the parameters for the RSASSA-PSS contain hashAlgorithm and maskGenAlgorithm that could be disabled or weak. At the same time, strip off the saltLength and trailerField display. > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1438: > >> 1436: try { >> 1437: LEGACY_CHECK.permits(algParams, jcp); >> 1438: return alg; > > No need to return here since it will be returned on line 1445 anyway. Removed. > test/jdk/sun/security/tools/jarsigner/CheckAlgParams.java line 30: > >> 28: * its signature algorithm use disabled or legacy algorithms >> 29: * @library /test/lib >> 30: * @modules java.base/sun.security.x509 > > Is this `@modules` line useful? No, removed it. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Wed Mar 2 18:04:06 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 18:04:06 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2] In-Reply-To: References: Message-ID: <9G07r8rmEiUCl3m83t9mIbkSuDVtDMlkyXkNHlYGRuo=.452b02a4-e1f6-47ec-a9bf-fc9fbf5886bb@github.com> On Wed, 2 Mar 2022 17:46:26 GMT, Hai-May Chao wrote: >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1414: >> >>> 1412: } catch (CertPathValidatorException e) { >>> 1413: disabledAlgFound = true; >>> 1414: return String.format(rb.getString("with.disabled"), algParams); >> >> The return value of this method will be shown as the "Signature algorithm" in the output. It's OK to include an optional "weak" (or "disabled") tag, but the core part still must be an algorithm name. Here, the updated code returns the string format of `algParams`, which is not an algorithm name. >> >> I'm not sure how to fix this nicely. Certainly you want to show the user why it is weak so the weak part should be displayed. A verbose solution could be "RSSSSA-PSS using PSSParameterSpec(...SHA-1...) (weak)", but the `toString()` output of `PSSParameterSpec` is quite long. >> >> Same comment to the code change below. > > I add "RSSSSA-PSS using ? to the `-verbose` output as suggested, and keep the remaining output as the parameters for the RSASSA-PSS contain hashAlgorithm and maskGenAlgorithm that could be disabled or weak. At the same time, strip off the saltLength and trailerField display. What does it look like now? Also, you might need to create a mapping in `Resources.java` because "using" should only be shown when system language is English. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Wed Mar 2 19:57:05 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 19:57:05 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2] In-Reply-To: <9G07r8rmEiUCl3m83t9mIbkSuDVtDMlkyXkNHlYGRuo=.452b02a4-e1f6-47ec-a9bf-fc9fbf5886bb@github.com> References: <9G07r8rmEiUCl3m83t9mIbkSuDVtDMlkyXkNHlYGRuo=.452b02a4-e1f6-47ec-a9bf-fc9fbf5886bb@github.com> Message-ID: On Wed, 2 Mar 2022 18:01:04 GMT, Weijun Wang wrote: >> I add "RSSSSA-PSS using ? to the `-verbose` output as suggested, and keep the remaining output as the parameters for the RSASSA-PSS contain hashAlgorithm and maskGenAlgorithm that could be disabled or weak. At the same time, strip off the saltLength and trailerField display. > > What does it look like now? Also, you might need to create a mapping in `Resources.java` because "using" should only be shown when system language is English. Also, what if it's another algorithm using another type of parameters? You cannot hardcode "RSASSA-PSS" and take it for granted that there is a "]" inside the string format of the parameter and it's the end of the weak part. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Wed Mar 2 21:38:26 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 21:38:26 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting Message-ID: The comment said "pad it w/ leading 0s". So let's pad it. ------------- Commit messages: - remove x bits - 8281628: KeyAgreement : generateSecret intermittently not resetting Changes: https://git.openjdk.java.net/jdk/pull/7665/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7665&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281628 Stats: 75 lines in 2 files changed: 74 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7665.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7665/head:pull/7665 PR: https://git.openjdk.java.net/jdk/pull/7665 From valeriep at openjdk.java.net Wed Mar 2 22:01:13 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 22:01:13 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:35:50 GMT, Weijun Wang wrote: > The comment said "pad it w/ leading 0s". So let's pad it. src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 347: > 345: // Array too short, pad it w/ leading 0s > 346: if (secret.length < expectedLen) { > 347: Arrays.fill(sharedSecret, offset, offset + (expectedLen - secret.length), (byte)0); nit: longer than 80 chars? test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line 28: > 26: * @bug 8281628 > 27: * @library /test/lib > 28: * @summary KeyAgreement : generateSecret intermittently not resetting nit: describe the fix instead of just using the bug synopsis. test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line 56: > 54: // Different stale data > 55: aliceSecret[0] = 0; > 56: bobSecret[0] = 1; Instead of only the first byte difference, would it be easier to trigger the bug with completely different buffer value, say FFFFFF vs 000000? ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From valeriep at openjdk.java.net Wed Mar 2 22:30:07 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 22:30:07 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 04:02:45 GMT, Anthony Scarpino wrote: > I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. Well, I am not sure how specifying a 32-byte SecretKeySpec (instance of a SecretKey) with AES Cipher would trigger AES_128_GCM op? Shouldn't the keysize be detected when Cipher.init() is called and then invoking the right op? True that this default key size change would impact callers who do not specify key size but then made the assumption of key being 16-byte. Well, the key generator javadoc did warn about not setting a default, i.e. different providers may have different default key size and that the default key size may change later for the same provider. So, it's not like we have not warned about it... ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From weijun at openjdk.java.net Wed Mar 2 22:30:07 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 22:30:07 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 21:47:06 GMT, Valerie Peng wrote: >> The comment said "pad it w/ leading 0s". So let's pad it. > > src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 347: > >> 345: // Array too short, pad it w/ leading 0s >> 346: if (secret.length < expectedLen) { >> 347: Arrays.fill(sharedSecret, offset, offset + (expectedLen - secret.length), (byte)0); > > nit: longer than 80 chars? I'll wrap it. > test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line 28: > >> 26: * @bug 8281628 >> 27: * @library /test/lib >> 28: * @summary KeyAgreement : generateSecret intermittently not resetting > > nit: describe the fix instead of just using the bug synopsis. OK. > test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line 56: > >> 54: // Different stale data >> 55: aliceSecret[0] = 0; >> 56: bobSecret[0] = 1; > > Instead of only the first byte difference, would it be easier to trigger the bug with completely different buffer value, say FFFFFF vs 000000? Maybe not. When the generated secret is shorter, the padded bytes are always at the beginning. ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From weijun at openjdk.java.net Wed Mar 2 22:36:49 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 22:36:49 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2] In-Reply-To: References: Message-ID: > The comment said "pad it w/ leading 0s". So let's pad it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: wrap and comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7665/files - new: https://git.openjdk.java.net/jdk/pull/7665/files/92ada682..68dc51e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7665&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7665&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7665.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7665/head:pull/7665 PR: https://git.openjdk.java.net/jdk/pull/7665 From valeriep at openjdk.java.net Wed Mar 2 22:36:50 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 22:36:50 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2] In-Reply-To: References: Message-ID: <6gXB8Ls3FhDaF07hpUTFUGt68hr1abRlyJzd_0q_hpQ=.40330548-787c-4b24-bd00-32773b981faf@github.com> On Wed, 2 Mar 2022 22:26:45 GMT, Weijun Wang wrote: >> test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line 56: >> >>> 54: // Different stale data >>> 55: aliceSecret[0] = 0; >>> 56: bobSecret[0] = 1; >> >> Instead of only the first byte difference, would it be easier to trigger the bug with completely different buffer value, say FFFFFF vs 000000? > > Maybe not. When the generated secret is shorter, the padded bytes are always at the beginning. With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect a difference and higher reproducibility... ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From weijun at openjdk.java.net Wed Mar 2 22:52:04 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 22:52:04 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2] In-Reply-To: <6gXB8Ls3FhDaF07hpUTFUGt68hr1abRlyJzd_0q_hpQ=.40330548-787c-4b24-bd00-32773b981faf@github.com> References: <6gXB8Ls3FhDaF07hpUTFUGt68hr1abRlyJzd_0q_hpQ=.40330548-787c-4b24-bd00-32773b981faf@github.com> Message-ID: On Wed, 2 Mar 2022 22:31:02 GMT, Valerie Peng wrote: >> Maybe not. When the generated secret is shorter, the padded bytes are always at the beginning. > > With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect a difference and higher reproducibility... After `n = generateSecret(secret, offset)` is called, only `n` bytes from `offset` should be touched, and in this case `n` is 64. Even if you allocate 80 bytes of data, we should not compare those after the 64th byte. ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From weijun at openjdk.java.net Wed Mar 2 23:03:44 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 23:03:44 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3] In-Reply-To: References: Message-ID: > The comment said "pad it w/ leading 0s". So let's pad it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: check length as well ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7665/files - new: https://git.openjdk.java.net/jdk/pull/7665/files/68dc51e2..5fb67074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7665&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7665&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7665.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7665/head:pull/7665 PR: https://git.openjdk.java.net/jdk/pull/7665 From weijun at openjdk.java.net Wed Mar 2 23:03:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Mar 2022 23:03:45 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3] In-Reply-To: References: <6gXB8Ls3FhDaF07hpUTFUGt68hr1abRlyJzd_0q_hpQ=.40330548-787c-4b24-bd00-32773b981faf@github.com> Message-ID: On Wed, 2 Mar 2022 22:48:36 GMT, Weijun Wang wrote: >> With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect a difference and higher reproducibility... > > After `n = generateSecret(secret, offset)` is called, only `n` bytes from `offset` should be touched, and in this case `n` is 64. Even if you allocate 80 bytes of data, we should not compare those after the 64th byte. But you remind me I should take it for granted that the return value is always 64 and it should be checked as well. A new commit pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From valeriep at openjdk.java.net Wed Mar 2 23:37:05 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 23:37:05 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 23:03:44 GMT, Weijun Wang wrote: >> The comment said "pad it w/ leading 0s". So let's pad it. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > check length as well Changes look good. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7665 From valeriep at openjdk.java.net Wed Mar 2 23:37:06 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 23:37:06 GMT Subject: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3] In-Reply-To: References: <6gXB8Ls3FhDaF07hpUTFUGt68hr1abRlyJzd_0q_hpQ=.40330548-787c-4b24-bd00-32773b981faf@github.com> Message-ID: <1PswEm2Uq0eKkoblJGCcW65rSJxpTAwcg4G0BrXG_KE=.8e584523-3c33-4bd6-b1aa-7b58ede2a58f@github.com> On Wed, 2 Mar 2022 23:00:02 GMT, Weijun Wang wrote: >> After `n = generateSecret(secret, offset)` is called, only `n` bytes from `offset` should be touched, and in this case `n` is 64. Even if you allocate 80 bytes of data, we should not compare those after the 64th byte. > > But you remind me I should take it for granted that the return value is always 64 and it should be checked as well. A new commit pushed. Hmm, I see, I confused the actual length with the buffer length. In the case where the generated bytes are shorter, the difference is only one byte, so setting other bytes do not matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From wetmore at openjdk.java.net Wed Mar 2 23:40:04 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 2 Mar 2022 23:40:04 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 Please update the copyright to include 2022. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From wetmore at openjdk.java.net Thu Mar 3 00:28:06 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 3 Mar 2022 00:28:06 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: References: Message-ID: <9rSTeWIbQhJoNbsw_h5Gf3_CkoPp1Mwu6lSFlNcJwik=.f37c22cc-55ef-4b54-b2e2-1c35aaa28642@github.com> On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 Please also update JDK-8282529 to include the description (i.e. above). IMHO, the bug should contain the information for the issue, rather than need to navigate 2 steps to the pull request. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From weijun at openjdk.java.net Thu Mar 3 00:43:08 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 3 Mar 2022 00:43:08 GMT Subject: Integrated: 8281628: KeyAgreement : generateSecret intermittently not resetting In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:35:50 GMT, Weijun Wang wrote: > The comment said "pad it w/ leading 0s". So let's pad it. This pull request has now been integrated. Changeset: 1485883c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/1485883c9e6e24315bb21f20604b1c326e862a5b Stats: 77 lines in 2 files changed: 76 ins; 0 del; 1 mod 8281628: KeyAgreement : generateSecret intermittently not resetting Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/7665 From bradford.wetmore at oracle.com Thu Mar 3 01:14:48 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 2 Mar 2022 17:14:48 -0800 Subject: Recent SSLSocket close() @apiNote Changes. Message-ID: <71796164-b59a-011f-c1ef-760182c396bf@oracle.com> Hi Xuelei, I am working on some close code including the recent PR[1] for: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket and ran into a change I hadn't noticed before. * @apiNote * When the connection is no longer needed, the client and server * applications should each close both sides of their respective connection. * For {@code SSLSocket} objects, for example, an application can call * {@link Socket#shutdownOutput()} for output stream close and call * {@link Socket#shutdownInput()} for input stream close. It used to be that just a single SSLSocket.close() was sufficient to completely shutdown the SSLSocket, and under the hood it closed the output/input in the right order. I believe this code still closes everything as before, but the updated @apiNote encourages the user to do a three-part shutdown instead. socket.shutdownOutput(); socket.shutdownInput(); socket.close(); // mostly repeats of above. This approach seems unnecessary unless the user is interested in the TLSv1.3 half-close mode. What is the rationale for recommending this way of doing closes in general? Or does this @apiNote need another iteration? Thanks, Brad [1] https://github.com/openjdk/jdk/pull/7648 From hchao at openjdk.java.net Thu Mar 3 01:40:39 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 01:40:39 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v3] In-Reply-To: References: Message-ID: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision: - Updated -verbose output - Updated -verbose output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7582/files - new: https://git.openjdk.java.net/jdk/pull/7582/files/9ffda802..516d8bf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=01-02 Stats: 20 lines in 2 files changed: 12 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7582/head:pull/7582 PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Thu Mar 3 01:40:40 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 01:40:40 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v3] In-Reply-To: References: <9G07r8rmEiUCl3m83t9mIbkSuDVtDMlkyXkNHlYGRuo=.452b02a4-e1f6-47ec-a9bf-fc9fbf5886bb@github.com> Message-ID: <8ZGUIHBiYXTjgJ8s5G_foFuTCfOq-f9esOinqcndjKY=.76531085-af4d-4c52-9bb2-40d1e63c628e@github.com> On Wed, 2 Mar 2022 19:54:13 GMT, Weijun Wang wrote: >> What does it look like now? Also, you might need to create a mapping in `Resources.java` because "using" should only be shown when system language is English. > > Also, what if it's another algorithm using another type of parameters? You cannot hardcode "RSASSA-PSS" and take it for granted that there is a "]" inside the string format of the parameter and it's the end of the weak part. Made change to add "RSASSA-PSS using? before its parameter output when the signature algorithm is RSASSA-PSS. Also, keep the parameter string without doing further parsing and stripping off based on the "]". ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Thu Mar 3 07:24:49 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 07:24:49 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v4] In-Reply-To: References: Message-ID: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Removed unused string ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7582/files - new: https://git.openjdk.java.net/jdk/pull/7582/files/516d8bf0..2a73d1ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7582/head:pull/7582 PR: https://git.openjdk.java.net/jdk/pull/7582 From xueleifan at tencent.com Thu Mar 3 07:46:09 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Thu, 3 Mar 2022 07:46:09 +0000 Subject: [Internet]Recent SSLSocket close() @apiNote Changes. In-Reply-To: <71796164-b59a-011f-c1ef-760182c396bf@oracle.com> References: <71796164-b59a-011f-c1ef-760182c396bf@oracle.com> Message-ID: Hi Brad, I think you are right that this design is actually for TLSv1.3 half-close mode. For TLS 1.3, there is no duplex closure design. The close() implementation in JDK is actually a workaround for compatibility. Application can use either the half-close mode socket.shutdownOutput(); socket.shutdownInput(); or duplex close mode for compatibilty: socket.close(); Unfortunately, in practice the half-close and duplex close are mixed with three lines: socket.shutdownOutput(); socket.shutdownInput(); socket.close(); It was not something I expected when I designed the spec for half-close mode. It should be helpful if having another iteration for the @apiNote. Thanks, Xuelei > On Mar 2, 2022, at 5:14 PM, Bradford Wetmore wrote: > > > Hi Xuelei, > > I am working on some close code including the recent PR[1] for: > > 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket > > and ran into a change I hadn't noticed before. > > * @apiNote > * When the connection is no longer needed, the client and server > * applications should each close both sides of their respective connection. > * For {@code SSLSocket} objects, for example, an application can call > * {@link Socket#shutdownOutput()} for output stream close and call > * {@link Socket#shutdownInput()} for input stream close. > > It used to be that just a single SSLSocket.close() was sufficient to completely shutdown the SSLSocket, and under the hood it closed the output/input in the right order. > > I believe this code still closes everything as before, but the updated @apiNote encourages the user to do a three-part shutdown instead. > > socket.shutdownOutput(); > socket.shutdownInput(); > socket.close(); // mostly repeats of above. > > This approach seems unnecessary unless the user is interested in the TLSv1.3 half-close mode. > > What is the rationale for recommending this way of doing closes in general? Or does this @apiNote need another iteration? > > Thanks, > > Brad > > [1] https://github.com/openjdk/jdk/pull/7648 > From jwaters at openjdk.java.net Thu Mar 3 08:16:02 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Thu, 3 Mar 2022 08:16:02 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 JDK-8282529 has been updated accordingly ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Thu Mar 3 11:21:16 2022 From: duke at openjdk.java.net (zzambers) Date: Thu, 3 Mar 2022 11:21:16 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary Message-ID: When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) I also ran jdk_security tests locally, which passed for me. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 ------------- Commit messages: - SSLSocketImpl: Do not use user_canceled workaround if the other side has already half-closed the connection. Changes: https://git.openjdk.java.net/jdk/pull/7664/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7664&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282600 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7664.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7664/head:pull/7664 PR: https://git.openjdk.java.net/jdk/pull/7664 From sgehwolf at openjdk.java.net Thu Mar 3 11:21:16 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 3 Mar 2022 11:21:16 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 @zzambers I've create https://bugs.openjdk.java.net/browse/JDK-8282600 for this issue. Please reference it in the PR title. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From duke at openjdk.java.net Thu Mar 3 11:26:00 2022 From: duke at openjdk.java.net (zzambers) Date: Thu, 3 Mar 2022 11:26:00 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 10:45:02 GMT, Severin Gehwolf wrote: >> When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) >> >> As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) >> >> This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) >> >> I also ran jdk_security tests locally, which passed for me. >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 >> [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 >> [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 > > @zzambers I've create https://bugs.openjdk.java.net/browse/JDK-8282600 for this issue. Please reference it in the PR title. @jerboaa thank you ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From duke at openjdk.java.net Thu Mar 3 12:36:33 2022 From: duke at openjdk.java.net (zzambers) Date: Thu, 3 Mar 2022 12:36:33 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 zzambers has updated the pull request incrementally with one additional commit since the last revision: Updated copyright for SSLSocket.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7648/files - new: https://git.openjdk.java.net/jdk/pull/7648/files/ff33d3f6..7fe494ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648 PR: https://git.openjdk.java.net/jdk/pull/7648 From xuelei at openjdk.java.net Thu Mar 3 15:43:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 3 Mar 2022 15:43:58 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 It looks like a nice change to me. Thank you! Did you want to add a test? Otherwise, please add a noreg- label in the bug JDK-8282600. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7664 From xuelei at openjdk.java.net Thu Mar 3 16:31:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 3 Mar 2022 16:31:41 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v3] In-Reply-To: References: Message-ID: > May I have this test update reviewed? > > The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not always easy to replace the certificates if the template has been used a lot. > > This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. > > I also did a few code clean up in this patch. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: typo introduced in bug ID ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7651/files - new: https://git.openjdk.java.net/jdk/pull/7651/files/64c60b39..1099e4be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7651&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7651&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7651/head:pull/7651 PR: https://git.openjdk.java.net/jdk/pull/7651 From xuelei at openjdk.java.net Thu Mar 3 16:31:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 3 Mar 2022 16:31:43 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v2] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 23:25:52 GMT, Rajan Halade wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Chaneg to use DateFormat > > test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 26: > >> 24: /** >> 25: * @test >> 26: * @bug 8806542 > > Missed to note earlier. 8806542 is not a valid bug number. It was updated to 8065422 so this change is not needed. Oops, definitely not an expected update. Thank you for the nice catch. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7651 From rhalade at openjdk.java.net Thu Mar 3 16:50:07 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 3 Mar 2022 16:50:07 GMT Subject: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v3] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 16:31:41 GMT, Xue-Lei Andrew Fan wrote: >> May I have this test update reviewed? >> >> The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not always easy to replace the certificates if the template has been used a lot. >> >> This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. >> >> I also did a few code clean up in this patch. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo introduced in bug ID Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7651 From duke at openjdk.java.net Thu Mar 3 16:53:05 2022 From: duke at openjdk.java.net (zzambers) Date: Thu, 3 Mar 2022 16:53:05 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 15:40:31 GMT, Xue-Lei Andrew Fan wrote: >> When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) >> >> As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) >> >> This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) >> >> I also ran jdk_security tests locally, which passed for me. >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 >> [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 >> [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 > > Did you want to add a test? Otherwise, please add a noreg- label in the bug JDK-8282600. @XueleiFan thank you for review. I have added noreg-external tag and some explanation to Openjdk bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From xuelei at openjdk.java.net Thu Mar 3 19:24:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 3 Mar 2022 19:24:07 GMT Subject: Integrated: 8282511: Use fixed certificate validation date in SSLExampleCert template In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 22:38:30 GMT, Xue-Lei Andrew Fan wrote: > May I have this test update reviewed? > > The certificates used in SSL testing template SSLExampleCert could expired in the future (for example [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not always easy to replace the certificates if the template has been used a lot. > > This update is trying to use a fixed validation date, so that even the certificates are expired the test will continue to work with no surprises. > > I also did a few code clean up in this patch. This pull request has now been integrated. Changeset: 268fa693 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/268fa693188b685de6289927ee5a1e99473a50f6 Stats: 218 lines in 2 files changed: 37 ins; 2 del; 179 mod 8282511: Use fixed certificate validation date in SSLExampleCert template Reviewed-by: rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/7651 From weijun at openjdk.java.net Thu Mar 3 19:43:08 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 3 Mar 2022 19:43:08 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v4] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 07:24:49 GMT, Hai-May Chao wrote: >> This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused string src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1418: > 1416: "RSASSA-PSS", algParams); > 1417: default: > 1418: return String.format(rb.getString("with.disabled"), algParams); There is no need to differentiate RSASSA-PSS and other algorithms. Just use the exact same format as you defined in `Resources.java`. This makes sure if one day another type of algorithm parameters fail the check, we will see the algorithm name and full description of the parameters as well. If the description is not clear, it's the problem of its `toString()` implementation. src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1452: > 1450: default: > 1451: return String.format(rb.getString("with.weak"), algParams); > 1452: } Same as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From ascarpino at openjdk.java.net Thu Mar 3 20:14:02 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 3 Mar 2022 20:14:02 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Fair point that the keysize would determine the algorithm used and the default key sizes for keygen. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From aturbanov at openjdk.java.net Thu Mar 3 20:31:36 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 3 Mar 2022 20:31:36 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss Message-ID: Pass cause exception as constructor parameter is shorter and easier to read. ------------- Commit messages: - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss Changes: https://git.openjdk.java.net/jdk/pull/7682/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7682&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282632 Stats: 22 lines in 3 files changed: 0 ins; 13 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7682.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7682/head:pull/7682 PR: https://git.openjdk.java.net/jdk/pull/7682 From hchao at openjdk.java.net Thu Mar 3 21:12:47 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 21:12:47 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v5] In-Reply-To: References: Message-ID: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Use algname in output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7582/files - new: https://git.openjdk.java.net/jdk/pull/7582/files/2a73d1ef..d2cd7ef8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=03-04 Stats: 14 lines in 1 file changed: 0 ins; 8 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7582/head:pull/7582 PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Thu Mar 3 21:12:49 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 21:12:49 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v4] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 19:35:21 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unused string > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1418: > >> 1416: "RSASSA-PSS", algParams); >> 1417: default: >> 1418: return String.format(rb.getString("with.disabled"), algParams); > > There is no need to differentiate RSASSA-PSS and other algorithms. Just use the exact same format as you defined in `Resources.java`. This makes sure if one day another type of algorithm parameters fail the check, we will see the algorithm name and full description of the parameters as well. If the description is not clear, it's the problem of its `toString()` implementation. Removed code that differentiates. ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Thu Mar 3 22:18:53 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 22:18:53 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v6] In-Reply-To: References: Message-ID: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: No need to do toUpperCase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7582/files - new: https://git.openjdk.java.net/jdk/pull/7582/files/d2cd7ef8..74dc7040 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7582&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7582/head:pull/7582 PR: https://git.openjdk.java.net/jdk/pull/7582 From weijun at openjdk.java.net Thu Mar 3 22:58:02 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 3 Mar 2022 22:58:02 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v6] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 22:18:53 GMT, Hai-May Chao wrote: >> This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > No need to do toUpperCase Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From hchao at openjdk.java.net Thu Mar 3 23:05:10 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 3 Mar 2022 23:05:10 GMT Subject: Integrated: 8277474: jarsigner does not check if algorithm parameters are disabled In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. This pull request has now been integrated. Changeset: fb6b929e Author: Hai-May Chao URL: https://git.openjdk.java.net/jdk/commit/fb6b929e6e935baeccfd03a7fbc048cc8b531ce5 Stats: 121 lines in 4 files changed: 112 ins; 1 del; 8 mod 8277474: jarsigner does not check if algorithm parameters are disabled Reviewed-by: mullan, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/7582 From duke at openjdk.java.net Fri Mar 4 11:28:03 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 4 Mar 2022 11:28:03 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 19:33:21 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. LGTM ------------- Marked as reviewed by stsypanov at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/7682 From mullan at openjdk.java.net Fri Mar 4 15:07:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Mar 2022 15:07:29 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 Message-ID: Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. ------------- Commit messages: - Initial revision. Changes: https://git.openjdk.java.net/jdk/pull/7697/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7697&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7192189 Stats: 121 lines in 3 files changed: 80 ins; 34 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7697.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7697/head:pull/7697 PR: https://git.openjdk.java.net/jdk/pull/7697 From mullan at openjdk.java.net Fri Mar 4 15:43:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Mar 2022 15:43:12 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 19:33:21 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java line 161: > 159: Ksign = getHmac(baseKey, new_ss); > 160: } catch (Exception e) { > 161: throw new GeneralSecurityException("Calculate Checkum Failed!", e); Can you also fix the typo, "Checkum" should be "Checksum". Same comment applies to line 172. ------------- PR: https://git.openjdk.java.net/jdk/pull/7682 From mullan at openjdk.java.net Fri Mar 4 16:32:09 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Mar 2022 16:32:09 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v18] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 18:57:02 GMT, Xue-Lei Andrew Fan wrote: >> This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 >> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more spec update per CSR feedback Since this new API is also intended to be supported for DTLS, have you added implementation support for that, and if so have you added a test for it? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Fri Mar 4 16:37:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Mar 2022 16:37:04 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: References: Message-ID: <2OmKOFzInqqbC6Rjya7yP1e3Bmhg4CK6eKw50bKMXdY=.302f42a5-98db-4654-b561-1d7958316e8d@github.com> On Fri, 4 Mar 2022 14:59:54 GMT, Sean Mullan wrote: > Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. About the CSR, did you have a plan to update the "Endpoint Identification Algorithms" in the [Java Security Standard Algorithm Names](https://docs.oracle.com/en/java/javase/17/docs/specs/security/standard-names.html#endpoint-identification-algorithms) documentation? Currently, the "HTTPS" name is defined for RFC 2818. With this update is may be worth to mention the compliant to RFC 6125, like HTTPS | RFC 2818, compliant with RFC 6125 ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From mullan at openjdk.java.net Fri Mar 4 16:51:58 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Mar 2022 16:51:58 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: <2OmKOFzInqqbC6Rjya7yP1e3Bmhg4CK6eKw50bKMXdY=.302f42a5-98db-4654-b561-1d7958316e8d@github.com> References: <2OmKOFzInqqbC6Rjya7yP1e3Bmhg4CK6eKw50bKMXdY=.302f42a5-98db-4654-b561-1d7958316e8d@github.com> Message-ID: On Fri, 4 Mar 2022 16:33:45 GMT, Xue-Lei Andrew Fan wrote: > About the CSR, did you have a plan to update the "Endpoint Identification Algorithms" in the [Java Security Standard Algorithm Names](https://docs.oracle.com/en/java/javase/17/docs/specs/security/standard-names.html#endpoint-identification-algorithms) documentation? Currently, the "HTTPS" name is defined for RFC 2818. With this update is may be worth to mention the compliant to RFC 6125, like > > ``` > HTTPS | RFC 2818, compliant with RFC 6125 > ``` I thought about that but I was hesitant to do that, because technically RFC 6125 does not obsolete RFC 2818 and there has been no successor to RFC 2818. So I would rather treat RFC 6125 as an implementation-specific feature of the JDK TLS implementation; in other words we chose to make our implementation compliant with RFC 6125 but other implementations may choose not to and still be compliant with RFC 2818. Since RFC 2818 is somewhat ambiguous/vague with respect to what components can use wildcards, I believe the JDK implementation is still compliant with 2818. I realize this is not a perfect situation, but if we do this via the API, then I think we need new APIs such that older implementations that may be less strict about wildcards are still compatible with 2818 if they choose. ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From duke at openjdk.java.net Fri Mar 4 16:56:25 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 16:56:25 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Hi I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. Now: what is the next step? This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code. ciao matteo ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 16:56:25 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 16:56:25 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines Message-ID: Hi I have reviewed the code for removing double semicolons at the end of lines all the best matteo ------------- Commit messages: - Removed double semicolon at the end of lines Changes: https://git.openjdk.java.net/jdk/pull/7268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282657 Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod Patch: https://git.openjdk.java.net/jdk/pull/7268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268 PR: https://git.openjdk.java.net/jdk/pull/7268 From jwaters at openjdk.java.net Fri Mar 4 16:56:26 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 4 Mar 2022 16:56:26 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > Hi > > I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. > Now: what is the next step? > > This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code. > > ciao > matteo Hi @matteobaccan The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry. Cheers, Julian ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From lancea at openjdk.java.net Fri Mar 4 17:07:59 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Mar 2022 17:07:59 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo The changes look OK. The copyright year probably should be updated as part of this PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 17:14:05 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 17:14:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Hi Lance I can make a second commit updating the copyright year Tell me if this is necessary ciao matteo ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From rriggs at openjdk.java.net Fri Mar 4 17:20:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 17:20:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot. And corresponding tests. This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers. If you had ask ahead of time, I would have suggested finding something with more value. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From xuelei at openjdk.java.net Fri Mar 4 17:32:05 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Mar 2022 17:32:05 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: References: <2OmKOFzInqqbC6Rjya7yP1e3Bmhg4CK6eKw50bKMXdY=.302f42a5-98db-4654-b561-1d7958316e8d@github.com> Message-ID: On Fri, 4 Mar 2022 16:48:47 GMT, Sean Mullan wrote: > > About the CSR, did you have a plan to update the "Endpoint Identification Algorithms" in the [Java Security Standard Algorithm Names](https://docs.oracle.com/en/java/javase/17/docs/specs/security/standard-names.html#endpoint-identification-algorithms) documentation? Currently, the "HTTPS" name is defined for RFC 2818. With this update is may be worth to mention the compliant to RFC 6125, like > > ``` > > HTTPS | RFC 2818, compliant with RFC 6125 > > ``` > > I thought about that but I was hesitant to do that, because technically RFC 6125 does not obsolete RFC 2818 and there has been no successor to RFC 2818. So I would rather treat RFC 6125 as an implementation-specific feature of the JDK TLS implementation; in other words we chose to make our implementation compliant with RFC 6125 but other implementations may choose not to and still be compliant with RFC 2818. Since RFC 2818 is somewhat ambiguous/vague with respect to what components can use wildcards, I believe the JDK implementation is still compliant with 2818. I realize this is not a perfect situation, but if we do this via the API, then I think we need new APIs such that older implementations that may be less strict about wildcards are still compatible with 2818 if they choose. It makes sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From ihse at openjdk.java.net Fri Mar 4 17:50:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Mar 2022 17:50:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot. > And corresponding tests. > This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers. > If you had ask ahead of time, I would have suggested finding something with more value. @RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From xuelei at openjdk.java.net Fri Mar 4 18:50:05 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 4 Mar 2022 18:50:05 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 14:59:54 GMT, Sean Mullan wrote: > Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From prr at openjdk.java.net Fri Mar 4 19:10:06 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 4 Mar 2022 19:10:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by prr (Reviewer). Looks like there's only one client source code file touched Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From rriggs at openjdk.java.net Fri Mar 4 19:33:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 19:33:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From iris at openjdk.java.net Fri Mar 4 19:43:03 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 4 Mar 2022 19:43:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice tidy of the code. Is there anything that can be done to prevent re-introduction of this trivial problem? Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace? ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From wetmore at openjdk.java.net Fri Mar 4 19:56:03 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 4 Mar 2022 19:56:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com> On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo LGTM also. Similar suggestion for updating copyrights. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From darcy at openjdk.java.net Fri Mar 4 21:23:30 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 21:23:30 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException Message-ID: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 ------------- Commit messages: - JDK-8282686: Add constructors take a cause to SocketException Changes: https://git.openjdk.java.net/jdk/pull/7705/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282686 Stats: 48 lines in 6 files changed: 23 ins; 12 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7705.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705 PR: https://git.openjdk.java.net/jdk/pull/7705 From darcy at openjdk.java.net Fri Mar 4 21:33:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 21:33:07 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From wetmore at openjdk.java.net Fri Mar 4 23:47:07 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 4 Mar 2022 23:47:07 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 12:36:33 GMT, zzambers wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216326 > > zzambers has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright for SSLSocket.java There are more changes needed, and should probably be done as part of this issue since we're already in this code anyway. The current code only talks about shutdownInput/shutdownOutput, but makes no mention of the duplex close(), which is the other way to shutdown the SSLSocket. It only needs a few words. https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029167.html These two changes will require a CSR to update the @apiNote. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From bradford.wetmore at oracle.com Sat Mar 5 00:46:36 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 4 Mar 2022 16:46:36 -0800 Subject: [External] : Re: [Internet]Recent SSLSocket close() @apiNote Changes. In-Reply-To: References: <71796164-b59a-011f-c1ef-760182c396bf@oracle.com> Message-ID: <6739900a-6c46-fad4-81fa-30a8836701b8@oracle.com> On 3/2/2022 11:46 PM, xueleifan(XueleiFan) wrote: > I think you are right that this design is actually for TLSv1.3 half-close mode. For TLS 1.3, there is no duplex closure design. The close() implementation in JDK is actually a workaround for compatibility. Application can use either the half-close mode > socket.shutdownOutput(); > socket.shutdownInput(); > > or duplex close mode for compatibilty: > socket.close(); > > Unfortunately, in practice the half-close and duplex close are mixed with three lines: > socket.shutdownOutput(); > socket.shutdownInput(); > socket.close(); Yeah, I've seen that in things like Apache HttpClient Core, which has subsequently been removed. How about something like this: http://cr.openjdk.java.net/~wetmore/8282529/webrev.00/ Thanks, Brad > It was not something I expected when I designed the spec for half-close mode. It should be helpful if having another iteration for the @apiNote. > > Thanks, > Xuelei > > >> On Mar 2, 2022, at 5:14 PM, Bradford Wetmore wrote: >> >> >> Hi Xuelei, >> >> I am working on some close code including the recent PR[1] for: >> >> 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket >> >> and ran into a change I hadn't noticed before. >> >> * @apiNote >> * When the connection is no longer needed, the client and server >> * applications should each close both sides of their respective connection. >> * For {@code SSLSocket} objects, for example, an application can call >> * {@link Socket#shutdownOutput()} for output stream close and call >> * {@link Socket#shutdownInput()} for input stream close. >> >> It used to be that just a single SSLSocket.close() was sufficient to completely shutdown the SSLSocket, and under the hood it closed the output/input in the right order. >> >> I believe this code still closes everything as before, but the updated @apiNote encourages the user to do a three-part shutdown instead. >> >> socket.shutdownOutput(); >> socket.shutdownInput(); >> socket.close(); // mostly repeats of above. >> >> This approach seems unnecessary unless the user is interested in the TLSv1.3 half-close mode. >> >> What is the rationale for recommending this way of doing closes in general? Or does this @apiNote need another iteration? >> >> Thanks, >> >> Brad >> >> [1] https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/7648__;!!ACWV5N9M2RV99hQ!cHw7i1wGs-eyCPUcrFXtAdFiUZL6aCPUGpGEQ9u56HHSuwew1j6YHapR8sSefEwr7TRXKQ$ >> > From dholmes at openjdk.java.net Sat Mar 5 05:52:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 5 Mar 2022 05:52:04 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com> On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo I eyeballed the diff file and all seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From aturbanov at openjdk.java.net Sat Mar 5 06:49:43 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sat, 5 Mar 2022 06:49:43 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss [v2] In-Reply-To: References: Message-ID: > Pass cause exception as constructor parameter is shorter and easier to read. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7682/files - new: https://git.openjdk.java.net/jdk/pull/7682/files/524ba92d..490f7ecb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7682&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7682&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7682.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7682/head:pull/7682 PR: https://git.openjdk.java.net/jdk/pull/7682 From aturbanov at openjdk.java.net Sat Mar 5 06:49:45 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sat, 5 Mar 2022 06:49:45 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 15:39:56 GMT, Sean Mullan wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss >> typo > > src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java line 161: > >> 159: Ksign = getHmac(baseKey, new_ss); >> 160: } catch (Exception e) { >> 161: throw new GeneralSecurityException("Calculate Checkum Failed!", e); > > Can you also fix the typo, "Checkum" should be "Checksum". Same comment applies to line 172. Sure. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/7682 From jwaters at openjdk.java.net Sat Mar 5 06:52:13 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Sat, 5 Mar 2022 06:52:13 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice, good work matteo Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Sat Mar 5 07:22:03 2022 From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=) Date: Sat, 5 Mar 2022 07:22:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From alanb at openjdk.java.net Sat Mar 5 09:50:03 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 5 Mar 2022 09:50:03 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote: > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 This looks good, I just wonder if we should add a test for the new constructors. One of them will be tested by the usages in the JDK, the cause-only constructor may not be exercised by any code. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7705 From mullan at openjdk.java.net Sat Mar 5 13:58:57 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Sat, 5 Mar 2022 13:58:57 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss [v2] In-Reply-To: References: Message-ID: <0LwVpdTuCdwGRDYGZqT0fwPC2h7nbNUqndtu9Bu38LQ=.160af017-fa90-41be-acef-1a2172ba5464@github.com> On Sat, 5 Mar 2022 06:49:43 GMT, Andrey Turbanov wrote: >> Pass cause exception as constructor parameter is shorter and easier to read. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss > typo Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7682 From xuelei at openjdk.java.net Sat Mar 5 16:16:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 5 Mar 2022 16:16:55 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: <6YOD-AAXJFwPkF-qNokBEUTyQaX2BnN4MIXPnuGng-4=.b1a042d3-b548-4fd4-bacf-45aa8f4cb315@github.com> On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote: > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 Looks good to me. I may file a new RFE and use this constructor in the JSSE implementation. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7705 From xueleifan at tencent.com Sat Mar 5 16:21:28 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Sat, 5 Mar 2022 16:21:28 +0000 Subject: [Internet]Re: [External] : Re: Recent SSLSocket close() @apiNote Changes. In-Reply-To: <6739900a-6c46-fad4-81fa-30a8836701b8@oracle.com> References: <71796164-b59a-011f-c1ef-760182c396bf@oracle.com> <6739900a-6c46-fad4-81fa-30a8836701b8@oracle.com> Message-ID: > http://cr.openjdk.java.net/~wetmore/8282529/webrev.00 I was wondering if the mixing of half-close and duplex-close could work as well, by adjusting the implementation code. It could be easier for developers. But your spec update looks good to me, even if we allow the three-lines closure. Thanks, Xuelei On Mar 4, 2022, at 4:46 PM, Bradford Wetmore > wrote: On 3/2/2022 11:46 PM, xueleifan(XueleiFan) wrote: I think you are right that this design is actually for TLSv1.3 half-close mode. For TLS 1.3, there is no duplex closure design. The close() implementation in JDK is actually a workaround for compatibility. Application can use either the half-close mode socket.shutdownOutput(); socket.shutdownInput(); or duplex close mode for compatibilty: socket.close(); Unfortunately, in practice the half-close and duplex close are mixed with three lines: socket.shutdownOutput(); socket.shutdownInput(); socket.close(); Yeah, I've seen that in things like Apache HttpClient Core, which has subsequently been removed. How about something like this: http://cr.openjdk.java.net/~wetmore/8282529/webrev.00/ Thanks, Brad It was not something I expected when I designed the spec for half-close mode. It should be helpful if having another iteration for the @apiNote. Thanks, Xuelei On Mar 2, 2022, at 5:14 PM, Bradford Wetmore wrote: Hi Xuelei, I am working on some close code including the recent PR[1] for: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket and ran into a change I hadn't noticed before. * @apiNote * When the connection is no longer needed, the client and server * applications should each close both sides of their respective connection. * For {@code SSLSocket} objects, for example, an application can call * {@link Socket#shutdownOutput()} for output stream close and call * {@link Socket#shutdownInput()} for input stream close. It used to be that just a single SSLSocket.close() was sufficient to completely shutdown the SSLSocket, and under the hood it closed the output/input in the right order. I believe this code still closes everything as before, but the updated @apiNote encourages the user to do a three-part shutdown instead. socket.shutdownOutput(); socket.shutdownInput(); socket.close(); // mostly repeats of above. This approach seems unnecessary unless the user is interested in the TLSv1.3 half-close mode. What is the rationale for recommending this way of doing closes in general? Or does this @apiNote need another iteration? Thanks, Brad [1] https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/7648__;!!ACWV5N9M2RV99hQ!cHw7i1wGs-eyCPUcrFXtAdFiUZL6aCPUGpGEQ9u56HHSuwew1j6YHapR8sSefEwr7TRXKQ$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.java.net Sat Mar 5 16:48:59 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 5 Mar 2022 16:48:59 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote: > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 Looks fine, would be worth including a couple of tests for coverage ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7705 From xuelei at openjdk.java.net Sun Mar 6 05:40:59 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 6 Mar 2022 05:40:59 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v19] In-Reply-To: References: Message-ID: > This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: add test for DTLS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/5a98c921..ca006ee0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=17-18 Stats: 134 lines in 1 file changed: 134 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252 PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Sun Mar 6 05:40:59 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 6 Mar 2022 05:40:59 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v18] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 16:29:04 GMT, Sean Mullan wrote: > Since this new API is also intended to be supported for DTLS, have you added implementation support for that, and if so have you added a test for it? Yes, the DTLS implementation is included. I added a test case for DTLS. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Mon Mar 7 08:03:29 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Mar 2022 08:03:29 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions Message-ID: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 ------------- Commit messages: - 8282723: Add constructors taking a cause to JSSE exceptions Changes: https://git.openjdk.java.net/jdk/pull/7722/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282723 Stats: 174 lines in 19 files changed: 64 ins; 48 del; 62 mod Patch: https://git.openjdk.java.net/jdk/pull/7722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722 PR: https://git.openjdk.java.net/jdk/pull/7722 From dfuchs at openjdk.java.net Mon Mar 7 10:27:58 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 7 Mar 2022 10:27:58 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote: > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7705 From dfuchs at openjdk.java.net Mon Mar 7 12:09:04 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 7 Mar 2022 12:09:04 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan wrote: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 LGTM. Someone from security-dev should probably review this too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From erikj at openjdk.java.net Mon Mar 7 13:44:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Mar 2022 13:44:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters wrote: > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Mon Mar 7 15:17:31 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 7 Mar 2022 15:17:31 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption Message-ID: `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): - `MethodHandles.longestParameterList()` never returns null - parameter types are never null - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null - exceptions types of method signature are never null ------------- Commit messages: - 8282662: Use List/Set.of() factory methods to save memory Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282662 Stats: 22 lines in 8 files changed: 1 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From dfuchs at openjdk.java.net Mon Mar 7 15:29:01 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 7 Mar 2022 15:29:01 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: <1oi34GhExojhpCh4STwXlzAJVSkLi4Re1qd-0koYt4g=.6b0cd860-3171-4244-9143-772493e101bd@github.com> On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? wrote: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null There's also another difference: they have different serial forms. From my cursory inspection it doesn't look like the returned list are put in serializable fields but it could be good to double check it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Mon Mar 7 15:57:05 2022 From: duke at openjdk.java.net (liach) Date: Mon, 7 Mar 2022 15:57:05 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? wrote: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From redestad at openjdk.java.net Mon Mar 7 16:09:58 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Mar 2022 16:09:58 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com> On Mon, 7 Mar 2022 15:54:02 GMT, liach wrote: > Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it? A good observation. In a couple of these places we could probably use `JavaUtilCollectionAccess.listFromTrustedArray` to avoid such copies. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From jwaters at openjdk.java.net Mon Mar 7 16:24:00 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Mon, 7 Mar 2022 16:24:00 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson wrote: > > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? > > They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you. Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Mon Mar 7 16:37:07 2022 From: duke at openjdk.java.net (zzambers) Date: Mon, 7 Mar 2022 16:37:07 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 23:43:30 GMT, Bradford Wetmore wrote: >> zzambers has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright for SSLSocket.java > > There are more changes needed, and should probably be done as part of this issue since we're already in this code anyway. The current code only talks about shutdownInput/shutdownOutput, but makes no mention of the duplex close(), which is the other way to shutdown the SSLSocket. It only needs a few words. > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029167.html > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html > > These two changes will require a CSR to update the @ apiNote. @bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side? ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From lancea at openjdk.java.net Mon Mar 7 16:43:08 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Mar 2022 16:43:08 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo What problem are you having editing the PR header? You should be able to do so as the author of the PR ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 16:52:07 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 16:52:07 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote: > What problem are you having editing the PR header? You should be able to do so as the author of the PR Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image: ![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 16:56:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 16:56:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo But as the JBS title and PR title now match, this is a moot point. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 17:18:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 17:18:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie wrote: > TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue. Ah, that explains it then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From ihse at openjdk.java.net Mon Mar 7 17:18:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Mar 2022 17:18:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > What problem are you having editing the PR header? You should be able to do so as the author of the PR @LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From darcy at openjdk.java.net Mon Mar 7 17:43:50 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 17:43:50 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException [v2] In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Add regression test. - Merge branch 'master' into JDK-8282686 - JDK-8282686: Add constructors take a cause to SocketException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7705/files - new: https://git.openjdk.java.net/jdk/pull/7705/files/e65f9ae5..978b379d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=00-01 Stats: 8268 lines in 175 files changed: 6072 ins; 1565 del; 631 mod Patch: https://git.openjdk.java.net/jdk/pull/7705.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705 PR: https://git.openjdk.java.net/jdk/pull/7705 From darcy at openjdk.java.net Mon Mar 7 17:55:45 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 17:55:45 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException [v3] In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com> > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7705/files - new: https://git.openjdk.java.net/jdk/pull/7705/files/978b379d..da863692 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7705&range=01-02 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7705.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705 PR: https://git.openjdk.java.net/jdk/pull/7705 From darcy at openjdk.java.net Mon Mar 7 17:55:47 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 17:55:47 GMT Subject: Integrated: JDK-8282686: Add constructors taking a cause to SocketException In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> Message-ID: On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote: > Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 This pull request has now been integrated. Changeset: 1faa5c80 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/1faa5c8092f8baec3ca08ed059653876ec46db46 Stats: 102 lines in 7 files changed: 77 ins; 12 del; 13 mod 8282686: Add constructors taking a cause to SocketException Reviewed-by: alanb, xuelei, lancea, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7705 From sean.mullan at oracle.com Mon Mar 7 18:16:25 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Mar 2022 13:16:25 -0500 Subject: [Internet]Re: JEP Review Request: TLS Certificate Compression In-Reply-To: <7C72500B-4991-416C-AA01-2BB92869C5F3@Tencent.Com> References: <9D47E367-3214-46E9-A73D-5B8693C42BD2@Tencent.Com> <7C72500B-4991-416C-AA01-2BB92869C5F3@Tencent.Com> Message-ID: <42f04521-223a-1c8a-ed68-476ca9a6efff@oracle.com> Hi Xuelei, Please start this discussion in a new thread with a new subject (ex: Proposal for potential new feature: TLS Certificate Compression) as it should be evaluated on its own prior to reaching consensus and deciding if a JEP should be drafted. Also, keep in mind that it may take a few days or longer for members of the Security Group and other interested participants to find time to review new proposals for significant features. Thanks, Sean On 2/28/22 3:33 PM, xueleifan(XueleiFan) wrote: > Hi, > > It may be better to have more detail here, rather than refer you to the > draft JEP.? The first question maybe,?if TLS Certificate Compression is > something we want it in OpenJDK? > > The TLS Certificate Compression standard was described in RFC 8879, and > has been enabled in browser Chrome and Safari. But, what?s TLS > Certificate Compression and what?s the benefits of this feature? > > For TLS connections, a client must authenticate the identity of the > server. This typically involves verification that the identity of the > server is included in a certificate and that the certificate is issued > by a trusted entity. > > Where servers provide certificates for authentication, the size of the > certificate chain can consume a large number of bytes. Controlling the > size of certificate chains is critical to performance and security in > QUIC. TLS certificate compression has the potential to ameliorate the > attacks/problems by reducing the size of the handshakes to a size > compatible with the security restriction. ?The TLS Certificate > Compression feature is an essential part for QUIC-TLS protocols. > > For more details, please refer to section 4.4 in RFC 9001 (Using TLS to > Secure QUIC): > --------- > Note: Where servers provide certificates for authentication, the size of > the certificate chain can consume a large number of bytes. Controlling > the size of certificate chains is critical to performance in QUIC as > servers are limited to sending 3 bytes for every byte received prior to > validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The > size of a certificate chain can be managed by limiting the number of > names or extensions; using keys with small public key representations, > like ECDSA; or by using certificate compression [COMPRESS].? > --------- > > and a more detailed description in the blog ?Does the QUIC handshake > require compression to be > fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study > ). > ?I just copy part of the conclusion section of the bog here for your > quick reference. > --------- > First, the TLS certificate compression extension has a very large impact > on QUIC performance. Even though the extension is new and being > introduced fairly late in the process when compared to overall QUIC > deployment schedules, it seems quite important for both clients and > servers to implement the new extension so that the QUIC handshake can > live up to its billing. Without some help, 40% of QUIC full handshakes > would be no better than TCP, but compression can repair most of that > issue. I have heard of other non-standardized approaches to reducing the > size of the certificate chain, and they seem reasonable, but this is a > problem worth addressing immediately with the existing compression > extension. > > ... > > Lastly, data from the real world again proves to be more insightful than > intuition and is invaluable in making protocol design and implementation > decisions. When I started this work I expected the impact of compression > to be positive but marginally focused on a few edge cases. The data > shows this optimization lands right on the sweet spot that ties > configurations and the QUIC specification together and impacts a large > portion of QUIC handshakes. My thanks to the authors of the compression > extension. > --------- > > > Besides, reducing the amount of information exchanged during a TLS > handshake to a minimum helps to improve performance in environments, for > example Internet of Things, where devices are connected to a network > with a low bandwidth and lossy radio technology. > > This feature is a part to improve the performance of TLS connections, > and it is also a part of the path towards QUIC standards. > > Chrome support TLS certificate compression with Brotil compression > algorithm, and Safari support TLS certificate compression with Zlib > compression algorithm. > > In a summary, JDK could benefits from support RFC 8879 in the following > areas: > > ? ? Performance - Reduce latency and improve performance of TLS and > QUIC connections by support the TLS certificate compression standard in JDK. > ? ? Security - Mitigate the impact of amplification attacks threat by > reducing the size of the TLS handshakes with compressed certificates. > > Please feel free to share you comments, if it?is something we want in > OpenJDK? > > Thanks, > Xuelei > > >> On Feb 28, 2022, at 10:57 AM, xueleifan(XueleiFan) >> > wrote: >> >> Hi, >> >> Could I have this JEP reviewed? ?One or more qualified Committers >> review is required to move it forward. >> >> Here is the PR if you want to have a further look at the >> implementation and test: >> https://github.com/openjdk/jdk/pull/7599 >> >> >> Thanks, >> Xuelei >> >>> On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan) >>> > wrote: >>> >>> Hi all, >>> >>> The JDK Enhancement Proposal, TLS Certificate Compression, has been >>> opened for community review. ?Detailed, please refer to the draft: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8281710 >>> >>> >>> Feel free to make comment and send your feedback to the alias. ?I may >>> submit this JEP in the beginning of next week if I hear no objections >>> by the end of this week. >>> >>> Thanks, >>> Xuelei >>> >> > From wetmore at openjdk.java.net Mon Mar 7 19:24:04 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 7 Mar 2022 19:24:04 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan wrote: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 src/java.base/share/classes/javax/net/ssl/SSLException.java line 52: > 50: */ > 51: public SSLException(String reason) > 52: { Thanks for changing the style. I've always hated the extra vertical space. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xueleifan at tencent.com Mon Mar 7 19:04:55 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 7 Mar 2022 19:04:55 +0000 Subject: Proposal for potential new feature: TLS Certificate Compression Message-ID: <0B2D394C-F741-46D7-8E99-4E57A870F588@Tencent.Com> Hi, The TLS Certificate Compression standard was described in RFC 8879, and has been enabled in browser Chrome and Safari. What?s TLS Certificate Compression and what?s the benefits of this feature? For TLS connections, a client must authenticate the identity of the server. This typically involves verification that the identity of the server is included in a certificate and that the certificate is issued by a trusted entity. Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance and security in QUIC. TLS certificate compression has the potential to ameliorate the attacks/problems by reducing the size of the handshakes to a size compatible with the security restriction. The TLS Certificate Compression feature is an essential part for QUIC-TLS protocols. For more details, please refer to section 4.4 in RFC 9001 (Using TLS to Secure QUIC): --------- Note: Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance in QUIC as servers are limited to sending 3 bytes for every byte received prior to validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain can be managed by limiting the number of names or extensions; using keys with small public key representations, like ECDSA; or by using certificate compression [COMPRESS]. ???? and a more detailed description in the blog ?Does the QUIC handshake require compression to be fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study ). I just copy part of the conclusion section of the bog here for your quick reference. --------- First, the TLS certificate compression extension has a very large impact on QUIC performance. Even though the extension is new and being introduced fairly late in the process when compared to overall QUIC deployment schedules, it seems quite important for both clients and servers to implement the new extension so that the QUIC handshake can live up to its billing. Without some help, 40% of QUIC full handshakes would be no better than TCP, but compression can repair most of that issue. I have heard of other non-standardized approaches to reducing the size of the certificate chain, and they seem reasonable, but this is a problem worth addressing immediately with the existing compression extension. ... Lastly, data from the real world again proves to be more insightful than intuition and is invaluable in making protocol design and implementation decisions. When I started this work I expected the impact of compression to be positive but marginally focused on a few edge cases. The data shows this optimi zation lands right on the sweet spot that ties configurations and the QUIC specification together and impacts a large portion of QUIC handshakes. My thanks to the authors of the compression extension. --------- Besides, reducing the amount of information exchanged during a TLS handshake to a minimum helps to improve performance in environments, for example Internet of Things, where devices are connected to a network with a low bandwidth and lossy radio technology. This feature is a part to improve the performance of TLS connections, and it is also a part of the path towards QUIC standards. Chrome support TLS certificate compression with Brotil compression algorithm, and Safari support TLS certificate compression with Zlib compression algorithm. In a summary, JDK could benefits from support RFC 8879 in the following areas: Performance - Reduce latency and improve performance of TLS and QUIC connections by support the TLS certificate compression standard in JDK. Security - Mitigate the impact of amplification attacks threat by reducing the size of the TLS handshakes with compressed certificates. What do you think? Do you want it to be a part of OpenJDK? Please feel free to share you comments. Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Mon Mar 7 19:42:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Mar 2022 19:42:47 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: typo correction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7722/files - new: https://git.openjdk.java.net/jdk/pull/7722/files/20c0c6b6..edb185ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722 PR: https://git.openjdk.java.net/jdk/pull/7722 From alanb at openjdk.java.net Mon Mar 7 19:44:13 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Mar 2022 19:44:13 GMT Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException [v3] In-Reply-To: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com> References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com> <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com> Message-ID: On Mon, 7 Mar 2022 17:55:45 GMT, Joe Darcy wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Improve test. Hmm, this seems to have been integrated without any Reviewer on the final commit. How did that happen? test/jdk/java/net/SocketException/TestSocketExceptionCtor.java line 32: > 30: import java.util.Objects; > 31: > 32: public class TestSocketExceptionCtor { I don't think this is a good name for the test because it tests mores than the constructors. So I think drop the suffix from the name. ------------- PR: https://git.openjdk.java.net/jdk/pull/7705 From xueleifan at tencent.com Mon Mar 7 19:46:14 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 7 Mar 2022 19:46:14 +0000 Subject: Proposal for potential new feature: TLS Certificate Compression Message-ID: <9C3E05A5-6DA1-4E11-91FC-EECC8A101742@Tencent.Com> Hi, The TLS Certificate Compression standard was described in RFC 8879, and has been enabled in browser Chrome and Safari. What?s TLS Certificate Compression and what?s the benefits of this feature? For TLS connections, a client must authenticate the identity of the server. This typically involves verification that the identity of the server is included in a certificate and that the certificate is issued by a trusted entity. Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance and security in QUIC. TLS certificate compression has the potential to ameliorate the attacks/problems by reducing the size of the handshakes to a size compatible with the security restriction. The TLS Certificate Compression feature is an essential part for QUIC-TLS protocols. For more details, please refer to section 4.4 in RFC 9001 (Using TLS to Secure QUIC): --------- Note: Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance in QUIC as servers are limited to sending 3 bytes for every byte received prior to validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain can be managed by limiting the number of names or extensions; using keys with small public key representations, like ECDSA; or by using certificate compression [COMPRESS]. ???? and a more detailed description in the blog ?Does the QUIC handshake require compression to be fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study). I just copy part of the conclusion section of the bog here for your quick reference. --------- First, the TLS certificate compression extension has a very large impact on QUIC performance. Even though the extension is new and being introduced fairly late in the process when compared to overall QUIC deployment schedules, it seems quite important for both clients and servers to implement the new extension so that the QUIC handshake can live up to its billing. Without some help, 40% of QUIC full handshakes would be no better than TCP, but compression can repair most of that issue. I have heard of other non-standardized approaches to reducing the size of the certificate chain, and they seem reasonable, but this is a problem worth addressing immediately with the existing compression extension. ... Lastly, data from the real world again proves to be more insightful than intuition and is invaluable in making protocol design and implementation decisions. When I started this work I expected the impact of compression to be positive but marginally focused on a few edge cases. The data shows this optimization lands right on the sweet spot that ties configurations and the QUIC specification together and impacts a large portion of QUIC handshakes. My thanks to the authors of the compression extension. --------- Besides, reducing the amount of information exchanged during a TLS handshake to a minimum helps to improve performance in environments, for example Internet of Things, where devices are connected to a network with a low bandwidth and lossy radio technology. This feature is a part to improve the performance of TLS connections, and it is also a part of the path towards QUIC standards. Chrome support TLS certificate compression with Brotil compression algorithm, and Safari support TLS certificate compression with Zlib compression algorithm. In a summary, JDK could benefits from supporting RFC 8879 in the following areas: Performance - Reduce latency and improve performance of TLS and QUIC connections by support the TLS certificate compression standard in JDK. Security - Mitigate the impact of amplification attacks threat by reducing the size of the TLS handshakes with compressed certificates. What do you think? Do you want it a part of OpenJDK? Please feel free to share you comments. Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhalade at openjdk.java.net Mon Mar 7 20:06:57 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 7 Mar 2022 20:06:57 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo correction Please consider adding simple tests to cover new APIs, similar to https://github.com/openjdk/jdk/pull/7705/files#diff-28e1041be519b6266b3b92aea29c5d8917c279880da7e5e9823a518196e96ea5 ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xueleifan at tencent.com Mon Mar 7 20:20:14 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 7 Mar 2022 20:20:14 +0000 Subject: [Internet]Re: Re: JEP Review Request: TLS Certificate Compression In-Reply-To: <42f04521-223a-1c8a-ed68-476ca9a6efff@oracle.com> References: <9D47E367-3214-46E9-A73D-5B8693C42BD2@Tencent.Com> <7C72500B-4991-416C-AA01-2BB92869C5F3@Tencent.Com> <42f04521-223a-1c8a-ed68-476ca9a6efff@oracle.com> Message-ID: Thank you for the suggestion, Sean. Hi all, please discuss the proposal in the new thread: https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html Xuelei > On Mar 7, 2022, at 10:16 AM, Sean Mullan wrote: > > Hi Xuelei, > > Please start this discussion in a new thread with a new subject (ex: Proposal for potential new feature: TLS Certificate Compression) as it should be evaluated on its own prior to reaching consensus and deciding if a JEP should be drafted. > > Also, keep in mind that it may take a few days or longer for members of the Security Group and other interested participants to find time to review new proposals for significant features. > > Thanks, > Sean > > On 2/28/22 3:33 PM, xueleifan(XueleiFan) wrote: >> Hi, >> It may be better to have more detail here, rather than refer you to the draft JEP. The first question maybe, if TLS Certificate Compression is something we want it in OpenJDK? >> The TLS Certificate Compression standard was described in RFC 8879, and has been enabled in browser Chrome and Safari. But, what?s TLS Certificate Compression and what?s the benefits of this feature? >> For TLS connections, a client must authenticate the identity of the server. This typically involves verification that the identity of the server is included in a certificate and that the certificate is issued by a trusted entity. >> Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance and security in QUIC. TLS certificate compression has the potential to ameliorate the attacks/problems by reducing the size of the handshakes to a size compatible with the security restriction. The TLS Certificate Compression feature is an essential part for QUIC-TLS protocols. >> For more details, please refer to section 4.4 in RFC 9001 (Using TLS to Secure QUIC): >> --------- >> Note: Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance in QUIC as servers are limited to sending 3 bytes for every byte received prior to validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain can be managed by limiting the number of names or extensions; using keys with small public key representations, like ECDSA; or by using certificate compression [COMPRESS].? >> --------- >> and a more detailed description in the blog ?Does the QUIC handshake require compression to be fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study ). I just copy part of the conclusion section of the bog here for your quick reference. >> --------- >> First, the TLS certificate compression extension has a very large impact on QUIC performance. Even though the extension is new and being introduced fairly late in the process when compared to overall QUIC deployment schedules, it seems quite important for both clients and servers to implement the new extension so that the QUIC handshake can live up to its billing. Without some help, 40% of QUIC full handshakes would be no better than TCP, but compression can repair most of that issue. I have heard of other non-standardized approaches to reducing the size of the certificate chain, and they seem reasonable, but this is a problem worth addressing immediately with the existing compression extension. >> ... >> Lastly, data from the real world again proves to be more insightful than intuition and is invaluable in making protocol design and implementation decisions. When I started this work I expected the impact of compression to be positive but marginally focused on a few edge cases. The data shows this optimization lands right on the sweet spot that ties configurations and the QUIC specification together and impacts a large portion of QUIC handshakes. My thanks to the authors of the compression extension. >> --------- >> Besides, reducing the amount of information exchanged during a TLS handshake to a minimum helps to improve performance in environments, for example Internet of Things, where devices are connected to a network with a low bandwidth and lossy radio technology. >> This feature is a part to improve the performance of TLS connections, and it is also a part of the path towards QUIC standards. >> Chrome support TLS certificate compression with Brotil compression algorithm, and Safari support TLS certificate compression with Zlib compression algorithm. >> In a summary, JDK could benefits from support RFC 8879 in the following areas: >> Performance - Reduce latency and improve performance of TLS and QUIC connections by support the TLS certificate compression standard in JDK. >> Security - Mitigate the impact of amplification attacks threat by reducing the size of the TLS handshakes with compressed certificates. >> Please feel free to share you comments, if it is something we want in OpenJDK? >> Thanks, >> Xuelei >>> On Feb 28, 2022, at 10:57 AM, xueleifan(XueleiFan) > wrote: >>> >>> Hi, >>> >>> Could I have this JEP reviewed? One or more qualified Committers review is required to move it forward. >>> >>> Here is the PR if you want to have a further look at the implementation and test: >>> https://github.com/openjdk/jdk/pull/7599 >>> >>> Thanks, >>> Xuelei >>> >>>> On Feb 15, 2022, at 9:30 PM, xueleifan(XueleiFan) > wrote: >>>> >>>> Hi all, >>>> >>>> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8281710 >>>> >>>> Feel free to make comment and send your feedback to the alias. I may submit this JEP in the beginning of next week if I hear no objections by the end of this week. >>>> >>>> Thanks, >>>> Xuelei >>>> >>> > From rhalade at openjdk.java.net Mon Mar 7 20:26:56 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 7 Mar 2022 20:26:56 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo correction Update following for SSLPeerUnverifiedException - https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java#L439 ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Mon Mar 7 20:33:01 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 7 Mar 2022 20:33:01 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo correction src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158: > 156: } catch (GeneralSecurityException gse) { > 157: throw new SSLHandshakeException( > 158: "Could not generate secret", gse); I can't quite tell given the coloring, but did this get changed into a tab? ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Mon Mar 7 20:45:05 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 7 Mar 2022 20:45:05 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo correction Didn't see any unit tests for the new methods. Can approve after they are included. src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204: > 202: } catch (GeneralSecurityException | java.io.IOException e) { > 203: throw new SSLHandshakeException( > 204: "Could not generate ECPublicKey", e); Nit: I think combining these lines would be < 80 chars src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 263: > 261: fragment = plaintext.fragment; > 262: contentType = plaintext.contentType; > 263: } catch (BadPaddingException bpe) { Does the copyright need to get updated? ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Mon Mar 7 20:45:06 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 7 Mar 2022 20:45:06 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 20:39:44 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158: >> >>> 156: } catch (GeneralSecurityException gse) { >>> 157: throw new SSLHandshakeException( >>> 158: "Could not generate secret", gse); >> >> I can't quite tell given the coloring, but did this get changed into a tab? > > Yes, I added 4 more whitespaces in line 158. Ah, missed that. Good to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Mon Mar 7 20:45:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Mar 2022 20:45:06 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 20:30:07 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> typo correction > > src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 158: > >> 156: } catch (GeneralSecurityException gse) { >> 157: throw new SSLHandshakeException( >> 158: "Could not generate secret", gse); > > I can't quite tell given the coloring, but did this get changed into a tab? Yes, I added 4 more whitespaces in line 158. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Mon Mar 7 20:54:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Mar 2022 20:54:58 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo correction > ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Mon Mar 7 20:54:59 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Mar 2022 20:54:59 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: <_k7ZQ-0FCYrNXalYTh9tyeZV-NF3868N4m7A0FKEY2I=.f6441cb7-3033-4a82-bfd7-2faa62fc4874@github.com> On Mon, 7 Mar 2022 20:24:08 GMT, Rajan Halade wrote: > Update following for SSLPeerUnverifiedException - > > https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java#L439 Hm, I will check more usage out of the JSSE implementation code. Thank you! > Please consider adding simple tests to cover new APIs, similar to https://github.com/openjdk/jdk/pull/7705/files#diff-28e1041be519b6266b3b92aea29c5d8917c279880da7e5e9823a518196e96ea5 Thank you for the reference. I will add some test cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Mon Mar 7 20:54:59 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 7 Mar 2022 20:54:59 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 20:36:41 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> typo correction > > src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 263: > >> 261: fragment = plaintext.fragment; >> 262: contentType = plaintext.contentType; >> 263: } catch (BadPaddingException bpe) { > > Does the copyright need to get updated? Oops, I missed this file. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Mon Mar 7 21:04:00 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 7 Mar 2022 21:04:00 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 16:34:08 GMT, zzambers wrote: > Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side? One of us needs to get the CSR approved. Why don't you pull the changes described in: https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html Assuming you are ok with the updated wording, I can create the CSR and submit. Once that it approved, then we can get this PR approved and you can integrate. Are you at contributor status? ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From rhalade at openjdk.java.net Mon Mar 7 21:31:05 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 7 Mar 2022 21:31:05 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 14:59:54 GMT, Sean Mullan wrote: > Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. test/jdk/sun/security/util/HostnameChecker/Wildcard.java line 72: > 70: } catch (Exception e) { > 71: if (expected) { > 72: throw new Exception("unexpectedly failed match", e); consider to update these to RuntimeException test/jdk/sun/security/util/HostnameMatcher/TestHostnameChecker.java line 196: > 194: check(checker, "5.6.7.8", cert3, true); > 195: check(checker, "foo.bar.com", cert4, true); > 196: check(checker, "altfoo.bar.com", cert4, true); Can expected result be updated to false instead of removing this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From mullan at openjdk.java.net Mon Mar 7 21:37:05 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 7 Mar 2022 21:37:05 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 21:26:34 GMT, Rajan Halade wrote: >> Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. > > test/jdk/sun/security/util/HostnameMatcher/TestHostnameChecker.java line 196: > >> 194: check(checker, "5.6.7.8", cert3, true); >> 195: check(checker, "foo.bar.com", cert4, true); >> 196: check(checker, "altfoo.bar.com", cert4, true); > > Can expected result be updated to false instead of removing this case? It occurred to me that I should probably combine TestHostnameChecker and the Wildcard tests as they are both tests for domain matching. Let me see if it isn't too much work to do that (still waiting for the CSR to be approved anyway). ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From duke at openjdk.java.net Mon Mar 7 21:37:05 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Mon, 7 Mar 2022 21:37:05 GMT Subject: Integrated: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo This pull request has now been integrated. Changeset: ccad3923 Author: Matteo Baccan Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9 Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod 8282657: Code cleanup: removing double semicolons at the end of lines Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From bradford.wetmore at oracle.com Mon Mar 7 21:38:25 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 7 Mar 2022 13:38:25 -0800 Subject: Need a reviewer for CSR: JDK-8282768 Message-ID: Hi, We (zzambers/I) need a reviewer for this CSR involving the close @apiNote of SSLSocket.java: https://bugs.openjdk.java.net/browse/JDK-8282768 Fix API Note in javadoc for javax.net.ssl.SSLSocket The original bug JDK-8282529[1] is/has been discussed in these threads [2][3], and has this pull request[4]. Brad [1] https://bugs.openjdk.java.net/browse/JDK-8282529 [2] https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029132.html [3] https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029163.html [4] https://github.com/openjdk/jdk/pull/7648 From rhalade at openjdk.java.net Mon Mar 7 21:57:04 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 7 Mar 2022 21:57:04 GMT Subject: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss [v2] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 06:49:43 GMT, Andrey Turbanov wrote: >> Pass cause exception as constructor parameter is shorter and easier to read. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss > typo Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7682 From aturbanov at openjdk.java.net Mon Mar 7 22:04:02 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 7 Mar 2022 22:04:02 GMT Subject: Integrated: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss In-Reply-To: References: Message-ID: <_Q3naKMN6kDDdtZu4WTw8_9dszYS0CveS1t_67Xo9n8=.ab615d34-328c-49e7-a040-8a13a39776c9@github.com> On Thu, 3 Mar 2022 19:33:21 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. This pull request has now been integrated. Changeset: 50eb915a Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/50eb915a74aed2daf03c7d39670d3a1ac8d5cbfb Stats: 22 lines in 3 files changed: 0 ins; 13 del; 9 mod 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss Reviewed-by: mullan, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/7682 From xuelei at openjdk.java.net Tue Mar 8 05:47:54 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 8 Mar 2022 05:47:54 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v3] In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: update more usage and add test cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7722/files - new: https://git.openjdk.java.net/jdk/pull/7722/files/edb185ec..628605e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=01-02 Stats: 216 lines in 10 files changed: 200 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722 PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Tue Mar 8 05:55:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 8 Mar 2022 05:55:06 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 20:34:02 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> typo correction > > src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204: > >> 202: } catch (GeneralSecurityException | java.io.IOException e) { >> 203: throw new SSLHandshakeException( >> 204: "Could not generate ECPublicKey", e); > > Nit: I think combining these lines would be < 80 chars The exception name is too long to have in one line. There are 83 characters in total if combining line 203 and 204. 3 characters exceeding 80 chars per line limit is not easy to tell with eyes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Tue Mar 8 06:02:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 8 Mar 2022 06:02:58 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v4] In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: update usage in test template ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7722/files - new: https://git.openjdk.java.net/jdk/pull/7722/files/628605e6..37953310 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722 PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Tue Mar 8 08:02:16 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 8 Mar 2022 08:02:16 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: more test case udpate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7722/files - new: https://git.openjdk.java.net/jdk/pull/7722/files/37953310..61cc7934 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722 PR: https://git.openjdk.java.net/jdk/pull/7722 From duke at openjdk.java.net Tue Mar 8 12:36:58 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 8 Mar 2022 12:36:58 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com> References: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com> Message-ID: On Mon, 7 Mar 2022 16:06:44 GMT, Claes Redestad wrote: > Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it? Good point, I see risky changes in this PR: - `ProxyGenerator` - `Proxy` - `MethodType` - `FileTreeIterator` As of `ProxyGenerator.ProxyMethod` at start-up time of my Spring Boot -based application there are 2696 invocations of `ProxyGenerator.ProxyMethod.generateMethod()` and 0 of them was for `exceptionTypes.length > 2`. This is expectable as the majority of the methods declare either 0, or 1-2 exceptions. As of `Proxy.getProxyConstructor()` in my application I have 1417 invocations of `List.of()` and 599 of them are with `intfsArray.length > 2`. There were no invocations of `Proxy.defaultMethodHandle()` so I have no statistics. For `MethodType` there were 0 invocations, and I have no statistics, but as of my experience most of the methods have 0-2 parameters. In case of `FileTreeIterator` incoming vararg is always of length either 0 or 1, as `FileVisitOption` enum has only one item. So I suggest to apply something like `intfsArray.length < 2 ? List.of(intfsArray) : Arrays.asList(intfsArray)` keeping the rest of the code as is. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From mullan at openjdk.java.net Tue Mar 8 13:00:50 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Mar 2022 13:00:50 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2] In-Reply-To: References: Message-ID: > Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Merge Wildcard test into TestHostnameCheck. Rename HostnameMatcher dir to HostnameChecker. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7697/files - new: https://git.openjdk.java.net/jdk/pull/7697/files/f91b9e15..2b6a9179 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7697&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7697&range=00-01 Stats: 562 lines in 9 files changed: 251 ins; 311 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7697.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7697/head:pull/7697 PR: https://git.openjdk.java.net/jdk/pull/7697 From mullan at openjdk.java.net Tue Mar 8 13:00:50 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Mar 2022 13:00:50 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 21:26:56 GMT, Rajan Halade wrote: >> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: >> >> Merge Wildcard test into TestHostnameCheck. >> Rename HostnameMatcher dir to HostnameChecker. > > test/jdk/sun/security/util/HostnameChecker/Wildcard.java line 72: > >> 70: } catch (Exception e) { >> 71: if (expected) { >> 72: throw new Exception("unexpectedly failed match", e); > > consider to update these to RuntimeException What are the benefits of throwing `RuntimeException` instead of `Exception`? In the latest commit, I have merged the `Wildcard.java` test into `TestHostnameChecker.java` test which already throws `Exception` on failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From mullan at openjdk.java.net Tue Mar 8 13:00:51 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Mar 2022 13:00:51 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2] In-Reply-To: References: Message-ID: <2Ab4J-MGPDGNytrkX_ALU8I7_6mgVCk3Pl5LHTClu0U=.c32fece1-0bc5-46a0-81f0-fe54cf0916c4@github.com> On Mon, 7 Mar 2022 21:33:47 GMT, Sean Mullan wrote: >> test/jdk/sun/security/util/HostnameMatcher/TestHostnameChecker.java line 196: >> >>> 194: check(checker, "5.6.7.8", cert3, true); >>> 195: check(checker, "foo.bar.com", cert4, true); >>> 196: check(checker, "altfoo.bar.com", cert4, true); >> >> Can expected result be updated to false instead of removing this case? > > It occurred to me that I should probably combine TestHostnameChecker and the Wildcard tests as they are both tests for domain matching. Let me see if it isn't too much work to do that (still waiting for the CSR to be approved anyway). Fixed in latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From duke at openjdk.java.net Tue Mar 8 14:21:19 2022 From: duke at openjdk.java.net (zzambers) Date: Tue, 8 Mar 2022 14:21:19 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v3] In-Reply-To: References: Message-ID: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 zzambers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: javax/net/ssl/SSLSocket: Fixed API Note in javadoc ------------- Changes: https://git.openjdk.java.net/jdk/pull/7648/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=02 Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648 PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Tue Mar 8 14:28:05 2022 From: duke at openjdk.java.net (zzambers) Date: Tue, 8 Mar 2022 14:28:05 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 21:01:12 GMT, Bradford Wetmore wrote: >> @bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side? > >> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the > process. Is action expected from my side? > > One of us needs to get the CSR approved. Why don't you pull the changes described in: > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html > > Assuming you are ok with the updated wording, I can create the CSR and submit. Once that it approved, then we can get this PR approved and you can integrate. > > Are you at contributor status? @bradfordwetmore I have updated this PR with your patch. I am covered by OCA. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Tue Mar 8 14:35:12 2022 From: duke at openjdk.java.net (liach) Date: Tue, 8 Mar 2022 14:35:12 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? wrote: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null Calling `Arrays.asList` vs `List.of` on a switch on the array length seems like an overkill for such a simple thing. Imo the safest changes are where we know the input array length is going to be 1 or 2. src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70: > 68: throws IOException > 69: { > 70: this.walker = new FileTreeWalker(List.of(options), maxDepth); Relates to https://bugs.openjdk.java.net/browse/JDK-8145048 src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java line 79: > 77: containerBeforeContainee(annotations, annoClass); > 78: > 79: result.addAll((indirectFirst ? 0 : 1), List.of(indirect)); This `indirect` is most likely to be of size > 2 ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue Mar 8 14:52:02 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Mar 2022 14:52:02 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Tue, 8 Mar 2022 05:51:21 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java line 204: >> >>> 202: } catch (GeneralSecurityException | java.io.IOException e) { >>> 203: throw new SSLHandshakeException( >>> 204: "Could not generate ECPublicKey", e); >> >> Nit: I think combining these lines would be < 80 chars > > The exception name is too long to have in one line. There are 83 characters in total if combining line 203 and 204. 3 characters exceeding 80 chars per line limit is not easy to tell with eyes. The 80 character recommendation isn't a hard limit, I favor readability in the 80-100 char range. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From duke at openjdk.java.net Tue Mar 8 15:03:57 2022 From: duke at openjdk.java.net (zzambers) Date: Tue, 8 Mar 2022 15:03:57 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v4] In-Reply-To: References: Message-ID: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 zzambers has updated the pull request incrementally with one additional commit since the last revision: small fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7648/files - new: https://git.openjdk.java.net/jdk/pull/7648/files/ddd59a9e..38d649e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7648&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7648/head:pull/7648 PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Tue Mar 8 15:03:57 2022 From: duke at openjdk.java.net (zzambers) Date: Tue, 8 Mar 2022 15:03:57 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v3] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 14:21:19 GMT, zzambers wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216326 > > zzambers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > javax/net/ssl/SSLSocket: Fixed API Note in javadoc But I am not a Commiter (I need sponsor). ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Tue Mar 8 15:25:57 2022 From: duke at openjdk.java.net (zzambers) Date: Tue, 8 Mar 2022 15:25:57 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 21:01:12 GMT, Bradford Wetmore wrote: >> @bradfordwetmore Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the process. Is action expected from my side? > >> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the > process. Is action expected from my side? > > One of us needs to get the CSR approved. Why don't you pull the changes described in: > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html > > Assuming you are ok with the updated wording, I can create the CSR and submit. Once that it approved, then we can get this PR approved and you can integrate. > > Are you at contributor status? @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself). I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From xueleifan at tencent.com Tue Mar 8 15:27:27 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Tue, 8 Mar 2022 15:27:27 +0000 Subject: [Internet]Need a reviewer for CSR: JDK-8282768 In-Reply-To: References: Message-ID: The CSR looks good to me, and I added my name as reviewer. Xuelei > On Mar 7, 2022, at 1:38 PM, Bradford Wetmore wrote: > > > Hi, > > We (zzambers/I) need a reviewer for this CSR involving the close @apiNote of SSLSocket.java: > > https://bugs.openjdk.java.net/browse/JDK-8282768 > Fix API Note in javadoc for javax.net.ssl.SSLSocket > > The original bug JDK-8282529[1] is/has been discussed in these threads [2][3], and has this pull request[4]. > > Brad > > [1] https://bugs.openjdk.java.net/browse/JDK-8282529 > [2] https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029132.html > [3] https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029163.html > [4] https://github.com/openjdk/jdk/pull/7648 > > > From mullan at openjdk.java.net Tue Mar 8 16:46:13 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Mar 2022 16:46:13 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v19] In-Reply-To: References: Message-ID: On Sun, 6 Mar 2022 05:40:59 GMT, Xue-Lei Andrew Fan wrote: >> This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 >> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > add test for DTLS Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 501: > 499: > 500: // Note that if the System Property value is not defined (JDK > 501: // default value) or empty, the provider-specific default is used. I think you can remove this comment as it is repeated on lines 507-508 (and makes more sense there). src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 564: > 562: String[] signatureSchemes) { > 563: > 564: if (signatureSchemes == null || signatureSchemes.length == 0) { Nit: remove extra space after `||`. src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 576: > 574: SSLLogger.finest( > 575: "Ignore the signature algorithm (" + ss > 576: + "), unsupported or unavailable"); Should this message be more consistent with the message in `getCustomizedSignatureScheme`?: "The current installed providers do not support signature scheme: " + schemeName test/jdk/javax/net/ssl/DTLS/DTLSSignatureSchemes.java line 125: > 123: testCase.runTest(testCase); > 124: if (exceptionExpected) { > 125: throw new RuntimeException("Unexpected success!"); The catch block on line 127 will end up catching this exception and swallowing it, and the test will incorrectly pass. test/jdk/javax/net/ssl/SSLParameters/SignatureSchemes.java line 81: > 79: super.runClientApplication(sslSocket); > 80: if (exceptionExpected) { > 81: throw new RuntimeException("Unexpected success!"); The catch block on line 83 will end up catching this exception and swallowing it, and the test will incorrectly pass. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From rhalade at openjdk.java.net Tue Mar 8 18:10:07 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 8 Mar 2022 18:10:07 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 13:00:50 GMT, Sean Mullan wrote: >> Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Merge Wildcard test into TestHostnameCheck. > Rename HostnameMatcher dir to HostnameChecker. Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From rhalade at openjdk.java.net Tue Mar 8 18:04:04 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 8 Mar 2022 18:04:04 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 12:56:50 GMT, Sean Mullan wrote: >> test/jdk/sun/security/util/HostnameChecker/Wildcard.java line 72: >> >>> 70: } catch (Exception e) { >>> 71: if (expected) { >>> 72: throw new Exception("unexpectedly failed match", e); >> >> consider to update these to RuntimeException > > What are the benefits of throwing `RuntimeException` instead of `Exception`? In the latest commit, I have merged the `Wildcard.java` test into `TestHostnameChecker.java` test which already throws `Exception` on failures. It's not essential. RuntimeException is a convenient choice since it's unchecked, so you don't have to sprinkle your code with throws clauses. https://openjdk.java.net/jtreg/faq.html#if-a-test-fails-do-i-have-to-throw-my-own-exception ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From mullan at openjdk.java.net Tue Mar 8 18:22:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Mar 2022 18:22:12 GMT Subject: Integrated: 7192189: Support endpoint identification algorithm in RFC 6125 In-Reply-To: References: Message-ID: <4ZNdYkU-nQRXt0sfDUlxRw5Z8DQLnDMaBBbHsFd8d_A=.8abb94ce-b20a-4892-9651-4c41667433ce@github.com> On Fri, 4 Mar 2022 14:59:54 GMT, Sean Mullan wrote: > Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. This pull request has now been integrated. Changeset: 72e987e3 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/72e987e3b49b81f2f66d125c18ab459d9ed572b6 Stats: 520 lines in 9 files changed: 251 ins; 265 del; 4 mod 7192189: Support endpoint identification algorithm in RFC 6125 Reviewed-by: xuelei, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From dcubed at openjdk.java.net Tue Mar 8 20:15:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 8 Mar 2022 20:15:11 GMT Subject: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 13:00:50 GMT, Sean Mullan wrote: >> Please review this change to fully support RFC 6125 in the TLS implementation. This change forbids wildcard domains in TLS certificates unless the wildcard is in the left-most component. Certificates of this nature should be rare and are not allowed per the CABForum baseline requirements. However there may be a small compatibility risk associated with this change, so a CSR has also been filed. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Merge Wildcard test into TestHostnameCheck. > Rename HostnameMatcher dir to HostnameChecker. I'm not seeing any indication in this PR documenting how this fix was tested. It appears to have caused a Tier2 test to fail on all platforms: JDK-8282832 sun/security/util/Pem/encoding.sh failed with "FileNotFoundException: .../open/test/jdk/sun/security/util/Pem/../HostnameMatcher/cert5.crt (No such file or directory)" https://bugs.openjdk.java.net/browse/JDK-8282832 ------------- PR: https://git.openjdk.java.net/jdk/pull/7697 From rhalade at openjdk.java.net Tue Mar 8 20:38:30 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 8 Mar 2022 20:38:30 GMT Subject: Integrated: 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh Message-ID: ?ecurity/util/Pem/encoding.sh ------------- Commit messages: - Update copyright year - 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh Changes: https://git.openjdk.java.net/jdk/pull/7749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282832 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7749/head:pull/7749 PR: https://git.openjdk.java.net/jdk/pull/7749 From mullan at openjdk.java.net Tue Mar 8 20:38:31 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Mar 2022 20:38:31 GMT Subject: Integrated: 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh In-Reply-To: References: Message-ID: <1imLhlWgJL4CMpam-HHS1HV3tkACMnoqn1kr98A2XGU=.4f5cab52-1da7-4cb4-84d9-e12963ae35b1@github.com> On Tue, 8 Mar 2022 20:25:12 GMT, Rajan Halade wrote: > ?ecurity/util/Pem/encoding.sh Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7749 From rhalade at openjdk.java.net Tue Mar 8 20:38:32 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 8 Mar 2022 20:38:32 GMT Subject: Integrated: 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 20:25:12 GMT, Rajan Halade wrote: > ?ecurity/util/Pem/encoding.sh This pull request has now been integrated. Changeset: ea19114e Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/ea19114e66326e4be7b4b9995888ad2ead3d37dc Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7749 From wetmore at openjdk.java.net Tue Mar 8 22:15:06 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 8 Mar 2022 22:15:06 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:23:13 GMT, zzambers wrote: >>> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the >> process. Is action expected from my side? >> >> One of us needs to get the CSR approved. Why don't you pull the changes described in: >> >> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html >> >> Assuming you are ok with the updated wording, I can create the CSR and submit. Once that it approved, then we can get this PR approved and you can integrate. >> >> Are you at contributor status? > > @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself). I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that. @zzambers Thanks for catching the two little issues with the closing brackets/missing space. CSR has been finalized, just need to wait for approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From wetmore at openjdk.java.net Tue Mar 8 22:15:05 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 8 Mar 2022 22:15:05 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v4] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:03:57 GMT, zzambers wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216326 > > zzambers has updated the pull request incrementally with one additional commit since the last revision: > > small fixes LGTM. I can sponsor after CSR approvals granted. Please hold off on integrating until then. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7648 From valeriep at openjdk.java.net Wed Mar 9 02:02:51 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 02:02:51 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to use SHA-384 as long as the keysize permits. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/27e27836..7f6fe4b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=00-01 Stats: 27 lines in 7 files changed: 6 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From xuelei at openjdk.java.net Wed Mar 9 08:25:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Mar 2022 08:25:48 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v20] In-Reply-To: References: Message-ID: > This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: correct test case issues and more ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7252/files - new: https://git.openjdk.java.net/jdk/pull/7252/files/ca006ee0..f1611238 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7252&range=18-19 Stats: 21 lines in 4 files changed: 12 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7252.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7252/head:pull/7252 PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Mar 9 08:25:50 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Mar 2022 08:25:50 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v19] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 16:13:08 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> add test for DTLS > > src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 501: > >> 499: >> 500: // Note that if the System Property value is not defined (JDK >> 501: // default value) or empty, the provider-specific default is used. > > I think you can remove this comment as it is repeated on lines 507-508 (and makes more sense there). I agreed. > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 564: > >> 562: String[] signatureSchemes) { >> 563: >> 564: if (signatureSchemes == null || signatureSchemes.length == 0) { > > Nit: remove extra space after `||`. Thanks for the catch! > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 576: > >> 574: SSLLogger.finest( >> 575: "Ignore the signature algorithm (" + ss >> 576: + "), unsupported or unavailable"); > > Should this message be more consistent with the message in `getCustomizedSignatureScheme`?: "The current installed providers do not support signature scheme: " + schemeName The usage of the method is a little bit different. This method is mainly used for selecting a few from many signature schemes, and it is usually log with "ignore ..." for those does not match but with high preference. See also the caller method, getSupportedAlgorithms(), between lines 389-405. > test/jdk/javax/net/ssl/DTLS/DTLSSignatureSchemes.java line 125: > >> 123: testCase.runTest(testCase); >> 124: if (exceptionExpected) { >> 125: throw new RuntimeException("Unexpected success!"); > > The catch block on line 127 will end up catching this exception and swallowing it, and the test will incorrectly pass. Good catch! > test/jdk/javax/net/ssl/SSLParameters/SignatureSchemes.java line 81: > >> 79: super.runClientApplication(sslSocket); >> 80: if (exceptionExpected) { >> 81: throw new RuntimeException("Unexpected success!"); > > The catch block on line 83 will end up catching this exception and swallowing it, and the test will incorrectly pass. Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From duke at openjdk.java.net Wed Mar 9 08:35:45 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Mar 2022 08:35:45 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8282662: Revert dubious changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/b31edfcd..5bbe8c4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=00-01 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Wed Mar 9 09:02:00 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Mar 2022 09:02:00 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> References: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> Message-ID: On Tue, 8 Mar 2022 14:28:00 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java line 79: > >> 77: containerBeforeContainee(annotations, annoClass); >> 78: >> 79: result.addAll((indirectFirst ? 0 : 1), List.of(indirect)); > > This `indirect` is most likely to be of size > 2 I've reverted this along with the rest of dubious changes ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Wed Mar 9 09:41:05 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Mar 2022 09:41:05 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> References: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> Message-ID: <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com> On Tue, 8 Mar 2022 14:27:23 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70: > >> 68: throws IOException >> 69: { >> 70: this.walker = new FileTreeWalker(List.of(options), maxDepth); > > Relates to https://bugs.openjdk.java.net/browse/JDK-8145048 Should I keep it as is or revert along with the rest of dubious changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From mullan at openjdk.java.net Wed Mar 9 13:35:13 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 9 Mar 2022 13:35:13 GMT Subject: RFR: 8280494: (D)TLS signature schemes [v20] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 08:25:48 GMT, Xue-Lei Andrew Fan wrote: >> This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 >> Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > correct test case issues and more Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From ssahoo at openjdk.java.net Wed Mar 9 15:10:13 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 9 Mar 2022 15:10:13 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive Message-ID: Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. ------------- Commit messages: - 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive Changes: https://git.openjdk.java.net/jdk/pull/7759/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282293 Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7759/head:pull/7759 PR: https://git.openjdk.java.net/jdk/pull/7759 From duke at openjdk.java.net Wed Mar 9 15:50:03 2022 From: duke at openjdk.java.net (liach) Date: Wed, 9 Mar 2022 15:50:03 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com> References: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com> Message-ID: On Wed, 9 Mar 2022 09:37:30 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70: >> >>> 68: throws IOException >>> 69: { >>> 70: this.walker = new FileTreeWalker(List.of(options), maxDepth); >> >> Relates to https://bugs.openjdk.java.net/browse/JDK-8145048 > > Should I keep it as is or revert along with the rest of dubious changes? probably keep it. this can be updated in the patch for that bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From weijun at openjdk.java.net Wed Mar 9 16:10:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 16:10:27 GMT Subject: RFR: 8282884: Provide OID aliases for MD2, MD5, and OAEP Message-ID: Add missing OID aliases for several algorithms. ------------- Commit messages: - 8282884: Provide OID aliases for MD2, MD5, and OAEP Changes: https://git.openjdk.java.net/jdk/pull/7761/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7761&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282884 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7761/head:pull/7761 PR: https://git.openjdk.java.net/jdk/pull/7761 From duke at openjdk.java.net Wed Mar 9 16:12:13 2022 From: duke at openjdk.java.net (liach) Date: Wed, 9 Mar 2022 16:12:13 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 08:35:45 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes src/java.base/share/classes/java/lang/invoke/MethodType.java line 910: > 908: if (skipPos > myLen || myLen - skipPos > fullLen) > 909: return false; > 910: List> myList = List.of(ptypes); imo should revert this one together with that proxy parameter one ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From xuelei at openjdk.java.net Wed Mar 9 16:15:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Mar 2022 16:15:14 GMT Subject: Integrated: 8280494: (D)TLS signature schemes In-Reply-To: References: Message-ID: <7yb7x6f1PGi17KAySfeI2YY24rTy2DWKmaJbyTzQI6I=.cbfc191a-e6b3-4b67-bb14-81ae60cc5636@github.com> On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan wrote: > This update is to support signature schemes customization for individual (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.java.net/browse/JDK-8280495 > RFE: https://bugs.openjdk.java.net/browse/JDK-8280494 > Release-note: https://bugs.openjdk.java.net/browse/JDK-8281290 This pull request has now been integrated. Changeset: 6d8d156c Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/6d8d156c97b90a9ab4776c6b42563a962d959741 Stats: 521 lines in 6 files changed: 462 ins; 12 del; 47 mod 8280494: (D)TLS signature schemes Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7252 From xuelei at openjdk.java.net Wed Mar 9 16:40:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Mar 2022 16:40:07 GMT Subject: RFR: 8282884: Provide OID aliases for MD2, MD5, and OAEP In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 16:04:02 GMT, Weijun Wang wrote: > Add missing OID aliases for several algorithms. It looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7761 From weijun at openjdk.java.net Wed Mar 9 16:44:03 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 16:44:03 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to use SHA-384 as long as the keysize permits. The `JarSigner` API is not updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From xuelei at openjdk.java.net Wed Mar 9 16:47:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Mar 2022 16:47:00 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v4] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:03:57 GMT, zzambers wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> [2] https://bugs.openjdk.java.net/browse/JDK-8216326 > > zzambers has updated the pull request incrementally with one additional commit since the last revision: > > small fixes Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From weijun at openjdk.java.net Wed Mar 9 16:51:06 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 16:51:06 GMT Subject: Integrated: 8282884: Provide OID aliases for MD2, MD5, and OAEP In-Reply-To: References: Message-ID: <-C8PvYL6UU_y7fFjqRhkVZqRm00aSHEMiDAt6c1CoqY=.b0979782-ecd7-4ee2-a6a7-b42252ee37e4@github.com> On Wed, 9 Mar 2022 16:04:02 GMT, Weijun Wang wrote: > Add missing OID aliases for several algorithms. This pull request has now been integrated. Changeset: 70318e1d Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/70318e1d17072198be5674ebe7118fb5f9373144 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8282884: Provide OID aliases for MD2, MD5, and OAEP Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7761 From valeriep at openjdk.java.net Wed Mar 9 19:15:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 19:15:36 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update JarSigner javadoc to make it consistent with previous update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/7f6fe4b5..099a6d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From weijun at openjdk.java.net Wed Mar 9 19:49:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 19:49:45 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update JarSigner javadoc to make it consistent with previous update Sorry if my previous comment confused you, the code and javadoc are not consistent now. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 561: > 559: return (isDSA || bitLength >= 624 ? "SHA384" : "SHA256"); > 560: } > 561: } In this method, "SHA-384" for 7680-bit key (7680 > 7680 is false). src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > 437: * Specifically, if a DSA or RSA key with a key size no less than 7680 > 438: * bits, or an EC key with a key size no less than 512 bits, > 439: * SHA-512 will be used as the hash function for the signature. In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From wetmore at openjdk.java.net Wed Mar 9 21:15:40 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 9 Mar 2022 21:15:40 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 I am looking at a few things in this PR. Please ping me before integrating. I believe this code is correct, but checking on the overall USER_CANCELED strategy. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From achung at openjdk.java.net Wed Mar 9 21:16:48 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 9 Mar 2022 21:16:48 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 Message-ID: msg drop for jdk19, Mar 9, 2022 ------------- Commit messages: - open jdk19 l10n msg drop Changes: https://git.openjdk.java.net/jdk/pull/7765/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280400 Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From valeriep at openjdk.java.net Wed Mar 9 22:13:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 22:13:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: <1j7YQWGZ5x2PU7aUm7m2gUBkI_BThArGU6qrn5fYPng=.49a446eb-f48f-4276-b326-f1cea296c1cb@github.com> On Wed, 9 Mar 2022 19:44:39 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JarSigner javadoc to make it consistent with previous update > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > >> 437: * Specifically, if a DSA or RSA key with a key size no less than 7680 >> 438: * bits, or an EC key with a key size no less than 512 bits, >> 439: * SHA-512 will be used as the hash function for the signature. > > In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). Right, there are a few places which this is documented. Code and doc aren't closely coupled together plus changed course a few times... I will fix this and double check other files. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From naoto at openjdk.java.net Wed Mar 9 22:29:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 9 Mar 2022 22:29:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 `src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties` These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging). ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From valeriep at openjdk.java.net Thu Mar 10 00:20:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Mar 2022 00:20:36 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v4] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to match the latest SignatureUtil.ifcFfcStrength() impl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/099a6d92..f728aa7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From joehw at openjdk.java.net Thu Mar 10 00:46:44 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 10 Mar 2022 00:46:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com> On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For the bundles in java.xml: For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date. For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header. In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From ssahoo at openjdk.java.net Thu Mar 10 05:59:14 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 10 Mar 2022 05:59:14 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v2] In-Reply-To: References: Message-ID: > Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update HttpsCB.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7759/files - new: https://git.openjdk.java.net/jdk/pull/7759/files/6899fe36..6d276479 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7759/head:pull/7759 PR: https://git.openjdk.java.net/jdk/pull/7759 From jjiang at openjdk.java.net Thu Mar 10 06:58:54 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 10 Mar 2022 06:58:54 GMT Subject: RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion Message-ID: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> In class sun.security.ssl.ProtocolVersion, the exception message for unsupported protocol needs a space. ProtocolVersion pv = ProtocolVersion.nameOf(pn); if (pv == null) { throw new IllegalArgumentException( "Unsupported protocol" + pn); } ------------- Commit messages: - 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion Changes: https://git.openjdk.java.net/jdk/pull/7769/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7769&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282932 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7769/head:pull/7769 PR: https://git.openjdk.java.net/jdk/pull/7769 From xuelei at openjdk.java.net Thu Mar 10 07:09:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 10 Mar 2022 07:09:36 GMT Subject: RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion In-Reply-To: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> References: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> Message-ID: On Thu, 10 Mar 2022 06:52:14 GMT, John Jiang wrote: > In class sun.security.ssl.ProtocolVersion, the exception message for unsupported protocol needs a space. > > ProtocolVersion pv = ProtocolVersion.nameOf(pn); > if (pv == null) { > throw new IllegalArgumentException( > "Unsupported protocol" + pn); > } Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7769 From duke at openjdk.java.net Thu Mar 10 08:52:19 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Mar 2022 08:52:19 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 16:09:01 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/java/lang/invoke/MethodType.java line 910: > >> 908: if (skipPos > myLen || myLen - skipPos > fullLen) >> 909: return false; >> 910: List> myList = List.of(ptypes); > > imo should revert this one together with that proxy parameter one Reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Thu Mar 10 08:52:17 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Mar 2022 08:52:17 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8282662: Revert dubious changes in MethodType ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/5bbe8c4e..e765c42a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From dfuchs at openjdk.java.net Thu Mar 10 10:34:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Mar 2022 10:34:43 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For simple webserver resource files - should the copyright year be 2022? ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From mullan at openjdk.java.net Thu Mar 10 14:01:48 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 10 Mar 2022 14:01:48 GMT Subject: RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion In-Reply-To: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> References: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> Message-ID: On Thu, 10 Mar 2022 06:52:14 GMT, John Jiang wrote: > In class sun.security.ssl.ProtocolVersion, the exception message for unsupported protocol needs a space. > > ProtocolVersion pv = ProtocolVersion.nameOf(pn); > if (pv == null) { > throw new IllegalArgumentException( > "Unsupported protocol" + pn); > } Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java line 293: > 291: if (pv == null) { > 292: throw new IllegalArgumentException( > 293: "Unsupported protocol " + pn); I think you should also add a colon so this reads better, i.e.: `"Unsupported protocol: " + pn);` ------------- PR: https://git.openjdk.java.net/jdk/pull/7769 From jjiang at openjdk.java.net Thu Mar 10 14:38:27 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 10 Mar 2022 14:38:27 GMT Subject: RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion [v2] In-Reply-To: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> References: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> Message-ID: > In class sun.security.ssl.ProtocolVersion, the exception message for unsupported protocol needs a space. > > ProtocolVersion pv = ProtocolVersion.nameOf(pn); > if (pv == null) { > throw new IllegalArgumentException( > "Unsupported protocol" + pn); > } John Jiang has updated the pull request incrementally with one additional commit since the last revision: add colon ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7769/files - new: https://git.openjdk.java.net/jdk/pull/7769/files/51943b99..dccd29ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7769&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7769&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7769/head:pull/7769 PR: https://git.openjdk.java.net/jdk/pull/7769 From naoto at openjdk.java.net Thu Mar 10 17:03:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 17:03:45 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From dfuchs at openjdk.java.net Thu Mar 10 17:09:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Mar 2022 17:09:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato wrote: > IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. Thanks Naoto! I have no objection then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From mullan at openjdk.java.net Thu Mar 10 17:47:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 10 Mar 2022 17:47:44 GMT Subject: RFR: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion [v2] In-Reply-To: References: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> Message-ID: On Thu, 10 Mar 2022 14:38:27 GMT, John Jiang wrote: >> In class sun.security.ssl.ProtocolVersion, the exception message for unsupported protocol needs a space. >> >> ProtocolVersion pv = ProtocolVersion.nameOf(pn); >> if (pv == null) { >> throw new IllegalArgumentException( >> "Unsupported protocol" + pn); >> } > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > add colon Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7769 From achung at openjdk.java.net Thu Mar 10 17:55:44 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Thu, 10 Mar 2022 17:55:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: moved CurrencyNames changes to jdk.localedata ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00-01 Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From jjiang at openjdk.java.net Thu Mar 10 18:28:45 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Thu, 10 Mar 2022 18:28:45 GMT Subject: Integrated: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion In-Reply-To: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> References: <-5fhXlBEWYZJAsDQdu4wEpdcT8MXL7K1lJsarcieryw=.1c710106-b22f-451a-a630-0f3205b6508e@github.com> Message-ID: On Thu, 10 Mar 2022 06:52:14 GMT, John Jiang wrote: > In class sun.security.ssl.ProtocolVersion, the exception message for unsupported protocol needs a space. > > ProtocolVersion pv = ProtocolVersion.nameOf(pn); > if (pv == null) { > throw new IllegalArgumentException( > "Unsupported protocol" + pn); > } This pull request has now been integrated. Changeset: 1f295239 Author: John Jiang URL: https://git.openjdk.java.net/jdk/commit/1f295239b97cccfff24df259215d34c712065867 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion Reviewed-by: xuelei, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7769 From cjplummer at openjdk.java.net Thu Mar 10 19:06:43 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 10 Mar 2022 19:06:43 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com> On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 305: > 303: {"Thread not suspended", "Thread nicht unterbrochen"}, > 304: {"thread group number description name", "{0,number,integer}. {1} {2}"}, > 305: {"Threadgroup name not specified.", "Name der Threadgruppe nicht angegeben."}, Same comment here as mentioned in TTYResources_ja.java. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 342: > 340: {"watch modification of", "\u00C4nderung von {0}.{1} \u00FCberwachen"}, > 341: {"zz help text", > 342: "** Befehlsliste **\nconnectors -- Listet verf\u00FCgbare Connectors und Transporte in dieser VM auf\n\nrun [class [args]] -- Startet die Ausf\u00FChrung der Hauptklasse der Anwendung\n\nthreads [threadgroup] -- Listet Threads auf\nthread -- Legt den Standardthread fest\nsuspend [thread id(s)] -- Unterbricht Threads (Standard: all)\nresume [thread id(s)] -- Nimmt Threads wieder auf (Standard: all)\nwhere [ | all] -- Gibt den Stack eines Threads aus\nwherei [ | all] -- Gibt den Stack eines Threads mit PC-Informationen aus\nup [n frames] -- Verschiebt den Stack eines Threads nach oben\ndown [n frames] -- Verschiebt den Stack eines Threads nach unten\nkill -- Bricht einen Thread mit dem angegebenen Ausnahmeobjekt ab\ninterrupt -- Unterbricht einen Thread\n\nprint -- Gibt den Wert eines Ausdrucks aus\ndump -- Gibt alle Objektinformationen aus\neval -- Bewertet einen Ausdruck (wie \"print\")\nset = -- Weist einem Feld/einer Variablen/einem Arrayelement einen neuen Wert zu\nlocals -- Gibt alle lokalen Variablen im aktuellen Stackframe aus\n\nclasses -- Listet derzeit bekannte Klassen auf\nclass -- Zeigt Details einer benannten Klasse an\nmethods -- Listet die Methoden einer Klasse auf\nfields -- Listet die Felder einer Klasse auf\n\nthreadgroups -- Listet Threadgruppen auf\nthreadgroup -- Legt die aktuelle Threadgruppe fest\n\nstop [go|thread] [] \n -- Legt einen Breakpoint fest\n -- Wenn Sie keine Optionen angeben, wird die aktuelle Breakpoint-Liste ausgegeben\n -- Wenn Sie \"go\" angeben, wird der Vorgang nach dem Stoppen sofort wiederaufgenommen\n -- Wenn Sie \"thread\" angeben, wird nur der Thread unterbrochen, in dem gestoppt wurde\n -- Wenn Sie weder \"go\" noch \"thread\" angeben, werden alle Threads unterbrochen\n -- Wenn Sie eine ganzzahlige angeben, wird der Vorgang nur im angegebenen Thread gestoppt\n -- \"at\" und \"in\" haben die gleiche Bedeutung\n -- kann eine Zeilennummer oder eine Methode sein:\n -- :\n -- .[(argument_type,...)]\nclear .[(argument_type,...)]\n -- L\u00F6scht einen Breakpoint in einer Methode\nclear : -- L\u00F6scht einen Breakpoint bei einer Zeile\nclear -- Listet Breakpoints auf\ncatch [uncaught|caught|all] |\n -- Break bei der angegebenen Ausnahme\nignore [uncaught|caught|all] |\n -- Bricht \"catch\" f\u00FCr die angegebene Ausnahme ab\nwatch [access|all] .\n -- \u00DCberwacht Zugriffe/\u00C4nderungen eines Feldes\nunwatch [access|all] .\n -- Hebt die \u00DCberwachung der Zugriffe/\u00C4nderungen eines Feldes auf\ntrace [go] methods [thread]\n -- Verfolgt Methodenstarts und -beendigungen.\n -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\ntrace [go] method exit | exits [thread]\n -- Verfolgt die Beendigung der aktuellen Methode oder die Beendigungen aller Methoden\n -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\nuntrace [methods] -- Stoppt das Tracing von Methodenstarts und/oder -beendigungen\nstep -- F\u00FChrt die aktuelle Zeile aus\nstep up -- Ausf\u00FChren, bis die aktuelle Methode an den Aufrufer zur\u00FCckgegeben wird\nstepi -- F\u00FChrt die aktuelle Anweisung aus\nnext -- Eine Zeile weiter (Aufrufe auslassen)\ncont -- Setzt die Ausf\u00FChrung ab dem Breakpoint fort\n\nlist [line number|method] -- Gibt den Quellcode aus\nuse (or sourcepath) [source file path]\n -- Zeigt den Quellpfad an oder \u00E4ndert diesen\nexclude [, ... | \"none\"]\n -- Meldet keine Schritt- oder Methodenereignisse f\u00FCr angegebene Klassen\nclasspath -- Gibt Classpath-Informationen aus der Ziel-VM aus\n\nmonitor -- F\u00FChrt bei jedem Programmstopp einen Befehl aus\nmonitor -- Listet Monitore auf\nunmonitor -- L\u00F6scht einen Monitor\nread -- Liest eine Befehlsdatei und f\u00FChrt diese aus\n\nlock -- Gibt Sperrinformationen f\u00FCr ein Objekt aus\nthreadlocks [thread id] -- Gibt Sperrinformationen f\u00FCr einen Thread aus\n\npop -- Holt den Stack bis zum aktuellen Frame (einschlie\u00DFlich)\nreenter -- Wie \"pop\", aber der aktuelle Frame wird wieder eingegeben\nredefine \n -- Definiert den Code f\u00FCr eine Klasse neu\n\ndisablegc -- Verhindert die Garbage Collection eines Objekts\nenablegc -- L\u00E4sst die Garbage Collection eines Objekts zu\n\n!! -- Wiederholt den letzten Befehl\n -- Wiederholt einen Befehl n-mal\nrepeat -- Zeigt an, ob die Wiederholung durch leeren Befehl im GDB-Stil aktiviert ist\nrepeat -- Aktiviert/deaktiviert die Wiederholung im GDB-Stil\n# -- Verwerfen (kein Vorgang)\nhelp (oder ?) -- Listet Befehle auf\ndbgtrace [flag] -- Identisch mit der Befehlszeilenoption \"dbgtrace\"\nversion -- Gibt Versionsinformationen aus\nexit (oder quit) -- Beendet den Debugger\n\n: Ein vollst\u00E4ndiger Klassenname mit Package-Qualifiers\n: Ein Klassenname mit einem Platzhalter am Anfang oder Ende (\"*\")\n: Threadnummer aus dem Befehl \"threads\"\n: Ein Ausdruck der Java(TM)-Programmiersprache.\nDer Gro\u00DFteil der g\u00E4ngigen Syntax wird unterst\u00FCtzt.\n\nStartbefehle k\u00F6nnen in \"jdb.ini\" oder \".jdbrc\" abgelegt werden\nin user.home oder user.dir"}, Same comment here as mentioned in TTYResources_ja.java. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305: > 303: {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"}, > 304: {"thread group number description name", "{0,number,integer}. {1} {2}"}, > 305: {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"}, I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 342: > 340: {"watch modification of", "{0}.{1}\u306E\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1"}, > 341: {"zz help text", > 342: "** \u30B3\u30DE\u30F3\u30C9\u30FB\u30EA\u30B9\u30C8 **\nconnectors -- \u3053\u306EVM\u5185\u306E\u4F7F\u7528\u53EF\u80FD\u306A\u30B3\u30CD\u30AF\u30BF\u3068\u30C8\u30E9\u30F3\u30B9\u30DD\u30FC\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\n\nrun [class [args]] -- \u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u30E1\u30A4\u30F3\u30FB\u30AF\u30E9\u30B9\u306E\u5B9F\u884C\u3092\u958B\u59CB\u3057\u307E\u3059\n\nthreads [threadgroup] -- \u30B9\u30EC\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthread -- \u30C7\u30D5\u30A9\u30EB\u30C8\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u8A2D\u5B9A\u3057\u307E\u3059\nsuspend [thread id(s)] -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nresume [thread id(s)] -- \u30B9\u30EC\u30C3\u30C9\u3092\u518D\u958B\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nwhere [ | all] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30C0\u30F3\u30D7\u3057\u307E\u3059\nwherei [ | all]-- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092pc\u60C5\u5831\u3068\u3068\u3082\u306B\u30C0\u30F3\u30D7\u3057\u307E\u3059\nup [n frames] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0A\u306B\u79FB\u52D5\u3057\u307E\u3059\ndown [n frames] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0B\u306B\u79FB\u52D5\u3057\u307E\u3059\nkill -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u3067\u30B9\u30EC\u30C3\u30C9\u3092\u5F37\u5236\u7D42\u4E86\u3057\u307E\u3059\ninterrupt -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n\nprint -- \u5F0F\u306E\u5024\u3092\u51FA\u529B\u3057\u307E\u3059\ndump -- \u3059\u3079\u3066\u306E\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u60C5\u58 31\u3092\u51FA\u529B\u3057\u307E\u3059\neval -- \u5F0F\u3092\u8A55\u4FA1\u3057\u307E\u3059(print\u3068\u540C\u3058)\nset = -- \u65B0\u3057\u3044\u5024\u3092\u30D5\u30A3\u30FC\u30EB\u30C9/\u5909\u6570/\u914D\u5217\u8981\u7D20\u306B\u4EE3\u5165\u3057\u307E\u3059\nlocals -- \u73FE\u5728\u306E\u30B9\u30BF\u30C3\u30AF\u30FB\u30D5\u30EC\u30FC\u30E0\u5185\u306E\u3059\u3079\u3066\u306E\u30ED\u30FC\u30AB\u30EB\u5909\u6570\u3092\u51FA\u529B\u3057\u307E\u3059\n\nclasses -- \u73FE\u5728\u65E2\u77E5\u306E\u30AF\u30E9\u30B9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nclass -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u8A73\u7D30\u3092\u8868\u793A\u3057\u307E\u3059\nmethods -- \u30AF\u30E9\u30B9\u306E\u30E1\u30BD\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nfields -- \u30AF\u30E9\u30B9\u306E\u30D5\u30A3\u30FC\u30EB\u30C9\u3092\u30EA\u30B9\u30C8\u305 7\u307E\u3059\n\nthreadgroups -- \u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthreadgroup -- \u73FE\u5728\u306E\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n\nstop [go|thread] [] \n -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n -- \u30AA\u30D7\u30B7\u30E7\u30F3\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u306E\u73FE\u5728\u306E\u30EA\u30B9\u30C8\u304C\u51FA\u529B\u3055\u308C\u307E\u3059\n -- \"go\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u505C\u6B62\u5F8C\u3059\u3050\u306B\u518D\u958B\u3057\u307E\u3059\n -- \"thread\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\ u505C\u6B62\u3057\u305F\u30B9\u30EC\u30C3\u30C9\u306E\u307F\u4E2D\u65AD\u3057\u307E\u3059\n -- \"go\"\u3082\"thread\"\u3082\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n -- \u6574\u6570\u306E\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u6307\u5B9A\u3055\u308C\u305F\u30B9\u30EC\u30C3\u30C9\u3067\u306E\u307F\u505C\u6B62\u3057\u307E\u3059\n -- \"at\"\u3068\"in\"\u306F\u540C\u3058\u610F\u5473\u3092\u6301\u3061\u307E\u3059\n -- \u306F\u884C\u756A\u53F7\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u306B\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059:\n -- :\n -- .[(argument_type,...)]\nclear .[(argument_type,...)]\n -- \u30E1\u30BD\u30C3\u30C9\u5185\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear : -- \u884C\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\ncatch [uncaught|caught|all] |\n -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u304C\u767A\u751F\u3057\u305F\u3068\u304D\u306B\u30D6\u30EC\u30FC\u30AF\u3057\u307E\u3059\nignore [uncaught|caught|all] |\n -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u306E'catch'\u3092\u53D6\u308A\u6D88\u3057\u307E\u3059\nwatch [access|all] .\n -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u3092\u30A6\u3 0A9\u30C3\u30C1\u3057\u307E\u3059\nunwatch [access|all] .\n -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1\u3092\u4E2D\u6B62\u3057\u307E\u3059\ntrace [go] methods [thread]\n -- \u30E1\u30BD\u30C3\u30C9\u306E\u5165\u308A\u53E3\u3068\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\u3002\n -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\ntrace [go] method exit | exits [thread]\n -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u307E\u305F\u306F\u3059\u3079\u3066\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\n -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\ u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\nuntrace [methods] -- \u30E1\u30BD\u30C3\u30C9\u306E\u958B\u59CB\u307E\u305F\u306F\u7D42\u4E86\u306E\u30C8\u30EC\u30FC\u30B9\u3092\u505C\u6B62\u3057\u307E\u3059\nstep -- \u73FE\u5728\u306E\u884C\u3092\u5B9F\u884C\u3057\u307E\u3059\nstep up -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u304C\u30E1\u30BD\u30C3\u30C9\u306E\u547C\u51FA\u3057\u5143\u306B\u623B\u308B\u307E\u3067\u5B9F\u884C\u3057\u307E\u3059\nstepi -- \u73FE\u5728\u306E\u547D\u4EE4\u3092\u5B9F\u884C\u3057\u307E\u3059\nnext -- 1\u884C\u3092\u30B9\u30C6\u30C3\u30D7\u5B9F\u884C\u3057\u307E\u3059(\u547C\u51FA\u3057\u3092\u30B9\u30C6\u30C3\u30D7\u30AA\u30FC\u30D0\u30FC)\ncont -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u304B\u3089\u5B9F\u884C\u3092\u7D9A\u884C\u3057\u307E\u3059\n\nlist [line number|method] -- \u30BD\u30FC\u30B9\u30FB\u30B3\u30FC\u30C9\u3092\u 51FA\u529B\u3057\u307E\u3059\nuse (or sourcepath) [source file path]\n -- \u30BD\u30FC\u30B9\u30FB\u30D1\u30B9\u3092\u8868\u793A\u307E\u305F\u306F\u5909\u66F4\u3057\u307E\u3059\nexclude [, ... | \"none\"]\n -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u30B9\u30C6\u30C3\u30D7\u3084\u30E1\u30BD\u30C3\u30C9\u30FB\u30A4\u30D9\u30F3\u30C8\u3092\u5831\u544A\u3057\u307E\u305B\u3093\nclasspath -- \u30BF\u30FC\u30B2\u30C3\u30C8VM\u304B\u3089\u30AF\u30E9\u30B9\u30D1\u30B9\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\nmonitor -- \u30D7\u30ED\u30B0\u30E9\u30E0\u304C\u505C\u6B62\u3059\u308B\u305F\u3073\u306B\u30B3\u30DE\u30F3\u30C9\u3092\u5B9F\u884C\u3057\u307E\u3059\nmonitor -- \u30E2\u30CB\u30BF\u30FC\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nunmonitor -- \u30E2\u30CB\u30BF\u30FC\u3092\u524A\u9664\u3057\u307E\u3059\nread -- \u30B 3\u30DE\u30F3\u30C9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u8AAD\u307F\u53D6\u3063\u3066\u5B9F\u884C\u3057\u307E\u3059\n\nlock -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nthreadlocks [thread id] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\npop -- \u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u307E\u3067\u306E\u3059\u3079\u3066\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30DD\u30C3\u30D7\u3057\u307E\u3059\nreenter -- pop\u3068\u540C\u3058\u3067\u3059\u304C\u3001\u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u304C\u518D\u5165\u529B\u3055\u308C\u307E\u3059\nredefine \n -- \u30AF\u30E9\u30B9\u306E\u30B3\u30FC\u30C9\u3092\u518D\u5B9A\u7FA9\u3057\u307E\u3059\n\ndisablegc -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3 \u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u6291\u5236\u3057\u307E\u3059\nenablegc -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3\u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u8A31\u53EF\u3057\u307E\u3059\n\n!! -- \u6700\u5F8C\u306E\u30B3\u30DE\u30F3\u30C9\u3092\u7E70\u308A\u8FD4\u3057\u307E\u3059\n -- \u30B3\u30DE\u30F3\u30C9\u3092n\u56DE\u7E70\u308A\u8FD4\u3057\u307E\u3059\nrepeat -- GDB\u5F62\u5F0F\u306E\u7A7A\u306E\u30B3\u30DE\u30F3\u30C9\u306E\u7E70\u8FD4\u3057\u304C\u6709\u52B9\u306B\u306A\u3063\u3066\u3044\u308B\u304B\u3069\u3046\u304B\u3092\u793A\u3057\u307E\u3059\nrepeat -- GDB\u5F62\u5F0F\u306E\u7E70\u8FD4\u3057\u3092\u6709\u52B9/\u7121\u52B9\u306B\u3057\u307E\u3059\n# -- \u7834\u68C4\u3057\u307E\u3059(\u64CD\u4F5C\u306A\u3057)\nhelp (\u307E\u305F\u306F?) -- \u30B3\u30DE\u30F3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u3 07E\u3059\ndbgtrace [flag] -- dbgtrace\u30B3\u30DE\u30F3\u30C9\u30FB\u30E9\u30A4\u30F3\u30FB\u30AA\u30D7\u30B7\u30E7\u30F3\u3068\u540C\u3058\u3067\u3059\nversion -- \u30D0\u30FC\u30B8\u30E7\u30F3\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nexit (\u307E\u305F\u306Fquit) -- \u30C7\u30D0\u30C3\u30AC\u3092\u7D42\u4E86\u3057\u307E\u3059\n\n: \u30D1\u30C3\u30B1\u30FC\u30B8\u4FEE\u98FE\u5B50\u3092\u542B\u3080\u5B8C\u5168\u30AF\u30E9\u30B9\u540D\n: \u5148\u982D\u307E\u305F\u306F\u672B\u5C3E\u306E\u30EF\u30A4\u30EB\u30C9\u30AB\u30FC\u30C9('*')\u3092\u542B\u3080\u30AF\u30E9\u30B9\u540D\n: 'threads'\u30B3\u30DE\u30F3\u30C9\u3067\u5831\u544A\u3055\u308C\u308B\u30B9\u30EC\u30C3\u30C9\u756A\u53F7\n: Java(TM)\u30D7\u30ED\u30B0\u30E9\u30DF\u30F3\u30B0\u8A00\u8A9E\u306E\u5F0F\u3002\n\u307B\u3068\u3093\u3069\u306E\u4E00\u822C\u7684\u306A\u69CB\u6587\u304C\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u307E\u3059\u 3002\n\n\u8D77\u52D5\u30B3\u30DE\u30F3\u30C9\u306F\u3001\"jdb.ini\"\u307E\u305F\u306F\".jdbrc\"\u306B\u914D\u7F6E\u3067\u304D\u307E\u3059\n(user.home\u307E\u305F\u306Fuser.dir\u5185)"}, Also as part of #7687 there is a new entry for the `threadgroup` command without any argument. This used to produce the "Threadgroup name not specified" error message which is I mentioned above was removed. It now has supported functionality, so there should be two `threadgroup` entries: "threadgroup -- set current threadgroup to \n" + "threadgroup -- set current threadgroup back to the top level threadgroup\n" + src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 305: > 303: {"Thread not suspended", "\u672A\u6302\u8D77\u7EBF\u7A0B"}, > 304: {"thread group number description name", "{0,number,integer}\u3002{1} {2}"}, > 305: {"Threadgroup name not specified.", "\u672A\u6307\u5B9A\u7EBF\u7A0B\u7EC4\u540D\u3002"}, Same comment here as mentioned in TTYResources_ja.java. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 342: > 340: {"watch modification of", "\u76D1\u89C6{0}.{1}\u7684\u4FEE\u6539"}, > 341: {"zz help text", > 342: "** \u547D\u4EE4\u5217\u8868 **\nconnectors -- \u5217\u51FA\u6B64 VM \u4E2D\u53EF\u7528\u7684\u8FDE\u63A5\u5668\u548C\u4F20\u8F93\n\nrun [class [args]] -- \u5F00\u59CB\u6267\u884C\u5E94\u7528\u7A0B\u5E8F\u7684\u4E3B\u7C7B\n\nthreads [threadgroup] -- \u5217\u51FA\u7EBF\u7A0B\nthread -- \u8BBE\u7F6E\u9ED8\u8BA4\u7EBF\u7A0B\nsuspend [thread id(s)] -- \u6302\u8D77\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nresume [thread id(s)] -- \u6062\u590D\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nwhere [ | all] -- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808\nwherei [ | all]-- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808, \u4EE5\u53CA pc \u4FE1\u606F\nup [n frames] -- \u4E0A\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\ndown [n frames] -- \u4E0B\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\nkill -- \u7EC8\u6B62\u5177\u6709\u7ED9\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u5BF9\u8C61\u7684\u7EBF\u7A0B \ninterrupt -- \u4E2D\u65AD\u7EBF\u7A0B\n\nprint -- \u8F93\u51FA\u8868\u8FBE\u5F0F\u7684\u503C\ndump -- \u8F93\u51FA\u6240\u6709\u5BF9\u8C61\u4FE1\u606F\neval -- \u5BF9\u8868\u8FBE\u5F0F\u6C42\u503C (\u4E0E print \u76F8\u540C)\nset = -- \u5411\u5B57\u6BB5/\u53D8\u91CF/\u6570\u7EC4\u5143\u7D20\u5206\u914D\u65B0\u503C\nlocals -- \u8F93\u51FA\u5F53\u524D\u5806\u6808\u5E27\u4E2D\u7684\u6240\u6709\u672C\u5730\u53D8\u91CF\n\nclasses -- \u5217\u51FA\u5F53\u524D\u5DF2\u77E5\u7684\u7C7B\nclass -- \u663E\u793A\u5DF2\u547D\u540D\u7C7B\u7684\u8BE6\u7EC6\u8D44\u6599\nmethods -- \u5217\u51FA\u7C7B\u7684\u65B9\u6CD5\nfields -- \u5217\u51FA\u7C7B\u7684\u5B57\u6BB5\n\nthreadgroups -- \u5217\u51FA\u7EBF\u7A0B\u7EC4\nthreadgroup -- \u8BBE\u7F6E\u5F53\u524D\u7EBF\u7A0B\u7EC4\n\nstop [go| thread] [] \n -- \u8BBE\u7F6E\u65AD\u70B9\n -- \u5982\u679C\u672A\u63D0\u4F9B\u4EFB\u4F55\u9009\u9879\uFF0C\u5219\u5C06\u6253\u5370\u5F53\u524D\u65AD\u70B9\u5217\u8868\n -- \u5982\u679C\u6307\u5B9A \"go\"\uFF0C\u5219\u5728\u505C\u6B62\u540E\u7ACB\u5373\u6062\u590D\n -- \u5982\u679C\u6307\u5B9A \"thread\"\uFF0C\u5219\u4EC5\u6302\u8D77\u5728\u5176\u4E2D\u505C\u6B62\u7684\u7EBF\u7A0B\n -- \u5982\u679C\u65E2\u672A\u6307\u5B9A \"go\" \u4E5F\u672A\u6307\u5B9A \"thread\"\uFF0C\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\n -- \u5982\u679C\u6307\u5B9A\u4EE5\u6574\u6570\u8868\u793A\u7684 \uFF0C\u5219\u4EC5\u5728\u6307\u5B9A\u7684\u7EBF\u7A0B\u4E2D\u505C\u6B62\n -- \"at\" \u548C \"in\" \u7684\u542B\u4E49\u76F8\u540C\n -- \u53EF\u4EE5\u662F\u884C\u53 F7\u6216\u65B9\u6CD5\uFF1A\n -- :\n -- .[(argument_type,...)]\nclear .[(argument_type,...)]\n -- \u6E05\u9664\u65B9\u6CD5\u4E2D\u7684\u65AD\u70B9\nclear : -- \u6E05\u9664\u884C\u4E2D\u7684\u65AD\u70B9\nclear -- \u5217\u51FA\u65AD\u70B9\ncatch [uncaught|caught|all] |\n -- \u51FA\u73B0\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u65F6\u4E2D\u65AD\nignore [uncaught|caught|all] |\n -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF, \u53D6\u6D88 'catch'\nwatch [access|all] .\n -- \u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u8BBF\u95EE/\u4FEE\u6539\nunwatch [access|all] .\n -- \u505C\u6B62\u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u 8BBF\u95EE/\u4FEE\u6539\ntrace [go] methods [thread]\n -- \u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C\u9000\u51FA\u3002\n -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\ntrace [go] method exit | exits [thread]\n -- \u8DDF\u8E2A\u5F53\u524D\u65B9\u6CD5\u7684\u9000\u51FA, \u6216\u8005\u6240\u6709\u65B9\u6CD5\u7684\u9000\u51FA\n -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\nuntrace [methods] -- \u505C\u6B62\u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C/\u6216\u9000\u51FA\nstep -- \u6267\u884C\u5F53\u524D\u884C\nstep up -- \u4E00\u76F4\u6267\u884C, \u76F4\u5230\u5F53\u524D\u65B9\u6CD5\u8FD4\u56DE\u5230\u5176\u8C03\u7528\u65B9\nstepi -- \u6267\u884C\u5F53\u524D\u6307\u4EE4\n\u4E0B\u4E00\u6B65 -- \u6B65\u8FDB\u4E00\u884C (\u6B65\u8FC7\u 8C03\u7528)\ncont -- \u4ECE\u65AD\u70B9\u5904\u7EE7\u7EED\u6267\u884C\n\nlist [line number|method] -- \u8F93\u51FA\u6E90\u4EE3\u7801\nuse (\u6216 sourcepath) [source file path]\n -- \u663E\u793A\u6216\u66F4\u6539\u6E90\u8DEF\u5F84\nexclude [, ... | \"none\"]\n -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u7C7B, \u4E0D\u62A5\u544A\u6B65\u9AA4\u6216\u65B9\u6CD5\u4E8B\u4EF6\nclasspath -- \u4ECE\u76EE\u6807 VM \u8F93\u51FA\u7C7B\u8DEF\u5F84\u4FE1\u606F\n\nmonitor -- \u6BCF\u6B21\u7A0B\u5E8F\u505C\u6B62\u65F6\u6267\u884C\u547D\u4EE4\nmonitor -- \u5217\u51FA\u76D1\u89C6\u5668\nunmonitor -- \u5220\u9664\u76D1\u89C6\u5668\nread -- \u8BFB\u53D6\u5E76\u6267\u884C\u547D\u4EE4\u6587\u4EF6\n\nlock -- \u8F93\u51FA\u5BF9\u8C61\u7684\u9501\u4FE1\u606F\nthreadlocks [thread id] -- \u8F93\u51FA\u7EBF\u7A0B\u7684\u9501 \u4FE1\u606F\n\npop -- \u901A\u8FC7\u5F53\u524D\u5E27\u51FA\u6808, \u4E14\u5305\u542B\u5F53\u524D\u5E27\nreenter -- \u4E0E pop \u76F8\u540C, \u4F46\u91CD\u65B0\u8FDB\u5165\u5F53\u524D\u5E27\nredefine \n -- \u91CD\u65B0\u5B9A\u4E49\u7C7B\u7684\u4EE3\u7801\n\ndisablegc -- \u7981\u6B62\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\nenablegc -- \u5141\u8BB8\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\n\n!! -- \u91CD\u590D\u6267\u884C\u6700\u540E\u4E00\u4E2A\u547D\u4EE4\n -- \u5C06\u547D\u4EE4\u91CD\u590D\u6267\u884C n \u6B21\nrepeat -- \u663E\u793A\u662F\u5426\u542F\u7528\u4E86 GDB \u6837\u5F0F\u7684\u7A7A\u547D\u4EE4\u91CD\u590D\nrepeat -- \u542F\u7528/\u7981\u7528 GDB \u6837\u5F0F\u7684\u91CD\u590D\n# -- \u653E\u5F03 (\u65E0\u64CD\u4F5C)\nhelp (\u6216 ?) -- \u5217\u51FA\u547D\u4EE4\ndbgtrace [flag] -- \u4E0E dbgtrace \u547D\u4EE4\u884C\u9009\u9879\u76F8\u540C\nversion -- \u8F93\u51FA\u7248\u672C\u4FE1\u606F\nexit (\u6216 quit) -- \u9000\u51FA\u8C03\u8BD5\u5668\n\n: \u5E26\u6709\u7A0B\u5E8F\u5305\u9650\u5B9A\u7B26\u7684\u5B8C\u6574\u7C7B\u540D\n: \u5E26\u6709\u524D\u5BFC\u6216\u5C3E\u968F\u901A\u914D\u7B26 ('*') \u7684\u7C7B\u540D\n: 'threads' \u547D\u4EE4\u4E2D\u62A5\u544A\u7684\u7EBF\u7A0B\u7F16\u53F7\n: Java(TM) \u7F16\u7A0B\u8BED\u8A00\u8868\u8FBE\u5F0F\u3002\n\u652F\u6301\u5927\u591A\u6570\u5E38\u89C1\u8BED\u6CD5\u3002\n\n\u53EF\u4EE5\u5C06\u542F\u52A8\u547D\u4EE4\u7F6E\u4E8E \"jdb.ini\" \u6216 \".jdbrc\" \u4E2D\n\u4F4D\u4E8E user.home \u6216 user.dir \u4E2D"}, Same comment here as mentioned in TTYResources_ja.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From naoto at openjdk.java.net Thu Mar 10 19:54:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 19:54:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP No need for these lines in each localized files, as English bundle contains them. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP Same here with `de` bundle. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP and here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From jamil.j.nimeh at oracle.com Fri Mar 11 15:25:25 2022 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 11 Mar 2022 07:25:25 -0800 Subject: Proposal for potential new feature: TLS Certificate Compression In-Reply-To: <9C3E05A5-6DA1-4E11-91FC-EECC8A101742@Tencent.Com> References: <9C3E05A5-6DA1-4E11-91FC-EECC8A101742@Tencent.Com> Message-ID: <1da938bb-ef67-52e3-ad8e-e945c1718c7e@oracle.com> Hi Xuelei, After reading over your descriptions and the supporting documentation this certainly seems like it would be a nice addition to JSSE.? It definitely seems like a performance win for QUIC and also for bandwidth-constrained devices.? I'm all for seeing this JEP proceed.? I'll likely have more comments down the line and I have taken a look at the proposed code changes and will go back and do a deeper dive on it.? I just don't want to jump any of the JEP process hoops by talking about code changes before some of the important first steps for the JEP have been cleared.? But you've got my support on this one! --Jamil On 3/7/2022 11:46 AM, xueleifan(XueleiFan) wrote: > Hi, > > The TLS Certificate Compression standard was described in RFC 8879, > and has been enabled in browser Chrome and Safari. What?s TLS > Certificate Compression and what?s the benefits of this feature? > > For TLS connections, a client must authenticate the identity of the > server. This typically involves verification that the identity of the > server is included in a certificate and that the certificate is issued > by a trusted entity. > > Where servers provide certificates for authentication, the size of the > certificate chain can consume a large number of bytes. Controlling the > size of certificate chains is critical to performance and security in > QUIC. TLS certificate compression has the potential to ameliorate the > attacks/problems by reducing the size of the handshakes to a size > compatible with the security restriction.? The TLS Certificate > Compression feature is an essential part for QUIC-TLS protocols. > > For more details, please refer to section 4.4 in RFC 9001 (Using TLS > to Secure QUIC): > --------- > Note: Where servers provide certificates for authentication, the size > of the certificate chain can consume a large number of bytes. > Controlling the size of certificate chains is critical to performance > in QUIC as servers are limited to sending 3 bytes for every byte > received prior to validating the client address; see Section 8.1 of > [QUIC-TRANSPORT]. The size of a certificate chain can be managed by > limiting the number of names or extensions; using keys with small > public key representations, like ECDSA; or by using certificate > compression [COMPRESS]. > ???? > > and a more detailed description in the blog ?Does the QUIC handshake > require compression to be > fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study). > ? I just copy part of the conclusion section of the bog here for your > quick reference. > --------- > First, the TLS certificate compression extension has a very large > impact on QUIC performance. Even though the extension is new and being > introduced fairly late in the process when compared to overall QUIC > deployment schedules, it seems quite important for both clients and > servers to implement the new extension so that the QUIC handshake can > live up to its billing. Without some help, 40% of QUIC full handshakes > would be no better than TCP, but compression can repair most of that > issue. I have heard of other non-standardized approaches to reducing > the size of the certificate chain, and they seem reasonable, but this > is a problem worth addressing immediately with the existing > compression extension. > ... > Lastly, data from the real world again proves to be more insightful > than intuition and is invaluable in making protocol design and > implementation decisions. When I started this work I expected the > impact of compression to be positive but marginally focused on a few > edge cases. The data shows this optimization lands right on the sweet > spot that ties configurations and the QUIC specification together and > impacts a large portion of QUIC handshakes. My thanks to the authors > of the compression extension. > --------- > > > Besides, reducing the amount of information exchanged during a TLS > handshake to a minimum helps to improve performance in environments, > for example Internet of Things, where devices are connected to a > network with a low bandwidth and lossy radio technology. > > This feature is a part to improve the performance of TLS connections, > and it is also a part of the path towards QUIC standards. > > Chrome support TLS certificate compression with Brotil compression > algorithm, and Safari support TLS certificate compression with Zlib > compression algorithm. > > In a summary, JDK could benefits from supporting RFC 8879 in the > following areas: > > ? Performance - Reduce latency and improve performance of TLS and QUIC > connections by support the TLS certificate compression standard in JDK. > ? Security - Mitigate the impact of amplification attacks threat by > reducing the size of the TLS handshakes with compressed certificates. > > What do you think? ?Do you want it a part of OpenJDK? ?Please feel > free to share you comments. > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Fri Mar 11 15:32:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Mar 2022 15:32:52 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata The security related changes look fine, except for the year 2021. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From wetmore at openjdk.java.net Sat Mar 12 01:46:42 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 12 Mar 2022 01:46:42 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:23:13 GMT, zzambers wrote: >>> Sure if more changes are desired I can pull your changes. When It comes to CSR I am not fully familiar with the >> process. Is action expected from my side? >> >> One of us needs to get the CSR approved. Why don't you pull the changes described in: >> >> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029209.html >> >> Assuming you are ok with the updated wording, I can create the CSR and submit. Once that it approved, then we can get this PR approved and you can integrate. >> >> Are you at contributor status? > > @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself). I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that. @zzambers, the CSR was approved yesterday, and is just waiting your integration. I will sponsor it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Mon Mar 14 10:41:40 2022 From: duke at openjdk.java.net (zzambers) Date: Mon, 14 Mar 2022 10:41:40 GMT Subject: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket [v2] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 01:43:16 GMT, Bradford Wetmore wrote: >> @bradfordwetmore Your changes look good to me. When it comes to wording, I'll let that to native english speaker(s) to judge :) (As I am not native english speaker myself). I built docs locally and result looks good (also links work), there was just one problem with brace, but I have fixed that. > > @zzambers, the CSR was approved yesterday, and is just waiting your integration. I will sponsor it. @bradfordwetmore, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From duke at openjdk.java.net Mon Mar 14 13:28:39 2022 From: duke at openjdk.java.net (zzambers) Date: Mon, 14 Mar 2022 13:28:39 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:12:06 GMT, Bradford Wetmore wrote: >> When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) >> >> As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) >> >> This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) >> >> I also ran jdk_security tests locally, which passed for me. >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 >> [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 >> [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 > > I am looking at a few things in this PR. Please ping me before integrating. > > I believe this code is correct, but checking on the overall USER_CANCELED strategy. @bradfordwetmore, it is ready from my side, but please take your time to do any checks, which you find necessary to make sure there is no problem here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From wetmore at openjdk.java.net Mon Mar 14 14:24:43 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 14 Mar 2022 14:24:43 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 Thanks, been working on another close issue. I should be finishing that shortly, ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From duke at openjdk.java.net Mon Mar 14 14:25:45 2022 From: duke at openjdk.java.net (zzambers) Date: Mon, 14 Mar 2022 14:25:45 GMT Subject: Integrated: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has changed as result of JDK-8216326 [2]. InputStream.close() / OutputStream.close() no longer perform half-close but full socket close, but API Note was never updated. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > [2] https://bugs.openjdk.java.net/browse/JDK-8216326 This pull request has now been integrated. Changeset: 08573cc3 Author: Zdenek Zambersky Committer: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/08573cc3b2370a697a7bd4ad0665ee20ae148d39 Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket Reviewed-by: wetmore, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7648 From achung at openjdk.java.net Mon Mar 14 16:41:48 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 14 Mar 2022 16:41:48 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com> References: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com> Message-ID: On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> moved CurrencyNames changes to jdk.localedata > > src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305: > >> 303: {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"}, >> 304: {"thread group number description name", "{0,number,integer}. {1} {2}"}, >> 305: {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"}, > > I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added. The translation was started before the updates to this file. This update can be done in the next msg drop. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From kizune at openjdk.java.net Mon Mar 14 17:41:55 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 14 Mar 2022 17:41:55 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata Marked as reviewed by kizune (Reviewer). Clientlibs related stuff looks correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From hchao at openjdk.java.net Mon Mar 14 17:52:27 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 14 Mar 2022 17:52:27 GMT Subject: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled Message-ID: When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. ------------- Commit messages: - remove tab in test - 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled Changes: https://git.openjdk.java.net/jdk/pull/7810/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7810&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282633 Stats: 137 lines in 5 files changed: 110 ins; 16 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7810/head:pull/7810 PR: https://git.openjdk.java.net/jdk/pull/7810 From xueleifan at tencent.com Mon Mar 14 18:21:26 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 14 Mar 2022 18:21:26 +0000 Subject: [Internet]Re: Proposal for potential new feature: TLS Certificate Compression In-Reply-To: <1da938bb-ef67-52e3-ad8e-e945c1718c7e@oracle.com> References: <9C3E05A5-6DA1-4E11-91FC-EECC8A101742@Tencent.Com> <1da938bb-ef67-52e3-ad8e-e945c1718c7e@oracle.com> Message-ID: <112601CA-A7BE-49AC-8210-FA7916FC9E32@Tencent.Com> Hi Jamil, Thank you for the support of this proposal. I am happy to move on to the next JEP process if no objections or comments in the coming weeks. Hi All, Please let me know if more time is required for the review of the proposal. Thanks, Xuelei On Mar 11, 2022, at 7:25 AM, Jamil Nimeh > wrote: Hi Xuelei, After reading over your descriptions and the supporting documentation this certainly seems like it would be a nice addition to JSSE. It definitely seems like a performance win for QUIC and also for bandwidth-constrained devices. I'm all for seeing this JEP proceed. I'll likely have more comments down the line and I have taken a look at the proposed code changes and will go back and do a deeper dive on it. I just don't want to jump any of the JEP process hoops by talking about code changes before some of the important first steps for the JEP have been cleared. But you've got my support on this one! --Jamil On 3/7/2022 11:46 AM, xueleifan(XueleiFan) wrote: Hi, The TLS Certificate Compression standard was described in RFC 8879, and has been enabled in browser Chrome and Safari. What?s TLS Certificate Compression and what?s the benefits of this feature? For TLS connections, a client must authenticate the identity of the server. This typically involves verification that the identity of the server is included in a certificate and that the certificate is issued by a trusted entity. Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance and security in QUIC. TLS certificate compression has the potential to ameliorate the attacks/problems by reducing the size of the handshakes to a size compatible with the security restriction. The TLS Certificate Compression feature is an essential part for QUIC-TLS protocols. For more details, please refer to section 4.4 in RFC 9001 (Using TLS to Secure QUIC): --------- Note: Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance in QUIC as servers are limited to sending 3 bytes for every byte received prior to validating the client address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a certificate chain can be managed by limiting the number of names or extensions; using keys with small public key representations, like ECDSA; or by using certificate compression [COMPRESS]. ???? and a more detailed description in the blog ?Does the QUIC handshake require compression to be fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study). I just copy part of the conclusion section of the bog here for your quick reference. --------- First, the TLS certificate compression extension has a very large impact on QUIC performance. Even though the extension is new and being introduced fairly late in the process when compared to overall QUIC deployment schedules, it seems quite important for both clients and servers to implement the new extension so that the QUIC handshake can live up to its billing. Without some help, 40% of QUIC full handshakes would be no better than TCP, but compression can repair most of that issue. I have heard of other non-standardized approaches to reducing the size of the certificate chain, and they seem reasonable, but this is a problem worth addressing immediately with the existing compression extension. ... Lastly, data from the real world again proves to be more insightful than intuition and is invaluable in making protocol design and implementation decisions. When I started this work I expected the impact of compression to be positive but marginally focused on a few edge cases. The data shows this optimization lands right on the sweet spot that ties configurations and the QUIC specification together and impacts a large portion of QUIC handshakes. My thanks to the authors of the compression extension. --------- Besides, reducing the amount of information exchanged during a TLS handshake to a minimum helps to improve performance in environments, for example Internet of Things, where devices are connected to a network with a low bandwidth and lossy radio technology. This feature is a part to improve the performance of TLS connections, and it is also a part of the path towards QUIC standards. Chrome support TLS certificate compression with Brotil compression algorithm, and Safari support TLS certificate compression with Zlib compression algorithm. In a summary, JDK could benefits from supporting RFC 8879 in the following areas: Performance - Reduce latency and improve performance of TLS and QUIC connections by support the TLS certificate compression standard in JDK. Security - Mitigate the impact of amplification attacks threat by reducing the size of the TLS handshakes with compressed certificates. What do you think? Do you want it a part of OpenJDK? Please feel free to share you comments. Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Mon Mar 14 20:08:31 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Mar 2022 20:08:31 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update again and undo DSA changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/f728aa7d..48f562ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=03-04 Stats: 45 lines in 9 files changed: 8 ins; 2 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From achung at openjdk.java.net Mon Mar 14 20:39:46 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 14 Mar 2022 20:39:46 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed repeated lines from ROOT bundle in CurrencyNames ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01-02 Stats: 675 lines in 3 files changed: 0 ins; 675 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From weijun at openjdk.java.net Mon Mar 14 21:30:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 14 Mar 2022 21:30:46 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 20:08:31 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update again and undo DSA changes Some small comments. Otherwise looks fine. src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 121: > 119: v = max; > 120: } > 121: } catch (NullPointerException | NoSuchAlgorithmException ne) { There is no need to mention NPE. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 101: > 99: // set default key sizes and apply our own algorithm-specific limits > 100: // override lower limit to disallow unsecure keys being generated > 101: // override upper limit to deter DOS attack No a P11 expert, but I assume `algorithm` here is already guaranteed to be in uppercase? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 122: > 120: default -> { > 121: throw new ProviderException > 122: ("Unrecognized algorithm for checking key size"); If it's an unknown key algorithm, is it possible we just ignore it and keep using `minKeyLen` and `maxKeyLen`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From naoto at openjdk.java.net Mon Mar 14 21:58:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Mar 2022 21:58:45 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed repeated lines from ROOT bundle in CurrencyNames src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1: > 1: # The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file) ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From weijun at openjdk.java.net Tue Mar 15 01:20:39 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 15 Mar 2022 01:20:39 GMT Subject: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 17:41:28 GMT, Hai-May Chao wrote: > When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. I think `include jdk.disabled.namedCurves` can also appear in the legacy algorithms, so it's likely there should also be a "key.bit.eccurve.weak" for jarsigner. ------------- PR: https://git.openjdk.java.net/jdk/pull/7810 From valeriep at openjdk.java.net Tue Mar 15 01:47:51 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 01:47:51 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:08:30 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again and undo DSA changes > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 121: > >> 119: v = max; >> 120: } >> 121: } catch (NullPointerException | NoSuchAlgorithmException ne) { > > There is no need to mention NPE. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From hchao at openjdk.java.net Tue Mar 15 15:37:25 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 15 Mar 2022 15:37:25 GMT Subject: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled [v2] In-Reply-To: References: Message-ID: > When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Check curve in jdk.security.legacyAlgorithms, and update testcase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7810/files - new: https://git.openjdk.java.net/jdk/pull/7810/files/cea8113f..993e09fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7810&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7810&range=00-01 Stats: 45 lines in 3 files changed: 36 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7810/head:pull/7810 PR: https://git.openjdk.java.net/jdk/pull/7810 From hchao at openjdk.java.net Tue Mar 15 15:37:26 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 15 Mar 2022 15:37:26 GMT Subject: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 17:41:28 GMT, Hai-May Chao wrote: > When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. Individual name curves could be added to `jdk.security.legacyAlgorithms` instead of by `jdk.disabled.namedCurves`, so changed `jarsigner` to display the named curves in the legacy algorithms. ------------- PR: https://git.openjdk.java.net/jdk/pull/7810 From weijun at openjdk.java.net Tue Mar 15 15:46:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 15 Mar 2022 15:46:45 GMT Subject: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled [v2] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 15:37:25 GMT, Hai-May Chao wrote: >> When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Check curve in jdk.security.legacyAlgorithms, and update testcase Change looks fine to me. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7810 From hchao at openjdk.java.net Tue Mar 15 15:58:48 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 15 Mar 2022 15:58:48 GMT Subject: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 01:16:59 GMT, Weijun Wang wrote: >> When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. > > I think `include jdk.disabled.namedCurves` can also appear in the legacy algorithms, so it's likely there should also be a "key.bit.eccurve.weak" for jarsigner. @wangweij Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7810 From hchao at openjdk.java.net Tue Mar 15 15:58:50 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 15 Mar 2022 15:58:50 GMT Subject: Integrated: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled In-Reply-To: References: Message-ID: <4obJdW08oGgVjHm9bJNtM2HcxtGVaw71IKk5tZ5SceE=.2f0e6dd9-f1ef-4118-90d6-ccb2d2d6968c@github.com> On Mon, 14 Mar 2022 17:41:28 GMT, Hai-May Chao wrote: > When a named curve is disabled in `jdk.disabled.namedCurves` property which is included in `jdk.jar.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled named curve as a result of its disabled algorithm constraint checking. This clarifies why an EC key is disabled in its warning and verbose output. This pull request has now been integrated. Changeset: f43ffe21 Author: Hai-May Chao URL: https://git.openjdk.java.net/jdk/commit/f43ffe211f8ff287697092c39e4c25a16b40a383 Stats: 176 lines in 5 files changed: 145 ins; 16 del; 15 mod 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/7810 From weijun at openjdk.java.net Tue Mar 15 19:54:39 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 15 Mar 2022 19:54:39 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 05:59:14 GMT, Sibabrata Sahoo wrote: >> Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update HttpsCB.java src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 338: > 336: return true; > 337: } > 338: String afterWildCard = domain.substring(1); `domain` could be an empty string if the property value is "domain:a,,b". I know it's invalid but at least let's try our best to avoid a runtime exception. In fact, why is this variable necessary? It looks like `regionMatches` allows you to compare ...er... regions. ------------- PR: https://git.openjdk.java.net/jdk/pull/7759 From kevinw at openjdk.java.net Tue Mar 15 20:29:56 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 15 Mar 2022 20:29:56 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation Message-ID: Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. ------------- Commit messages: - 8283092: JMX subclass permission check redundant with strong encapsulation Changes: https://git.openjdk.java.net/jdk/pull/7827/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7827&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283092 Stats: 31 lines in 3 files changed: 0 ins; 28 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7827/head:pull/7827 PR: https://git.openjdk.java.net/jdk/pull/7827 From valeriep at openjdk.java.net Tue Mar 15 20:40:45 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 20:40:45 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:18:56 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again and undo DSA changes > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 101: > >> 99: // set default key sizes and apply our own algorithm-specific limits >> 100: // override lower limit to disallow unsecure keys being generated >> 101: // override upper limit to deter DOS attack > > Not a P11 expert, but I assume `algorithm` here is already guaranteed to be in uppercase? Yes, for P11KeyPairGenerator, its algorithm values are all in uppercase. I verified it with an existing regression test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Tue Mar 15 20:47:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 20:47:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:24:15 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again and undo DSA changes > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 122: > >> 120: default -> { >> 121: throw new ProviderException >> 122: ("Unrecognized algorithm for checking key size"); > > If it's an unknown key algorithm, is it possible we just ignore it and keep using `minKeyLen` and `maxKeyLen`? Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception so it can be caught and handled during develop time. P11KeyPairGenerator class is only used for known algorithms which it is registered for, so probably ok to go either way. I'd prefer to play it safe and force a review of this block of code when new algorithm is added. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Tue Mar 15 20:51:25 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 20:51:25 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Removed NPE from the catch statement. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/48f562ab..c8ae1655 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From sean.mullan at oracle.com Tue Mar 15 21:30:50 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Mar 2022 17:30:50 -0400 Subject: [Internet]Re: Proposal for potential new feature: TLS Certificate Compression In-Reply-To: <112601CA-A7BE-49AC-8210-FA7916FC9E32@Tencent.Com> References: <9C3E05A5-6DA1-4E11-91FC-EECC8A101742@Tencent.Com> <1da938bb-ef67-52e3-ad8e-e945c1718c7e@oracle.com> <112601CA-A7BE-49AC-8210-FA7916FC9E32@Tencent.Com> Message-ID: <5ce34a85-8a47-d633-360b-7948cd7be4c4@oracle.com> On 3/14/22 2:21 PM, xueleifan(XueleiFan) wrote: > Hi Jamil, > > Thank you for the support of this proposal. ?I am happy to move on to > the next JEP process if no objections or comments in the coming weeks. > > Hi All, > > Please let me know if more time is required for the review of the proposal. I suggest you send a new message to security-dev with a link to the JEP Draft for review as the next step (even though you already posted it). Don't post any code yet, and don't move it to Submitted until there has been enough time for review and consensus has been reached that this is an idea that is worthy of being added to the JDK Roadmap. Thanks, Sean > Thanks, > Xuelei > > > >> On Mar 11, 2022, at 7:25 AM, Jamil Nimeh > > wrote: >> >> Hi Xuelei, >> >> After reading over your descriptions and the supporting documentation >> this certainly seems like it would be a nice addition to JSSE.? It >> definitely seems like a performance win for QUIC and also for >> bandwidth-constrained devices.? I'm all for seeing this JEP proceed. >> I'll likely have more comments down the line and I have taken a look >> at the proposed code changes and will go back and do a deeper dive on >> it.? I just don't want to jump any of the JEP process hoops by talking >> about code changes before some of the important first steps for the >> JEP have been cleared.? But you've got my support on this one! >> >> --Jamil >> >> On 3/7/2022 11:46 AM, xueleifan(XueleiFan) wrote: >>> Hi, >>> >>> The TLS Certificate Compression standard was described in RFC 8879, >>> and has been enabled in browser Chrome and Safari. What?s TLS >>> Certificate Compression and what?s the benefits of this feature? >>> >>> For TLS connections, a client must authenticate the identity of the >>> server. This typically involves verification that the identity of the >>> server is included in a certificate and that the certificate is >>> issued by a trusted entity. >>> >>> Where servers provide certificates for authentication, the size of >>> the certificate chain can consume a large number of bytes. >>> Controlling the size of certificate chains is critical to performance >>> and security in QUIC. TLS certificate compression has the potential >>> to ameliorate the attacks/problems by reducing the size of the >>> handshakes to a size compatible with the security restriction.? The >>> TLS Certificate Compression feature is an essential part for QUIC-TLS >>> protocols. >>> >>> For more details, please refer to section 4.4 in RFC 9001 (Using TLS >>> to Secure QUIC): >>> --------- >>> Note: Where servers provide certificates for authentication, the size >>> of the certificate chain can consume a large number of bytes. >>> Controlling the size of certificate chains is critical to performance >>> in QUIC as servers are limited to sending 3 bytes for every byte >>> received prior to validating the client address; see Section 8.1 of >>> [QUIC-TRANSPORT]. The size of a certificate chain can be managed by >>> limiting the number of names or extensions; using keys with small >>> public key representations, like ECDSA; or by using certificate >>> compression [COMPRESS]. >>> ???? >>> >>> and a more detailed description in the blog ?Does the QUIC handshake >>> require compression to be >>> fast??(https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study). >>> ? I just copy part of the conclusion section of the bog here for your >>> quick reference. >>> --------- >>> First, the TLS certificate compression extension has a very large >>> impact on QUIC performance. Even though the extension is new and >>> being introduced fairly late in the process when compared to overall >>> QUIC deployment schedules, it seems quite important for both clients >>> and servers to implement the new extension so that the QUIC handshake >>> can live up to its billing. Without some help, 40% of QUIC full >>> handshakes would be no better than TCP, but compression can repair >>> most of that issue. I have heard of other non-standardized approaches >>> to reducing the size of the certificate chain, and they seem >>> reasonable, but this is a problem worth addressing immediately with >>> the existing compression extension. >>> ... >>> Lastly, data from the real world again proves to be more insightful >>> than intuition and is invaluable in making protocol design and >>> implementation decisions. When I started this work I expected the >>> impact of compression to be positive but marginally focused on a few >>> edge cases. The data shows this optimization lands right on the sweet >>> spot that ties configurations and the QUIC specification together and >>> impacts a large portion of QUIC handshakes. My thanks to the authors >>> of the compression extension. >>> --------- >>> >>> >>> Besides, reducing the amount of information exchanged during a TLS >>> handshake to a minimum helps to improve performance in environments, >>> for example Internet of Things, where devices are connected to a >>> network with a low bandwidth and lossy radio technology. >>> >>> This feature is a part to improve the performance of TLS connections, >>> and it is also a part of the path towards QUIC standards. >>> >>> Chrome support TLS certificate compression with Brotil compression >>> algorithm, and Safari support TLS certificate compression with Zlib >>> compression algorithm. >>> >>> In a summary, JDK could benefits from supporting RFC 8879 in the >>> following areas: >>> >>> ? ? Performance - Reduce latency and improve performance of TLS and >>> QUIC connections by support the TLS certificate compression standard >>> in JDK. >>> ? ? Security - Mitigate the impact of amplification attacks threat by >>> reducing the size of the TLS handshakes with compressed certificates. >>> >>> What do you think? ?Do you want it a part of OpenJDK? ?Please feel >>> free to share you comments. >>> >>> Thanks, >>> Xuelei > From ihse at openjdk.java.net Tue Mar 15 23:50:20 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 23:50:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn - Fix merge - Merge tag 'jdk-19+13' into shuffle-data-reborn Added tag jdk-19+13 for changeset 5df2a057 - Move characterdata templates to share/classes/java/lang. - Update comment refering to "make" dir - Move new symbols to jdk.compiler - Merge branch 'master' into shuffle-data - Move macosxicons from share to macosx - Move to share/data, and move jdwp.spec to java.se - Update references in test - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f ------------- Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05 Stats: 85 lines in 1695 files changed: 4 ins; 1 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Mar 15 23:50:22 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 23:50:22 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v5] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Move characterdata templates to share/classes/java/lang. This PR was almost ready to merge, but unfortunately got closed about a year ago when I disappeared on medical leave. :-( I've been putting off coming back to to this, worried that the merge conflicts would be bad. But no! Git handled the merge fantastically well; the default merge mode even realized that new files in a directory which had been moved elsewhere should probably also be moved to the same place. I was pleasantly surprised how easy this was. Nevertheless, I have carefully studied the automatic merge for any signs or mistakes. I only found one: a single renamed file (blacklist -> blocked) that it failed to match. So I believe this PR is back in the same integrateable state that it was when I left it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Mar 15 23:59:55 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 23:59:55 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues. I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR. I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively). I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228. There were two open questions: * should jdwp.spec belong to specs directory instead of data * should bin/idea.sh be changed to exclude data but they sounded so exploratory that I decided not to open JBS issues for them. @wangweij @naotoj @prrace @erikj79 @jonathan-gibbons You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From weijun at openjdk.java.net Wed Mar 16 00:16:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 16 Mar 2022 00:16:50 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: <5LsStIDKZnRP4PyIE5dShT-XezKK-91XEglZ99DypvQ=.b9b15bd7-b7c0-4923-a26c-dc4ad331c757@github.com> On Tue, 15 Mar 2022 20:44:20 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 122: >> >>> 120: default -> { >>> 121: throw new ProviderException >>> 122: ("Unrecognized algorithm for checking key size"); >> >> If it's an unknown key algorithm, is it possible we just ignore it and keep using `minKeyLen` and `maxKeyLen`? > > Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception so it can be caught and handled during develop time. P11KeyPairGenerator class is only used for known algorithms which it is registered for, so probably ok to go either way. I'd prefer to play it safe and force a review of this block of code when new algorithm is added. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 16 00:33:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 16 Mar 2022 00:33:43 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6] In-Reply-To: References: Message-ID: <6V_3NdKeibCcMiNw0PQEzKU-fhEytrR08Ckb_taEXkM=.c4af0ad3-697f-4515-bc66-42899ec68cb6@github.com> On Tue, 15 Mar 2022 20:51:25 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Removed NPE from the catch statement. Could you please please review CSR at: https://bugs.openjdk.java.net/browse/JDK-8282995 Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From Alan.Bateman at oracle.com Wed Mar 16 06:31:24 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2022 06:31:24 +0000 Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> Magnus, This proposal does not address the previous concerns. As before, you are proposing to put the data files used to generate the classes for jdk.localedata and jdk.charsets into src/java.base and I don't think we should do that. I really think this PR needs to be withdraw n or closed until there is at least some agreement on placement. I know you want to get the files moved out of the make tree but there are many issues to work through before that can happen. -Alan On 15/03/2022 23:59, Magnus Ihse Bursie wrote: > On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: > >>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >>> >>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >>> >>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >>> >>> ### Modules reviewed >>> >>> - [x] java.base >>> - [x] java.desktop >>> - [x] jdk.compiler >>> - [x] java.se >> Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn >> - Fix merge >> - Merge tag 'jdk-19+13' into shuffle-data-reborn >> >> Added tag jdk-19+13 for changeset 5df2a057 >> - Move characterdata templates to share/classes/java/lang. >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f > I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues. > > I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR. > > I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively). > > I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228. > > There were two open questions: > > * should jdwp.spec belong to specs directory instead of data > * should bin/idea.sh be changed to exclude data > > but they sounded so exploratory that I decided not to open JBS issues for them. > > @wangweij @naotoj @prrace @erikj79 @jonathan-gibbons You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping) > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1611 From magnus.ihse.bursie at oracle.com Wed Mar 16 08:44:51 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 09:44:51 +0100 Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> References: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> Message-ID: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com> On 2022-03-16 07:31, Alan Bateman wrote: > Magnus, > > This proposal does not address the previous concerns. As before, you > are proposing to put the data files used to generate the classes for > jdk.localedata and jdk.charsets into src/java.base and I don't think > we should do that. I really think this PR needs to be withdraw n or > closed until there is at least some agreement on placement. I know you > want to get the files moved out of the make tree but there are many > issues to work through before that can happen. I'm sorry that you feel I did not properly address your concerns. You wrote: "If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module." which I interpreted as a need to file a follow-up issue to sort that out, not a veto on the entire PR. If you have such strong opinions on the data files shared between java.base and jdk.charsets/jdk.localedata, I propose we leave them in make/data for the time being, clean up the associated mess, and then work out where they actually should be. Does that sound okay to you? /Magnus > > -Alan > > On 15/03/2022 23:59, Magnus Ihse Bursie wrote: >> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie >> wrote: >> >>>> A lot (but not all) of the data in make/data is tied to a specific >>>> module. For instance, the publicsuffixlist is used by java.base, >>>> and fontconfig by java.desktop. (A few directories, like >>>> mainmanifest, is *actually* used by make for the whole build.) >>>> >>>> These data files should move to the module they belong to. The are, >>>> after all, "source code" for that module that is "compiler" into >>>> resulting deliverables, for that module. (But the "source code" >>>> language is not Java or C, but typically a highly domain specific >>>> language or data format, and the "compilation" is, often, a >>>> specialized transformation.) >>>> >>>> This misplacement of the data directory is most visible at code >>>> review time. When such data is changed, most of the time build-dev >>>> (or the new build label) is involved, even though this has nothing >>>> to do with the build. While this is annoying, a worse problem is if >>>> the actual team that needs to review the patch (i.e., the team >>>> owning the module) is missed in the review. >>>> >>>> ### Modules reviewed >>>> >>>> - [x] java.base >>>> - [x] java.desktop >>>> - [x] jdk.compiler >>>> - [x] java.se >>> Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn >>> ? - Fix merge >>> ? - Merge tag 'jdk-19+13' into shuffle-data-reborn >>> ??? ??? Added tag jdk-19+13 for changeset 5df2a057 >>> ? - Move characterdata templates to share/classes/java/lang. >>> ? - Update comment refering to "make" dir >>> ? - Move new symbols to jdk.compiler >>> ? - Merge branch 'master' into shuffle-data >>> ? - Move macosxicons from share to macosx >>> ? - Move to share/data, and move jdwp.spec to java.se >>> ? - Update references in test >>> ? - ... and 2 more: >>> https://git.openjdk.java.net/jdk/compare/83d77186...598f740f >> I have carefully reviewed all PR comments, and the changes I made in >> response to them. I believe I have resolved all requests from >> reviewers. What remained to do was to create an informational JEP >> about the new source structure, and file some follow-up issues. >> >> I have now created and submitted a new informational JEP ("JDK Source >> Structure"), available at >> https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this >> JEP, it felt increasingly silly to just copy and extend the part >> about src/$MODULE from JEP 201, so I extended it to cover a relevant >> overview of the entire JDK source base structure. I actually think >> this JEP has a good merit on its own, notwithstanding it being a >> reviewer requirement for this PR. >> >> I have also filed follow up issues for the non-standard >> jdk.hotspot.agent `doc` and `test` directories >> (https://bugs.openjdk.java.net/browse/JDK-8283197 and >> https://bugs.openjdk.java.net/browse/JDK-8283198, respectively). >> >> I have filed a follow up issue for continued efforts to clean up >> charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228. >> >> There were two open questions: >> >> ? * should jdwp.spec belong to specs directory instead of data >> ? * should bin/idea.sh be changed to exclude data >> >> but they sounded so exploratory that I decided not to open JBS issues >> for them. >> >> @wangweij? @naotoj? @prrace? @erikj79 @jonathan-gibbons? You have all >> approved this PR at an older revision. Can you please reconfirm that >> your approval stands for the latest revision? (Sorry for the mass ping) >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1611 > From dfuchs at openjdk.java.net Wed Mar 16 15:18:51 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Mar 2022 15:18:51 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls wrote: > Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. Marked as reviewed by dfuchs (Reviewer). src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 233: > 231: } > 232: return null; > 233: } I have verified in module-info.java that sun.management.spi is only conditionally exported so I agree that the explicit permission check can now be removed. src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java line 35: > 33: > 34: /** > 35: * Instantiates a new AgentProvider. This class should probably be removed altogether. I see that you logged [JDK-8283254](https://bugs.openjdk.java.net/browse/JDK-8283254) so this is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From prr at openjdk.java.net Wed Mar 16 17:19:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 16 Mar 2022 17:19:57 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: <_XwD8h3_L03wqvO0Na4_OoHwtdYInzjTKsOaFvqKfUY=.47ccb949-e5fe-49bb-b4b8-3bc36676910a@github.com> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f How are folks reviewing this huge PR ? My browser paints a few files and that's it, and the drop down list to "jump to" is too big to display - it says ! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From achung at openjdk.java.net Wed Mar 16 18:31:55 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 16 Mar 2022 18:31:55 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed incorrect translation of compiler configuration file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02-03 Stats: 2310 lines in 3 files changed: 0 ins; 2310 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From ihse at openjdk.java.net Wed Mar 16 19:10:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 19:10:03 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f It might be helpful to go to the webrev instead: https://openjdk.github.io/cr/?repo=jdk&pr=1611&range=05 Only the first dozen or so of files has actual changes; the rest are moved files. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From Alan.Bateman at oracle.com Wed Mar 16 19:53:11 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2022 19:53:11 +0000 Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com> References: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com> Message-ID: <1ffca295-1c99-300e-1ac5-f81c51d8ef9b@oracle.com> On 16/03/2022 08:44, Magnus Ihse Bursie wrote: > : > > If you have such strong opinions on the data files shared between > java.base and jdk.charsets/jdk.localedata, I propose we leave them in > make/data for the time being, clean up the associated mess, and then > work out where they actually should be. Does that sound okay to you? The concern, as before, is that it puts data files into src/java.base that are used by the build to generate classes/resources for the service provider modules.? We also have the complication that the charsets to include in java.base varies by platform so the module/package for each charset is decided at build time. It's always been low-priority to re-visit that and not clear if we could even get to an agreement easily because there are IBM platforms that want EBCDIC and other double byte charsets whereas other platforms don't want these in java.base. So yes, if you can drop the move of the charset data and CLDR data from the patch then it will make it easier to discuss. You asked about the JDWP spec. This is the protocol spec that is used to generate the spec in HTML, and source files for the debugger front-end and backend (jdk.jdi and jdk.jdwp.agent modules). The "specs" directory might be right. There is another source file (jdwp-spec.md) that isn't in the src tree right now and they probably go together. -Alan From kevinw at openjdk.java.net Wed Mar 16 21:31:45 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 16 Mar 2022 21:31:45 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 15:14:53 GMT, Daniel Fuchs wrote: >> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. > > src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 233: > >> 231: } >> 232: return null; >> 233: } > > I have verified in module-info.java that sun.management.spi is only conditionally exported so I agree that the explicit permission check can now be removed. thanks > src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java line 35: > >> 33: >> 34: /** >> 35: * Instantiates a new AgentProvider. > > This class should probably be removed altogether. I see that you logged [JDK-8283254](https://bugs.openjdk.java.net/browse/JDK-8283254) so this is fine. Thanks Daniel - yes will get rid of this class soon, I'll keep these two actions in separate changes. 8-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From naoto at openjdk.java.net Wed Mar 16 21:39:02 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Mar 2022 21:39:02 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f Looks good, with minor comments. Also I am assuming you will modify the copyright year for these files before the merge. make/modules/jdk.charsets/Gensrc.gmk line 32: > 30: # Generate files using the charsetmapping tool > 31: # > 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Wed Mar 16 21:40:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Mar 2022 21:40:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed incorrect translation of compiler configuration file LGTM. Thanks for the change. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7765 From ihse at openjdk.java.net Wed Mar 16 22:00:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 22:00:02 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 21:31:08 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie 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 branch 'master' into shuffle-data-reborn >> - Fix merge >> - Merge tag 'jdk-19+13' into shuffle-data-reborn >> >> Added tag jdk-19+13 for changeset 5df2a057 >> - Move characterdata templates to share/classes/java/lang. >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f > > make/modules/jdk.charsets/Gensrc.gmk line 32: > >> 30: # Generate files using the charsetmapping tool >> 31: # >> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping > > Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Wed Mar 16 22:04:49 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Mar 2022 22:04:49 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 21:56:53 GMT, Magnus Ihse Bursie wrote: >> make/modules/jdk.charsets/Gensrc.gmk line 32: >> >>> 30: # Generate files using the charsetmapping tool >>> 31: # >>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping >> >> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too > > This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. > > So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect. Thanks for reminding me. Then yes, I'd agree with Alan. It'd be much simpler to exclude this from this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Wed Mar 16 23:53:19 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 23:53:19 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v7] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/598f740f..1c91b951 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05-06 Stats: 35 lines in 35 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Thu Mar 17 00:07:53 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Mar 2022 00:07:53 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v8] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Restore charsetmapping and cldr to make/data ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c91b951..34bb3c16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06-07 Stats: 5 lines in 1079 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Thu Mar 17 00:12:38 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Mar 2022 00:12:38 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/34bb3c16..b1d1e4d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07-08 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From weijun at openjdk.java.net Thu Mar 17 00:31:11 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Mar 2022 00:31:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos The security-related change looks fine to me ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Thu Mar 17 00:31:13 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Mar 2022 00:31:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Wed, 16 Dec 2020 18:34:37 GMT, Naoto Sato wrote: >>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. >>> >>> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html: >>> >>> > As to charsetmapping and cldrconverter, I believe they can reside in >>> > java.base, as jdk.charsets and jdk.localedata modules depend on it. >>> >>> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart. >>> >>> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place. >> >> I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory. > >>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is. > > Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this. @naotoj @AlanBateman I have now rolled back any changes to make/data/cldr and make/data/charsetmapping. I have also updated copyright years; thanks for reminding me Naoto! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From erikj at openjdk.java.net Thu Mar 17 13:35:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Mar 2022 13:35:35 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mullan at openjdk.java.net Thu Mar 17 14:13:30 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 17 Mar 2022 14:13:30 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls wrote: > Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. I think you also need to update this test such that it checks that the module access restrictions prevent subclassing instead of the permission check: test/jdk/sun/management/PlatformMBeanProviderConstructorCheck.java Also, it looks like this permission was never publicly documented and was only used internally, so it probably doesn't need a CSR, but I don't know for sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From naoto at openjdk.java.net Thu Mar 17 16:15:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Mar 2022 16:15:30 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos LGTM. Thanks for the change, Magnus! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From alanb at openjdk.java.net Fri Mar 18 10:03:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 10:03:39 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Thanks for dropping the charset and locale data from the proposal. The updated proposal (b1d1e4d8) looks okay but I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed? I suspect that JEP will need to includes a "specs" directory. It's okay to jdwp.spec into the java.se "data" directory for now I think "specs" would be a bette place for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From magnus.ihse.bursie at oracle.com Fri Mar 18 14:13:58 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Mar 2022 14:13:58 +0000 Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: <62193BC0-B3FC-43E9-A65D-387708D85B3D@oracle.com> > 18 mars 2022 kl. 11:04 skrev Alan Bateman : > > I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed? I am *not* planning to wait for the JEP. (My perhaps cynical prediction is that it will be treated as a low-priority, bike-shedding playground which is unlikely to progress to its final stage for a year or so?) The point of the informational JEP is that it is a living document. If the code changes, we can update the JEP. The JEP as it stands right now describes the code base as it will look when this PR is integrated. And yes, I?m open for more updates/changes in the future if we find the need. Things like code structure is something which we impose on the source code to be helpful. If it works against our best interests, we need to change it. And sometimes it?s hard to get things right the first time around. /Magnus From kevinw at openjdk.java.net Fri Mar 18 14:45:35 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 18 Mar 2022 14:45:35 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 13:55:22 GMT, Sean Mullan wrote: > test/jdk/sun/management/PlatformMBeanProviderConstructorCheck.java Thank for noticing that Sean - had run various tests but missed this. I have an update, will add it here soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From kevinw at openjdk.java.net Fri Mar 18 17:49:05 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 18 Mar 2022 17:49:05 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v2] In-Reply-To: References: Message-ID: > Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Test update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7827/files - new: https://git.openjdk.java.net/jdk/pull/7827/files/a6d05f73..98f1577d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7827&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7827&range=00-01 Stats: 71 lines in 1 file changed: 28 ins; 11 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/7827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7827/head:pull/7827 PR: https://git.openjdk.java.net/jdk/pull/7827 From kevinw at openjdk.java.net Fri Mar 18 17:49:06 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 18 Mar 2022 17:49:06 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls wrote: > Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. Added test update. Checks that with permissive module options we can extend sun.management.spi.PlatformMBeanProvider, and that without them we cannot. Output of the new test is like this: ----------System.out:(11/1279)---------- ---PlatformMBeanProviderConstructorCheck: ---PlatformMBeanProviderConstructorCheck: invoke MyProvider with expectedFail = false ---PlatformMBeanProviderConstructorCheck PASSED (1) (expectedFail = false) ---PlatformMBeanProviderConstructorCheck: re-invoke without --add-modules or --add-exports Command line: [/tank/kwalls/repos/personal/jdk/open/test/../../build/linux-x86_64-server-release/images/jdk/bin/java -cp /tank/kwalls/repos/personal/jdk/open/test/JTwork/classes/sun/management/PlatformMBeanProviderConstructorCheck.d:/tank/kwalls/repos/personal/jdk/open/test/jdk/sun/management:/tank/kwalls/repos/personal/jdk/open/test/JTwork/classes/test/lib:/tank/kwalls/repos/personal/jdk/open/test/lib:/opt/jtreg6.1/lib/javatest.jar:/opt/jtreg6.1/lib/jtreg.jar PlatformMBeanProviderConstructorCheck --nomoduleargs ] [2022-03-18T17:19:34.798024163Z] Gathering output for process 10627 [2022-03-18T17:19:34.902532753Z] Waiting for completion for process 10627 [2022-03-18T17:19:34.902807078Z] Waiting for completion finished for process 10627 Output and diagnostic info for process 10627 was saved into 'pid-10627-output.log' [2022-03-18T17:19:34.908368606Z] Waiting for completion for process 10627 [2022-03-18T17:19:34.908503964Z] Waiting for completion finished for process 10627 ----------System.err:(9/647)---------- stdout: [---PlatformMBeanProviderConstructorCheck: ---PlatformMBeanProviderConstructorCheck: invoke MyProvider with expectedFail = true ---PlatformMBeanProviderConstructorCheck got exception: java.lang.IllegalAccessError: superclass access check failed: class PlatformMBeanProviderConstructorCheck$MyProvider (in unnamed module @0x4795bbf5) cannot access class sun.management.spi.PlatformMBeanProvider (in module java.management) because module java.management does not export sun.management.spi to unnamed module @0x4795bbf5 ---PlatformMBeanProviderConstructorCheck PASSED (2) (expectedFail = true) ]; stderr: [] exitValue = 0 STATUS:Passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From xuelei at openjdk.java.net Fri Mar 18 18:11:33 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 18 Mar 2022 18:11:33 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more test case udpate ping ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Fri Mar 18 18:50:58 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 18 Mar 2022 18:50:58 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 Message-ID: JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. This change introduces similar behavior to SSLEngine. The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. Tier1/2 mach5 tests have been successfully run. ------------- Commit messages: - Merge branch 'master' into JDK-8273553 - Added SSLSocket bugid since we're actually checking both sides now. - I/O Issues, rewrite the I/O section so that early Socket closes don't kill our server-side reads. - Merge branch 'master' into JDK-8273553 - Merge branch 'master' into JDK-8273553 - Merge - Minor test tweaks. - Remove inadvertent whitespace - Forgot copyright Info - 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 Changes: https://git.openjdk.java.net/jdk/pull/7796/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7796&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273553 Stats: 506 lines in 3 files changed: 493 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7796.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7796/head:pull/7796 PR: https://git.openjdk.java.net/jdk/pull/7796 From alanb at openjdk.java.net Fri Mar 18 19:37:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 19:37:34 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From wetmore at openjdk.java.net Fri Mar 18 21:03:41 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 18 Mar 2022 21:03:41 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more test case udpate test/jdk/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java line 487: > 485: if ((local != null) && (remote != null)) { > 486: // If both failed, return the curthread's exception. > 487: local.addSuppressed(remote); Copyright 2016->2022. test/jdk/javax/net/ssl/ALPN/SSLSocketAlpnTest.java line 483: > 481: if ((local != null) && (remote != null)) { > 482: // If both failed, return the curthread's exception. > 483: local.addSuppressed(remote); Copyright 2016->2022. test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 2: > 1: /* > 2: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved. I am unsure about the copyrights on these files. They are probably ok, but you should get approval by someone more familiar. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Fri Mar 18 21:15:35 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 18 Mar 2022 21:15:35 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more test case udpate Please see latest comments and let's verify the copyright is correct, but otherwise looks good. test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 32: > 30: import java.util.Objects; > 31: > 32: public class CheckSSLHandshakeException { My personal preference would have been to combine all of these into a single testfile to minimize clutter in the logs and directories, but no strong objection. test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java line 349: > 347: } > 348: } > 349: } finally { Copyright update test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java line 544: > 542: /* > 543: * Check various exception conditions. > 544: */ Copyright update ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7722 From prr at openjdk.java.net Fri Mar 18 21:21:30 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 18 Mar 2022 21:21:30 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Changes requested by prr (Reviewer). make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk line 27: > 25: > 26: # Generate java sources using the X11 offsets that are precalculated in files > 27: # src/java.desktop/share/data/x11wrappergen/sizes-
.txt. This doesn't seem right to me. This is X11 specific. It should not be in share. Same for related files. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From prr at openjdk.java.net Fri Mar 18 21:27:36 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 18 Mar 2022 21:27:36 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos This doesn't seem right to me to put x11wrappergen into share. This is X11 specific. It should not be in share. Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From iris at openjdk.java.net Fri Mar 18 23:08:28 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 18 Mar 2022 23:08:28 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Tue, 8 Mar 2022 08:02:16 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more test case udpate Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From iris at openjdk.java.net Fri Mar 18 23:08:28 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 18 Mar 2022 23:08:28 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Fri, 18 Mar 2022 21:00:40 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> more test case udpate > > test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 2: > >> 1: /* >> 2: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights reserved. > > I am unsure about the third-party copyrights on these files. They are probably ok, but you should get approval by someone more familiar. > > Secondly, in the Oracle environment, we generally use a trailing , comma after the date. e.g. > > `Copyright (C) 2022, ` The location of the copyright is fine. No need to enforce Oracle date formatting. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From wetmore at openjdk.java.net Fri Mar 18 23:12:26 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 18 Mar 2022 23:12:26 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Fri, 18 Mar 2022 23:05:36 GMT, Iris Clark wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> more test case udpate > > Marked as reviewed by iris (Reviewer). Thanks, @irisclark! ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Sat Mar 19 04:23:24 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 19 Mar 2022 04:23:24 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v6] In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7722/files - new: https://git.openjdk.java.net/jdk/pull/7722/files/61cc7934..5d0fcf2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7722&range=04-05 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7722/head:pull/7722 PR: https://git.openjdk.java.net/jdk/pull/7722 From xuelei at openjdk.java.net Sat Mar 19 04:23:25 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 19 Mar 2022 04:23:25 GMT Subject: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v5] In-Reply-To: References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Fri, 18 Mar 2022 21:08:56 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> more test case udpate > > test/jdk/javax/net/ssl/SSLException/CheckSSLHandshakeException.java line 32: > >> 30: import java.util.Objects; >> 31: >> 32: public class CheckSSLHandshakeException { > > My personal preference would have been to combine all of these into a single testfile to minimize clutter in the logs and directories, but no strong objection. I understand. I would like to have them in separated test cases so that it is easier to monitor the regressions in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From aturbanov at openjdk.java.net Sat Mar 19 13:35:26 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sat, 19 Mar 2022 13:35:26 GMT Subject: Integrated: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 13:20:34 GMT, Andrey Turbanov wrote: > 8282534: Remove redundant null check in ChaCha20Cipher.engineInit This pull request has now been integrated. Changeset: 80415e04 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/80415e04c5fd6709e7e5b5ffb7a3d9431b672d99 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod 8282534: Remove redundant null check in ChaCha20Cipher.engineInit Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7424 From joe.darcy at oracle.com Sat Mar 19 22:38:20 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Sat, 19 Mar 2022 15:38:20 -0700 Subject: FYI, candidate list of classes to be updated to sealed in JDK-8283414: Update java.base to use sealed classes (umbrella) Message-ID: <63f66025-f2ff-6311-f5e7-31f3f70c2697@oracle.com> Hello, With a number of efforts to update various class hierarchies in the JDK to sealed classes, I wrote an annotation processor to find candidates to be changed to sealed. The candidates for this analysis are non-final public classes with at least one package access constructor and no public constructors. That is, the candidate class cannot be generally subclassable. Several dozen candidates were identified and listed in JDK-8283414, including two cases where changing the classes in question to sealed was already out for review (JDK-8282536 and JDK-8283237). I've created subtasks for a number of other cases in core-libs; the cases in security libs could also be reviewed. -Joe From xuelei at openjdk.java.net Sun Mar 20 06:49:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 20 Mar 2022 06:49:56 GMT Subject: Integrated: 8282723: Add constructors taking a cause to JSSE exceptions In-Reply-To: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> References: <2Wj0NQkT7DHpTiYvHeq_C9yi930hf89oMKUxt6kNITc=.91ae6be6-8e1d-4312-b613-9f047bd27e0e@github.com> Message-ID: On Mon, 7 Mar 2022 07:52:29 GMT, Xue-Lei Andrew Fan wrote: > Please review this small API enhancement to add the usual constructors taking a cause to javax.net.ssl exceptions. The use of initCause in the JSSE implementation code is updated to use the new constructors accordingly. > > Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 This pull request has now been integrated. Changeset: 4df67426 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/4df67426ed02f18af0757897acb28b636a317a91 Stats: 396 lines in 30 files changed: 264 ins; 53 del; 79 mod 8282723: Add constructors taking a cause to JSSE exceptions Reviewed-by: wetmore, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7722 From aturbanov at openjdk.java.net Sun Mar 20 13:50:42 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Mar 2022 13:50:42 GMT Subject: RFR: 8283426: Fix 'exeption' typo Message-ID: Fix repeated type `exeption` ------------- Commit messages: - [PATCH] Typo 'Exeption' instead of 'Exception' Changes: https://git.openjdk.java.net/jdk/pull/7879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283426 Stats: 24 lines in 10 files changed: 0 ins; 2 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From xuelei at openjdk.java.net Sun Mar 20 14:41:37 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 20 Mar 2022 14:41:37 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: <_PAkHa5ReaDzrQiBnAEskX-GEe8viZdHkXfcUgMUBro=.f8aa01f8-13cf-4847-8f51-00e3b3e10516@github.com> On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated type `exeption` Looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7879 From iris at openjdk.java.net Sun Mar 20 14:57:22 2022 From: iris at openjdk.java.net (Iris Clark) Date: Sun, 20 Mar 2022 14:57:22 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated type `exeption` Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From dholmes at openjdk.java.net Mon Mar 21 00:56:30 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Mar 2022 00:56:30 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Looks good. Thanks for cleaning this up. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7879 From wetmore at openjdk.java.net Mon Mar 21 04:49:33 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 21 Mar 2022 04:49:33 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Good grief! I wouldn't have expected it to be so widespread. Thanks for noticing and fixing. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7879 From xuelei at openjdk.java.net Mon Mar 21 05:01:31 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 21 Mar 2022 05:01:31 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. Looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7796 From aivanov at openjdk.java.net Mon Mar 21 07:26:47 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 21 Mar 2022 07:26:47 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Marked as reviewed by aivanov (Reviewer). src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java line 201: > 199: /* > 200: * The method could not be implemented due to CALayer restrictions. > 201: * The exception enforce clients not to use it. Suggestion: * The exception enforces clients not to use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From aturbanov at openjdk.java.net Mon Mar 21 09:02:17 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Mar 2022 09:02:17 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v2] In-Reply-To: References: Message-ID: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com> > Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Apply suggestion Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/files - new: https://git.openjdk.java.net/jdk/pull/7879/files/d93dde25..4c1e68ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From aivanov at openjdk.java.net Mon Mar 21 13:23:30 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 21 Mar 2022 13:23:30 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v2] In-Reply-To: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com> References: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com> Message-ID: On Mon, 21 Mar 2022 09:02:17 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8283426: Fix 'exeption' typo > > Apply suggestion > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From ihse at openjdk.java.net Mon Mar 21 13:41:40 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 13:41:40 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v10] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix fontconfig according to review request ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/b1d1e4d8..5a75e7d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08-09 Stats: 26 lines in 5 files changed: 10 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Mar 21 13:46:27 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 13:46:27 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v11] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge tag 'jdk-19+14' into shuffle-data Added tag jdk-19+14 for changeset 08cadb47 - Move x11wrappergen from share/data to unix/data - Fix fontconfig according to review request - Fix typos - Restore charsetmapping and cldr to make/data - Update copyright year - Merge branch 'master' into shuffle-data-reborn - Fix merge - Merge tag 'jdk-19+13' into shuffle-data-reborn Added tag jdk-19+13 for changeset 5df2a057 - Move characterdata templates to share/classes/java/lang. - ... and 8 more: https://git.openjdk.java.net/jdk/compare/08cadb47...ea17b206 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10 Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Mar 21 14:15:36 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 14:15:36 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. > > This is X11 specific. It should not be in share. > > Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories. @prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`. (Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From coffeys at openjdk.java.net Mon Mar 21 15:08:31 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 21 Mar 2022 15:08:31 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: <4fRUYXBjP7by_UNsrj5DU977__d-2kGIKMKQCb5Wmy0=.b877858c-3c70-4f25-91f4-6196b3dff1d2@github.com> On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 130: > 128: * The following is to set up the keystores/trust material. > 129: */ > 130: private static final String pathToStores = "../../../../javax/net/ssl/etc"; I think the advise is to move away from binary style keystores. i.e. to use test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for a replacement. Is that possible here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From xueleifan at tencent.com Mon Mar 21 15:49:22 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 21 Mar 2022 15:49:22 +0000 Subject: JEP Review Request: TLS Certificate Compression Message-ID: Hi, The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: https://bugs.openjdk.java.net/browse/JDK-8281710 and the discussion of this potential feature at security-dev: https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html Please feel free to make comments and review the JEP. Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.java.net Mon Mar 21 16:06:35 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 16:06:35 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v12] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Correct name for bfc files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/ea17b206..f66afd1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Mar 21 16:29:25 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 16:29:25 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into shuffle-data - Correct name for bfc files - Merge tag 'jdk-19+14' into shuffle-data Added tag jdk-19+14 for changeset 08cadb47 - Move x11wrappergen from share/data to unix/data - Fix fontconfig according to review request - Fix typos - Restore charsetmapping and cldr to make/data - Update copyright year - Merge branch 'master' into shuffle-data-reborn - Fix merge - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d ------------- Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12 Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Mon Mar 21 16:36:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 16:36:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) Message-ID: This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/424 ------------- Commit messages: - Fix TestLayouts on 32-bits - Update copyright - Drop unused imports in Reflection.java - Fix writeOversized for booleans - Revert changes to scopedMemoryAccess.cpp - Add TestUpcallStack to problem list - Revert changes to problem list - Revert to previous handshake logic - Initial push Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282191 Stats: 66428 lines in 364 files changed: 44012 ins; 19911 del; 2505 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon Mar 21 16:36:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 16:36:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Here is a list of the main changes in this iteration. #### java.lang.foreign The API is now a **preview** API in `java.lang.foreign`. As such to be able to use the API, users must pass the `--enable-preview` flag accordingly, to `javac` and `java`. Since the API now lives in `java.base`, we dropped the `MemoryHandles` class and moved all its var handle combinator methods under `MethodHandles`. We have also dropped the `MemorySegment::map` factory and replaced it with a new overload in `FileChannel`, which plays much better with custom file systems. #### ResourceScope The `ResourceScope` abstraction has been renamed to `MemorySession`. Aside from the naming difference (which also is reflected in some of the factories associated with `MemorySession`, another difference are that `MemorySession` now implements `SegmentAllocator` and can be used straight away to allocate segments. Finally, the fact that some sessions are not closeable is now reflected in the API (see `MemorySession::isCloseable`), and a method has been added to create a non-closeable *view* of the memory session. #### Restricted methods Addressing the feedback we have received during incubation, the mechanism to control access to restricted methods is now more permissive. Users can still use the `--enable-native-access` flag, to get a strict, opt-in behavior, in case they want to control which modules can access restricted methods in the foreign API. But if no flag is specified, access is allowed, with a runtime warning. Supporting this required some changes in `ModuleBootstrap` so that we could record the fact that we have seen an `--enable-native-access` flag (so that all checks in `Reflection.java` becomes constant). #### Deterministic library loading/unloading We have enhanced the `SymbolLookup` abstraction to provide a new symbol lookup, called *library lookup*. A library lookup is a symbol lookup built around a specific native library which is loaded/unloaded using dlopen/LoadLibrary. Library lookups are associated with memory sessions, so the library can be unloaded deterministically when the session is closed. #### Memory layouts All memory layout constants feature the expected alignment constraints. For instance, `JAVA_CHAR` is 2 byte aligned, `JAVA_INT` is 4 byte aligned, and so on. #### Removed functionalities As we moved the API in `java.base` we have dropped a number of API points which did not seem to add much value, based on the feedback received: * `SequenceLayout`s now always have a bounded size. As a result, `MemoryLayout::byteSize` no longer returns an optional. A zero-length sequence can be used instead; * `NativeSymbol` has been dropped. At the end of the day, its role is undistinguishable from that of a memory segment with zero-length, so API (and users) should use zero-length segments instead; * `MemorySession::keepAlive` - has been removed; in its place we have a simple, high-order method which executes an action (a `Runnable`) while keeping the session alive (`MemorySession::whileAlive`); * `MemoryLayout::map` only provides limited capabilities when rewriting layouts (e.g. it can only replace one layout at a time); as such we removed this API, and we might add something better at a later point. #### Hotspot changes While the Panama foreign repo contains several Hotspot changes which simplify and regularize the foreign function support, these changes are not included here, as we have discovered some intermittent instability in macosx-aarch64. We might attempt to integrate the hotspot changes at a later date. Javadoc: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/javadoc/java.base/module-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/specdiff_out/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jboes at openjdk.java.net Mon Mar 21 16:36:45 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 21 Mar 2022 16:36:45 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: <1c6iI0BzRJEWKr5IDBEaZfw6CyXoJw1N5G54lDjpGYc=.52e24356-0cf0-4939-8a7f-776800511b51@github.com> On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600: > 598: * @param elementLayout the source element layout. If the byte order associated with the layout is > 599: * different from the native order, a byte swap operation will be performed on each array element. > 600: * @return a fresh short array copy of this memory segment. Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods? src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600: > 598: * @param elementLayout the source element layout. If the byte order associated with the layout is > 599: * different from the native order, a byte swap operation will be performed on each array element. > 600: * @return a fresh short array copy of this memory segment. Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods? src/java.base/share/classes/java/lang/foreign/package-info.java line 149: > 147: * provided: > 148: * > 149: * {@snippet lang=java : missing leading space in comment on line 150 and 162 src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986: > 7984: *

> 7985: * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values > 7986: * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type ... are the return *types* ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986: > 7984: *

> 7985: * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values > 7986: * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type ... are the return *types* ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035: > 8033: * @param pos the position of the first coordinate to be inserted > 8034: * @param values the series of bound coordinates to insert > 8035: * @return an adapter var handle which inserts an additional coordinates, ... which inserts additional coordinates, ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035: > 8033: * @param pos the position of the first coordinate to be inserted > 8034: * @param values the series of bound coordinates to insert > 8035: * @return an adapter var handle which inserts an additional coordinates, ... which inserts additional coordinates, ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151: > 8149: * > 8150: * @param target the var handle to invoke after the dummy coordinates are dropped > 8151: * @param pos position of first coordinate to drop (zero for the leftmost) ... of *the* first coordinate to drop ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151: > 8149: * > 8150: * @param target the var handle to invoke after the dummy coordinates are dropped > 8151: * @param pos position of first coordinate to drop (zero for the leftmost) ... of *the* first coordinate to drop ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From rhalade at openjdk.java.net Mon Mar 21 17:04:36 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 21 Mar 2022 17:04:36 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. should this be updated to only list 2022? ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From erikj at openjdk.java.net Mon Mar 21 17:07:40 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Mar 2022 17:07:40 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into shuffle-data > - Correct name for bfc files > - Merge tag 'jdk-19+14' into shuffle-data > > Added tag jdk-19+14 for changeset 08cadb47 > - Move x11wrappergen from share/data to unix/data > - Fix fontconfig according to review request > - Fix typos > - Restore charsetmapping and cldr to make/data > - Update copyright year > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d OS specific X11 and fontconfig looks good. make/modules/java.desktop/gendata/GendataFontConfig.gmk line 57: > 55: TARGETS += $(FONTCONFIG_OUT_BIN_FILE) > 56: > 57: endif It says no newline at end of file, maybe add that if it's true. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From erikj at openjdk.java.net Mon Mar 21 17:24:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Mar 2022 17:24:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Build changes look ok. make/modules/java.base/Lib.gmk line 217: > 215: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ > 216: LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \ > 217: LIBS := $(LIBCXX) -lc -lm -ldl, \ Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this: LDFLAGS := $(LDFLAGS_JDKLIB), \ LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build. I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon Mar 21 17:40:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 17:40:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 17:16:49 GMT, Erik Joelsson wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > make/modules/java.base/Lib.gmk line 217: > >> 215: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ >> 216: LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \ >> 217: LIBS := $(LIBCXX) -lc -lm -ldl, \ > > Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this: > > > LDFLAGS := $(LDFLAGS_JDKLIB), \ > LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > > > For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build. > > I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time. Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From prr at openjdk.java.net Mon Mar 21 17:57:38 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 21 Mar 2022 17:57:38 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. > > This is X11 specific. It should not be in share. > > Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories. > @prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`. > > (Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.) Indeed they do not but it is a better approximation than "shared". ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mchung at openjdk.java.net Mon Mar 21 18:46:27 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Mar 2022 18:46:27 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v2] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 17:49:05 GMT, Kevin Walls wrote: >> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Test update src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 210: > 208: } > 209: > 210: private PlatformMBeanProvider(Void unused) { This `PlatformMBeanProvider(Void)` constructor is no longer needed. Same for `AgentProvider(Void)` constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From jjg at openjdk.java.net Mon Mar 21 19:00:36 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 21 Mar 2022 19:00:36 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into shuffle-data > - Correct name for bfc files > - Merge tag 'jdk-19+14' into shuffle-data > > Added tag jdk-19+14 for changeset 08cadb47 > - Move x11wrappergen from share/data to unix/data > - Fix fontconfig according to review request > - Fix typos > - Restore charsetmapping and cldr to make/data > - Update copyright year > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d As before, the changes for `jdk.compiler` and `idk.javadoc` look OK, and if there is general consensus on the overall proposed move, then I think that overall it is a good idea. I did not review the `jdk.compiler` in low-level detail, but scanning the webrev index file, the changes seemed OK, and a pure move (no lines changed.) It might have been better to have handled this on a per-module basis, rather than all-at-once, but whatever ... ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jvernee at openjdk.java.net Mon Mar 21 19:29:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Mar 2022 19:29:31 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 src/java.base/share/classes/java/lang/foreign/CLinker.java line 176: > 174: * @param symbol the address of the target function. > 175: * @param function the function descriptor of the target function. > 176: * @return a new downcall method handle. The method handle type is inferred Maybe drop the "new" from this. Since we want to do caching in the future. Suggestion: * @return a downcall method handle. The method handle type is inferred src/java.base/share/classes/java/lang/foreign/CLinker.java line 199: > 197: * > 198: * @param function the function descriptor of the target function. > 199: * @return a new downcall method handle. The method handle type is inferred Suggestion: * @return a downcall method handle. The method handle type is inferred src/java.base/share/classes/java/lang/foreign/MemoryAddress.java line 159: > 157: * Creates a memory address from the given long value. > 158: * @param value the long value representing a raw address. > 159: * @return a new memory address instance. Similar here. A new address is not always returned. Suggestion: * @return a memory address instance. src/java.base/share/classes/java/lang/foreign/package-info.java line 230: > 228: * where {@code M1}, {@code M2}, {@code ... Mn} are module names (for the unnamed module, the special value {@code ALL-UNNAMED} > 229: * can be used). If this option is specified, access to restricted methods is only granted to the modules listed by that > 230: * option. If this option is not specified, access to restricted method is enabled for all modules, but Suggestion: * option. If this option is not specified, access to restricted methods is enabled for all modules, but src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 53: > (failed to retrieve contents of file, check the PR for context) Keeping this static import would seem more readable here, instead of prefixing everything with `AArch64Architecture.`. (especially in the ABI definition below) src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53: > (failed to retrieve contents of file, check the PR for context) Same here, I think keeping the static import for this would make things more readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Mon Mar 21 19:42:33 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Mar 2022 19:42:33 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: <80sBZo5_9EhVEBljhwN7YRFwROLhSnYgNPH1Qg2tMOk=.061730ba-b085-4109-b5c9-ddbf0397301f@github.com> On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into shuffle-data > - Correct name for bfc files > - Merge tag 'jdk-19+14' into shuffle-data > > Added tag jdk-19+14 for changeset 08cadb47 > - Move x11wrappergen from share/data to unix/data > - Fix fontconfig according to review request > - Fix typos > - Restore charsetmapping and cldr to make/data > - Update copyright year > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d I reviewed java.base and java.se. I agree that java.se is a better home for jdwp.spec. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From mullan at openjdk.java.net Mon Mar 21 19:49:08 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 21 Mar 2022 19:49:08 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list Message-ID: This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 ------------- Commit messages: - Initial revision. Changes: https://git.openjdk.java.net/jdk/pull/7894/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7894&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8163327 Stats: 137 lines in 4 files changed: 83 ins; 35 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7894.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7894/head:pull/7894 PR: https://git.openjdk.java.net/jdk/pull/7894 From mullan at openjdk.java.net Mon Mar 21 19:49:09 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 21 Mar 2022 19:49:09 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: <6LQYqGowTsVXm3P5gYDn5nt987dJDOgLBc0jEt3IjY0=.e8eb4c2a-4e47-4927-98f9-ff65383fe91a@github.com> On Mon, 21 Mar 2022 19:40:07 GMT, Sean Mullan wrote: > This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. > > Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 test/jdk/javax/net/ssl/ciphersuites/DisabledAlgorithms.java line 100: > 98: "SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA", > 99: "SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA", > 100: "SSL_RSA_EXPORT_WITH_RC4_40_MD5", Also added additional suites that are already disabled and had not been added to this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From kevinw at openjdk.java.net Mon Mar 21 20:19:03 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 21 Mar 2022 20:19:03 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v3] In-Reply-To: References: Message-ID: > Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: remove redundant constructors ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7827/files - new: https://git.openjdk.java.net/jdk/pull/7827/files/98f1577d..913958e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7827&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7827&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7827/head:pull/7827 PR: https://git.openjdk.java.net/jdk/pull/7827 From kevinw at openjdk.java.net Mon Mar 21 20:25:32 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 21 Mar 2022 20:25:32 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v2] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 18:40:53 GMT, Mandy Chung wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Test update > > src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 210: > >> 208: } >> 209: >> 210: private PlatformMBeanProvider(Void unused) { > > This `PlatformMBeanProvider(Void)` constructor is no longer needed. Same for `AgentProvider(Void)` constructor. Thanks, yes they can go... Rebuilt and tested ok after the new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From mchung at openjdk.java.net Mon Mar 21 20:38:32 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Mar 2022 20:38:32 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v3] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 20:19:03 GMT, Kevin Walls wrote: >> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant constructors Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From mcimadamore at openjdk.java.net Mon Mar 21 21:25:31 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 21:25:31 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 14:17:21 GMT, Jorn Vernee wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53: > >> (failed to retrieve contents of file, check the PR for context) > Same here, I think keeping the static import for this would make things more readable. Good catch. I think the IDE did that when I moved files across; I've fixed few of these, but there's more it seems. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From ihse at openjdk.java.net Mon Mar 21 21:30:29 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 21:30:29 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v14] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add missing newline at EOF ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c47d82d..8faeff36 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Mar 21 21:39:38 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 21:39:38 GMT Subject: Integrated: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se This pull request has now been integrated. Changeset: f8878cb0 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/f8878cb0cc436993ef1222bc13b00b923d91aad1 Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod 8257733: Move module-specific data from make to respective module Reviewed-by: jjg, weijun, naoto, erikj, prr, alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From wetmore at openjdk.java.net Tue Mar 22 00:29:24 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 22 Mar 2022 00:29:24 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 17:00:53 GMT, Rajan Halade wrote: >> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. >> >> This change introduces similar behavior to SSLEngine. >> >> The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. >> >> Tier1/2 mach5 tests have been successfully run. > > test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 2: > >> 1: /* >> 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. > > should this be updated to only list 2022? In previous days, we used to include the dates from the templates, which this test was derived from. I could go either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From wetmore at openjdk.java.net Tue Mar 22 00:29:25 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 22 Mar 2022 00:29:25 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: <4fRUYXBjP7by_UNsrj5DU977__d-2kGIKMKQCb5Wmy0=.b877858c-3c70-4f25-91f4-6196b3dff1d2@github.com> References: <4fRUYXBjP7by_UNsrj5DU977__d-2kGIKMKQCb5Wmy0=.b877858c-3c70-4f25-91f4-6196b3dff1d2@github.com> Message-ID: <4VpdRd67pLgvszi56l8JVrhiQPRk_gWcLeX02U9gRXQ=.b23ca773-bdec-4725-ad4a-8a36b6d65029@github.com> On Mon, 21 Mar 2022 15:05:02 GMT, Sean Coffey wrote: >> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. >> >> This change introduces similar behavior to SSLEngine. >> >> The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. >> >> Tier1/2 mach5 tests have been successfully run. > > test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 130: > >> 128: * The following is to set up the keystores/trust material. >> 129: */ >> 130: private static final String pathToStores = "../../../../javax/net/ssl/etc"; > > I think the advise is to move away from binary style keystores. i.e. to use test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for a replacement. Is that possible here ? Sigh...this is a whole can of worms I wasn't expecting. Looks like one person did the SSLContextTemplate and updated with SSLEngineTemplate, then another person took a completely different takes with SSLSocketTemplate, and then SSLSocketSSLEngineTemplate didn't get touched at all. This should really be harmonized. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From xuelei at openjdk.java.net Tue Mar 22 06:18:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Mar 2022 06:18:28 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 19:40:07 GMT, Sean Mullan wrote: > This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. > > Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 425: > 423: ProtocolVersion.PROTOCOLS_TO_12, > 424: K_RSA, B_3DES, M_SHA, H_SHA256), > 425: It is good to have the supported cipher suites ordered. So it may be nice to have this block between line 348 and 349. ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From ssahoo at openjdk.java.net Tue Mar 22 07:51:18 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Tue, 22 Mar 2022 07:51:18 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v3] In-Reply-To: References: Message-ID: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com> > Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update AbstractDelegateHttpsURLConnection.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7759/files - new: https://git.openjdk.java.net/jdk/pull/7759/files/6d276479..9f8a2081 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7759&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7759/head:pull/7759 PR: https://git.openjdk.java.net/jdk/pull/7759 From kevinw at openjdk.java.net Tue Mar 22 07:58:38 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 22 Mar 2022 07:58:38 GMT Subject: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v3] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 20:19:03 GMT, Kevin Walls wrote: >> Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant constructors Thanks all for the comments and reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From kevinw at openjdk.java.net Tue Mar 22 07:58:38 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 22 Mar 2022 07:58:38 GMT Subject: Integrated: 8283092: JMX subclass permission check redundant with strong encapsulation In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls wrote: > Removing permission checks which, in the presence of a Security Manager, would check for a RuntimePermission "className.subclass". This was to prevent subclassing these classes, but is no longer necessary with strong encapsulation from modules. This pull request has now been integrated. Changeset: 37fc77ef Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/37fc77ef60dd97c4acc468ecfeb6753132974720 Stats: 108 lines in 4 files changed: 28 ins; 45 del; 35 mod 8283092: JMX subclass permission check redundant with strong encapsulation Reviewed-by: dfuchs, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7827 From mcimadamore at openjdk.java.net Tue Mar 22 10:11:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 10:11:47 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments * Use `new` instead of `fresh` * Drop use of `new` where caching might be used * Remove unused imports * Add static imports to make code more succint * Fix other typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/8e6017dc..6bb1b5c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=00-01 Stats: 83 lines in 10 files changed: 2 ins; 7 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mullan at openjdk.java.net Tue Mar 22 12:31:35 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 22 Mar 2022 12:31:35 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 06:15:07 GMT, Xue-Lei Andrew Fan wrote: >> This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. >> >> Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 > > src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 425: > >> 423: ProtocolVersion.PROTOCOLS_TO_12, >> 424: K_RSA, B_3DES, M_SHA, H_SHA256), >> 425: > > It is good to have the supported cipher suites ordered. So it may be nice to have this block between line 348 and 349. Can you be more specific? I'm not following where you think they should be ordered. Are you suggesting they should be ordered before the anon suites even though most of them use stronger algorithms? Also, does the order matter if the application is going to be setting them via APIs? For example, if an application calls `SSLSocket.setEnabledCipherSuites(new String[] { "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA" })` is the order specified respected? Or does the provider re-order it according to this file? ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From coffeys at openjdk.java.net Tue Mar 22 12:31:36 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 22 Mar 2022 12:31:36 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: <4VpdRd67pLgvszi56l8JVrhiQPRk_gWcLeX02U9gRXQ=.b23ca773-bdec-4725-ad4a-8a36b6d65029@github.com> References: <4fRUYXBjP7by_UNsrj5DU977__d-2kGIKMKQCb5Wmy0=.b877858c-3c70-4f25-91f4-6196b3dff1d2@github.com> <4VpdRd67pLgvszi56l8JVrhiQPRk_gWcLeX02U9gRXQ=.b23ca773-bdec-4725-ad4a-8a36b6d65029@github.com> Message-ID: On Tue, 22 Mar 2022 00:24:41 GMT, Bradford Wetmore wrote: >> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 130: >> >>> 128: * The following is to set up the keystores/trust material. >>> 129: */ >>> 130: private static final String pathToStores = "../../../../javax/net/ssl/etc"; >> >> I think the advise is to move away from binary style keystores. i.e. to use test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for a replacement. Is that possible here ? > > Sigh...this is a whole can of worms I wasn't expecting. Looks like one person did the SSLContextTemplate and updated with SSLEngineTemplate, then another person took a completely different takes with SSLSocketTemplate, and then SSLSocketSSLEngineTemplate didn't get touched at all. > > This should really be harmonized. :( ouch - maybe this should be fixed up in a separate bug then. Don't think it should be a blocker for this fix ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From ssahoo at openjdk.java.net Tue Mar 22 13:26:35 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Tue, 22 Mar 2022 13:26:35 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v2] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 19:46:09 GMT, Weijun Wang wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: >> >> Update HttpsCB.java > > src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 338: > >> 336: return true; >> 337: } >> 338: String afterWildCard = domain.substring(1); > > `domain` could be an empty string if the property value is "domain:a,,b". I know it's invalid but at least let's try our best to avoid a runtime exception. In fact, why is this variable necessary? It looks like `regionMatches` allows you to compare ...er... regions. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7759 From mcimadamore at openjdk.java.net Tue Mar 22 14:04:07 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 14:04:07 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - rename syslookup lib on Windows - Add missing LIBS flag - Simplify syslookup build changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6bb1b5c9..4b2760d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=01-02 Stats: 28 lines in 3 files changed: 1 ins; 23 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue Mar 22 14:04:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 14:04:10 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 17:36:53 GMT, Maurizio Cimadamore wrote: >> make/modules/java.base/Lib.gmk line 217: >> >>> 215: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ >>> 216: LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \ >>> 217: LIBS := $(LIBCXX) -lc -lm -ldl, \ >> >> Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this: >> >> >> LDFLAGS := $(LDFLAGS_JDKLIB), \ >> LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ >> >> >> For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build. >> >> I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time. > > Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments. I've fixed the makefile as you suggested - I agree the result is much simpler. I've tested the changes on mac/linux/win and everything looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From xuelei at openjdk.java.net Tue Mar 22 14:46:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Mar 2022 14:46:32 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 12:28:14 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 425: >> >>> 423: ProtocolVersion.PROTOCOLS_TO_12, >>> 424: K_RSA, B_3DES, M_SHA, H_SHA256), >>> 425: >> >> It is good to have the supported cipher suites ordered. So it may be nice to have this block between line 348 and 349. > > Can you be more specific? I'm not following where you think they should be ordered. Are you suggesting they should be ordered before the anon suites even though most of them use stronger algorithms? Also, does the order matter if the application is going to be setting them via APIs? For example, if an application calls `SSLSocket.setEnabledCipherSuites(new String[] { "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA" })` is the order specified respected? Or does the provider re-order it according to this file? In some situation, applications may set the supported cipher suites as the enabled cipher suites. Therefore, the supported cipher suites are also ordered in the current implementation, even though not strictly. Although 3DES suites are pretty weak, but they m be better than anon suites in practice, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From weijun at openjdk.java.net Tue Mar 22 15:47:39 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 22 Mar 2022 15:47:39 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v3] In-Reply-To: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com> References: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com> Message-ID: On Tue, 22 Mar 2022 07:51:18 GMT, Sibabrata Sahoo wrote: >> Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update AbstractDelegateHttpsURLConnection.java Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7759 From rhalade at openjdk.java.net Tue Mar 22 16:32:35 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 22 Mar 2022 16:32:35 GMT Subject: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v3] In-Reply-To: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com> References: <4S_tt6hVXD0LVZa8xwliUZfDaa-Govv5gYAuYziv4W8=.8c540ac0-229f-416f-a389-4706aa962fee@github.com> Message-ID: On Tue, 22 Mar 2022 07:51:18 GMT, Sibabrata Sahoo wrote: >> Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update AbstractDelegateHttpsURLConnection.java Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7759 From rhalade at openjdk.java.net Tue Mar 22 16:36:35 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 22 Mar 2022 16:36:35 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From rhalade at openjdk.java.net Tue Mar 22 16:36:36 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 22 Mar 2022 16:36:36 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 00:26:01 GMT, Bradford Wetmore wrote: >> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. >> >> should this be updated to only list 2022? > > In previous days, we used to include the dates from the templates, which this test was derived from. I could go either way. I am not knowledgable one in this area and thought was merely a typo. Fine either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From erikj at openjdk.java.net Tue Mar 22 16:58:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Mar 2022 16:58:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 14:04:07 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: > > - rename syslookup lib on Windows > - Add missing LIBS flag > - Simplify syslookup build changes make/modules/java.base/Lib.gmk line 217: > 215: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > 216: LIBS := $(LIBCXX), \ > 217: LIBS_linux := -lc -lm -ldl, \ This looks much better, thanks! Now if you could just fix the indentation of the parameters to 4 spaces, it would be perfect. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From coffeys at openjdk.java.net Tue Mar 22 18:06:37 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 22 Mar 2022 18:06:37 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: <73Vy89xx_L1sVm-XLDO-vKtWGjxVZFxth9df-EW2I1A=.58649c54-a4bf-42d6-b13f-512e097a9c16@github.com> On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From mcimadamore at openjdk.java.net Tue Mar 22 19:07:12 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 19:07:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix indentation in Lib.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/4b2760d3..7ec71f73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mullan at openjdk.java.net Tue Mar 22 19:21:36 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 22 Mar 2022 19:21:36 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 14:42:53 GMT, Xue-Lei Andrew Fan wrote: >> Can you be more specific? I'm not following where you think they should be ordered. Are you suggesting they should be ordered before the anon suites even though most of them use stronger algorithms? Also, does the order matter if the application is going to be setting them via APIs? For example, if an application calls `SSLSocket.setEnabledCipherSuites(new String[] { "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA" })` is the order specified respected? Or does the provider re-order it according to this file? > > In some situation, applications may set the supported cipher suites as the enabled cipher suites. Therefore, the supported cipher suites are also ordered in the current implementation, even though not strictly. Although 3DES suites are pretty weak, but they might be better than anon suites in practice, I think. I see. That makes sense. However, I will note that the current order does not reflect the preference rules defined in lines 336-348 (copied below): // Definition of the CipherSuites that are supported but not enabled // by default. // They are listed in preference order, preferred first, using the // following criteria: // 1. If a cipher suite has been obsoleted, we put it at the end of // the list. // 2. Prefer the stronger bulk cipher, in the order of AES_256, // AES_128, 3DES-EDE, RC-4, DES, DES40, RC4_40, NULL. // 3. Prefer the stronger MAC algorithm, in the order of SHA384, // SHA256, SHA, MD5. // 4. Prefer the better performance of key exchange and digital // signature algorithm, in the order of ECDHE-ECDSA, ECDHE-RSA, // RSA, ECDH-ECDSA, ECDH-RSA, DHE-RSA, DHE-DSS, anonymous. In particular, some of the RC4 suites support forward secrecy but are ordered after the anon suites. The rules above say nothing about anon suites. They seem to be ordered as higher priority than others mainly because they use stronger ciphers. But 3DES and RC4 are obsolete suites, so maybe it is correct that they should be where they are. Thus, it isn't clear to me if the current order does or does not accurately reflect these rules. I put the 3DES suites where they were because to me they are probably/maybe stronger than the RC4 suites, but do not use strong ciphers that the anon suites do, and are obsolete. So we either need to clarify the rules and put anon suites lower, and change the obsolete rule. Otherwise, I'm reluctant to make a change that seems inconsistent with the rules. Having said all that, I also don't want to over-rotate on this and try to decide what suite is more weaker than others, since you really shouldn't be using any of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From xuelei at openjdk.java.net Tue Mar 22 19:38:34 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Mar 2022 19:38:34 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 19:40:07 GMT, Sean Mullan wrote: > This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. > > Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From xuelei at openjdk.java.net Tue Mar 22 19:38:34 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Mar 2022 19:38:34 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 19:18:24 GMT, Sean Mullan wrote: > So we either need to clarify the rules and put anon suites lower, and change the obsolete rule. It makes sense to me. It might be better to update the rules firstly (or just leave it alone as the priority is pretty low), but which is out of the scope of this update. I will approve this update. ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From erikj at openjdk.java.net Tue Mar 22 20:46:31 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Mar 2022 20:46:31 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 19:07:12 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation in Lib.gmk Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mullan at openjdk.java.net Tue Mar 22 21:21:14 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 22 Mar 2022 21:21:14 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list [v2] In-Reply-To: References: Message-ID: > This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. > > Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Move TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA and SSL_DH_anon_WITH_3DES_EDE_CBC_SHA lower in priority after other 3DES suites. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7894/files - new: https://git.openjdk.java.net/jdk/pull/7894/files/aed9c954..9edfa9ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7894&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7894&range=00-01 Stats: 18 lines in 1 file changed: 9 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7894.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7894/head:pull/7894 PR: https://git.openjdk.java.net/jdk/pull/7894 From mullan at openjdk.java.net Tue Mar 22 21:21:15 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 22 Mar 2022 21:21:15 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 19:34:17 GMT, Xue-Lei Andrew Fan wrote: >> I see. That makes sense. However, I will note that the current order does not reflect the preference rules defined in lines 336-348 (copied below): >> >> >> // Definition of the CipherSuites that are supported but not enabled >> // by default. >> // They are listed in preference order, preferred first, using the >> // following criteria: >> // 1. If a cipher suite has been obsoleted, we put it at the end of >> // the list. >> // 2. Prefer the stronger bulk cipher, in the order of AES_256, >> // AES_128, 3DES-EDE, RC-4, DES, DES40, RC4_40, NULL. >> // 3. Prefer the stronger MAC algorithm, in the order of SHA384, >> // SHA256, SHA, MD5. >> // 4. Prefer the better performance of key exchange and digital >> // signature algorithm, in the order of ECDHE-ECDSA, ECDHE-RSA, >> // RSA, ECDH-ECDSA, ECDH-RSA, DHE-RSA, DHE-DSS, anonymous. >> >> In particular, some of the RC4 suites support forward secrecy but are ordered after the anon suites. The rules above say nothing about anon suites. They seem to be ordered as higher priority than others mainly because they use stronger ciphers. But 3DES and RC4 are obsolete suites, so maybe it is correct that they should be where they are. >> >> Thus, it isn't clear to me if the current order does or does not accurately reflect these rules. I put the 3DES suites where they were because to me they are probably/maybe stronger than the RC4 suites, but do not use strong ciphers that the anon suites do, and are obsolete. So we either need to clarify the rules and put anon suites lower, and change the obsolete rule. Otherwise, I'm reluctant to make a change that seems inconsistent with the rules. >> >> Having said all that, I also don't want to over-rotate on this and try to decide what suite is more weaker than others, since you really shouldn't be using any of them. > >> So we either need to clarify the rules and put anon suites lower, and change the obsolete rule. > > It makes sense to me. It might be better to update the rules firstly (or just leave it alone as the priority is pretty low), but which is out of the scope of this update. I will approve this update. Ok, let me think about whether this is worth improving as a separate issue. I did make one change to the order however, and that is to move the TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA and SSL_DH_anon_WITH_3DES_EDE_CBC_SHA suites lower in priority after other 3DES suites as these clearly should be lower in priority because they are using 3DES and anonymous authn. ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From valeriep at openjdk.java.net Tue Mar 22 21:25:28 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 22 Mar 2022 21:25:28 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor code refactoring ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/c8ae1655..1eb63292 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=05-06 Stats: 20 lines in 1 file changed: 1 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From xuelei at openjdk.java.net Tue Mar 22 21:39:31 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Mar 2022 21:39:31 GMT Subject: RFR: 8163327: Remove 3DES from the default enabled cipher suites list [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 21:21:14 GMT, Sean Mullan wrote: >> This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. >> >> Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Move TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA and SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > lower in priority after other 3DES suites. Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7894 From valeriep at openjdk.java.net Wed Mar 23 00:36:55 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 00:36:55 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor Message-ID: Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. A CSR will be filed once the wording changes are reviewed. Thanks, Valerie ------------- Commit messages: - 8254935: Deprecate the PSSParameterSpec(int) constructor Changes: https://git.openjdk.java.net/jdk/pull/7913/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254935 Stats: 26 lines in 2 files changed: 18 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From wetmore at openjdk.java.net Wed Mar 23 01:16:27 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 23 Mar 2022 01:16:27 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 16:32:22 GMT, Rajan Halade wrote: >> In previous days, we used to include the dates from the templates, which this test was derived from. I could go either way. > > I am not knowledgable one in this area and thought was merely a typo. Fine either way. I'll leave for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From wetmore at openjdk.java.net Wed Mar 23 01:16:27 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 23 Mar 2022 01:16:27 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: <4fRUYXBjP7by_UNsrj5DU977__d-2kGIKMKQCb5Wmy0=.b877858c-3c70-4f25-91f4-6196b3dff1d2@github.com> <4VpdRd67pLgvszi56l8JVrhiQPRk_gWcLeX02U9gRXQ=.b23ca773-bdec-4725-ad4a-8a36b6d65029@github.com> Message-ID: On Tue, 22 Mar 2022 12:28:44 GMT, Sean Coffey wrote: >> Sigh...this is a whole can of worms I wasn't expecting. Looks like one person did the SSLContextTemplate and updated with SSLEngineTemplate, then another person took a completely different takes with SSLSocketTemplate, and then SSLSocketSSLEngineTemplate didn't get touched at all. >> >> This should really be harmonized. :( > > ouch - maybe this should be fixed up in a separate bug then. Don't think it should be a blocker for this fix Assessing how much work it will be. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From weijun at openjdk.java.net Wed Mar 23 01:23:33 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Mar 2022 01:23:33 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Minor code refactoring Everything looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7652 From weijun at openjdk.java.net Wed Mar 23 02:58:28 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Mar 2022 02:58:28 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 00:29:16 GMT, Valerie Peng wrote: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 114: > 112: * recommended to explicitly specify all desired parameter > 113: * values with > 114: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. We are deprecating a field so I would say "This field uses default values defined in ... which may become...". Do we need to write "PKCS #1" with a blank inside? Same below. Also, the "all desired parameter values" phrase is perfect for the constructor below but this is for a field not a method so "parameters" does not make sense to me. How about something like "Instead of using this field, user should create a new `PSSParameterSpec` object by calling..." or we can just not mention it. User would need to create one anyway. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 118: > 116: * @since 1.5 > 117: */ > 118: @Deprecated(since="19", forRemoval=true) Do we really want to remove it in the future? It's awkward but probably not so harmful. Removing it may unnecessarily break existing codes. Same with the constructor below. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 178: > 176: * less than 0 > 177: * @deprecated This constructor uses the default values as defined in > 178: * ASN.1 encoding in PKCS#1 except for the salt length. These Add "the" before "ASN.1 encoding". src/java.base/share/classes/sun/security/rsa/PSSParameters.java line 83: > 81: @Override > 82: protected void engineInit(byte[] encoded) throws IOException { > 83: // first initialize with the ASN.1 DEFAULT defined in PKCS#1 v2.2 "DEFAULT values"? Also, "PKCS #1". ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From xuelei at openjdk.java.net Wed Mar 23 04:54:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Mar 2022 04:54:26 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: Message-ID: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Minor code refactoring src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: > 127: return currVal; > 128: } > 129: I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. Or did I miss something? src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > 135: public static final int DEF_ED_KEY_SIZE; > 136: public static final int DEF_XEC_KEY_SIZE; > 137: private static final AtomicInteger DEF_AES_KEY_SIZE; See the previous comment, maybe it could be `public static final int DEF_AES_KEY_SIZE.` ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From ssahoo at openjdk.java.net Wed Mar 23 06:50:34 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 23 Mar 2022 06:50:34 GMT Subject: Integrated: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive In-Reply-To: References: Message-ID: <97oXmMX1Yy5SS5Pt4PHkOsWojq39kls1UYfZZfby0Xw=.46fa1099-4320-400b-92a9-23dad11d51a4@github.com> On Wed, 9 Mar 2022 15:03:31 GMT, Sibabrata Sahoo wrote: > Domain value for system property jdk.https.negotiate.cbt is case-insensitive now. Included Test has been updated to address the change. This pull request has now been integrated. Changeset: 86015e15 Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/86015e15a5105a779ee065cca64479c8d4fbc074 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive Reviewed-by: weijun, rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/7759 From aturbanov at openjdk.java.net Wed Mar 23 07:31:23 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 23 Mar 2022 07:31:23 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v3] In-Reply-To: References: Message-ID: > Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo fix more typos, found by Sean Coffey ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/files - new: https://git.openjdk.java.net/jdk/pull/7879/files/4c1e68ed..1baca5ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=01-02 Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From aivanov at openjdk.java.net Wed Mar 23 10:15:36 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 23 Mar 2022 10:15:36 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v3] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 07:31:23 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8283426: Fix 'exeption' typo > fix more typos, found by Sean Coffey Marked as reviewed by aivanov (Reviewer). test/jdk/javax/sql/testng/test/rowset/serial/SerialJavaObjectTests.java line 46: > 44: > 45: /* > 46: * Validate that an SerialException is thrown when the object specified Suggestion: * Validate that a SerialException is thrown when the object specified ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From dfuchs at openjdk.java.net Wed Mar 23 11:38:34 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 23 Mar 2022 11:38:34 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 799: > 797: } finally { > 798: conContext.closeInbound(); > 799: engineLock.unlock(); I see that `onContext.closeInbound()` might throw, which would leave the `engineLock` locked and could cause deadlocks down the road. So maybe you should have a nested `try { } finally { }` here to make sure the lock is properly unlocked. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From mcimadamore at openjdk.java.net Wed Mar 23 14:06:56 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 23 Mar 2022 14:06:56 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop redundant javadoc statements re. handling of nulls (handling of nulls is specified once and for all in the package javadoc) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/7ec71f73..c9bc9a70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=03-04 Stats: 12 lines in 2 files changed: 3 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From xuelei at openjdk.java.net Wed Mar 23 15:13:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Mar 2022 15:13:32 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 11:34:33 GMT, Daniel Fuchs wrote: >> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. >> >> This change introduces similar behavior to SSLEngine. >> >> The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. >> >> Tier1/2 mach5 tests have been successfully run. > > src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 799: > >> 797: } finally { >> 798: conContext.closeInbound(); >> 799: engineLock.unlock(); > > I see that `onContext.closeInbound()` might throw, which would leave the `engineLock` locked and could cause deadlocks down the road. So maybe you should have a nested `try { } finally { }` here to make sure the lock is properly unlocked. +1. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From wetmore at openjdk.java.net Wed Mar 23 16:48:24 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 23 Mar 2022 16:48:24 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 15:10:21 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 799: >> >>> 797: } finally { >>> 798: conContext.closeInbound(); >>> 799: engineLock.unlock(); >> >> I see that `onContext.closeInbound()` might throw, which would leave the `engineLock` locked and could cause deadlocks down the road. So maybe you should have a nested `try { } finally { }` here to make sure the lock is properly unlocked. > > +1. Good catch. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From mr.chrisvest at gmail.com Wed Mar 23 16:54:41 2022 From: mr.chrisvest at gmail.com (Chris Vest) Date: Wed, 23 Mar 2022 09:54:41 -0700 Subject: SSLEngine.unwrap on read-only input ByteBuffer Message-ID: Hi, In Netty we've been trying to design some safer APIs, and attempted to make more use of read-only ByteBuffers. We discovered that SSLEngine.unwrap does not like read-only input buffers, even though the input buffers should in theory only be read from. We obviously make sure that the output buffers are writable. By my reading of the javadoc, and the code, I believe this was intended to work - or at least not intended to not work - but probably wasn't tested directly. When we try we get this stack trace on adopt-openjdk-11.0.7: javax.net.ssl.SSLProtocolException: null > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:118) > at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:668) > at > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:623) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:441) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:420) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:674) > at io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > at > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > ... 20 common frames omitted > Caused by: java.nio.ReadOnlyBufferException: null > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2493) > at > java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1629) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > ... 31 common frames omitted I also tried this on a panama-preview snapshot JDK I have, and got a similar stack trace: % java -version > openjdk version "19-internal" 2022-09-20 > OpenJDK Runtime Environment (fastdebug build > 19-internal-adhoc.chris.panama-foreign) > OpenJDK 64-Bit Server VM (fastdebug build > 19-internal-adhoc.chris.panama-foreign, mixed mode) % git show > commit 144af9f43cd2d6f88b675b8c85e4034e5b9d6695 (HEAD -> foreign-preview, > origin/foreign-preview) javax.net.ssl.SSLProtocolException: null > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:121) > at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) > at > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:719) > at io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > at > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > ... 20 common frames omitted > Caused by: java.nio.ReadOnlyBufferException: null > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2497) > at > java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1933) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > ... 31 common frames omitted We can work around this in Netty since we need to support JDK versions that has this issue anyway, but I think it's a bug that should be fixed at some point. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.java.net Wed Mar 23 17:01:12 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 23 Mar 2022 17:01:12 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v2] In-Reply-To: References: Message-ID: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. Bradford Wetmore 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 12 additional commits since the last revision: - Code review comment: enclose conContext.closeInbound() in a try/finally block. - Merge branch 'master' into JDK-8273553 - Merge branch 'master' into JDK-8273553 - Added SSLSocket bugid since we're actually checking both sides now. - I/O Issues, rewrite the I/O section so that early Socket closes don't kill our server-side reads. - Merge branch 'master' into JDK-8273553 - Merge branch 'master' into JDK-8273553 - Merge - Minor test tweaks. - Remove inadvertent whitespace - ... and 2 more: https://git.openjdk.java.net/jdk/compare/84577bde...b2f64d92 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7796/files - new: https://git.openjdk.java.net/jdk/pull/7796/files/43953018..b2f64d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7796&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7796&range=00-01 Stats: 4167 lines in 793 files changed: 2485 ins; 1099 del; 583 mod Patch: https://git.openjdk.java.net/jdk/pull/7796.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7796/head:pull/7796 PR: https://git.openjdk.java.net/jdk/pull/7796 From bradford.wetmore at oracle.com Wed Mar 23 17:38:36 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 23 Mar 2022 10:38:36 -0700 Subject: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: Message-ID: <3a0a0011-40bb-36a1-e62f-e8863a2f3403@oracle.com> Offhand, sounds like a bug to me. I've filed: https://bugs.openjdk.java.net/browse/JDK-8283577 to track. It's possible an optimization might have been done using an in-place en/decryption, but it should work. By chance, do you have a simple reproducer handy? If not, we should be able to come up with one if it is what I think it is. Brad On 3/23/2022 9:54 AM, Chris Vest wrote: > Hi, > > In Netty we've been trying to design some safer APIs, and attempted to > make more use of read-only ByteBuffers. > > We discovered that SSLEngine.unwrap does not like read-only input > buffers, even though the input buffers should in theory only be read > from. We obviously make sure that the output buffers are writable. > > By my reading of the javadoc, and the code, I believe this was intended > to work - or at least not intended to not work - but probably wasn't > tested directly. > > When we try we get this stack trace on adopt-openjdk-11.0.7: > > javax.net.ssl.SSLProtocolException: null > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:118) > at > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:668) > at > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:623) > at > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:441) > at > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:420) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:674) > at io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > at > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > ... 20 common frames omitted > Caused by: java.nio.ReadOnlyBufferException: null > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2493) > at > java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1629) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > ... 31 common frames omitted > > > I also tried this on a panama-preview snapshot JDK I have, and got a > similar stack trace: > > % java -version > openjdk version "19-internal" 2022-09-20 > OpenJDK Runtime Environment (fastdebug build > 19-internal-adhoc.chris.panama-foreign) > OpenJDK 64-Bit Server VM (fastdebug build > 19-internal-adhoc.chris.panama-foreign, mixed mode) > > > % git show > commit 144af9f43cd2d6f88b675b8c85e4034e5b9d6695 (HEAD -> > foreign-preview, origin/foreign-preview) > > > javax.net.ssl.SSLProtocolException: null > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:121) > at > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) > at > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) > at > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) > at > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:719) > at io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > at > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > at > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > ... 20 common frames omitted > Caused by: java.nio.ReadOnlyBufferException: null > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2497) > at > java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1933) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > ... 31 common frames omitted > > > We can work around this in Netty since we need to support JDK versions > that has this issue anyway, but I think it's a bug that should be fixed > at some point. > > Thanks, > Chris > From xuelei at openjdk.java.net Wed Mar 23 18:17:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Mar 2022 18:17:39 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v2] In-Reply-To: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> References: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> Message-ID: On Wed, 23 Mar 2022 17:01:12 GMT, Bradford Wetmore wrote: >> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. >> >> This change introduces similar behavior to SSLEngine. >> >> The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. >> >> Tier1/2 mach5 tests have been successfully run. > > Bradford Wetmore 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 12 additional commits since the last revision: > > - Code review comment: enclose conContext.closeInbound() in a try/finally block. > - Merge branch 'master' into JDK-8273553 > - Merge branch 'master' into JDK-8273553 > - Added SSLSocket bugid since we're actually checking both sides now. > - I/O Issues, rewrite the I/O section so that early Socket closes don't kill our server-side reads. > - Merge branch 'master' into JDK-8273553 > - Merge branch 'master' into JDK-8273553 > - Merge > - Minor test tweaks. > - Remove inadvertent whitespace > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1662472a...b2f64d92 src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 802: > 800: } finally { > 801: engineLock.unlock(); > 802: } I looked the update further. It would be nice if the try-statement could support more than one finally blocks in the future so that the code could be more clear. try { ... } finally { // the 1st final block } finally { // the 2nd final block } For the block from 781 to 787, it may be more effective if moving the block out of the synchronization lock (that's, moving 781-787 to line 779.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From mullan at openjdk.java.net Wed Mar 23 18:36:31 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 23 Mar 2022 18:36:31 GMT Subject: Integrated: 8163327: Remove 3DES from the default enabled cipher suites list In-Reply-To: References: Message-ID: <26eTeEV7buq0EzTxRy0hx4XA3ggTx-k_tLC81EoVVrk=.fdc1e205-b03e-4777-b330-94d1087d0ad4@github.com> On Mon, 21 Mar 2022 19:40:07 GMT, Sean Mullan wrote: > This fix removes obsolete and deprecated 3DES cipher suites from the default enabled cipher suites list of the SunJSSE provider implementation. > > Note that 3DES suites are already disabled by default via the `jdk.tls.disabledAlgorithms` security property. This change goes one step further and provides an extra level of defense by making them unavailable by default. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8283450 This pull request has now been integrated. Changeset: 138460c0 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/138460c004a9a21a84f892896cf2f172fab2ac99 Stats: 137 lines in 4 files changed: 83 ins; 35 del; 19 mod 8163327: Remove 3DES from the default enabled cipher suites list Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7894 From aturbanov at openjdk.java.net Wed Mar 23 19:41:58 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 23 Mar 2022 19:41:58 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v4] In-Reply-To: References: Message-ID: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com> > Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/files - new: https://git.openjdk.java.net/jdk/pull/7879/files/1baca5ea..2ee3c98a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From valeriep at openjdk.java.net Wed Mar 23 20:49:53 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 20:49:53 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> Message-ID: <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> On Wed, 23 Mar 2022 04:46:48 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor code refactoring > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: > >> 127: return currVal; >> 128: } >> 129: > > I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. > > Or did I miss something? My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From xuelei at openjdk.java.net Wed Mar 23 21:54:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Mar 2022 21:54:46 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> Message-ID: On Wed, 23 Mar 2022 20:45:22 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: >> >>> 127: return currVal; >>> 128: } >>> 129: >> >> I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. >> >> Or did I miss something? > > My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). I see. Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 23 22:02:49 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 22:02:49 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> Message-ID: On Wed, 23 Mar 2022 21:51:51 GMT, Xue-Lei Andrew Fan wrote: >> My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). > > I see. > > Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? Sure, I can do that. Will add a comment about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 23 22:48:41 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 22:48:41 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added comment regarding possible deadlocks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/1eb63292..a48ccef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=06-07 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Thu Mar 24 00:42:48 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 00:42:48 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 02:37:18 GMT, Weijun Wang wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 178: > >> 176: * less than 0 >> 177: * @deprecated This constructor uses the default values as defined in >> 178: * ASN.1 encoding in PKCS#1 except for the salt length. These > > Add "the" before "ASN.1 encoding". Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Thu Mar 24 00:55:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 00:55:44 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 02:46:20 GMT, Weijun Wang wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 114: > >> 112: * recommended to explicitly specify all desired parameter >> 113: * values with >> 114: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. > > We are deprecating a field so I would say "This field uses default values defined in ... which may become...". > > Do we need to write "PKCS #1" with a blank inside? Same below. > > Also, the "all desired parameter values" phrase is perfect for the constructor below but this is for a field not a method so "parameters" does not make sense to me. How about something like "Instead of using this field, user should create a new `PSSParameterSpec` object by calling..." or we can just not mention it. User would need to create one anyway. Well, I did a quick search, it seems both PKCS#X and PKCS #X are used interchangeably. I use PKCS#X to be consistent within this file. Maybe it does not matter much? I thought we tend to return without the space, e.g. PKCS8EncodedKeySpec.getFormat(). Other wording suggestions incorporated. Thanks~ ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Thu Mar 24 01:00:46 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 01:00:46 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 02:51:08 GMT, Weijun Wang wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 118: > >> 116: * @since 1.5 >> 117: */ >> 118: @Deprecated(since="19", forRemoval=true) > > Do we really want to remove it in the future? It's awkward but probably not so harmful. Removing it may unnecessarily break existing codes. Same with the constructor below. Hmm, I am under the impression that we tend to use forRemoval=true when deprecating stuff, so users may pay more attention to it. This does not mean that we MUST remove it? Also, marking it for removal would give users more time in case something came up and removal become necessary? > src/java.base/share/classes/sun/security/rsa/PSSParameters.java line 83: > >> 81: @Override >> 82: protected void engineInit(byte[] encoded) throws IOException { >> 83: // first initialize with the ASN.1 DEFAULT defined in PKCS#1 v2.2 > > "DEFAULT values"? Also, "PKCS #1". Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From weijun at openjdk.java.net Thu Mar 24 01:40:47 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Mar 2022 01:40:47 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor In-Reply-To: References: Message-ID: <4Td-PLB5CTHbuEuXk7QwOEVxM-s8lvGsnFGWbDgAv9o=.7f3fd67c-d707-4b55-aa7f-bf5ff082c74f@github.com> On Thu, 24 Mar 2022 00:52:28 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 114: >> >>> 112: * recommended to explicitly specify all desired parameter >>> 113: * values with >>> 114: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. >> >> We are deprecating a field so I would say "This field uses default values defined in ... which may become...". >> >> Do we need to write "PKCS #1" with a blank inside? Same below. >> >> Also, the "all desired parameter values" phrase is perfect for the constructor below but this is for a field not a method so "parameters" does not make sense to me. How about something like "Instead of using this field, user should create a new `PSSParameterSpec` object by calling..." or we can just not mention it. User would need to create one anyway. > > Well, I did a quick search, it seems both PKCS#X and PKCS #X are used interchangeably. I use PKCS#X to be consistent within this file. Maybe it does not matter much? I thought we tend to return without the space, e.g. PKCS8EncodedKeySpec.getFormat(). Other wording suggestions incorporated. Thanks~ My understanding is that if there is a "#" then there should be a " " before it. However, if the format without the space is already used elsewhere, we can keep using it. >> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 118: >> >>> 116: * @since 1.5 >>> 117: */ >>> 118: @Deprecated(since="19", forRemoval=true) >> >> Do we really want to remove it in the future? It's awkward but probably not so harmful. Removing it may unnecessarily break existing codes. Same with the constructor below. > > Hmm, I am under the impression that we tend to use forRemoval=true when deprecating stuff, so users may pay more attention to it. This does not mean that we MUST remove it? Also, marking it for removal would give users more time in case something came up and removal become necessary? You are right that there is no rule that an API deprecated for removal must be removed. OK, you decide what the best way is. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From wetmore at openjdk.java.net Thu Mar 24 05:01:55 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 24 Mar 2022 05:01:55 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v2] In-Reply-To: References: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> Message-ID: On Wed, 23 Mar 2022 18:09:46 GMT, Xue-Lei Andrew Fan wrote: >> Bradford Wetmore 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 12 additional commits since the last revision: >> >> - Code review comment: enclose conContext.closeInbound() in a try/finally block. >> - Merge branch 'master' into JDK-8273553 >> - Merge branch 'master' into JDK-8273553 >> - Added SSLSocket bugid since we're actually checking both sides now. >> - I/O Issues, rewrite the I/O section so that early Socket closes don't kill our server-side reads. >> - Merge branch 'master' into JDK-8273553 >> - Merge branch 'master' into JDK-8273553 >> - Merge >> - Minor test tweaks. >> - Remove inadvertent whitespace >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/fdf65be0...b2f64d92 > > src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 802: > >> 800: } finally { >> 801: engineLock.unlock(); >> 802: } > > I looked the update further. It would be nice if the try-statement could support more than one finally blocks in the future so that the code could be more clear. > > try { > ... > } finally { > // the 1st final block > } finally { > // the 2nd final block > } > > > For the block from 781 to 787, it may be more effective if moving the block out of the synchronization lock (that's, moving 781-787 to line 779.) I'm not following your first comment. AFAIK, double finally blocks aren't currently an option, unless I'm missing a new language feature. Or is this just a general "it would be nice if the Java language was able to do..." comment? try { ... throw new SSLException(...); } finally { conContext.closeInbound(); } finally { engineLock.unlock(); } As to your second question, the model of: method() { engineLock.lock(); try { action(); } finally { engineUnlock.unlock(); } } is very simple to understand and thus maintain, and is used quite consistently throughout SSLEngineImpl and catches any problems. IIUC, you are suggesting: public void closeInbound() throws SSLException { if (isInboundDone()) { return; } if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { SSLLogger.finest("Closing inbound of SSLEngine"); } engineLock.lock(); try { if (!conContext.isInputCloseNotified && (conContext.isNegotiated || conContext.handshakeContext != null)) { throw new SSLException( "closing inbound before receiving peer's close_notify"); } } finally { try { conContext.closeInbound(); } finally { engineLock.unlock(); } } } What is the advantage to changing to this style, other than a very small performance win by not locking in the already closed case? Isn't the locking code pretty optimized? SSLLogger might throw a NPE (unlikely), and isInboundDone() just checks a variable, but the code could change down the road. I'm just not seeing a reason to change the maintainability of this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From xuelei at openjdk.java.net Thu Mar 24 06:45:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 24 Mar 2022 06:45:42 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 22:48:41 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Added comment regarding possible deadlocks. Looks good to me. Thanks! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > 135: public static final int DEF_ED_KEY_SIZE; > 136: public static final int DEF_XEC_KEY_SIZE; > 137: // the logic for finding the max allowable value in getDefAESKeySize() Capital the 1st letter? ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7652 From xuelei at openjdk.java.net Thu Mar 24 06:45:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 24 Mar 2022 06:45:43 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> Message-ID: On Wed, 23 Mar 2022 21:59:02 GMT, Valerie Peng wrote: >> I see. >> >> Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? > > Sure, I can do that. Will add a comment about this. Thank you. I have no more comment except a minor nit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From anders.rundgren.net at gmail.com Thu Mar 24 06:46:46 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Thu, 24 Mar 2022 07:46:46 +0100 Subject: "Pluggable" key serialization in JCE/JCA Message-ID: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> Hi List, I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth to Java's internal representation. This reduces the value of the abstract types as well. Now there is whole bunch of new algorithms coming to the Java platform making this task even less attractive. So my question is simply: How about including this part in an enhanced JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding this complexity from users and library developers? Eventually you could end up with something like: PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or stream); You would not even have to know in which format the key is supplied in since this could be accomplished by simple "sniffing". To make "pluggability" feasible, I'm trying to convince the JOSE/COSE folks to give each new crypto system a separate namespace as an alternative to overloading OKP (RFC 8037), even if the parameters match technically.? AFAICT, X.509 public keys essentially already adhere to this notion. I would exclude private key import and export in HSMs since these are specific and rare occasions. WDYT? Thanx, Anders From xuelei at openjdk.java.net Thu Mar 24 06:51:51 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 24 Mar 2022 06:51:51 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v2] In-Reply-To: References: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> Message-ID: On Wed, 23 Mar 2022 18:09:46 GMT, Xue-Lei Andrew Fan wrote: >> Bradford Wetmore 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 12 additional commits since the last revision: >> >> - Code review comment: enclose conContext.closeInbound() in a try/finally block. >> - Merge branch 'master' into JDK-8273553 >> - Merge branch 'master' into JDK-8273553 >> - Added SSLSocket bugid since we're actually checking both sides now. >> - I/O Issues, rewrite the I/O section so that early Socket closes don't kill our server-side reads. >> - Merge branch 'master' into JDK-8273553 >> - Merge branch 'master' into JDK-8273553 >> - Merge >> - Minor test tweaks. >> - Remove inadvertent whitespace >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/2cf735d5...b2f64d92 > > src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 802: > >> 800: } finally { >> 801: engineLock.unlock(); >> 802: } > > I looked the update further. It would be nice if the try-statement could support more than one finally blocks in the future so that the code could be more clear. > > try { > ... > } finally { > // the 1st final block > } finally { > // the 2nd final block > } > > > For the block from 781 to 787, it may be more effective if moving the block out of the synchronization lock (that's, moving 781-787 to line 779.) > @XueleiFan, I'm not following your first comment. Sorry for that. I was wondering something new in the future, which is not doable in the current Java language. Please just leave it alone. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From wetmore at openjdk.java.net Thu Mar 24 06:51:51 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 24 Mar 2022 06:51:51 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v2] In-Reply-To: References: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> Message-ID: On Thu, 24 Mar 2022 06:45:46 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 802: >> >>> 800: } finally { >>> 801: engineLock.unlock(); >>> 802: } >> >> I looked the update further. It would be nice if the try-statement could support more than one finally blocks in the future so that the code could be more clear. >> >> try { >> ... >> } finally { >> // the 1st final block >> } finally { >> // the 2nd final block >> } >> >> >> For the block from 781 to 787, it may be more effective if moving the block out of the synchronization lock (that's, moving 781-787 to line 779.) > >> @XueleiFan, I'm not following your first comment. > > Sorry for that. I was wondering something new in the future, which is not doable in the current Java language. Please just leave it alone. Ah! Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From xuelei at openjdk.java.net Thu Mar 24 06:57:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 24 Mar 2022 06:57:48 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v2] In-Reply-To: References: <9IaupdelfNFjZ8LyjXRH8X4btW2t-b7F1zb8UYafjbc=.8d451c4b-30bc-4834-9bef-4dc54d900117@github.com> Message-ID: On Thu, 24 Mar 2022 06:48:00 GMT, Bradford Wetmore wrote: >>> @XueleiFan, I'm not following your first comment. >> >> Sorry for that. I was wondering something new in the future, which is not doable in the current Java language. Please just leave it alone. > > Ah! Thanks. > IIUC, you are suggesting: > ... snipped ... Yes. > What is the advantage to changing to this style, other than a very small performance win by not locking in the already closed case? The advantage is mainly about the performance, as I/O of SSLLogger could be slow. The SSLSocketImpl code does not put the similar block locked. But it may be not the purpose of this update. I'm fine if you want to leave it alone. ------------- PR: https://git.openjdk.java.net/jdk/pull/7796 From ssahoo at openjdk.java.net Thu Mar 24 10:47:17 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 24 Mar 2022 10:47:17 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule Message-ID: Added coverage to logout method. ------------- Commit messages: - 8281717: Cover logout method for several LoginModule Changes: https://git.openjdk.java.net/jdk/pull/7940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7940&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281717 Stats: 49 lines in 1 file changed: 29 ins; 11 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7940/head:pull/7940 PR: https://git.openjdk.java.net/jdk/pull/7940 From jvernee at openjdk.java.net Thu Mar 24 13:16:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 13:16:53 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 14:06:56 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Drop redundant javadoc statements re. handling of nulls > (handling of nulls is specified once and for all in the package javadoc) Some more nits. One potential issue with adding --enable-preview when building benchmarks (last comment of the bunch). Other than that, I think this looks good. make/test/BuildMicrobenchmark.gmk line 97: > 95: SRC := $(MICROBENCHMARK_SRC), \ > 96: BIN := $(MICROBENCHMARK_CLASSES), \ > 97: JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \ It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 61: > 59: *

  • {@linkplain MemorySegment#allocateNative(long, long, MemorySession) native memory segments}, backed by off-heap memory;
  • > 60: *
  • {@linkplain FileChannel#map(FileChannel.MapMode, long, long, MemorySession) mapped memory segments}, obtained by mapping > 61: * a file into main memory ({@code mmap}); tha contents of a mapped memory segments can be {@linkplain #force() persisted} and Suggestion: * a file into main memory ({@code mmap}); the contents of a mapped memory segments can be {@linkplain #force() persisted} and src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 298: > 296: > 297: /** > 298: * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address Saw a similar change in other places, so I'll suggest this here as well. Suggestion: * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 311: > 309: > 310: /** > 311: * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address Suggestion: * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address src/java.base/share/classes/java/lang/foreign/MemorySession.java line 143: > 141: > 142: /** > 143: * {@return the owner thread associated with this memory session (if any)} Maybe the "if any" here could be more specific. e.g. saying that `null` is returned if the session doesn't have an owner thread. src/java.base/share/classes/java/lang/foreign/MemorySession.java line 165: > 163: > 164: /** > 165: * Closes this memory session. As a side effect, if this operation completes without exceptions, this session I'd suggest change this to "As a result of this", since the effects listed are the main reason for closing a session. (it strikes me as strange. If the things listed are side-effects, then what is the main effect of closing a segment?) Suggestion: * Closes this memory session. As a result of this, if this operation completes without exceptions, this session src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 51: > 49: *

    > 50: * Clients can obtain a {@linkplain #loaderLookup() loader lookup}, > 51: * which can be used to search symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)}, "search symbols" sounds a bit unnatural to me... I like the wording in the libraryLookup doc more Suggestion: * which can be used to find symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)}, src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 59: > 57: *

    > 58: * Finally, clients can load a library and obtain a {@linkplain #libraryLookup(Path, MemorySession) library lookup} which can be used > 59: * to search symbols in that library. A library lookup is associated with a {@linkplain MemorySession memory session}, Suggestion: * to find symbols in that library. A library lookup is associated with a {@linkplain MemorySession memory session}, src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7895: > 7893: * VarHandle handle = MethodHandles.memorySegmentViewVarHandle(ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN)); //(MemorySegment, long) -> int > 7894: * handle = MethodHandles.insertCoordinates(handle, 1, 4); //(MemorySegment) -> int > 7895: * } These could be snippets. Also, I think it would be nice to add a link to MemoryLayout.varHandle here. src/java.base/share/classes/java/nio/channels/FileChannel.java line 975: > 973: /** > 974: * Maps a region of this channel's file into a new mapped memory segment, > 975: * with a given offset, size and memory session. Suggestion: * with the given offset, size and memory session. src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 51: > 49: > 50: /* A fallback lookup, used when creation of system lookup fails. */ > 51: private static final Function> fallbackLookup = name -> Optional.empty(); Now that we have SymbolLookup again, these Function types could potentially be changed to SymbolLookup again. (and also avoid some churn here) src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135: > 133: } > 134: > 135: public Optional lookup(String name) { `@Override` here? src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071: > 1069: sessionImpl.checkValidStateSlow(); > 1070: if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0."); > 1071: if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0."); The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Thu Mar 24 14:11:50 2022 From: duke at openjdk.java.net (duke) Date: Thu, 24 Mar 2022 14:11:50 GMT Subject: Withdrawn: 8255739: x509Certificate returns =?UTF-8?B?77+9?= for invalid subjectAlternativeNames In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 11:59:18 GMT, Masanori Yano wrote: > Could you please review the JDK-8255739 bug fix? > > I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the substituted characters, which is explained in the description of BugDB. > > I modified DerValue.readStringInternal() not to read incorrect SubjectAlternativeNames and throw an IOException. sun.security.x509.X509CertInfo.parse() catch the IOExcepton and ignore it if SAN is a non-ciritical extension like the behavior of the IOException in readStringInternal(). So I added a test with -Djava.security.debug=x509 to confirm that. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6928 From mstjohns at comcast.net Thu Mar 24 15:59:47 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 24 Mar 2022 11:59:47 -0400 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> Message-ID: <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> On 3/24/2022 2:46 AM, Anders Rundgren wrote: > Hi List, > > I find it a bit strange that every user of crypto either have to write > or install specific software for converting JOSE/COSE/PEM keys > back-and-forth to Java's internal representation. This reduces the > value of the abstract types as well. > > Now there is whole bunch of new algorithms coming to the Java platform > making this task even less attractive. > > So my question is simply: How about including this part in an enhanced > JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding > this complexity from users and library developers? Hi Anders - Isn't that the exact purpose for KeyFactory and its plugins? You might need to add KeySpec types for Jose and Cose (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those cover all of the secret, public and private key specifications. Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or GenericEncodedKeySpec (String alg, String encodedKey). > > Eventually you could end up with something like: > > PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or > stream); > > You would not even have to know in which format the key is supplied in > since this could be accomplished by simple "sniffing". Nope.? This isn't safe as someone might up with yet another representation that looks like one of the "sniffable" ones.? You could build a private implementation that takes its best shot, but .... > > To make "pluggability" feasible, I'm trying to convince the JOSE/COSE > folks to give each new crypto system a separate namespace as an > alternative to overloading OKP (RFC 8037), even if the parameters > match technically.? AFAICT, X.509 public keys essentially already > adhere to this notion. > > I would exclude private key import and export in HSMs since these are > specific and rare occasions. Again, no.? Don't do this in an incomplete way - it will come back to bite you.? You don't have to implement the plugin that talks to the HSM, but you have to define the mechanism/API so that the HSM vendors don't curse your first born child later. Mike > > WDYT? > > Thanx, > Anders From mr.chrisvest at gmail.com Thu Mar 24 16:13:55 2022 From: mr.chrisvest at gmail.com (Chris Vest) Date: Thu, 24 Mar 2022 09:13:55 -0700 Subject: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <3a0a0011-40bb-36a1-e62f-e8863a2f3403@oracle.com> References: <3a0a0011-40bb-36a1-e62f-e8863a2f3403@oracle.com> Message-ID: On Wed, Mar 23, 2022 at 10:38 AM Bradford Wetmore < bradford.wetmore at oracle.com> wrote: > Offhand, sounds like a bug to me. I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8283577 Thanks. The in-place use of the input buffer might also be unexpected even when the buffer is not read-only. > By chance, do you have a simple reproducer handy? > See https://github.com/netty/netty/pull/12213#issuecomment-1077796917 > > Brad > > > > On 3/23/2022 9:54 AM, Chris Vest wrote: > > Hi, > > > > In Netty we've been trying to design some safer APIs, and attempted to > > make more use of read-only ByteBuffers. > > > > We discovered that SSLEngine.unwrap does not like read-only input > > buffers, even though the input buffers should in theory only be read > > from. We obviously make sure that the output buffers are writable. > > > > By my reading of the javadoc, and the code, I believe this was intended > > to work - or at least not intended to not work - but probably wasn't > > tested directly. > > > > When we try we get this stack trace on adopt-openjdk-11.0.7: > > > > javax.net.ssl.SSLProtocolException: null > > at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > > at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326) > > at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) > > at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > > at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:118) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:668) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:623) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:441) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:420) > > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:674) > > at io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > > at > > > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > > at > > > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > > at > > > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > > ... 20 common frames omitted > > Caused by: java.nio.ReadOnlyBufferException: null > > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2493) > > at > > > java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1629) > > at > > > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) > > at > > > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) > > at > > > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) > > at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > > ... 31 common frames omitted > > > > > > I also tried this on a panama-preview snapshot JDK I have, and got a > > similar stack trace: > > > > % java -version > > openjdk version "19-internal" 2022-09-20 > > OpenJDK Runtime Environment (fastdebug build > > 19-internal-adhoc.chris.panama-foreign) > > OpenJDK 64-Bit Server VM (fastdebug build > > 19-internal-adhoc.chris.panama-foreign, mixed mode) > > > > > > % git show > > commit 144af9f43cd2d6f88b675b8c85e4034e5b9d6695 (HEAD -> > > foreign-preview, origin/foreign-preview) > > > > > > javax.net.ssl.SSLProtocolException: null > > at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > > at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) > > at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) > > at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) > > at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:121) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) > > at > > > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) > > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:719) > > at io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > > at > > > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > > at > > > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > > at > > > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > > ... 20 common frames omitted > > Caused by: java.nio.ReadOnlyBufferException: null > > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2497) > > at > > > java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1933) > > at > > > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) > > at > > > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) > > at > > > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) > > at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > > ... 31 common frames omitted > > > > > > We can work around this in Netty since we need to support JDK versions > > that has this issue anyway, but I think it's a bug that should be fixed > > at some point. > > > > Thanks, > > Chris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueleifan at tencent.com Thu Mar 24 16:27:20 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Thu, 24 Mar 2022 16:27:20 +0000 Subject: [Internet]"Pluggable" key serialization in JCE/JCA In-Reply-To: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> Message-ID: <89428495-FFB8-49A7-86DF-7EF940CCE456@Tencent.Com> > On Mar 23, 2022, at 11:46 PM, Anders Rundgren wrote: > > Hi List, > > I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth to Java's internal representation. This reduces the value of the abstract types as well. > > Now there is whole bunch of new algorithms coming to the Java platform making this task even less attractive. > > So my question is simply: How about including this part in an enhanced JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding this complexity from users and library developers? > > Eventually you could end up with something like: > > PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or stream); > > You would not even have to know in which format the key is supplied in since this could be accomplished by simple "sniffing". > If I understand the proposal correctly, it may be challenging in the current JCA/JCE framework, especially for interoperability, unless one just wants to work with one provider only. A third provider need to understand the private key spec so that it can work with it. It may be doable by defining the export method accordingly, but again it will run into the problem you concerned about ?converting the keys back-and-forth?. Xuelei > To make "pluggability" feasible, I'm trying to convince the JOSE/COSE folks to give each new crypto system a separate namespace as an alternative to overloading OKP (RFC 8037), even if the parameters match technically. AFAICT, X.509 public keys essentially already adhere to this notion. > > I would exclude private key import and export in HSMs since these are specific and rare occasions. > > WDYT? > > Thanx, > Anders > From anders.rundgren.net at gmail.com Thu Mar 24 16:28:57 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Thu, 24 Mar 2022 17:28:57 +0100 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> Message-ID: <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> On 2022-03-24 16:59, Michael StJohns wrote: > On 3/24/2022 2:46 AM, Anders Rundgren wrote: >> Hi List, >> >> I find it a bit strange that every user of crypto either have to write >> or install specific software for converting JOSE/COSE/PEM keys >> back-and-forth to Java's internal representation. This reduces the >> value of the abstract types as well. >> >> Now there is whole bunch of new algorithms coming to the Java platform >> making this task even less attractive. >> >> So my question is simply: How about including this part in an enhanced >> JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding >> this complexity from users and library developers? > > Hi Anders - Hi Mike, > > Isn't that the exact purpose for KeyFactory and its plugins? They presume that you know not only the key algorithm but the associated parameters as well. Why should users or library developers have to deal with that? The requirement to know key algorithm in advance forces you into ASN.1 decoding for dealing with PEMs. Been there done that. > > You might need to add KeySpec types for Jose and Cose > (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those cover > all of the secret, public and private key specifications. > > Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or > GenericEncodedKeySpec (String alg, String encodedKey). > > >> >> Eventually you could end up with something like: >> >> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or >> stream); >> >> You would not even have to know in which format the key is supplied in >> since this could be accomplished by simple "sniffing". > > Nope.? This isn't safe as someone might up with yet another > representation that looks like one of the "sniffable" ones.? You could > build a private implementation that takes its best shot, but .... Finding out if the container is COSE, JOSE, or PEM is (AFAICT) trivial. If the guess is incorrect a properly designed decoder should simply fail. > >> >> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE >> folks to give each new crypto system a separate namespace as an >> alternative to overloading OKP (RFC 8037), even if the parameters >> match technically.? AFAICT, X.509 public keys essentially already >> adhere to this notion. >> >> I would exclude private key import and export in HSMs since these are >> specific and rare occasions. > > Again, no.? Don't do this in an incomplete way - it will come back to > bite you.? You don't have to implement the plugin that talks to the HSM, > but you have to define the mechanism/API so that the HSM vendors don't > curse your first born child later. This is little bit out of my league but targeting the masses is core. Anders > > Mike > > >> >> WDYT? >> >> Thanx, >> Anders > > From anders.rundgren.net at gmail.com Thu Mar 24 16:34:46 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Thu, 24 Mar 2022 17:34:46 +0100 Subject: [Internet]"Pluggable" key serialization in JCE/JCA In-Reply-To: <89428495-FFB8-49A7-86DF-7EF940CCE456@Tencent.Com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <89428495-FFB8-49A7-86DF-7EF940CCE456@Tencent.Com> Message-ID: <65e9b8cf-f686-8df9-1506-6be41bcdf62a@gmail.com> On 2022-03-24 17:27, xueleifan(XueleiFan) wrote: > >> On Mar 23, 2022, at 11:46 PM, Anders Rundgren wrote: >> >> Hi List, >> >> I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth to Java's internal representation. This reduces the value of the abstract types as well. >> >> Now there is whole bunch of new algorithms coming to the Java platform making this task even less attractive. >> >> So my question is simply: How about including this part in an enhanced JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding this complexity from users and library developers? >> >> Eventually you could end up with something like: >> >> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or stream); >> >> You would not even have to know in which format the key is supplied in since this could be accomplished by simple "sniffing". >> > > If I understand the proposal correctly, it may be challenging in the current JCA/JCE framework, especially for interoperability, unless one just wants to work with one provider only. A third provider need to understand the private key spec so that it can work with it. It may be doable by defining the export method accordingly, but again it will run into the problem you concerned about ?converting the keys back-and-forth?. The idea is that each provider would also have a converter for the algorithms it support. This is what I meant with "pluggable". If you want to use a specific provider you would specify that as well. Thanx, Anders > > Xuelei > > >> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE folks to give each new crypto system a separate namespace as an alternative to overloading OKP (RFC 8037), even if the parameters match technically. AFAICT, X.509 public keys essentially already adhere to this notion. >> >> I would exclude private key import and export in HSMs since these are specific and rare occasions. >> >> WDYT? >> >> Thanx, >> Anders >> > From mcimadamore at openjdk.java.net Thu Mar 24 17:57:16 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 17:57:16 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/c9bc9a70..95f65eea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 17:57:19 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 17:57:19 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 13:10:20 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop redundant javadoc statements re. handling of nulls >> (handling of nulls is specified once and for all in the package javadoc) > > make/test/BuildMicrobenchmark.gmk line 97: > >> 95: SRC := $(MICROBENCHMARK_SRC), \ >> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >> 97: JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \ > > It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version. Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From valeriep at openjdk.java.net Thu Mar 24 18:11:50 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 18:11:50 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 06:41:11 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment regarding possible deadlocks. > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > >> 135: public static final int DEF_ED_KEY_SIZE; >> 136: public static final int DEF_XEC_KEY_SIZE; >> 137: // the logic for finding the max allowable value in getDefAESKeySize() > > Capital the 1st letter? Ok~ ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Thu Mar 24 18:16:23 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 18:16:23 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v9] In-Reply-To: References: Message-ID: <92zDCOTW4v6y8rwrO9990oQ-XSc6C14VLJPPyezzOpU=.d3efec00-dd3d-4fea-b29f-f24d3019f474@github.com> > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Use uppercase for 1st letter in some comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/a48ccef5..8b7bc16a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From mcimadamore at openjdk.java.net Thu Mar 24 18:19:09 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 18:19:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/95f65eea..3e8cfd74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=05-06 Stats: 16 lines in 3 files changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 18:19:12 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 18:19:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 13:00:12 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop redundant javadoc statements re. handling of nulls >> (handling of nulls is specified once and for all in the package javadoc) > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071: > >> 1069: sessionImpl.checkValidStateSlow(); >> 1070: if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0."); >> 1071: if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0."); > > The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing? `mapInternal` in FileChannelImpl takes care of that for both flavors of `map` ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Thu Mar 24 18:38:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 18:38:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 17:48:23 GMT, Maurizio Cimadamore wrote: >> make/test/BuildMicrobenchmark.gmk line 97: >> >>> 95: SRC := $(MICROBENCHMARK_SRC), \ >>> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 97: JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \ >> >> It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version. > > Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well. I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick: diff --git a/make/RunTests.gmk b/make/RunTests.gmk index 81540266ec0..9ed45fb02a8 100644 --- a/make/RunTests.gmk +++ b/make/RunTests.gmk @@ -583,7 +583,7 @@ define SetupRunMicroTestBody $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS)) # Current tests needs to open java.io - $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED + $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview # Save output as JSON or CSV file ifneq ($$(MICRO_RESULTS_FORMAT), ) People manually running the benchmarks.jar will have to pass `--enable-preview` still though. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From valeriep at openjdk.java.net Thu Mar 24 18:58:28 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 18:58:28 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2] In-Reply-To: References: Message-ID: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to address review feedbacks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/ef502bc9..7e37deb4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=00-01 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From mcimadamore at openjdk.java.net Thu Mar 24 18:59:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 18:59:11 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v8] In-Reply-To: References: Message-ID: <6yP7vgmmPmX36zl3Lp0Dxw48sxlimGcfvOI0YrM4Bt0=.86078fb2-182d-44a1-b861-a7a234073f40@github.com> > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3e8cfd74..6881b6dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From valeriep at openjdk.java.net Thu Mar 24 19:01:49 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 19:01:49 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2] In-Reply-To: <4Td-PLB5CTHbuEuXk7QwOEVxM-s8lvGsnFGWbDgAv9o=.7f3fd67c-d707-4b55-aa7f-bf5ff082c74f@github.com> References: <4Td-PLB5CTHbuEuXk7QwOEVxM-s8lvGsnFGWbDgAv9o=.7f3fd67c-d707-4b55-aa7f-bf5ff082c74f@github.com> Message-ID: On Thu, 24 Mar 2022 01:37:15 GMT, Weijun Wang wrote: >> Hmm, I am under the impression that we tend to use forRemoval=true when deprecating stuff, so users may pay more attention to it. This does not mean that we MUST remove it? Also, marking it for removal would give users more time in case something came up and removal become necessary? > > You are right that there is no rule that an API deprecated for removal must be removed. OK, you decide what the best way is. It's true that the chance of removing it is not that high (at least based on current situation). So, I removed the forRemoval=true part as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From mcimadamore at openjdk.java.net Thu Mar 24 19:05:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:05:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v9] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address more review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6881b6dc..d95c6d0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=07-08 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 19:12:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:12:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add --enable-preview to micro benchmark java options ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/d95c6d0f..6e7189b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From aivanov at openjdk.java.net Thu Mar 24 19:25:53 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 24 Mar 2022 19:25:53 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v4] In-Reply-To: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com> References: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com> Message-ID: On Wed, 23 Mar 2022 19:41:58 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8283426: Fix 'exeption' typo > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From jvernee at openjdk.java.net Thu Mar 24 19:27:22 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 19:27:22 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 19:19:34 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to RunTests.gmk Looks Good! ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 19:27:21 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:27:21 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Revert changes to RunTests.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6e7189b4..504b564a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Thu Mar 24 19:27:23 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 19:27:23 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:35:12 GMT, Jorn Vernee wrote: >> Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well. > > I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick: > > > diff --git a/make/RunTests.gmk b/make/RunTests.gmk > index 81540266ec0..9ed45fb02a8 100644 > --- a/make/RunTests.gmk > +++ b/make/RunTests.gmk > @@ -583,7 +583,7 @@ define SetupRunMicroTestBody > $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS)) > > # Current tests needs to open java.io > - $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED > + $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview > > # Save output as JSON or CSV file > ifneq ($$(MICRO_RESULTS_FORMAT), ) > > > People manually running the benchmarks.jar will have to pass `--enable-preview` still though. After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 19:27:24 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:27:24 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 19:17:40 GMT, Jorn Vernee wrote: >> I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick: >> >> >> diff --git a/make/RunTests.gmk b/make/RunTests.gmk >> index 81540266ec0..9ed45fb02a8 100644 >> --- a/make/RunTests.gmk >> +++ b/make/RunTests.gmk >> @@ -583,7 +583,7 @@ define SetupRunMicroTestBody >> $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS)) >> >> # Current tests needs to open java.io >> - $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED >> + $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview >> >> # Save output as JSON or CSV file >> ifneq ($$(MICRO_RESULTS_FORMAT), ) >> >> >> People manually running the benchmarks.jar will have to pass `--enable-preview` still though. > > After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted. Turns out this is no longer necessary. As part of the support for preview API, javac now only pollutes the classfile if a source file is using preview features, as described in this PR: https://github.com/openjdk/jdk/pull/703 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From aturbanov at openjdk.java.net Thu Mar 24 19:54:48 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 24 Mar 2022 19:54:48 GMT Subject: Integrated: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` This pull request has now been integrated. Changeset: dc5a65ab Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/dc5a65ab378f0780f7760965f2b52cbbd7c62aad Stats: 38 lines in 17 files changed: 0 ins; 2 del; 36 mod 8283426: Fix 'exeption' typo Reviewed-by: xuelei, iris, dholmes, wetmore, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From sean.mullan at oracle.com Thu Mar 24 20:05:02 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Mar 2022 16:05:02 -0400 Subject: JEP Review Request: TLS Certificate Compression In-Reply-To: References: Message-ID: <66667359-7a4f-4fdb-2b8a-5384d9b9a29b@oracle.com> On 3/21/22 11:49 AM, xueleifan(XueleiFan) wrote: > Hi, > > > The JDK Enhancement Proposal, TLS Certificate Compression, has been > opened for community review. ?Detailed, please refer to the draft: > > https://bugs.openjdk.java.net/browse/JDK-8281710 Or a more readable version at https://openjdk.java.net/jeps/8281710 --Sean > > and the discussion of this potential feature at security-dev: > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html > > > Please feel free to make comments and review the JEP. > > Thanks, > Xuelei From valeriep at openjdk.java.net Thu Mar 24 20:12:42 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 20:12:42 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:58:28 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to address review feedbacks. CSR filed at https://bugs.openjdk.java.net/browse/JDK-8283650 Please review, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From bradford.wetmore at oracle.com Thu Mar 24 20:31:34 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 24 Mar 2022 13:31:34 -0700 Subject: [External] : Re: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <3a0a0011-40bb-36a1-e62f-e8863a2f3403@oracle.com> Message-ID: <45a355b6-d69c-27bd-ac8a-9f2ca0e425ac@oracle.com> Problem easily duplicated, thanks for the reproducer. I've updated the bug with the info. Brad On 3/24/2022 9:13 AM, Chris Vest wrote: > On Wed, Mar 23, 2022 at 10:38 AM Bradford Wetmore > > wrote: > > Offhand, sounds like a bug to me.? I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8283577 > > > > Thanks. The in-place use of the input buffer might also be unexpected > even when the buffer is not read-only. > > By chance, do you have a simple reproducer handy? > > > See https://github.com/netty/netty/pull/12213#issuecomment-1077796917 > > > > Brad > > > > On 3/23/2022 9:54 AM, Chris Vest wrote: > > Hi, > > > > In Netty we've been trying to design some safer APIs, and > attempted to > > make more use of read-only ByteBuffers. > > > > We discovered that SSLEngine.unwrap does not like read-only input > > buffers, even though the input buffers should in theory only be read > > from. We obviously make sure that the output buffers are writable. > > > > By my reading of the javadoc, and the code, I believe this was > intended > > to work - or at least not intended to not work - but probably wasn't > > tested directly. > > > > When we try we get this stack trace on adopt-openjdk-11.0.7: > > > >? ? ?javax.net.ssl.SSLProtocolException: null > >? ? ?at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > >? ? ?at > > > ?java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326) > >? ? ?at > > > ?java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) > >? ? ?at > > > ?java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > >? ? ?at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:118) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:668) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:623) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:441) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:420) > >? ? ?at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:674) > >? ? ?at > io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > >? ? ?at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > >? ? ?at > > > ?io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > >? ? ?at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > >? ? ?at > > > ?io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > >? ? ?at > > > ?io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > >? ? ?... 20 common frames omitted > >? ? ?Caused by: java.nio.ReadOnlyBufferException: null > >? ? ?at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2493) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1629) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) > >? ? ?at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > >? ? ?... 31 common frames omitted > > > > > > I also tried this on a panama-preview snapshot JDK I have, and got a > > similar stack trace: > > > >? ? ?% java -version > >? ? ?openjdk version "19-internal" 2022-09-20 > >? ? ?OpenJDK Runtime Environment (fastdebug build > >? ? ?19-internal-adhoc.chris.panama-foreign) > >? ? ?OpenJDK 64-Bit Server VM (fastdebug build > >? ? ?19-internal-adhoc.chris.panama-foreign, mixed mode) > > > > > >? ? ?% git show > >? ? ?commit 144af9f43cd2d6f88b675b8c85e4034e5b9d6695 (HEAD -> > >? ? ?foreign-preview, origin/foreign-preview) > > > > > >? ? ?javax.net.ssl.SSLProtocolException: null > >? ? ?at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > >? ? ?at > > > ?java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) > >? ? ?at > > > ?java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) > >? ? ?at > > > ?java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) > >? ? ?at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:121) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) > >? ? ?at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:719) > >? ? ?at > io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) > >? ? ?at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) > >? ? ?at > > > ?io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) > >? ? ?at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) > >? ? ?at > > > ?io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) > >? ? ?at > > > ?io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) > >? ? ?... 20 common frames omitted > >? ? ?Caused by: java.nio.ReadOnlyBufferException: null > >? ? ?at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2497) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1933) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) > >? ? ?at > > > ?java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) > >? ? ?at > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > >? ? ?... 31 common frames omitted > > > > > > We can work around this in Netty since we need to support JDK > versions > > that has this issue anyway, but I think it's a bug that should be > fixed > > at some point. > > > > Thanks, > > Chris > > > From weijun at openjdk.java.net Thu Mar 24 20:31:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Mar 2022 20:31:48 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:58:28 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to address review feedbacks. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 112: > 110: * @deprecated This field uses the default values defined in the ASN.1 > 111: * encoding in PKCS#1 which may become obsolete as time progresses. > 112: * Thus, it is recommended to create a new PSSParameterSpec object Should `PSSParameterSpec` be inside a `{@code ...}`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From weijun at openjdk.java.net Thu Mar 24 20:36:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Mar 2022 20:36:48 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2] In-Reply-To: References: Message-ID: <4YwiHU1kQOYiU1fIaGyl5xcch42IMjoTVZq2T9yCtwU=.1f8d1d7c-7197-40c3-aa51-84507ccc390a@github.com> On Thu, 24 Mar 2022 18:58:28 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to address review feedbacks. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 74: > 72: * TrailerField -- 1 > 73: * > 74: *

    Its values are based on the default values in the ASN.1 encoding Maybe "defined in the ASN.1..."? src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 75: > 73: * > 74: *

    Its values are based on the default values in the ASN.1 encoding > 75: * from PKCS#1 standard and may become obsolete as time progresses. Either "the PKCS#1 standard" or simply "PKCS#1" sounds good, but "PKCS#1 standard" without "the"? src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 76: > 74: *

    Its values are based on the default values in the ASN.1 encoding > 75: * from PKCS#1 standard and may become obsolete as time progresses. > 76: * Please do not rely on PSSParameterSpec.DEFAULT unless these values are Put `PSSParameterSpec.DEFAULT` in `{@code...}`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From norman.maurer at googlemail.com Thu Mar 24 20:46:52 2022 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 24 Mar 2022 21:46:52 +0100 Subject: [External] : Re: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <45a355b6-d69c-27bd-ac8a-9f2ca0e425ac@oracle.com> References: <45a355b6-d69c-27bd-ac8a-9f2ca0e425ac@oracle.com> Message-ID: <053E0909-FDD7-4572-92A3-D94AF917EAEB@googlemail.com> I agree with Chris here that doing in-place modification of the source buffer is really surprising even if it?s not read-only. This really sounds like something I would consider a ?breaking change? as I can?t imagine users would expect this at all (nothing was ever in the javadocs that would suggest this behavior) Bye Norman > Am 24.03.2022 um 21:32 schrieb Bradford Wetmore : > > ?Problem easily duplicated, thanks for the reproducer. > > I've updated the bug with the info. > > Brad > > >> On 3/24/2022 9:13 AM, Chris Vest wrote: >> On Wed, Mar 23, 2022 at 10:38 AM Bradford Wetmore > wrote: >> Offhand, sounds like a bug to me. I've filed: >> https://bugs.openjdk.java.net/browse/JDK-8283577 >> >> Thanks. The in-place use of the input buffer might also be unexpected even when the buffer is not read-only. >> By chance, do you have a simple reproducer handy? >> See https://github.com/netty/netty/pull/12213#issuecomment-1077796917 >> Brad >> On 3/23/2022 9:54 AM, Chris Vest wrote: >> > Hi, >> > >> > In Netty we've been trying to design some safer APIs, and >> attempted to >> > make more use of read-only ByteBuffers. >> > >> > We discovered that SSLEngine.unwrap does not like read-only input >> > buffers, even though the input buffers should in theory only be read >> > from. We obviously make sure that the output buffers are writable. >> > >> > By my reading of the javadoc, and the code, I believe this was >> intended >> > to work - or at least not intended to not work - but probably wasn't >> > tested directly. >> > >> > When we try we get this stack trace on adopt-openjdk-11.0.7: >> > >> > javax.net.ssl.SSLProtocolException: null >> > at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) >> > at >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326) >> > at >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) >> > at >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >> > at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:118) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:668) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:623) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:441) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:420) >> > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:674) >> > at >> io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) >> > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) >> > at >> > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) >> > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) >> > at >> > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) >> > at >> > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) >> > ... 20 common frames omitted >> > Caused by: java.nio.ReadOnlyBufferException: null >> > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2493) >> > at >> > java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1629) >> > at >> > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) >> > at >> > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) >> > at >> > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) >> > at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) >> > ... 31 common frames omitted >> > >> > >> > I also tried this on a panama-preview snapshot JDK I have, and got a >> > similar stack trace: >> > >> > % java -version >> > openjdk version "19-internal" 2022-09-20 >> > OpenJDK Runtime Environment (fastdebug build >> > 19-internal-adhoc.chris.panama-foreign) >> > OpenJDK 64-Bit Server VM (fastdebug build >> > 19-internal-adhoc.chris.panama-foreign, mixed mode) >> > >> > >> > % git show >> > commit 144af9f43cd2d6f88b675b8c85e4034e5b9d6695 (HEAD -> >> > foreign-preview, origin/foreign-preview) >> > >> > >> > javax.net.ssl.SSLProtocolException: null >> > at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) >> > at >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) >> > at >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) >> > at >> > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) >> > at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:121) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) >> > at >> > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) >> > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:719) >> > at >> io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100) >> > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227) >> > at >> > io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105) >> > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165) >> > at >> > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384) >> > at >> > io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327) >> > ... 20 common frames omitted >> > Caused by: java.nio.ReadOnlyBufferException: null >> > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2497) >> > at >> > java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1933) >> > at >> > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) >> > at >> > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) >> > at >> > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) >> > at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) >> > ... 31 common frames omitted >> > >> > >> > We can work around this in Netty since we need to support JDK >> versions >> > that has this issue anyway, but I think it's a bug that should be >> fixed >> > at some point. >> > >> > Thanks, >> > Chris >> > From rick.hillegas at gmail.com Thu Mar 24 21:27:25 2022 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Thu, 24 Mar 2022 14:27:25 -0700 Subject: protecting security-sensitive operations on multi-tenant servers Message-ID: <3a162d52-7566-4af5-0a4f-56754a660b30@gmail.com> The Apache Derby community is getting ready to vet a new release which can be used on Java 17. Before buttoning down the release, I wanted to check in on current best practices for defending enterprise applications against the threats which the Java Security Manager parries. There may be some work we could do to better prepare our users for a future without a Security Manager. In particular, what are current best Java practices for protecting a multi-tenant server against abuse of the following security-sensitive operations: o Reading and setting of system properties. o Creation of class loaders. o File access o Network access o De-registration of JDBC drivers Thanks, -Rick From naoto at openjdk.java.net Thu Mar 24 22:11:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 24 Mar 2022 22:11:30 GMT Subject: RFR: 8282819: Deprecate Locale class constructors Message-ID: Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. ------------- Commit messages: - 8282819: Deprecate Locale class constructors Changes: https://git.openjdk.java.net/jdk/pull/7947/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282819 Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From valeriep at openjdk.java.net Thu Mar 24 22:53:56 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 22:53:56 GMT Subject: Integrated: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! This pull request has now been integrated. Changeset: 313bc7f6 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/313bc7f64f69d8f352d495d2c35bea62aca910e4 Stats: 504 lines in 29 files changed: 326 ins; 8 del; 170 mod 8267319: Use larger default key sizes and algorithms based on CNSA Reviewed-by: weijun, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Thu Mar 24 23:02:50 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 23:02:50 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2] In-Reply-To: <4YwiHU1kQOYiU1fIaGyl5xcch42IMjoTVZq2T9yCtwU=.1f8d1d7c-7197-40c3-aa51-84507ccc390a@github.com> References: <4YwiHU1kQOYiU1fIaGyl5xcch42IMjoTVZq2T9yCtwU=.1f8d1d7c-7197-40c3-aa51-84507ccc390a@github.com> Message-ID: On Thu, 24 Mar 2022 20:30:20 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated to address review feedbacks. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 74: > >> 72: * TrailerField -- 1 >> 73: * >> 74: *

    Its values are based on the default values in the ASN.1 encoding > > Maybe "defined in the ASN.1..."? Sure. > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 75: > >> 73: * >> 74: *

    Its values are based on the default values in the ASN.1 encoding >> 75: * from PKCS#1 standard and may become obsolete as time progresses. > > Either "the PKCS#1 standard" or simply "PKCS#1" sounds good, but "PKCS#1 standard" without "the"? Ok, I will add "the". > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 76: > >> 74: *

    Its values are based on the default values in the ASN.1 encoding >> 75: * from PKCS#1 standard and may become obsolete as time progresses. >> 76: * Please do not rely on PSSParameterSpec.DEFAULT unless these values are > > Put `PSSParameterSpec.DEFAULT` in `{@code...}`? Yes, will do. > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 112: > >> 110: * @deprecated This field uses the default values defined in the ASN.1 >> 111: * encoding in PKCS#1 which may become obsolete as time progresses. >> 112: * Thus, it is recommended to create a new PSSParameterSpec object > > Should `PSSParameterSpec` be inside a `{@code ...}`? Yes, good catch. Will fix. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From rhalade at openjdk.java.net Thu Mar 24 23:05:49 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 24 Mar 2022 23:05:49 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 10:41:18 GMT, Sibabrata Sahoo wrote: > Added coverage to logout method. test/jdk/com/sun/security/auth/module/AllPlatforms.java line 26: > 24: /* > 25: * @test > 26: * @bug 8039951 8281717 No need to add bug id here as this is not a product change. test/jdk/com/sun/security/auth/module/AllPlatforms.java line 44: > 42: try { > 43: login("windows", "NTLoginModule", "required"); > 44: login("unix", "UnixLoginModule", "required"); thanks for fixing this code. Test earlier skipped UnixLoginModule early on "nix" platform as windows login would fail. test/jdk/com/sun/security/auth/module/AllPlatforms.java line 45: > 43: UNIX_MODULE, "optional", > 44: NT_MODULE, "optional"); > 45: login(OS.replaceAll("[^a-zA-Z0-9]", ""), getPlatformLoginModule(), "required"); I think test should still be run on all platforms even though login would fail. On other platforms than the test being run on, test shouldn't fail with "UnsatisfiedLinkError" as per JDK-8039951. ------------- PR: https://git.openjdk.java.net/jdk/pull/7940 From valeriep at openjdk.java.net Thu Mar 24 23:18:33 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 23:18:33 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v3] In-Reply-To: References: Message-ID: <1kUJqOj1uGv262ycTlnLGNPQwaEp02AQDi81Hm0UivQ=.e19773d0-866b-4e64-b18e-39323c8c73e2@github.com> > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Use "{@code }" and other minor edits. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/7e37deb4..73da71ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Thu Mar 24 23:28:27 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 23:28:27 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v4] In-Reply-To: References: Message-ID: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: minor fix for consistency. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/73da71ec..b8e9f9fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Thu Mar 24 23:34:30 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 23:34:30 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: More minor edits. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/b8e9f9fe..c3b5dbe8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From smarks at openjdk.java.net Fri Mar 25 00:25:47 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 25 Mar 2022 00:25:47 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Specs looks good, with minor modifications. I'm not so sure about replacement of the constructors with string concatenation with ternary operators; see my other comment. src/java.base/share/classes/java/util/Locale.java line 252: > 250: *

    The {@code Locale} class provides a number of convenient constants > 251: * that you can use to obtain {@code Locale} objects for commonly used > 252: * locales. For example, the following obtains a {@code Locale} object I'd replace this part (and the example below) with something like, For example, {@code Locale.US} is the {@code Locale} object for the United States. src/java.base/share/classes/java/util/Locale.java line 2511: > 2509: * constructors, the {@code Builder} checks if a value configured by a > 2510: * setter satisfies the syntax requirements defined by the {@code Locale} > 2511: * class. A {@code Locale} object obtained by a {@code Builder} is ...obtained from a Builder... src/java.base/share/classes/java/util/Locale.java line 2526: > 2524: * > 2525: *

    The following example shows how to obtain a {@code Locale} object > 2526: * with the {@code Builder}. ...shows how to obtain a Locale object using a Builder. src/java.base/share/classes/java/util/Locale.java line 2660: > 2658: * > 2659: *

    The country value in the {@code Locale} obtained by the > 2660: * {@code Builder} is always normalized to upper case. ...obtained from a Builder... src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375: > 373: (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) + > 374: (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) + > 375: (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant())); It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide? ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From weijun at openjdk.java.net Fri Mar 25 01:37:55 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Mar 2022 01:37:55 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 23:34:30 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > More minor edits. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 78: > 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these > 77: * values are really what you want to use. > 78: * I just read the whole class spec. Since the default values are already included on lines 38-41, I think there is no need to use so much words and we can just say "defined above". ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From naoto at openjdk.java.net Fri Mar 25 01:59:51 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 01:59:51 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375: > >> 373: (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) + >> 374: (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) + >> 375: (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant())); > > It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide? True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From mstjohns at comcast.net Fri Mar 25 02:12:07 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 24 Mar 2022 22:12:07 -0400 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> Message-ID: <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> On 3/24/2022 12:28 PM, Anders Rundgren wrote: > On 2022-03-24 16:59, Michael StJohns wrote: >> On 3/24/2022 2:46 AM, Anders Rundgren wrote: >>> Hi List, >>> >>> I find it a bit strange that every user of crypto either have to write >>> or install specific software for converting JOSE/COSE/PEM keys >>> back-and-forth to Java's internal representation. This reduces the >>> value of the abstract types as well. >>> >>> Now there is whole bunch of new algorithms coming to the Java platform >>> making this task even less attractive. >>> >>> So my question is simply: How about including this part in an enhanced >>> JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding >>> this complexity from users and library developers? >> >> Hi Anders - > > Hi Mike, > >> >> Isn't that the exact purpose for KeyFactory and its plugins? > > They presume that you know not only the key algorithm but the > associated parameters as well.? Why should users or library developers > have to deal with that? Um - no.? They presume you know the key algorithm, but (using EC Public keys for example), you can use either of the X509PublicKeySpec (to decode an encoded key), or the ECPublicKeySpec (to deal with building a key from scratch using the parameters.? You can notionally (haven't tried it, but should work) use KeyFactory.getKeySpec() to convert between the two formats or use Key.getEncoded() to get the default encoding for the key. The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and PKCS8EncodedKeySpec clases. PEM is actually not an encoding, but a wrapping of an encoding. The only part of Java that deals with it natively (I believe) is the CertificateFactory for X.509 certificates.? You may have an extra step to add or remove a PEM style envelope (or the equivalent BASE64 bare string), but that's reasonable. > > The requirement to know key algorithm in advance forces you into ASN.1 > decoding for dealing with PEMs.? Been there done that. Ah - not sure why you wouldn't know the key algorithm, BUT:? It should theoretically be possible to write a KeyFactory provider that does that decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and returns an appropriate PublicKey. Check the actual return type to figure out what type of key.? E.g.: KeyFactory kf = KeyFactory.getInstance("GenericDecoder"); As I said below, you'll need to define the equivalent opaque format KeySpec classes to handle COSE and JOSE.? I think that's a class per type of encoding. > >> >> You might need to add KeySpec types for Jose and Cose >> (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those cover >> all of the secret, public and private key specifications. >> >> Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or >> GenericEncodedKeySpec (String alg, String encodedKey). >> >> >>> >>> Eventually you could end up with something like: >>> >>> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or >>> stream); >>> >>> You would not even have to know in which format the key is supplied in >>> since this could be accomplished by simple "sniffing". >> >> Nope.? This isn't safe as someone might up with yet another >> representation that looks like one of the "sniffable" ones.? You could >> build a private implementation that takes its best shot, but .... > > Finding out if the container is COSE, JOSE, or PEM is (AFAICT) > trivial.? If the guess is incorrect a properly designed decoder should > simply fail. It's trivial NOW because its a closed set of possibilities.? And even then, you're assuming you don't have to detect ASN1 vs raw key encodings vs string encodings.? Simply detecting a) whether a file is character, b) detecting the character encoding, and c) accidentally thinking a character file is actually binary or vice versa is fragile. The addition of the "new" EC variant keys required a substantial reworking of the API to support them and the arguments were fierce.? The additions were not free. I deal with no fewer than 3 encodings for an EC public key.? Two or three for an EC private key. 2 or 3 text versions of a RSA public key along with the X509Encoded? binary version and the TPM binary version.? Etc.? I usually know what type of key I'm dealing with when I get it, but I would love a magic DWIM class that did the right thing on all inputs. > >> >>> >>> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE >>> folks to give each new crypto system a separate namespace as an >>> alternative to overloading OKP (RFC 8037), even if the parameters >>> match technically.? AFAICT, X.509 public keys essentially already >>> adhere to this notion. >>> >>> I would exclude private key import and export in HSMs since these are >>> specific and rare occasions. >> >> Again, no.? Don't do this in an incomplete way - it will come back to >> bite you.? You don't have to implement the plugin that talks to the HSM, >> but you have to define the mechanism/API so that the HSM vendors don't >> curse your first born child later. > > > This is little bit out of my league but targeting the masses is core. This is the problem with open source some times. It may be core, but it is not complete and leaving this as a problem to be worked later is a bit unprofessional. I don't mean any offense here, but there's a problem with basing everything what IOT requires and ignoring everything else. Later, Mike > > > Anders > >> >> Mike >> >> >>> >>> WDYT? >>> >>> Thanx, >>> Anders >> >> > From valeriep at openjdk.java.net Fri Mar 25 05:18:20 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 25 Mar 2022 05:18:20 GMT Subject: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 Message-ID: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. Mach5 run succeeds. Thanks, Valerie ------------- Commit messages: - 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 Changes: https://git.openjdk.java.net/jdk/pull/7952/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7952&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283665 Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7952.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7952/head:pull/7952 PR: https://git.openjdk.java.net/jdk/pull/7952 From xuelei at openjdk.java.net Fri Mar 25 05:34:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 25 Mar 2022 05:34:48 GMT Subject: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 In-Reply-To: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> References: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Message-ID: On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7952 From ascarpino at openjdk.java.net Fri Mar 25 05:47:36 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 25 Mar 2022 05:47:36 GMT Subject: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 In-Reply-To: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> References: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Message-ID: On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by ascarpino (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7952 From hchao at openjdk.java.net Fri Mar 25 06:25:47 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 25 Mar 2022 06:25:47 GMT Subject: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 In-Reply-To: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> References: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Message-ID: On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7952 From anders.rundgren.net at gmail.com Fri Mar 25 08:03:15 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 25 Mar 2022 09:03:15 +0100 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> Message-ID: Hi Mike & the JDK crypto team, What I'm saying is that key serialization in Java haven't gotten enough attention. Examples: AFAIK, there is still no support for using named curves to construct an EC key. Names curves are MANDATORY in JOSE/CODE. The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is simply put GIGANTIC: https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html The only obvious solution is rolling your own: https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java This code [probably] stinks but it is hardly my fault... The JDK crypto team is the only party who can clean up this mess. Since importing X.509 certificates through PKCS12/KeyStore works out of the box without any a prior knowledge of key algorithms, there is already a precedent. It is almost just copy and paste :) The new crypto systems that are on the way in (BLS, Post Quantum), accentuates this issue. Regarding HSMs, I gave it one more thought and I didn't come up with any connections except maybe in Keytool but HSMs appear to be X.509-oriented which not the case with COSE/JOSE. Regards, Anders On 2022-03-25 3:12, Michael StJohns wrote: > On 3/24/2022 12:28 PM, Anders Rundgren wrote: >> On 2022-03-24 16:59, Michael StJohns wrote: >>> On 3/24/2022 2:46 AM, Anders Rundgren wrote: >>>> Hi List, >>>> >>>> I find it a bit strange that every user of crypto either have to write >>>> or install specific software for converting JOSE/COSE/PEM keys >>>> back-and-forth to Java's internal representation. This reduces the >>>> value of the abstract types as well. >>>> >>>> Now there is whole bunch of new algorithms coming to the Java platform >>>> making this task even less attractive. >>>> >>>> So my question is simply: How about including this part in an enhanced >>>> JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding >>>> this complexity from users and library developers? >>> >>> Hi Anders - >> >> Hi Mike, >> >>> >>> Isn't that the exact purpose for KeyFactory and its plugins? >> >> They presume that you know not only the key algorithm but the >> associated parameters as well.? Why should users or library developers >> have to deal with that? > > Um - no.? They presume you know the key algorithm, but (using EC Public > keys for example), you can use either of the X509PublicKeySpec (to > decode an encoded key), or the ECPublicKeySpec (to deal with building a > key from scratch using the parameters.? You can notionally (haven't > tried it, but should work) use KeyFactory.getKeySpec() to convert > between the two formats or use Key.getEncoded() to get the default > encoding for the key. > > The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and > PKCS8EncodedKeySpec clases. > > PEM is actually not an encoding, but a wrapping of an encoding. The only > part of Java that deals with it natively (I believe) is the > CertificateFactory for X.509 certificates.? You may have an extra step > to add or remove a PEM style envelope (or the equivalent BASE64 bare > string), but that's reasonable. > >> >> The requirement to know key algorithm in advance forces you into ASN.1 >> decoding for dealing with PEMs.? Been there done that. > > Ah - not sure why you wouldn't know the key algorithm, BUT:? It should > theoretically be possible to write a KeyFactory provider that does that > decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and > returns an appropriate PublicKey. Check the actual return type to figure > out what type of key.? E.g.: > > KeyFactory kf = KeyFactory.getInstance("GenericDecoder"); > > As I said below, you'll need to define the equivalent opaque format > KeySpec classes to handle COSE and JOSE.? I think that's a class per > type of encoding. > >> >>> >>> You might need to add KeySpec types for Jose and Cose >>> (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those cover >>> all of the secret, public and private key specifications. >>> >>> Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or >>> GenericEncodedKeySpec (String alg, String encodedKey). >>> >>> >>>> >>>> Eventually you could end up with something like: >>>> >>>> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or >>>> stream); >>>> >>>> You would not even have to know in which format the key is supplied in >>>> since this could be accomplished by simple "sniffing". >>> >>> Nope.? This isn't safe as someone might up with yet another >>> representation that looks like one of the "sniffable" ones.? You could >>> build a private implementation that takes its best shot, but .... >> >> Finding out if the container is COSE, JOSE, or PEM is (AFAICT) >> trivial.? If the guess is incorrect a properly designed decoder should >> simply fail. > > It's trivial NOW because its a closed set of possibilities.? And even > then, you're assuming you don't have to detect ASN1 vs raw key encodings > vs string encodings.? Simply detecting a) whether a file is character, > b) detecting the character encoding, and c) accidentally thinking a > character file is actually binary or vice versa is fragile. > > The addition of the "new" EC variant keys required a substantial > reworking of the API to support them and the arguments were fierce.? The > additions were not free. > > I deal with no fewer than 3 encodings for an EC public key.? Two or > three for an EC private key. 2 or 3 text versions of a RSA public key > along with the X509Encoded? binary version and the TPM binary version. > Etc.? I usually know what type of key I'm dealing with when I get it, > but I would love a magic DWIM class that did the right thing on all inputs. > > >> >>> >>>> >>>> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE >>>> folks to give each new crypto system a separate namespace as an >>>> alternative to overloading OKP (RFC 8037), even if the parameters >>>> match technically.? AFAICT, X.509 public keys essentially already >>>> adhere to this notion. >>>> >>>> I would exclude private key import and export in HSMs since these are >>>> specific and rare occasions. >>> >>> Again, no.? Don't do this in an incomplete way - it will come back to >>> bite you.? You don't have to implement the plugin that talks to the HSM, >>> but you have to define the mechanism/API so that the HSM vendors don't >>> curse your first born child later. >> >> >> This is little bit out of my league but targeting the masses is core. > > This is the problem with open source some times. It may be core, but it > is not complete and leaving this as a problem to be worked later is a > bit unprofessional. > > I don't mean any offense here, but there's a problem with basing > everything what IOT requires and ignoring everything else. > > Later, Mike > > >> >> >> Anders >> >>> >>> Mike >>> >>> >>>> >>>> WDYT? >>>> >>>> Thanx, >>>> Anders >>> >>> >> > From weijun at openjdk.java.net Fri Mar 25 13:00:54 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Mar 2022 13:00:54 GMT Subject: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 In-Reply-To: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> References: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Message-ID: On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7952 From rriggs at openjdk.java.net Fri Mar 25 15:40:46 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 15:40:46 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. src/java.base/share/classes/java/util/Locale.java line 245: > 243: *

    Factory Method

    > 244: * > 245: *

    The method {@link #forLanguageTag} obtains a {@code Locale} The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory. Yes, it already exists and does what's required but you might get better uptake with a more natural name. Some alternatives: - `Locale.of("en_US")` - short and conventional - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories - `Locale.forLanguage("en_US")` - natural but less conventional ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From weijun at openjdk.java.net Fri Mar 25 15:42:09 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Mar 2022 15:42:09 GMT Subject: RFR: 8283691: Classes in java.security still reference deprecated classes in spec Message-ID: Some spec cleanup. ------------- Commit messages: - 8283691: Classes in java.security still reference deprecated classes in spec Changes: https://git.openjdk.java.net/jdk/pull/7961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7961&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283691 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7961/head:pull/7961 PR: https://git.openjdk.java.net/jdk/pull/7961 From dcubed at openjdk.java.net Fri Mar 25 15:48:55 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Mar 2022 15:48:55 GMT Subject: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 In-Reply-To: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> References: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Message-ID: On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Is this fix going to be integrated soon? We're up to 4 Tier2 job sets with these failures. That's 12 failures per Tier2 job set... ------------- PR: https://git.openjdk.java.net/jdk/pull/7952 From mstjohns at comcast.net Fri Mar 25 16:07:47 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 25 Mar 2022 12:07:47 -0400 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> Message-ID: On 3/25/2022 4:03 AM, Anders Rundgren wrote: > Hi Mike & the JDK crypto team, > > What I'm saying is that key serialization in Java haven't gotten > enough attention.? Examples: > > AFAIK, there is still no support for using named curves to construct > an EC key.? Names curves are MANDATORY in JOSE/CODE. Use AlgorithmParameterGenerator with ECGenParameterSpec.? Works like a charm. > > The gap between EdDSA keys as expressed in JOSE/COSE and the Java API > is simply put GIGANTIC: > https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html > > The only obvious solution is rolling your own: > https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java > > This code [probably] stinks but it is hardly my fault... TL;dr - but if you're talking about EDDSA and the equivalent ECDH functions their related key? ilk - well, I tried, but lost the battle to use the same API as the existing key material.? I'd call that a self inflicted wound. > > The JDK crypto team is the only party who can clean up this mess. > > Since importing X.509 certificates through PKCS12/KeyStore works out > of the box without any a prior knowledge of key algorithms, there is > already a precedent.? It is almost just copy and paste :) Yeah, but even then that model? has problems.? Cf the discussion on this list about an RSA key that was marked with RSA-OAEP as its algorithm and the issued I encountered being able to use it as java key material.?? I got back a PublicKey, but one that I couldn't coerce into an RSAPublicKey without re-encoding the key and changing the algorithm OID - it just wasn't supported.? And that model only knows about ASN1 - or did someone update the CertificateFactory for JOSE/COSE format certificates (if such a thing exists)? > > The new crypto systems that are on the way in (BLS, Post Quantum), > accentuates this issue. And the "converter" as you call it will be far behind. > > Regarding HSMs, I gave it one more thought and I didn't come up with > any connections except maybe in Keytool but HSMs appear to be > X.509-oriented which not the case with COSE/JOSE. Think PKCS11, the PKCS11 Java provider, and the ability to retrieve a public key from an HSM for various purposes.? The ability to place a private key on the HSM to secure it (there are a number of use cases where generating an unextractable private key on the HSM - the usual model - can't be used).? HSMs are cryptographically oriented not X509 oriented and new mechanisms and key types are added all the time.? They have tools to do the key loading directly - from well known formats, or programatically through things like Java PKCS11 or C PKCS11. Later, Mike > > Regards, > Anders > > On 2022-03-25 3:12, Michael StJohns wrote: >> On 3/24/2022 12:28 PM, Anders Rundgren wrote: >>> On 2022-03-24 16:59, Michael StJohns wrote: >>>> On 3/24/2022 2:46 AM, Anders Rundgren wrote: >>>>> Hi List, >>>>> >>>>> I find it a bit strange that every user of crypto either have to >>>>> write >>>>> or install specific software for converting JOSE/COSE/PEM keys >>>>> back-and-forth to Java's internal representation. This reduces the >>>>> value of the abstract types as well. >>>>> >>>>> Now there is whole bunch of new algorithms coming to the Java >>>>> platform >>>>> making this task even less attractive. >>>>> >>>>> So my question is simply: How about including this part in an >>>>> enhanced >>>>> JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding >>>>> this complexity from users and library developers? >>>> >>>> Hi Anders - >>> >>> Hi Mike, >>> >>>> >>>> Isn't that the exact purpose for KeyFactory and its plugins? >>> >>> They presume that you know not only the key algorithm but the >>> associated parameters as well.? Why should users or library developers >>> have to deal with that? >> >> Um - no.? They presume you know the key algorithm, but (using EC Public >> keys for example), you can use either of the X509PublicKeySpec (to >> decode an encoded key), or the ECPublicKeySpec (to deal with building a >> key from scratch using the parameters.? You can notionally (haven't >> tried it, but should work) use KeyFactory.getKeySpec() to convert >> between the two formats or use Key.getEncoded() to get the default >> encoding for the key. >> >> The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and >> PKCS8EncodedKeySpec clases. >> >> PEM is actually not an encoding, but a wrapping of an encoding. The only >> part of Java that deals with it natively (I believe) is the >> CertificateFactory for X.509 certificates.? You may have an extra step >> to add or remove a PEM style envelope (or the equivalent BASE64 bare >> string), but that's reasonable. >> >>> >>> The requirement to know key algorithm in advance forces you into ASN.1 >>> decoding for dealing with PEMs.? Been there done that. >> >> Ah - not sure why you wouldn't know the key algorithm, BUT:? It should >> theoretically be possible to write a KeyFactory provider that does that >> decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and >> returns an appropriate PublicKey. Check the actual return type to figure >> out what type of key.? E.g.: >> >> KeyFactory kf = KeyFactory.getInstance("GenericDecoder"); >> >> As I said below, you'll need to define the equivalent opaque format >> KeySpec classes to handle COSE and JOSE.? I think that's a class per >> type of encoding. >> >>> >>>> >>>> You might need to add KeySpec types for Jose and Cose >>>> (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those >>>> cover >>>> all of the secret, public and private key specifications. >>>> >>>> Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or >>>> GenericEncodedKeySpec (String alg, String encodedKey). >>>> >>>> >>>>> >>>>> Eventually you could end up with something like: >>>>> >>>>> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or >>>>> stream); >>>>> >>>>> You would not even have to know in which format the key is >>>>> supplied in >>>>> since this could be accomplished by simple "sniffing". >>>> >>>> Nope.? This isn't safe as someone might up with yet another >>>> representation that looks like one of the "sniffable" ones. You could >>>> build a private implementation that takes its best shot, but .... >>> >>> Finding out if the container is COSE, JOSE, or PEM is (AFAICT) >>> trivial.? If the guess is incorrect a properly designed decoder should >>> simply fail. >> >> It's trivial NOW because its a closed set of possibilities.? And even >> then, you're assuming you don't have to detect ASN1 vs raw key encodings >> vs string encodings.? Simply detecting a) whether a file is character, >> b) detecting the character encoding, and c) accidentally thinking a >> character file is actually binary or vice versa is fragile. >> >> The addition of the "new" EC variant keys required a substantial >> reworking of the API to support them and the arguments were fierce.? The >> additions were not free. >> >> I deal with no fewer than 3 encodings for an EC public key.? Two or >> three for an EC private key. 2 or 3 text versions of a RSA public key >> along with the X509Encoded? binary version and the TPM binary version. >> Etc.? I usually know what type of key I'm dealing with when I get it, >> but I would love a magic DWIM class that did the right thing on all >> inputs. >> >> >>> >>>> >>>>> >>>>> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE >>>>> folks to give each new crypto system a separate namespace as an >>>>> alternative to overloading OKP (RFC 8037), even if the parameters >>>>> match technically.? AFAICT, X.509 public keys essentially already >>>>> adhere to this notion. >>>>> >>>>> I would exclude private key import and export in HSMs since these are >>>>> specific and rare occasions. >>>> >>>> Again, no.? Don't do this in an incomplete way - it will come back to >>>> bite you.? You don't have to implement the plugin that talks to the >>>> HSM, >>>> but you have to define the mechanism/API so that the HSM vendors don't >>>> curse your first born child later. >>> >>> >>> This is little bit out of my league but targeting the masses is core. >> >> This is the problem with open source some times. It may be core, but it >> is not complete and leaving this as a problem to be worked later is a >> bit unprofessional. >> >> I don't mean any offense here, but there's a problem with basing >> everything what IOT requires and ignoring everything else. >> >> Later, Mike >> >> >>> >>> >>> Anders >>> >>>> >>>> Mike >>>> >>>> >>>>> >>>>> WDYT? >>>>> >>>>> Thanx, >>>>> Anders >>>> >>>> >>> >> > From anthony.scarpino at oracle.com Fri Mar 25 16:12:40 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 25 Mar 2022 09:12:40 -0700 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> Message-ID: <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> When you say "construct and EC key", do you mean creating an EC key from an existing set of values via PKCS8 or X509 encoding? Or are you talking about EC key generation? Tony On 3/25/22 1:03 AM, Anders Rundgren wrote: > Hi Mike & the JDK crypto team, > > What I'm saying is that key serialization in Java haven't gotten enough > attention.? Examples: > > AFAIK, there is still no support for using named curves to construct an > EC key.? Names curves are MANDATORY in JOSE/CODE. > > The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is > simply put GIGANTIC: > https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html > > The only obvious solution is rolling your own: > https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java > > This code [probably] stinks but it is hardly my fault... > > The JDK crypto team is the only party who can clean up this mess. > > Since importing X.509 certificates through PKCS12/KeyStore works out of > the box without any a prior knowledge of key algorithms, there is > already a precedent.? It is almost just copy and paste :) > > The new crypto systems that are on the way in (BLS, Post Quantum), > accentuates this issue. > > Regarding HSMs, I gave it one more thought and I didn't come up with any > connections except maybe in Keytool but HSMs appear to be X.509-oriented > which not the case with COSE/JOSE. > > Regards, > Anders > > On 2022-03-25 3:12, Michael StJohns wrote: >> On 3/24/2022 12:28 PM, Anders Rundgren wrote: >>> On 2022-03-24 16:59, Michael StJohns wrote: >>>> On 3/24/2022 2:46 AM, Anders Rundgren wrote: >>>>> Hi List, >>>>> >>>>> I find it a bit strange that every user of crypto either have to write >>>>> or install specific software for converting JOSE/COSE/PEM keys >>>>> back-and-forth to Java's internal representation. This reduces the >>>>> value of the abstract types as well. >>>>> >>>>> Now there is whole bunch of new algorithms coming to the Java platform >>>>> making this task even less attractive. >>>>> >>>>> So my question is simply: How about including this part in an enhanced >>>>> JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding >>>>> this complexity from users and library developers? >>>> >>>> Hi Anders - >>> >>> Hi Mike, >>> >>>> >>>> Isn't that the exact purpose for KeyFactory and its plugins? >>> >>> They presume that you know not only the key algorithm but the >>> associated parameters as well.? Why should users or library developers >>> have to deal with that? >> >> Um - no.? They presume you know the key algorithm, but (using EC Public >> keys for example), you can use either of the X509PublicKeySpec (to >> decode an encoded key), or the ECPublicKeySpec (to deal with building a >> key from scratch using the parameters.? You can notionally (haven't >> tried it, but should work) use KeyFactory.getKeySpec() to convert >> between the two formats or use Key.getEncoded() to get the default >> encoding for the key. >> >> The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and >> PKCS8EncodedKeySpec clases. >> >> PEM is actually not an encoding, but a wrapping of an encoding. The only >> part of Java that deals with it natively (I believe) is the >> CertificateFactory for X.509 certificates.? You may have an extra step >> to add or remove a PEM style envelope (or the equivalent BASE64 bare >> string), but that's reasonable. >> >>> >>> The requirement to know key algorithm in advance forces you into ASN.1 >>> decoding for dealing with PEMs.? Been there done that. >> >> Ah - not sure why you wouldn't know the key algorithm, BUT:? It should >> theoretically be possible to write a KeyFactory provider that does that >> decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and >> returns an appropriate PublicKey. Check the actual return type to figure >> out what type of key.? E.g.: >> >> KeyFactory kf = KeyFactory.getInstance("GenericDecoder"); >> >> As I said below, you'll need to define the equivalent opaque format >> KeySpec classes to handle COSE and JOSE.? I think that's a class per >> type of encoding. >> >>> >>>> >>>> You might need to add KeySpec types for Jose and Cose >>>> (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those >>>> cover >>>> all of the secret, public and private key specifications. >>>> >>>> Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or >>>> GenericEncodedKeySpec (String alg, String encodedKey). >>>> >>>> >>>>> >>>>> Eventually you could end up with something like: >>>>> >>>>> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or >>>>> stream); >>>>> >>>>> You would not even have to know in which format the key is supplied in >>>>> since this could be accomplished by simple "sniffing". >>>> >>>> Nope.? This isn't safe as someone might up with yet another >>>> representation that looks like one of the "sniffable" ones.? You could >>>> build a private implementation that takes its best shot, but .... >>> >>> Finding out if the container is COSE, JOSE, or PEM is (AFAICT) >>> trivial.? If the guess is incorrect a properly designed decoder should >>> simply fail. >> >> It's trivial NOW because its a closed set of possibilities.? And even >> then, you're assuming you don't have to detect ASN1 vs raw key encodings >> vs string encodings.? Simply detecting a) whether a file is character, >> b) detecting the character encoding, and c) accidentally thinking a >> character file is actually binary or vice versa is fragile. >> >> The addition of the "new" EC variant keys required a substantial >> reworking of the API to support them and the arguments were fierce.? The >> additions were not free. >> >> I deal with no fewer than 3 encodings for an EC public key.? Two or >> three for an EC private key. 2 or 3 text versions of a RSA public key >> along with the X509Encoded? binary version and the TPM binary version. >> Etc.? I usually know what type of key I'm dealing with when I get it, >> but I would love a magic DWIM class that did the right thing on all >> inputs. >> >> >>> >>>> >>>>> >>>>> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE >>>>> folks to give each new crypto system a separate namespace as an >>>>> alternative to overloading OKP (RFC 8037), even if the parameters >>>>> match technically.? AFAICT, X.509 public keys essentially already >>>>> adhere to this notion. >>>>> >>>>> I would exclude private key import and export in HSMs since these are >>>>> specific and rare occasions. >>>> >>>> Again, no.? Don't do this in an incomplete way - it will come back to >>>> bite you.? You don't have to implement the plugin that talks to the >>>> HSM, >>>> but you have to define the mechanism/API so that the HSM vendors don't >>>> curse your first born child later. >>> >>> >>> This is little bit out of my league but targeting the masses is core. >> >> This is the problem with open source some times. It may be core, but it >> is not complete and leaving this as a problem to be worked later is a >> bit unprofessional. >> >> I don't mean any offense here, but there's a problem with basing >> everything what IOT requires and ignoring everything else. >> >> Later, Mike >> >> >>> >>> >>> Anders >>> >>>> >>>> Mike >>>> >>>> >>>>> >>>>> WDYT? >>>>> >>>>> Thanx, >>>>> Anders >>>> >>>> >>> >> > From mstjohns at comcast.net Fri Mar 25 16:13:01 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 25 Mar 2022 12:13:01 -0400 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> Message-ID: On 3/25/2022 12:07 PM, Michael StJohns wrote: >> AFAIK, there is still no support for using named curves to construct >> an EC key. Names curves are MANDATORY in JOSE/CODE. > > Use AlgorithmParameterGenerator with ECGenParameterSpec.? Works like a > charm. Sorry - Got that slightly wrong.? Use this instead: > AlgorithmParameters parameters = AlgorithmParameters.getInstance("EC", > "SunEC"); parameters.init(newECGenParameterSpec > ("secp128r1")); > ECParameterSpec ecParameters = > parameters.getParameterSpec(ECParameterSpec.class); ECPublicKeySpec > pubKeySpec = newECPublicKeySpec(point, ecParameters); PublicKey key = > KeyFactory.getInstance("EC", "SunEC").generatePublic(pubKeySpec); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.java.net Fri Mar 25 16:21:52 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 16:21:52 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Given the large number of cleanups, I would have suggested to keep them separate from the change to re-focus the API on factories. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Fri Mar 25 16:21:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 16:21:52 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > src/java.base/share/classes/java/util/Locale.java line 245: > >> 243: *

    Factory Method

    >> 244: * >> 245: *

    The method {@link #forLanguageTag} obtains a {@code Locale} > > The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory. > Yes, it already exists and does what's required but you might get better uptake with a more natural name. > > Some alternatives: > - `Locale.of("en_US")` - short and conventional > - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories > - `Locale.forLanguage("en_US")` - natural but less conventional I was thinking of a *new* factory method, along the line with Stuart's suggestion, something like this: Locale.of(String... elements) where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or `(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot be null. These elements are *not* language tags, but conventional arguments to constructors, so it is compatible (and works as a stop-gap) to the old constructors. This way third parties will not have to deal with the boilerplate code mentioned above on migration. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From anders.rundgren.net at gmail.com Fri Mar 25 16:33:38 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 25 Mar 2022 17:33:38 +0100 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> Message-ID: <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> On 2022-03-25 17:12, Anthony Scarpino wrote: > When you say "construct and EC key", do you mean creating an EC key from > an existing set of values via PKCS8 or X509 encoding? Or are you > talking about EC key generation? I was talking about creating keys from parameter data supplied by for example JOSE: { "kty": "EC", "crv": "P-256", "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" } Apparently this particular issue have solution (as Michael StJohns showed), although it is not particularity intuitive as well as undocumented. Another take on this issue: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() "Returns the key in its primary encoding format, or null if this key does not support encoding" With COSE/JOSE there is no longer an obvious primary encoding format. Anders > > Tony > > On 3/25/22 1:03 AM, Anders Rundgren wrote: >> Hi Mike & the JDK crypto team, >> >> What I'm saying is that key serialization in Java haven't gotten enough >> attention.? Examples: >> >> AFAIK, there is still no support for using named curves to construct an >> EC key.? Names curves are MANDATORY in JOSE/CODE. >> >> The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is >> simply put GIGANTIC: >> https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html >> >> The only obvious solution is rolling your own: >> https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java >> >> This code [probably] stinks but it is hardly my fault... >> >> The JDK crypto team is the only party who can clean up this mess. >> >> Since importing X.509 certificates through PKCS12/KeyStore works out of >> the box without any a prior knowledge of key algorithms, there is >> already a precedent.? It is almost just copy and paste :) >> >> The new crypto systems that are on the way in (BLS, Post Quantum), >> accentuates this issue. >> >> Regarding HSMs, I gave it one more thought and I didn't come up with any >> connections except maybe in Keytool but HSMs appear to be X.509-oriented >> which not the case with COSE/JOSE. >> >> Regards, >> Anders >> >> On 2022-03-25 3:12, Michael StJohns wrote: >>> On 3/24/2022 12:28 PM, Anders Rundgren wrote: >>>> On 2022-03-24 16:59, Michael StJohns wrote: >>>>> On 3/24/2022 2:46 AM, Anders Rundgren wrote: >>>>>> Hi List, >>>>>> >>>>>> I find it a bit strange that every user of crypto either have to write >>>>>> or install specific software for converting JOSE/COSE/PEM keys >>>>>> back-and-forth to Java's internal representation. This reduces the >>>>>> value of the abstract types as well. >>>>>> >>>>>> Now there is whole bunch of new algorithms coming to the Java platform >>>>>> making this task even less attractive. >>>>>> >>>>>> So my question is simply: How about including this part in an enhanced >>>>>> JCE/JCA?? That is, making the encoder/decoder "pluggable" and hiding >>>>>> this complexity from users and library developers? >>>>> >>>>> Hi Anders - >>>> >>>> Hi Mike, >>>> >>>>> >>>>> Isn't that the exact purpose for KeyFactory and its plugins? >>>> >>>> They presume that you know not only the key algorithm but the >>>> associated parameters as well.? Why should users or library developers >>>> have to deal with that? >>> >>> Um - no.? They presume you know the key algorithm, but (using EC Public >>> keys for example), you can use either of the X509PublicKeySpec (to >>> decode an encoded key), or the ECPublicKeySpec (to deal with building a >>> key from scratch using the parameters.? You can notionally (haven't >>> tried it, but should work) use KeyFactory.getKeySpec() to convert >>> between the two formats or use Key.getEncoded() to get the default >>> encoding for the key. >>> >>> The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and >>> PKCS8EncodedKeySpec clases. >>> >>> PEM is actually not an encoding, but a wrapping of an encoding. The only >>> part of Java that deals with it natively (I believe) is the >>> CertificateFactory for X.509 certificates.? You may have an extra step >>> to add or remove a PEM style envelope (or the equivalent BASE64 bare >>> string), but that's reasonable. >>> >>>> >>>> The requirement to know key algorithm in advance forces you into ASN.1 >>>> decoding for dealing with PEMs.? Been there done that. >>> >>> Ah - not sure why you wouldn't know the key algorithm, BUT:? It should >>> theoretically be possible to write a KeyFactory provider that does that >>> decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and >>> returns an appropriate PublicKey. Check the actual return type to figure >>> out what type of key.? E.g.: >>> >>> KeyFactory kf = KeyFactory.getInstance("GenericDecoder"); >>> >>> As I said below, you'll need to define the equivalent opaque format >>> KeySpec classes to handle COSE and JOSE.? I think that's a class per >>> type of encoding. >>> >>>> >>>>> >>>>> You might need to add KeySpec types for Jose and Cose >>>>> (JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those >>>>> cover >>>>> all of the secret, public and private key specifications. >>>>> >>>>> Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or >>>>> GenericEncodedKeySpec (String alg, String encodedKey). >>>>> >>>>> >>>>>> >>>>>> Eventually you could end up with something like: >>>>>> >>>>>> PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or >>>>>> stream); >>>>>> >>>>>> You would not even have to know in which format the key is supplied in >>>>>> since this could be accomplished by simple "sniffing". >>>>> >>>>> Nope.? This isn't safe as someone might up with yet another >>>>> representation that looks like one of the "sniffable" ones.? You could >>>>> build a private implementation that takes its best shot, but .... >>>> >>>> Finding out if the container is COSE, JOSE, or PEM is (AFAICT) >>>> trivial.? If the guess is incorrect a properly designed decoder should >>>> simply fail. >>> >>> It's trivial NOW because its a closed set of possibilities.? And even >>> then, you're assuming you don't have to detect ASN1 vs raw key encodings >>> vs string encodings.? Simply detecting a) whether a file is character, >>> b) detecting the character encoding, and c) accidentally thinking a >>> character file is actually binary or vice versa is fragile. >>> >>> The addition of the "new" EC variant keys required a substantial >>> reworking of the API to support them and the arguments were fierce.? The >>> additions were not free. >>> >>> I deal with no fewer than 3 encodings for an EC public key.? Two or >>> three for an EC private key. 2 or 3 text versions of a RSA public key >>> along with the X509Encoded? binary version and the TPM binary version. >>> Etc.? I usually know what type of key I'm dealing with when I get it, >>> but I would love a magic DWIM class that did the right thing on all >>> inputs. >>> >>> >>>> >>>>> >>>>>> >>>>>> To make "pluggability" feasible, I'm trying to convince the JOSE/COSE >>>>>> folks to give each new crypto system a separate namespace as an >>>>>> alternative to overloading OKP (RFC 8037), even if the parameters >>>>>> match technically.? AFAICT, X.509 public keys essentially already >>>>>> adhere to this notion. >>>>>> >>>>>> I would exclude private key import and export in HSMs since these are >>>>>> specific and rare occasions. >>>>> >>>>> Again, no.? Don't do this in an incomplete way - it will come back to >>>>> bite you.? You don't have to implement the plugin that talks to the >>>>> HSM, >>>>> but you have to define the mechanism/API so that the HSM vendors don't >>>>> curse your first born child later. >>>> >>>> >>>> This is little bit out of my league but targeting the masses is core. >>> >>> This is the problem with open source some times. It may be core, but it >>> is not complete and leaving this as a problem to be worked later is a >>> bit unprofessional. >>> >>> I don't mean any offense here, but there's a problem with basing >>> everything what IOT requires and ignoring everything else. >>> >>> Later, Mike >>> >>> >>>> >>>> >>>> Anders >>>> >>>>> >>>>> Mike >>>>> >>>>> >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanx, >>>>>> Anders >>>>> >>>>> >>>> >>> >> From valeriep at openjdk.java.net Fri Mar 25 17:15:46 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 25 Mar 2022 17:15:46 GMT Subject: Integrated: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 In-Reply-To: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> References: <1goCY5Ul1kkZZH37YfCLhjnj0GSDPGHBpwo5M0WnULk=.96bd15c9-aebd-4b52-8eb6-7faed519554a@github.com> Message-ID: On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie This pull request has now been integrated. Changeset: 3b5dfee9 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/3b5dfee939dda02e14498baa2b52b0150326b938 Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod 8283665: Two Jarsigner tests needs to be updated with JDK-8267319 Reviewed-by: xuelei, ascarpino, hchao, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/7952 From mstjohns at comcast.net Fri Mar 25 17:23:46 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 25 Mar 2022 13:23:46 -0400 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> Message-ID: <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> On 3/25/2022 12:33 PM, Anders Rundgren wrote: > On 2022-03-25 17:12, Anthony Scarpino wrote: >> When you say "construct and EC key", do you mean creating an EC key from >> an existing set of values via PKCS8 or X509 encoding?? Or are you >> talking about EC key generation? > > I was talking about creating keys from parameter data supplied by for > example JOSE: > ? { > ??? "kty": "EC", > ??? "crv": "P-256", > ??? "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", > ??? "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" > ? } > > Apparently this particular issue have solution (as Michael StJohns > showed), although it is not particularity intuitive as well as > undocumented. > > Another take on this issue: > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() > > "Returns the key in its primary encoding format, or null if this key > does not support encoding" > > With COSE/JOSE there is no longer an obvious primary encoding format. Of course there is.? You may not like that it's not COSE or JOSE, but the encoding spec remains as is and 10s of 1000s of implementations that use that encoding would be annoyed if you tried to claim a new "primary encoding format". The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for private keys, and RAW encoding for SecretKeys is what's there and I'm pretty sure won't change.? I occasionally wished for a getEncoded() method that took an encoding type as an argument (e.g. getEncoded("bareXY") or some such), but that's not in the API. What I'd suggest is that you write a JEP for adding EncodedKeySpec classes for COSE and JOSE to the API.?? I'd probably also add a GenericKeyEncodingSpec class.? That should be simple enough as a first step. The second step would be to write and contribute a Jose and Cose KeyFactory implementation that uses those classes. As I noted, it should be possible to externalize any preferred encoding by using the getKeySpec method of KeyFactory rather than just the key types default encoding. Later, Mike > > Anders > >> >> Tony From anders.rundgren.net at gmail.com Fri Mar 25 17:46:14 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 25 Mar 2022 18:46:14 +0100 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> Message-ID: <68b51ded-ee87-2fb5-1884-8d25dea2821e@gmail.com> Hi Michael & the JDK crypto team, Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. I'm not in favor of this idea since breaks existing OKP code. I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. It seems that nobody representing JDK crypto is involved in COSE/JOSE. Thanx, Anders On 2022-03-25 18:23, Michael StJohns wrote: > On 3/25/2022 12:33 PM, Anders Rundgren wrote: >> On 2022-03-25 17:12, Anthony Scarpino wrote: >>> When you say "construct and EC key", do you mean creating an EC key from >>> an existing set of values via PKCS8 or X509 encoding?? Or are you >>> talking about EC key generation? >> >> I was talking about creating keys from parameter data supplied by for >> example JOSE: >> ? { >> ??? "kty": "EC", >> ??? "crv": "P-256", >> ??? "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >> ??? "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >> ? } >> >> Apparently this particular issue have solution (as Michael StJohns >> showed), although it is not particularity intuitive as well as >> undocumented. >> >> Another take on this issue: >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >> >> "Returns the key in its primary encoding format, or null if this key >> does not support encoding" >> >> With COSE/JOSE there is no longer an obvious primary encoding format. > > Of course there is.? You may not like that it's not COSE or JOSE, but > the encoding spec remains as is and 10s of 1000s of implementations that > use that encoding would be annoyed if you tried to claim a new "primary > encoding format". > > The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for > private keys, and RAW encoding for SecretKeys is what's there and I'm > pretty sure won't change.? I occasionally wished for a getEncoded() > method that took an encoding type as an argument (e.g. > getEncoded("bareXY") or some such), but that's not in the API. > > What I'd suggest is that you write a JEP for adding EncodedKeySpec > classes for COSE and JOSE to the API.?? I'd probably also add a > GenericKeyEncodingSpec class.? That should be simple enough as a first step. > > The second step would be to write and contribute a Jose and Cose > KeyFactory implementation that uses those classes. > > As I noted, it should be possible to externalize any preferred encoding > by using the getKeySpec method of KeyFactory rather than just the key > types default encoding. > > Later, Mike > > >> >> Anders >> >>> >>> Tony > From hchao at openjdk.java.net Fri Mar 25 18:18:44 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 25 Mar 2022 18:18:44 GMT Subject: RFR: 8283691: Classes in java.security still reference deprecated classes in spec In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7961 From mullan at openjdk.java.net Fri Mar 25 18:27:42 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 25 Mar 2022 18:27:42 GMT Subject: RFR: 8283691: Classes in java.security still reference deprecated classes in spec In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7961 From anders.rundgren.net at gmail.com Fri Mar 25 18:56:52 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 25 Mar 2022 19:56:52 +0100 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> Message-ID: Hi Michael & the JDK crypto team, Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. I'm not in favor of this idea since breaks existing OKP code. I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. It seems that nobody representing JDK crypto is involved in COSE/JOSE. Thanx, Anders On 2022-03-25 18:23, Michael StJohns wrote: > On 3/25/2022 12:33 PM, Anders Rundgren wrote: >> On 2022-03-25 17:12, Anthony Scarpino wrote: >>> When you say "construct and EC key", do you mean creating an EC key from >>> an existing set of values via PKCS8 or X509 encoding?? Or are you >>> talking about EC key generation? >> >> I was talking about creating keys from parameter data supplied by for >> example JOSE: >> ? { >> ??? "kty": "EC", >> ??? "crv": "P-256", >> ??? "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >> ??? "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >> ? } >> >> Apparently this particular issue have solution (as Michael StJohns >> showed), although it is not particularity intuitive as well as >> undocumented. >> >> Another take on this issue: >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >> >> "Returns the key in its primary encoding format, or null if this key >> does not support encoding" >> >> With COSE/JOSE there is no longer an obvious primary encoding format. > > Of course there is.? You may not like that it's not COSE or JOSE, but > the encoding spec remains as is and 10s of 1000s of implementations that > use that encoding would be annoyed if you tried to claim a new "primary > encoding format". > > The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for > private keys, and RAW encoding for SecretKeys is what's there and I'm > pretty sure won't change.? I occasionally wished for a getEncoded() > method that took an encoding type as an argument (e.g. > getEncoded("bareXY") or some such), but that's not in the API. > > What I'd suggest is that you write a JEP for adding EncodedKeySpec > classes for COSE and JOSE to the API.?? I'd probably also add a > GenericKeyEncodingSpec class.? That should be simple enough as a first step. > > The second step would be to write and contribute a Jose and Cose > KeyFactory implementation that uses those classes. > > As I noted, it should be possible to externalize any preferred encoding > by using the getKeySpec method of KeyFactory rather than just the key > types default encoding. > > Later, Mike > > >> >> Anders >> >>> >>> Tony > From aturbanov at openjdk.java.net Fri Mar 25 20:23:08 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 25 Mar 2022 20:23:08 GMT Subject: RFR: 8283711: Remove redundant 'new String' calls after concatenation Message-ID: Result of string concatenation is a newly created String object. There is no need it wrap it in another 'new String' call. Such calls are confusing and produce warnings in IDE. Without them code is easier to read. Similar cleanup [JDK-8273375](https://bugs.openjdk.java.net/browse/JDK-8273375) in java.desktop ------------- Commit messages: - [PATCH] Remove redundant 'new String' calls after concatenation - [PATCH] Remove redundant 'new String' calls after concatenation Changes: https://git.openjdk.java.net/jdk/pull/7876/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7876&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283711 Stats: 13 lines in 3 files changed: 0 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7876/head:pull/7876 PR: https://git.openjdk.java.net/jdk/pull/7876 From wetmore at openjdk.java.net Fri Mar 25 20:44:39 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 25 Mar 2022 20:44:39 GMT Subject: RFR: 8283691: Classes in java.security still reference deprecated classes in spec In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7961 From wetmore at openjdk.java.net Fri Mar 25 20:49:53 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 25 Mar 2022 20:49:53 GMT Subject: RFR: 8283711: Remove redundant 'new String' calls after concatenation In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:07:52 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created String object. There is no need it wrap it in another 'new String' call. > Such calls are confusing and produce warnings in IDE. Without them code is easier to read. > Similar cleanup [JDK-8273375](https://bugs.openjdk.java.net/browse/JDK-8273375) in java.desktop LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7876 From vromero at openjdk.java.net Fri Mar 25 20:49:53 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Mar 2022 20:49:53 GMT Subject: RFR: 8283711: Remove redundant 'new String' calls after concatenation In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:07:52 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created String object. There is no need it wrap it in another 'new String' call. > Such calls are confusing and produce warnings in IDE. Without them code is easier to read. > Similar cleanup [JDK-8273375](https://bugs.openjdk.java.net/browse/JDK-8273375) in java.desktop the compiler changes looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7876 From weijun at openjdk.java.net Fri Mar 25 21:24:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Mar 2022 21:24:46 GMT Subject: Integrated: 8283691: Classes in java.security still reference deprecated classes in spec In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. This pull request has now been integrated. Changeset: e97cf157 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/e97cf157cf20aeaef4a8c16fed6f3bb2bc933819 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod 8283691: Classes in java.security still reference deprecated classes in spec Reviewed-by: hchao, mullan, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/7961 From valeriep at openjdk.java.net Fri Mar 25 21:37:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 25 Mar 2022 21:37:43 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 01:33:12 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> More minor edits. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 78: > >> 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these >> 77: * values are really what you want to use. >> 78: * > > I just read the whole class spec. Since the default values are already included on lines 38-41, I think there is no need to use so much words and we can just say "defined above". I am not sure if everyone reads the complete spec from class to fields and methods. Which part do you want to remove and just use "defined above"? Personally, I find "above" kind of vague... It's better to keep the comment near the field. Perhaps we should trim the class spec instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From weijun at openjdk.java.net Fri Mar 25 21:52:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Mar 2022 21:52:48 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 21:34:28 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 78: >> >>> 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these >>> 77: * values are really what you want to use. >>> 78: * >> >> I just read the whole class spec. Since the default values are already included on lines 38-41, I think there is no need to use so much words and we can just say "defined above". > > I am not sure if everyone reads the complete spec from class to fields and methods. Which part do you want to remove and just use "defined above"? Personally, I find "above" kind of vague... It's better to keep the comment near the field. Perhaps we should trim the class spec instead? Almost the whole class spec is copied from PKCS #1 but at the end you have "defined in the ASN.1 encoding from the PKCS#1 standard", which might make people wonder if it is something else. If you don't want to remove anything, how about "defined in the ASN.1 encoding from the PKCS#1 standard above". It's verbose but not confusing. BTW, on https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/spec/PSSParameterSpec.html, the whole "Note" is shown on one line. I guess that's not intended. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Sat Mar 26 00:30:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 26 Mar 2022 00:30:43 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 21:49:07 GMT, Weijun Wang wrote: >> I am not sure if everyone reads the complete spec from class to fields and methods. Which part do you want to remove and just use "defined above"? Personally, I find "above" kind of vague... It's better to keep the comment near the field. Perhaps we should trim the class spec instead? > > Almost the whole class spec is copied from PKCS #1 but at the end you have "defined in the ASN.1 encoding from the PKCS#1 standard", which might make people wonder if it is something else. If you don't want to remove anything, how about "defined in the ASN.1 encoding from the PKCS#1 standard above". It's verbose but not confusing. > > BTW, on https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/spec/PSSParameterSpec.html, the whole "Note" is shown on one line. I guess that's not intended. Ah, Ok, I think I see what you are saying now. I agree about trimming the class spec. Are you ok with removing line 67-77 (proposed/new version)? This would reduce the duplication of wordings. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From weijun at openjdk.java.net Sat Mar 26 02:14:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 26 Mar 2022 02:14:45 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Sat, 26 Mar 2022 00:27:19 GMT, Valerie Peng wrote: >> Almost the whole class spec is copied from PKCS #1 but at the end you have "defined in the ASN.1 encoding from the PKCS#1 standard", which might make people wonder if it is something else. If you don't want to remove anything, how about "defined in the ASN.1 encoding from the PKCS#1 standard above". It's verbose but not confusing. >> >> BTW, on https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/spec/PSSParameterSpec.html, the whole "Note" is shown on one line. I guess that's not intended. > > Ah, Ok, I think I see what you are saying now. I agree about trimming the class spec. Are you ok with removing line 67-77 (proposed/new version)? This would reduce the duplication of wordings. Good suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From xuelei at openjdk.java.net Sat Mar 26 14:54:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 26 Mar 2022 14:54:46 GMT Subject: RFR: 8283711: Remove redundant 'new String' calls after concatenation In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:07:52 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created String object. There is no need it wrap it in another 'new String' call. > Such calls are confusing and produce warnings in IDE. Without them code is easier to read. > Similar cleanup [JDK-8273375](https://bugs.openjdk.java.net/browse/JDK-8273375) in java.desktop Good catches! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7876 From xueleifan at tencent.com Sat Mar 26 15:05:14 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Sat, 26 Mar 2022 15:05:14 +0000 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> Message-ID: <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> Hi Anders, I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? Thanks, Xuelei > On Mar 25, 2022, at 11:56 AM, Anders Rundgren wrote: > > Hi Michael & the JDK crypto team, > > Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. > > BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. > I'm not in favor of this idea since breaks existing OKP code. > I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. > > Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. > > It seems that nobody representing JDK crypto is involved in COSE/JOSE. > > Thanx, > Anders > > > On 2022-03-25 18:23, Michael StJohns wrote: >> On 3/25/2022 12:33 PM, Anders Rundgren wrote: >>> On 2022-03-25 17:12, Anthony Scarpino wrote: >>>> When you say "construct and EC key", do you mean creating an EC key from >>>> an existing set of values via PKCS8 or X509 encoding? Or are you >>>> talking about EC key generation? >>> >>> I was talking about creating keys from parameter data supplied by for >>> example JOSE: >>> { >>> "kty": "EC", >>> "crv": "P-256", >>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >>> } >>> >>> Apparently this particular issue have solution (as Michael StJohns >>> showed), although it is not particularity intuitive as well as >>> undocumented. >>> >>> Another take on this issue: >>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >>> >>> "Returns the key in its primary encoding format, or null if this key >>> does not support encoding" >>> >>> With COSE/JOSE there is no longer an obvious primary encoding format. >> Of course there is. You may not like that it's not COSE or JOSE, but >> the encoding spec remains as is and 10s of 1000s of implementations that >> use that encoding would be annoyed if you tried to claim a new "primary >> encoding format". >> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for >> private keys, and RAW encoding for SecretKeys is what's there and I'm >> pretty sure won't change. I occasionally wished for a getEncoded() >> method that took an encoding type as an argument (e.g. >> getEncoded("bareXY") or some such), but that's not in the API. >> What I'd suggest is that you write a JEP for adding EncodedKeySpec >> classes for COSE and JOSE to the API. I'd probably also add a >> GenericKeyEncodingSpec class. That should be simple enough as a first step. >> The second step would be to write and contribute a Jose and Cose >> KeyFactory implementation that uses those classes. >> As I noted, it should be possible to externalize any preferred encoding >> by using the getKeySpec method of KeyFactory rather than just the key >> types default encoding. >> Later, Mike >>> >>> Anders >>> >>>> >>>> Tony > > From anders.rundgren.net at gmail.com Sat Mar 26 15:41:35 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sat, 26 Mar 2022 16:41:35 +0100 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> Message-ID: <65a547d4-f1dd-5a62-f036-08c4bcc2d724@gmail.com> On 2022-03-26 16:05, xueleifan(XueleiFan) wrote: > Hi Anders, > > I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? Hi Xuelei, The core JOSE RFCs should be Signatures: https://www.rfc-editor.org/rfc/rfc7515.html Encryption: https://www.rfc-editor.org/rfc/rfc7516.html Algorithms: https://www.rfc-editor.org/rfc/rfc7518.html Ed*,X* support https://www.rfc-editor.org/rfc/rfc8037.html COSE: https://www.rfc-editor.org/rfc/rfc8152.html JOSE is a very wide-spread standard. It is for example a part of OAuth used by for example most social media platforms as well as GitHub. It is nowadays de-facto the replacement for XML Dsig. COSE has a more narrow set of applications but with a huge volume like IoT. It is also a part of FIDO which is how I came in contact with COSE. We will eventually all use FIDO. If there is anything you want to ask, just send me an e-mail, anytime. I'm not a cryptographer but a user of crypto which is why I'm a little bit "obsessed" with the high level APIs :) Regards, Anders > > Thanks, > Xuelei > >> On Mar 25, 2022, at 11:56 AM, Anders Rundgren wrote: >> >> Hi Michael & the JDK crypto team, >> >> Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. >> >> BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. >> I'm not in favor of this idea since breaks existing OKP code. >> I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. >> >> Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. >> >> It seems that nobody representing JDK crypto is involved in COSE/JOSE. >> >> Thanx, >> Anders >> >> >> On 2022-03-25 18:23, Michael StJohns wrote: >>> On 3/25/2022 12:33 PM, Anders Rundgren wrote: >>>> On 2022-03-25 17:12, Anthony Scarpino wrote: >>>>> When you say "construct and EC key", do you mean creating an EC key from >>>>> an existing set of values via PKCS8 or X509 encoding? Or are you >>>>> talking about EC key generation? >>>> >>>> I was talking about creating keys from parameter data supplied by for >>>> example JOSE: >>>> { >>>> "kty": "EC", >>>> "crv": "P-256", >>>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >>>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >>>> } >>>> >>>> Apparently this particular issue have solution (as Michael StJohns >>>> showed), although it is not particularity intuitive as well as >>>> undocumented. >>>> >>>> Another take on this issue: >>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >>>> >>>> "Returns the key in its primary encoding format, or null if this key >>>> does not support encoding" >>>> >>>> With COSE/JOSE there is no longer an obvious primary encoding format. >>> Of course there is. You may not like that it's not COSE or JOSE, but >>> the encoding spec remains as is and 10s of 1000s of implementations that >>> use that encoding would be annoyed if you tried to claim a new "primary >>> encoding format". >>> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for >>> private keys, and RAW encoding for SecretKeys is what's there and I'm >>> pretty sure won't change. I occasionally wished for a getEncoded() >>> method that took an encoding type as an argument (e.g. >>> getEncoded("bareXY") or some such), but that's not in the API. >>> What I'd suggest is that you write a JEP for adding EncodedKeySpec >>> classes for COSE and JOSE to the API. I'd probably also add a >>> GenericKeyEncodingSpec class. That should be simple enough as a first step. >>> The second step would be to write and contribute a Jose and Cose >>> KeyFactory implementation that uses those classes. >>> As I noted, it should be possible to externalize any preferred encoding >>> by using the getKeySpec method of KeyFactory rather than just the key >>> types default encoding. >>> Later, Mike >>>> >>>> Anders >>>> >>>>> >>>>> Tony >> >> > From duke at openjdk.java.net Sat Mar 26 16:38:41 2022 From: duke at openjdk.java.net (liach) Date: Sat, 26 Mar 2022 16:38:41 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com> On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Sat Mar 26 19:27:40 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sat, 26 Mar 2022 19:27:40 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType There were changes with `Set.of()`, but I've reverted them as dubious. I'll rename the ticket and PR's title. As of the second question I didn't look namely for `Collections.addAll(set, elements)`, if I find any feasible for replacement with `Set.of()` then I'll add it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From mstjohns at comcast.net Sat Mar 26 21:27:23 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 26 Mar 2022 17:27:23 -0400 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> Message-ID: <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> On 3/26/2022 11:05 AM, xueleifan(XueleiFan) wrote: > Hi Anders, > > I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? > > Thanks, > Xuelei Hi Xuelei - Just for clarification - JOSE/COSE are data description languages? with specific provisions for encoding various type of cryptographic key material.? E.g. think ASN1 ~= JOSE or COSE and the RFC's that Anders is pointing you at as approximately equal to PKCS8 and X.509 plus the key type specific stuff (e.g. PKCS1 for RSA key encodings, X9.63 for EC key encodings, later IETF RFCs for newer encodings). This isn't about math so much as it is about encodings. Mike > >> On Mar 25, 2022, at 11:56 AM, Anders Rundgren wrote: >> >> Hi Michael & the JDK crypto team, >> >> Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. >> >> BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. >> I'm not in favor of this idea since breaks existing OKP code. >> I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. >> >> Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. >> >> It seems that nobody representing JDK crypto is involved in COSE/JOSE. >> >> Thanx, >> Anders >> >> >> On 2022-03-25 18:23, Michael StJohns wrote: >>> On 3/25/2022 12:33 PM, Anders Rundgren wrote: >>>> On 2022-03-25 17:12, Anthony Scarpino wrote: >>>>> When you say "construct and EC key", do you mean creating an EC key from >>>>> an existing set of values via PKCS8 or X509 encoding? Or are you >>>>> talking about EC key generation? >>>> I was talking about creating keys from parameter data supplied by for >>>> example JOSE: >>>> { >>>> "kty": "EC", >>>> "crv": "P-256", >>>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >>>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >>>> } >>>> >>>> Apparently this particular issue have solution (as Michael StJohns >>>> showed), although it is not particularity intuitive as well as >>>> undocumented. >>>> >>>> Another take on this issue: >>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >>>> >>>> "Returns the key in its primary encoding format, or null if this key >>>> does not support encoding" >>>> >>>> With COSE/JOSE there is no longer an obvious primary encoding format. >>> Of course there is. You may not like that it's not COSE or JOSE, but >>> the encoding spec remains as is and 10s of 1000s of implementations that >>> use that encoding would be annoyed if you tried to claim a new "primary >>> encoding format". >>> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for >>> private keys, and RAW encoding for SecretKeys is what's there and I'm >>> pretty sure won't change. I occasionally wished for a getEncoded() >>> method that took an encoding type as an argument (e.g. >>> getEncoded("bareXY") or some such), but that's not in the API. >>> What I'd suggest is that you write a JEP for adding EncodedKeySpec >>> classes for COSE and JOSE to the API. I'd probably also add a >>> GenericKeyEncodingSpec class. That should be simple enough as a first step. >>> The second step would be to write and contribute a Jose and Cose >>> KeyFactory implementation that uses those classes. >>> As I noted, it should be possible to externalize any preferred encoding >>> by using the getKeySpec method of KeyFactory rather than just the key >>> types default encoding. >>> Later, Mike >>>> Anders >>>> >>>>> Tony >> From ecki at zusammenkunft.net Sat Mar 26 22:14:52 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 26 Mar 2022 22:14:52 +0000 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> Message-ID: Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Michael StJohns Gesendet: Samstag, M?rz 26, 2022 10:29 PM An: security-dev at openjdk.java.net Betreff: Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA On 3/26/2022 11:05 AM, xueleifan(XueleiFan) wrote: > Hi Anders, > > I would like to have look at the COSE/JOSE specs. If it is convenient to you, any suggestions about where I could start from? RFC 8812? Do you know where (areas and products) the COSE/JOSE specs are used in practice? > > Thanks, > Xuelei Hi Xuelei - Just for clarification - JOSE/COSE are data description languages with specific provisions for encoding various type of cryptographic key material. E.g. think ASN1 ~= JOSE or COSE and the RFC's that Anders is pointing you at as approximately equal to PKCS8 and X.509 plus the key type specific stuff (e.g. PKCS1 for RSA key encodings, X9.63 for EC key encodings, later IETF RFCs for newer encodings). This isn't about math so much as it is about encodings. Mike > >> On Mar 25, 2022, at 11:56 AM, Anders Rundgren wrote: >> >> Hi Michael & the JDK crypto team, >> >> Although it might be cool writing a JEP it is not really my job. There are also multiple ways of addressing this issue. >> >> BTW, the COSE/JOSE folks who are about to introduce new algorithms want to overload RFC 8037 which defines a key type OKP. >> I'm not in favor of this idea since breaks existing OKP code. >> I'm suggesting that each new crypto system should get its own name space and thus long-term corresponding Java interfaces. >> >> Since this is happening NOW and there is no turning back, it would be useful to get some early feedback from the JDK folks. In fact, this is the origin of this request. >> >> It seems that nobody representing JDK crypto is involved in COSE/JOSE. >> >> Thanx, >> Anders >> >> >> On 2022-03-25 18:23, Michael StJohns wrote: >>> On 3/25/2022 12:33 PM, Anders Rundgren wrote: >>>> On 2022-03-25 17:12, Anthony Scarpino wrote: >>>>> When you say "construct and EC key", do you mean creating an EC key from >>>>> an existing set of values via PKCS8 or X509 encoding? Or are you >>>>> talking about EC key generation? >>>> I was talking about creating keys from parameter data supplied by for >>>> example JOSE: >>>> { >>>> "kty": "EC", >>>> "crv": "P-256", >>>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU", >>>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg" >>>> } >>>> >>>> Apparently this particular issue have solution (as Michael StJohns >>>> showed), although it is not particularity intuitive as well as >>>> undocumented. >>>> >>>> Another take on this issue: >>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded() >>>> >>>> "Returns the key in its primary encoding format, or null if this key >>>> does not support encoding" >>>> >>>> With COSE/JOSE there is no longer an obvious primary encoding format. >>> Of course there is. You may not like that it's not COSE or JOSE, but >>> the encoding spec remains as is and 10s of 1000s of implementations that >>> use that encoding would be annoyed if you tried to claim a new "primary >>> encoding format". >>> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for >>> private keys, and RAW encoding for SecretKeys is what's there and I'm >>> pretty sure won't change. I occasionally wished for a getEncoded() >>> method that took an encoding type as an argument (e.g. >>> getEncoded("bareXY") or some such), but that's not in the API. >>> What I'd suggest is that you write a JEP for adding EncodedKeySpec >>> classes for COSE and JOSE to the API. I'd probably also add a >>> GenericKeyEncodingSpec class. That should be simple enough as a first step. >>> The second step would be to write and contribute a Jose and Cose >>> KeyFactory implementation that uses those classes. >>> As I noted, it should be possible to externalize any preferred encoding >>> by using the getKeySpec method of KeyFactory rather than just the key >>> types default encoding. >>> Later, Mike >>>> Anders >>>> >>>>> Tony >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.rundgren.net at gmail.com Sun Mar 27 06:47:54 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sun, 27 Mar 2022 08:47:54 +0200 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> Message-ID: <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> On 2022-03-26 23:14, Bernd Eckenfels wrote: > Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). > > In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. > > BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. > Thanx Bernd and Michael for the additional clarifications! Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037 This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set. This is now an active proposal: https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading"). To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces. IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs. I'm therefore suggesting that key containers for specific crypto systems should have unique names. In this particular case "BLS" seems logical. In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey. WDYT? There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon. The same discussion has emerged for Post Quantum Crypto algorithms. Thanx, Anders From clanger at openjdk.java.net Sun Mar 27 08:55:11 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Sun, 27 Mar 2022 08:55:11 GMT Subject: RFR: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319 Message-ID: <7OV9yFIJN-rK37sCt6N0TlLQ4uLHWbAuzvTi9b_RS70=.6c0a6a0f-ee0e-4405-8397-e944d201bef9@github.com> Remove double semicolon ------------- Commit messages: - JDK-8283727 Changes: https://git.openjdk.java.net/jdk/pull/7976/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7976&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283727 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7976/head:pull/7976 PR: https://git.openjdk.java.net/jdk/pull/7976 From mullan at openjdk.java.net Sun Mar 27 13:10:40 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Sun, 27 Mar 2022 13:10:40 GMT Subject: RFR: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319 In-Reply-To: <7OV9yFIJN-rK37sCt6N0TlLQ4uLHWbAuzvTi9b_RS70=.6c0a6a0f-ee0e-4405-8397-e944d201bef9@github.com> References: <7OV9yFIJN-rK37sCt6N0TlLQ4uLHWbAuzvTi9b_RS70=.6c0a6a0f-ee0e-4405-8397-e944d201bef9@github.com> Message-ID: <0ER9Fl20PTNai9zDBKHEdWM3rbn3mL5itZO_97DIL5o=.90c35b22-fa76-4347-871c-3d089e4612c7@github.com> On Sun, 27 Mar 2022 08:48:12 GMT, Christoph Langer wrote: > Remove double semicolon Marked as reviewed by mullan (Reviewer). Regarding the bug, the `noreg-self` label is used for fixes to tests. `noreg-trivial` seems more appropriate for this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7976 From rick.hillegas at gmail.com Sun Mar 27 13:45:34 2022 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Sun, 27 Mar 2022 06:45:34 -0700 Subject: protecting security-sensitive operations on multi-tenant servers In-Reply-To: <3a162d52-7566-4af5-0a4f-56754a660b30@gmail.com> References: <3a162d52-7566-4af5-0a4f-56754a660b30@gmail.com> Message-ID: From the silence, I assume that there isn't any advice I can give Derby users. At this time the Security Manager is the only mechanism for protecting an application against these threats. Users should ignore the deprecation diagnostics and set -Djava.security.manager=allow. On 3/24/22 2:27 PM, Rick Hillegas wrote: > The Apache Derby community is getting ready to vet a new release which > can be used on Java 17. Before buttoning down the release, I wanted to > check in on current best practices for defending enterprise > applications against the threats which the Java Security Manager > parries. There may be some work we could do to better prepare our > users for a future without a Security Manager. > > In particular, what are current best Java practices for protecting a > multi-tenant server against abuse of the following security-sensitive > operations: > > o Reading and setting of system properties. > > o Creation of class loaders. > > o File access > > o Network access > > o De-registration of JDBC drivers > > Thanks, > -Rick > From Alan.Bateman at oracle.com Sun Mar 27 14:22:46 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Mar 2022 15:22:46 +0100 Subject: protecting security-sensitive operations on multi-tenant servers In-Reply-To: References: <3a162d52-7566-4af5-0a4f-56754a660b30@gmail.com> Message-ID: <8937b43a-103d-c3d6-63a9-dba061a82048@oracle.com> On 27/03/2022 14:45, Rick Hillegas wrote: > From the silence, I assume that there isn't any advice I can give > Derby users. At this time the Security Manager is the only mechanism > for protecting an application against these threats. Users should > ignore the deprecation diagnostics and set -Djava.security.manager=allow. > I think it's more that the SM was never the right solution for this type of isolation. Also some of the "operations" that you list, creating class loaders, de-registering JDBC drivers, ... suggest there may be potentially malicious code in these environments too. Do you know if these are legacy deployments or Derby users that haven't explored OS containers to isolate applications on the same hardware? -Alan From clanger at openjdk.java.net Sun Mar 27 14:34:42 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Sun, 27 Mar 2022 14:34:42 GMT Subject: RFR: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319 In-Reply-To: <0ER9Fl20PTNai9zDBKHEdWM3rbn3mL5itZO_97DIL5o=.90c35b22-fa76-4347-871c-3d089e4612c7@github.com> References: <7OV9yFIJN-rK37sCt6N0TlLQ4uLHWbAuzvTi9b_RS70=.6c0a6a0f-ee0e-4405-8397-e944d201bef9@github.com> <0ER9Fl20PTNai9zDBKHEdWM3rbn3mL5itZO_97DIL5o=.90c35b22-fa76-4347-871c-3d089e4612c7@github.com> Message-ID: On Sun, 27 Mar 2022 13:07:54 GMT, Sean Mullan wrote: > Regarding the bug, the `noreg-self` label is used for fixes to tests. `noreg-trivial` seems more appropriate for this issue. You're right, I changed this. Thanks also for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7976 From rick.hillegas at gmail.com Sun Mar 27 17:51:47 2022 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Sun, 27 Mar 2022 10:51:47 -0700 Subject: protecting security-sensitive operations on multi-tenant servers In-Reply-To: <8937b43a-103d-c3d6-63a9-dba061a82048@oracle.com> References: <3a162d52-7566-4af5-0a4f-56754a660b30@gmail.com> <8937b43a-103d-c3d6-63a9-dba061a82048@oracle.com> Message-ID: <69ae791e-74c7-0fbb-8a88-218b04c7a5db@gmail.com> Thanks, Alan. I don't have a lot of visibility into how Derby's security mechanisms are deployed. We only hear from users when they have problems--and we don't field many security-related issues. I will put your advice into our release notes: move your application into a container so that you will be protected when the Security Manager is removed. Thanks, -Rick On 3/27/22 7:22 AM, Alan Bateman wrote: > > > On 27/03/2022 14:45, Rick Hillegas wrote: >> From the silence, I assume that there isn't any advice I can give >> Derby users. At this time the Security Manager is the only mechanism >> for protecting an application against these threats. Users should >> ignore the deprecation diagnostics and set >> -Djava.security.manager=allow. >> > I think it's more that the SM was never the right solution for this > type of isolation. Also some of the "operations" that you list, > creating class loaders, de-registering JDBC drivers, ... suggest there > may be potentially malicious code in these environments too. Do you > know if these are legacy deployments or Derby users that haven't > explored OS containers to isolate applications on the same hardware? > > -Alan From anthony.scarpino at oracle.com Mon Mar 28 04:31:29 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 28 Mar 2022 04:31:29 +0000 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> Message-ID: <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> Thanks for all the info. We don?t have experience with JOSE or COSE, I think we need to digest some of this data before making a future step Not knowing this technology until you brought it up a few days ago, a few questions i have are how is this used and how common? Would I see this used for more secure sites like banks or shopping through the browser or it more common sites. Is it only browser-based or are their other used cases? Bernd mentioned QR codes, is COSE used inside the QR code or the authentication for the user to get to their QR code? Thanks Tony > On Mar 26, 2022, at 11:48 PM, Anders Rundgren wrote: > > ?On 2022-03-26 23:14, Bernd Eckenfels wrote: >> Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). >> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. >> BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. > > Thanx Bernd and Michael for the additional clarifications! > > Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037 > > This document defines how to use the Diffie-Hellman algorithms > "X25519" and "X448" as well as the signature algorithms "Ed25519" and > "Ed448" from the IRTF CFRG elliptic curves work in JSON Object > Signing and Encryption (JOSE). > > When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set. This is now an active proposal: > https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html > > Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading"). To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces. > > IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs. I'm therefore suggesting that key containers for specific crypto systems should have unique names. In this particular case "BLS" seems logical. In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey. > > WDYT? > > There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon. The same discussion has emerged for Post Quantum Crypto algorithms. > > Thanx, > Anders From ssahoo at openjdk.java.net Mon Mar 28 07:02:23 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Mon, 28 Mar 2022 07:02:23 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule [v2] In-Reply-To: References: Message-ID: > Added coverage to logout method. Sibabrata Sahoo has updated the pull request incrementally with two additional commits since the last revision: - Update AllPlatforms.java - Update AllPlatforms.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7940/files - new: https://git.openjdk.java.net/jdk/pull/7940/files/7c43e30f..13a999b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7940&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7940&range=00-01 Stats: 31 lines in 1 file changed: 2 ins; 17 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7940/head:pull/7940 PR: https://git.openjdk.java.net/jdk/pull/7940 From ssahoo at openjdk.java.net Mon Mar 28 07:02:27 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Mon, 28 Mar 2022 07:02:27 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 23:02:47 GMT, Rajan Halade wrote: >> Sibabrata Sahoo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update AllPlatforms.java >> - Update AllPlatforms.java > > test/jdk/com/sun/security/auth/module/AllPlatforms.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 8039951 8281717 > > No need to add bug id here as this is not a product change. Done. > test/jdk/com/sun/security/auth/module/AllPlatforms.java line 44: > >> 42: try { >> 43: login("windows", "NTLoginModule", "required"); >> 44: login("unix", "UnixLoginModule", "required"); > > thanks for fixing this code. Test earlier skipped UnixLoginModule early on "nix" platform as windows login would fail. It will run on all platform even the unsuccessful ones appear before. > test/jdk/com/sun/security/auth/module/AllPlatforms.java line 45: > >> 43: UNIX_MODULE, "optional", >> 44: NT_MODULE, "optional"); >> 45: login(OS.replaceAll("[^a-zA-Z0-9]", ""), getPlatformLoginModule(), "required"); > > I think test should still be run on all platforms even though login would fail. On other platforms than the test being run on, test shouldn't fail with "UnsatisfiedLinkError" as per JDK-8039951. Now it will run in all platform other than the running one and the expected failure is LoginException. So any other types of Exception will be treated as failure including UnsatisfiedLinkError. ------------- PR: https://git.openjdk.java.net/jdk/pull/7940 From ecki at zusammenkunft.net Mon Mar 28 09:30:05 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 28 Mar 2022 09:30:05 +0000 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> Message-ID: Hello, I think both might be too protocol specific to include it in JCE, but a library for JWK would fit into JWT support in Jakarta EE. For COSE the key descriptors are very simple (no certificates), not sure if anything besides a cose library is really needed. (That library would benefit from a curve registry, but since cose uses its own code values for the curve access to the CurveDB would not help I think). CBOR is not QR specific, it?s specific for the Covid Vaccination Certificate framework (due to the QR code size restriction it can?t use JSON). Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Anthony Scarpino Gesendet: Monday, March 28, 2022 6:31:29 AM An: Anders Rundgren Cc: Bernd Eckenfels ; security-dev at openjdk.java.net Betreff: Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA Thanks for all the info. We don?t have experience with JOSE or COSE, I think we need to digest some of this data before making a future step Not knowing this technology until you brought it up a few days ago, a few questions i have are how is this used and how common? Would I see this used for more secure sites like banks or shopping through the browser or it more common sites. Is it only browser-based or are their other used cases? Bernd mentioned QR codes, is COSE used inside the QR code or the authentication for the user to get to their QR code? Thanks Tony > On Mar 26, 2022, at 11:48 PM, Anders Rundgren wrote: > > ?On 2022-03-26 23:14, Bernd Eckenfels wrote: >> Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). >> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. >> BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. > > Thanx Bernd and Michael for the additional clarifications! > > Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037 > > This document defines how to use the Diffie-Hellman algorithms > "X25519" and "X448" as well as the signature algorithms "Ed25519" and > "Ed448" from the IRTF CFRG elliptic curves work in JSON Object > Signing and Encryption (JOSE). > > When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set. This is now an active proposal: > https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html > > Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading"). To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces. > > IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs. I'm therefore suggesting that key containers for specific crypto systems should have unique names. In this particular case "BLS" seems logical. In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey. > > WDYT? > > There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon. The same discussion has emerged for Post Quantum Crypto algorithms. > > Thanx, > Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From clanger at openjdk.java.net Mon Mar 28 09:52:44 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 28 Mar 2022 09:52:44 GMT Subject: Integrated: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319 In-Reply-To: <7OV9yFIJN-rK37sCt6N0TlLQ4uLHWbAuzvTi9b_RS70=.6c0a6a0f-ee0e-4405-8397-e944d201bef9@github.com> References: <7OV9yFIJN-rK37sCt6N0TlLQ4uLHWbAuzvTi9b_RS70=.6c0a6a0f-ee0e-4405-8397-e944d201bef9@github.com> Message-ID: On Sun, 27 Mar 2022 08:48:12 GMT, Christoph Langer wrote: > Remove double semicolon This pull request has now been integrated. Changeset: cdef087a Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/cdef087aae5d0edb3ad3421107d7dc2b5e18dd28 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319 Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/7976 From omikhaltcova at openjdk.java.net Mon Mar 28 10:58:49 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 28 Mar 2022 10:58:49 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. gentle ping; pls review this pr! ------------- PR: https://git.openjdk.java.net/jdk/pull/7658 From dev at anthonyv.be Mon Mar 28 12:12:06 2022 From: dev at anthonyv.be (Anthony Vanelverdinghe) Date: Mon, 28 Mar 2022 14:12:06 +0200 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> Message-ID: Just for the record, the code for the EU Digital Covid Certificate is available on GitHub at https://github.com/orgs/ehn-dcc-development/repositories?language=java Specifically, https://github.com/ehn-dcc-development/dgc-java#structure says "CBOR, CWT/COSE - Support for representing the DGC in CBOR and to sign/validate it. dgc-create-validate" Authentication for the user to get to their QR code was done via an eID (at least in the countries that issue electronic IDs). Kind regards Anthony On 28/03/2022 11:30, Bernd Eckenfels wrote: > Hello, > > I think both might be too protocol specific to include it in JCE, but > a library for JWK would fit into JWT support in Jakarta EE. > > ?For COSE the key descriptors are very simple (no certificates), not > sure if anything besides a cose library is really needed. (That > library would benefit from a curve registry, but since cose uses its > own code values for the curve access to the CurveDB would not help I > think). > > CBOR is not QR specific, it?s specific for the Covid Vaccination > Certificate framework (due to the QR code size restriction it can?t > use JSON). > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* Anthony Scarpino > *Gesendet:* Monday, March 28, 2022 6:31:29 AM > *An:* Anders Rundgren > *Cc:* Bernd Eckenfels ; > security-dev at openjdk.java.net > *Betreff:* Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA > Thanks for all the info. We don?t have experience with JOSE or COSE, I > think we need to digest some of this data before making a future step > > Not knowing this technology until you brought it up a few days ago, a > few questions i have are how is this used and how common?? Would I see > this used for more secure sites like banks or shopping through the > browser or it more common sites. Is it only browser-based or are their > other used cases?? Bernd mentioned QR codes, is COSE used inside the > QR code or the authentication for the user to get to their QR code? > > Thanks > > Tony > > > On Mar 26, 2022, at 11:48 PM, Anders Rundgren > wrote: > > > > ?On 2022-03-26 23:14, Bernd Eckenfels wrote: > >> Just for completeness, the standard for key transport in JOSE is > JWK (RFC7517). > >> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. > >> BTW the most widely used CBOR/COSE application are probably the QR > codes around Covid and Vaccination certificates of the EU. > > > > Thanx Bernd and Michael for the additional clarifications! > > > > Now to the thing that spurred this discussion: > https://datatracker.ietf.org/doc/html/rfc8037 > > > >?? This document defines how to use the Diffie-Hellman algorithms > >?? "X25519" and "X448" as well as the signature algorithms "Ed25519" and > >?? "Ed448" from the IRTF CFRG elliptic curves work in JSON Object > >?? Signing and Encryption (JOSE). > > > > When RFC 8037 was created the assumption was that the "OKP" key > container {sh|c}ould be used for other crypto systems having the same > parameter set.? This is now an active proposal: > > > https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html > > > > Obviously everything works just fine if you look at the container in > isolation. However, it means that "OKP" encoder/decoder code must be > updated for every new reuse ("overloading").? To be meaningful these > new algorithms would also have to coerced into the existing XEC or > EdDSA interfaces. > > > > IMO, this would be VERY UNFORTUNATE since it is incompatible with > the provider concept as well as with object oriented crypto APIs.? I'm > therefore suggesting that key containers for specific crypto systems > should have unique names.? In this particular case "BLS" seems > logical.? In Java it could eventually be mapped to BLSPublicKey and > BLSPrivateKey. > > > > WDYT? > > > > There is no need for a JEP at this stage, only some kind of > indication of what the JDK crypto team see as the best way forward > from your horizon.? The same discussion has emerged for Post Quantum > Crypto algorithms. > > > > Thanx, > > Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.java.net Mon Mar 28 14:39:45 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 28 Mar 2022 14:39:45 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 23:34:30 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > More minor edits. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 32: > 30: /** > 31: * This class specifies a parameter spec for RSASSA-PSS signature scheme, > 32: * as defined in the On line 31, add "the" before "RSASSA-PSS". src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 67: > 65: * } > 66: * > 67: *

    Note: the {@code PSSParameterSpec.DEFAULT} uses the following: Suggest rewording as: `Note: {@code PSSParameterSpec.DEFAULT} uses the following values:` src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 77: > 75: * from the PKCS#1 standard and may become obsolete as time progresses. > 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these > 77: * values are really what you want to use. Some suggested rewordings: `Its values are based on the default values defined in the PKCS#1 standard, as defined above. Some of these defaults are no longer recommended due to advances in cryptanalysis -- see RFC 8017 for more details. Thus, {@code PSSParameterSpec.DEFAULT} is deprecated and should be used at your own risk.` src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 114: > 112: * Thus, it is recommended to create a new {@code PSSParameterSpec} > 113: * object with the desired parameter values using > 114: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. Similar rewording suggestion here: "This field uses the default values defined in the PKCS#1 standard. Some of these defaults are no longer recommended due to advances in cryptanalysis -- see RFC 8017 for more details. Thus ..." src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 179: > 177: * @deprecated This constructor uses the default values defined in > 178: * the ASN.1 encoding in PKCS#1 except for the salt length. > 179: * These default values may become obsolete as time progresses. Similar rewording suggestion as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From xuelei at openjdk.java.net Mon Mar 28 14:44:45 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 28 Mar 2022 14:44:45 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. what are included int the cert9.db and key4.db? Imported/copied from cert8.db and key3.db or generated on the fly? ------------- PR: https://git.openjdk.java.net/jdk/pull/7658 From mullan at openjdk.java.net Mon Mar 28 14:51:55 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 28 Mar 2022 14:51:55 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. Please hold off on this change until we check on whether it needs additional 3rd party code approvals. ------------- PR: https://git.openjdk.java.net/jdk/pull/7658 From omikhaltcova at openjdk.java.net Mon Mar 28 16:24:48 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 28 Mar 2022 16:24:48 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. These files are just copied from another place of the repo as shown in the comments to JDK-8282538. They already exist. [olga at localhost projects]$ cp ./jdk-fork/test/jdk/sun/security/pkcs11/Secmod/cert9.db ./jdk-fork/test/jdk/sun/security/pkcs11/nss/db/ [olga at localhost projects]$ cp ./jdk-fork/test/jdk/sun/security/pkcs11/Secmod/key4.db ./jdk-fork/test/jdk/sun/security/pkcs11/nss/db/ ------------- PR: https://git.openjdk.java.net/jdk/pull/7658 From achung at openjdk.java.net Mon Mar 28 18:35:54 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 28 Mar 2022 18:35:54 GMT Subject: Integrated: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 This pull request has now been integrated. Changeset: c0aecd15 Author: Alisen Chung Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c0aecd15ae8d7abf37901f785fccaff2317c3b23 Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod 8280400: JDK 19 L10n resource files update - msgdrop 10 Reviewed-by: naoto, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From mullan at openjdk.java.net Mon Mar 28 18:40:42 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 28 Mar 2022 18:40:42 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. Marked as reviewed by mullan (Reviewer). Ok, thanks for the clarification. This change seems fine to me then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7658 From xuelei at openjdk.java.net Mon Mar 28 18:55:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 28 Mar 2022 18:55:48 GMT Subject: RFR: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. It looks good to me if the db files are copied from Secmod. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7658 From aturbanov at openjdk.java.net Mon Mar 28 19:16:44 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 28 Mar 2022 19:16:44 GMT Subject: Integrated: 8283711: Remove redundant 'new String' calls after concatenation In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:07:52 GMT, Andrey Turbanov wrote: > Result of string concatenation is a newly created String object. There is no need it wrap it in another 'new String' call. > Such calls are confusing and produce warnings in IDE. Without them code is easier to read. > Similar cleanup [JDK-8273375](https://bugs.openjdk.java.net/browse/JDK-8273375) in java.desktop This pull request has now been integrated. Changeset: d472c019 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/d472c019344524aa20c74bdc4ab7823b6940be67 Stats: 13 lines in 3 files changed: 0 ins; 1 del; 12 mod 8283711: Remove redundant 'new String' calls after concatenation Reviewed-by: wetmore, vromero, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7876 From aturbanov at openjdk.java.net Mon Mar 28 19:25:05 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 28 Mar 2022 19:25:05 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls Message-ID: In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. ------------- Commit messages: - [PATCH] Simplify String.indexOf/lastIndexOf calls Changes: https://git.openjdk.java.net/jdk/pull/7877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7877&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283800 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7877/head:pull/7877 PR: https://git.openjdk.java.net/jdk/pull/7877 From omikhaltcova at openjdk.java.net Mon Mar 28 19:30:46 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 28 Mar 2022 19:30:46 GMT Subject: Integrated: 8282538: PKCS11 tests fail on CentOS Stream 9 In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 12:05:08 GMT, Olga Mikhaltsova wrote: > I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. > Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. > In case of CentOS Stream 9 the lowest available version of NSS for downgrade is 3.67 and cert9.db, key4.db are targeted. This pull request has now been integrated. Changeset: d8fd2223 Author: Olga Mikhaltsova Committer: Alexey Bakhtin URL: https://git.openjdk.java.net/jdk/commit/d8fd22239bafecdaaedb8985ab6d709ed846e808 Stats: 0 lines in 2 files changed: 0 ins; 0 del; 0 mod 8282538: PKCS11 tests fail on CentOS Stream 9 Reviewed-by: mullan, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7658 From xueleifan at tencent.com Mon Mar 28 19:57:21 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 28 Mar 2022 19:57:21 +0000 Subject: [Internet]Re: Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> Message-ID: Thank you for the information and discussion, Anders, Bernd and Mike. I had a better understand of JOSE/COSE and the problems. For the crypto implementation, for example Ed25519 in the SunEC provider, I would prefer to keep the footprint in OpenJDK as minimal as possible. For example, the Ed25519 key factory could accept XECPublicKeySpec and XECPrivateKeySpec only, and support no more encoding format (currently, X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC provider). Except COSE/JOSE/PEM, there may be a few other known encoding formats, and more in the future. It would be challenging to track many encoding formats in specific protocols and their development in OpenJDK. If a provider does not support protocol specific format, the application rely on it could fail, which is not good for application developers. And thus the purpose to support more encoding format in one provider could be frangible. There could be third party's encoding format specific provider, for example a KeyFactory provider accepting JOSE/COSE format and converting between XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats. The factory might belong more to the protocol specific library, rather than the OpenJDK reference implementation. Unfortunately, the current KeyFactory.getInstance(? Ed25519?) design cannot identify the encoding formats, and thus may just return a provider that does not support the expected encoding format. It might be a workaround to use different algorithm name, like ?JOSE/Ed25519?. Alternatively, the JOSE/COSE could transfer the encoded stream to XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory. It may be transparent to application developers if the transferring is wrapped in the protocol specific lib. Just my $.02. Xuelei On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels > wrote: Hello, I think both might be too protocol specific to include it in JCE, but a library for JWK would fit into JWT support in Jakarta EE. For COSE the key descriptors are very simple (no certificates), not sure if anything besides a cose library is really needed. (That library would benefit from a curve registry, but since cose uses its own code values for the curve access to the CurveDB would not help I think). CBOR is not QR specific, it?s specific for the Covid Vaccination Certificate framework (due to the QR code size restriction it can?t use JSON). Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Anthony Scarpino > Gesendet: Monday, March 28, 2022 6:31:29 AM An: Anders Rundgren > Cc: Bernd Eckenfels >; security-dev at openjdk.java.net > Betreff: Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA Thanks for all the info. We don?t have experience with JOSE or COSE, I think we need to digest some of this data before making a future step Not knowing this technology until you brought it up a few days ago, a few questions i have are how is this used and how common? Would I see this used for more secure sites like banks or shopping through the browser or it more common sites. Is it only browser-based or are their other used cases? Bernd mentioned QR codes, is COSE used inside the QR code or the authentication for the user to get to their QR code? Thanks Tony > On Mar 26, 2022, at 11:48 PM, Anders Rundgren > wrote: > > ?On 2022-03-26 23:14, Bernd Eckenfels wrote: >> Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). >> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. >> BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. > > Thanx Bernd and Michael for the additional clarifications! > > Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037 > > This document defines how to use the Diffie-Hellman algorithms > "X25519" and "X448" as well as the signature algorithms "Ed25519" and > "Ed448" from the IRTF CFRG elliptic curves work in JSON Object > Signing and Encryption (JOSE). > > When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set. This is now an active proposal: > https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html > > Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading"). To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces. > > IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs. I'm therefore suggesting that key containers for specific crypto systems should have unique names. In this particular case "BLS" seems logical. In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey. > > WDYT? > > There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon. The same discussion has emerged for Post Quantum Crypto algorithms. > > Thanx, > Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Mon Mar 28 20:11:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 28 Mar 2022 20:11:42 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. Please add a noreg- label to the bug. Otherwise, looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7877 From bpb at openjdk.java.net Mon Mar 28 20:11:42 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 28 Mar 2022 20:11:42 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7877 From achung at openjdk.java.net Mon Mar 28 21:30:15 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 28 Mar 2022 21:30:15 GMT Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 Message-ID: This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. ------------- Commit messages: - Revert "8280400: JDK 19 L10n resource files update - msgdrop 10" Changes: https://git.openjdk.java.net/jdk/pull/8005/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8005&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283806 Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod Patch: https://git.openjdk.java.net/jdk/pull/8005.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8005/head:pull/8005 PR: https://git.openjdk.java.net/jdk/pull/8005 From kcr at openjdk.java.net Mon Mar 28 21:30:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Mar 2022 21:30:16 GMT Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. I confirm that this is an exact backout of [JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400). ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/8005 From lmesnik at openjdk.java.net Mon Mar 28 21:49:55 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 28 Mar 2022 21:49:55 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7877 From valeriep at openjdk.java.net Mon Mar 28 21:50:32 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 28 Mar 2022 21:50:32 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v6] In-Reply-To: References: Message-ID: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Trimmed the duplicated mentioning of DEFAULT from class javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/c3b5dbe8..0a99ba26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=04-05 Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Mon Mar 28 21:50:33 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 28 Mar 2022 21:50:33 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 14:12:36 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> More minor edits. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 32: > >> 30: /** >> 31: * This class specifies a parameter spec for RSASSA-PSS signature scheme, >> 32: * as defined in the > > On line 31, add "the" before "RSASSA-PSS". Ok. > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 67: > >> 65: * } >> 66: * >> 67: *

    Note: the {@code PSSParameterSpec.DEFAULT} uses the following: > > Suggest rewording as: > `Note: {@code PSSParameterSpec.DEFAULT} uses the following values:` This part has been removed to reduce duplication since there is already javadoc for DEFAULT below. > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 77: > >> 75: * from the PKCS#1 standard and may become obsolete as time progresses. >> 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these >> 77: * values are really what you want to use. > > Some suggested rewordings: > > `Its values are based on the default values defined in the PKCS#1 standard, as defined above. Some of these defaults are no longer recommended due to advances in cryptanalysis -- see RFC 8017 for more details. Thus, {@code PSSParameterSpec.DEFAULT} is deprecated and should be used at your own risk.` Thanks for the rewording suggestion. This part has been removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Mon Mar 28 21:54:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 28 Mar 2022 21:54:44 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 14:36:24 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> More minor edits. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 179: > >> 177: * @deprecated This constructor uses the default values defined in >> 178: * the ASN.1 encoding in PKCS#1 except for the salt length. >> 179: * These default values may become obsolete as time progresses. > > Similar rewording suggestion as above. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Mon Mar 28 22:10:42 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 28 Mar 2022 22:10:42 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 14:35:31 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> More minor edits. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 114: > >> 112: * Thus, it is recommended to create a new {@code PSSParameterSpec} >> 113: * object with the desired parameter values using >> 114: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. > > Similar rewording suggestion here: > > "This field uses the default values defined in the PKCS#1 standard. Some of these defaults are no longer recommended due to advances in cryptanalysis -- see RFC 8017 for more details. Thus ..." Hmm, RFC 8017 is PKCS#1 v2.2 and I assume you mean PKCS#1 v2.2 with link to RFC 8017. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Mon Mar 28 22:18:20 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 28 Mar 2022 22:18:20 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v7] In-Reply-To: References: Message-ID: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update again with Sean's wording suggestion. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/0a99ba26..db4dddb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=05-06 Stats: 20 lines in 1 file changed: 5 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From naoto at openjdk.java.net Mon Mar 28 22:44:36 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 22:44:36 GMT Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8005 From achung at openjdk.java.net Mon Mar 28 23:40:44 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 28 Mar 2022 23:40:44 GMT Subject: Integrated: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. This pull request has now been integrated. Changeset: 634800a5 Author: Alisen Chung Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/634800a536e7f9d148a4caa2663a60a2c5fc4929 Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 Reviewed-by: kcr, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/8005 From ssahoo at openjdk.java.net Tue Mar 29 06:24:16 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Tue, 29 Mar 2022 06:24:16 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule [v3] In-Reply-To: References: Message-ID: > Added coverage to logout method. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update AllPlatforms.java Updated exception handling to ignore the case where the running platform doesn't match the test case. In that case required native library loading will fail. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7940/files - new: https://git.openjdk.java.net/jdk/pull/7940/files/13a999b0..b7e3bc04 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7940&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7940&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7940/head:pull/7940 PR: https://git.openjdk.java.net/jdk/pull/7940 From duke at openjdk.java.net Tue Mar 29 09:51:42 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 29 Mar 2022 09:51:42 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com> References: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com> Message-ID: On Sat, 26 Mar 2022 16:35:14 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes in MethodType > > Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array? @liach I've found a couple of places: - `AsynchronousFileChannel.open()` - `FileChannel.open()` - `DecimalStyle.getAvailableLocales()` They all either rely on user input, i.e. might throw NPE or IAE for nulls or duplicates respectively, or return the set, which is currently modifiable `HashSet`. I think the possible win isn't worth the effort. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From mullan at openjdk.java.net Tue Mar 29 14:22:45 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 29 Mar 2022 14:22:45 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v7] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 22:18:20 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update again with Sean's wording suggestion. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 98: > 96: > 97: /** > 98: * The PSS parameter set with all default values Nit - add period at end of sentence. src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 106: > 104: * a new {@code PSSParameterSpec} with the desired parameter values > 105: * using > 106: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. I think it would be more clear to see the full signature of the ctor that you are recommending be used instead, so I would change these 2 lines to: `using the {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int)} constructor.` src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 175: > 173: * standard for more details. Thus, it is recommended to explicitly > 174: * specify all desired parameter values with > 175: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. Same comment about seeing the full signature of the ctor as mentioned above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From anders.rundgren.net at gmail.com Tue Mar 29 17:18:26 2022 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 29 Mar 2022 19:18:26 +0200 Subject: "Pluggable" key serialization in JCE/JCA In-Reply-To: References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> Message-ID: <5684ad88-1658-e6dc-b4d7-87060f03d75c@gmail.com> On 2022-03-28 21:57, xueleifan(XueleiFan) wrote: > Thank you for the information and discussion, Anders, Bernd and Mike. ?I had a better understand of JOSE/COSE and the problems. Thanx Xuelei! May I ask a highly related question? Assume there is a new cool XYZ algorithm family supported by a third party JCE provider. What would be needed in order to make XYZ public keys in X.509 certificates automatically decode into an associated XYXPublicKey (also supplied by the third party)? I tried to follow the JDK X.509 decoder source but I failed :( Regards, Anders > > For the crypto implementation, for example Ed25519 in the SunEC provider, I would prefer to keep the footprint in OpenJDK as minimal as possible. ?For example, the Ed25519 key factory could accept?XECPublicKeySpec and?XECPrivateKeySpec only, and support no more encoding format (currently,?X509EncodedKeySpec?and?PKCS8EncodedKeySpec are also supported?by the SunEC provider). ?Except COSE/JOSE/PEM, there may be a few other known encoding formats, and more in the future. ?It would be challenging to track many encoding formats in specific protocols and their development in OpenJDK. ?If a provider does not support protocol specific format, the application rely on it could fail, which is not good for application developers. ?And thus the purpose to support more encoding format in one provider could be frangible. > > There could be third party's encoding format specific provider, for example a KeyFactory provider accepting JOSE/COSE format and converting between XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats. ?The factory might belong more to the protocol specific library, rather than the OpenJDK reference implementation. Unfortunately, the current KeyFactory.getInstance(??Ed25519?) design cannot identify the encoding formats, and thus may just return a provider that does not support the expected encoding format. ?It might be a workaround to use different algorithm name, like ?JOSE/Ed25519?. > > Alternatively, the JOSE/COSE could transfer the encoded stream to XECPublicKeySpec and?XECPrivateKeySpec, without using KeyFactory. ?It may be transparent to application developers if the transferring is wrapped in the protocol specific lib. > > Just my $.02. > > Xuelei > >> On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels > wrote: >> >> Hello, >> >> I think both might be too protocol specific to include it in JCE, but a library for JWK would fit into JWT support in Jakarta EE. >> >> ?For COSE the key descriptors are very simple (no certificates), not sure if anything besides a cose library is really needed. (That library would benefit from a curve registry, but since cose uses its own code values for the curve access to the CurveDB would not help I think). >> >> CBOR is not QR specific, it?s specific for the Covid Vaccination Certificate framework (due to the QR code size restriction it can?t use JSON). >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *Von:* Anthony Scarpino > >> *Gesendet:* Monday, March 28, 2022 6:31:29 AM >> *An:* Anders Rundgren > >> *Cc:* Bernd Eckenfels >; security-dev at openjdk.java.net > >> *Betreff:* Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA >> Thanks for all the info. We don?t have experience with JOSE or COSE, I think we need to digest some of this data before making a future step >> >> Not knowing this technology until you brought it up a few days ago, a few questions i have are how is this used and how common?? Would I see this used for more secure sites like banks or shopping through the browser or it more common sites. Is it only browser-based or are their other used cases?? Bernd mentioned QR codes, is COSE used inside the QR code or the authentication for the user to get to their QR code? >> >> Thanks >> >> Tony >> >> > On Mar 26, 2022, at 11:48 PM, Anders Rundgren > wrote: >> > >> > ?On 2022-03-26 23:14, Bernd Eckenfels wrote: >> >> Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). >> >> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. >> >> BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. >> > >> > Thanx Bernd and Michael for the additional clarifications! >> > >> > Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037 >> > >> >?? This document defines how to use the Diffie-Hellman algorithms >> >?? "X25519" and "X448" as well as the signature algorithms "Ed25519" and >> >?? "Ed448" from the IRTF CFRG elliptic curves work in JSON Object >> >?? Signing and Encryption (JOSE). >> > >> > When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set.? This is now an active proposal: >> > https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html >> > >> > Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading").? To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces. >> > >> > IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs.? I'm therefore suggesting that key containers for specific crypto systems should have unique names.? In this particular case "BLS" seems logical.? In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey. >> > >> > WDYT? >> > >> > There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon.? The same discussion has emerged for Post Quantum Crypto algorithms. >> > >> > Thanx, >> > Anders > From xueleifan at tencent.com Tue Mar 29 17:58:45 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Tue, 29 Mar 2022 17:58:45 +0000 Subject: [Internet]Re: "Pluggable" key serialization in JCE/JCA In-Reply-To: <5684ad88-1658-e6dc-b4d7-87060f03d75c@gmail.com> References: <0de9ec29-a06c-10e7-54ff-ddcacabd559b@gmail.com> <5c9c8a22-3ee0-90fd-cffa-4d8344c9dfba@comcast.net> <40dd14d8-15c1-75ce-0954-da0e300749a3@gmail.com> <25edb158-18c3-03ed-3a86-7bf07608e5c2@comcast.net> <5e298314-a288-69ac-6fa8-7ae5d4955b99@oracle.com> <4bf301fb-9a02-1bf3-e9bf-14abec8b25d8@gmail.com> <79807ce0-75e9-96d4-a703-fed74b106970@comcast.net> <42588480-FF6F-48AE-A010-4270FE89A212@Tencent.Com> <44a857e7-6cc8-5019-1597-fb51aa5f19a5@comcast.net> <289bddeb-f237-7553-8529-21abcdb3cebe@gmail.com> <83B5C82B-DBF8-4CF6-AE08-B079B6347728@oracle.com> <5684ad88-1658-e6dc-b4d7-87060f03d75c@gmail.com> Message-ID: > On Mar 29, 2022, at 10:18 AM, Anders Rundgren wrote: > > On 2022-03-28 21:57, xueleifan(XueleiFan) wrote: >> Thank you for the information and discussion, Anders, Bernd and Mike. I had a better understand of JOSE/COSE and the problems. > > Thanx Xuelei! > May I ask a highly related question? > > Assume there is a new cool XYZ algorithm family supported by a third party JCE provider. > What would be needed in order to make XYZ public keys in X.509 certificates automatically decode into an associated XYXPublicKey (also supplied by the third party)? > It depends. For the JDK X509 certificate implementation, KeyFactory are used to generated the public key from X509 encoded key specification (public key DER value in the cert). X509EncodedKeySpec x509KeySpec = new X509EncodedKeySpec(x509EncodedKeyStream.toByteArray()); KeyFactory keyFac = KeyFactory.getInstance(algid.getName()); keyFac.generatePublic(x509KeySpec); The ?algid? is also recorded in the X.509 certificate. So, a third party provider may be able to get it supported by support XYZ algorithm in its KeyFactory implementation. KeyFactory keyFac = KeyFactory.getInstance(?XYZ?/?XYZ-OID?); But it really depends on the X.509 provider implementation behaviors. I know there are cases that X.509 provider was updated, or forked, here and there in order to support new algorithms, unfortunately. Best, Xuelei > I tried to follow the JDK X.509 decoder source but I failed :( > > Regards, > Anders > >> For the crypto implementation, for example Ed25519 in the SunEC provider, I would prefer to keep the footprint in OpenJDK as minimal as possible. For example, the Ed25519 key factory could accept XECPublicKeySpec and XECPrivateKeySpec only, and support no more encoding format (currently, X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC provider). Except COSE/JOSE/PEM, there may be a few other known encoding formats, and more in the future. It would be challenging to track many encoding formats in specific protocols and their development in OpenJDK. If a provider does not support protocol specific format, the application rely on it could fail, which is not good for application developers. And thus the purpose to support more encoding format in one provider could be frangible. >> There could be third party's encoding format specific provider, for example a KeyFactory provider accepting JOSE/COSE format and converting between XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats. The factory might belong more to the protocol specific library, rather than the OpenJDK reference implementation. Unfortunately, the current KeyFactory.getInstance(? Ed25519?) design cannot identify the encoding formats, and thus may just return a provider that does not support the expected encoding format. It might be a workaround to use different algorithm name, like ?JOSE/Ed25519?. >> Alternatively, the JOSE/COSE could transfer the encoded stream to XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory. It may be transparent to application developers if the transferring is wrapped in the protocol specific lib. >> Just my $.02. >> Xuelei >>> On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels > wrote: >>> >>> Hello, >>> >>> I think both might be too protocol specific to include it in JCE, but a library for JWK would fit into JWT support in Jakarta EE. >>> >>> For COSE the key descriptors are very simple (no certificates), not sure if anything besides a cose library is really needed. (That library would benefit from a curve registry, but since cose uses its own code values for the curve access to the CurveDB would not help I think). >>> >>> CBOR is not QR specific, it?s specific for the Covid Vaccination Certificate framework (due to the QR code size restriction it can?t use JSON). >>> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>> *Von:* Anthony Scarpino > >>> *Gesendet:* Monday, March 28, 2022 6:31:29 AM >>> *An:* Anders Rundgren > >>> *Cc:* Bernd Eckenfels >; security-dev at openjdk.java.net > >>> *Betreff:* Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA >>> Thanks for all the info. We don?t have experience with JOSE or COSE, I think we need to digest some of this data before making a future step >>> >>> Not knowing this technology until you brought it up a few days ago, a few questions i have are how is this used and how common? Would I see this used for more secure sites like banks or shopping through the browser or it more common sites. Is it only browser-based or are their other used cases? Bernd mentioned QR codes, is COSE used inside the QR code or the authentication for the user to get to their QR code? >>> >>> Thanks >>> >>> Tony >>> >>> > On Mar 26, 2022, at 11:48 PM, Anders Rundgren > wrote: >>> > > ?On 2022-03-26 23:14, Bernd Eckenfels wrote: >>> >> Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). >>> >> In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. >>> >> BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. >>> > > Thanx Bernd and Michael for the additional clarifications! >>> > > Now to the thing that spurred this discussion: https://datatracker.ietf.org/doc/html/rfc8037 >>> > > This document defines how to use the Diffie-Hellman algorithms >>> > "X25519" and "X448" as well as the signature algorithms "Ed25519" and >>> > "Ed448" from the IRTF CFRG elliptic curves work in JSON Object >>> > Signing and Encryption (JOSE). >>> > > When RFC 8037 was created the assumption was that the "OKP" key container {sh|c}ould be used for other crypto systems having the same parameter set. This is now an active proposal: >>> > https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html >>> > > Obviously everything works just fine if you look at the container in isolation. However, it means that "OKP" encoder/decoder code must be updated for every new reuse ("overloading"). To be meaningful these new algorithms would also have to coerced into the existing XEC or EdDSA interfaces. >>> > > IMO, this would be VERY UNFORTUNATE since it is incompatible with the provider concept as well as with object oriented crypto APIs. I'm therefore suggesting that key containers for specific crypto systems should have unique names. In this particular case "BLS" seems logical. In Java it could eventually be mapped to BLSPublicKey and BLSPrivateKey. >>> > > WDYT? >>> > > There is no need for a JEP at this stage, only some kind of indication of what the JDK crypto team see as the best way forward from your horizon. The same discussion has emerged for Post Quantum Crypto algorithms. >>> > > Thanx, >>> > Anders > From mcimadamore at openjdk.java.net Tue Mar 29 18:13:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 29 Mar 2022 18:13:05 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v12] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore 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 27 additional commits since the last revision: - Use thread local storage to optimize attach of async threads - Drop support for Constable from MemoryLayout/FunctionDescriptor - Merge branch 'master' into foreign-preview - Revert changes to RunTests.gmk - Add --enable-preview to micro benchmark java options - Address more review comments - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee - Address review comments - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee - ... and 17 more: https://git.openjdk.java.net/jdk/compare/02333d66...55aee872 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/504b564a..55aee872 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=10-11 Stats: 99257 lines in 1550 files changed: 79659 ins; 15544 del; 4054 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue Mar 29 18:23:41 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 29 Mar 2022 18:23:41 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v13] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Switch to daemon threads for async upcalls ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/55aee872..43dc6be3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From rhalade at openjdk.java.net Tue Mar 29 18:28:08 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 29 Mar 2022 18:28:08 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule [v3] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 06:24:16 GMT, Sibabrata Sahoo wrote: >> Added coverage to logout method. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update AllPlatforms.java > > Updated exception handling to ignore the case where the running platform doesn't match the test case. In that case required native library loading will fail. Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7940 From rhalade at openjdk.java.net Tue Mar 29 18:28:12 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 29 Mar 2022 18:28:12 GMT Subject: RFR: 8281717: Cover logout method for several LoginModule [v3] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 06:58:29 GMT, Sibabrata Sahoo wrote: >> test/jdk/com/sun/security/auth/module/AllPlatforms.java line 45: >> >>> 43: UNIX_MODULE, "optional", >>> 44: NT_MODULE, "optional"); >>> 45: login(OS.replaceAll("[^a-zA-Z0-9]", ""), getPlatformLoginModule(), "required"); >> >> I think test should still be run on all platforms even though login would fail. On other platforms than the test being run on, test shouldn't fail with "UnsatisfiedLinkError" as per JDK-8039951. > > Now it will run in all platform other than the running one and the expected failure is LoginException. So any other types of Exception will be treated as failure including UnsatisfiedLinkError. thanks for addressing it! ------------- PR: https://git.openjdk.java.net/jdk/pull/7940 From wetmore at openjdk.java.net Tue Mar 29 22:02:36 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 29 Mar 2022 22:02:36 GMT Subject: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v3] In-Reply-To: References: Message-ID: <3Ywjt1MLxEKsjLW0qVfLCi2AbwEOdflg0DMjWzdQN88=.2456dc39-0033-44b7-8e17-354adab81f7a@github.com> > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal internal_error (80) and invalidate existing sessions (either completed or under construction) as described in (RFC 4346/TLSv1.1+) if a connection was closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their respective sessions. > > Tier1/2 mach5 tests have been successfully run. Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge branch 'master' into JDK-8273553 - Code review comment: enclose conContext.closeInbound() in a try/finally block. - Merge branch 'master' into JDK-8273553 - Merge branch 'master' into JDK-8273553 - Added SSLSocket bugid since we're actually checking both sides now. - I/O Issues, rewrite the I/O section so that early Socket closes don't kill our server-side reads. - Merge branch 'master' into JDK-8273553 - Merge branch 'master' into JDK-8273553 - Merge - Minor test tweaks. - ... and 3 more: https://git.openjdk.java.net/jdk/compare/38460839...08d22aee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7796/files - new: https://git.openjdk.java.net/jdk/pull/7796/files/b2f64d92..08d22aee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7796&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7796&range=01-02 Stats: 65793 lines in 503 files changed: 62965 ins; 887 del; 1941 mod Patch: https://git.openjdk.java.net/jdk/pull/7796.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7796/head:pull/7796 PR: https://git.openjdk.java.net/jdk/pull/7796 From valeriep at openjdk.java.net Tue Mar 29 22:47:30 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Mar 2022 22:47:30 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v7] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 14:08:26 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again with Sean's wording suggestion. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 98: > >> 96: >> 97: /** >> 98: * The PSS parameter set with all default values > > Nit - add period at end of sentence. Sure. > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 106: > >> 104: * a new {@code PSSParameterSpec} with the desired parameter values >> 105: * using >> 106: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. > > I think it would be more clear to see the full signature of the ctor that you are recommending be used instead, so I would change these 2 lines to: > > `using the {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int)} constructor.` Makes sense. > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 175: > >> 173: * standard for more details. Thus, it is recommended to explicitly >> 174: * specify all desired parameter values with >> 175: * {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) PSSParameterSpec}. > > Same comment about seeing the full signature of the ctor as mentioned above. Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Tue Mar 29 22:47:21 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Mar 2022 22:47:21 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v8] In-Reply-To: References: Message-ID: <_cv4JvXIu-OXFKkwcn9d5jwJ0KWFd_-enFglgxKdNoM=.a70ec8e4-17d4-4571-9dcc-ae5fff3effba@github.com> > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Changed the PSSParameterSpec javadoc link to show arguments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/db4dddb1..26e31a64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=06-07 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From achung at openjdk.java.net Wed Mar 30 00:54:29 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 30 Mar 2022 00:54:29 GMT Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10 Message-ID: redo of 8280400 ------------- Commit messages: - 8280400: JDK 19 L10n resource files update - msgdrop 10 Changes: https://git.openjdk.java.net/jdk/pull/8026/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8026&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283805 Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod Patch: https://git.openjdk.java.net/jdk/pull/8026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026 PR: https://git.openjdk.java.net/jdk/pull/8026 From aturbanov at openjdk.java.net Wed Mar 30 07:11:38 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 30 Mar 2022 07:11:38 GMT Subject: Integrated: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. This pull request has now been integrated. Changeset: 9bb916db Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/9bb916db0a6af2c6476c0bfbc55c1bb8721b4354 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod 8283800: Simplify String.indexOf/lastIndexOf calls Reviewed-by: xuelei, bpb, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/7877 From kcr at openjdk.java.net Wed Mar 30 11:35:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Mar 2022 11:35:38 GMT Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote: > redo of 8280400 Since this is identical to the original fix, I would expect the same Tier2 test failure as reported in [JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804). ------------- PR: https://git.openjdk.java.net/jdk/pull/8026 From mullan at openjdk.java.net Wed Mar 30 14:44:41 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 30 Mar 2022 14:44:41 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v8] In-Reply-To: <_cv4JvXIu-OXFKkwcn9d5jwJ0KWFd_-enFglgxKdNoM=.a70ec8e4-17d4-4571-9dcc-ae5fff3effba@github.com> References: <_cv4JvXIu-OXFKkwcn9d5jwJ0KWFd_-enFglgxKdNoM=.a70ec8e4-17d4-4571-9dcc-ae5fff3effba@github.com> Message-ID: On Tue, 29 Mar 2022 22:47:21 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. >> >> A CSR will be filed once the wording changes are reviewed. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed the PSSParameterSpec javadoc link to show arguments. Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 105: > 103: * standard for more details. Thus, it is recommended to create > 104: * a new {@code PSSParameterSpec} with the desired parameter values > 105: * using s/using/using the/ src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 174: > 172: * PKCS#1 v2.2 > 173: * standard for more details. Thus, it is recommended to explicitly > 174: * specify all desired parameter values with s/with/with the/ ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From naoto at openjdk.java.net Wed Mar 30 15:48:38 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 30 Mar 2022 15:48:38 GMT Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote: > redo of 8280400 I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8026 From mcimadamore at openjdk.java.net Wed Mar 30 18:06:28 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 30 Mar 2022 18:06:28 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v14] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix bad usage of `@link` with primitive array types ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/43dc6be3..0bcc8664 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=12-13 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From valeriep at openjdk.java.net Wed Mar 30 20:07:23 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Mar 2022 20:07:23 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v9] In-Reply-To: References: Message-ID: > Can someone help review this update to the PSSParameterSpec class regarding the constructor with int argument and the DEFAULT static field? Just added @Deprecate javadoc tag and caution about their usage as suggested in the bug record. > > A CSR will be filed once the wording changes are reviewed. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor edit to address Sean's review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7913/files - new: https://git.openjdk.java.net/jdk/pull/7913/files/26e31a64..29b03c11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7913&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913 PR: https://git.openjdk.java.net/jdk/pull/7913 From valeriep at openjdk.java.net Wed Mar 30 20:07:24 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Mar 2022 20:07:24 GMT Subject: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v8] In-Reply-To: References: <_cv4JvXIu-OXFKkwcn9d5jwJ0KWFd_-enFglgxKdNoM=.a70ec8e4-17d4-4571-9dcc-ae5fff3effba@github.com> Message-ID: <8ci3py2Ew9-F0h9o_UyTwIw3wxh5q26Etr6LwKgeR2A=.a6d7b4a9-aa8a-4776-8d0f-e37b7d11c053@github.com> On Wed, 30 Mar 2022 14:40:00 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed the PSSParameterSpec javadoc link to show arguments. > > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 105: > >> 103: * standard for more details. Thus, it is recommended to create >> 104: * a new {@code PSSParameterSpec} with the desired parameter values >> 105: * using > > s/using/using the/ Yes, thanks. Need to re-read the whole sentence again even with minor changes... > src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 174: > >> 172: * PKCS#1 v2.2 >> 173: * standard for more details. Thus, it is recommended to explicitly >> 174: * specify all desired parameter values with > > s/with/with the/ Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7913 From mcimadamore at openjdk.java.net Wed Mar 30 20:59:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 30 Mar 2022 20:59:34 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v15] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak FunctionDescriptor::argumentLayouts to return an immutable list ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/0bcc8664..af41a76c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=13-14 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed Mar 30 21:51:16 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 30 Mar 2022 21:51:16 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into foreign-preview - Tweak FunctionDescriptor::argumentLayouts to return an immutable list - Fix bad usage of `@link` with primitive array types - Switch to daemon threads for async upcalls - Use thread local storage to optimize attach of async threads - Drop support for Constable from MemoryLayout/FunctionDescriptor - Merge branch 'master' into foreign-preview - Revert changes to RunTests.gmk - Add --enable-preview to micro benchmark java options - Address more review comments - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=15 Stats: 64862 lines in 366 files changed: 43028 ins; 19321 del; 2513 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Wed Mar 30 22:25:44 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 30 Mar 2022 22:25:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v15] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 20:59:34 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak FunctionDescriptor::argumentLayouts to return an immutable list src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 73: > 71: */ > 72: public List argumentLayouts() { > 73: return Collections.unmodifiableList(argLayouts); This?change doesn?t?seem to?be?necessary, as?`FunctionDescriptor` is?already?created?with?`List.of(?)` (or?`Stream.toList()` in?the?case of?`FunctionDescriptor.VariadicFunction`), which?produce immutable?lists (although?`Stream.toList()` permits?`null`s, which?`Stream.collect(Collectors.toImmutableList())` and?`List.of(?)`?doesn?t). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From psandoz at openjdk.java.net Wed Mar 30 22:44:42 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 30 Mar 2022 22:44:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Merge branch 'master' into foreign-preview > - Tweak FunctionDescriptor::argumentLayouts to return an immutable list > - Fix bad usage of `@link` with primitive array types > - Switch to daemon threads for async upcalls > - Use thread local storage to optimize attach of async threads > - Drop support for Constable from MemoryLayout/FunctionDescriptor > - Merge branch 'master' into foreign-preview > - Revert changes to RunTests.gmk > - Add --enable-preview to micro benchmark java options > - Address more review comments > - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5 Java code looks good (i did not go through the tests). As is common no comments, since code was reviewed in smaller steps in the panama-foreign respository. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From Matthew.Carter at microsoft.com Thu Mar 31 21:16:47 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Thu, 31 Mar 2022 21:16:47 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location Message-ID: Current support for KeyStores on Windows is limited to the current user location [1] There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. Given the above I propose that we add native support for local machine KeyStore locations Users can currently access two physical key stores (in the current user location): "Windows-MY": .Default "Windows-ROOT": .Default.LocalMachine, .SmartCard Adding the local machine location opens up access to a further two physical key stores ? "Windows-MY": .Default "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject Thanks in advance Mat Carter [1] https://docs.microsoft.com/en-us/windows/win32/seccrypto/system-store-locations [2] https://bugs.openjdk.java.net/browse/JDK-6782021 [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017832.html [4] https://stackoverflow.com/questions/70200603/accessing-windows-local-machine-certificates-from-a-windows-service-written-in-j [5] https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java Sent from Outlook