From jlaskey at openjdk.java.net Thu Apr 1 11:04:53 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 1 Apr 2021 11:04:53 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v40] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: - Merge branch 'master' into 8248862 - Correct return type of RandomGeneratorFactory.of - Merge branch 'master' into 8248862 - CSR review revisions - CSR review updates - Removed @since from nextDouble ThreadLocalRandom - RandomGeneratorFactory::all(Class category) @implNote was out of date - Clarify all() - Cleaned up ints(), longs(), doubles() - Merge branch 'master' into 8248862 - ... and 66 more: https://git.openjdk.java.net/jdk/compare/011f6d13...5a23b4f1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=39 Stats: 12968 lines in 26 files changed: 11202 ins; 1588 del; 178 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From weijun at openjdk.java.net Thu Apr 1 13:32:47 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 13:32:47 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: spec word change, no hashCode and equals, test change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3181/files - new: https://git.openjdk.java.net/jdk/pull/3181/files/211c491c..5b88fff4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=01-02 Stats: 69 lines in 5 files changed: 18 ins; 38 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3181/head:pull/3181 PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Thu Apr 1 13:32:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 13:32:49 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: References: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com> Message-ID: <_-zU9sQFME5GaU1_tSs2TAUuOkOxk4REAbRo46DTwMA=.a814b3d5-fe64-4ca4-a9a1-3a43685259f5@github.com> On Tue, 30 Mar 2021 20:24:49 GMT, Weijun Wang wrote: >> I wonder if the @implSpec is clear enough that this will be returned. I might suggest adding a similar @implSpec in this method that basically states what you said above. > > I'm not sure if it's appropriate to specify the default value in this method. As long as there is an `RSAPSSParameterSpec` object, there must be a non-null `PSSParameterSpec` inside and it is the one that was used to construct this object. > > I am thinking if we can append the following to the `@implSpec` in the class spec: > * One can obtain this default value using the following expression: > *

>  * XMLSignatureFactory.getInstance()
>  *      .newSignatureMethod(SignatureMethod.RSA_PSS, null)
>  *      .getParameterSpec()
>  * 
> > but this makes it more like an `@implNote` instead of an `@implSpec`. I added the new lines as `@implNote` and kept the old `@implSpec` there (since it's still a requirement for implementations). New commit pushed. CSR updated as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From jnimeh at openjdk.java.net Thu Apr 1 15:55:18 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 1 Apr 2021 15:55:18 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 21:47:24 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. > > thanks > > Tony src/java.base/share/classes/sun/security/rsa/RSACore.java line 414: > 412: if (!u.equals(BigInteger.ZERO) && > 413: !v.equals(BigInteger.ZERO)) { > 414: Is it ever possible that u could be equal to BigInteger.ZERO? The only place I see a new BlindingRandomPair created is within the scope of the BlindingParameters object, and it has a guard in its constructor that resets u to BigInteger.ONE if u is zero. Or is this check to guard against the reset of u/v down around line 416-419 (recalculated when reusable)? ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From hchao at openjdk.java.net Thu Apr 1 16:34:43 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 16:34:43 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: > Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. > CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Updated with review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3281/files - new: https://git.openjdk.java.net/jdk/pull/3281/files/f33cf92a..5d4d11cc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=00-01 Stats: 129 lines in 6 files changed: 38 ins; 42 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/3281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3281/head:pull/3281 PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 1 16:34:53 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 16:34:53 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Wed, 31 Mar 2021 13:36:39 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated with review comments > > Some comments on the CSR: > 1. In the "Solution" section, we might need to point out that since there is no standard way to create a certificate request in this case (because the request must be signed by the owner's private key) we will not be able to enhance `-certreq` and `-gencert` to achieve the goal. > 2. In the "Specification" section, "It is a required option...". I would prefer "This is especially useful when...". Also, we should not mention "JKS" since there can be other keystores using different key passwords. Just say "It can be specified if the private key of the signer entry is protected by a different password from the store password". Or you can look at how `-keypass` is described in other commands. > 3. I don't think it's necessary to list `X448` and `X25519` in the "Default key size" section since that's the only key size for the algorithms. We only need to say `255 (when using -genkeypair and -keyalg is "EdDSA" or "XDH")`. @wangweij Thanks for the review. Updated the CSR with your comments. > src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 114: > >> 112: } >> 113: >> 114: /** > > The original constructor can be modified to call `this(keyType,sigAlg,providerName,null,null)`. This is also a good time to modify `public CertAndKeyGen (String keyType, String sigAlg)` to call `this(keyType,sigAlg,null)`. Also please simplify the method javadoc. Updated the original constructor to call `this(keyType,sigAlg,providerName,null,null)` and its comment block. But leave another original constructor `public CertAndKeyGen (String keyType, String sigAlg)` unchanged, because it does not have `providerName` and `NoSuchProviderException` should not be declared like other constructors. > src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 234: > >> 232: if (sigAlg == null) { >> 233: throw new IllegalArgumentException( >> 234: "Cannot derive signature algorithm from " > > The text of the exception should be updated because a different key could be used. Done. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1930: > >> 1928: } >> 1929: >> 1930: if (reqSigner && signerAlias == null) { > > What if we do not use a `reqSigner` flag? Will the error message be misleading. I guess it will something like "Cannot derive a signature algorithm from the key algorithm". My opinion is that it's quite enough. > > If we keep it, we will have to maintain it. Removed this flag to let the "Cannot derive signature algorithm from keyAlg" be emitted instead. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1941: > >> 1939: signerFlag = true; >> 1940: >> 1941: if (keyStore.containsAlias(signerAlias) == false) { > > It's probably more precise to make sure the entry is a `PrivateKeyEntry` because we have other entries like `TrustedCertificateEntry` and `SecretKeyEntry`. Or you can double check this below to ensure both `signerPrivateKey` and `signerCert` are non null. As `RecoveryKey()` will make sure if the entry exists in the keystore and is a `PrivateKeyEntry`, removed this checking and updated to check for if `signerCert` is null. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1951: > >> 1949: (PrivateKey)recoverKey(signerAlias, storePass, signerKeyPass).fst; >> 1950: Certificate signerCert = keyStore.getCertificate(signerAlias); >> 1951: byte[] encoded = signerCert.getEncoded(); > > Most likely `signerCert` is already a `X509CertImpl`. Updated to only do this line of code when it is not a `X509CertImpl`. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013: > >> 2011: } >> 2012: >> 2013: X509Certificate[] chain = new X509Certificate[1]; > > Since the chain might contain one, I'd suggest we just declare a `newCert` here. When signer flag is not on, we can simply get the chain with `new Certificate[] {newCert}`. Not sure the reason why a change is needed for the existing logic. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2025: > >> 2023: ("Generating.keysize.bit.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.validality.days.for")); >> 2024: if (groupName != null) { >> 2025: keysize = KeyUtil.getKeySize(privKey); > > Don't understand why `keysize` only needs to be calculated when there is no signer flag. In fact, we can just always use the `getKeySize` output below. For the no -signer case, calculating the `keysize` based on the `groupName` is the original logic, and `groupName` and `keysize` can not coexist. Updated the -signer case to do the same. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2043: > >> 2041: if (signerFlag) { >> 2042: Certificate[] signerChain = keyStore.getCertificateChain(signerAlias); >> 2043: Certificate[] tmpChain = new X509Certificate[signerChain.length + 1]; > > This is not a temp chain, it's the final chain. Renamed this variable name to `finalChain`. > src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 312: > >> 310: "Generating {0} bit {1} key pair and self-signed certificate ({2}) with a validity of {3} days\n\tfor: {4}"}, >> 311: {"Generating.keysize.bit.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.an.entry.specified.by.the.signer.option.with.a.validity.of.validality.days.for", >> 312: "Generating {0} bit {1} key pair and a certificate ({2}) issued by an entry specified by the -signer option with a validity of {3} days\n\tfor: {4}"}, > > How about printing out signer's alias? Added signer's alias to the message. > src/java.base/share/classes/sun/security/util/KeyUtil.java line 102: > >> 100: size = pubk.getParams().getP().bitLength(); >> 101: } else if (key instanceof XECKey) { >> 102: String name = ((NamedParameterSpec)((XECKey) key).getParams()).getName(); > > I hope the params is always `NamedParameterSpec` but would rather be safe to check instanceof first. Added the checking. > test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 230: > >> 228: } >> 229: >> 230: static void testSignerJKS() throws Exception { > > Please add some comments on why testing with JKS is necessary. Added the comments about JKS keystore. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 1 16:46:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 16:46:22 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 1 Apr 2021 16:25:13 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 114: >> >>> 112: } >>> 113: >>> 114: /** >> >> The original constructor can be modified to call `this(keyType,sigAlg,providerName,null,null)`. This is also a good time to modify `public CertAndKeyGen (String keyType, String sigAlg)` to call `this(keyType,sigAlg,null)`. Also please simplify the method javadoc. > > Updated the original constructor to call `this(keyType,sigAlg,providerName,null,null)` and its comment block. But leave another original constructor `public CertAndKeyGen (String keyType, String sigAlg)` unchanged, because it does not have `providerName` and `NoSuchProviderException` should not be declared like other constructors. You're right. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 1 16:52:29 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 16:52:29 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 1 Apr 2021 16:26:39 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013: >> >>> 2011: } >>> 2012: >>> 2013: X509Certificate[] chain = new X509Certificate[1]; >> >> Since the chain might contain one, I'd suggest we just declare a `newCert` here. When signer flag is not on, we can simply get the chain with `new Certificate[] {newCert}`. > > Not sure the reason why a change is needed for the existing logic. With a signer, it makes no sense to create a single-cert array at the beginning. I am suggesting: X509Certificate newCert = keypair.getSelfCertificate(...); Certificate[] finalChain; if (signerFlag) { finalChain = new ... finalChain[0] = newCert; } else { finalChain = new Certificate[] { newCert }; } keyStore.setEntry(..., finalChain); ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 1 16:56:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 16:56:33 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: <54YBxt9lpYQWPKQHbKrALY7yyKPPW6TnPt18xA2QxzE=.985b983d-532c-4b92-b165-67d70e948972@github.com> On Thu, 1 Apr 2021 16:34:43 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. >> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated with review comments src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 88: > 86: * constructor CertAndKeyGen(String keyType, String sigAlg, > 87: * String providerName, PrivateKey signerPrivateKey, > 88: * X500Name signerSubjectName) You can simply add a `@see #CertAndKeyGen(String, String, String, PrivateKey, X500Name)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 1 17:07:35 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 17:07:35 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: <6GXkBFJne0zTRyh92ouDWRUepg2RYQZTwzBmdG43H8s=.ae88d49c-d3c1-4df5-9da3-36ae43943d62@github.com> On Thu, 1 Apr 2021 16:34:43 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. >> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated with review comments src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 132: > 130: if (signerPrivateKey != null) { > 131: this.signerFlag = true; > 132: } If you make this line `this.sigerFlag = signerPrivateKey != null`, then we can make most field final. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 1 17:07:36 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 17:07:36 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 1 Apr 2021 16:25:49 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1941: >> >>> 1939: signerFlag = true; >>> 1940: >>> 1941: if (keyStore.containsAlias(signerAlias) == false) { >> >> It's probably more precise to make sure the entry is a `PrivateKeyEntry` because we have other entries like `TrustedCertificateEntry` and `SecretKeyEntry`. Or you can double check this below to ensure both `signerPrivateKey` and `signerCert` are non null. > > As `RecoveryKey()` will make sure if the entry exists in the keystore and is a `PrivateKeyEntry`, removed this checking and updated to check for if `signerCert` is null. Yes, it must be a private key entry. On the other hand, I think it's unnecessary to check about the `signerCert`. I don't think it'll be ever null. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From xuelei at openjdk.java.net Thu Apr 1 18:01:38 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 1 Apr 2021 18:01:38 GMT Subject: RFR: 8264606: More comment for ECDH public key validation Message-ID: <8TPaRmWNOkpFW63dVEvAAsF1hbNdxYUlhge8NJdKu14=.dc3630e5-d32f-414d-b743-b882be4106c3@github.com> Improve the readability by adding more comments in the ECDH public key validation implementation in JDK. ------------- Commit messages: - 8264606: More comment for ECDH public key validation Changes: https://git.openjdk.java.net/jdk/pull/3313/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264606 Stats: 25 lines in 1 file changed: 18 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3313/head:pull/3313 PR: https://git.openjdk.java.net/jdk/pull/3313 From jlaskey at openjdk.java.net Thu Apr 1 19:54:46 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 1 Apr 2021 19:54:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v41] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Fix NotCompliantCauseTest to not rely on Random not being a bean ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/5a23b4f1..c5fb77f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=40 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=39-40 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From hchao at openjdk.java.net Thu Apr 1 20:37:47 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 20:37:47 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v3] In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: <4MrKasWkS_Hw1H3cEzS5PxrZfImEQFxzDWgu2gnhHrE=.604ab8de-6de1-401f-b0f8-86f824fdde2a@github.com> > Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. > CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Updated with review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3281/files - new: https://git.openjdk.java.net/jdk/pull/3281/files/5d4d11cc..d63818ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=01-02 Stats: 26 lines in 2 files changed: 3 ins; 15 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3281/head:pull/3281 PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 1 20:37:54 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 20:37:54 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2] In-Reply-To: <54YBxt9lpYQWPKQHbKrALY7yyKPPW6TnPt18xA2QxzE=.985b983d-532c-4b92-b165-67d70e948972@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> <54YBxt9lpYQWPKQHbKrALY7yyKPPW6TnPt18xA2QxzE=.985b983d-532c-4b92-b165-67d70e948972@github.com> Message-ID: On Thu, 1 Apr 2021 16:53:31 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated with review comments > > src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 88: > >> 86: * constructor CertAndKeyGen(String keyType, String sigAlg, >> 87: * String providerName, PrivateKey signerPrivateKey, >> 88: * X500Name signerSubjectName) > > You can simply add a `@see #CertAndKeyGen(String, String, String, PrivateKey, X500Name)`. Done. > src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 132: > >> 130: if (signerPrivateKey != null) { >> 131: this.signerFlag = true; >> 132: } > > If you make this line `this.sigerFlag = signerPrivateKey != null`, then we can make most field final. Done, and no change to final. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 1 20:37:55 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 20:37:55 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v3] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: <3DjbfzCweyqp75zztp8h52ZdLBpNTvSzuidmvxYvyv0=.5300efe5-0df5-4420-96cb-7e08aa8297b4@github.com> On Thu, 1 Apr 2021 16:49:19 GMT, Weijun Wang wrote: >> Not sure the reason why a change is needed for the existing logic. > > With a signer, it makes no sense to create a single-cert array at the beginning. I am suggesting: > X509Certificate newCert = keypair.getSelfCertificate(...); > Certificate[] finalChain; > if (signerFlag) { > finalChain = new ... > finalChain[0] = newCert; > } else { > finalChain = new Certificate[] { newCert }; > } > keyStore.setEntry(..., finalChain); Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 1 21:40:26 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 1 Apr 2021 21:40:26 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v3] In-Reply-To: <4MrKasWkS_Hw1H3cEzS5PxrZfImEQFxzDWgu2gnhHrE=.604ab8de-6de1-401f-b0f8-86f824fdde2a@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> <4MrKasWkS_Hw1H3cEzS5PxrZfImEQFxzDWgu2gnhHrE=.604ab8de-6de1-401f-b0f8-86f824fdde2a@github.com> Message-ID: On Thu, 1 Apr 2021 20:37:47 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. >> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated with review comments src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 104: > 102: * key will be chosen after the first keypair is generated. > 103: * @param providerName name of the provider > 104: * @param signerPrivateKey signer's private key Add an "(optional)" or "can be null" to the last 2 `@param`s. src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 296: > 294: // Create a self-signed certificate, or a certificate that is signed by > 295: // a signer when the signer's private key is provided. > 296: public X509Certificate getSelfCertificate (X500Name myname, Date firstDate, It'a pity the method name still contains "self", but I'm OK to keep it as is. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1163: > 1161: } > 1162: doGenKeyPair(alias, dname, keyAlgName, keysize, groupName, sigAlgName, > 1163: signerAlias); Maybe we can just keep using the old argument list. `signerAlias` is a global variable and it's visible everywhere. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1927: > 1925: CertAndKeyGen keypair; > 1926: if (signerAlias != null) { > 1927: signerFlag = true; Is the `signerFlag` really useful? We can just check `signerAlias != null`. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1978: > 1976: } else { > 1977: certImpl = new X509CertImpl(signerCert.getEncoded()); > 1978: } The exact same 7 lines above also appears in the code change above. Is it possible to combine them? src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 310: > 308: "Generating {0} bit {1} key pair and self-signed certificate ({2}) with a validity of {3} days\n\tfor: {4}"}, > 309: {"Generating.keysize.bit.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.an.entry.signerAlias.specified.by.the.signer.option.with.a.validity.of.validality.days.for", > 310: "Generating {0} bit {1} key pair and a certificate ({2}) issued by an entry <{3}> specified by the -signer option with a validity of {4} days\n\tfor: {5}"}, A little too long? Can we remove the "specified by the -signer option" words or even the whole "issued by an entry <{3}> specified by the -signer option"? ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 1 21:40:26 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 21:40:26 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v3] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 1 Apr 2021 17:04:33 GMT, Weijun Wang wrote: >> As `RecoveryKey()` will make sure if the entry exists in the keystore and is a `PrivateKeyEntry`, removed this checking and updated to check for if `signerCert` is null. > > Yes, it must be a private key entry. On the other hand, I think it's unnecessary to check about the `signerCert`. I don't think it'll be ever null. Ok, removed this checking. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From christoph.langer at sap.com Thu Apr 1 21:49:49 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Apr 2021 21:49:49 +0000 Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE In-Reply-To: References: Message-ID: Hi Martin, looks good to me. Best regards Christoph From: Doerr, Martin Sent: Dienstag, 30. M?rz 2021 14:01 To: jdk-updates-dev ; security-dev Cc: Langer, Christoph Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Hi, JDK-8254631 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the javadoc parts don't compile with 11u. They are not compatible with 11u and are documented to be dropped in the CSR (linked below). As also documented in the CSR, the old behavior can get restored by specifying the property: jdk.tls.alpnCharset=UTF-8 Bug: https://bugs.openjdk.java.net/browse/JDK-8254631 Original change: https://git.openjdk.java.net/jdk/commit/fe5cccc1 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264177 11u backport: http://cr.openjdk.java.net/~mdoerr/8254631_ALPN_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From hchao at openjdk.java.net Thu Apr 1 23:29:33 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 23:29:33 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v3] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> <4MrKasWkS_Hw1H3cEzS5PxrZfImEQFxzDWgu2gnhHrE=.604ab8de-6de1-401f-b0f8-86f824fdde2a@github.com> Message-ID: <-fTQVdNvqq1MPbbJ4sn2UxOEVwC3DQ4dvAjohEqpJlo=.db51998e-1ab6-44cd-b3f3-55bfb2b0130d@github.com> On Thu, 1 Apr 2021 21:27:52 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated with review comments > > src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 104: > >> 102: * key will be chosen after the first keypair is generated. >> 103: * @param providerName name of the provider >> 104: * @param signerPrivateKey signer's private key > > Add an "(optional)" or "can be null" to the last 2 `@param`s. Done. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1163: > >> 1161: } >> 1162: doGenKeyPair(alias, dname, keyAlgName, keysize, groupName, sigAlgName, >> 1163: signerAlias); > > Maybe we can just keep using the old argument list. `signerAlias` is a global variable and it's visible everywhere. I'd prefer to have it. It is the same as other global arguments being passed to this method. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1927: > >> 1925: CertAndKeyGen keypair; >> 1926: if (signerAlias != null) { >> 1927: signerFlag = true; > > Is the `signerFlag` really useful? We can just check `signerAlias != null`. Sure, use `signerAlias` instead. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1978: > >> 1976: } else { >> 1977: certImpl = new X509CertImpl(signerCert.getEncoded()); >> 1978: } > > The exact same 7 lines above also appears in the code change above. Is it possible to combine them? Here is mainly to locate the signer?s SKID, and moved it up to the first occurrence of these lines of code to combine them. > src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 310: > >> 308: "Generating {0} bit {1} key pair and self-signed certificate ({2}) with a validity of {3} days\n\tfor: {4}"}, >> 309: {"Generating.keysize.bit.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.an.entry.signerAlias.specified.by.the.signer.option.with.a.validity.of.validality.days.for", >> 310: "Generating {0} bit {1} key pair and a certificate ({2}) issued by an entry <{3}> specified by the -signer option with a validity of {4} days\n\tfor: {5}"}, > > A little too long? Can we remove the "specified by the -signer option" words or even the whole "issued by an entry <{3}> specified by the -signer option"? Removed the "specified by the -signer option?, and keep the "issued by an entry <{3}>? that I agreed it?d be good to print out the signer?s alias in response to your previous review comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 1 23:36:04 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 1 Apr 2021 23:36:04 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: > Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. > CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: update with review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3281/files - new: https://git.openjdk.java.net/jdk/pull/3281/files/d63818ba..157601f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=02-03 Stats: 39 lines in 4 files changed: 7 ins; 19 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3281/head:pull/3281 PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Fri Apr 2 01:47:16 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 2 Apr 2021 01:47:16 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 1 Apr 2021 23:36:04 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. >> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > update with review comments Only a few minor comments. Approved. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1978: > 1976: keypair.getPublicKeyAnyway(), > 1977: signerSubjectKeyId); > 1978: } else { No need for an if-else block? `signerSubjectKeyId` is null in this case. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013: > 2011: x500Name}; > 2012: System.err.println(form.format(source)); > 2013: } Either put the declaration of `source` outside the if-else block and move the println line outside; or, move the declaration of `form` inside. It looks confusing that `form` is declared outside and `source` inside. src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 310: > 308: "Generating {0} bit {1} key pair and self-signed certificate ({2}) with a validity of {3} days\n\tfor: {4}"}, > 309: {"Generating.keysize.bit.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.an.entry.signerAlias.with.a.validity.of.validality.days.for", > 310: "Generating {0} bit {1} key pair and a certificate ({2}) issued by an entry <{3}> with a validity of {4} days\n\tfor: {5}"}, I feel "issued by <{3}>" sounds more normal. No need to say "an entry". You decide it. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Fri Apr 2 01:59:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 2 Apr 2021 01:59:18 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Fri, 2 Apr 2021 01:44:03 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> update with review comments > > Only a few minor comments. Approved. Maybe we don't need to resolve it in this code change. If we look carefully at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 is using the signer's SKID in 10.1 as its own SKID and it has no AKID. Currently, keytool will generate a new SKID and use signer's SKID as AKID. If we really want to generate a certificate that's identical to the one in the RFC, we'll need a way to tell keytool to omit the AKID (something like "-ext akid=none"). ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Fri Apr 2 02:06:32 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 2 Apr 2021 02:06:32 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Fri, 2 Apr 2021 01:56:15 GMT, Weijun Wang wrote: >> Only a few minor comments. Approved. > > Maybe we don't need to resolve it in this code change. If we look carefully at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 is using the signer's SKID in 10.1 as its own SKID and it has no AKID. Currently, keytool will generate a new SKID and use signer's SKID as AKID. If we really want to generate a certificate that's identical to the one in the RFC, we'll need a way to tell keytool to omit the AKID (something like "-ext akid=none"). A simple fix you can do this time although unrelated to the issue. `Main::createV3Extensions` shows a `@param akey` in spec but the actual argument name is `pkey`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From xuelei at openjdk.java.net Fri Apr 2 04:06:35 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 2 Apr 2021 04:06:35 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Fri, 2 Apr 2021 01:56:15 GMT, Weijun Wang wrote: > Maybe we don't need to resolve it in this code change. If we look carefully at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 is using the signer's SKID in 10.1 as its own SKID and it has no AKID. Currently, keytool will generate a new SKID and use signer's SKID as AKID. If we really want to generate a certificate that's identical to the one in the RFC, we'll need a way to tell keytool to omit the AKID (something like "-ext akid=none"). Better to use AKID for certification path building. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From xuelei at openjdk.java.net Fri Apr 2 04:14:44 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 2 Apr 2021 04:14:44 GMT Subject: RFR: 8264606: More comment for ECDH public key validation [v2] In-Reply-To: <8TPaRmWNOkpFW63dVEvAAsF1hbNdxYUlhge8NJdKu14=.dc3630e5-d32f-414d-b743-b882be4106c3@github.com> References: <8TPaRmWNOkpFW63dVEvAAsF1hbNdxYUlhge8NJdKu14=.dc3630e5-d32f-414d-b743-b882be4106c3@github.com> Message-ID: > Improve the readability by adding more comments in the ECDH public key validation implementation in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: typo correct of unmapable character in the comment line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3313/files - new: https://git.openjdk.java.net/jdk/pull/3313/files/04d7e1cc..11c2bcdf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3313&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3313&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3313/head:pull/3313 PR: https://git.openjdk.java.net/jdk/pull/3313 From xuelei.fan at oracle.com Fri Apr 2 05:24:03 2021 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 2 Apr 2021 05:24:03 +0000 Subject: [External] : Re: Request for comment: the session ticket protection scheme for distributed TLS sessions. In-Reply-To: References: Message-ID: <82C3CCE0-CF92-4D6A-9A7A-27BD78A8AC3B@oracle.com> Thank you Daniel for the comment. All are great points. > On Mar 17, 2021, at 1:56 AM, Daniel Jeli?ski wrote: > > Hi Xuelei, > I reviewed the RFC above (I hope I'm not too late!) and have some > concerns about the security properties of the proposed solution. > Essentially they would apply to all schemes using session ticket > encryption keys derived from a long-lived secret. > I understand the concerns completely. It is really a compromising solution so as to simplify the TLS session distribution problems. > How does this apply to TLS versions before 1.3? My understanding is > that deriving session ticket encryption keys from a long-term secret > immediately forfeits all forward secrecy in all versions of TLS before > 1.3. This also applies to TLS 1.3 when psk_ke is used. > Unfortunately, there is no forward secrecy benefits for TLS 1.2 and psk_ke for TLS 1.3. For TLS 1.2 and psk_ke, new distributed keying materials should be introduced for forward secrecy benefits. I will consider an improvement here. > How are we going to ensure Key Compromise Impersonation (KCI) > resistance (defined in [1])? Will it be possible for an attacker to > spoof peer certificates in a session ticket if he gains access to our > long-term secret? > Sorry for the delayed response. It took me a while to understand the impact of KCI. As far as I could understand, the KCI resistance is at the same level as the one-client-one-server mode connections, if we design and validate the session ticket carefully. > I didn't find answers in the JEP or in the CSR, so I thought I'd ask here. Thank you for the comments, which definitely help me a lot. Xuelei > Thanks, > Daniel > > [1] https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8446*appendix-E.1__;Iw!!GqivPVa7Brio!Jn80lostzwxXdApD87mhqhgrhjD3mUdQL6a_wTCxBdBZrJXI5OiS-q8mRQi4EltR$ > > czw., 29 pa? 2020 o 04:41 Xue-Lei Fan napisa?(a): >> >> The PNG may be too large to open from some mail system. Here is the PDF version. BTW, I also made an update on the use of AEAD algorithm with additional data. >> >> Thanks, >> Xuelei >> >> >>> On Oct 23, 2020, at 8:58 AM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> I'm working on the JEP to improve the scalability and throughput of the TLS implementation, by supporting distributed session resumption across clusters of computers. >>> >>> TLS session tickets will used for session resumption in a cluster. To support distributed session resumption, a session ticket that is generated and protected in one server node must be usable for session resumption on other server nodes in the distributed system. Each node should use the same session ticket structure, and share the secrets that are used to protect session tickets. More details, please refer to the JEP: >>> https://bugs.openjdk.java.net/browse/JDK-8245551 >>> >>> It is a essential part of the implementation that we need to define a session ticket protection scheme. The scheme will support key generation, key rotation and key synchronization across clusters of computers. >>> >>> The attached doc_distributed_credential_protection.md is a markdown file, which may not easy to read. So I attached a rendered picture as well. >>> >>> Please let me know if you have any concerns. Any comments are welcome. >>> >>> Thanks, >>> Xuelei >>> >> From github.com+30433125+djelinski at openjdk.java.net Fri Apr 2 06:40:28 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Fri, 2 Apr 2021 06:40:28 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding In-Reply-To: References: Message-ID: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> On Wed, 31 Mar 2021 21:47:24 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. > > thanks > > Tony src/java.base/share/classes/sun/security/rsa/RSACore.java line 66: > 64: // like performance testing. > 65: private static final Map> > 66: blindingCache = new WeakHashMap<>(); I'd use a synchronizedMap here now ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From weijun at openjdk.java.net Fri Apr 2 11:55:21 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 2 Apr 2021 11:55:21 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Fri, 2 Apr 2021 04:03:50 GMT, Xue-Lei Andrew Fan wrote: >> Maybe we don't need to resolve it in this code change. If we look carefully at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 is using the signer's SKID in 10.1 as its own SKID and it has no AKID. Currently, keytool will generate a new SKID and use signer's SKID as AKID. If we really want to generate a certificate that's identical to the one in the RFC, we'll need a way to tell keytool to omit the AKID (something like "-ext akid=none"). > >> Maybe we don't need to resolve it in this code change. If we look carefully at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 is using the signer's SKID in 10.1 as its own SKID and it has no AKID. Currently, keytool will generate a new SKID and use signer's SKID as AKID. If we really want to generate a certificate that's identical to the one in the RFC, we'll need a way to tell keytool to omit the AKID (something like "-ext akid=none"). > > Better to use AKID for certification path building. I don't mean we will remove it by default. Just think there needs a way to remove either AKID or SKID, because we always generate them automatically. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From mullan at openjdk.java.net Fri Apr 2 12:21:28 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 2 Apr 2021 12:21:28 GMT Subject: RFR: 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:02:33 GMT, Weijun Wang wrote: > These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3266 From wetmore at openjdk.java.net Fri Apr 2 14:45:22 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 2 Apr 2021 14:45:22 GMT Subject: RFR: 8264606: More comment for ECDH public key validation [v2] In-Reply-To: References: <8TPaRmWNOkpFW63dVEvAAsF1hbNdxYUlhge8NJdKu14=.dc3630e5-d32f-414d-b743-b882be4106c3@github.com> Message-ID: On Fri, 2 Apr 2021 04:14:44 GMT, Xue-Lei Andrew Fan wrote: >> Improve the readability by adding more comments in the ECDH public key validation implementation in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > typo correct of unmapable character in the comment line Marked as reviewed by wetmore (Reviewer). src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 164: > 162: } > 163: > 164: // Check whether a public key is valid, following the ECC Coding conventions used to be /* */ for method description and multiline comments. Otherwise, this work is much appreciated for any maintainers. ------------- PR: https://git.openjdk.java.net/jdk/pull/3313 From xuelei at openjdk.java.net Fri Apr 2 15:26:28 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 2 Apr 2021 15:26:28 GMT Subject: Integrated: 8264606: More comment for ECDH public key validation In-Reply-To: <8TPaRmWNOkpFW63dVEvAAsF1hbNdxYUlhge8NJdKu14=.dc3630e5-d32f-414d-b743-b882be4106c3@github.com> References: <8TPaRmWNOkpFW63dVEvAAsF1hbNdxYUlhge8NJdKu14=.dc3630e5-d32f-414d-b743-b882be4106c3@github.com> Message-ID: On Thu, 1 Apr 2021 17:53:47 GMT, Xue-Lei Andrew Fan wrote: > Improve the readability by adding more comments in the ECDH public key validation implementation in JDK. This pull request has now been integrated. Changeset: 177bc84f Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/177bc84f Stats: 25 lines in 1 file changed: 18 ins; 1 del; 6 mod 8264606: More comment for ECDH public key validation Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/3313 From xuelei at openjdk.java.net Fri Apr 2 16:45:43 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 2 Apr 2021 16:45:43 GMT Subject: RFR: 8264554: X509KeyManagerImpl calls getProtectionParameter with incorrect alias Message-ID: In X509KeyManagerImpl.java, a composited entry alias consists three parts: an UID counter, a builder index and the real entry alias (See the makeAlias() method). While calling the KeyStore.Builder.getProtectionParameter(String alias) method, the real entry alias should be used instead, rather than the composited entry alias. Simple and straightforward update, no new regression test. ------------- Commit messages: - 8264554: X509KeyManagerImpl calls getProtectionParameter with incorrect alias Changes: https://git.openjdk.java.net/jdk/pull/3326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264554 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3326/head:pull/3326 PR: https://git.openjdk.java.net/jdk/pull/3326 From sspitsyn at openjdk.java.net Fri Apr 2 17:17:24 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 2 Apr 2021 17:17:24 GMT Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception chaining In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote: > 8264148: Update spec for exceptions retrofitted for exception chaining Joe, The Serviceability part looks good. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/3182 From ascarpino at openjdk.java.net Fri Apr 2 17:31:24 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 2 Apr 2021 17:31:24 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 15:51:55 GMT, Jamil Nimeh wrote: >> Hi, >> >> I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/rsa/RSACore.java line 414: > >> 412: if (!u.equals(BigInteger.ZERO) && >> 413: !v.equals(BigInteger.ZERO)) { >> 414: > > Is it ever possible that u could be equal to BigInteger.ZERO? The only place I see a new BlindingRandomPair created is within the scope of the BlindingParameters object, and it has a guard in its constructor that resets u to BigInteger.ONE if u is zero. Or is this check to guard against the reset of u/v down around line 416-419 (recalculated when reusable)? The both values are never zero now as the old code used zero to define the parameters needed to be reset. I don't think this zero check is necessary.. let me try something else that fits with the isReusable() here and the one below when putting it into the queue ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From ascarpino at openjdk.java.net Fri Apr 2 17:48:25 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 2 Apr 2021 17:48:25 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding In-Reply-To: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> References: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> Message-ID: On Fri, 2 Apr 2021 06:36:57 GMT, djelinski wrote: >> Hi, >> >> I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/rsa/RSACore.java line 66: > >> 64: // like performance testing. >> 65: private static final Map> >> 66: blindingCache = new WeakHashMap<>(); > > I'd use a synchronizedMap here now Using a synchronizedMap would only let one thread access the hashmap at a time, which is what I'm trying to reduce. Get ops do not need to be locked and put ops don't either because the values are objects of random data, losing one is not significant to the operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From dcubed at openjdk.java.net Fri Apr 2 18:16:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 18:16:41 GMT Subject: Integrated: 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 Message-ID: A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 ------------- Commit messages: - 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 Changes: https://git.openjdk.java.net/jdk/pull/3328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264656 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3328/head:pull/3328 PR: https://git.openjdk.java.net/jdk/pull/3328 From rriggs at openjdk.java.net Fri Apr 2 18:16:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 2 Apr 2021 18:16:41 GMT Subject: Integrated: 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 18:04:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on linux-x64 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3328 From dcubed at openjdk.java.net Fri Apr 2 18:16:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 18:16:41 GMT Subject: Integrated: 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 In-Reply-To: References: Message-ID: <9wJi85TZw20AZh6Ir0lhbStDdNKkzri-oQO6NLSPIs4=.3974f494-a578-4043-8d3c-8507be8c5446@github.com> On Fri, 2 Apr 2021 18:09:48 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java >> on linux-x64 > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the blazingly fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3328 From dcubed at openjdk.java.net Fri Apr 2 18:16:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Apr 2021 18:16:42 GMT Subject: Integrated: 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 In-Reply-To: References: Message-ID: <-O0DJM0hHD_NxmMXROVSDkLZ7bA29_S94sTyWHhDNTk=.aa9911fe-689c-4525-9f5b-eeef07507d7f@github.com> On Fri, 2 Apr 2021 18:04:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on linux-x64 This pull request has now been integrated. Changeset: d0f3cc92 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/d0f3cc92 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8264656: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on linux-x64 Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/3328 From ascarpino at openjdk.java.net Fri Apr 2 19:56:58 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 2 Apr 2021 19:56:58 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v2] In-Reply-To: References: Message-ID: > Hi, > > I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: Better handle the comparing of ONE and ZERO ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3296/files - new: https://git.openjdk.java.net/jdk/pull/3296/files/3b054789..e948ecac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=00-01 Stats: 13 lines in 1 file changed: 1 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3296/head:pull/3296 PR: https://git.openjdk.java.net/jdk/pull/3296 From github.com+30433125+djelinski at openjdk.java.net Fri Apr 2 20:55:30 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Fri, 2 Apr 2021 20:55:30 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v2] In-Reply-To: References: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> Message-ID: On Fri, 2 Apr 2021 17:45:45 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/rsa/RSACore.java line 66: >> >>> 64: // like performance testing. >>> 65: private static final Map> >>> 66: blindingCache = new WeakHashMap<>(); >> >> I'd use a synchronizedMap here now > > Using a synchronizedMap would only let one thread access the hashmap at a time, which is what I'm trying to reduce. Get ops do not need to be locked and put ops don't either because the values are objects of random data, losing one is not significant to the operation. According to SO, unsynchronized writes to a map can lead to lock up, see here: https://stackoverflow.com/a/1003237 Or here: https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html?m=1 What's the performance impact of adding synchronization on the hash map only? ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From mathiske at amazon.com Fri Apr 2 20:21:51 2021 From: mathiske at amazon.com (Mathiske, Bernd) Date: Fri, 2 Apr 2021 20:21:51 +0000 Subject: Defer disabling TLS 1.0/1.1 by default? Message-ID: We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now. Can this default configuration change be deferred in general?? Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default?? Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date? My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct? We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur. (sent to jdk-updates-dev@, jdk8u-dev@, and security-dev@) Bernd From colm at apache.org Fri Apr 2 21:15:58 2021 From: colm at apache.org (=?UTF-8?Q?Colm_MacC=C3=A1rthaigh?=) Date: Fri, 2 Apr 2021 14:15:58 -0700 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: References: Message-ID: I'm a mere Java user and developer, I'm not a JDK person. I'm also only on jdk-updates-dev, so if this message ended up in mod-queues, apologies! I'm replying as a TLS person. I work at AWS too, leading our TLS work, and we took a look at this as part of the upcoming changes for Amazon Corretto. The short version is this: we think about 1% of applications and traffic "out there" are still using TLS1.0/TLS1.1. Given where browsers are at, I think this percentage is an under-estimate of the usage on Java applications - I suspect it's even higher there. When we dig in with customers "Why are you still using TLS1.0 or TLS1.1" the most common reasons are legacy appliances and applications. Think of hardware load balancers that were never updated, or can't be, to support TLS1.2 or better. Compliance mandated traffic inspection devices that force TLS1.0 in certain industries are another reason. For these applications, the change will break them, and they'll get a low-level exception. The users can re-enable TLS1.0 and TLS1.1, but they may suffer an outage because they likely weren't expecting a breaking change low in the networking stack. Retiring TLS1.0 and TLS1.1 is worthy, but I'd suggest that doing it in one pass is premature right now. The browsers are each at different degrees of support, some have "nuisance" warnings, some have no warnings at all. They've all punted a few times on when TLS1.0 and TLS1.1 may be hard disabled, but so far it's available in some form in all of them. I don't know of any other programming language (e.g. Go, Python, etc) that's doing something similar either. I tend to be an absolute paranoid zealot about security, but I don't lose sleep terribly over the issues that are in TLS1.0 and TLS1.1. I do want to retire the protocols ... but ideally without breaking anyone. If there's a way instead to do multiple passes and ship a JDK that measures TLS1.0 and TLS1.1 usage - as the browsers do - I'd love that. Then I could work with users to identify workloads where they are relying on TLS1.0 as a last resort and be proactive about the change. This doesn't have to be spyware phone-home measurements, even a local counter would be valuable. When we make these kinds of changes to AWS services, we go through a similar process: we see who is still using the old protocols and reach out to customers to work with them to update and ensure they won't be impacted. OpenJDK isn't a managed service, but we could help consumers help themselves at least. Since it will likely come up - here's a summary of the known security issues that are in TLS1.0 and TLS1.1: 1. The BEAST attack, which is in TLS1.0 only. The BEAST attack is a sophisticated attack that utilizes both active traffic interception and manipulation of retries and responses to Browsers (the ?B? in BEAST stands for ?Browser?). In general, it?s not the kind of attack that Java applications are vulnerable to.Even so, OpenJDK actually includes mitigations for the BEAST attack, but the "other" side of a TLS connection may not. 2. The SHA1/MD5 Transcript hash. To ensure that a sender or receiver isn?t being tricked by any kind of attacker in the middle, TLS uses a secure record of all the data sent and received called a transcript hash. In TLSv1.0 and TLSv1.1 this hash uses either a novel combination of the MD5 and SHA1 algorithms, or the SHA1 algorithm alone. Both MD5 and SHA1 are considered broken. In Cryptography we like to have extremely generous security margins, and the bar for what is considered ?broken? and what is actually practical are often very different. In this case, researchers estimate that it takes about 150 trillion trillion (that?s 150 trillion, times a trillion) operations to brute-force a TLSv1.0 or TLSv1.1 transcript hash. These hashes aren?t fixed, like the hashes on a certificate, they are unique to every SSL/TLS session. To use this weakness an attacker first has to intercept all communications between the sender and receiver. They put themselves in the middle. Then, during the handshake, the attacker must perform 150 trillion trillion operations to ?crack? the hash before allowing either side to proceed past the handshake. This also must happen without either side timing out or noticing the delay. Advanced dedicated SHA1 crackers can crack approximately 100 billion SHA1 hashes per second per processor. Even with these devices, it would take about fifty thousand processor years to crack a single TLS transcript hash. Performing the attack within 30 seconds would require over 500 million such devices operating in parallel. There are also no commercial devices capable of targeting the novel MD5/SHA1 combination, which is much more typical in TLSv1.0 and TLSv1.1. In short, cryptographers are rightly concerned about this issue. Processors will only get faster, and at some point, this attack may fall within the capabilities of large actors such as nation states and organized crime. But this issue is not a serious risk or threat for most java applications. 3. TLS1.0 and TLS1.1 support only the CBC ciphers which are vulnerable to Lucky13 and Sweet32. Turning off TLS1.0 and TLS1.1 actually doesn't fully mitigate these - these ciphers can be used over TLS1.2 also. But TLS1.2 does have better alternatives (e.g. AES-GCM). Lucky13 isn't a practical attack against TLS, even in extremely favorable circumstances for an attacker. Regardless, OpenJDK includes mitigations and uses a constant-time padding algorithm which is what matters. That leaves Sweet32, which is specific to 3DES. This issue impacts applications that send very large amounts of data, and again requires an active interception from an attacker. Many large websites with great security teams continue to maintain 3DES as a last-resort for compatibility with legacy systems, and I can see the reasoning. Other background: My experience is that many Java applications use TLS for confidentiality, but often do not consider traffic interception important in their threat model. It's very common to see self-signed certificates being used, for example, which make any application vulnerable to interception. The kinds of places where TLS1.0 and TLS1.1 are still used tend by their nature to be private networks that have other security controls in place. There are no TLS1.0 or TLS1.1 differences relating to how certificates are handled. OpenJDK is also immune to downgrade attacks. An attacker can't make it choose TLS1.0 or 1.1 if the other end supports TLS1.2 or better. On the whole, with all of those trade-offs in balance, it feels risky to me to disable TLS1.0 and TLS1.1 right now. To be clear though: it is better to use TLS1.2 than to use TLS1.0 and TLS1.1, and I'm very glad that OpenJDK does it right. People should fix or remove those legacy appliances in their networks, and I know customers that are. We all know that attacks only improve over time. But I don't think there's quite any clearly exploitable or very concerning issue that rises to the level of "this shouldn't even be supported in the language right now". I also don't see it as a few "bad" users out there holding back the rest of us. Keeping TLS1.0 and TLS1.1 in the default set in no way prevents applications from using TLS1.2 or better. But opinions can differ here. Others may prefer to be more forceful with changes and to take on a mission of clearing cruft faster. We've been having internal discussions about this and wanted to bring it here to the community and be open about it. On Fri, Apr 2, 2021 at 1:22 PM Mathiske, Bernd wrote: > > We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now. > > Can this default configuration change be deferred in general? > > Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default? > > Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date? > > My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct? > > We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur. > > (sent to jdk-updates-dev@, jdk8u-dev@, and security-dev@) > > Bernd > > -- Colm From weijun at openjdk.java.net Fri Apr 2 22:04:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 2 Apr 2021 22:04:19 GMT Subject: Withdrawn: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 21:36:21 GMT, Weijun Wang wrote: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From ascarpino at openjdk.java.net Fri Apr 2 23:15:22 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 2 Apr 2021 23:15:22 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v2] In-Reply-To: References: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> Message-ID: On Fri, 2 Apr 2021 20:52:42 GMT, djelinski wrote: >> Using a synchronizedMap would only let one thread access the hashmap at a time, which is what I'm trying to reduce. Get ops do not need to be locked and put ops don't either because the values are objects of random data, losing one is not significant to the operation. > > According to SO, unsynchronized writes to a map can lead to lock up, see here: > https://stackoverflow.com/a/1003237 > Or here: > https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html?m=1 > What's the performance impact of adding synchronization on the hash map only? Ok, thanks for pointing that out, I didn't realize that limitation. However using synchronizedMap is overkill as it locks every operation. As I read it, only structural changes like adding and removing keys from the map causes problems. Getting a value from the map does not. Therefore I would only need to synchronize the putIfAbsent() at 449, which is pretty minor. The expunging of the map is already synchronized in WeakHashMap. The original code was half the performance of this one. ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From github.com+592810+efge at openjdk.java.net Sat Apr 3 01:10:17 2021 From: github.com+592810+efge at openjdk.java.net (Florent Guillaume) Date: Sat, 3 Apr 2021 01:10:17 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v2] In-Reply-To: References: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> Message-ID: On Fri, 2 Apr 2021 23:12:21 GMT, Anthony Scarpino wrote: >> According to SO, unsynchronized writes to a map can lead to lock up, see here: >> https://stackoverflow.com/a/1003237 >> Or here: >> https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html?m=1 >> What's the performance impact of adding synchronization on the hash map only? > > Ok, thanks for pointing that out, I didn't realize that limitation. However using synchronizedMap is overkill as it locks every operation. As I read it, only structural changes like adding and removing keys from the map causes problems. Getting a value from the map does not. Therefore I would only need to synchronize the putIfAbsent() at 449, which is pretty minor. The expunging of the map is already synchronized in WeakHashMap. > > The original code was half the performance of this one. If you synchronize `putIfAbsent` but not `get` you'll still get the possible infinite loop described in the SO post. ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From github.com+30433125+djelinski at openjdk.java.net Sat Apr 3 05:43:37 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Sat, 3 Apr 2021 05:43:37 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v2] In-Reply-To: References: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> Message-ID: On Sat, 3 Apr 2021 01:06:50 GMT, Florent Guillaume wrote: >> Ok, thanks for pointing that out, I didn't realize that limitation. However using synchronizedMap is overkill as it locks every operation. As I read it, only structural changes like adding and removing keys from the map causes problems. Getting a value from the map does not. Therefore I would only need to synchronize the putIfAbsent() at 449, which is pretty minor. The expunging of the map is already synchronized in WeakHashMap. >> >> The original code was half the performance of this one. > > If you synchronize `putIfAbsent` but not `get` you'll still get the possible infinite loop described in the SO post. Expunging entries is synchronized over an internal data structure, so if you synchronize puts only, nothing prevents expunge (called from get) from running in parallel with put. The original code performed big integer exponentiation inside a synchronized block, your code doesn't. I expect substantial performance gains even with synchronization around hash map access, this is why I asked about performance. ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From martin.doerr at sap.com Sat Apr 3 14:11:55 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Sat, 3 Apr 2021 14:11:55 +0000 Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review and the approval! Best regards, Martin From: Langer, Christoph Sent: Donnerstag, 1. April 2021 23:50 To: Doerr, Martin ; jdk-updates-dev ; security-dev Subject: RE: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Hi Martin, looks good to me. Best regards Christoph From: Doerr, Martin > Sent: Dienstag, 30. M?rz 2021 14:01 To: jdk-updates-dev >; security-dev > Cc: Langer, Christoph > Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE Hi, JDK-8254631 is backported to 11.0.12-oracle. I'd like to backport it for parity. It applies cleanly, but the javadoc parts don't compile with 11u. They are not compatible with 11u and are documented to be dropped in the CSR (linked below). As also documented in the CSR, the old behavior can get restored by specifying the property: jdk.tls.alpnCharset=UTF-8 Bug: https://bugs.openjdk.java.net/browse/JDK-8254631 Original change: https://git.openjdk.java.net/jdk/commit/fe5cccc1 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264177 11u backport: http://cr.openjdk.java.net/~mdoerr/8254631_ALPN_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+829871+salusasecondus at openjdk.java.net Sat Apr 3 15:35:32 2021 From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin) Date: Sat, 3 Apr 2021 15:35:32 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: References: Message-ID: On Sat, 27 Mar 2021 00:25:09 GMT, Valerie Peng wrote: >> This change updates SunJCE provider as below: >> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. >> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. >> >> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. >> >> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Refactor code to reduce code duplication > Address review comments > Add more test vectors I'd advise against the AutoPadding scheme without more careful analysis and discussion. Have we seen either KW or KWP specifications which recommend that behavior? My concern is that we've seen cases before where two different cryptographic algorithms could be selected transparently upon decryption and it lowers the security of the overall system. (A variant of in-band signalling.) The general consensus that I've been seeing in the (applied) cryptographic community is strongly away from in-band signalling and towards the decryptor fully specifying the algorithms and behavior prior to attempting decryption. src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 71: > 69: match &= (ivAndLen[i] == iv[i]); > 70: } > 71: if (!match) { True nitpick (thus ignorable): I believe that using bitwise math is slightly more resistant to compiler and/or CPU optimization to defend against timing-attacks. (Since I haven't even seen an attack against KW or KWP, this is simply a note in general rather than something which needs to be fixed.) src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 78: > 76: for (int k = 5; k < SEMI_BLKSIZE; k++) { > 77: if (outLen != 0) { > 78: outLen <<= SEMI_BLKSIZE; While technically, this is correct (as it is shifting by 8 bits), it is pure coincidence that `SEMI_BLKSIZE` (8 bytes) happens to have the name integer value as the number of bits in one byte. It took me more reads than I care to admit to understand why this worked. Could we just replace this one with an `8` as it is clearer and more accurate? ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From github.com+76791+alblue at openjdk.java.net Sat Apr 3 22:17:51 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sat, 3 Apr 2021 22:17:51 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security Message-ID: 8264681: Use the blessed modifier order in java.security ------------- Commit messages: - 8264681: Use the blessed modifier order in java.security Changes: https://git.openjdk.java.net/jdk/pull/3338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264681 Stats: 162 lines in 55 files changed: 0 ins; 0 del; 162 mod Patch: https://git.openjdk.java.net/jdk/pull/3338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3338/head:pull/3338 PR: https://git.openjdk.java.net/jdk/pull/3338 From mstjohns at comcast.net Sat Apr 3 23:36:25 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 3 Apr 2021 19:36:25 -0400 Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: References: Message-ID: <6376950b-8e3c-6df6-b70d-8791ae7f0b1f@comcast.net> On 4/3/2021 11:35 AM, Greg Rubin wrote: > I'd advise against the AutoPadding scheme without more careful analysis and discussion. Have we seen either KW or KWP specifications which recommend that behavior? > > My concern is that we've seen cases before where two different cryptographic algorithms could be selected transparently upon decryption and it lowers the security of the overall system. (A variant of in-band signalling.) The general consensus that I've been seeing in the (applied) cryptographic community is strongly away from in-band signalling and towards the decryptor fully specifying the algorithms and behavior prior to attempting decryption. I think this is in response to my comment? The wrap function can take a Key as an input and can have the unwrap method produce a Key as an output - indeed it should be used primarily for this rather than the more general encrypt/decrypt functions.? The problem is that the encoding of the key may not be known prior to the attempt to wrap it - hence it's not known whether or not padding need be applied.? This is especially problematic with HSMs.? Providing an AutoPadding mode would allow the wrapping algorithm to decide whether to use either of the RFC 3394 (AKA KW) Integrity Check Value (ICV) or the RFC5649 (aka KWP) value and padding length. The key thing to remember here is that the IV (initial value - RFC language) /ICV (integrity check value - NIST language)actually isn't an IV(initialization vector) in the ordinary meaning, it's a flag, padding and integrity indicator and will be fixed for all keys of the same length that use the specified values.?? E.g. unlike other modes that require an initialization vector, you don't need to know the ICV to decrypt the underlying key stream, but you can? (and for that matter MUST) easily test the recovered first block against the expected ICV to determine whether the output needs padding removed or not. FWIW, the actual cryptographic operations between padded data and non-padded data (of the right multiple length) are identical. It's only the pre or post processing that's looking for different data. Obviously, this doesn't work if someone provides their own IV - but that's fairly unlikely.? CF CCM and its non-normative example formatting function appendix A -? each and every implementation I've seen uses that formatting function, even though it isn't actually required by the standard.? I'd be surprised if anyone decided to use a different set of non-standard IV values. If an AutoPadding mode were implemented, I'd throw exceptions if someone tried to set the IV. Later, Mike From jlaskey at openjdk.java.net Mon Apr 5 14:20:56 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 5 Apr 2021 14:20:56 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v42] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: - Merge branch 'master' into 8248862 - Fix NotCompliantCauseTest to not rely on Random not being a bean - Merge branch 'master' into 8248862 - Correct return type of RandomGeneratorFactory.of - Merge branch 'master' into 8248862 - CSR review revisions - CSR review updates - Removed @since from nextDouble ThreadLocalRandom - RandomGeneratorFactory::all(Class category) @implNote was out of date - Clarify all() - ... and 68 more: https://git.openjdk.java.net/jdk/compare/a8005efd...ffd982b0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=41 Stats: 12973 lines in 27 files changed: 11202 ins; 1590 del; 181 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Mon Apr 5 16:32:36 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 5 Apr 2021 16:32:36 GMT Subject: Integrated: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 13:45:12 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 This pull request has now been integrated. Changeset: a0ec2cb2 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/a0ec2cb2 Stats: 12973 lines in 27 files changed: 11202 ins; 1590 del; 181 mod 8248862: Implement Enhanced Pseudo-Random Number Generators Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From rhalade at openjdk.java.net Mon Apr 5 18:08:08 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 5 Apr 2021 18:08:08 GMT Subject: RFR: 8264190: Harden TLS interop tests [v4] In-Reply-To: References: Message-ID: <4XwZCEeOBjrDMWiHwGB12RiWDNJ4CtdiPIK5qdf1lp0=.0a148f0c-fa73-4a1b-aebf-d53b41c97fad@github.com> On Wed, 31 Mar 2021 10:53:34 GMT, Fernando Guallini wrote: >> Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server. >> >> In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > add max_retries count, move shell methods to ProcUtils and add win methods Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3218 From ascarpino at openjdk.java.net Mon Apr 5 21:18:28 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 5 Apr 2021 21:18:28 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v2] In-Reply-To: References: <-DtksChD3MjWQXdhk4g-g3iR6B1sFSQhnre5HhRqdBo=.87dd1ec7-e07f-4be5-9cb1-9832b8d76d33@github.com> Message-ID: On Sat, 3 Apr 2021 05:40:11 GMT, djelinski wrote: >> If you synchronize `putIfAbsent` but not `get` you'll still get the possible infinite loop described in the SO post. > > Expunging entries is synchronized over an internal data structure, so if you synchronize puts only, nothing prevents expunge (called from get) from running in parallel with put. > The original code performed big integer exponentiation inside a synchronized block, your code doesn't. I expect substantial performance gains even with synchronization around hash map access, this is why I asked about performance. I finally see that get() is affected by the locking. Expunge seems to not lock the able which could cause multiple threads get ops to corrupt the map. I'll put a ReentrantLock around the put & get. I prefer to not use synchronized() blocks as ReentrantLock maybe better after Project Loom Sure, the performance was largely affected by the math ops in the old code. I wanted to eliminate as much of the performance decelerators as possible ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From xuelei at openjdk.java.net Mon Apr 5 23:49:08 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 5 Apr 2021 23:49:08 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 20:52:57 GMT, Xue-Lei Andrew Fan wrote: > As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. > > The handshake status could have more precise status if the out bound. The patch was confirmed by the bug submitter. ping ... ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From xuelei at openjdk.java.net Mon Apr 5 23:50:26 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 5 Apr 2021 23:50:26 GMT Subject: RFR: 8264554: X509KeyManagerImpl calls getProtectionParameter with incorrect alias In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:38:14 GMT, Xue-Lei Andrew Fan wrote: > In X509KeyManagerImpl.java, a composited entry alias consists three parts: an UID counter, a builder index and the real entry alias (See the makeAlias() method). While calling the KeyStore.Builder.getProtectionParameter(String alias) method, the real entry alias should be used instead, rather than the composited entry alias. > > Simple and straightforward update, no new regression test. ping ... ------------- PR: https://git.openjdk.java.net/jdk/pull/3326 From ascarpino at openjdk.java.net Tue Apr 6 04:26:58 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Apr 2021 04:26:58 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v3] In-Reply-To: References: Message-ID: > Hi, > > I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: Use ReentrantLock for put and get ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3296/files - new: https://git.openjdk.java.net/jdk/pull/3296/files/e948ecac..dda3ed69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=01-02 Stats: 21 lines in 1 file changed: 9 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3296/head:pull/3296 PR: https://git.openjdk.java.net/jdk/pull/3296 From github.com+30433125+djelinski at openjdk.java.net Tue Apr 6 07:32:26 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Tue, 6 Apr 2021 07:32:26 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 04:26:58 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > Use ReentrantLock for put and get src/java.base/share/classes/sun/security/rsa/RSACore.java line 443: > 441: lock.lock(); > 442: try { > 443: queue = blindingCache.get(n); Suggestion: queue = blindingCache.computeIfAbsent(n, ignored -> new ConcurrentLinkedQueue<>()); ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From mullan at openjdk.java.net Tue Apr 6 14:11:25 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 6 Apr 2021 14:11:25 GMT Subject: RFR: 8264554: X509KeyManagerImpl calls getProtectionParameter with incorrect alias In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:38:14 GMT, Xue-Lei Andrew Fan wrote: > In X509KeyManagerImpl.java, a composited entry alias consists three parts: an UID counter, a builder index and the real entry alias (See the makeAlias() method). While calling the KeyStore.Builder.getProtectionParameter(String alias) method, the real entry alias should be used instead, rather than the composited entry alias. > > Simple and straightforward update, no new regression test. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3326 From mbalao at openjdk.java.net Tue Apr 6 14:29:36 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 14:29:36 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 20:51:26 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 265: > >> 263: // NSS requires block-sized updates in multi-part operations. >> 264: reqBlockUpdates = ((tokenLabel[0] == 'N' && tokenLabel[1] == 'S' >> 265: && tokenLabel[2] == 'S') ? true : false); > > IIRC, depending on how the impl is registered, engineSetPadding(String) may not always be called. It's probably safer to set this in engineInit(...)? Looks to me that engineSetPadding is always called from the P11Cipher constructor. I thought that was a good location to set the reqBlockUpdates variable because it's next to the paddingObj initialization; which is a pre-requisite for reqBlockUpdates to be used. In other words, if we have no Java-side padding (paddingObj == null), reqBlockUpdates won't be used and we don't even pay the price of setting it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 14:51:19 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 14:51:19 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: <1q_IlMBvLO9YrkQOYcMMVL2T0c3SD3CzyLUtFhnBKc4=.538d7c60-2cbf-40cc-b5ea-8b641a435a70@github.com> On Tue, 30 Mar 2021 21:19:38 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 639: > >> 637: // returned to the caller. None of this is necessary for >> 638: // encryption: encrypted data can be safely returned upon a >> 639: // implUpdate call. > > nit: all of the "unencrypted" -> "decrypted". I think this is a bit too verbose? Could we trim it down more, e.g. for decrypting with update() calls, up to a block of input is held inside padBuffer as it may contain padding bytes when no more data is supplied when doFinal() is called. > > It should be clear that this does not apply for encryption, so there should be no need to state that. I'll replace "unencrypted" with "decrypted" and remove the comment about this not being necessary for encryption. I've also trimmed and improved my comment a bit: "While decrypting with implUpdate, the current encrypted block is always held in a buffer. If it's the last one (unknown at this point), it may contain padding bytes and need further processing. In implDoFinal (where we know it's the last one) the buffer is decrypted, unpadded and returned.". One comment about your suggestion: it's block-sized, not 'up to a block size'. But sounded a bit confusing to me overall, so if possible I'd stick to something along the lines above. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 14:56:25 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 14:56:25 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 21:24:37 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 654: > >> 652: } >> 653: // update 'padBuffer' if using our own padding impl. >> 654: if (paddingObj != null) { > > nit: if (paddingObj != null && newPadBufferLen > 0)? Yes, makes sense. I've replaced the other " newPadBufferLen != 0" with "newPadBufferLen > 0" to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 15:19:36 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 15:19:36 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 21:49:57 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 606: > >> 604: // NSS throws up when called with data not in multiple >> 605: // of blocks. Try to work around this by holding the >> 606: // extra data in padBuffer. > > nit: The comment looks a little bit strange. This particular block of code is for handling existing buffered data buffered in earlier update() calls. The comment however is more about 'reqBlockUpdates' itself. How about merging this with the comment for 'reqBlockUpdates' field and then changing this comment to what this particular block of code does. Yes, you are right. I merged the comment with the field description. I believe there is not much to say about that block, though. At least there is nothing new there, except that we may buffer for reqBlockUpdates reasons. If you still want a comment there, let me know and I try to figure out something. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 15:31:30 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 15:31:30 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: <-nQA2Ne5zGoySwymZnaGeLMIq5pOh8RDwAjLfeNfhQM=.8f75ad51-f0b7-4b7a-aa70-2ae8d0034467@github.com> Message-ID: On Tue, 30 Mar 2021 22:12:16 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 819: >> >>> 817: int startOff = 0; >>> 818: if (reqBlockUpdates) { >>> 819: startOff = bytesBuffered; >> >> Shouldn't the starting offset be the number of bytes in padBuffer, i.e. padBufferLen? > > Then no need for the assert(...) to check the starting offset value. padBufferLen and bytesBuffered look a bit confusing to me. My suspicion is that they have the same value every time we need them. I'll make the change you suggested and check that we have no regressions. If you believe the assertions are trivial, I'll remove them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From xuelei at openjdk.java.net Tue Apr 6 15:46:27 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 6 Apr 2021 15:46:27 GMT Subject: Integrated: 8264554: X509KeyManagerImpl calls getProtectionParameter with incorrect alias In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:38:14 GMT, Xue-Lei Andrew Fan wrote: > In X509KeyManagerImpl.java, a composited entry alias consists three parts: an UID counter, a builder index and the real entry alias (See the makeAlias() method). While calling the KeyStore.Builder.getProtectionParameter(String alias) method, the real entry alias should be used instead, rather than the composited entry alias. > > Simple and straightforward update, no new regression test. This pull request has now been integrated. Changeset: 2f516996 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/2f516996 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8264554: X509KeyManagerImpl calls getProtectionParameter with incorrect alias Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/3326 From mbalao at openjdk.java.net Tue Apr 6 16:48:28 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 16:48:28 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: <2KhtRp_kHPcx_YIF67BL1e2ldskod81nRSrjbUXFbUU=.3743305b-76e0-4d83-9680-e2504ed34e17@github.com> References: <2KhtRp_kHPcx_YIF67BL1e2ldskod81nRSrjbUXFbUU=.3743305b-76e0-4d83-9680-e2504ed34e17@github.com> Message-ID: On Wed, 31 Mar 2021 16:51:31 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 68: > >> 66: ByteBuffer cipherText = >> 67: ByteBuffer.allocate(((inputSize / 16 ) + 1) * 16); >> 68: byte[] tmp = new byte[16]; > > Seems no need to do new byte[] given how it's used. Right. That was probably a vestige of an intermediate version. > test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 78: > >> 76: updateLength); >> 77: if (tmp != null) >> 78: cipherText.put(tmp); > > nit: either use "{ }" or move cipherText.put() call to the same line as if-check. Ok ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 17:00:39 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 17:00:39 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: <7Rw1crXLanfl1cKWHtYq6Xqw-cOemmPfAgmj_fZ_2r8=.032a9f40-89c8-429a-96ad-843022ea5837@github.com> References: <7Rw1crXLanfl1cKWHtYq6Xqw-cOemmPfAgmj_fZ_2r8=.032a9f40-89c8-429a-96ad-843022ea5837@github.com> Message-ID: On Wed, 31 Mar 2021 17:00:26 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 97: > >> 95: throw new Exception("Cross-provider cipher test failed."); >> 96: } >> 97: } > > Why not just use the byte[] forms for the Cipher.doFinal() and simplify this part, i.e. line 86-96? We are accumulating cipher text in the cipherText local variable while doing updates, both for the 'update(byte[]...' and 'update(ByteBuffer...' cases. The last call to doFinal will return the last block of cipher text, which we need to append. In regards to Cipher::doFinal, we are using the byte[] form of it. Please let me know if I'm not understanding your comment correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 17:09:33 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 17:09:33 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 00:07:14 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 910: > >> 908: if (paddingObj != null) { >> 909: int actualPadLen = paddingObj.setPaddingBytes(padBuffer, >> 910: 0, requiredOutLen - bytesBuffered); > > Shouldn't the starting offset be 'padBufferLen'? Oh, yes, well spotted.. I forgot to synchronize with the byte[] path. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 17:14:37 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 17:14:37 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 00:16:28 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Avoid overriding buffered bytes with padding in the doFinal call. >> - Only do encryption block-size buffering for NSS >> - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 912: > >> 910: 0, requiredOutLen - bytesBuffered); >> 911: k = token.p11.C_EncryptUpdate(session.id(), >> 912: 0, padBuffer, 0, actualPadLen, > > actualPadLen => actualPadLen + startOfs? Yes, I forgot to synchronize with the byte[] path. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 17:52:36 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 17:52:36 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: <7Rw1crXLanfl1cKWHtYq6Xqw-cOemmPfAgmj_fZ_2r8=.032a9f40-89c8-429a-96ad-843022ea5837@github.com> Message-ID: On Tue, 6 Apr 2021 16:56:49 GMT, Martin Balao wrote: >> test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 97: >> >>> 95: throw new Exception("Cross-provider cipher test failed."); >>> 96: } >>> 97: } >> >> Why not just use the byte[] forms for the Cipher.doFinal() and simplify this part, i.e. line 86-96? > > We are accumulating cipher text in the cipherText local variable while doing updates, both for the 'update(byte[]...' and 'update(ByteBuffer...' cases. The last call to doFinal will return the last block of cipher text, which we need to append. In regards to Cipher::doFinal, we are using the byte[] form of it. Please let me know if I'm not understanding your comment correctly. I've just realized that the test is not exercising the 'doFinal(ByteBuffer..' path. Thus, why it did not catch the previous sync bugs. I'll fix that. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 18:30:31 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 18:30:31 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v3] In-Reply-To: References: Message-ID: > Hi, > > I'd like to propose a fix for JDK-8261355 [1]. > > The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. > > No regressions observed in jdk/sun/security/pkcs11. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Bug fixes and improvements as discussed in the PR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2510/files - new: https://git.openjdk.java.net/jdk/pull/2510/files/dd81ec9c..b47c03ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2510&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2510&range=01-02 Stats: 53 lines in 2 files changed: 11 ins; 18 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/2510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2510/head:pull/2510 PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Tue Apr 6 18:33:44 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 6 Apr 2021 18:33:44 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:22:55 GMT, Valerie Peng wrote: >> Hi, >> >> I'd like to propose a fix for JDK-8261355 [1]. >> >> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. >> >> No regressions observed in jdk/sun/security/pkcs11. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 > > I will take a look. > Thanks~ @valeriepeng please take a look at my comments in-line and the new proposal here: https://github.com/openjdk/jdk/pull/2510/commits/b47c03edff1f48b925a67203102385470ac1afdc Thanks, Martin.- ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From ascarpino at openjdk.java.net Tue Apr 6 19:43:50 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Apr 2021 19:43:50 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v4] In-Reply-To: References: Message-ID: > Hi, > > I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: use computeIfAbsent instead ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3296/files - new: https://git.openjdk.java.net/jdk/pull/3296/files/dda3ed69..f8c7baf7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3296&range=02-03 Stats: 19 lines in 1 file changed: 3 ins; 15 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3296/head:pull/3296 PR: https://git.openjdk.java.net/jdk/pull/3296 From ascarpino at openjdk.java.net Tue Apr 6 19:43:55 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 6 Apr 2021 19:43:55 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 07:29:00 GMT, djelinski wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ReentrantLock for put and get > > src/java.base/share/classes/sun/security/rsa/RSACore.java line 443: > >> 441: lock.lock(); >> 442: try { >> 443: queue = blindingCache.get(n); > > Suggestion: > > queue = blindingCache.computeIfAbsent(n, ignored -> new ConcurrentLinkedQueue<>()); Yeah, that makes sense after all the changes ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From github.com+30433125+djelinski at openjdk.java.net Tue Apr 6 20:40:25 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Tue, 6 Apr 2021 20:40:25 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v4] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 19:43:50 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > use computeIfAbsent instead +1 (non-binding) ------------- Marked as reviewed by djelinski at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3296 From weijun at openjdk.java.net Wed Apr 7 00:00:59 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 7 Apr 2021 00:00:59 GMT Subject: Integrated: 8262389: Use permitted_enctypes if default_tkt_enctypes or default_tgs_enctypes is not present In-Reply-To: References: Message-ID: <3fTMDk-aeqZstn05Pjddw3sy84nXjGylrL_PHU91k6Q=.9e8e128f-766a-4cd3-a05c-1937bc076fc2@github.com> On Thu, 25 Feb 2021 20:56:42 GMT, Weijun Wang wrote: > When default_tkt_enctypes or default_tgs_enctypes, use the value of permitted_enctypes if it exists. > > Please also review the CSR at https://bugs.openjdk.java.net/browse/JDK-8262391 and release note at https://bugs.openjdk.java.net/browse/JDK-8262401. This pull request has now been integrated. Changeset: eb5c097b Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/eb5c097b Stats: 60 lines in 2 files changed: 60 ins; 0 del; 0 mod 8262389: Use permitted_enctypes if default_tkt_enctypes or default_tgs_enctypes is not present Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2729 From jnimeh at openjdk.java.net Wed Apr 7 00:54:27 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 7 Apr 2021 00:54:27 GMT Subject: RFR: 8262316: Reducing locks in RSA Blinding [v4] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 19:43:50 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > use computeIfAbsent instead Looks good to me as well. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3296 From martin.doerr at sap.com Wed Apr 7 16:10:00 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Apr 2021 16:10:00 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: Hi, JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I've taken the 13u backport as source because it resolves the wrong backport order with JDK-8242141. Bug: https://bugs.openjdk.java.net/browse/JDK-8226374 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264555 Original change (JDK14): https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 13u backport: https://github.com/openjdk/jdk13u-dev/commit/384445d2 11u rejected hunks (integrated manually): http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt my new 11u backport: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Wed Apr 7 16:46:51 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 7 Apr 2021 16:46:51 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: References: Message-ID: <1ccMxvSOPGJxTHjdAXJRJzURscmdthFtW2g8EH9pwbU=.84a10e07-6067-492f-a7ce-68f64eabe3af@github.com> On Tue, 6 Apr 2021 18:29:56 GMT, Martin Balao wrote: >> I will take a look. >> Thanks~ > > @valeriepeng please take a look at my comments in-line and the new proposal here: https://github.com/openjdk/jdk/pull/2510/commits/b47c03edff1f48b925a67203102385470ac1afdc > > Thanks, > Martin.- Sure, will take another look. Thanks! Valerie ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From greg at rubinfamily.org Wed Apr 7 17:28:03 2021 From: greg at rubinfamily.org (Greg Rubin) Date: Wed, 7 Apr 2021 10:28:03 -0700 Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: <6376950b-8e3c-6df6-b70d-8791ae7f0b1f@comcast.net> References: <6376950b-8e3c-6df6-b70d-8791ae7f0b1f@comcast.net> Message-ID: Mike, Yes, this was in response to your comment. I'm aware that the IV really serves more as an integrity check and mode signalling mechanism than anything else. My concern is that in the past few years I've seen various issues related to "in band signalling" where something about the ciphertext (or directly associated metadata) changes how the data is decrypted and authenticated. This has reached the level where several cryptographic forums I participate in are starting to consider it a full anti-pattern. The proposed "AutoPadding" mode is an example of in-band signalling in which an externally provided ciphertext changes how it is interpreted. While I cannot personally think of a specific risk in this case, I would be inclined not to include this mode unless there is a strong driving need from our users. While I have definitely seen people not knowing if their data was encrypted with KW or KW+PKCS5/7, I haven't personally seen uncertainty between KW and KWP. (I also haven't worked with all possible HSMs, just a few of them.) So, from a position of caution, I'd avoid "AutoPadding", but this is a preference based on current best-practice rather than a strong objection based on specific concerns or risks. Thank you, Greg On Sat, Apr 3, 2021 at 4:38 PM Michael StJohns wrote: > On 4/3/2021 11:35 AM, Greg Rubin wrote: > > I'd advise against the AutoPadding scheme without more careful analysis > and discussion. Have we seen either KW or KWP specifications which > recommend that behavior? > > > > My concern is that we've seen cases before where two different > cryptographic algorithms could be selected transparently upon decryption > and it lowers the security of the overall system. (A variant of in-band > signalling.) The general consensus that I've been seeing in the (applied) > cryptographic community is strongly away from in-band signalling and > towards the decryptor fully specifying the algorithms and behavior prior to > attempting decryption. > > I think this is in response to my comment? > > The wrap function can take a Key as an input and can have the unwrap > method produce a Key as an output - indeed it should be used primarily > for this rather than the more general encrypt/decrypt functions. The > problem is that the encoding of the key may not be known prior to the > attempt to wrap it - hence it's not known whether or not padding need be > applied. This is especially problematic with HSMs. Providing an > AutoPadding mode would allow the wrapping algorithm to decide whether to > use either of the RFC 3394 (AKA KW) Integrity Check Value (ICV) or the > RFC5649 (aka KWP) value and padding length. > > The key thing to remember here is that the IV (initial value - RFC > language) /ICV (integrity check value - NIST language)actually isn't an > IV(initialization vector) in the ordinary meaning, it's a flag, padding > and integrity indicator and will be fixed for all keys of the same > length that use the specified values. E.g. unlike other modes that > require an initialization vector, you don't need to know the ICV to > decrypt the underlying key stream, but you can (and for that matter > MUST) easily test the recovered first block against the expected ICV to > determine whether the output needs padding removed or not. > > FWIW, the actual cryptographic operations between padded data and > non-padded data (of the right multiple length) are identical. It's only > the pre or post processing that's looking for different data. > > Obviously, this doesn't work if someone provides their own IV - but > that's fairly unlikely. CF CCM and its non-normative example formatting > function appendix A - each and every implementation I've seen uses that > formatting function, even though it isn't actually required by the > standard. I'd be surprised if anyone decided to use a different set of > non-standard IV values. > > If an AutoPadding mode were implemented, I'd throw exceptions if someone > tried to set the IV. > > Later, Mike > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ascarpino at openjdk.java.net Wed Apr 7 17:32:51 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 7 Apr 2021 17:32:51 GMT Subject: Integrated: 8262316: Reducing locks in RSA Blinding In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 21:47:24 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of the locking change to the RSA blinding code. The problem was reported that multithreaded performance suffered because there was one global lock on the many blindings operation. The change reduces locking by using a ConcurrentLinkedQueue to store the different BlindingParameters that other threads maybe using. The queue size is limited to prevent sudden surges in stored BlindingParameters and a WeakHashMap is still used so the objects can be freed when no longer used. Performance doubles under high load. > > thanks > > Tony This pull request has now been integrated. Changeset: 7a99a987 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/7a99a987 Stats: 80 lines in 1 file changed: 37 ins; 17 del; 26 mod 8262316: Reducing locks in RSA Blinding Reviewed-by: jnimeh ------------- PR: https://git.openjdk.java.net/jdk/pull/3296 From mstjohns at comcast.net Wed Apr 7 18:49:11 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 7 Apr 2021 14:49:11 -0400 Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: References: <6376950b-8e3c-6df6-b70d-8791ae7f0b1f@comcast.net> Message-ID: <91c7929d-0592-8947-d065-7f6180df86cc@comcast.net> On 4/7/2021 1:28 PM, Greg Rubin wrote: > Mike, > > Yes, this was in response to your comment. > > I'm aware that the IV really serves more as an integrity check and > mode signalling mechanism than anything else. My concern is that in > the past few years I've seen various issues related to "in band > signalling" where something about the ciphertext (or directly > associated metadata) changes how the data is decrypted and > authenticated. This has reached the level where several cryptographic > forums I participate in are starting to consider it a full anti-pattern. > > The proposed "AutoPadding" mode is an example of in-band signalling in > which an externally provided ciphertext? changes how it is > interpreted. While I cannot personally think of a specific risk in > this case, I would be inclined not to include this mode unless there > is a strong driving need from our users. While I have definitely seen > people not knowing if their data was encrypted with KW or KW+PKCS5/7, > I haven't personally?seen uncertainty between KW and KWP. (I also > haven't worked with all possible HSMs, just a few of them.) So, from a > position of caution, I'd avoid "AutoPadding", but this is a preference > based on current best-practice rather than a strong objection based on > specific concerns or risks. I sent a note off to the original mode inventor - Russ Housley: > Can you think of any reason why there might be an issue with providing > an autopadding mode for KW/KWP (e.g. select which to use based on the > input data for encrypt and determine which was used after running the > unwrap function but before removing the initial block and any padding)? I got back: > As long as every party supports both modes, you could use KW id [sic - > I think he meant "is"] the inout is a multiple of 64 bits, otherwise > use KWP. ?Of course, the algorithm identifier needs to be set > appropriately. Which sort of confirms what I thought, but added a question:? Are there algorithm OIDs for KW with PKCS5 padding or do people just use the KW OID( 2.16.840.1.101.3.4.1.{5,25,45}?? As far as I can tell, there are no OIDs for KW with PKCS5. Does there need to be an autopad OID? If it were me, I'd be avoiding implementing the PKCS5 padding mode here.? I can't actually find a specification that includes it and it looks like a hack that was fixed by the specification of KWP.? I'd prefer not to extend the hack's lifetime, given that RFC5649 is 10+ years old. WRT to HSM uncertainty, I ran into problems especially trying to wrap RSA private keys.? Turned out that some encoded as 8 byte multiples and some did not.? In any event, I mentioned HSMs, but I really care about the general model for the JCE.? I'd *really* like to avoid having to have to first figure out the private key encoding length (which may be difficult as a provider may not choose to export an unwrapped private key even if its a software provider) before choosing the wrapping algorithm.?? Doing it that way just fits the JCE model better. At some point, there needs to be an RFC written that specifies the default encodings for keys wrapped by this algorithm. Later, Mike > > Thank you, > Greg > > On Sat, Apr 3, 2021 at 4:38 PM Michael StJohns > wrote: > > On 4/3/2021 11:35 AM, Greg Rubin wrote: > > I'd advise against the AutoPadding scheme without more careful > analysis and discussion. Have we seen either KW or KWP > specifications which recommend that behavior? > > > > My concern is that we've seen cases before where two different > cryptographic algorithms could be selected transparently upon > decryption and it lowers the security of the overall system. (A > variant of in-band signalling.) The general consensus that I've > been seeing in the (applied) cryptographic community is strongly > away from in-band signalling and towards the decryptor fully > specifying the algorithms and behavior prior to attempting decryption. > > I think this is in response to my comment? > > The wrap function can take a Key as an input and can have the unwrap > method produce a Key as an output - indeed it should be used > primarily > for this rather than the more general encrypt/decrypt functions.? The > problem is that the encoding of the key may not be known prior to the > attempt to wrap it - hence it's not known whether or not padding > need be > applied.? This is especially problematic with HSMs.? Providing an > AutoPadding mode would allow the wrapping algorithm to decide > whether to > use either of the RFC 3394 (AKA KW) Integrity Check Value (ICV) or > the > RFC5649 (aka KWP) value and padding length. > > The key thing to remember here is that the IV (initial value - RFC > language) /ICV (integrity check value - NIST language)actually > isn't an > IV(initialization vector) in the ordinary meaning, it's a flag, > padding > and integrity indicator and will be fixed for all keys of the same > length that use the specified values.?? E.g. unlike other modes that > require an initialization vector, you don't need to know the ICV to > decrypt the underlying key stream, but you can? (and for that matter > MUST) easily test the recovered first block against the expected > ICV to > determine whether the output needs padding removed or not. > > FWIW, the actual cryptographic operations between padded data and > non-padded data (of the right multiple length) are identical. It's > only > the pre or post processing that's looking for different data. > > Obviously, this doesn't work if someone provides their own IV - but > that's fairly unlikely.? CF CCM and its non-normative example > formatting > function appendix A -? each and every implementation I've seen > uses that > formatting function, even though it isn't actually required by the > standard.? I'd be surprised if anyone decided to use a different > set of > non-standard IV values. > > If an AutoPadding mode were implemented, I'd throw exceptions if > someone > tried to set the IV. > > Later, Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Wed Apr 7 18:50:24 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 7 Apr 2021 14:50:24 -0400 Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: <91c7929d-0592-8947-d065-7f6180df86cc@comcast.net> References: <6376950b-8e3c-6df6-b70d-8791ae7f0b1f@comcast.net> <91c7929d-0592-8947-d065-7f6180df86cc@comcast.net> Message-ID: *sigh* Minor correction in line. On 4/7/2021 2:49 PM, Michael StJohns wrote: > On 4/7/2021 1:28 PM, Greg Rubin wrote: >> Mike, >> >> Yes, this was in response to your comment. >> >> I'm aware that the IV really serves more as an integrity check and >> mode signalling mechanism than anything else. My concern is that in >> the past few years I've seen various issues related to "in band >> signalling" where something about the ciphertext (or directly >> associated metadata) changes how the data is decrypted and >> authenticated. This has reached the level where several cryptographic >> forums I participate in are starting to consider it a full anti-pattern. >> >> The proposed "AutoPadding" mode is an example of in-band signalling >> in which an externally provided ciphertext changes how it is >> interpreted. While I cannot personally think of a specific risk in >> this case, I would be inclined not to include this mode unless there >> is a strong driving need from our users. While I have definitely seen >> people not knowing if their data was encrypted with KW or KW+PKCS5/7, >> I haven't personally?seen uncertainty between KW and KWP. (I also >> haven't worked with all possible HSMs, just a few of them.)? So, from >> a position of caution, I'd avoid "AutoPadding", but this is a >> preference based on current best-practice rather than a strong >> objection based on specific concerns or risks. > > > I sent a note off to the original mode inventor - Russ Housley: > >> Can you think of any reason why there might be an issue with >> providing an autopadding mode for KW/KWP (e.g. select which to use >> based on the input data for encrypt and determine which was used >> after running the unwrap function but before removing the initial >> block and any padding)? > > I got back: > >> As long as every party supports both modes, you could use KW id [sic >> - I think he meant "is"] "if" not "is" >> the inout is a multiple of 64 bits, otherwise use KWP. ?Of course, >> the algorithm identifier needs to be set appropriately. > > Which sort of confirms what I thought, but added a question: Are there > algorithm OIDs for KW with PKCS5 padding or do people just use the KW > OID( 2.16.840.1.101.3.4.1.{5,25,45}?? As far as I can tell, there are > no OIDs for KW with PKCS5. > > Does there need to be an autopad OID? > > If it were me, I'd be avoiding implementing the PKCS5 padding mode > here.? I can't actually find a specification that includes it and it > looks like a hack that was fixed by the specification of KWP.? I'd > prefer not to extend the hack's lifetime, given that? RFC5649 is 10+ > years old. > > WRT to HSM uncertainty, I ran into problems especially trying to wrap > RSA private keys.? Turned out that some encoded as 8 byte multiples > and some did not.? In any event, I mentioned HSMs, but I really care > about the general model for the JCE. I'd *really* like to avoid having > to have to first figure out the private key encoding length (which may > be difficult as a provider may not choose to export an unwrapped > private key even if its a software provider) before choosing the > wrapping algorithm.?? Doing it that way just fits the JCE model better. > > At some point, there needs to be an RFC written that specifies the > default encodings for keys wrapped by this algorithm. > > Later, Mike > > >> >> Thank you, >> Greg >> >> On Sat, Apr 3, 2021 at 4:38 PM Michael StJohns > > wrote: >> >> On 4/3/2021 11:35 AM, Greg Rubin wrote: >> > I'd advise against the AutoPadding scheme without more careful >> analysis and discussion. Have we seen either KW or KWP >> specifications which recommend that behavior? >> > >> > My concern is that we've seen cases before where two different >> cryptographic algorithms could be selected transparently upon >> decryption and it lowers the security of the overall system. (A >> variant of in-band signalling.) The general consensus that I've >> been seeing in the (applied) cryptographic community is strongly >> away from in-band signalling and towards the decryptor fully >> specifying the algorithms and behavior prior to attempting >> decryption. >> >> I think this is in response to my comment? >> >> The wrap function can take a Key as an input and can have the unwrap >> method produce a Key as an output - indeed it should be used >> primarily >> for this rather than the more general encrypt/decrypt functions.? >> The >> problem is that the encoding of the key may not be known prior to >> the >> attempt to wrap it - hence it's not known whether or not padding >> need be >> applied.? This is especially problematic with HSMs. Providing an >> AutoPadding mode would allow the wrapping algorithm to decide >> whether to >> use either of the RFC 3394 (AKA KW) Integrity Check Value (ICV) >> or the >> RFC5649 (aka KWP) value and padding length. >> >> The key thing to remember here is that the IV (initial value - RFC >> language) /ICV (integrity check value - NIST language)actually >> isn't an >> IV(initialization vector) in the ordinary meaning, it's a flag, >> padding >> and integrity indicator and will be fixed for all keys of the same >> length that use the specified values.?? E.g. unlike other modes that >> require an initialization vector, you don't need to know the ICV to >> decrypt the underlying key stream, but you can? (and for that matter >> MUST) easily test the recovered first block against the expected >> ICV to >> determine whether the output needs padding removed or not. >> >> FWIW, the actual cryptographic operations between padded data and >> non-padded data (of the right multiple length) are identical. >> It's only >> the pre or post processing that's looking for different data. >> >> Obviously, this doesn't work if someone provides their own IV - but >> that's fairly unlikely.? CF CCM and its non-normative example >> formatting >> function appendix A -? each and every implementation I've seen >> uses that >> formatting function, even though it isn't actually required by the >> standard.? I'd be surprised if anyone decided to use a different >> set of >> non-standard IV values. >> >> If an AutoPadding mode were implemented, I'd throw exceptions if >> someone >> tried to set the IV. >> >> Later, Mike >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at rubinfamily.org Wed Apr 7 19:37:40 2021 From: greg at rubinfamily.org (Greg Rubin) Date: Wed, 7 Apr 2021 12:37:40 -0700 Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: References: <6376950b-8e3c-6df6-b70d-8791ae7f0b1f@comcast.net> <91c7929d-0592-8947-d065-7f6180df86cc@comcast.net> Message-ID: I agree that the response from Housley certainly supports that "AutoPadding" is likely a safe mode to use. I still would prefer not to see it (keeping things simple) but don't really have any objections to it. For KW+PKCS5, I have (unfortunately) seen this deployed in the real world and had to assist Java developers in manually removing PKCS5 padding from the result of KW decryption. (No OIDs were used in any parts of these designs, so I cannot say what would have been used.) So, since I had to help multiple people write this code already, I really cannot object to adding support for it. The JCA supports many algorithms which shouldn't be used but exist for compatibility and interactions with other systems (DES, RC4, etc.). This would be yet another algorithm of that type. (Arguably, both KW and KWP should probably be replaced by AES-GCM for modern systems, but that is an entirely different discussion.) As for OIDs, that seems somewhat unrelated and I don't think we need something new. I've rarely needed to use the OIDs for KW or KWP and suspect that we could simply choose the one that corresponds to the algorithm we actually used. I've also encountered HSMs which added PKCS5 padding prior to KW so that all output was 8-byte aligned. That was very frustrating to deal with as it was not clearly documented at the time. Finally, I believe that the encoding question is separate from the wrapping question. Each key type should (and generally does) define how to encode it as an octet string. Then you apply the relevant wrapping/unwrapping algorithm to that encoding. KW/KWP should not define how to encode keys any more than RSA should define how to wrap a serialized RSA key. (However, I may have misunderstood your comment "... RFC written that specifies the default encodings for keys wrapped by this algorithm.") Greg On Wed, Apr 7, 2021 at 11:51 AM Michael StJohns wrote: > *sigh* Minor correction in line. > > On 4/7/2021 2:49 PM, Michael StJohns wrote: > > On 4/7/2021 1:28 PM, Greg Rubin wrote: > > Mike, > > Yes, this was in response to your comment. > > I'm aware that the IV really serves more as an integrity check and mode > signalling mechanism than anything else. My concern is that in the past few > years I've seen various issues related to "in band signalling" where > something about the ciphertext (or directly associated metadata) changes > how the data is decrypted and authenticated. This has reached the level > where several cryptographic forums I participate in are starting to > consider it a full anti-pattern. > > The proposed "AutoPadding" mode is an example of in-band signalling in > which an externally provided ciphertext changes how it is interpreted. > While I cannot personally think of a specific risk in this case, I would be > inclined not to include this mode unless there is a strong driving need > from our users. While I have definitely seen people not knowing if their > data was encrypted with KW or KW+PKCS5/7, I haven't personally seen > uncertainty between KW and KWP. (I also haven't worked with all possible > HSMs, just a few of them.) So, from a position of caution, I'd avoid > "AutoPadding", but this is a preference based on current best-practice > rather than a strong objection based on specific concerns or risks. > > > I sent a note off to the original mode inventor - Russ Housley: > > Can you think of any reason why there might be an issue with providing an > autopadding mode for KW/KWP (e.g. select which to use based on the input > data for encrypt and determine which was used after running the unwrap > function but before removing the initial block and any padding)? > > I got back: > > As long as every party supports both modes, you could use KW id [sic - I > think he meant "is"] > > "if" not "is" > > the inout is a multiple of 64 bits, otherwise use KWP. Of course, the > algorithm identifier needs to be set appropriately. > > Which sort of confirms what I thought, but added a question: Are there > algorithm OIDs for KW with PKCS5 padding or do people just use the KW OID( > 2.16.840.1.101.3.4.1.{5,25,45}? As far as I can tell, there are no OIDs > for KW with PKCS5. > > Does there need to be an autopad OID? > > If it were me, I'd be avoiding implementing the PKCS5 padding mode here. > I can't actually find a specification that includes it and it looks like a > hack that was fixed by the specification of KWP. I'd prefer not to extend > the hack's lifetime, given that RFC5649 is 10+ years old. > > WRT to HSM uncertainty, I ran into problems especially trying to wrap RSA > private keys. Turned out that some encoded as 8 byte multiples and some > did not. In any event, I mentioned HSMs, but I really care about the > general model for the JCE. I'd *really* like to avoid having to have to > first figure out the private key encoding length (which may be difficult as > a provider may not choose to export an unwrapped private key even if its a > software provider) before choosing the wrapping algorithm. Doing it that > way just fits the JCE model better. > > At some point, there needs to be an RFC written that specifies the default > encodings for keys wrapped by this algorithm. > > Later, Mike > > > > Thank you, > Greg > > On Sat, Apr 3, 2021 at 4:38 PM Michael StJohns > wrote: > >> On 4/3/2021 11:35 AM, Greg Rubin wrote: >> > I'd advise against the AutoPadding scheme without more careful analysis >> and discussion. Have we seen either KW or KWP specifications which >> recommend that behavior? >> > >> > My concern is that we've seen cases before where two different >> cryptographic algorithms could be selected transparently upon decryption >> and it lowers the security of the overall system. (A variant of in-band >> signalling.) The general consensus that I've been seeing in the (applied) >> cryptographic community is strongly away from in-band signalling and >> towards the decryptor fully specifying the algorithms and behavior prior to >> attempting decryption. >> >> I think this is in response to my comment? >> >> The wrap function can take a Key as an input and can have the unwrap >> method produce a Key as an output - indeed it should be used primarily >> for this rather than the more general encrypt/decrypt functions. The >> problem is that the encoding of the key may not be known prior to the >> attempt to wrap it - hence it's not known whether or not padding need be >> applied. This is especially problematic with HSMs. Providing an >> AutoPadding mode would allow the wrapping algorithm to decide whether to >> use either of the RFC 3394 (AKA KW) Integrity Check Value (ICV) or the >> RFC5649 (aka KWP) value and padding length. >> >> The key thing to remember here is that the IV (initial value - RFC >> language) /ICV (integrity check value - NIST language)actually isn't an >> IV(initialization vector) in the ordinary meaning, it's a flag, padding >> and integrity indicator and will be fixed for all keys of the same >> length that use the specified values. E.g. unlike other modes that >> require an initialization vector, you don't need to know the ICV to >> decrypt the underlying key stream, but you can (and for that matter >> MUST) easily test the recovered first block against the expected ICV to >> determine whether the output needs padding removed or not. >> >> FWIW, the actual cryptographic operations between padded data and >> non-padded data (of the right multiple length) are identical. It's only >> the pre or post processing that's looking for different data. >> >> Obviously, this doesn't work if someone provides their own IV - but >> that's fairly unlikely. CF CCM and its non-normative example formatting >> function appendix A - each and every implementation I've seen uses that >> formatting function, even though it isn't actually required by the >> standard. I'd be surprised if anyone decided to use a different set of >> non-standard IV values. >> >> If an AutoPadding mode were implemented, I'd throw exceptions if someone >> tried to set the IV. >> >> Later, Mike >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Wed Apr 7 20:25:45 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 7 Apr 2021 20:25:45 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: <1ccMxvSOPGJxTHjdAXJRJzURscmdthFtW2g8EH9pwbU=.84a10e07-6067-492f-a7ce-68f64eabe3af@github.com> References: <1ccMxvSOPGJxTHjdAXJRJzURscmdthFtW2g8EH9pwbU=.84a10e07-6067-492f-a7ce-68f64eabe3af@github.com> Message-ID: On Wed, 7 Apr 2021 16:42:53 GMT, Valerie Peng wrote: >> @valeriepeng please take a look at my comments in-line and the new proposal here: https://github.com/openjdk/jdk/pull/2510/commits/b47c03edff1f48b925a67203102385470ac1afdc >> >> Thanks, >> Martin.- > > Sure, will take another look. Thanks! > Valerie Rest of changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From valeriep at openjdk.java.net Wed Apr 7 20:25:46 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 7 Apr 2021 20:25:46 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 14:26:00 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 265: >> >>> 263: // NSS requires block-sized updates in multi-part operations. >>> 264: reqBlockUpdates = ((tokenLabel[0] == 'N' && tokenLabel[1] == 'S' >>> 265: && tokenLabel[2] == 'S') ? true : false); >> >> IIRC, depending on how the impl is registered, engineSetPadding(String) may not always be called. It's probably safer to set this in engineInit(...)? > > Looks to me that engineSetPadding is always called from the P11Cipher constructor. I thought that was a good location to set the reqBlockUpdates variable because it's next to the paddingObj initialization; which is a pre-requisite for reqBlockUpdates to be used. In other words, if we have no Java-side padding (paddingObj == null), reqBlockUpdates won't be used and we don't even pay the price of setting it. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From valeriep at openjdk.java.net Wed Apr 7 20:29:31 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 7 Apr 2021 20:29:31 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 18:30:31 GMT, Martin Balao wrote: >> Hi, >> >> I'd like to propose a fix for JDK-8261355 [1]. >> >> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. >> >> No regressions observed in jdk/sun/security/pkcs11. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Bug fixes and improvements as discussed in the PR Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From hohensee at amazon.com Wed Apr 7 21:41:30 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 21:41:30 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: The backport looks fine, except there's a missing blank line after FFDHE_2048 in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one for the 13u backport: perhaps Yan will add one after the fact). I'm not a security person, so it would be great if someone who is reviews the CSR to see if there are any 11u-specific issues with it. Thanks, Paul ?-----Original Message----- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Wednesday, April 7, 2021 at 9:10 AM To: jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi, JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I've taken the 13u backport as source because it resolves the wrong backport order with JDK-8242141. Bug: https://bugs.openjdk.java.net/browse/JDK-8226374 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264555 Original change (JDK14): https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 13u backport: https://github.com/openjdk/jdk13u-dev/commit/384445d2 11u rejected hunks (integrated manually): http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt my new 11u backport: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ Please review. Best regards, Martin From christoph.langer at sap.com Wed Apr 7 22:15:43 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Apr 2021 22:15:43 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: Hi Paul, thanks for the review. The CSR that Martin mentions is the one that Oracle has filed for 11.0.12-oracle. so we can simply reuse it. As for 13, there exists a CSR as well: JDK-8256335 Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Mittwoch, 7. April 2021 23:42 > To: Doerr, Martin ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > The backport looks fine, except there's a missing blank line after FFDHE_2048 > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > security person, so it would be great if someone who is reviews the CSR to > see if there are any 11u-specific issues with it. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Wednesday, April 7, 2021 at 9:10 AM > To: jdk-updates-dev , security-dev > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi, > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It doesn't apply cleanly. I've taken the 13u backport as source because it > resolves the wrong backport order with JDK-8242141. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8226374 > > 11u CSR: > https://bugs.openjdk.java.net/browse/JDK-8264555 > > Original change (JDK14): > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > 13u backport: > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > 11u rejected hunks (integrated manually): > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > my new 11u backport: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From hohensee at amazon.com Wed Apr 7 23:00:36 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 23:00:36 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: Hmm, could have sworn... Thanks, Paul ?-----Original Message----- From: "Langer, Christoph" Date: Wednesday, April 7, 2021 at 3:16 PM To: "Hohensee, Paul" , "Doerr, Martin" , jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi Paul, thanks for the review. The CSR that Martin mentions is the one that Oracle has filed for 11.0.12-oracle. so we can simply reuse it. As for 13, there exists a CSR as well: JDK-8256335 Best regards Christoph > -----Original Message----- > From: Hohensee, Paul > Sent: Mittwoch, 7. April 2021 23:42 > To: Doerr, Martin ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > The backport looks fine, except there's a missing blank line after FFDHE_2048 > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > security person, so it would be great if someone who is reviews the CSR to > see if there are any 11u-specific issues with it. > > Thanks, > Paul > > -----Original Message----- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Wednesday, April 7, 2021 at 9:10 AM > To: jdk-updates-dev , security-dev > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi, > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > It doesn't apply cleanly. I've taken the 13u backport as source because it > resolves the wrong backport order with JDK-8242141. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8226374 > > 11u CSR: > https://bugs.openjdk.java.net/browse/JDK-8264555 > > Original change (JDK14): > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > 13u backport: > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > 11u rejected hunks (integrated manually): > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > my new 11u backport: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > Please review. > > Best regards, > Martin > From hchao at openjdk.java.net Wed Apr 7 23:17:54 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 7 Apr 2021 23:17:54 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Fri, 2 Apr 2021 11:52:16 GMT, Weijun Wang wrote: >>> Maybe we don't need to resolve it in this code change. If we look carefully at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 is using the signer's SKID in 10.1 as its own SKID and it has no AKID. Currently, keytool will generate a new SKID and use signer's SKID as AKID. If we really want to generate a certificate that's identical to the one in the RFC, we'll need a way to tell keytool to omit the AKID (something like "-ext akid=none"). >> >> Better to use AKID for certification path building. > > I don't mean we will remove it by default. Just think there needs a way to remove either AKID or SKID, because we always generate them automatically. The support for omitting AKID will be tracked by different PR if needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Wed Apr 7 23:17:53 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 7 Apr 2021 23:17:53 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v5] In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: > Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. > CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: update with review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3281/files - new: https://git.openjdk.java.net/jdk/pull/3281/files/157601f2..3be5bc98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=03-04 Stats: 28 lines in 3 files changed: 0 ins; 12 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3281/head:pull/3281 PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Wed Apr 7 23:17:59 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 7 Apr 2021 23:17:59 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Fri, 2 Apr 2021 01:40:16 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> update with review comments > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1978: > >> 1976: keypair.getPublicKeyAnyway(), >> 1977: signerSubjectKeyId); >> 1978: } else { > > No need for an if-else block? `signerSubjectKeyId` is null in this case. Removed. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013: > >> 2011: x500Name}; >> 2012: System.err.println(form.format(source)); >> 2013: } > > Either put the declaration of `source` outside the if-else block and move the println line outside; or, move the declaration of `form` inside. It looks confusing that `form` is declared outside and `source` inside. Done. > src/java.base/share/classes/sun/security/tools/keytool/Resources.java line 310: > >> 308: "Generating {0} bit {1} key pair and self-signed certificate ({2}) with a validity of {3} days\n\tfor: {4}"}, >> 309: {"Generating.keysize.bit.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.an.entry.signerAlias.with.a.validity.of.validality.days.for", >> 310: "Generating {0} bit {1} key pair and a certificate ({2}) issued by an entry <{3}> with a validity of {4} days\n\tfor: {5}"}, > > I feel "issued by <{3}>" sounds more normal. No need to say "an entry". You decide it. Removed "an entry". ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 8 00:06:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 00:06:39 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v5] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Wed, 7 Apr 2021 23:17:53 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. >> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > update with review comments No comment on src side. src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 88: > 86: */ > 87: public CertAndKeyGen (String keyType, String sigAlg, String providerName) > 88: throws NoSuchAlgorithmException, NoSuchProviderException Indent the line 8 spaces further. test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 96: > 94: > 95: Certificate[] certChain = kstore.getCertificateChain("e1"); > 96: if (certChain.length != 2) { Try using `Asserts` class in `/test/lib` to make code simpler. Also, why not throw an exception but call `System.exit(1)`? We usually do not call this method in a test because the test framework must take great care so that itself does not get terminated. test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 299: > 297: System.exit(1); > 298: } > 299: Since you are here, you can check if the new entry is indeed protected by the new key password. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 8 01:25:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 01:25:02 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding Message-ID: This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. ------------- Commit messages: - 8264864: Multiple byte tag not supported by ASN.1 encoding Changes: https://git.openjdk.java.net/jdk/pull/3391/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264864 Stats: 78 lines in 2 files changed: 77 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3391/head:pull/3391 PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 01:33:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 01:33:56 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v2] In-Reply-To: References: Message-ID: > This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: make sure test fails before code change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3391/files - new: https://git.openjdk.java.net/jdk/pull/3391/files/d25d3fb2..46b3700b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=00-01 Stats: 11 lines in 1 file changed: 6 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3391/head:pull/3391 PR: https://git.openjdk.java.net/jdk/pull/3391 From hchao at openjdk.java.net Thu Apr 8 01:48:20 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 8 Apr 2021 01:48:20 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v6] In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: > Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. > CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: test update with comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3281/files - new: https://git.openjdk.java.net/jdk/pull/3281/files/3be5bc98..63f6a4ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3281&range=04-05 Stats: 36 lines in 2 files changed: 0 ins; 17 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3281/head:pull/3281 PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 8 01:48:21 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 8 Apr 2021 01:48:21 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v5] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 8 Apr 2021 00:01:57 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> update with review comments > > src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java line 88: > >> 86: */ >> 87: public CertAndKeyGen (String keyType, String sigAlg, String providerName) >> 88: throws NoSuchAlgorithmException, NoSuchProviderException > > Indent the line 8 spaces further. Done. > test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 96: > >> 94: >> 95: Certificate[] certChain = kstore.getCertificateChain("e1"); >> 96: if (certChain.length != 2) { > > Try using `Asserts` class in `/test/lib` to make code simpler. Also, why not throw an exception but call `System.exit(1)`? We usually do not call this method in a test because the test framework must take great care so that itself does not get terminated. Changed to throw the exception for errors. Meanwhile, the test is pretty straightforward/simple, and using if comparison should serve its testing need and it does not make the code complicated. > test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 299: > >> 297: System.exit(1); >> 298: } >> 299: > > Since you are here, you can check if the new entry is indeed protected by the new key password. In testSignerJKS() has made sure that the new entry created with new key password can *only* be accessed when a correct key password is provided in order to retrieve the corresponding signer?s private key. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From hchao at openjdk.java.net Thu Apr 8 01:52:40 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 8 Apr 2021 01:52:40 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v5] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: <__UDDjpd-P_1ngSW1vaJtmCmdLQvOIwEDbYchdbATzk=.350abbcd-597a-4be8-afae-6a142ffa310e@github.com> On Thu, 8 Apr 2021 01:42:18 GMT, Hai-May Chao wrote: >> test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 299: >> >>> 297: System.exit(1); >>> 298: } >>> 299: >> >> Since you are here, you can check if the new entry is indeed protected by the new key password. > > In testSignerJKS() has made sure that the new entry created with new key password can *only* be accessed when a correct key password is provided in order to retrieve the corresponding signer?s private key. The new entry protected by the new key password is an existing function, and its testing should have been covered. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 8 02:03:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 02:03:19 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v5] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 8 Apr 2021 01:42:16 GMT, Hai-May Chao wrote: >> test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 96: >> >>> 94: >>> 95: Certificate[] certChain = kstore.getCertificateChain("e1"); >>> 96: if (certChain.length != 2) { >> >> Try using `Asserts` class in `/test/lib` to make code simpler. Also, why not throw an exception but call `System.exit(1)`? We usually do not call this method in a test because the test framework must take great care so that itself does not get terminated. > > Changed to throw the exception for errors. Meanwhile, the test is pretty straightforward/simple, and using if comparison should serve its testing need and it does not make the code complicated. You can choose your style, but `Asserts.assertEquals(certChain.length, 2, "Generated cert chain is in error")` is definitely simpler and will give you more info when it fails. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 8 02:03:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 02:03:19 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v5] In-Reply-To: <__UDDjpd-P_1ngSW1vaJtmCmdLQvOIwEDbYchdbATzk=.350abbcd-597a-4be8-afae-6a142ffa310e@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> <__UDDjpd-P_1ngSW1vaJtmCmdLQvOIwEDbYchdbATzk=.350abbcd-597a-4be8-afae-6a142ffa310e@github.com> Message-ID: On Thu, 8 Apr 2021 01:48:20 GMT, Hai-May Chao wrote: >> In testSignerJKS() has made sure that the new entry created with new key password can *only* be accessed when a correct key password is provided in order to retrieve the corresponding signer?s private key. > > The new entry protected by the new key password is an existing function, and its testing should have been covered. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From weijun at openjdk.java.net Thu Apr 8 02:03:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 02:03:18 GMT Subject: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v6] In-Reply-To: References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Thu, 8 Apr 2021 01:48:20 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. >> CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > test update with comment Well done. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3281 From xuelei at openjdk.java.net Thu Apr 8 03:52:31 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 8 Apr 2021 03:52:31 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 01:33:56 GMT, Weijun Wang wrote: >> This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > make sure test fails before code change src/java.base/share/classes/sun/security/util/DerValue.java line 322: > 320: tag = buf[pos++]; > 321: if ((tag & 0x1f) == 0x1f) { > 322: throw new IOException("Tag number cannot exceed 30"); It may be safe if not support multiple bytes tag in the current implementation of JDK, especially the ASN.1 implementation is private. However, multiple bytes tag is a legal form of ASN.1 encoding, I think. It would be nice to have a comment to state that this form is not support yet, and we may consider it in the future if needed. It may be helpful for future code maintenance. The exception message, "Tag number cannot exceed 30", may be not accuracy. I think tag number can exceed 30 per the specification, but JDK does not support it yet because we did not run into such tags in practice. I may use some words like: "Tag number exceed 30 is not supported". ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From martin.doerr at sap.com Thu Apr 8 09:52:29 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 8 Apr 2021 09:52:29 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: References: Message-ID: Hi Paul and Christoph, thank you for the review and the approval. I've added the blank line. In addition, I've reviewed the whole change again and found a copy & paste bug in my webrev.00: SECT283_K1(0x0009, "sect283k1", true, NamedGroupSpec.NAMED_GROUP_ECDHE, ProtocolVersion.PROTOCOLS_TO_12, - CurveDB.lookup("sect163k1")), + CurveDB.lookup("sect283k1")), This is the version I'm planning to push: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/ Tests have passed. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 8. April 2021 01:01 > To: Langer, Christoph ; Doerr, Martin > ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hmm, could have sworn... > > Thanks, > Paul > > ?-----Original Message----- > From: "Langer, Christoph" > Date: Wednesday, April 7, 2021 at 3:16 PM > To: "Hohensee, Paul" , "Doerr, Martin" > , jdk-updates-dev dev at openjdk.java.net>, security-dev > Cc: "Lindenmaier, Goetz" > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi Paul, > > thanks for the review. The CSR that Martin mentions is the one that Oracle > has filed for 11.0.12-oracle. so we can simply reuse it. > > As for 13, there exists a CSR as well: JDK-8256335 > > Best regards > Christoph > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Mittwoch, 7. April 2021 23:42 > > To: Doerr, Martin ; jdk-updates-dev updates- > > dev at openjdk.java.net>; security-dev > > Cc: Lindenmaier, Goetz ; Langer, Christoph > > > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > The backport looks fine, except there's a missing blank line after > FFDHE_2048 > > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be > one > > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > > security person, so it would be great if someone who is reviews the CSR to > > see if there are any 11u-specific issues with it. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Doerr, Martin" > > Date: Wednesday, April 7, 2021 at 9:10 AM > > To: jdk-updates-dev , security-dev > > > > Cc: "Lindenmaier, Goetz" , "Langer, > > Christoph" > > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hi, > > > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > > It doesn't apply cleanly. I've taken the 13u backport as source because it > > resolves the wrong backport order with JDK-8242141. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8226374 > > > > 11u CSR: > > https://bugs.openjdk.java.net/browse/JDK-8264555 > > > > Original change (JDK14): > > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > > > 13u backport: > > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > > > 11u rejected hunks (integrated manually): > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > > > my new 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > > > Please review. > > > > Best regards, > > Martin > > > From weijun at openjdk.java.net Thu Apr 8 13:57:37 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 13:57:37 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: Message-ID: > This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update exception wordings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3391/files - new: https://git.openjdk.java.net/jdk/pull/3391/files/46b3700b..9b0f9db9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3391/head:pull/3391 PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 13:57:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 13:57:38 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 03:46:07 GMT, Xue-Lei Andrew Fan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> make sure test fails before code change > > src/java.base/share/classes/sun/security/util/DerValue.java line 322: > >> 320: tag = buf[pos++]; >> 321: if ((tag & 0x1f) == 0x1f) { >> 322: throw new IOException("Tag number cannot exceed 30"); > > It may be safe if not support multiple bytes tag in the current implementation of JDK, especially the ASN.1 implementation is private. However, multiple bytes tag is a legal form of ASN.1 encoding, I think. It would be nice to have a comment to state that this form is not support yet, and we may consider it in the future if needed. It may be helpful for future code maintenance. > > The exception message, "Tag number cannot exceed 30", may be not accuracy. I think tag number can exceed 30 per the specification, but JDK does not support it yet because we did not run into such tags in practice. I may use some words like: "Tag number exceed 30 is not supported". Messages updated. "exceed" is a verb and I'm not sure whether to choose "exceeding" or "that exceeds" so finally use "over". Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From xuelei at openjdk.java.net Thu Apr 8 15:56:11 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 8 Apr 2021 15:56:11 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:57:37 GMT, Weijun Wang wrote: >> This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update exception wordings Looks good to me, except a minor comment. src/java.base/share/classes/sun/security/util/DerValue.java line 225: > 223: DerValue(byte tag, byte[] buffer, int start, int end, boolean allowBER) { > 224: if ((tag & 0x1f) == 0x1f) { > 225: throw new IllegalArgumentException("Tag number 31 is not supported"); As number 31 just means the tag is bigger than 31, Is it more accuracy by using "Tag number over 30 is not supported"? ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 17:06:36 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 17:06:36 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v4] In-Reply-To: References: Message-ID: > This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: change exception message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3391/files - new: https://git.openjdk.java.net/jdk/pull/3391/files/9b0f9db9..004b35e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3391/head:pull/3391 PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 17:06:37 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 17:06:37 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 15:53:10 GMT, Xue-Lei Andrew Fan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> update exception wordings > > src/java.base/share/classes/sun/security/util/DerValue.java line 225: > >> 223: DerValue(byte tag, byte[] buffer, int start, int end, boolean allowBER) { >> 224: if ((tag & 0x1f) == 0x1f) { >> 225: throw new IllegalArgumentException("Tag number 31 is not supported"); > > As number 31 just means the tag is bigger than 31, Is it more accuracy by using "Tag number over 30 is not supported"? Well, it's a little delicate here. Even if we support multi-byte tag one day, this constructor will still only be used to create a single-byte tag `DerValue`, and it's illegal for a single byte tag to end with 0x1f. So the words above is to remind people that they cannot create a tag number 31 `DerValue` just because it seems it still fits into the 5 bits. Precisely, the words should be "this constructor only supports tag number between 0 and 30", but... I'll choose your words. ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From jnimeh at openjdk.java.net Thu Apr 8 17:06:38 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 8 Apr 2021 17:06:38 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:57:37 GMT, Weijun Wang wrote: >> This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update exception wordings src/java.base/share/classes/sun/security/util/DerValue.java line 322: > 320: tag = buf[pos++]; > 321: if ((tag & 0x1f) == 0x1f) { > 322: throw new IOException("Tag number over 30 is not supported"); Would it be useful for these types of exception messages to either display the offending tag value or perhaps the tag offset? Just thinking it might be a nice thing for the recipient to know where in the DER encoding the issue is. ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From mullan at openjdk.java.net Thu Apr 8 17:07:07 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 8 Apr 2021 17:07:07 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 22:09:55 GMT, Alex Blewitt wrote: > 8264681: Use the blessed modifier order in java.security The rest looks fine, but I would double-check all the copyrights to see if you are modifying any other 3rd-party code than the ones I commented on. Best to leave that code as-is and fix it at the source, if possible. src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java line 390: > 388: } > 389: > 390: public abstract PSSParameterSpec getPSSParameterSpec(); This is 3rd-party (Apache) code. It would be better to change this at Apache. I would leave this one out. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Constants.java line 53: > 51: > 52: /** > 53: * This class holds only static final member variables that are constants Probably best to leave this file unchanged as it is 3rd-party code. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3338 From weijun at openjdk.java.net Thu Apr 8 17:13:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 17:13:13 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: Message-ID: <5pxsCIzTFh4p6nQxFGK5xcqk8e4mtILULZ96N_541ho=.a472dd86-dae6-4645-88a2-1945755d4d24@github.com> On Thu, 8 Apr 2021 16:58:24 GMT, Jamil Nimeh wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> update exception wordings > > src/java.base/share/classes/sun/security/util/DerValue.java line 322: > >> 320: tag = buf[pos++]; >> 321: if ((tag & 0x1f) == 0x1f) { >> 322: throw new IOException("Tag number over 30 is not supported"); > > Would it be useful for these types of exception messages to either display the offending tag value or perhaps the tag offset? Just thinking it might be a nice thing for the recipient to know where in the DER encoding the issue is. I don't want to go on reading the following bytes to find out what the intended tag number is, because that somehow shows I do understand the encoding _a lot_ but still don't want to support it (well, actually I only understand _a little_). There are only 2 kinds of tags: one <= 30 and one >= 31. IMHO, the message has already expressed the meaning that we only support the 1st one. An alternative message I can think of is "Unsupported tag byte: 0xBF", but it looks too cryptic. ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From jnimeh at openjdk.java.net Thu Apr 8 17:22:13 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 8 Apr 2021 17:22:13 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: <5pxsCIzTFh4p6nQxFGK5xcqk8e4mtILULZ96N_541ho=.a472dd86-dae6-4645-88a2-1945755d4d24@github.com> References: <5pxsCIzTFh4p6nQxFGK5xcqk8e4mtILULZ96N_541ho=.a472dd86-dae6-4645-88a2-1945755d4d24@github.com> Message-ID: On Thu, 8 Apr 2021 17:10:13 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 322: >> >>> 320: tag = buf[pos++]; >>> 321: if ((tag & 0x1f) == 0x1f) { >>> 322: throw new IOException("Tag number over 30 is not supported"); >> >> Would it be useful for these types of exception messages to either display the offending tag value or perhaps the tag offset? Just thinking it might be a nice thing for the recipient to know where in the DER encoding the issue is. > > I don't want to go on reading the following bytes to find out what the intended tag number is, because that somehow shows I do understand the encoding _a lot_ but still don't want to support it (well, actually I only understand _a little_). There are only 2 kinds of tags: one <= 30 and one >= 31. IMHO, the message has already expressed the meaning that we only support the 1st one. > > An alternative message I can think of is "Unsupported tag byte: 0xBF", but it looks too cryptic. I think that is fair. If you don't want to read ahead like that, what about using the "offset" or "pos" field to give a message like "Tag number over 30 at offset NN is not supported" (something like that, at least) Maybe don't worry about the tag value itself, but at least the position in the data stream. Just a suggestion only, no strong feelings about this either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From xuelei at openjdk.java.net Thu Apr 8 17:31:09 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 8 Apr 2021 17:31:09 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: Message-ID: <_FAWtSfTrwbuYMk9SgeQ8dqDsQzzvULd_c_G2r-yxTs=.f4890d1e-9041-4d3b-950d-5863e65cb870@github.com> On Thu, 8 Apr 2021 16:59:54 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 225: >> >>> 223: DerValue(byte tag, byte[] buffer, int start, int end, boolean allowBER) { >>> 224: if ((tag & 0x1f) == 0x1f) { >>> 225: throw new IllegalArgumentException("Tag number 31 is not supported"); >> >> As number 31 just means the tag is bigger than 31, Is it more accuracy by using "Tag number over 30 is not supported"? > > Well, it's a little delicate here. Even if we support multi-byte tag one day, this constructor will still only be used to create a single-byte tag `DerValue`, and it's illegal for a single byte tag to end with 0x1f. So the words above is to remind people that they cannot create a tag number 31 `DerValue` just because it seems it still fits into the 5 bits. Precisely, the words should be "this constructor only supports tag number between 0 and 30", but... I'll choose your words. It makes sense. Your words is good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 17:51:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 17:51:08 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v3] In-Reply-To: References: <5pxsCIzTFh4p6nQxFGK5xcqk8e4mtILULZ96N_541ho=.a472dd86-dae6-4645-88a2-1945755d4d24@github.com> Message-ID: On Thu, 8 Apr 2021 17:18:50 GMT, Jamil Nimeh wrote: >> I don't want to go on reading the following bytes to find out what the intended tag number is, because that somehow shows I do understand the encoding _a lot_ but still don't want to support it (well, actually I only understand _a little_). There are only 2 kinds of tags: one <= 30 and one >= 31. IMHO, the message has already expressed the meaning that we only support the 1st one. >> >> An alternative message I can think of is "Unsupported tag byte: 0xBF", but it looks too cryptic. > > I think that is fair. If you don't want to read ahead like that, what about using the "offset" or "pos" field to give a message like "Tag number over 30 at offset NN is not supported" (something like that, at least) Maybe don't worry about the tag value itself, but at least the position in the data stream. Just a suggestion only, no strong feelings about this either way. There _is_ an `offset` value here but I have really no idea if the user knows where to count from. If we say "offset" then we probably need to tell what data block we are talking about. What if the DerValue is just a portion of a bigger data block? That said, if you really like it, I can add an offset like "tag byte at offset nnnn". I just hope the user can find it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 20:11:24 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 20:11:24 GMT Subject: RFR: 8264864: Multiple byte tag not supported by ASN.1 encoding [v5] In-Reply-To: References: Message-ID: > This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: add offset info in exception message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3391/files - new: https://git.openjdk.java.net/jdk/pull/3391/files/004b35e8..9cb908bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3391&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3391/head:pull/3391 PR: https://git.openjdk.java.net/jdk/pull/3391 From weijun at openjdk.java.net Thu Apr 8 21:29:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 8 Apr 2021 21:29:18 GMT Subject: Integrated: 8264864: Multiple byte tag not supported by ASN.1 encoding In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 01:06:47 GMT, Weijun Wang wrote: > This code change does not intend to support multiple byte tags. Instead, it aims to fail more gracefully when such a tag is encountered. For `DerValue` constructors from an encoding (type I), an `IOException` will be thrown since it's already in the throws clause. For constructors from tag and value (type II), an `IllegalArgumentException` will be thrown. All existing type II callers inside JDK use tag numbers smaller than 31. This pull request has now been integrated. Changeset: 3d2b4cc5 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/3d2b4cc5 Stats: 83 lines in 2 files changed: 82 ins; 0 del; 1 mod 8264864: Multiple byte tag not supported by ASN.1 encoding Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3391 From hohensee at amazon.com Thu Apr 8 21:35:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 8 Apr 2021 21:35:32 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Message-ID: <281326AC-22CC-4EF0-8250-3BA00BCD9221@amazon.com> Ouch, missed that. Good to go. Thanks, Paul ?-----Original Message----- From: "Doerr, Martin" Date: Thursday, April 8, 2021 at 2:53 AM To: "Hohensee, Paul" , "Langer, Christoph" , jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi Paul and Christoph, thank you for the review and the approval. I've added the blank line. In addition, I've reviewed the whole change again and found a copy & paste bug in my webrev.00: SECT283_K1(0x0009, "sect283k1", true, NamedGroupSpec.NAMED_GROUP_ECDHE, ProtocolVersion.PROTOCOLS_TO_12, - CurveDB.lookup("sect163k1")), + CurveDB.lookup("sect283k1")), This is the version I'm planning to push: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/ Tests have passed. Best regards, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 8. April 2021 01:01 > To: Langer, Christoph ; Doerr, Martin > ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hmm, could have sworn... > > Thanks, > Paul > > -----Original Message----- > From: "Langer, Christoph" > Date: Wednesday, April 7, 2021 at 3:16 PM > To: "Hohensee, Paul" , "Doerr, Martin" > , jdk-updates-dev dev at openjdk.java.net>, security-dev > Cc: "Lindenmaier, Goetz" > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi Paul, > > thanks for the review. The CSR that Martin mentions is the one that Oracle > has filed for 11.0.12-oracle. so we can simply reuse it. > > As for 13, there exists a CSR as well: JDK-8256335 > > Best regards > Christoph > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Mittwoch, 7. April 2021 23:42 > > To: Doerr, Martin ; jdk-updates-dev updates- > > dev at openjdk.java.net>; security-dev > > Cc: Lindenmaier, Goetz ; Langer, Christoph > > > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > The backport looks fine, except there's a missing blank line after > FFDHE_2048 > > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be > one > > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > > security person, so it would be great if someone who is reviews the CSR to > > see if there are any 11u-specific issues with it. > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: jdk-updates-dev on > > behalf of "Doerr, Martin" > > Date: Wednesday, April 7, 2021 at 9:10 AM > > To: jdk-updates-dev , security-dev > > > > Cc: "Lindenmaier, Goetz" , "Langer, > > Christoph" > > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hi, > > > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. > > It doesn't apply cleanly. I've taken the 13u backport as source because it > > resolves the wrong backport order with JDK-8242141. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8226374 > > > > 11u CSR: > > https://bugs.openjdk.java.net/browse/JDK-8264555 > > > > Original change (JDK14): > > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > > > 13u backport: > > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > > > 11u rejected hunks (integrated manually): > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > > > my new 11u backport: > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > > > Please review. > > > > Best regards, > > Martin > > > From mbalao at openjdk.java.net Thu Apr 8 21:52:43 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Thu, 8 Apr 2021 21:52:43 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v4] In-Reply-To: References: Message-ID: > Hi, > > I'd like to propose a fix for JDK-8261355 [1]. > > The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. > > No regressions observed in jdk/sun/security/pkcs11. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Minor comment enhancement ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2510/files - new: https://git.openjdk.java.net/jdk/pull/2510/files/b47c03ed..fd299156 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2510&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2510&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2510/head:pull/2510 PR: https://git.openjdk.java.net/jdk/pull/2510 From hchao at openjdk.java.net Fri Apr 9 02:03:27 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 9 Apr 2021 02:03:27 GMT Subject: Integrated: 8260693: Provide the support for specifying a signer in keytool -genkeypair In-Reply-To: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> References: <9CS0BANjQdPxZywcRp8mLk0Mp9MnJTgokwAbc7SsLro=.313f4780-213e-4b61-b619-28839606e99c@github.com> Message-ID: On Wed, 31 Mar 2021 06:30:01 GMT, Hai-May Chao wrote: > Please review the changes that adds the -signer option to keytool -genkeypair command. As key agreement algorithms do not have a signing algorithm, the specified signer's private key will be used to sign and generate a key agreement certificate. > CSR review is at: https://bugs.openjdk.java.net/browse/JDK-8264325 This pull request has now been integrated. Changeset: 719f95e5 Author: Hai-May Chao URL: https://git.openjdk.java.net/jdk/commit/719f95e5 Stats: 488 lines in 6 files changed: 446 ins; 4 del; 38 mod 8260693: Provide the support for specifying a signer in keytool -genkeypair Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/3281 From xuelei at openjdk.java.net Fri Apr 9 05:01:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 9 Apr 2021 05:01:50 GMT Subject: RFR: 8264948: Check for TLS extensions total length Message-ID: To improve the readability, it would be nice to check the TLS extensions total length while parsing. No new regression test, trial update. ------------- Commit messages: - 8264948: Check for TLS extensions total length Changes: https://git.openjdk.java.net/jdk/pull/3405/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3405&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264948 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3405/head:pull/3405 PR: https://git.openjdk.java.net/jdk/pull/3405 From jnimeh at openjdk.java.net Fri Apr 9 05:58:18 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Fri, 9 Apr 2021 05:58:18 GMT Subject: RFR: 8264948: Check for TLS extensions total length In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 04:55:14 GMT, Xue-Lei Andrew Fan wrote: > To improve the readability, it would be nice to check the TLS extensions total length while parsing. > > No new regression test, trial update. src/java.base/share/classes/sun/security/ssl/SSLExtensions.java line 68: > 66: Alert.ILLEGAL_PARAMETER, > 67: "Insufficient extensions data"); > 68: } For both of these blocks the checks themselves look OK, but illegal_parameter I thought was more for cases where a field value is out of range or inconsistent with already negotiated parameters. I would think that decode_error would be more appropriate to cases like this where the encoding is structurally incorrect and the length doesn't match the actual data size. ------------- PR: https://git.openjdk.java.net/jdk/pull/3405 From martin.doerr at sap.com Fri Apr 9 09:19:05 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Apr 2021 09:19:05 +0000 Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups In-Reply-To: <281326AC-22CC-4EF0-8250-3BA00BCD9221@amazon.com> References: <281326AC-22CC-4EF0-8250-3BA00BCD9221@amazon.com> Message-ID: That one was hard to see. Pushed. Thanks, Martin > -----Original Message----- > From: Hohensee, Paul > Sent: Donnerstag, 8. April 2021 23:36 > To: Doerr, Martin ; Langer, Christoph > ; jdk-updates-dev dev at openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Ouch, missed that. Good to go. > > Thanks, > Paul > > ?-----Original Message----- > From: "Doerr, Martin" > Date: Thursday, April 8, 2021 at 2:53 AM > To: "Hohensee, Paul" , "Langer, Christoph" > , jdk-updates-dev dev at openjdk.java.net>, security-dev > Cc: "Lindenmaier, Goetz" > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi Paul and Christoph, > > thank you for the review and the approval. > > I've added the blank line. > In addition, I've reviewed the whole change again and found a copy & paste > bug in my webrev.00: > SECT283_K1(0x0009, "sect283k1", true, > NamedGroupSpec.NAMED_GROUP_ECDHE, > ProtocolVersion.PROTOCOLS_TO_12, > - CurveDB.lookup("sect163k1")), > + CurveDB.lookup("sect283k1")), > > This is the version I'm planning to push: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/ > > Tests have passed. > > Best regards, > Martin > > > > -----Original Message----- > > From: Hohensee, Paul > > Sent: Donnerstag, 8. April 2021 01:01 > > To: Langer, Christoph ; Doerr, Martin > > ; jdk-updates-dev > dev at openjdk.java.net>; security-dev > > Cc: Lindenmaier, Goetz > > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hmm, could have sworn... > > > > Thanks, > > Paul > > > > -----Original Message----- > > From: "Langer, Christoph" > > Date: Wednesday, April 7, 2021 at 3:16 PM > > To: "Hohensee, Paul" , "Doerr, Martin" > > , jdk-updates-dev > dev at openjdk.java.net>, security-dev > > Cc: "Lindenmaier, Goetz" > > Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > groups > > > > Hi Paul, > > > > thanks for the review. The CSR that Martin mentions is the one that Oracle > > has filed for 11.0.12-oracle. so we can simply reuse it. > > > > As for 13, there exists a CSR as well: JDK-8256335 > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Hohensee, Paul > > > Sent: Mittwoch, 7. April 2021 23:42 > > > To: Doerr, Martin ; jdk-updates-dev > updates- > > > dev at openjdk.java.net>; security-dev > > > Cc: Lindenmaier, Goetz ; Langer, > Christoph > > > > > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and > named > > > groups > > > > > > The backport looks fine, except there's a missing blank line after > > FFDHE_2048 > > > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be > > one > > > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > > > security person, so it would be great if someone who is reviews the CSR > to > > > see if there are any 11u-specific issues with it. > > > > > > Thanks, > > > Paul > > > > > > -----Original Message----- > > > From: jdk-updates-dev on > > > behalf of "Doerr, Martin" > > > Date: Wednesday, April 7, 2021 at 9:10 AM > > > To: jdk-updates-dev , security-dev > > > > > > Cc: "Lindenmaier, Goetz" , "Langer, > > > Christoph" > > > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > > > groups > > > > > > Hi, > > > > > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for > parity. > > > It doesn't apply cleanly. I've taken the 13u backport as source because it > > > resolves the wrong backport order with JDK-8242141. > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8226374 > > > > > > 11u CSR: > > > https://bugs.openjdk.java.net/browse/JDK-8264555 > > > > > > Original change (JDK14): > > > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > > > > > 13u backport: > > > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > > > > > 11u rejected hunks (integrated manually): > > > > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > > > > > my new 11u backport: > > > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > > > > > Please review. > > > > > > Best regards, > > > Martin > > > > > > From akolarkunnu at openjdk.java.net Fri Apr 9 11:15:40 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Fri, 9 Apr 2021 11:15:40 GMT Subject: RFR: 8260923: Add more tests for SSLSocket input/output shutdown [v2] In-Reply-To: References: Message-ID: > There is a lack of tests in the area of java.net.Socket.shutdownInput() and java.net.Socket.shutdownOutput() , so added more tests in this area of with different TLS versions. Please review. Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision: 8260923: Add more tests for SSLSocket input/output shutdown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2745/files - new: https://git.openjdk.java.net/jdk/pull/2745/files/f6a41313..b0157da7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2745&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2745&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2745.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2745/head:pull/2745 PR: https://git.openjdk.java.net/jdk/pull/2745 From coffeys at openjdk.java.net Fri Apr 9 11:27:29 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 9 Apr 2021 11:27:29 GMT Subject: RFR: 8260923: Add more tests for SSLSocket input/output shutdown [v2] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 11:15:40 GMT, Abdul Kolarkunnu wrote: >> There is a lack of tests in the area of java.net.Socket.shutdownInput() and java.net.Socket.shutdownOutput() , so added more tests in this area of with different TLS versions. Please review. > > Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision: > > 8260923: Add more tests for SSLSocket input/output shutdown Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2745 From coffeys at openjdk.java.net Fri Apr 9 11:27:29 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 9 Apr 2021 11:27:29 GMT Subject: RFR: 8260923: Add more tests for SSLSocket input/output shutdown In-Reply-To: <7wLKOz0zuJxRxEDVlQvEroHgb50BkhVVY2ZjmBxQwdw=.b23ee12d-cdc8-4b76-9ab4-bd064d075bce@github.com> References: <7wLKOz0zuJxRxEDVlQvEroHgb50BkhVVY2ZjmBxQwdw=.b23ee12d-cdc8-4b76-9ab4-bd064d075bce@github.com> Message-ID: On Tue, 2 Mar 2021 10:31:03 GMT, Abdul Kolarkunnu wrote: >> There is a lack of tests in the area of java.net.Socket.shutdownInput() and java.net.Socket.shutdownOutput() , so added more tests in this area of with different TLS versions. Please review. > > @coffeys Thanks for increasing code coverage here. Looks fine to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2745 From ccleary at openjdk.java.net Fri Apr 9 13:22:38 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Fri, 9 Apr 2021 13:22:38 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI Message-ID: ### Description This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. ### Fixes - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. ------------- Commit messages: - 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI Changes: https://git.openjdk.java.net/jdk/pull/3416/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3416&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8048199 Stats: 75 lines in 5 files changed: 0 ins; 42 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/3416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416 PR: https://git.openjdk.java.net/jdk/pull/3416 From alanb at openjdk.java.net Fri Apr 9 13:33:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 9 Apr 2021 13:33:25 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary wrote: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 401: > 399: return AccessController.doPrivileged( > 400: (PrivilegedAction) () -> System.getProperty(propName, defVal) > 401: ); If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g. PrivilegedAction pa = () -> System.getProperty(propName, defVal); return AccessController.doPrivileged(pa); ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From rriggs at openjdk.java.net Fri Apr 9 13:55:25 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Apr 2021 13:55:25 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary wrote: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. Looks good. A general reminder about one important difference between an anonymous inner class and a lambda. An anonymous has *identity* but a lambda does not; or only accidentally. None of the uses here require identity. src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413: > 411: return AccessController.doPrivileged( > 412: (PrivilegedAction) () -> Long.getLong(propName, defVal).longValue() > 413: ); And GetIntegerAction here. Though it only supports an int value. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From rriggs at openjdk.java.net Fri Apr 9 13:55:26 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Apr 2021 13:55:26 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 13:30:27 GMT, Alan Bateman wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 401: > >> 399: return AccessController.doPrivileged( >> 400: (PrivilegedAction) () -> System.getProperty(propName, defVal) >> 401: ); > > If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g. > > PrivilegedAction pa = () -> System.getProperty(propName, defVal); > return AccessController.doPrivileged(pa); An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default). The package is already exported from java.base to java.desktop, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From ccleary at openjdk.java.net Fri Apr 9 13:55:26 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Fri, 9 Apr 2021 13:55:26 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 13:45:03 GMT, Roger Riggs wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 401: >> >>> 399: return AccessController.doPrivileged( >>> 400: (PrivilegedAction) () -> System.getProperty(propName, defVal) >>> 401: ); >> >> If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g. >> >> PrivilegedAction pa = () -> System.getProperty(propName, defVal); >> return AccessController.doPrivileged(pa); > > An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default). > The package is already exported from java.base to java.desktop, etc. That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake? ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From akolarkunnu at openjdk.java.net Fri Apr 9 14:01:23 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Fri, 9 Apr 2021 14:01:23 GMT Subject: Integrated: 8260923: Add more tests for SSLSocket input/output shutdown In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 11:12:08 GMT, Abdul Kolarkunnu wrote: > There is a lack of tests in the area of java.net.Socket.shutdownInput() and java.net.Socket.shutdownOutput() , so added more tests in this area of with different TLS versions. Please review. This pull request has now been integrated. Changeset: 9bb1863e Author: Abdul Kolarkunnu URL: https://git.openjdk.java.net/jdk/commit/9bb1863e Stats: 59 lines in 1 file changed: 36 ins; 13 del; 10 mod 8260923: Add more tests for SSLSocket input/output shutdown Reviewed-by: coffeys ------------- PR: https://git.openjdk.java.net/jdk/pull/2745 From rriggs at openjdk.java.net Fri Apr 9 14:04:27 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Apr 2021 14:04:27 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 13:51:30 GMT, Conor Cleary wrote: >> An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default). >> The package is already exported from java.base to java.desktop, etc. > > That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. > I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake? Right, not a performance problem. Just simpler to use an existing method to read a privileged property. And there will be one less doPriv. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From ccleary at openjdk.java.net Fri Apr 9 15:44:18 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Fri, 9 Apr 2021 15:44:18 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: <2Gxd3r3g-ZHlCtLt2dCrqCiJPuERgJCRO4umyyHR1pc=.387bd392-ca48-4ff6-b0fc-efd5b81148dc@github.com> On Fri, 9 Apr 2021 14:01:32 GMT, Roger Riggs wrote: >> That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. >> I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake? > > Right, not a performance problem. Just simpler to use an existing method to read a privileged property. > And there will be one less doPriv. I think I may change the PR to reflect what Alan suggested. Its more readable than the lambda-with-cast solution in that an action is created _and then_ an action is carried out as supposed to fitting it all into one call. Its also as concise. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From ccleary at openjdk.java.net Fri Apr 9 15:51:36 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Fri, 9 Apr 2021 15:51:36 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com> On Fri, 9 Apr 2021 13:46:46 GMT, Roger Riggs wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413: > >> 411: return AccessController.doPrivileged( >> 412: (PrivilegedAction) () -> Long.getLong(propName, defVal).longValue() >> 413: ); > > And GetIntegerAction here. Though it only supports an int value. Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods? ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From rriggs at openjdk.java.net Fri Apr 9 16:33:10 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Apr 2021 16:33:10 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com> References: <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com> Message-ID: On Fri, 9 Apr 2021 15:47:35 GMT, Conor Cleary wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413: >> >>> 411: return AccessController.doPrivileged( >>> 412: (PrivilegedAction) () -> Long.getLong(propName, defVal).longValue() >>> 413: ); >> >> And GetIntegerAction here. Though it only supports an int value. > > Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. > > WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods? Its a slippery slope that might require a bit more investigation to check the expected value sizes to see if a change to the number of bits in the value for each property might break something. Technical debt can take you down a rabbit hole. Quickest to just convert to the lamba as you proposed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From mullan at openjdk.java.net Fri Apr 9 16:47:10 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 9 Apr 2021 16:47:10 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 13:32:47 GMT, Weijun Wang wrote: >> This enhancement contains the following code changes: >> >> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. >> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. >> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` >> 4. Tests > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > spec word change, no hashCode and equals, test change src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 74: > 72: * {@code MaskGenerationFunction}, 32 as {@code SaltLength}, and 1 as > 73: * {@code TrailerField}. This is equivalent to the parameter-less signature > 74: * method as defined by http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1. http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 is just a placeholder page for the namespace. I would instead link to `SignatureMethod.SHA256_RSA_MGF1` and also reference the RFC for more information. How about: `This is equivalent to the {@link SignatureMethod#SHA256_RSA_MGF1 parameter-less signature method} as defined in RFC 6931. ` ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From naoto at openjdk.java.net Fri Apr 9 16:58:49 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 9 Apr 2021 16:58:49 GMT Subject: RFR: 8264208: Console charset API Message-ID: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. ------------- Commit messages: - 8264208: Console charset API Changes: https://git.openjdk.java.net/jdk/pull/3419/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264208 Stats: 202 lines in 9 files changed: 174 ins; 17 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Fri Apr 9 17:19:13 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 9 Apr 2021 17:19:13 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider Message-ID: Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. Thanks! Valerie ------------- Commit messages: - 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider Changes: https://git.openjdk.java.net/jdk/pull/3420/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255410 Stats: 1513 lines in 14 files changed: 1406 ins; 30 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/3420.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3420/head:pull/3420 PR: https://git.openjdk.java.net/jdk/pull/3420 From mullan at openjdk.java.net Fri Apr 9 17:26:30 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 9 Apr 2021 17:26:30 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 21:39:28 GMT, Weijun Wang wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> spec word change, no hashCode and equals, test change > > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java line 588: > >> 586: >> 587: public enum DigestAlgorithm { >> 588: // SHA1("SHA-1", DigestMethod.SHA1, 20), > > Do we want to support "SHA-1"? It's considered weak and not the default but the RFC has not disabled it. Since we already have secure validation on by default, it does seem to be a security issue. > > The "RSASSA-PSS without Parameters" section at https://tools.ietf.org/html/rfc6931#section-2.3.10 also lists SHA-224 and SHA3-**. We should probably support them as well, or at least make sure we support the same algorithms in "without Parameters" and "with Parameters". I'm ok with not supporting SHA-1, although adding it would not be a security issue. It is blocked by default now, but it can be re-enabled, and SHA-1 in general is still available in the JDK. I'm fine with adding support for SHA-224 and SHA-3 as part of this issue. You can add support for all the algorithms that we have the underlying crypto support for. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Fri Apr 9 17:32:22 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 9 Apr 2021 17:32:22 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 16:44:07 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> spec word change, no hashCode and equals, test change > > src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 74: > >> 72: * {@code MaskGenerationFunction}, 32 as {@code SaltLength}, and 1 as >> 73: * {@code TrailerField}. This is equivalent to the parameter-less signature >> 74: * method as defined by http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1. > > http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 is just a placeholder page for the namespace. I would instead link to `SignatureMethod.SHA256_RSA_MGF1` and also reference the RFC for more information. How about: > > `This is equivalent to the {@link SignatureMethod#SHA256_RSA_MGF1 parameter-less signature method} as defined in RFC 6931. > ` Correct. How about: This is equivalent to the parameter-less signature method {@link SignatureMethod#SHA256_RSA_MGF1 SHA256_RSA_MGF1} as defined in RFC 6931. SHA256_RSA_MGF1 is not the only parameter-less method so I prefer showing its name. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From valeriep at openjdk.java.net Fri Apr 9 17:33:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 9 Apr 2021 17:33:07 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v2] In-Reply-To: References: Message-ID: > Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Removed CKM_CHACHA20 when registering ChaCha20 SecretKeyFactory service ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3420/files - new: https://git.openjdk.java.net/jdk/pull/3420/files/5702b63b..d0f16238 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3420.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3420/head:pull/3420 PR: https://git.openjdk.java.net/jdk/pull/3420 From xuelei at openjdk.java.net Fri Apr 9 19:29:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 9 Apr 2021 19:29:50 GMT Subject: RFR: 8264948: Check for TLS extensions total length [v2] In-Reply-To: References: Message-ID: > To improve the readability, it would be nice to check the TLS extensions total length while parsing. > > No new regression test, trial update. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Change to use decode_error for incorrect extension length ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3405/files - new: https://git.openjdk.java.net/jdk/pull/3405/files/5332d35d..1fa255c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3405&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3405&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3405.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3405/head:pull/3405 PR: https://git.openjdk.java.net/jdk/pull/3405 From xuelei at openjdk.java.net Fri Apr 9 19:29:54 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 9 Apr 2021 19:29:54 GMT Subject: RFR: 8264948: Check for TLS extensions total length [v2] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 05:55:40 GMT, Jamil Nimeh wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Change to use decode_error for incorrect extension length > > src/java.base/share/classes/sun/security/ssl/SSLExtensions.java line 68: > >> 66: Alert.ILLEGAL_PARAMETER, >> 67: "Insufficient extensions data"); >> 68: } > > For both of these blocks the checks themselves look OK, but illegal_parameter I thought was more for cases where a field value is out of range or inconsistent with already negotiated parameters. I would think that decode_error would be more appropriate to cases like this where the encoding is structurally incorrect and the length doesn't match the actual data size. Good catch! Updated to use decode_error. ------------- PR: https://git.openjdk.java.net/jdk/pull/3405 From joehw at openjdk.java.net Fri Apr 9 19:34:21 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 9 Apr 2021 19:34:21 GMT Subject: RFR: 8264208: Console charset API In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com> On Fri, 9 Apr 2021 16:47:55 GMT, Naoto Sato wrote: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Marked as reviewed by joehw (Reviewer). src/java.base/share/classes/java/io/Console.java line 404: > 402: * > 403: * @return A {@code Charset} object used in this {@code Console}. > 404: * @since 17 A couple of minor comments: May replace {@code Charset} with @link; Add "the" to the sentence: The returned charset corresponds to "the" input... @return: javadoc guide suggests "do not capitalize and do not end with a period" when writing a phrase. But I guess for consistency in this class, it's okay to capitalize. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From mullan at openjdk.java.net Fri Apr 9 19:53:09 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 9 Apr 2021 19:53:09 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:28:45 GMT, Weijun Wang wrote: >> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 74: >> >>> 72: * {@code MaskGenerationFunction}, 32 as {@code SaltLength}, and 1 as >>> 73: * {@code TrailerField}. This is equivalent to the parameter-less signature >>> 74: * method as defined by http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1. >> >> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 is just a placeholder page for the namespace. I would instead link to `SignatureMethod.SHA256_RSA_MGF1` and also reference the RFC for more information. How about: >> >> `This is equivalent to the {@link SignatureMethod#SHA256_RSA_MGF1 parameter-less signature method} as defined in RFC 6931. >> ` > > Correct. > > How about: > This is equivalent to the parameter-less signature > method {@link SignatureMethod#SHA256_RSA_MGF1 SHA256_RSA_MGF1} as defined > in RFC 6931. > > SHA256_RSA_MGF1 is not the only parameter-less method so I prefer showing its name. Works for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Fri Apr 9 19:57:21 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 9 Apr 2021 19:57:21 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:23:05 GMT, Sean Mullan wrote: >> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java line 588: >> >>> 586: >>> 587: public enum DigestAlgorithm { >>> 588: // SHA1("SHA-1", DigestMethod.SHA1, 20), >> >> Do we want to support "SHA-1"? It's considered weak and not the default but the RFC has not disabled it. Since we already have secure validation on by default, it does seem to be a security issue. >> >> The "RSASSA-PSS without Parameters" section at https://tools.ietf.org/html/rfc6931#section-2.3.10 also lists SHA-224 and SHA3-**. We should probably support them as well, or at least make sure we support the same algorithms in "without Parameters" and "with Parameters". > > I'm ok with not supporting SHA-1, although adding it would not be a security issue. It is blocked by default now, but it can be re-enabled, and SHA-1 in general is still available in the JDK. > > I'm fine with adding support for SHA-224 and SHA-3 as part of this issue. You can add support for all the algorithms that we have the underlying crypto support for. Not sure if I got it, are you OK with adding SHA-1? It must be listed here to be supported. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From mullan at openjdk.java.net Fri Apr 9 20:55:12 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 9 Apr 2021 20:55:12 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 19:54:22 GMT, Weijun Wang wrote: >> I'm ok with not supporting SHA-1, although adding it would not be a security issue. It is blocked by default now, but it can be re-enabled, and SHA-1 in general is still available in the JDK. >> >> I'm fine with adding support for SHA-224 and SHA-3 as part of this issue. You can add support for all the algorithms that we have the underlying crypto support for. > > Not sure if I got it, are you OK with adding SHA-1? It must be listed here to be supported. Let's not add it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From naoto at openjdk.java.net Fri Apr 9 21:06:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 9 Apr 2021 21:06:03 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com> Message-ID: <4k7yjIhZ_ZaZ7o617B5Ijmf0osdKHppduwmZpVFWeAA=.63b03ee3-ea9c-4c7b-aec9-13ca8c675fa1@github.com> On Fri, 9 Apr 2021 19:25:02 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflected the review comments. > > src/java.base/share/classes/java/io/Console.java line 404: > >> 402: * >> 403: * @return A {@code Charset} object used in this {@code Console}. >> 404: * @since 17 > > A couple of minor comments: > May replace {@code Charset} with @link; > Add "the" to the sentence: The returned charset corresponds to "the" input... > @return: javadoc guide suggests "do not capitalize and do not end with a period" when writing a phrase. But I guess for consistency in this class, it's okay to capitalize. Thanks, Joe. Modified as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Fri Apr 9 21:06:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 9 Apr 2021 21:06:00 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflected the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From hai-may.chao at oracle.com Fri Apr 9 21:12:42 2021 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 9 Apr 2021 14:12:42 -0700 Subject: RFR: Release Note for JDK-8264968 Provide the support for specifying a signer in keytool -genkeypair command Message-ID: Please review the release note for JDK-8264968: https://bugs.openjdk.java.net/browse/JDK-8264968 Thanks, Hai-May From jnimeh at openjdk.java.net Fri Apr 9 22:06:29 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Fri, 9 Apr 2021 22:06:29 GMT Subject: RFR: 8264948: Check for TLS extensions total length [v2] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 19:29:50 GMT, Xue-Lei Andrew Fan wrote: >> To improve the readability, it would be nice to check the TLS extensions total length while parsing. >> >> No new regression test, trial update. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Change to use decode_error for incorrect extension length Looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3405 From joehw at openjdk.java.net Fri Apr 9 22:21:25 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 9 Apr 2021 22:21:25 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: <4k7yjIhZ_ZaZ7o617B5Ijmf0osdKHppduwmZpVFWeAA=.63b03ee3-ea9c-4c7b-aec9-13ca8c675fa1@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <__ihL9ryNtSo-eJ_qsADX-CYWLkU9MyJreehabFPu6o=.181ffcb4-1d8b-4172-aaae-c103c0156f9c@github.com> <4k7yjIhZ_ZaZ7o617B5Ijmf0osdKHppduwmZpVFWeAA=.63b03ee3-ea9c-4c7b-aec9-13ca8c675fa1@github.com> Message-ID: On Fri, 9 Apr 2021 21:02:26 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 404: >> >>> 402: * >>> 403: * @return A {@code Charset} object used in this {@code Console}. >>> 404: * @since 17 >> >> A couple of minor comments: >> May replace {@code Charset} with @link; >> Add "the" to the sentence: The returned charset corresponds to "the" input... >> @return: javadoc guide suggests "do not capitalize and do not end with a period" when writing a phrase. But I guess for consistency in this class, it's okay to capitalize. > > Thanks, Joe. Modified as suggested. Thanks. Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From joehw at openjdk.java.net Fri Apr 9 22:21:24 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 9 Apr 2021 22:21:24 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> Message-ID: On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflected the review comments. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Fri Apr 9 22:57:28 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 9 Apr 2021 22:57:28 GMT Subject: RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 21:52:43 GMT, Martin Balao wrote: >> Hi, >> >> I'd like to propose a fix for JDK-8261355 [1]. >> >> The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. >> >> No regressions observed in jdk/sun/security/pkcs11. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Minor comment enhancement Looks fine, thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2510 From weijun at openjdk.java.net Fri Apr 9 23:18:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 9 Apr 2021 23:18:08 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v4] In-Reply-To: References: Message-ID: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more digest methods and spec change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3181/files - new: https://git.openjdk.java.net/jdk/pull/3181/files/5b88fff4..82c29fea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=02-03 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3181/head:pull/3181 PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Fri Apr 9 23:18:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 9 Apr 2021 23:18:08 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params In-Reply-To: References: Message-ID: <4CLDmNQA23-QnpmxFum4G9yiamXi-mUbKVgP-yioZI0=.e169b876-118e-4fda-aa4c-b63051aec036@github.com> On Wed, 24 Mar 2021 21:36:21 GMT, Weijun Wang wrote: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests New commit pushed and CSR at https://bugs.openjdk.java.net/browse/JDK-8259575 updated. How do you find the `@implSpec` and `@implNote` in `RSAPSSParameterSpec.java`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From ecki at zusammenkunft.net Sat Apr 10 00:21:48 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 10 Apr 2021 00:21:48 +0000 Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com>, <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> Message-ID: Hello, I like the API, it is useful, however not enough to replace the defaultCharset once the Change to UTF8 is done. You still need a way to query the platforms file encoding (especially on Windows). Also I wonder if the Javadoc needs to discuss platform aspects of console, especially System.out and LANG on unix vs. windows. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Naoto Sato Gesendet: Friday, April 9, 2021 11:06:00 PM An: core-libs-dev at openjdk.java.net ; security-dev at openjdk.java.net Betreff: Re: RFR: 8264208: Console charset API [v2] > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflected the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Sat Apr 10 03:52:11 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 10 Apr 2021 03:52:11 GMT Subject: Integrated: 8264948: Check for TLS extensions total length In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 04:55:14 GMT, Xue-Lei Andrew Fan wrote: > To improve the readability, it would be nice to check the TLS extensions total length while parsing. > > No new regression test, trial update. This pull request has now been integrated. Changeset: 5784f6b7 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/5784f6b7 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod 8264948: Check for TLS extensions total length Reviewed-by: jnimeh ------------- PR: https://git.openjdk.java.net/jdk/pull/3405 From alanb at openjdk.java.net Sun Apr 11 13:47:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 11 Apr 2021 13:47:43 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> Message-ID: On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflected the review comments. src/java.base/share/classes/java/io/Console.java line 397: > 395: /** > 396: * Returns the {@link java.nio.charset.Charset Charset} object used in > 397: * this {@code Console}. The Console is a singleton and the existing methods use "the console" so I think we should do the same here. We'll need to add to the description of the System.{in,out,err} fields, I don't mind if we do it as part of this PR or another issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From shade at openjdk.java.net Mon Apr 12 06:19:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Apr 2021 06:19:02 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security In-Reply-To: References: Message-ID: <4tWvLKqqgdARSgKZxa7gn-lwpzifDgXkF3jWGSIOpHg=.19632b96-ee23-4348-b868-722068a4802c@github.com> On Sat, 3 Apr 2021 22:09:55 GMT, Alex Blewitt wrote: > 8264681: Use the blessed modifier order in java.security I think some review comments from Sean were left unaddressed... ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3338 From shade at openjdk.java.net Mon Apr 12 06:19:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Apr 2021 06:19:05 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:02:20 GMT, Sean Mullan wrote: >> 8264681: Use the blessed modifier order in java.security > > src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java line 390: > >> 388: } >> 389: >> 390: public abstract PSSParameterSpec getPSSParameterSpec(); > > This is 3rd-party (Apache) code. It would be better to change this at Apache. I would leave this one out. @alblue, this is the unresolved comment. Please fix it? > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Constants.java line 53: > >> 51: >> 52: /** >> 53: * This class holds only static final member variables that are constants > > Probably best to leave this file unchanged as it is 3rd-party code. Same here... ------------- PR: https://git.openjdk.java.net/jdk/pull/3338 From github.com+30433125+djelinski at openjdk.java.net Mon Apr 12 06:55:08 2021 From: github.com+30433125+djelinski at openjdk.java.net (djelinski) Date: Mon, 12 Apr 2021 06:55:08 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 20:52:57 GMT, Xue-Lei Andrew Fan wrote: > As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. > > The handshake status could have more precise status if the out bound. The patch was confirmed by the bug submitter. Would it be possible to add a test for that? src/java.base/share/classes/sun/security/ssl/TransportContext.java line 590: > 588: HandshakeStatus getHandshakeStatus() { > 589: if (!outputRecord.isEmpty()) { > 590: // If no handshaking, special case to wrap alters or Suggestion: // If not handshaking, special case to wrap alerts or src/java.base/share/classes/sun/security/ssl/TransportContext.java line 592: > 590: // If no handshaking, special case to wrap alters or > 591: // post-handshake messages. > 592: if (!isOutboundClosed()) { If I'm reading the [TransportContect#closeNotify](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/src/java.base/share/classes/sun/security/ssl/TransportContext.java#L275) and [TransportContext#passiveInboundClose](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/src/java.base/share/classes/sun/security/ssl/TransportContext.java#L524) correctly, non-empty output record with both inbound and outbound closed happens when we reply with our close_notify to peer's. Now we will return NOT_HANDSHAKING which appears to be wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From github.com+76791+alblue at openjdk.java.net Mon Apr 12 09:20:45 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Mon, 12 Apr 2021 09:20:45 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 22:09:55 GMT, Alex Blewitt wrote: > 8264681: Use the blessed modifier order in java.security Sorry, thought those changes had been removed. Let me fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3338 From github.com+76791+alblue at openjdk.java.net Mon Apr 12 09:32:13 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Mon, 12 Apr 2021 09:32:13 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security [v2] In-Reply-To: References: Message-ID: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> > 8264681: Use the blessed modifier order in java.security Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: Removed upstream licensed code from commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3338/files - new: https://git.openjdk.java.net/jdk/pull/3338/files/d91bdba9..3e9047f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3338&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3338&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3338/head:pull/3338 PR: https://git.openjdk.java.net/jdk/pull/3338 From github.com+76791+alblue at openjdk.java.net Mon Apr 12 10:14:45 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Mon, 12 Apr 2021 10:14:45 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security [v2] In-Reply-To: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> References: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> Message-ID: On Mon, 12 Apr 2021 09:32:13 GMT, Alex Blewitt wrote: >> 8264681: Use the blessed modifier order in java.security > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Removed upstream licensed code from commit Did a search of the files included in the commit, didn't see anything other than the two above without the standard Oracle copyright . Wasn't sure about `src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ATTRIBUTE.java` though; it has an Oracle copyright on it (and not the 'do not alter') one. Should I remove that one from this commit as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3338 From mullan at openjdk.java.net Mon Apr 12 12:45:49 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 12 Apr 2021 12:45:49 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:34:39 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> update XMLUtils (not used by tests here) > > src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 139: > >> 137: >> 138: @Override >> 139: public String toString() { > > Add specification. Actually, on second thought, I don't think we should override `toString`. None of the other spec classes override `toString`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From mullan at openjdk.java.net Mon Apr 12 13:26:46 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 12 Apr 2021 13:26:46 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 23:18:08 GMT, Weijun Wang wrote: >> This enhancement contains the following code changes: >> >> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. >> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. >> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` >> 4. Tests > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more digest methods and spec change > New commit pushed and CSR at https://bugs.openjdk.java.net/browse/JDK-8259575 updated. How do you find the `@implSpec` and `@implNote` in `RSAPSSParameterSpec.java`? The `@implSpec` looks good. I view the `@implNote` more like an `@apiNote` though. test/lib/jdk/test/lib/security/XMLUtils.java line 63: > 61: import java.security.spec.PSSParameterSpec; > 62: import java.util.*; > 63: Can you add some comments about this class, e.g., "A collection of test utility methods for parsing, validating and generating XML Signatures". test/lib/jdk/test/lib/security/XMLUtils.java line 100: > 98: //////////// CONVERT //////////// > 99: > 100: public static String doc2string(Document doc) throws Exception { Add method description. test/lib/jdk/test/lib/security/XMLUtils.java line 111: > 109: } > 110: > 111: public static Document string2doc(String input) throws Exception { Add method description. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From ccleary at openjdk.java.net Mon Apr 12 14:09:55 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Mon, 12 Apr 2021 14:09:55 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: References: Message-ID: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: - Update copyright headers - Tidied up lambdas ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3416/files - new: https://git.openjdk.java.net/jdk/pull/3416/files/f0c2238a..840ea35c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3416&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3416&range=00-01 Stats: 29 lines in 5 files changed: 1 ins; 7 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416 PR: https://git.openjdk.java.net/jdk/pull/3416 From ccleary at openjdk.java.net Mon Apr 12 14:09:56 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Mon, 12 Apr 2021 14:09:56 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: References: <1sJidHe6B9avCln-Fqqklfv4TKrXL64_utx21MprrYk=.817a96d0-71db-4dec-9dfa-8d66b5854452@github.com> Message-ID: On Fri, 9 Apr 2021 16:30:05 GMT, Roger Riggs wrote: >> Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. >> >> WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods? > > Its a slippery slope that might require a bit more investigation to check the expected value sizes to see if a change to the number of bits in the value for each property might break something. Technical debt can take you down a rabbit hole. Quickest to just convert to the lamba as you proposed. I have stuck with the lambda conversion solution in the [current changes](https://github.com/openjdk/jdk/pull/3416/commits/1746840eaa9a8de34d89d73d993e2f86aa0d0ed3), however WRT to Alan's previous feedback on creating a PrivilegedAction explicitly as it makes everything a bit more readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From weijun at openjdk.java.net Mon Apr 12 14:54:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 12 Apr 2021 14:54:41 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v4] In-Reply-To: References: Message-ID: <3pIqD2rGaTOGBAoe54OgzTpr7DjT-M-CO-hJbA6j72A=.ae7d2dfd-fc3b-47b3-8954-9be41607f044@github.com> On Mon, 12 Apr 2021 13:23:44 GMT, Sean Mullan wrote: > The `@implSpec` looks good. I view the `@implNote` more like an `@apiNote` though. API notes are for "[commentary, rationale, or examples pertaining to the API](https://bugs.openjdk.java.net/browse/JDK-8068562)". I'm not sure if `getParameterSpec()` must always return a non-null object when algorithm is RSASSA-PSS. The spec says "may be null if not specified". So I used "In this implementation". > test/lib/jdk/test/lib/security/XMLUtils.java line 63: > >> 61: import java.security.spec.PSSParameterSpec; >> 62: import java.util.*; >> 63: > > Can you add some comments about this class, e.g., "A collection of test utility methods for parsing, validating and generating XML Signatures". OK for this and the next two. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Mon Apr 12 15:08:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 12 Apr 2021 15:08:42 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 12:42:23 GMT, Sean Mullan wrote: >> src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/RSAPSSParameterSpec.java line 139: >> >>> 137: >>> 138: @Override >>> 139: public String toString() { >> >> Add specification. > > Actually, on second thought, I don't think we should override `toString`. None of the other spec classes override `toString`. I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Mon Apr 12 15:25:09 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 12 Apr 2021 15:25:09 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v5] In-Reply-To: References: Message-ID: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: no RSAPSSParameterSpec::toString and some test comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3181/files - new: https://git.openjdk.java.net/jdk/pull/3181/files/82c29fea..ce1678ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=03-04 Stats: 34 lines in 2 files changed: 15 ins; 15 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3181/head:pull/3181 PR: https://git.openjdk.java.net/jdk/pull/3181 From mullan at openjdk.java.net Mon Apr 12 15:34:40 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 12 Apr 2021 15:34:40 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security [v2] In-Reply-To: References: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> Message-ID: On Mon, 12 Apr 2021 10:12:06 GMT, Alex Blewitt wrote: > Did a search of the files included in the commit, didn't see anything other than the two above without the standard Oracle copyright . > > Wasn't sure about `src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_ATTRIBUTE.java` though; it has an Oracle copyright on it (and not the 'do not alter') one. Should I remove that one from this commit as well? This one should be ok. We have already made changes to this file so preserving pure parity with the 3rd party sources is not an overriding concern. ------------- PR: https://git.openjdk.java.net/jdk/pull/3338 From dfuchs at openjdk.java.net Mon Apr 12 16:16:39 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 12 Apr 2021 16:16:39 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> Message-ID: On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright headers > - Tidied up lambdas LGTM src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 400: > 398: private static final String getProperty(final String propName, final String defVal) { > 399: PrivilegedAction pa = () -> System.getProperty(propName, defVal); > 400: return AccessController.doPrivileged(pa); Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3416 From aefimov at openjdk.java.net Mon Apr 12 16:56:42 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Mon, 12 Apr 2021 16:56:42 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> Message-ID: <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com> On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright headers > - Tidied up lambdas The change looks good to me with one small suggestion: src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223: > 221: */ > 222: private final ClassLoader getContextClassLoader() { > 223: PrivilegedAction pa = () -> Thread.currentThread().getContextClassLoader(); We can use here an instance method reference to beautify code a little bit more: ```PrivilegedAction pa = Thread.currentThread()::getContextClassLoader;``` ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/3416 From mullan at openjdk.java.net Mon Apr 12 17:37:29 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 12 Apr 2021 17:37:29 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: <_-zU9sQFME5GaU1_tSs2TAUuOkOxk4REAbRo46DTwMA=.a814b3d5-fe64-4ca4-a9a1-3a43685259f5@github.com> References: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com> <_-zU9sQFME5GaU1_tSs2TAUuOkOxk4REAbRo46DTwMA=.a814b3d5-fe64-4ca4-a9a1-3a43685259f5@github.com> Message-ID: <6V0tGnzyowoBbSrS5zWmzff2XakLYTwUtqCohmVxKdo=.34c3e075-c3a0-4188-804d-d2e63bb539f7@github.com> On Thu, 1 Apr 2021 13:29:42 GMT, Weijun Wang wrote: >> I'm not sure if it's appropriate to specify the default value in this method. As long as there is an `RSAPSSParameterSpec` object, there must be a non-null `PSSParameterSpec` inside and it is the one that was used to construct this object. >> >> I am thinking if we can append the following to the `@implSpec` in the class spec: >> >> * One can obtain this default value using the following expression: >> *

>>  * XMLSignatureFactory.getInstance()
>>  *      .newSignatureMethod(SignatureMethod.RSA_PSS, null)
>>  *      .getParameterSpec()
>>  * 
>> >> >> but this makes it more like an `@implNote` instead of an `@implSpec`. > > I added the new lines as `@implNote` and kept the old `@implSpec` there (since it's still a requirement for implementations). New commit pushed. CSR updated as well. Ok, I understand now. I think `@implSpec` (and probably the `@implNote`) are in the wrong class. `@implSpec` means the implementation of this class. But this class is final and does not contain that logic. The logic of specifying/returning the defaults is in the JDK (XMLDSig provider) implementation of `SignatureMethod`. So I think it belongs there. In this class, you could add a sentence/link to `SignatureMethod`, something like "See SignatureMethod for how default values are determined when the parameters are not specified." Also, I think the `@implSpec` needs to be more specific, and also cover the cases where some, but not all of the parameters are specified and defaults are then used. For this, you will need to be more general, as the default salt length is based on what hash algorithm is being used. As for `@implNote`, this probably could use more discussion, but it might be better to make this part of the specification. If some implementations can return null, and others return defaults, it complicates the application's logic. The RFC has clearly specified what the defaults should be, so maybe the easiest thing to do is to make all implementations comply by also making it part of the API contract, and hiding the XML details as to whether the parameter was actually specified or not, which should not matter to applications. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From rriggs at openjdk.java.net Mon Apr 12 17:37:28 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 12 Apr 2021 17:37:28 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> Message-ID: On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright headers > - Tidied up lambdas Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From chegar at openjdk.java.net Mon Apr 12 18:41:30 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 12 Apr 2021 18:41:30 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> Message-ID: <_GNd3qUOe-dSf-ZjSVe0SieHKlaJys9Ue8kbLl9Ai0Q=.430a49bc-b581-46c4-9290-47d3596c73f2@github.com> On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright headers > - Tidied up lambdas Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From valeriep at openjdk.java.net Mon Apr 12 20:52:57 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 12 Apr 2021 20:52:57 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v2] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:33:07 GMT, Valerie Peng wrote: >> Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. >> >> Thanks! >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Removed CKM_CHACHA20 when registering ChaCha20 SecretKeyFactory service Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8265008 Thanks! Valerie ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From weijun at openjdk.java.net Mon Apr 12 20:57:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 12 Apr 2021 20:57:39 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: <6V0tGnzyowoBbSrS5zWmzff2XakLYTwUtqCohmVxKdo=.34c3e075-c3a0-4188-804d-d2e63bb539f7@github.com> References: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com> <_-zU9sQFME5GaU1_tSs2TAUuOkOxk4REAbRo46DTwMA=.a814b3d5-fe64-4ca4-a9a1-3a43685259f5@github.com> <6V0tGnzyowoBbSrS5zWmzff2XakLYTwUtqCohmVxKdo=.34c3e075-c3a0-4188-804d-d2e63bb539f7@github.com> Message-ID: On Mon, 12 Apr 2021 17:29:55 GMT, Sean Mullan wrote: >> I added the new lines as `@implNote` and kept the old `@implSpec` there (since it's still a requirement for implementations). New commit pushed. CSR updated as well. > > Ok, I understand now. I think `@implSpec` (and probably the `@implNote`) are in the wrong class. `@implSpec` means the implementation of this class. But this class is final and does not contain that logic. The logic of specifying/returning the defaults is in the JDK (XMLDSig provider) implementation of `SignatureMethod`. So I think it belongs there. In this class, you could add a sentence/link to `SignatureMethod`, something like "See SignatureMethod for how default values are determined when the parameters are not specified." > > Also, I think the `@implSpec` needs to be more specific, and also cover the cases where some, but not all of the parameters are specified and defaults are then used. For this, you will need to be more general, as the default salt length is based on what hash algorithm is being used. > > As for `@implNote`, this probably could use more discussion, but it might be better to make this part of the specification. If some implementations can return null, and others return defaults, it complicates the application's logic. The RFC has clearly specified what the defaults should be, so maybe the easiest thing to do is to make all implementations comply by also making it part of the API contract, and hiding the XML details as to whether the parameter was actually specified or not, which should not matter to applications. You are right that the overridable methods are elsewhere (`XMLSignatureFactory::newSignatureMethod` and `SignatureMethod::getParameterSpec`), but I still feel it a little strange to move the default parameter of one particular algorithm to the general interface `SignatureMethod` (this is similar to talking about EC curve names in `KeyPairGenerator`). It seems more natural to talk about this inside a class which is specific to the RSASSA-PSS algorithm and `RSAPSSParameterSpec` is the only public API we can find. We can add something like "specify null if you want a default spec" to `XMLSignatureFactory::newSignatureMethod` but it does not have enough space to describe "how default values are determined" for each algorithm. I understand `@implSpec` is for implementations of a class or a method, but does not mean the words must be put inside that exact class and method? Maybe not necessarily. As for making `@implSpec` more specific, at signing time, we can only either provide a `RSAPSSParameterSpec` or not one, so there is only one default value which is SHA256_RSA_MGF1. On the other hand, at validation time we might be parsing a partial-filled `RSAPSSParams` node and that's where default salt and default trailer field show up. Also about the return value of `SignatureMethod::getParameterSpec`, are you suggesting that for RSASSA-PSS it must be non null? This can be specified somewhere but we need to find a place. For the existing `HMACParameterSpec`, the method returns null if none is set. Do we treat that as no spec at all (but for RSASSA-PSS there is always one)? My current opinion is that we still document all these in `RSAPSSParameterSpec` but be very clear that this part is for `XMLSignatureFactory::newSignatureMethod` and that part is for `SignatureMethod::getParameterSpec`, etc, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From mbalao at openjdk.java.net Mon Apr 12 20:57:47 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Mon, 12 Apr 2021 20:57:47 GMT Subject: Withdrawn: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 15:06:35 GMT, Martin Balao wrote: > Hi, > > I'd like to propose a fix for JDK-8261355 [1]. > > The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. > > No regressions observed in jdk/sun/security/pkcs11. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From mbalao at openjdk.java.net Mon Apr 12 21:03:41 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Mon, 12 Apr 2021 21:03:41 GMT Subject: Integrated: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 15:06:35 GMT, Martin Balao wrote: > Hi, > > I'd like to propose a fix for JDK-8261355 [1]. > > The scheme used for holding data and padding while performing encryption operations is almost the same than the existing one for decryption. The only difference is that encryption does not require a block-sized buffer to be always held because there is no need, upon an update call, to determine which bytes are real output for the caller and which are padding -as it's required for decryption-. I added a couple of comments in implUpdate to explain this. > > No regressions observed in jdk/sun/security/pkcs11. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 This pull request has now been integrated. Changeset: 1ee80e03 Author: Martin Balao URL: https://git.openjdk.java.net/jdk/commit/1ee80e03 Stats: 245 lines in 2 files changed: 163 ins; 29 del; 53 mod 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/2510 From fguallini at openjdk.java.net Mon Apr 12 21:08:54 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Mon, 12 Apr 2021 21:08:54 GMT Subject: Integrated: 8264190: Harden TLS interop tests In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 15:31:43 GMT, Fernando Guallini wrote: > Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate intermittent failures, this patch updates interop/BaseInteropTest.java in order to validate the server is alive and if not, retry to create a valid server. > > In addition, Utilities::isSessionResumed implementation is now comparing equality of first and second session creation time to validate session resumption This pull request has now been integrated. Changeset: f4e63957 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/f4e63957 Stats: 169 lines in 5 files changed: 114 ins; 43 del; 12 mod 8264190: Harden TLS interop tests Reviewed-by: rhalade ------------- PR: https://git.openjdk.java.net/jdk/pull/3218 From naoto at openjdk.java.net Mon Apr 12 21:15:18 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 12 Apr 2021 21:15:18 GMT Subject: RFR: 8264208: Console charset API [v3] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/8fd8f6e6..c172d0a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=01-02 Stats: 33 lines in 2 files changed: 3 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Mon Apr 12 21:15:19 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 12 Apr 2021 21:15:19 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> Message-ID: On Sun, 11 Apr 2021 13:44:05 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflected the review comments. > > src/java.base/share/classes/java/io/Console.java line 397: > >> 395: /** >> 396: * Returns the {@link java.nio.charset.Charset Charset} object used in >> 397: * this {@code Console}. > > The Console is a singleton and the existing methods use "the console" so I think we should do the same here. > > We'll need to add to the description of the System.{in,out,err} fields, I don't mind if we do it as part of this PR or another issue. Javadoc updated. Instead of modifying System.out/err (System.in is not affected, as it does not convert b2c), I modified PrintStream javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Mon Apr 12 23:01:24 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 12 Apr 2021 23:01:24 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reverted PrintStream changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/c172d0a1..68db1a79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=02-03 Stats: 50 lines in 2 files changed: 8 ins; 9 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Mon Apr 12 23:01:25 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 12 Apr 2021 23:01:25 GMT Subject: RFR: 8264208: Console charset API [v2] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <3EyP3ItWxdLn49PTwDDP7Z-TJ5AKP-kb34HSCZYsy9E=.e33c7c8b-4029-438d-a6c3-2e7a05371784@github.com> Message-ID: <2OM-k59QZOx9ankM6iryhlGwX7Y3YfAIUpQux3gPuWs=.c94fc3f6-2256-4e98-9820-95dffb05244d@github.com> On Mon, 12 Apr 2021 21:12:08 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 397: >> >>> 395: /** >>> 396: * Returns the {@link java.nio.charset.Charset Charset} object used in >>> 397: * this {@code Console}. >> >> The Console is a singleton and the existing methods use "the console" so I think we should do the same here. >> >> We'll need to add to the description of the System.{in,out,err} fields, I don't mind if we do it as part of this PR or another issue. > > Javadoc updated. Instead of modifying System.out/err (System.in is not affected, as it does not convert b2c), I modified PrintStream javadoc. Reverted the changes to PrintStream, as it defaults to Charset.defaultCharset(). Added descriptions to System.out/err instead (and modified the impl). ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Tue Apr 13 01:00:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 13 Apr 2021 01:00:43 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v5] In-Reply-To: References: Message-ID: > This change updates SunJCE provider as below: > - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. > - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. > > Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. > > Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Changed AESParameters to allow 4-byte, 8-byte IVs and removed KWParameters and KWPParameters. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2404/files - new: https://git.openjdk.java.net/jdk/pull/2404/files/e4fd6ea2..eec0dab6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=03-04 Stats: 211 lines in 6 files changed: 16 ins; 186 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404 PR: https://git.openjdk.java.net/jdk/pull/2404 From joehw at openjdk.java.net Tue Apr 13 02:37:59 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 13 Apr 2021 02:37:59 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com> On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reverted PrintStream changes src/java.base/share/classes/java/lang/System.java line 2020: > 2018: setIn0(new BufferedInputStream(fdIn)); > 2019: setOut0(newPrintStream(fdOut, cs)); > 2020: setErr0(newPrintStream(fdErr, cs)); It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change? ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Tue Apr 13 04:47:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 13 Apr 2021 04:47:00 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: References: Message-ID: <8RZqBr31pwc2KKvFm6ETx5jkDnrrA0HDL1GWIRpmX0A=.7dbfa5cd-90a6-402c-aece-865b9d948e22@github.com> On Sat, 27 Mar 2021 03:54:24 GMT, Greg Rubin wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor code to reduce code duplication >> Address review comments >> Add more test vectors > > src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 78: > >> 76: for (int k = 5; k < SEMI_BLKSIZE; k++) { >> 77: if (outLen != 0) { >> 78: outLen <<= SEMI_BLKSIZE; > > While technically, this is correct (as it is shifting by 8 bits), it is pure coincidence that `SEMI_BLKSIZE` (8 bytes) happens to have the name integer value as the number of bits in one byte. It took me more reads than I care to admit to understand why this worked. Could we just replace this one with an `8` as it is clearer and more accurate? Yes, makes sense. I will update it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From valeriep at openjdk.java.net Tue Apr 13 05:08:58 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 13 Apr 2021 05:08:58 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v3] In-Reply-To: References: Message-ID: <6DFldQr0ZFjJQpTDSBeq7Npmwg9Fij1yUbbr8vY71Lc=.72ac8747-93c8-46b6-add8-5d0fa3de53b7@github.com> On Tue, 23 Mar 2021 19:14:16 GMT, Greg Rubin wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed AlgorithmParameters impls to register under AES/KW/NoPadding and >> AES/KWP/NoPadding > > test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java line 50: > >> 48: >> 49: System.out.println("input len: " + inLen); >> 50: c.init(Cipher.ENCRYPT_MODE, KEY, new IvParameterSpec(in, 0, ivLen)); > > Do we have tests for no IV (and thus the default)? > Do we have tests that the null (default) IV matches the results from an explicitly provided default ID? In NISTWrapKAT.java, all of its test vectors do not use custom IV. So, the default IV scenario for KW and KWP are covered there. I can add another init(...) call which sets the IV based on the current IV to that test. ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From valeriep at openjdk.java.net Tue Apr 13 06:04:58 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 13 Apr 2021 06:04:58 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v4] In-Reply-To: References: Message-ID: On Sat, 27 Mar 2021 03:51:40 GMT, Greg Rubin wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor code to reduce code duplication >> Address review comments >> Add more test vectors > > src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 71: > >> 69: match &= (ivAndLen[i] == iv[i]); >> 70: } >> 71: if (!match) { > > True nitpick (thus ignorable): I believe that using bitwise math is slightly more resistant to compiler and/or CPU optimization to defend against timing-attacks. (Since I haven't even seen an attack against KW or KWP, this is simply a note in general rather than something which needs to be fixed.) Sure, I can change to below: Suggestion: int match = 0; for (int i = 0; i < ICV2.length; i++) { match |= (ivAndLen[i] ^ iv[i]); } if (match != 0) { throw new IllegalBlockSizeException("Integrity check failed"); } Is this what you have in mind? ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From ccleary at openjdk.java.net Tue Apr 13 09:36:58 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 13 Apr 2021 09:36:58 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com> References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com> Message-ID: On Mon, 12 Apr 2021 16:44:16 GMT, Aleksei Efimov wrote: >> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright headers >> - Tidied up lambdas > > src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223: > >> 221: */ >> 222: private final ClassLoader getContextClassLoader() { >> 223: PrivilegedAction pa = () -> Thread.currentThread().getContextClassLoader(); > > We can use here an instance method reference to beautify code a little bit more: > ```PrivilegedAction pa = Thread.currentThread()::getContextClassLoader;``` Good idea, also would fit in with the style of the method just after, `priviligedHasNext()` as that also uses a functional interface. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From ccleary at openjdk.java.net Tue Apr 13 10:04:20 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 13 Apr 2021 10:04:20 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com> Message-ID: <4F7WdUagEWET1dKexsG-tW7MIhIwVPeYGW9u2w_kArE=.e7bd2f51-37f2-4542-bfdd-bcdd7cee6218@github.com> On Tue, 13 Apr 2021 09:34:15 GMT, Conor Cleary wrote: >> src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223: >> >>> 221: */ >>> 222: private final ClassLoader getContextClassLoader() { >>> 223: PrivilegedAction pa = () -> Thread.currentThread().getContextClassLoader(); >> >> We can use here an instance method reference to beautify code a little bit more: >> ```PrivilegedAction pa = Thread.currentThread()::getContextClassLoader;``` > > Good idea, also would fit in with the style of the method just after, `priviligedHasNext()` as that also uses a functional interface. Changes included as described in commit [5d6ecd3](https://github.com/openjdk/jdk/pull/3416/commits/5d6ecd31eb6ed2a63f17b2e798e83b91cb720075) ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From ccleary at openjdk.java.net Tue Apr 13 10:04:19 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Tue, 13 Apr 2021 10:04:19 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v3] In-Reply-To: References: Message-ID: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: 8048199: Cleaner syntak in getContextClassLoader ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3416/files - new: https://git.openjdk.java.net/jdk/pull/3416/files/840ea35c..5d6ecd31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3416&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3416&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416 PR: https://git.openjdk.java.net/jdk/pull/3416 From dfuchs at openjdk.java.net Tue Apr 13 10:11:57 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 13 Apr 2021 10:11:57 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: <4F7WdUagEWET1dKexsG-tW7MIhIwVPeYGW9u2w_kArE=.e7bd2f51-37f2-4542-bfdd-bcdd7cee6218@github.com> References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> <6swcWQ-3ggr_cADnhcbdBABHX0QOLZ0JWeFBjLIZ_t8=.df79f1f9-13ed-43e0-a3d6-08d3809b0c00@github.com> <4F7WdUagEWET1dKexsG-tW7MIhIwVPeYGW9u2w_kArE=.e7bd2f51-37f2-4542-bfdd-bcdd7cee6218@github.com> Message-ID: On Tue, 13 Apr 2021 10:00:51 GMT, Conor Cleary wrote: >> Good idea, also would fit in with the style of the method just after, `priviligedHasNext()` as that also uses a functional interface. > > Changes included as described in commit [5d6ecd3](https://github.com/openjdk/jdk/pull/3416/commits/5d6ecd31eb6ed2a63f17b2e798e83b91cb720075) Here again this is not strictly equivalent but AFAIK `Thread::currentThread` doesn't require any permission, so this should be OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From aefimov at openjdk.java.net Tue Apr 13 10:33:58 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Tue, 13 Apr 2021 10:33:58 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v3] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 10:04:19 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8048199: Cleaner syntak in getContextClassLoader Marked as reviewed by aefimov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From dfuchs at openjdk.java.net Tue Apr 13 11:09:58 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 13 Apr 2021 11:09:58 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v3] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 10:04:19 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. > > Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: > > 8048199: Cleaner syntak in getContextClassLoader Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From itakiguchi at openjdk.java.net Tue Apr 13 12:58:00 2021 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 13 Apr 2021 12:58:00 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reverted PrintStream changes I have 2 concerns: 1. I think method name "charset()" is too short. It's not called frequently. This method name should explain functionality. 2. Sometimes stderr may be redirected to stdout by shell. Why do we need to set different encodings for these two (sun.stdout.encoding and sun.stderr.encoding) ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From alanb at openjdk.java.net Tue Apr 13 13:07:11 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 13 Apr 2021 13:07:11 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Tue, 13 Apr 2021 12:54:51 GMT, Ichiroh Takiguchi wrote: > 1. I think method name "charset()" is too short. It's not called frequently. This method name should explain functionality. > 2. Sometimes stderr may be redirected to stdout by shell. Why do we need to set different encodings for these two (sun.stdout.encoding and sun.stderr.encoding) ? Console's class description already covers this "If the virtual machine is started from an interactive command line without redirecting the standard input and output streams then ...". The existing reader and writer methods use the same charset. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From fguallini at openjdk.java.net Tue Apr 13 13:27:37 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 13 Apr 2021 13:27:37 GMT Subject: RFR: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out Message-ID: test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java has been seen to fail intermittently. The server side is binding to the wildcard/localhost address which has been a source of instability in many tests. Binding to loopback address fixes the intermittent failures. In addition, other changes were introduced in the tests to improve code readability: - Reduce duplication by reusing code - Replace if statements with Switch expressions - Make fields final when appropriate - Convert ServerCallable and ClientCallable to records - Replace Byte.valueOf with Byte.parseByte to avoid redundant boxing ------------- Commit messages: - renamed constants field - fix intermittent time out, refactor Changes: https://git.openjdk.java.net/jdk/pull/3466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3466&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264152 Stats: 300 lines in 3 files changed: 78 ins; 130 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/3466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3466/head:pull/3466 PR: https://git.openjdk.java.net/jdk/pull/3466 From sean.mullan at oracle.com Tue Apr 13 13:39:30 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Apr 2021 09:39:30 -0400 Subject: RFR: Release Note for JDK-8264968 Provide the support for specifying a signer in keytool -genkeypair command In-Reply-To: References: Message-ID: <60fd42db-6d61-83c2-c26c-013257a649b1@oracle.com> Looks good, a couple of suggested rewordings in the second sentence: The `-signer` and `-signerkeypass` options have been added to the `-genkeypair` command of the `keytool` utility. The `-signer` option specifies the keystore alias of a signer and the `-signerkeypass` option specifies the password used to protect the signer?s private key. These options allow `keytool -genkeypair` to sign the certificate using the signer?s private key. This is especially useful for generating a certificate with a key agreement algorithm as its public key algorithm. --Sean On 4/9/21 5:12 PM, Hai-May Chao wrote: > Please review the release note for JDK-8264968: > > https://bugs.openjdk.java.net/browse/JDK-8264968 > > Thanks, > Hai-May > From github.com+76791+alblue at openjdk.java.net Tue Apr 13 13:43:03 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Tue, 13 Apr 2021 13:43:03 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security [v2] In-Reply-To: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> References: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> Message-ID: <1Wc1v_DNXKt7_WzXdEb1hEnsBzpiQ2DgyzAPlR5yWlU=.d8d32e2e-d730-468d-85ee-c6c6714e2d48@github.com> On Mon, 12 Apr 2021 09:32:13 GMT, Alex Blewitt wrote: >> 8264681: Use the blessed modifier order in java.security > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Removed upstream licensed code from commit What happens to this now? Do I need to wait for a re-review of the change or do I hit the (slash) integrate command now? ------------- PR: https://git.openjdk.java.net/jdk/pull/3338 From mullan at openjdk.java.net Tue Apr 13 14:26:04 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 13 Apr 2021 14:26:04 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: References: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com> <_-zU9sQFME5GaU1_tSs2TAUuOkOxk4REAbRo46DTwMA=.a814b3d5-fe64-4ca4-a9a1-3a43685259f5@github.com> <6V0tGnzyowoBbSrS5zWmzff2XakLYTwUtqCohmVxKdo=.34c3e075-c3a0-4188-804d-d2e63bb539f7@github.com> Message-ID: <6NmFTKEIwxZ-oHGYqILFAur_LliPrz6FN2MN9Sk1Y-E=.99dedee5-83e0-4aba-b995-83807edcec27@github.com> On Mon, 12 Apr 2021 20:53:21 GMT, Weijun Wang wrote: >> Ok, I understand now. I think `@implSpec` (and probably the `@implNote`) are in the wrong class. `@implSpec` means the implementation of this class. But this class is final and does not contain that logic. The logic of specifying/returning the defaults is in the JDK (XMLDSig provider) implementation of `SignatureMethod`. So I think it belongs there. In this class, you could add a sentence/link to `SignatureMethod`, something like "See SignatureMethod for how default values are determined when the parameters are not specified." >> >> Also, I think the `@implSpec` needs to be more specific, and also cover the cases where some, but not all of the parameters are specified and defaults are then used. For this, you will need to be more general, as the default salt length is based on what hash algorithm is being used. >> >> As for `@implNote`, this probably could use more discussion, but it might be better to make this part of the specification. If some implementations can return null, and others return defaults, it complicates the application's logic. The RFC has clearly specified what the defaults should be, so maybe the easiest thing to do is to make all implementations comply by also making it part of the API contract, and hiding the XML details as to whether the parameter was actually specified or not, which should not matter to applications. > > You are right that the overridable methods are elsewhere (`XMLSignatureFactory::newSignatureMethod` and `SignatureMethod::getParameterSpec`), but I still feel it a little strange to move the default parameter of one particular algorithm to the general interface `SignatureMethod` (this is similar to talking about EC curve names in `KeyPairGenerator`). It seems more natural to talk about this inside a class which is specific to the RSASSA-PSS algorithm and `RSAPSSParameterSpec` is the only public API we can find. We can add something like "specify null if you want a default spec" to `XMLSignatureFactory::newSignatureMethod` but it does not have enough space to describe "how default values are determined" for each algorithm. > > I understand `@implSpec` is for implementations of a class or a method, but does not mean the words must be put inside that exact class and method? Maybe not necessarily. > > As for making `@implSpec` more specific, at signing time, we can only either provide a `RSAPSSParameterSpec` or not one, so there is only one default value which is SHA256_RSA_MGF1. On the other hand, at validation time we might be parsing a partial-filled `RSAPSSParams` node and that's where default salt and default trailer field show up. > > Also about the return value of `SignatureMethod::getParameterSpec`, are you suggesting that for RSASSA-PSS it must be non null? This can be specified somewhere but we need to find a place. For the existing `HMACParameterSpec`, the method returns null if none is set. Do we treat that as no spec at all (but for RSASSA-PSS there is always one)? > > My current opinion is that we still document all these in `RSAPSSParameterSpec` but be very clear that this part is for `XMLSignatureFactory::newSignatureMethod` and that part is for `SignatureMethod::getParameterSpec`, etc, etc. I think it is worth asking the TCK team about this. After further thought, I am not sure `implSpec` is correct because the implementation is not in the classes, it is in the provider. I now think it needs to be part of the API contract, so that all implementations are compliant. `SignatureMethod` already defines the RSA_PSS algorithm constant, so it doesn't seem so out-of-place to put the specification there, something like: /** * The * RSASSA-PSS signature method algorithm URI. * * If the parameter is not specified when calling `XMLSignatureFactory.newSignatureMethod` with * RSA_PSS as the signature algorithm, the default parameter is used, which uses SHA-256 as the * {@code DigestMethod}, MGF1 with SHA-256 as the * {@code MaskGenerationFunction}, 32 as {@code SaltLength}, and 1 as * {@code TrailerField}. This is equivalent to the parameter-less signature * method {@link SignatureMethod#SHA256_RSA_MGF1 SHA256_RSA_MGF1} as defined * in RFC 6931. This default * parameter is returned by the `getParameterSpec` method. * * @since 17 */ String RSA_PSS = "http://www.w3.org/2007/05/xmldsig-more#rsa-pss"; Forget my comment about making `implSpec` more specific, I think that is now implied by RFC 3161. I also think the above specification would take care of my returning null comment, as all implementations would need to comply. I just didn't want applications to have to have code that checks for null and then don't know whether that means it is the default parameters or something else since it was implementation specific. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From shade at openjdk.java.net Tue Apr 13 14:32:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 13 Apr 2021 14:32:07 GMT Subject: RFR: 8264681: Use the blessed modifier order in java.security [v2] In-Reply-To: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> References: <4_f1MYi_0s9nCUF85BlpgJMImC6qh6nnEmvBw1VdZlI=.58e89e63-b695-4d2a-88d3-f08953869f90@github.com> Message-ID: <4gK-Vwt9sdS6jMZKTY9R0OrfvpKzmNmXm274TE0sFRs=.a83cf8c7-c86a-4c90-895f-77cd79a8db39@github.com> On Mon, 12 Apr 2021 09:32:13 GMT, Alex Blewitt wrote: >> 8264681: Use the blessed modifier order in java.security > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Removed upstream licensed code from commit I think all conversations have been resolved, we can integrate. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3338 From weijun at openjdk.java.net Tue Apr 13 14:43:16 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 14:43:16 GMT Subject: RFR: 8265138: Simplify DerUtils::checkAlg Message-ID: This fix makes `DerUtils::checkAlg` simple and clear, no more raw `Object` and ambiguous string arguments. ------------- Commit messages: - 8265138: Simplify DerUtils::checkAlg Changes: https://git.openjdk.java.net/jdk/pull/3467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265138 Stats: 37 lines in 3 files changed: 3 ins; 1 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/3467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3467/head:pull/3467 PR: https://git.openjdk.java.net/jdk/pull/3467 From weijun at openjdk.java.net Tue Apr 13 14:56:58 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 14:56:58 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2] In-Reply-To: <6NmFTKEIwxZ-oHGYqILFAur_LliPrz6FN2MN9Sk1Y-E=.99dedee5-83e0-4aba-b995-83807edcec27@github.com> References: <_VAVqXSjw7UY02YvH8P782Lrll3Uzjs8bKH3U1Au0lE=.5dce48b0-f21c-4023-a68c-c7e42a0d4c76@github.com> <_-zU9sQFME5GaU1_tSs2TAUuOkOxk4REAbRo46DTwMA=.a814b3d5-fe64-4ca4-a9a1-3a43685259f5@github.com> <6V0tGnzyowoBbSrS5zWmzff2XakLYTwUtqCohmVxKdo=.34c3e075-c3a0-4188-804d-d2e63bb539f7@github.com> <6NmFTKEIwxZ-oHGYqILFAur_LliPrz6FN2MN9Sk1Y-E=.99dedee5-83e0-4aba-b995-83807edcec27@github.com> Message-ID: On Tue, 13 Apr 2021 14:22:47 GMT, Sean Mullan wrote: >> You are right that the overridable methods are elsewhere (`XMLSignatureFactory::newSignatureMethod` and `SignatureMethod::getParameterSpec`), but I still feel it a little strange to move the default parameter of one particular algorithm to the general interface `SignatureMethod` (this is similar to talking about EC curve names in `KeyPairGenerator`). It seems more natural to talk about this inside a class which is specific to the RSASSA-PSS algorithm and `RSAPSSParameterSpec` is the only public API we can find. We can add something like "specify null if you want a default spec" to `XMLSignatureFactory::newSignatureMethod` but it does not have enough space to describe "how default values are determined" for each algorithm. >> >> I understand `@implSpec` is for implementations of a class or a method, but does not mean the words must be put inside that exact class and method? Maybe not necessarily. >> >> As for making `@implSpec` more specific, at signing time, we can only either provide a `RSAPSSParameterSpec` or not one, so there is only one default value which is SHA256_RSA_MGF1. On the other hand, at validation time we might be parsing a partial-filled `RSAPSSParams` node and that's where default salt and default trailer field show up. >> >> Also about the return value of `SignatureMethod::getParameterSpec`, are you suggesting that for RSASSA-PSS it must be non null? This can be specified somewhere but we need to find a place. For the existing `HMACParameterSpec`, the method returns null if none is set. Do we treat that as no spec at all (but for RSASSA-PSS there is always one)? >> >> My current opinion is that we still document all these in `RSAPSSParameterSpec` but be very clear that this part is for `XMLSignatureFactory::newSignatureMethod` and that part is for `SignatureMethod::getParameterSpec`, etc, etc. > > I think it is worth asking the TCK team about this. After further thought, I am not sure `implSpec` is correct because the implementation is not in the classes, it is in the provider. I now think it needs to be part of the API contract, so that all implementations are compliant. `SignatureMethod` already defines the RSA_PSS algorithm constant, so it doesn't seem so out-of-place to put the specification there, something like: > > > /** > * The > * RSASSA-PSS signature method algorithm URI. > * > * If the parameter is not specified when calling `XMLSignatureFactory.newSignatureMethod` with > * RSA_PSS as the signature algorithm, the default parameter is used, which uses SHA-256 as the > * {@code DigestMethod}, MGF1 with SHA-256 as the > * {@code MaskGenerationFunction}, 32 as {@code SaltLength}, and 1 as > * {@code TrailerField}. This is equivalent to the parameter-less signature > * method {@link SignatureMethod#SHA256_RSA_MGF1 SHA256_RSA_MGF1} as defined > * in RFC 6931. This default > * parameter is returned by the `getParameterSpec` method. > * > * @since 17 > */ > String RSA_PSS = "http://www.w3.org/2007/05/xmldsig-more#rsa-pss"; > > Forget my comment about making `implSpec` more specific, I think that is now implied by RFC 3161. I also think the above specification would take care of my returning null comment, as all implementations would need to comply. I just didn't want applications to have to have code that checks for null and then don't know whether that means it is the default parameters or something else since it was implementation specific. Great, I forgot about this string. This *is* a proper place to put the text. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Tue Apr 13 15:31:35 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 15:31:35 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v6] In-Reply-To: References: Message-ID: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: spec clarification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3181/files - new: https://git.openjdk.java.net/jdk/pull/3181/files/ce1678ea..a28a8fa1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=04-05 Stats: 67 lines in 5 files changed: 34 ins; 24 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3181/head:pull/3181 PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Tue Apr 13 15:31:35 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 15:31:35 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v5] In-Reply-To: References: Message-ID: <7jyOsaAmijkv0ksfXxMTCRPcUrvx5-Qqt5qosxQclyg=.825fa44d-240c-4610-acad-8467e3305a80@github.com> On Mon, 12 Apr 2021 15:25:09 GMT, Weijun Wang wrote: >> This enhancement contains the following code changes: >> >> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. >> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. >> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` >> 4. Tests > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > no RSAPSSParameterSpec::toString and some test comments New commit pushed. If you're OK with the change, I'll update the CSR as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From xuelei at openjdk.java.net Tue Apr 13 16:19:07 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 13 Apr 2021 16:19:07 GMT Subject: RFR: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 13:19:17 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java has been seen to fail intermittently. > The server side is binding to the wildcard/localhost address which has been a source of instability in many tests. Binding to loopback address fixes the intermittent failures. > > In addition, other changes were introduced in the tests to improve code readability: > - Reduce duplication by reusing code > - Replace if statements with Switch expressions > - Make fields final when appropriate > - Convert ServerCallable and ClientCallable to records > - Replace Byte.valueOf with Byte.parseByte to avoid redundant boxing Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3466 From xuelei at openjdk.java.net Tue Apr 13 16:20:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 13 Apr 2021 16:20:57 GMT Subject: RFR: 8265138: Simplify DerUtils::checkAlg In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 14:36:46 GMT, Weijun Wang wrote: > This fix makes `DerUtils::checkAlg` simple and clear, no more raw `Object` and ambiguous string arguments. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3467 From weijun at openjdk.java.net Tue Apr 13 17:00:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 17:00:03 GMT Subject: Integrated: 8265138: Simplify DerUtils::checkAlg In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 14:36:46 GMT, Weijun Wang wrote: > This fix makes `DerUtils::checkAlg` simple and clear, no more raw `Object` and ambiguous string arguments. This pull request has now been integrated. Changeset: 9cd5400d Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/9cd5400d Stats: 37 lines in 3 files changed: 3 ins; 1 del; 33 mod 8265138: Simplify DerUtils::checkAlg Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3467 From mullan at openjdk.java.net Tue Apr 13 17:10:03 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 13 Apr 2021 17:10:03 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v6] In-Reply-To: References: Message-ID: <9vVlrgxLEkqGLI1O953B4EsKH69YOLJm2xF-IbQ7Xgc=.ff5a27c5-8b65-4cd8-baf2-56e237b4ecea@github.com> On Tue, 13 Apr 2021 15:31:35 GMT, Weijun Wang wrote: >> This enhancement contains the following code changes: >> >> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. >> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. >> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` >> 4. Tests > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > spec clarification src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java line 247: > 245: * as the signature algorithm, the default parameter as defined in > 246: * RFC 6931 Section 2.3.9 > 247: * is used and this default parameter will also be returned by the WE should mention/link to the type returned. Suggest breaking this into two sentences: `If the {@code params} parameter is {@code null} when calling {@link XMLSignatureFactory#newSignatureMethod} with {@code RSA_PSS} as the signature algorithm, the default parameter as defined in RFC 6931 Section 2.3.9 is used. This default parameter is represented as an {@link RSAPSSParameterSpec} type and returned by the {@link SignatureMethod#getParameterSpec()} method.` ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From xuelei at openjdk.java.net Tue Apr 13 17:55:05 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 13 Apr 2021 17:55:05 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 06:30:43 GMT, djelinski wrote: >> As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. >> >> The handshake status could have more precise status if the out bound. The patch was confirmed by the bug submitter. > > src/java.base/share/classes/sun/security/ssl/TransportContext.java line 590: > >> 588: HandshakeStatus getHandshakeStatus() { >> 589: if (!outputRecord.isEmpty()) { >> 590: // If no handshaking, special case to wrap alters or > > Suggestion: > > // If not handshaking, special case to wrap alerts or Thank you for the correction. > src/java.base/share/classes/sun/security/ssl/TransportContext.java line 592: > >> 590: // If no handshaking, special case to wrap alters or >> 591: // post-handshake messages. >> 592: if (!isOutboundClosed()) { > > If I'm reading the [TransportContect#closeNotify](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/src/java.base/share/classes/sun/security/ssl/TransportContext.java#L275) and [TransportContext#passiveInboundClose](https://github.com/openjdk/jdk/blob/627ad9fe22a153410c14d0b2061bb7dee2c300af/src/java.base/share/classes/sun/security/ssl/TransportContext.java#L524) correctly, non-empty output record with both inbound and outbound closed happens when we reply with our close_notify to peer's. Now we will return NOT_HANDSHAKING which appears to be wrong. Good catch! I will have an update. Thank you for the code review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From hai-may.chao at oracle.com Tue Apr 13 18:04:59 2021 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 13 Apr 2021 11:04:59 -0700 Subject: RFR: Release Note for JDK-8264968 Provide the support for specifying a signer in keytool -genkeypair command In-Reply-To: <60fd42db-6d61-83c2-c26c-013257a649b1@oracle.com> References: <60fd42db-6d61-83c2-c26c-013257a649b1@oracle.com> Message-ID: <2C7E1963-C83A-435A-87F5-546BAB9D4CFC@oracle.com> Hi Sean, Updated with your comments. Thanks for the review. Tia-May > On Apr 13, 2021, at 6:39 AM, Sean Mullan wrote: > > Looks good, a couple of suggested rewordings in the second sentence: > > > The `-signer` and `-signerkeypass` options have been added to the `-genkeypair` command of the `keytool` utility. The `-signer` option specifies the keystore alias of a signer and the `-signerkeypass` option specifies the password used to protect the signer?s private key. These options allow `keytool -genkeypair` to sign the certificate using the signer?s private key. This is especially useful for generating a certificate with a key agreement algorithm as its public key algorithm. > > --Sean > > On 4/9/21 5:12 PM, Hai-May Chao wrote: >> Please review the release note for JDK-8264968: >> https://bugs.openjdk.java.net/browse/JDK-8264968 >> Thanks, >> Hai-May From naoto at openjdk.java.net Tue Apr 13 18:13:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 13 Apr 2021 18:13:29 GMT Subject: RFR: 8264208: Console charset API [v5] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflected further review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/68db1a79..cafde56a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=03-04 Stats: 14 lines in 1 file changed: 6 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From weijun at openjdk.java.net Tue Apr 13 18:16:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 18:16:30 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v7] In-Reply-To: References: Message-ID: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more spec clarification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3181/files - new: https://git.openjdk.java.net/jdk/pull/3181/files/a28a8fa1..df55414c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3181&range=05-06 Stats: 12 lines in 2 files changed: 0 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3181/head:pull/3181 PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Tue Apr 13 18:16:31 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Apr 2021 18:16:31 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v6] In-Reply-To: <9vVlrgxLEkqGLI1O953B4EsKH69YOLJm2xF-IbQ7Xgc=.ff5a27c5-8b65-4cd8-baf2-56e237b4ecea@github.com> References: <9vVlrgxLEkqGLI1O953B4EsKH69YOLJm2xF-IbQ7Xgc=.ff5a27c5-8b65-4cd8-baf2-56e237b4ecea@github.com> Message-ID: On Tue, 13 Apr 2021 17:07:19 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> spec clarification > > src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java line 247: > >> 245: * as the signature algorithm, the default parameter as defined in >> 246: * RFC 6931 Section 2.3.9 >> 247: * is used and this default parameter will also be returned by the > > WE should mention/link to the type returned. Suggest breaking this into two sentences: > > `If the {@code params} parameter is {@code null} when calling {@link XMLSignatureFactory#newSignatureMethod} with {@code RSA_PSS} as the signature algorithm, the default parameter as defined in RFC 6931 Section 2.3.9 is used. This default parameter is represented as an {@link RSAPSSParameterSpec} type and returned by the {@link SignatureMethod#getParameterSpec()} method.` OK, and some other tweaks. New commit pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From naoto at openjdk.java.net Tue Apr 13 18:28:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 13 Apr 2021 18:28:00 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com> Message-ID: On Tue, 13 Apr 2021 02:34:15 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted PrintStream changes > > src/java.base/share/classes/java/lang/System.java line 2020: > >> 2018: setIn0(new BufferedInputStream(fdIn)); >> 2019: setOut0(newPrintStream(fdOut, cs)); >> 2020: setErr0(newPrintStream(fdErr, cs)); > > It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change? Although the code path is different, the logic to determine the encoding is not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a terminal (in fact, there's a bug where they aren't set even in a terminal on unix env, which I fixed in this patch) which is the same condition in which `System.console()` returns the console. And for both cases, it will default to `Charset.defaultCharset()` if they are not available. Having said that, one regression test started to fail with this implementation change as follows: Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated. at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199) at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287) at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258) at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960) at java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518) at java.base/java.util.Scanner.useLocale(Scanner.java:1270) at java.base/java.util.Scanner.(Scanner.java:543) at java.base/java.util.Scanner.(Scanner.java:554) at TestConsole.main(TestConsole.java:54) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188) ... 8 more I haven't looked at it in detail but it seems that calling `System.console()` in `System.initPhase1()` is not allowed, as the module system is not there yet. So I reverted the implementation to the original and simply retained the description in `System.out/err` with a change to `determined by` to `equivalent to`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Tue Apr 13 18:31:59 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 13 Apr 2021 18:31:59 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Tue, 13 Apr 2021 13:04:17 GMT, Alan Bateman wrote: > 1. I think method name "charset()" is too short. It's not called frequently. This method name should explain functionality. As for this one, I am open for suggestions. I thought `consoel()` was concise, and analogous to `Charset.defaultCharset()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From joehw at openjdk.java.net Tue Apr 13 19:33:59 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 13 Apr 2021 19:33:59 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com> Message-ID: On Tue, 13 Apr 2021 18:24:55 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/System.java line 2020: >> >>> 2018: setIn0(new BufferedInputStream(fdIn)); >>> 2019: setOut0(newPrintStream(fdOut, cs)); >>> 2020: setErr0(newPrintStream(fdErr, cs)); >> >> It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change? > > Although the code path is different, the logic to determine the encoding is not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a terminal (in fact, there's a bug where they aren't set even in a terminal on unix env, which I fixed in this patch) which is the same condition in which `System.console()` returns the console. And for both cases, it will default to `Charset.defaultCharset()` if they are not available. > > Having said that, one regression test started to fail with this implementation change as follows: > > Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated. > at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199) > at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287) > at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258) > at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960) > at java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518) > at java.base/java.util.Scanner.useLocale(Scanner.java:1270) > at java.base/java.util.Scanner.(Scanner.java:543) > at java.base/java.util.Scanner.(Scanner.java:554) > at TestConsole.main(TestConsole.java:54) > Caused by: java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) > at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188) > ... 8 more > > I haven't looked at it in detail but it seems that calling `System.console()` in `System.initPhase1()` is not allowed, as the module system is not there yet. So I reverted the implementation to the original and simply retained the description in `System.out/err` with a change to `determined by` to `equivalent to`. Thanks for the explanation and updates. It's a worthwhile exercise to attempt to align things around the new method. A short note above line 2023 to record this might be useful as well (sth. like it's eq to console != null ? console.charset() : Charset.defaultCharset();). No need to create another update if you decide to add the note. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Tue Apr 13 19:59:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 13 Apr 2021 19:59:30 GMT Subject: RFR: 8264208: Console charset API [v4] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <_jImIdy-NWto77yZ2WGq4axm1eLG1xNrmSl6iOy3dg8=.fcf33741-a040-44b9-88db-31872dd796d0@github.com> Message-ID: On Tue, 13 Apr 2021 19:30:53 GMT, Joe Wang wrote: >> Although the code path is different, the logic to determine the encoding is not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a terminal (in fact, there's a bug where they aren't set even in a terminal on unix env, which I fixed in this patch) which is the same condition in which `System.console()` returns the console. And for both cases, it will default to `Charset.defaultCharset()` if they are not available. >> >> Having said that, one regression test started to fail with this implementation change as follows: >> >> Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated. >> at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199) >> at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287) >> at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258) >> at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960) >> at java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518) >> at java.base/java.util.Scanner.useLocale(Scanner.java:1270) >> at java.base/java.util.Scanner.(Scanner.java:543) >> at java.base/java.util.Scanner.(Scanner.java:554) >> at TestConsole.main(TestConsole.java:54) >> Caused by: java.lang.reflect.InvocationTargetException >> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) >> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) >> at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188) >> ... 8 more >> >> I haven't looked at it in detail but it seems that calling `System.console()` in `System.initPhase1()` is not allowed, as the module system is not there yet. So I reverted the implementation to the original and simply retained the description in `System.out/err` with a change to `determined by` to `equivalent to`. > > Thanks for the explanation and updates. It's a worthwhile exercise to attempt to align things around the new method. A short note above line 2023 to record this might be useful as well (sth. like it's eq to console != null ? console.charset() : Charset.defaultCharset();). No need to create another update if you decide to add the note. Thanks. Added some explanations as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Tue Apr 13 19:59:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 13 Apr 2021 19:59:30 GMT Subject: RFR: 8264208: Console charset API [v6] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added comment to System.out/err init. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/cafde56a..9e323145 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=04-05 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From joehw at openjdk.java.net Tue Apr 13 21:39:05 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 13 Apr 2021 21:39:05 GMT Subject: RFR: 8264208: Console charset API [v6] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added comment to System.out/err init. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Wed Apr 14 03:58:33 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 14 Apr 2021 03:58:33 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v3] In-Reply-To: References: Message-ID: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> > Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Fixed an tagLen issue, no key+iv reuse check for decryption, and add regression test for ChaCha20 SKF. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3420/files - new: https://git.openjdk.java.net/jdk/pull/3420/files/d0f16238..2e3b7968 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=01-02 Stats: 290 lines in 3 files changed: 122 ins; 165 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3420.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3420/head:pull/3420 PR: https://git.openjdk.java.net/jdk/pull/3420 From github.com+76791+alblue at openjdk.java.net Wed Apr 14 06:03:58 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Wed, 14 Apr 2021 06:03:58 GMT Subject: Integrated: 8264681: Use the blessed modifier order in java.security In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 22:09:55 GMT, Alex Blewitt wrote: > 8264681: Use the blessed modifier order in java.security This pull request has now been integrated. Changeset: ebbce91e Author: Alex Blewitt Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ebbce91e Stats: 160 lines in 53 files changed: 0 ins; 0 del; 160 mod 8264681: Use the blessed modifier order in java.security Reviewed-by: mullan, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3338 From ssahoo at openjdk.java.net Wed Apr 14 13:49:59 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 14 Apr 2021 13:49:59 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. Message-ID: This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. ------------- Commit messages: - 8185127: Add Tests to cover hashCode() method for java supported crypto key types. Changes: https://git.openjdk.java.net/jdk/pull/3490/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8185127 Stats: 153 lines in 1 file changed: 153 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From alanb at openjdk.java.net Wed Apr 14 15:06:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 14 Apr 2021 15:06:47 GMT Subject: RFR: 8264208: Console charset API [v6] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added comment to System.out/err init. src/java.base/share/classes/java/lang/System.java line 166: > 164: * exists, {@link Charset#defaultCharset()} otherwise. > 165: */ > 166: public static final PrintStream err = null; I still think we need something in System.in to link to Console::charset. If someone creates an InputStreamReader(System.in) then it will use the default charset, they should be using Console::reader for these cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Wed Apr 14 16:55:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Apr 2021 16:55:05 GMT Subject: RFR: 8264208: Console charset API [v6] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Wed, 14 Apr 2021 15:03:19 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment to System.out/err init. > > src/java.base/share/classes/java/lang/System.java line 166: > >> 164: * exists, {@link Charset#defaultCharset()} otherwise. >> 165: */ >> 166: public static final PrintStream err = null; > > I still think we need something in System.in to link to Console::charset. If someone creates an InputStreamReader(System.in) then it will use the default charset, they should be using Console::reader for these cases. Added some explanation to it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Wed Apr 14 16:55:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Apr 2021 16:55:03 GMT Subject: RFR: 8264208: Console charset API [v7] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added Console::charset() relation with System.in ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/9e323145..45ab77b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=05-06 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Wed Apr 14 17:17:03 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Apr 2021 17:17:03 GMT Subject: RFR: 8264208: Console charset API [v8] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added @see links. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/45ab77b3..5988f600 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=06-07 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From ssahoo at openjdk.java.net Wed Apr 14 17:37:00 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 14 Apr 2021 17:37:00 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: References: Message-ID: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Comment changed. Comment changed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/ff6490d6..ca459d0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From weijun at openjdk.java.net Wed Apr 14 18:19:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 14 Apr 2021 18:19:56 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib Message-ID: I'd like to move this tool to test/lib inside a proper named package. ------------- Commit messages: - 8265227: Move Proc.java from security/testlibrary to test/lib Changes: https://git.openjdk.java.net/jdk/pull/3496/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3496&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265227 Stats: 18 lines in 8 files changed: 10 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3496/head:pull/3496 PR: https://git.openjdk.java.net/jdk/pull/3496 From rriggs at openjdk.java.net Wed Apr 14 18:34:38 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 14 Apr 2021 18:34:38 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib In-Reply-To: References: Message-ID: <_DSRugZreWhgto9Ei9f-ljpdgu0X-NzWfk1UoafA5hY=.c6024916-08ed-44d0-a58f-ea31dd25f3c5@github.com> On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. Good idea. Is there a more evocative class name than Proc? It looks similar to jdk.test.lib.process.ProcessTools. Would it fit in the jdk.test.lib.process package? It would make it easier for non-security testers to find and use? ( I like the fluid construction) ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From weijun at openjdk.java.net Wed Apr 14 18:39:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 14 Apr 2021 18:39:44 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. Well, we can certainly rename it. It's only used by several tests. Maybe `ChildProcess`? And we can certainly move it to a different package. I know it has some duplicate functions with other tools so it will be better to do some cleanup first. The best function of this class is it provides several methods (both for child and parent) to simplify inter-process message transport. ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From rriggs at openjdk.java.net Wed Apr 14 18:45:39 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 14 Apr 2021 18:45:39 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. I think is fine to move it first and refactor it separately; that's a bigger job. If its fit for the purpose, the overlap is fine between tools. ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From plevart at openjdk.java.net Wed Apr 14 19:14:24 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 14 Apr 2021 19:14:24 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further Message-ID: While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce The comparative results are here: https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 The jmh-result.json files are here: https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. So WDYT? ------------- Commit messages: - Make JavaLangAccess JLA field private static final - Alternative String.join Changes: https://git.openjdk.java.net/jdk/pull/3501/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265237 Stats: 97 lines in 4 files changed: 61 ins; 18 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501 PR: https://git.openjdk.java.net/jdk/pull/3501 From plevart at openjdk.java.net Wed Apr 14 19:45:40 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 14 Apr 2021 19:45:40 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart wrote: > While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. > Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. > But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. > This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: > > https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce > > The comparative results are here: > > https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 > > The jmh-result.json files are here: > > https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 > > Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. > > So WDYT? Some background: This change was motivated by Sergey Tsypanov's attempt to replace usage of StringBuilder with string concatenation in JDK-8265075 only to find out that string concatenation in java.base module is compiled down to inline usage of StringBuilder, so no improvement was possible. StringJoiner API and String.join static utility methods lend itself to a better implementation, but in last incarnation they are implemented with StringBuilder internally: String.join -> StringJoiner -> StringBuilder. A lot of JDK internal usages of StringBuilder were already replaced with StringJoiner (JDK-8054714) but under the hood the StringBuilder is still used. There were also lots of incremental attempts to improve StringJoiner. I think this one is the last one for some time to come... :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3501 From github.com+592810+efge at openjdk.java.net Wed Apr 14 19:57:42 2021 From: github.com+592810+efge at openjdk.java.net (Florent Guillaume) Date: Wed, 14 Apr 2021 19:57:42 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart wrote: > While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. > Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. > But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. > This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: > > https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce > > The comparative results are here: > > https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 > > The jmh-result.json files are here: > > https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 > > Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. > > So WDYT? src/java.base/share/classes/java/lang/String.java line 3230: > 3228: > 3229: /** > 3230: * Designated join routine. Did you mean "dedicated"? ------------- PR: https://git.openjdk.java.net/jdk/pull/3501 From redestad at openjdk.java.net Wed Apr 14 20:06:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 14 Apr 2021 20:06:38 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further In-Reply-To: References: Message-ID: <5lcL44Q8ptrdLGm9T6OhAUfK9Qf3qr-3APVax-LNAfM=.3d7d6f77-501b-4374-b414-f7992ba9edef@github.com> On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart wrote: > While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. > Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. > But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. > This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: > > https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce > > The comparative results are here: > > https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 > > The jmh-result.json files are here: > > https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 > > Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. > > So WDYT? I think this seems reasonable. The String encoding details doesn't leak outside of java.lang, and numbers do look convincing. There's a StringJoinerBenchmark micro added by JDK-8148937 which could perhaps be expanded with the scenarios you've experimented with here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3501 From xuelei at openjdk.java.net Wed Apr 14 20:18:38 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 14 Apr 2021 20:18:38 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib In-Reply-To: References: Message-ID: <2LuaXjMT38wCZCEKkPXprphc9FSxn3TmlTxodgPwewA=.22c5d7a5-a5e0-4b61-b76b-c3e1cad356ba@github.com> On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3496 From weijun at openjdk.java.net Wed Apr 14 20:48:07 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 14 Apr 2021 20:48:07 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v2] In-Reply-To: References: Message-ID: <0lSKQG9R4AZwuyJdvDKZ8Ot5ysfhShxywxrAgmUw3vU=.9c16a29f-88d4-4edd-b3d6-6c68eb5e2e18@github.com> > I'd like to move this tool to test/lib inside a proper named package. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: move to process and a test for itself ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3496/files - new: https://git.openjdk.java.net/jdk/pull/3496/files/4823a1c6..200ce3bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3496&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3496&range=00-01 Stats: 89 lines in 8 files changed: 82 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3496/head:pull/3496 PR: https://git.openjdk.java.net/jdk/pull/3496 From plevart at openjdk.java.net Wed Apr 14 22:26:39 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 14 Apr 2021 22:26:39 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 19:54:26 GMT, Florent Guillaume wrote: >> While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. >> Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. >> But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. >> This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: >> >> https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce >> >> The comparative results are here: >> >> https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 >> >> The jmh-result.json files are here: >> >> https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 >> >> Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. >> >> So WDYT? > > src/java.base/share/classes/java/lang/String.java line 3230: > >> 3228: >> 3229: /** >> 3230: * Designated join routine. > > Did you mean "dedicated"? No, I meant designated. It is the routine that all other public API entry points call at the end to do the job. Would some other word more accurately describe that? I definitely didn't mean "dedicated". ------------- PR: https://git.openjdk.java.net/jdk/pull/3501 From weijun at openjdk.java.net Wed Apr 14 22:57:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 14 Apr 2021 22:57:55 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v3] In-Reply-To: References: Message-ID: > I'd like to move this tool to test/lib inside a proper named package. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: do not call internal method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3496/files - new: https://git.openjdk.java.net/jdk/pull/3496/files/200ce3bd..72878e37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3496&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3496&range=01-02 Stats: 21 lines in 5 files changed: 5 ins; 9 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3496/head:pull/3496 PR: https://git.openjdk.java.net/jdk/pull/3496 From weijun at openjdk.java.net Wed Apr 14 22:57:56 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 14 Apr 2021 22:57:56 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v2] In-Reply-To: <0lSKQG9R4AZwuyJdvDKZ8Ot5ysfhShxywxrAgmUw3vU=.9c16a29f-88d4-4edd-b3d6-6c68eb5e2e18@github.com> References: <0lSKQG9R4AZwuyJdvDKZ8Ot5ysfhShxywxrAgmUw3vU=.9c16a29f-88d4-4edd-b3d6-6c68eb5e2e18@github.com> Message-ID: On Wed, 14 Apr 2021 20:48:07 GMT, Weijun Wang wrote: >> I'd like to move this tool to test/lib inside a proper named package. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > move to process and a test for itself New commit that uses a different method to find out `-add-exports` and `--add-opens` so there is no need to use an internal method. Otherwise, multiple other tests that have `@build jdk.test.lib.process.*` would fail without the extra `@modules` tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From rhalade at openjdk.java.net Thu Apr 15 02:38:36 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 15 Apr 2021 02:38:36 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v3] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 22:57:55 GMT, Weijun Wang wrote: >> I'd like to move this tool to test/lib inside a proper named package. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > do not call internal method Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From ssahoo at openjdk.java.net Thu Apr 15 07:26:34 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 15 Apr 2021 07:26:34 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v3] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 22:57:55 GMT, Weijun Wang wrote: >> I'd like to move this tool to test/lib inside a proper named package. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > do not call internal method Marked as reviewed by ssahoo (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From ssahoo at openjdk.java.net Thu Apr 15 10:30:35 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 15 Apr 2021 10:30:35 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v3] In-Reply-To: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> References: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> Message-ID: On Wed, 14 Apr 2021 03:58:33 GMT, Valerie Peng wrote: >> Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. >> >> Thanks! >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed an tagLen issue, no key+iv reuse check for decryption, and add regression test for ChaCha20 SKF. test/jdk/sun/security/pkcs11/Cipher/TestChaChaPoly.java line 1: > 1: /* There is no compatibility Test exist between SunJCE and SunPKCS11 providers. Do we need one here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From github.com+592810+efge at openjdk.java.net Thu Apr 15 11:24:36 2021 From: github.com+592810+efge at openjdk.java.net (Florent Guillaume) Date: Thu, 15 Apr 2021 11:24:36 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 22:23:57 GMT, Peter Levart wrote: >> src/java.base/share/classes/java/lang/String.java line 3230: >> >>> 3228: >>> 3229: /** >>> 3230: * Designated join routine. >> >> Did you mean "dedicated"? > > No, I meant designated. It is the routine that all other public API entry points call at the end to do the job. Would some other word more accurately describe that? I definitely didn't mean "dedicated". Oh then sorry, I thought it was a typo of some sort. I'd have said something like "Centralized join logic". But whatever works for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/3501 From ccleary at openjdk.java.net Thu Apr 15 14:11:35 2021 From: ccleary at openjdk.java.net (Conor Cleary) Date: Thu, 15 Apr 2021 14:11:35 GMT Subject: Integrated: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary wrote: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. This pull request has now been integrated. Changeset: 4e90d740 Author: Conor Cleary Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/4e90d740 Stats: 84 lines in 5 files changed: 0 ins; 48 del; 36 mod 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI Reviewed-by: rriggs, dfuchs, aefimov, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From rriggs at openjdk.java.net Thu Apr 15 14:25:38 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 15 Apr 2021 14:25:38 GMT Subject: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v3] In-Reply-To: References: Message-ID: <1YayR5iC8s3iMPA8TTu1-E6ev01xC1GwdDE-_KIv2Dc=.59253d19-49fa-4a92-b066-f7c9b18d1f63@github.com> On Wed, 14 Apr 2021 22:57:55 GMT, Weijun Wang wrote: >> I'd like to move this tool to test/lib inside a proper named package. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > do not call internal method Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From jnimeh at openjdk.java.net Thu Apr 15 14:27:42 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 15 Apr 2021 14:27:42 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v3] In-Reply-To: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> References: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> Message-ID: On Wed, 14 Apr 2021 03:58:33 GMT, Valerie Peng wrote: >> Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. >> >> Thanks! >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed an tagLen issue, no key+iv reuse check for decryption, and add regression test for ChaCha20 SKF. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 225: > 223: } > 224: apAlgo = "ChaCha20-Poly1305"; > 225: spec = new IvParameterSpec(iv); Are there protections further up the call stack that guarantee that iv will be non-null when encrypt == false? I assume there are but I figured I'd ask since a null iv could cause NPE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From alanb at openjdk.java.net Thu Apr 15 14:29:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 15 Apr 2021 14:29:35 GMT Subject: RFR: 8264208: Console charset API [v8] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Wed, 14 Apr 2021 17:17:03 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added @see links. src/java.base/share/classes/java/io/Console.java line 397: > 395: /** > 396: * Returns the {@link java.nio.charset.Charset Charset} object used in > 397: * the {@code Console}. What would you think about re-phrasing the first sentence to use "for the Console" rather than "in the Console". src/java.base/share/classes/java/lang/System.java line 123: > 121: * > 122: * @see Console#charset() > 123: * @see Console#reader() What would you think about changing the example in InputStreamReader class description as part of this? ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From jnimeh at openjdk.java.net Thu Apr 15 14:47:36 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 15 Apr 2021 14:47:36 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v3] In-Reply-To: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> References: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> Message-ID: <4o48lWSs8Y0gr9I_MFNC5o-ShmRHHdlc3NnXXPrpAzU=.817a86d0-8627-4288-9b80-bf70ed40b3a9@github.com> On Wed, 14 Apr 2021 03:58:33 GMT, Valerie Peng wrote: >> Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. >> >> Thanks! >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fixed an tagLen issue, no key+iv reuse check for decryption, and add regression test for ChaCha20 SKF. Marked as reviewed by jnimeh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From weijun at openjdk.java.net Thu Apr 15 15:10:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 15 Apr 2021 15:10:40 GMT Subject: Integrated: 8265227: Move Proc.java from security/testlibrary to test/lib In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:12:57 GMT, Weijun Wang wrote: > I'd like to move this tool to test/lib inside a proper named package. This pull request has now been integrated. Changeset: c70589c6 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/c70589c6 Stats: 119 lines in 9 files changed: 96 ins; 9 del; 14 mod 8265227: Move Proc.java from security/testlibrary to test/lib Reviewed-by: rriggs, xuelei, rhalade, ssahoo ------------- PR: https://git.openjdk.java.net/jdk/pull/3496 From mark.reinhold at oracle.com Thu Apr 15 18:05:00 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Apr 2021 11:05:00 -0700 (PDT) Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal Message-ID: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> https://openjdk.java.net/jeps/411 Summary: Deprecate the Security Manager for removal in a future release. The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API (JEP 398). - Mark From valeriep at openjdk.java.net Thu Apr 15 18:20:33 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Apr 2021 18:20:33 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: References: Message-ID: <1JbkIQrU6-4ORkePJ6eMBoCn5zMvaVA3V972J2dECKI=.732e26f0-7205-422b-a87e-33b55db37e30@github.com> On Wed, 14 Apr 2021 17:37:00 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Comment changed. > > Comment changed. test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 73: > 71: && !Arrays.equals(origKey.getEncoded(), copyKey.getEncoded()) > 72: && origKey.hashCode() != copyKey.hashCode()) { > 73: throw new RuntimeException("Key inequality found"); Check the format equality as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From valeriep at openjdk.java.net Thu Apr 15 18:25:36 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Apr 2021 18:25:36 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 17:37:00 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Comment changed. > > Comment changed. test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 114: > 112: HmacSHA384("HmacSHA384"), > 113: HmacSHA512("HmacSHA512"), > 114: RC2("RC2"); Just curious, how are these decided? Should this be an exhaustive list or just enough sampling for code coverage? If this is meant to be a general test, have you tried to not hardcoding the algorithm names to be enum? Otherwise, new algorithms will not be tested if not updating this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From naoto at openjdk.java.net Thu Apr 15 18:29:17 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 15 Apr 2021 18:29:17 GMT Subject: RFR: 8264208: Console charset API [v9] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Modified javadocs per suggestions. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/5988f600..083f6180 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=07-08 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Thu Apr 15 18:35:34 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Apr 2021 18:35:34 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: <1JbkIQrU6-4ORkePJ6eMBoCn5zMvaVA3V972J2dECKI=.732e26f0-7205-422b-a87e-33b55db37e30@github.com> References: <1JbkIQrU6-4ORkePJ6eMBoCn5zMvaVA3V972J2dECKI=.732e26f0-7205-422b-a87e-33b55db37e30@github.com> Message-ID: <8KJMIC0AzHUXsFORKHq36G0y3-ecHf6ZPAWke5oaqVs=.e2018165-3ebc-44fd-a5ec-5dcbaf25aa4c@github.com> On Thu, 15 Apr 2021 18:18:07 GMT, Valerie Peng wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment changed. >> >> Comment changed. > > test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 73: > >> 71: && !Arrays.equals(origKey.getEncoded(), copyKey.getEncoded()) >> 72: && origKey.hashCode() != copyKey.hashCode()) { >> 73: throw new RuntimeException("Key inequality found"); > > Check the format equality as well? Should be || instead of &&? ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From naoto at openjdk.java.net Thu Apr 15 18:36:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 15 Apr 2021 18:36:40 GMT Subject: RFR: 8264208: Console charset API [v8] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Thu, 15 Apr 2021 14:17:11 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Added @see links. > > src/java.base/share/classes/java/io/Console.java line 397: > >> 395: /** >> 396: * Returns the {@link java.nio.charset.Charset Charset} object used in >> 397: * the {@code Console}. > > What would you think about re-phrasing the first sentence to use "for the Console" rather than "in the Console". Changed to "for the Console", as well as `@return`. > src/java.base/share/classes/java/lang/System.java line 123: > >> 121: * >> 122: * @see Console#charset() >> 123: * @see Console#reader() > > What would you think about changing the example in InputStreamReader class description as part of this? Replaced `System.in` with generic `anInputStream`, as changing `new InputStreamReader` with `Console.reader()` would defy the purpose of the example. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Thu Apr 15 18:39:35 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 15 Apr 2021 18:39:35 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 17:37:00 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Comment changed. > > Comment changed. test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 124: > 122: public SecretKey genSecretKey() throws Exception { > 123: KeyGenerator kg = KeyGenerator.getInstance(this.algoName); > 124: return kg.generateKey(); Would be informative to print out which provider is tested, i.e. where this kg is from. Same goes for KeyPairGenerator. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From plevart at openjdk.java.net Thu Apr 15 19:26:48 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 15 Apr 2021 19:26:48 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further [v2] In-Reply-To: References: Message-ID: > While JDK-8148937 improved StringJoiner class by replacing internal use of getChars that copies out characters from String elements into a char[] array with StringBuilder which is somehow more optimal, the improvement was marginal in speed (0% ... 10%) and mainly for smaller strings, while GC was reduced by about 50% in average per operation. > Initial attempt to tackle that issue was more involved, but was later discarded because it was apparently using too much internal String details in code that lives outside String and outside java.lang package. > But there is another way to package such "intimate" code - we can put it into String itself and just call it from StringJoiner. > This PR is an attempt at doing just that. It introduces new package-private method in `java.lang.String` which is then used from both pubic static `String.join` methods as well as from `java.util.StringJoiner` (via SharedSecrets). The improvements can be seen by running the following JMH benchmark: > > https://gist.github.com/plevart/86ac7fc6d4541dbc08256cde544019ce > > The comparative results are here: > > https://jmh.morethan.io/?gist=7eb421cf7982456a2962269137f71c15 > > The jmh-result.json files are here: > > https://gist.github.com/plevart/7eb421cf7982456a2962269137f71c15 > > Improvement in speed ranges from 8% (for small strings) to 200% (for long strings), while creation of garbage has been further reduced to an almost garbage-free operation. > > So WDYT? Peter Levart has updated the pull request incrementally with one additional commit since the last revision: Add String.join benchmark method to StringJoinerBenchmark and adjust some parameters to cover bigger range ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3501/files - new: https://git.openjdk.java.net/jdk/pull/3501/files/62b577fd..6160e5aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3501&range=00-01 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3501/head:pull/3501 PR: https://git.openjdk.java.net/jdk/pull/3501 From plevart at openjdk.java.net Thu Apr 15 19:38:33 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 15 Apr 2021 19:38:33 GMT Subject: RFR: 8265237: String.join and StringJoiner can be improved further In-Reply-To: <5lcL44Q8ptrdLGm9T6OhAUfK9Qf3qr-3APVax-LNAfM=.3d7d6f77-501b-4374-b414-f7992ba9edef@github.com> References: <5lcL44Q8ptrdLGm9T6OhAUfK9Qf3qr-3APVax-LNAfM=.3d7d6f77-501b-4374-b414-f7992ba9edef@github.com> Message-ID: <4Tz9nGuYDst6V9GXbl_q-2R8JhPSQgeZJeMU00k5wBg=.d4269d05-133f-4935-8216-a130d250b5f5@github.com> On Wed, 14 Apr 2021 20:03:27 GMT, Claes Redestad wrote: > There's a StringJoinerBenchmark micro added by JDK-8148937 which could perhaps be expanded with the scenarios you've experimented with here? I modified that micro benchmark and added a method to also measure String.join static method along with StringJoiner for same parameters and extended the range of parameters to cover more diversity. The results are here: https://jmh.morethan.io/?gist=c38cc13d63774ec505cc8d394c00d502 It is apparent that there is a huge speedup when strings are bigger. But even smaller strings get a substantial speedup. There's also substantial reduction of garbage per operation. Previously the garbage amounted to the internal array of String elements and the StringBuffer with its internal byte[] array of characters. Now only the array of elements is the garbage. ------------- PR: https://git.openjdk.java.net/jdk/pull/3501 From reinier at zwitserloot.com Fri Apr 16 01:29:02 2021 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 16 Apr 2021 03:29:02 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries Message-ID: One useful thing that you can do with SecurityManager, which would be impossible if it is removed, and which isn't described in the 'specific narrow use cases' section: Monitoring and restriction of, specifically, third party libraries. 99 out of a 100 modern java projects have a rather long list of dependencies, and most of those dependencies have a limited and specific intent. "This library reads EXIM data from a JPG". "This library marshals JSON into java POJOs". "This library makes QR code PNGs". As an app programmer I want to monitor, and optionally restrict what these libraries can do. I can have an app that does (and is intended to) make network connections all the time, but as part of doing the job I wrote it for, it may be generating some QR PNGs. If the _QR generator library_ is making network calls? I want to know, and I probably want to stop it from happening. SecurityManager can do that. I don't know of a good way to take care of this without it, and it is not (currently) described in JEP411. I can't use OS-level monitoring, because the OS has no awareness of modules / packages / classnames, so I can't tell it to accept without log or warning any network access done by the parts of my application that are supposed to do this, but that I _do_ want it to log, warn, or halt any attempt by that QR generator library to hit the network. The original intent of SecurityManager was clearly to allow you to run untrusted code on a VM (the 'applet' use case), but this is somewhat different: It's not so much about attempting to secure presumably malicious code in a library or applet, but instead about attempting to secure against operations that ordinary java code may do, but which you simply aren't expecting from some specific library. Some real-world and/or highly plausible examples: * An XML parser library may make network calls or open files on disk due to e.g. XXE shenanigans: See https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing ? this isn't just plausible, we have plenty of proof that this has caused significant security breaches multiple times in XML's history. A SecurityManager that monitors (or outright denies) specifically the network and disk access from an XML parser library would have meant XXE attacks could never have happened. * Some twitter library may be invoking a relative-pathed `cmd.exe` in order to retrieve some system info from windows that cannot be obtained with any of the core java libraries. Perhaps to check if the twitter desktop client is installed (the authors of the library may well be unaware of the new ProcessInfo API). No doubt a scan of all java-tagged projects on github finds rather a lot of libraries that Runtime.exec("cmd.exe") for some unexpected, non-malicious purpose. Nevertheless, ProcessBuilder does apply $PATH processing and a system operator may not be willing to accept invokes to a relative path that can be trivially hijacked if some directory in the PATH is compromised, especially if the programming team that uses the library wasn't expecting it to do so. A SecurityManager can monitor this and even stop it from happening. * Any library could have the bright idea to 'phone home' and make a network call simply to give the library author some idea of how widespread their library is used. This could have an entirely innocuous purpose: The library author thought it'd be a cool idea to have a live map of the planet on their website, with a little animated blip every time their library is used to, say, parse some JSON. SecurityManager is the simplest way to spot this and stop it. I don't think SecurityManager is necessarily fantastic at stopping _intentionally malicious behaviour_ by a library written by untrustworthy charlatans (even though that was its original intent). But, it does a great job at stopping a misunderstanding between a library author and the user of said library, such as the rather plausible scenarios I just described. Modern security practices put a lot of focus on monitoring; SecurityManager can do that too: A SecurityManager is not obligated to deal with e.g. a notification that some code is attempting to open a file by throwing SecurityException - they can also simply log or notify somebody that it is happening and allow it. They could check if the caller is in a subset of 'blessed' code that has been checked by the dev team and has sign-off that it is allowed to do it. They could simply do a quick echo in dev-mode only, just so developers are aware whilst running tests that some library is doing things that have potential security implications and open potential surface area for a breach. I'm not sure if the file-based configuration of the security manager (policy files) needs to be kept around to enable this use case, but the basic infrastructure, and almost all of the various `check` methods in java.lang.SecurityManager have plausible scenarios where an application may want to monitor or deny what it triggers on when a library is doing it that you don't want it to or did not expect to. --Reinier Zwitserloot -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssahoo at openjdk.java.net Fri Apr 16 07:37:37 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 16 Apr 2021 07:37:37 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 18:23:09 GMT, Valerie Peng wrote: >> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment changed. >> >> Comment changed. > > test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 114: > >> 112: HmacSHA384("HmacSHA384"), >> 113: HmacSHA512("HmacSHA512"), >> 114: RC2("RC2"); > > Just curious, how are these decided? Should this be an exhaustive list or just enough sampling for code coverage? If this is meant to be a general test, have you tried to not hardcoding the algorithm names to be enum? Otherwise, new algorithms will not be tested if not updating this test. Done. Key(pair)Generator list will be collected dynamically. In fact it will now test even the same algorithm names supported by different providers too instead finding the 1st one. > test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 124: > >> 122: public SecretKey genSecretKey() throws Exception { >> 123: KeyGenerator kg = KeyGenerator.getInstance(this.algoName); >> 124: return kg.generateKey(); > > Would be informative to print out which provider is tested, i.e. where this kg is from. Same goes for KeyPairGenerator. Added print statement for KeyGenerator and corresponding Provider list. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Fri Apr 16 07:43:35 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 16 Apr 2021 07:43:35 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v2] In-Reply-To: <8KJMIC0AzHUXsFORKHq36G0y3-ecHf6ZPAWke5oaqVs=.e2018165-3ebc-44fd-a5ec-5dcbaf25aa4c@github.com> References: <1JbkIQrU6-4ORkePJ6eMBoCn5zMvaVA3V972J2dECKI=.732e26f0-7205-422b-a87e-33b55db37e30@github.com> <8KJMIC0AzHUXsFORKHq36G0y3-ecHf6ZPAWke5oaqVs=.e2018165-3ebc-44fd-a5ec-5dcbaf25aa4c@github.com> Message-ID: On Thu, 15 Apr 2021 18:32:26 GMT, Valerie Peng wrote: >> test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 73: >> >>> 71: && !Arrays.equals(origKey.getEncoded(), copyKey.getEncoded()) >>> 72: && origKey.hashCode() != copyKey.hashCode()) { >>> 73: throw new RuntimeException("Key inequality found"); >> >> Check the format equality as well? > > Should be || instead of &&? Would also be nice to know which one(s) failed. Considering equality and hashCode check may not be same for all KeyTypes, i have relaxed the verification with || operator. Also added print statement for possible failure cause. Added verification for format too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Fri Apr 16 08:26:52 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 16 Apr 2021 08:26:52 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v3] In-Reply-To: References: Message-ID: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Addressed Initial comments. Addressed Initial comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/ca459d0c..1fc51e07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=01-02 Stats: 85 lines in 1 file changed: 30 ins; 34 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Fri Apr 16 08:34:11 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 16 Apr 2021 08:34:11 GMT Subject: RFR: 8185127: Add Tests to cover hashCode() method for java supported crypto key types. [v4] In-Reply-To: References: Message-ID: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update CompareKeys.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/1fc51e07..be5d9a62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Fri Apr 16 09:18:40 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 16 Apr 2021 09:18:40 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v4] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 08:34:11 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update CompareKeys.java Getting java.io.NotSerializableException: sun.security.mscapi.CKey$NativeHandles for MSCAPI RSA algorithm. Need to change the Test with alternate implementation. For now Withdrawing the pull request. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Fri Apr 16 09:18:41 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Fri, 16 Apr 2021 09:18:41 GMT Subject: Withdrawn: 8185127: Add tests to cover hashCode() method for java supported crypto key types In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 13:38:06 GMT, Sibabrata Sahoo wrote: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From coffeys at openjdk.java.net Fri Apr 16 11:32:20 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 16 Apr 2021 11:32:20 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider Message-ID: Added capability to allow the PKCS11 Token to be destroyed once a session is logged out from. New configuration properties via pkcs11 config file. Cleaned up the native resource poller also. New unit test case to test behaviour. Some PKCS11 tests refactored to allow pkcs11 provider to be configured (and tested) with a config file of choice. Reviewer request @valeriepeng ------------- Commit messages: - 8240256: Better resource cleaning for SunPKCS11 Provider Changes: https://git.openjdk.java.net/jdk/pull/3544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3544&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240256 Stats: 604 lines in 13 files changed: 493 ins; 63 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/3544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3544/head:pull/3544 PR: https://git.openjdk.java.net/jdk/pull/3544 From fguallini at openjdk.java.net Fri Apr 16 16:54:35 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Fri, 16 Apr 2021 16:54:35 GMT Subject: Integrated: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out In-Reply-To: References: Message-ID: <5VzlhVsQQzyVqp7OKzxtqyzqVv6y7kwuUBeKTF1VnfA=.9ee89aad-99d2-40fc-8e76-9e81e8581c9e@github.com> On Tue, 13 Apr 2021 13:19:17 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java has been seen to fail intermittently. > The server side is binding to the wildcard/localhost address which has been a source of instability in many tests. Binding to loopback address fixes the intermittent failures. > > In addition, other changes were introduced in the tests to improve code readability: > - Reduce duplication by reusing code > - Replace if statements with Switch expressions > - Make fields final when appropriate > - Convert ServerCallable and ClientCallable to records > - Replace Byte.valueOf with Byte.parseByte to avoid redundant boxing This pull request has now been integrated. Changeset: 79adc16f Author: Fernando Guallini Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/79adc16f Stats: 300 lines in 3 files changed: 78 ins; 130 del; 92 mod 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3466 From rriggs at openjdk.java.net Fri Apr 16 18:33:38 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 16 Apr 2021 18:33:38 GMT Subject: RFR: 8264208: Console charset API [v9] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Thu, 15 Apr 2021 18:29:17 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Modified javadocs per suggestions. For the test, can it be re-written in Java. The direction has been to avoid creating new shell tests as they are fragile. There are test utilities in ProcessTool to make launching and checking for output very easy. src/java.base/share/classes/java/io/InputStreamReader.java line 48: > 46: *

For top efficiency, consider wrapping an InputStreamReader within a > 47: * BufferedReader. For example: > 48: * Oddly, none of the reference in this class to the default charset are links to Charset.defaultCharset(). That would be a useful addition, either in the class javadoc or in the 1-arg constructor that uses the default charset. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Fri Apr 16 18:58:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 16 Apr 2021 18:58:35 GMT Subject: RFR: 8264208: Console charset API [v9] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Fri, 16 Apr 2021 18:15:41 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified javadocs per suggestions. > > src/java.base/share/classes/java/io/InputStreamReader.java line 48: > >> 46: *

For top efficiency, consider wrapping an InputStreamReader within a >> 47: * BufferedReader. For example: >> 48: * > > Oddly, none of the reference in this class to the default charset are links to Charset.defaultCharset(). > That would be a useful addition, either in the class javadoc or in the 1-arg constructor that uses the default charset. Thanks, Roger. Both are good suggestions. Will incorporate them into the next iteration. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From sean.mullan at oracle.com Fri Apr 16 21:02:06 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Apr 2021 17:02:06 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: Hello Reinier, Thanks for the feedback on the JEP. If I read your message correctly, you seem to be primarily concerned with logging and/or restricting access to file and network operations. In my personal view, some of the examples you present that do somewhat sketchy things are probably not a good idea to put in production. There should be additional audits and reviews of code, and code that is not widely used should be eyed with extra suspicion. It may not be quite the same as running untrusted code, but it seems quite near it. It doesn't seem realistic to keep the SecurityManager API and possibly a lot more of related APIs supported for this limited use case. Also if you remove the access control and policy infrastructure from the JDK, then you are responsible for the policy, determining what code is making the check, whether it is trusted or not, etc. That is difficult to implement safely. My guess is that it would become too hard to use, or too hard to implement safely, and would become rarely used (like the Security Manager). That said, I think it is worth exploring (in this JEP) or another JEP ways that we might think about that could help provide DiD protection for network and file access. This is an opportunity to look at the problem with a fresh set of eyes, w/o the existing complicated infrastructure and APIs that encompass the Security Manager. Thanks, Sean On 4/15/21 9:29 PM, Reinier Zwitserloot wrote: > One useful thing that you can do with SecurityManager, which would be > impossible if it is removed, and which isn't described in the 'specific > narrow use cases' section: > > Monitoring and restriction of, specifically, third party libraries. > > 99 out of a 100 modern java projects have a rather long list of > dependencies, and most of those dependencies have a limited and specific > intent. "This library reads EXIM data from a JPG". "This library > marshals JSON into java POJOs". "This library makes QR code PNGs". > > As an app programmer I want to monitor, and optionally restrict what > these libraries can do. I can have?an app that does (and is intended to) > make network connections all the time, but as part of doing the job I > wrote it for, it may be generating some QR PNGs. If the _QR generator > library_ is making network calls? I want to know, and I probably want to > stop it from happening. > > SecurityManager can do that. I don't know of a good way to take care of > this without it, and it is not (currently) described in JEP411. I can't > use OS-level monitoring, because the OS has no awareness of modules / > packages / classnames, so I can't tell it to accept without log or > warning any network access done by the parts of my application that are > supposed to do this, but that I _do_ want it to log, warn, or halt any > attempt by that QR generator library to hit the network. > > The original intent of SecurityManager was clearly to allow you to run > untrusted code on a VM (the 'applet' use case), but this is somewhat > different: It's not so much about attempting to secure presumably > malicious code in a library or applet, but instead about attempting to > secure against operations that ordinary java code may do, but which you > simply aren't expecting from some specific library. > > Some real-world and/or highly plausible examples: > > * An XML parser library may make network calls or open files on disk due > to e.g. XXE shenanigans: See > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing > > ? this isn't just plausible, we have plenty of proof that this has > caused significant security breaches multiple times in XML's history. A > SecurityManager that monitors (or outright denies) specifically the > network and disk access from an XML parser library would have meant XXE > attacks could never have happened. > > * Some twitter library may be invoking a relative-pathed `cmd.exe` in > order to retrieve some system info from windows that cannot be obtained > with any of the core java libraries. Perhaps to check if the twitter > desktop client is installed (the authors of the library may well be > unaware of the new ProcessInfo API). No doubt a scan of all java-tagged > projects on github finds rather a lot of libraries that > Runtime.exec("cmd.exe") for some unexpected, non-malicious purpose. > Nevertheless, ProcessBuilder does apply $PATH processing and a system > operator may not be willing to accept invokes to a relative path that > can be trivially hijacked if some directory in the PATH is compromised, > especially if the programming team that uses the library wasn't > expecting it to do so. A SecurityManager can monitor this and even stop > it from happening. > > * Any library could have the bright idea to 'phone home' and make a > network call simply to give the library author some idea of how > widespread their library is used. This could have an entirely innocuous > purpose: The library author thought it'd be a cool idea to have a live > map of the planet on their website, with a little animated blip every > time their library is used to, say, parse some JSON. SecurityManager is > the simplest way to spot this and stop it. > > I don't think SecurityManager is necessarily?fantastic at stopping > _intentionally malicious behaviour_ by a library written by > untrustworthy charlatans (even though that was its original intent). > But, it does a great job at stopping a misunderstanding between a > library author and the user of said library, such as the rather > plausible scenarios I just described. > > Modern security practices put a lot of focus on monitoring; > SecurityManager can do that too: A SecurityManager is not obligated to > deal with e.g. a notification that some code is attempting to open a > file by throwing SecurityException - they can also simply log or notify > somebody that it is happening and allow it. They could check if the > caller is in a subset of 'blessed' code that has been checked by the dev > team and has sign-off that it is allowed to do it. They could simply do > a quick echo in dev-mode only, just so developers are aware whilst > running tests that some library is doing things that have potential > security implications and open potential surface area for a breach. > > I'm not sure if the file-based configuration of the security manager > (policy files) needs to be kept around to enable this use case, but the > basic infrastructure, and almost all of the various `check` methods in > java.lang.SecurityManager have plausible scenarios where an application > may want to monitor or deny what it triggers on when a library is doing > it that you don't want it to or did not expect to. > > ?--Reinier Zwitserloot From ron.pressler at oracle.com Fri Apr 16 21:25:00 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 16 Apr 2021 21:25:00 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: <01FAFB96-2BB8-45E5-A565-4E339A3343AA@oracle.com> I think it?s worth adding that treating libraries as untrusted code is unworkable over the long run, as their set of permissions possibly needs to be reexamined with every update. On the other hand, JFR can serve as a mechanism for tracing application behaviour, which, when streamed, can serve to raise alerts. ? Ron > On 16 Apr 2021, at 22:02, Sean Mullan wrote: > > Hello Reinier, > > Thanks for the feedback on the JEP. If I read your message correctly, you seem to be primarily concerned with logging and/or restricting access to file and network operations. > > In my personal view, some of the examples you present that do somewhat sketchy things are probably not a good idea to put in production. There should be additional audits and reviews of code, and code that is not widely used should be eyed with extra suspicion. It may not be quite the same as running untrusted code, but it seems quite near it. > > It doesn't seem realistic to keep the SecurityManager API and possibly a lot more of related APIs supported for this limited use case. Also if you remove the access control and policy infrastructure from the JDK, then you are responsible for the policy, determining what code is making the check, whether it is trusted or not, etc. That is difficult to implement safely. My guess is that it would become too hard to use, or too hard to implement safely, and would become rarely used (like the Security Manager). > > That said, I think it is worth exploring (in this JEP) or another JEP ways that we might think about that could help provide DiD protection for network and file access. This is an opportunity to look at the problem with a fresh set of eyes, w/o the existing complicated infrastructure and APIs that encompass the Security Manager. > > Thanks, > Sean > > On 4/15/21 9:29 PM, Reinier Zwitserloot wrote: >> One useful thing that you can do with SecurityManager, which would be impossible if it is removed, and which isn't described in the 'specific narrow use cases' section: >> Monitoring and restriction of, specifically, third party libraries. >> 99 out of a 100 modern java projects have a rather long list of dependencies, and most of those dependencies have a limited and specific intent. "This library reads EXIM data from a JPG". "This library marshals JSON into java POJOs". "This library makes QR code PNGs". >> As an app programmer I want to monitor, and optionally restrict what these libraries can do. I can have an app that does (and is intended to) make network connections all the time, but as part of doing the job I wrote it for, it may be generating some QR PNGs. If the _QR generator library_ is making network calls? I want to know, and I probably want to stop it from happening. >> SecurityManager can do that. I don't know of a good way to take care of this without it, and it is not (currently) described in JEP411. I can't use OS-level monitoring, because the OS has no awareness of modules / packages / classnames, so I can't tell it to accept without log or warning any network access done by the parts of my application that are supposed to do this, but that I _do_ want it to log, warn, or halt any attempt by that QR generator library to hit the network. >> The original intent of SecurityManager was clearly to allow you to run untrusted code on a VM (the 'applet' use case), but this is somewhat different: It's not so much about attempting to secure presumably malicious code in a library or applet, but instead about attempting to secure against operations that ordinary java code may do, but which you simply aren't expecting from some specific library. >> Some real-world and/or highly plausible examples: >> * An XML parser library may make network calls or open files on disk due to e.g. XXE shenanigans: See https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing ? this isn't just plausible, we have plenty of proof that this has caused significant security breaches multiple times in XML's history. A SecurityManager that monitors (or outright denies) specifically the network and disk access from an XML parser library would have meant XXE attacks could never have happened. >> * Some twitter library may be invoking a relative-pathed `cmd.exe` in order to retrieve some system info from windows that cannot be obtained with any of the core java libraries. Perhaps to check if the twitter desktop client is installed (the authors of the library may well be unaware of the new ProcessInfo API). No doubt a scan of all java-tagged projects on github finds rather a lot of libraries that Runtime.exec("cmd.exe") for some unexpected, non-malicious purpose. Nevertheless, ProcessBuilder does apply $PATH processing and a system operator may not be willing to accept invokes to a relative path that can be trivially hijacked if some directory in the PATH is compromised, especially if the programming team that uses the library wasn't expecting it to do so. A SecurityManager can monitor this and even stop it from happening. >> * Any library could have the bright idea to 'phone home' and make a network call simply to give the library author some idea of how widespread their library is used. This could have an entirely innocuous purpose: The library author thought it'd be a cool idea to have a live map of the planet on their website, with a little animated blip every time their library is used to, say, parse some JSON. SecurityManager is the simplest way to spot this and stop it. >> I don't think SecurityManager is necessarily fantastic at stopping _intentionally malicious behaviour_ by a library written by untrustworthy charlatans (even though that was its original intent). But, it does a great job at stopping a misunderstanding between a library author and the user of said library, such as the rather plausible scenarios I just described. >> Modern security practices put a lot of focus on monitoring; SecurityManager can do that too: A SecurityManager is not obligated to deal with e.g. a notification that some code is attempting to open a file by throwing SecurityException - they can also simply log or notify somebody that it is happening and allow it. They could check if the caller is in a subset of 'blessed' code that has been checked by the dev team and has sign-off that it is allowed to do it. They could simply do a quick echo in dev-mode only, just so developers are aware whilst running tests that some library is doing things that have potential security implications and open potential surface area for a breach. >> I'm not sure if the file-based configuration of the security manager (policy files) needs to be kept around to enable this use case, but the basic infrastructure, and almost all of the various `check` methods in java.lang.SecurityManager have plausible scenarios where an application may want to monitor or deny what it triggers on when a library is doing it that you don't want it to or did not expect to. >> --Reinier Zwitserloot From org.openjdk at io7m.com Fri Apr 16 21:37:35 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 16 Apr 2021 21:37:35 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: <20210416213735.535b26a8@sunflower.int.arc7.info> On 2021-04-16T17:02:06 -0400 Sean Mullan wrote: > > That said, I think it is worth exploring (in this JEP) or another JEP > ways that we might think about that could help provide DiD protection > for network and file access. This is an opportunity to look at the > problem with a fresh set of eyes, w/o the existing complicated > infrastructure and APIs that encompass the Security Manager. This is something that has interested me in the past. Although I'm not working on anything currently that would need it, I've often come up against this sort of thing in application plugin systems. That is, users have an application that they do trust and they want to load plugins into it that weren't written by the application author and that they do not necessarily trust. Languages such as Lua handle this fairly well by having programmers create lightweight scripting contexts for running scripts inside a host program. The guest scripts: * Can't call I/O methods if they aren't given access to a a table of I/O methods. This actually extends to not being able to call foreign code at all if access isn't provided; scripts are limited to objects within the provided table. * Can't use unbounded heap space if a custom allocator is handed to the script context. * Can't go into an infinite loop if instruction count limits are enabled (the interpreter is pre-empted or halted if it reaches N instructions, where N is some value configured by the host). * Can't create new threads. * Are probably memory-safe, assuming a lack of bugs in the Lua interpreter. :) Under those constraints, it's pretty tough to do anything disruptive even if you're trying to. Without access to I/O functions and other foreign code in the global table, you're pretty much limited to doing arithmetic. Quietly. And not too much of it. Similar constraints are available for code running under GraalJS [0] and that's certainly achieved without a security manager. I'm more inclined to think something that is rather blunt and brute force can be made to work well than something extremely fine-grained like the security manager. The blunt and brute force method says "put all this small piece of untrusted code in this box, and it's not allowed to do anything other than the very few things I say it can, and the code outside of the box is allowed to do whatever it could normally do". The security manager more or less has to have a large manually-maintained policy for the entire application and everything in it, and I think that's where it falls over. [0]:https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.Builder.html -- Mark Raynsford | https://www.io7m.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From mullan at openjdk.java.net Fri Apr 16 22:20:37 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 16 Apr 2021 22:20:37 GMT Subject: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v7] In-Reply-To: References: Message-ID: <8IlfspYhzndgX5LeIulGnLbZcX9fh1vaxyT6Zjj6Ekk=.4438f51d-2691-4020-8e6f-6141dfb1ffc9@github.com> On Tue, 13 Apr 2021 18:16:30 GMT, Weijun Wang wrote: >> This enhancement contains the following code changes: >> >> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. >> 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. >> 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` >> 4. Tests > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > more spec clarification Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From naoto at openjdk.java.net Sat Apr 17 03:39:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 17 Apr 2021 03:39:55 GMT Subject: RFR: 8264208: Console charset API [v10] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: - Changed shell based test into java based - Added link to Charset#defaultChaset() in InputStreamReader. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/083f6180..238dbb42 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=08-09 Stats: 88 lines in 3 files changed: 27 ins; 51 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From ssahoo at openjdk.java.net Sat Apr 17 08:14:02 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Sat, 17 Apr 2021 08:14:02 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v5] In-Reply-To: References: Message-ID: <9aykiA4ORGyuvq74q103kZuG83aWXB7Ju7Cw_Hr1GG4=.25a2f8a0-b985-4971-a8d0-acfe614ffcf8@github.com> > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Updated Test to remove SunMSCAPI provider SunMSCAPI provider excluded from the supported algorithm provider list because neither the native generated keys are serializable nor PKCS8EncodedKeySpec compatible for certain algorithms like RSA. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/be5d9a62..cb219824 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=03-04 Stats: 41 lines in 1 file changed: 10 ins; 15 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Sat Apr 17 08:16:42 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Sat, 17 Apr 2021 08:16:42 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v4] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 08:34:11 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update CompareKeys.java I have removed processing any KeyGeneration algorithm starts with "SunTls" along with SunMSCAPI. I am getting issues with KeyGenerated through SunMSCAPI provider which are neither serializable nor compatible with PKCS8EncodedKeySpec for certain algorithms like RSA. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From dev at anthonyv.be Sat Apr 17 08:24:00 2021 From: dev at anthonyv.be (Anthony Vanelverdinghe) Date: Sat, 17 Apr 2021 10:24:00 +0200 Subject: =?utf-8?q?Re=3A?==?utf-8?q?_JEP411=3A?= Missing =?utf-8?q?use-case=3A?= Monitoring / restricting libraries In-Reply-To: <20210416213735.535b26a8@sunflower.int.arc7.info> Message-ID: <3616-607a9b00-653-6086a60@136646411> Actually I think GraalVM can already do this today, since the mentioned API is for use with any guest language, and Java can now run as a guest language [1]. Note that this is also reminiscent of the `java.scripting` module (JSR 223), which also has a `ScriptContext` class, but I'm not sure what the long-term plans are for that API. Imho, any new mechanism should be tightly integrated with the module system. In fact, Panama already has the concept of "restricted operations". Currently, access to these operations is enabled with a simple system property, but, quoting from [2]: > We plan, in the future, to make access to restricted operations more integrated with the module system; that is, certain modules might require restricted native access; when an application which depends on said modules is executed, the user might need to provide permissions to said modules to perform restricted native operations, or the runtime will refuse to build the application's module graph. Kind regards, Anthony [1] https://github.com/oracle/graal/tree/master/espresso [2] https://htmlpreview.github.io/?https://github.com/openjdk/panama-foreign/blob/eb2f956aef1d039a0d364eb69ed91bb9293c4387/doc/panama_memaccess.html On Friday, April 16, 2021 23:37 CEST, Mark Raynsford wrote: > On 2021-04-16T17:02:06 -0400 > Sean Mullan wrote: > > > > That said, I think it is worth exploring (in this JEP) or another JEP > > ways that we might think about that could help provide DiD protection > > for network and file access. This is an opportunity to look at the > > problem with a fresh set of eyes, w/o the existing complicated > > infrastructure and APIs that encompass the Security Manager. > > This is something that has interested me in the past. Although I'm not > working on anything currently that would need it, I've often come up > against this sort of thing in application plugin systems. That is, > users have an application that they do trust and they want to load > plugins into it that weren't written by the application author and that > they do not necessarily trust. > > Languages such as Lua handle this fairly well by having programmers > create lightweight scripting contexts for running scripts inside a > host program. The guest scripts: > > * Can't call I/O methods if they aren't given access to a > a table of I/O methods. This actually extends to not being > able to call foreign code at all if access isn't provided; > scripts are limited to objects within the provided table. > > * Can't use unbounded heap space if a custom allocator is > handed to the script context. > > * Can't go into an infinite loop if instruction count limits > are enabled (the interpreter is pre-empted or halted if it > reaches N instructions, where N is some value configured > by the host). > > * Can't create new threads. > > * Are probably memory-safe, assuming a lack of bugs in the > Lua interpreter. :) > > Under those constraints, it's pretty tough to do anything disruptive > even if you're trying to. Without access to I/O functions and other > foreign code in the global table, you're pretty much limited to doing > arithmetic. Quietly. And not too much of it. > > Similar constraints are available for code running under GraalJS [0] > and that's certainly achieved without a security manager. > > I'm more inclined to think something that is rather blunt and brute > force can be made to work well than something extremely fine-grained > like the security manager. The blunt and brute force method says > "put all this small piece of untrusted code in this box, and it's > not allowed to do anything other than the very few things I say it can, > and the code outside of the box is allowed to do whatever it could > normally do". The security manager more or less has to have a large > manually-maintained policy for the entire application and everything in > it, and I think that's where it falls over. > > [0]:https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.Builder.html > > -- > Mark Raynsford | https://www.io7m.com > From ssahoo at openjdk.java.net Sat Apr 17 09:36:55 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Sat, 17 Apr 2021 09:36:55 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v6] In-Reply-To: References: Message-ID: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with two additional commits since the last revision: - Update CompareKeys.java - Update CompareKeys.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/cb219824..cce15c0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=04-05 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From reinier at zwitserloot.com Sat Apr 17 14:08:34 2021 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 17 Apr 2021 16:08:34 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: > Sean wrote: > I read your message correctly, you seem to be primarily concerned with logging and/or restricting access to file and network operations. Process execution as well. > In my personal view, some of the examples you present that do somewhat sketchy things are probably not a good idea to put in production. I'm not sure if you're talking about e.g. an XML parser library that makes a network call - in which case, yes, that was my point: That's probably not great, so we need a strategy to monitor/stop this; there isn't one other than Security Manager, so security manager should probably not be removed yet. Or, are you talking about setting up a SecurityManager to monitor such things. Why would that be 'somewhat sketchy' and 'not a good idea to put in production'? > It doesn't seem realistic to keep the SecurityManager API and possibly a lot more of related APIs supported for this limited use case. It's not 'limited'; quite the opposite. Almost every significant java project out there uses a sizable list of dependencies. > determining what code is making the check, whether it is trusted or not, etc. That is difficult to implement safely. Monitoring (basically, logging unique class names that are the source of a thing) is not particularly complicated. > My guess is that it would become too hard to use, or too hard to implement safely, That would seem to argue for first adding a new API to java to fulfill this use-case, before removing the one way that is currently available. > and would become rarely used (like the Security Manager). Yes, I worry about figuring out how commonly this is done. There are some issues there: * Given e.g. the XXE scare, this should probably be done more than it currently is. * Given that applications are far less readily open sources than libraries are, and this is the domain of, specifically, applications only, the usual strategies to figure out if some use case is commonly employed (namely, checking open source repos) is not going to give any conclusive answers. It's analogous to finding code that configures how your log backends are set up on github: Almost no java project on there does it, because libraries aren't supposed to, and most of the projects are libraries. --Reinier Zwitserloot On Fri, 16 Apr 2021 at 23:05, Sean Mullan wrote: > Hello Reinier, > > Thanks for the feedback on the JEP. If I read your message correctly, > you seem to be primarily concerned with logging and/or restricting > access to file and network operations. > > In my personal view, some of the examples you present that do somewhat > sketchy things are probably not a good idea to put in production. There > should be additional audits and reviews of code, and code that is not > widely used should be eyed with extra suspicion. It may not be quite the > same as running untrusted code, but it seems quite near it. > > It doesn't seem realistic to keep the SecurityManager API and possibly a > lot more of related APIs supported for this limited use case. Also if > you remove the access control and policy infrastructure from the JDK, > then you are responsible for the policy, determining what code is making > the check, whether it is trusted or not, etc. That is difficult to > implement safely. My guess is that it would become too hard to use, or > too hard to implement safely, and would become rarely used (like the > Security Manager). > > That said, I think it is worth exploring (in this JEP) or another JEP > ways that we might think about that could help provide DiD protection > for network and file access. This is an opportunity to look at the > problem with a fresh set of eyes, w/o the existing complicated > infrastructure and APIs that encompass the Security Manager. > > Thanks, > Sean > > On 4/15/21 9:29 PM, Reinier Zwitserloot wrote: > > One useful thing that you can do with SecurityManager, which would be > > impossible if it is removed, and which isn't described in the 'specific > > narrow use cases' section: > > > > Monitoring and restriction of, specifically, third party libraries. > > > > 99 out of a 100 modern java projects have a rather long list of > > dependencies, and most of those dependencies have a limited and specific > > intent. "This library reads EXIM data from a JPG". "This library > > marshals JSON into java POJOs". "This library makes QR code PNGs". > > > > As an app programmer I want to monitor, and optionally restrict what > > these libraries can do. I can have an app that does (and is intended to) > > make network connections all the time, but as part of doing the job I > > wrote it for, it may be generating some QR PNGs. If the _QR generator > > library_ is making network calls? I want to know, and I probably want to > > stop it from happening. > > > > SecurityManager can do that. I don't know of a good way to take care of > > this without it, and it is not (currently) described in JEP411. I can't > > use OS-level monitoring, because the OS has no awareness of modules / > > packages / classnames, so I can't tell it to accept without log or > > warning any network access done by the parts of my application that are > > supposed to do this, but that I _do_ want it to log, warn, or halt any > > attempt by that QR generator library to hit the network. > > > > The original intent of SecurityManager was clearly to allow you to run > > untrusted code on a VM (the 'applet' use case), but this is somewhat > > different: It's not so much about attempting to secure presumably > > malicious code in a library or applet, but instead about attempting to > > secure against operations that ordinary java code may do, but which you > > simply aren't expecting from some specific library. > > > > Some real-world and/or highly plausible examples: > > > > * An XML parser library may make network calls or open files on disk due > > to e.g. XXE shenanigans: See > > > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing > > < > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing> > > > ? this isn't just plausible, we have plenty of proof that this has > > caused significant security breaches multiple times in XML's history. A > > SecurityManager that monitors (or outright denies) specifically the > > network and disk access from an XML parser library would have meant XXE > > attacks could never have happened. > > > > * Some twitter library may be invoking a relative-pathed `cmd.exe` in > > order to retrieve some system info from windows that cannot be obtained > > with any of the core java libraries. Perhaps to check if the twitter > > desktop client is installed (the authors of the library may well be > > unaware of the new ProcessInfo API). No doubt a scan of all java-tagged > > projects on github finds rather a lot of libraries that > > Runtime.exec("cmd.exe") for some unexpected, non-malicious purpose. > > Nevertheless, ProcessBuilder does apply $PATH processing and a system > > operator may not be willing to accept invokes to a relative path that > > can be trivially hijacked if some directory in the PATH is compromised, > > especially if the programming team that uses the library wasn't > > expecting it to do so. A SecurityManager can monitor this and even stop > > it from happening. > > > > * Any library could have the bright idea to 'phone home' and make a > > network call simply to give the library author some idea of how > > widespread their library is used. This could have an entirely innocuous > > purpose: The library author thought it'd be a cool idea to have a live > > map of the planet on their website, with a little animated blip every > > time their library is used to, say, parse some JSON. SecurityManager is > > the simplest way to spot this and stop it. > > > > I don't think SecurityManager is necessarily fantastic at stopping > > _intentionally malicious behaviour_ by a library written by > > untrustworthy charlatans (even though that was its original intent). > > But, it does a great job at stopping a misunderstanding between a > > library author and the user of said library, such as the rather > > plausible scenarios I just described. > > > > Modern security practices put a lot of focus on monitoring; > > SecurityManager can do that too: A SecurityManager is not obligated to > > deal with e.g. a notification that some code is attempting to open a > > file by throwing SecurityException - they can also simply log or notify > > somebody that it is happening and allow it. They could check if the > > caller is in a subset of 'blessed' code that has been checked by the dev > > team and has sign-off that it is allowed to do it. They could simply do > > a quick echo in dev-mode only, just so developers are aware whilst > > running tests that some library is doing things that have potential > > security implications and open potential surface area for a breach. > > > > I'm not sure if the file-based configuration of the security manager > > (policy files) needs to be kept around to enable this use case, but the > > basic infrastructure, and almost all of the various `check` methods in > > java.lang.SecurityManager have plausible scenarios where an application > > may want to monitor or deny what it triggers on when a library is doing > > it that you don't want it to or did not expect to. > > > > --Reinier Zwitserloot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier at zwitserloot.com Sat Apr 17 14:18:50 2021 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 17 Apr 2021 16:18:50 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <01FAFB96-2BB8-45E5-A565-4E339A3343AA@oracle.com> References: <01FAFB96-2BB8-45E5-A565-4E339A3343AA@oracle.com> Message-ID: > Ron wrote: > I think it?s worth adding that treating libraries as untrusted code is unworkable over the long run Well, define 'untrusted'. If you mean: "untrusted" as in it may well contain code explicitly designed to compromise our internal security, put there for malicious purposes by someone who is looking to infiltrate your software, systems, data, or clients ? then, yes, I agree. Don't run libraries that may be compromised, even if you have registered a SecurityManager. But if you mean "untrusted" as in: I did not personally check the full source code of the entire library, and it may be doing things _not_ with malicious intent, but nevertheless something that opens up additional attack surface that I wasn't expecting and need to update my internal security policies accordingly (or outright stop the library from doing it): Then I disagree. Why would it be 'unworkable' to treat libraries this way? I'd say rather the opposite: There will always be misunderstandings between the user of a library and the author of one of what and how it works. There's a bit of community interaction with such things: If, say, the ZXING library (google's QR code generator stuff) ends advertising itself as 'makes QR code images', but is implemented as a light wrapper around https://charts.google.com?qr, then I expect the community to make a bit of a stink on social media about this, but the community cannot necessarily be trusted upon to take that first step quickly (of figuring out a library is doing things that cause one to raise one's eyebrow). There is ample historic context for this, such as the amount of time it took to find heartbleed. Monitoring a library for network access would let you figure out, quickly, that ZXING is not doing what you thought it did. NB: Just to be clear, zxing _does not_ make any network calls. The library generates PNGs with QR codes as you would expect. But it makes for a plausible hypothetical, I think. --Reinier Zwitserloot On Fri, 16 Apr 2021 at 23:28, Ron Pressler wrote: > I think it?s worth adding that treating libraries as untrusted code is > unworkable over the long run, as their set of permissions possibly > needs to be reexamined with every update. On the other hand, JFR can serve > as a mechanism for tracing application behaviour, which, > when streamed, can serve to raise alerts. > > ? Ron > > > On 16 Apr 2021, at 22:02, Sean Mullan wrote: > > > > Hello Reinier, > > > > Thanks for the feedback on the JEP. If I read your message correctly, > you seem to be primarily concerned with logging and/or restricting access > to file and network operations. > > > > In my personal view, some of the examples you present that do somewhat > sketchy things are probably not a good idea to put in production. There > should be additional audits and reviews of code, and code that is not > widely used should be eyed with extra suspicion. It may not be quite the > same as running untrusted code, but it seems quite near it. > > > > It doesn't seem realistic to keep the SecurityManager API and possibly a > lot more of related APIs supported for this limited use case. Also if you > remove the access control and policy infrastructure from the JDK, then you > are responsible for the policy, determining what code is making the check, > whether it is trusted or not, etc. That is difficult to implement safely. > My guess is that it would become too hard to use, or too hard to implement > safely, and would become rarely used (like the Security Manager). > > > > That said, I think it is worth exploring (in this JEP) or another JEP > ways that we might think about that could help provide DiD protection for > network and file access. This is an opportunity to look at the problem with > a fresh set of eyes, w/o the existing complicated infrastructure and APIs > that encompass the Security Manager. > > > > Thanks, > > Sean > > > > On 4/15/21 9:29 PM, Reinier Zwitserloot wrote: > >> One useful thing that you can do with SecurityManager, which would be > impossible if it is removed, and which isn't described in the 'specific > narrow use cases' section: > >> Monitoring and restriction of, specifically, third party libraries. > >> 99 out of a 100 modern java projects have a rather long list of > dependencies, and most of those dependencies have a limited and specific > intent. "This library reads EXIM data from a JPG". "This library marshals > JSON into java POJOs". "This library makes QR code PNGs". > >> As an app programmer I want to monitor, and optionally restrict what > these libraries can do. I can have an app that does (and is intended to) > make network connections all the time, but as part of doing the job I wrote > it for, it may be generating some QR PNGs. If the _QR generator library_ is > making network calls? I want to know, and I probably want to stop it from > happening. > >> SecurityManager can do that. I don't know of a good way to take care of > this without it, and it is not (currently) described in JEP411. I can't use > OS-level monitoring, because the OS has no awareness of modules / packages > / classnames, so I can't tell it to accept without log or warning any > network access done by the parts of my application that are supposed to do > this, but that I _do_ want it to log, warn, or halt any attempt by that QR > generator library to hit the network. > >> The original intent of SecurityManager was clearly to allow you to run > untrusted code on a VM (the 'applet' use case), but this is somewhat > different: It's not so much about attempting to secure presumably malicious > code in a library or applet, but instead about attempting to secure against > operations that ordinary java code may do, but which you simply aren't > expecting from some specific library. > >> Some real-world and/or highly plausible examples: > >> * An XML parser library may make network calls or open files on disk > due to e.g. XXE shenanigans: See > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing > < > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing> > ? this isn't just plausible, we have plenty of proof that this has caused > significant security breaches multiple times in XML's history. A > SecurityManager that monitors (or outright denies) specifically the network > and disk access from an XML parser library would have meant XXE attacks > could never have happened. > >> * Some twitter library may be invoking a relative-pathed `cmd.exe` in > order to retrieve some system info from windows that cannot be obtained > with any of the core java libraries. Perhaps to check if the twitter > desktop client is installed (the authors of the library may well be unaware > of the new ProcessInfo API). No doubt a scan of all java-tagged projects on > github finds rather a lot of libraries that Runtime.exec("cmd.exe") for > some unexpected, non-malicious purpose. Nevertheless, ProcessBuilder does > apply $PATH processing and a system operator may not be willing to accept > invokes to a relative path that can be trivially hijacked if some directory > in the PATH is compromised, especially if the programming team that uses > the library wasn't expecting it to do so. A SecurityManager can monitor > this and even stop it from happening. > >> * Any library could have the bright idea to 'phone home' and make a > network call simply to give the library author some idea of how widespread > their library is used. This could have an entirely innocuous purpose: The > library author thought it'd be a cool idea to have a live map of the planet > on their website, with a little animated blip every time their library is > used to, say, parse some JSON. SecurityManager is the simplest way to spot > this and stop it. > >> I don't think SecurityManager is necessarily fantastic at stopping > _intentionally malicious behaviour_ by a library written by untrustworthy > charlatans (even though that was its original intent). But, it does a great > job at stopping a misunderstanding between a library author and the user of > said library, such as the rather plausible scenarios I just described. > >> Modern security practices put a lot of focus on monitoring; > SecurityManager can do that too: A SecurityManager is not obligated to deal > with e.g. a notification that some code is attempting to open a file by > throwing SecurityException - they can also simply log or notify somebody > that it is happening and allow it. They could check if the caller is in a > subset of 'blessed' code that has been checked by the dev team and has > sign-off that it is allowed to do it. They could simply do a quick echo in > dev-mode only, just so developers are aware whilst running tests that some > library is doing things that have potential security implications and open > potential surface area for a breach. > >> I'm not sure if the file-based configuration of the security manager > (policy files) needs to be kept around to enable this use case, but the > basic infrastructure, and almost all of the various `check` methods in > java.lang.SecurityManager have plausible scenarios where an application may > want to monitor or deny what it triggers on when a library is doing it that > you don't want it to or did not expect to. > >> --Reinier Zwitserloot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Apr 17 14:51:56 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 17 Apr 2021 15:51:56 +0100 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: On 16/04/2021 02:29, Reinier Zwitserloot wrote: > : > > * An XML parser library may make network calls or open files on disk > due to e.g. XXE shenanigans: See > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing > > ? this isn't just plausible, we have plenty of proof that this has > caused significant security breaches multiple times in XML's history. > A SecurityManager that monitors (or outright denies) specifically the > network and disk access from an XML parser library would have meant > XXE attacks could never have happened. > The Security Developer's Guide has a good chapter on this topic [1] as there many configuration knobs to restrict or disable "external access" during XML processing. As things stand, running with a security manager enables FEATURE_SECURE_PROCESSING globally but that is unfortunate coupling and perhaps masks that the security features for XML processing can be controlled programmatically, it doesn't require a security manager to do that. -Alan [1] https://docs.oracle.com/en/java/javase/16/security/java-api-xml-processing-jaxp-security-guide.html From ron.pressler at oracle.com Sat Apr 17 15:09:34 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 17 Apr 2021 15:09:34 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <01FAFB96-2BB8-45E5-A565-4E339A3343AA@oracle.com> Message-ID: <6B1E3E51-D591-4164-A9E6-2640F599664E@oracle.com> Do you regularly use the Security Manager to sandbox your own dependencies and find it convenient and effective ? in which case, could you please describe your practice concretely so that it would be possible to consider alternatives ? or are you saying that you can *envision* such a powerful use-case? The desire to remove the Security Manager does not stem from its theoretical utility, which is absolutely amazing, but from its practical utility, which years of experience have found to be less than amazing after all, and probably too low to justify its burdensome cost. As to monitoring application activity, suspicious or otherwise, JFR is the component for that, and could be effective for the monitoring use-case you describe. ? Ron > On 17 Apr 2021, at 15:18, Reinier Zwitserloot wrote: > > > Ron wrote: > > > I think it?s worth adding that treating libraries as untrusted code is unworkable over the long run > > Well, define 'untrusted'. > > If you mean: "untrusted" as in it may well contain code explicitly designed to compromise our internal security, put there for malicious purposes by someone who is looking to infiltrate your software, systems, data, or clients ? then, yes, I agree. Don't run libraries that may be compromised, even if you have registered a SecurityManager. > > But if you mean "untrusted" as in: I did not personally check the full source code of the entire library, and it may be doing things _not_ with malicious intent, but nevertheless something that opens up additional attack surface that I wasn't expecting and need to update my internal security policies accordingly (or outright stop the library from doing it): Then I disagree. Why would it be 'unworkable' to treat libraries this way? I'd say rather the opposite: There will always be misunderstandings between the user of a library and the author of one of what and how it works. > > There's a bit of community interaction with such things: If, say, the ZXING library (google's QR code generator stuff) ends advertising itself as 'makes QR code images', but is implemented as a light wrapper around https://charts.google.com?qr, then I expect the community to make a bit of a stink on social media about this, but the community cannot necessarily be trusted upon to take that first step quickly (of figuring out a library is doing things that cause one to raise one's eyebrow). There is ample historic context for this, such as the amount of time it took to find heartbleed. Monitoring a library for network access would let you figure out, quickly, that ZXING is not doing what you thought it did. > > NB: Just to be clear, zxing _does not_ make any network calls. The library generates PNGs with QR codes as you would expect. But it makes for a plausible hypothetical, I think. > > --Reinier Zwitserloot > > > On Fri, 16 Apr 2021 at 23:28, Ron Pressler wrote: > I think it?s worth adding that treating libraries as untrusted code is unworkable over the long run, as their set of permissions possibly > needs to be reexamined with every update. On the other hand, JFR can serve as a mechanism for tracing application behaviour, which, > when streamed, can serve to raise alerts. > > ? Ron > > > On 16 Apr 2021, at 22:02, Sean Mullan wrote: > > > > Hello Reinier, > > > > Thanks for the feedback on the JEP. If I read your message correctly, you seem to be primarily concerned with logging and/or restricting access to file and network operations. > > > > In my personal view, some of the examples you present that do somewhat sketchy things are probably not a good idea to put in production. There should be additional audits and reviews of code, and code that is not widely used should be eyed with extra suspicion. It may not be quite the same as running untrusted code, but it seems quite near it. > > > > It doesn't seem realistic to keep the SecurityManager API and possibly a lot more of related APIs supported for this limited use case. Also if you remove the access control and policy infrastructure from the JDK, then you are responsible for the policy, determining what code is making the check, whether it is trusted or not, etc. That is difficult to implement safely. My guess is that it would become too hard to use, or too hard to implement safely, and would become rarely used (like the Security Manager). > > > > That said, I think it is worth exploring (in this JEP) or another JEP ways that we might think about that could help provide DiD protection for network and file access. This is an opportunity to look at the problem with a fresh set of eyes, w/o the existing complicated infrastructure and APIs that encompass the Security Manager. > > > > Thanks, > > Sean > > > > On 4/15/21 9:29 PM, Reinier Zwitserloot wrote: > >> One useful thing that you can do with SecurityManager, which would be impossible if it is removed, and which isn't described in the 'specific narrow use cases' section: > >> Monitoring and restriction of, specifically, third party libraries. > >> 99 out of a 100 modern java projects have a rather long list of dependencies, and most of those dependencies have a limited and specific intent. "This library reads EXIM data from a JPG". "This library marshals JSON into java POJOs". "This library makes QR code PNGs". > >> As an app programmer I want to monitor, and optionally restrict what these libraries can do. I can have an app that does (and is intended to) make network connections all the time, but as part of doing the job I wrote it for, it may be generating some QR PNGs. If the _QR generator library_ is making network calls? I want to know, and I probably want to stop it from happening. > >> SecurityManager can do that. I don't know of a good way to take care of this without it, and it is not (currently) described in JEP411. I can't use OS-level monitoring, because the OS has no awareness of modules / packages / classnames, so I can't tell it to accept without log or warning any network access done by the parts of my application that are supposed to do this, but that I _do_ want it to log, warn, or halt any attempt by that QR generator library to hit the network. > >> The original intent of SecurityManager was clearly to allow you to run untrusted code on a VM (the 'applet' use case), but this is somewhat different: It's not so much about attempting to secure presumably malicious code in a library or applet, but instead about attempting to secure against operations that ordinary java code may do, but which you simply aren't expecting from some specific library. > >> Some real-world and/or highly plausible examples: > >> * An XML parser library may make network calls or open files on disk due to e.g. XXE shenanigans: See https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing ? this isn't just plausible, we have plenty of proof that this has caused significant security breaches multiple times in XML's history. A SecurityManager that monitors (or outright denies) specifically the network and disk access from an XML parser library would have meant XXE attacks could never have happened. > >> * Some twitter library may be invoking a relative-pathed `cmd.exe` in order to retrieve some system info from windows that cannot be obtained with any of the core java libraries. Perhaps to check if the twitter desktop client is installed (the authors of the library may well be unaware of the new ProcessInfo API). No doubt a scan of all java-tagged projects on github finds rather a lot of libraries that Runtime.exec("cmd.exe") for some unexpected, non-malicious purpose. Nevertheless, ProcessBuilder does apply $PATH processing and a system operator may not be willing to accept invokes to a relative path that can be trivially hijacked if some directory in the PATH is compromised, especially if the programming team that uses the library wasn't expecting it to do so. A SecurityManager can monitor this and even stop it from happening. > >> * Any library could have the bright idea to 'phone home' and make a network call simply to give the library author some idea of how widespread their library is used. This could have an entirely innocuous purpose: The library author thought it'd be a cool idea to have a live map of the planet on their website, with a little animated blip every time their library is used to, say, parse some JSON. SecurityManager is the simplest way to spot this and stop it. > >> I don't think SecurityManager is necessarily fantastic at stopping _intentionally malicious behaviour_ by a library written by untrustworthy charlatans (even though that was its original intent). But, it does a great job at stopping a misunderstanding between a library author and the user of said library, such as the rather plausible scenarios I just described. > >> Modern security practices put a lot of focus on monitoring; SecurityManager can do that too: A SecurityManager is not obligated to deal with e.g. a notification that some code is attempting to open a file by throwing SecurityException - they can also simply log or notify somebody that it is happening and allow it. They could check if the caller is in a subset of 'blessed' code that has been checked by the dev team and has sign-off that it is allowed to do it. They could simply do a quick echo in dev-mode only, just so developers are aware whilst running tests that some library is doing things that have potential security implications and open potential surface area for a breach. > >> I'm not sure if the file-based configuration of the security manager (policy files) needs to be kept around to enable this use case, but the basic infrastructure, and almost all of the various `check` methods in java.lang.SecurityManager have plausible scenarios where an application may want to monitor or deny what it triggers on when a library is doing it that you don't want it to or did not expect to. > >> --Reinier Zwitserloot > From dblack at atlassian.com Sun Apr 18 23:50:32 2021 From: dblack at atlassian.com (David Black) Date: Mon, 19 Apr 2021 09:50:32 +1000 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: On Fri, 16 Apr 2021 at 04:05, wrote: > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > - Mark > Hi, How can those interested in the JEP get involved? (I am asking because Atlassian makes use of a custom java security manager, based on the manas security manager[0], to help mitigate SSRF attacks[1]) [0] - https://code.google.com/archive/p/manas-java-security/ [1] - https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager/blob/master/example-security-manager-core/src/main/java/com/google/security/manas/ManasSecurityManager.java#L410 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Apr 19 13:49:31 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Apr 2021 09:49:31 -0400 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: -bcc jdk-dev at openjdk.java.net On 4/18/21 7:50 PM, David Black wrote: > On Fri, 16 Apr 2021 at 04:05, > wrote: > > https://openjdk.java.net/jeps/411 > > ? Summary: Deprecate the Security Manager for removal in a future > ? release. The Security Manager dates from Java 1.0. It has not > been the > ? primary means of securing client-side Java code for many years, > and it > ? has rarely been used to secure server-side code. To move Java > forward, > ? we intend to deprecate the Security Manager for removal in > concert with > ? the legacy Applet API (JEP 398). > > - Mark > > > Hi, > How can those interested in the JEP get involved? Please provide feedback on the security-dev at openjdk.java.net list. --Sean > (I am asking because Atlassian makes use of a custom java security > manager, based on the manas security manager[0], to help mitigate SSRF > attacks[1]) > > > [0] - https://code.google.com/archive/p/manas-java-security/ > > [1] - > https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager/blob/master/example-security-manager-core/src/main/java/com/google/security/manas/ManasSecurityManager.java#L410 > > From weijun at openjdk.java.net Mon Apr 19 14:32:36 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 19 Apr 2021 14:32:36 GMT Subject: Integrated: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params In-Reply-To: References: Message-ID: <07fAq0RCrbT29T3CW8btY0Y4apx4kvMmNKdf0L-uyss=.badb7093-94aa-4c51-836f-bbe90fa9d56b@github.com> On Wed, 24 Mar 2021 21:36:21 GMT, Weijun Wang wrote: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. > 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is aware of the defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests This pull request has now been integrated. Changeset: 8dbf7aa1 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/8dbf7aa1 Stats: 1319 lines in 11 files changed: 1159 ins; 110 del; 50 mod 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/3181 From weijun at openjdk.java.net Mon Apr 19 14:36:18 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 19 Apr 2021 14:36:18 GMT Subject: RFR: 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission [v2] In-Reply-To: References: Message-ID: > These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3266/files - new: https://git.openjdk.java.net/jdk/pull/3266/files/28f783e8..28f783e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3266&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3266&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3266/head:pull/3266 PR: https://git.openjdk.java.net/jdk/pull/3266 From weijun at openjdk.java.net Mon Apr 19 15:05:12 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 19 Apr 2021 15:05:12 GMT Subject: RFR: 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission [v3] In-Reply-To: References: Message-ID: > These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - proc path changed - Merge - 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission - update XMLUtils (not used by tests here) - 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params ------------- Changes: https://git.openjdk.java.net/jdk/pull/3266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3266&range=02 Stats: 140 lines in 2 files changed: 140 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3266/head:pull/3266 PR: https://git.openjdk.java.net/jdk/pull/3266 From weijun at openjdk.java.net Mon Apr 19 16:15:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 19 Apr 2021 16:15:42 GMT Subject: Integrated: 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:02:33 GMT, Weijun Wang wrote: > These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application. This pull request has now been integrated. Changeset: 8bec6fe6 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/8bec6fe6 Stats: 140 lines in 2 files changed: 140 ins; 0 del; 0 mod 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/3266 From sgehwolf at redhat.com Tue Apr 20 10:23:49 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 20 Apr 2021 12:23:49 +0200 Subject: [8u] RFR: 8206925: Support the certificate_authorities extension Message-ID: Hi, Please review this OpenJDK 8u backport of the certificate_authorities extensionj. The OpenJDK 11u patch didn't apply cleanly after path unshuffeling, but was fairly trivial to resolve. Conflicts caused by: 1. X509Authentication.java copyright line conflict only. Resolved manually. 2. SSLContextTemplate.java private interface methods not allowed in JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to default. Note: this is code used in tests only. 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the test invocations since JDK 8u doesn't enable TLSv1.3 on the client side by default. See JDK-8248721, CSR of the TLSv1.3 8u backport. Other than that, the patch is identical to the OpenJDK 11.0.12 version of this patch. This introduces a new system property, jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has been reused from the Oracle JDK backport. See below. Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 CSR: https://bugs.openjdk.java.net/browse/JDK-8248709 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/ Testing: sun/security/ssl tests and tier1. No new regressions. New tests pass. Thoughts? Thanks, Severin From coffeys at openjdk.java.net Tue Apr 20 12:17:29 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 20 Apr 2021 12:17:29 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore Message-ID: Trivial enough change. Improved the exception thrown from JceKeyStore also. ------------- Commit messages: - Fix white space - 8236671: NullPointerException in JKS keystore Changes: https://git.openjdk.java.net/jdk/pull/3588/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3588&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236671 Stats: 17 lines in 3 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3588/head:pull/3588 PR: https://git.openjdk.java.net/jdk/pull/3588 From r.spilker at gmail.com Thu Apr 15 21:10:30 2021 From: r.spilker at gmail.com (Roel Spilker) Date: Thu, 15 Apr 2021 23:10:30 +0200 Subject: JEP411: Restricting/logging library usages using a SecurityManager Message-ID: Hi all, So I do get why RMI and Applets are no longer used. I also agree that the performance and usability of the current implementation is suboptimal, and that configuring the security manager through text files is also not that easy. But on my server application, we use libraries. And I'm very interested on how they behave. I would like to log or restrict the following actions: - Spawning new processes - Unexpected file access - Unexpected network traffic Currently, our application sets a custom written security manager to restrict or log those aspects. For example, we would block all XXE attacks by just having our security manager. In JEP411 I did not find a way to do those things without a security manager. What does the security group think about these use cases? Does it still make sense to deprecate/remove the entire security manager? Would a replacement for certain concerns be in order? Kind regards, Roel Spilker -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Kain at unisys.com Fri Apr 16 14:16:25 2021 From: Michael.Kain at unisys.com (Kain, Michael T) Date: Fri, 16 Apr 2021 14:16:25 +0000 Subject: How do I report a potential bug in OpenJDK? Message-ID: We've been using OpenJDK in a product and since March 17, OpenJDK seems to be reporting a "Certificate Unknown" error on a previously working certificate. Versions are 8.0.212.03, 8.0.282.8, 11.0.5.10, 11.0.10.9. Given that I'm a newbie - debug? Diagnostics? Changelog to look at possible patches which changed function? Mike ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ----------------------------- Mike Kain | Distinguished Engineer and Security Architect, ClearPath MCP systems | ClearPath Forward Unisys | (610)727-5442 | Michael.Kain at unisys.com 801 Lakeview Drive, Suite 100, Mailstop 2818, Blue Bell, PA 19422 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all devices. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 70 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 7719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 776 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 779 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7850 bytes Desc: not available URL: From sionlau0 at gmail.com Sun Apr 18 08:16:39 2021 From: sionlau0 at gmail.com (lau sion) Date: Sun, 18 Apr 2021 16:16:39 +0800 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From sionlau0 at gmail.com Sun Apr 18 08:25:47 2021 From: sionlau0 at gmail.com (lau sion) Date: Sun, 18 Apr 2021 16:25:47 +0800 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at anthonyv.be Tue Apr 20 16:06:40 2021 From: dev at anthonyv.be (Anthony Vanelverdinghe) Date: Tue, 20 Apr 2021 18:06:40 +0200 Subject: JEP =?utf-8?q?411=3A?= methods in j.u.c.Executors In-Reply-To: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: <6936-607efc00-35b-51ef3d80@213965831> The JEP should also address the following methods in java.util.concurrent.Executors: privilegedCallable, privilegedCallableUsingCurrentClassLoader?, privilegedThreadFactory Since AccessController et al. will be terminally deprecated, I'd assume these methods should be as well. Kind regards, Anthony On Thursday, April 15, 2021 20:05 CEST, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > - Mark From hchao at openjdk.java.net Tue Apr 20 16:49:06 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 20 Apr 2021 16:49:06 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:54:39 GMT, Sean Coffey wrote: > Trivial enough change. Improved the exception thrown from JceKeyStore also. Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From xuelei at openjdk.java.net Tue Apr 20 17:03:06 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 20 Apr 2021 17:03:06 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:54:39 GMT, Sean Coffey wrote: > Trivial enough change. Improved the exception thrown from JceKeyStore also. It looks like a public behavior change to me. Did you want to file a CSR and update the specification (KeyStore) as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From Alan.Bateman at oracle.com Tue Apr 20 18:15:53 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Apr 2021 19:15:53 +0100 Subject: JEP411: Restricting/logging library usages using a SecurityManager In-Reply-To: References: Message-ID: <2d44f5b7-c5ba-2366-4612-35ae9983bd96@oracle.com> On 15/04/2021 22:10, Roel Spilker wrote: > : > > But on my server application, we use libraries. And I'm very > interested on how they behave. > > I would?like to log or restrict the following actions: > - Spawning new processes > - Unexpected file access > - Unexpected network traffic > > Currently, our application sets a custom written security?manager to > restrict or log those aspects. It's possible to use bytecode instrumentation and a Java agent to instrument the API classes that support these operations and that may be an alternative. One thing that would be interesting to expand on is what you mean by "restrict"? Do you grant socket permissions to connect to specific hosts or just set your own security manager to log the socket permissions? For Runtime.exec/ProcessBuilder, there are API additions in the works that should help with this too. > > For example, we would block all XXE attacks by just having?our > security manager. > Someone else asked about this a few days ago too. The Security Developer's Guide has a good chapter on this topic [1] as there many configuration knobs to restrict or disable "external access" that don't require setting a SecurityManager. -Alan. [1] https://docs.oracle.com/en/java/javase/16/security/java-api-xml-processing-jaxp-security-guide.html From coffeys at openjdk.java.net Tue Apr 20 20:09:05 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 20 Apr 2021 20:09:05 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 17:00:40 GMT, Xue-Lei Andrew Fan wrote: > It looks like a public behavior change to me. Did you want to file a CSR and update the specification (KeyStore) as well? I think it would be nice if we could keep use the old exception, IllegalArgumentException, as described in the bug. @XueleiFan - The spec in question has been broken for almost 3 years with the throwing of NPE. One issue here is that Sun provider with JKS keystore will throw IllegalArgumentException in older JDK versions but the SunJCE provider and JCEKS keystore throws KeyStoreException when null password is encountered . There's a mismatch. To me, it looks like KeyStoreException is the correct exception in such scenarios (and according to API spec) I can file a CSR to have the implementation adhere to spec if that's desired. ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From ecki at zusammenkunft.net Tue Apr 20 20:10:24 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 20 Apr 2021 20:10:24 +0000 Subject: How do I report a potential bug in OpenJDK? In-Reply-To: References: Message-ID: It is nest to post the verbatim error message and maybe also the URL to reproduce. But if you notice a sudden change in behavior and the cert is not expired, then it?s likely a server-side change. Did you try to connect with browser and OpenSSl cli? You can debug JSSE connections but the exception message should be a good start: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ReadDebug.html Is the ca in the truststores you are using? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Kain, Michael T Gesendet: Dienstag, April 20, 2021 6:05 PM An: security-dev at openjdk.java.net Cc: Kain, Michael T Betreff: How do I report a potential bug in OpenJDK? We?ve been using OpenJDK in a product and since March 17, OpenJDK seems to be reporting a ?Certificate Unknown? error on a previously working certificate. Versions are 8.0.212.03, 8.0.282.8, 11.0.5.10, 11.0.10.9. Given that I?m a newbie ? debug? Diagnostics? Changelog to look at possible patches which changed function? Mike ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Mike Kain | Distinguished Engineer and Security Architect, ClearPath MCP systems | ClearPath Forward Unisys | (610)727-5442 | Michael.Kain at unisys.com 801 Lakeview Drive, Suite 100, Mailstop 2818, Blue Bell, PA 19422 [unisys_logo] THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all devices. [Grey_LI] [Grey_TW] [Grey_GP] [Grey_YT] [Grey_FB] [Grey_UB] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 70 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 7719 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 778 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 776 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 779 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 775 bytes Desc: image006.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 755 bytes Desc: image007.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 791 bytes Desc: image008.jpg URL: From xuelei at openjdk.java.net Tue Apr 20 20:22:08 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 20 Apr 2021 20:22:08 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 20:06:16 GMT, Sean Coffey wrote: > > It looks like a public behavior change to me. Did you want to file a CSR and update the specification (KeyStore) as well? I think it would be nice if we could keep use the old exception, IllegalArgumentException, as described in the bug. > > @XueleiFan - The spec in question has been broken for almost 3 years with the throwing of NPE. > > One issue here is that Sun provider with JKS keystore will throw IllegalArgumentException in older JDK versions but the SunJCE provider and JCEKS keystore throws KeyStoreException when null password is encountered . There's a mismatch. To me, it looks like KeyStoreException is the correct exception in such scenarios (and according to API spec) > > I can file a CSR to have the implementation adhere to spec if that's desired. It makes sense to me. I think it would be good to have this stated in the spec in case more mismatch introduced in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From naoto at openjdk.java.net Tue Apr 20 22:35:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 20 Apr 2021 22:35:00 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato 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: - Refined the test case. - Merge branch 'master' into JDK-8264208 - Changed shell based test into java based - Added link to Charset#defaultChaset() in InputStreamReader. - Modified javadocs per suggestions. - Added @see links. - Added Console::charset() relation with System.in - Added comment to System.out/err init. - Reflected further review comments. - Reverted PrintStream changes - ... and 3 more: https://git.openjdk.java.net/jdk/compare/8cc07521...e585d16f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/238dbb42..e585d16f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=09-10 Stats: 72701 lines in 1955 files changed: 33448 ins; 34099 del; 5154 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Wed Apr 21 00:22:15 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 21 Apr 2021 00:22:15 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v2] In-Reply-To: References: <1JbkIQrU6-4ORkePJ6eMBoCn5zMvaVA3V972J2dECKI=.732e26f0-7205-422b-a87e-33b55db37e30@github.com> <8KJMIC0AzHUXsFORKHq36G0y3-ecHf6ZPAWke5oaqVs=.e2018165-3ebc-44fd-a5ec-5dcbaf25aa4c@github.com> Message-ID: On Fri, 16 Apr 2021 07:37:43 GMT, Sibabrata Sahoo wrote: >> Should be || instead of &&? Would also be nice to know which one(s) failed. > > Considering equality and hashCode check may not be same for all KeyTypes, i have relaxed the verification with || operator. Also added print statement for possible failure checks. Added verification for format too. I am not too sure about this check, please see my other comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From valeriep at openjdk.java.net Wed Apr 21 00:22:16 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 21 Apr 2021 00:22:16 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v6] In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 09:36:55 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with two additional commits since the last revision: > > - Update CompareKeys.java > - Update CompareKeys.java test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 85: > 83: || origKey.hashCode() == copyKey.hashCode()) > 84: && !Arrays.equals(origKey.getEncoded(), copyKey.getEncoded()) > 85: && !origKey.getFormat().equals(copyKey.getFormat())) { So, all of these 3 checks have to fail in order to be considered key inequality? Could you spell out clearly what is expected here? I am not sure if this compound condition is correct. As it is now, the copy must have different format(2nd condition) AND different encoding(3rd condition) AND (not equals AND not same hash code)(1st condition), in order to trigger the RuntimeException. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From valeriep at openjdk.java.net Wed Apr 21 00:22:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 21 Apr 2021 00:22:17 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 07:32:08 GMT, Sibabrata Sahoo wrote: >> test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 114: >> >>> 112: HmacSHA384("HmacSHA384"), >>> 113: HmacSHA512("HmacSHA512"), >>> 114: RC2("RC2"); >> >> Just curious, how are these decided? Should this be an exhaustive list or just enough sampling for code coverage? If this is meant to be a general test, have you tried to not hardcoding the algorithm names to be enum? Otherwise, new algorithms will not be tested if not updating this test. > > Done. Key(pair)Generator list will be collected dynamically. In fact it will now test even the same algorithm names supported by different providers too instead finding the 1st one. Sounds good. >> test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 124: >> >>> 122: public SecretKey genSecretKey() throws Exception { >>> 123: KeyGenerator kg = KeyGenerator.getInstance(this.algoName); >>> 124: return kg.generateKey(); >> >> Would be informative to print out which provider is tested, i.e. where this kg is from. Same goes for KeyPairGenerator. > > Added print statement for KeyGenerator and corresponding Provider. Great, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From valeriep at openjdk.java.net Wed Apr 21 01:29:03 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 21 Apr 2021 01:29:03 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote: > Added capability to allow the PKCS11 Token to be destroyed once a session is logged out from. New configuration properties via pkcs11 config file. Cleaned up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng I will take a look. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3544 From lim.chainz11+mailing at gmail.com Wed Apr 21 05:26:28 2021 From: lim.chainz11+mailing at gmail.com (Lim) Date: Wed, 21 Apr 2021 13:26:28 +0800 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: Hi all, apologize if I interrupted this thread. I agreed on what Reinier has said and I have similar concerns about the removal of SecurityManager. I have developed a "Mod" for a certain game to monitor which "Mods" are using network connections. The mod is a kind of library since other libraries can use them to extend the library functionality such as add-on. In this context, library refers to Mod, a modification that can provide extra features to the base game. These libraries are usually obtained from reputable websites by the end user. However, not all libraries can be obtained in these websites, some which are hosted by the author themselves that are readily compiled. Most of the library in this game does not require network connections to work except, for legitimate reasons such as version checker, downloading required resources, but some requested network connections anyway without reasons. This gives the concern, are the network calls justified for a game that can be played offline? Besides that, Reinier gives good point of why the ability to deny/allow network is important and I would like to give an example when I am developing the library: On 2021-04-16 09:29, Reinier Zwitserloot wrote: > * Any library could have the bright idea to 'phone home' and make a > network call simply to give the library author some idea of how > widespread their library is used. This could have an entirely innocuous > purpose: The library author thought it'd be a cool idea to have a live > map of the planet on their website, with a little animated blip every > time their library is used to, say, parse some JSON. SecurityManager is > the simplest way to spot this and stop it. Although most of the recent libraries do not have analytics that I've seen, I have seen one older version of the library that has analytics enabled without any way to disable except performing bytecode modifications. This has implications to the users' privacy since they do not anticipate it has analytics within them and libraries that have analytics are frowned upon in the mod community. This also violates some of the privacy laws in some countries. The security manager is the only viable way to control these libraries from "phone home" in my opinion. Since the end user "install" these libraries by putting into a specific folder for the loader to launch the game with these modifications. They are not expected to change their system just to know if a particular library has these "features". For example, using firewall/hosts file/DNS/other monitoring tools. It might help but it does not provide insight into which class/package which Reinier has said and that's where the SecurityManager can help. By using the "checkConnect" methods in SecurityManager, I can allow/deny and notify appropriate messages in the log for the end user to check. In addition, there is a configuration that allows the end user to configure which hosts are allowed for the network connections. I hope that the core SecurityManager functionality will be preserved. Will there be an alternative that is able to provide similar functionality through programmatic means for my use case? I have read the comments about using JFR stream/bytecode instrumentation but it required the usage of Java Agent and command line flags which is not acceptable in this use case. Thanks From ron.pressler at oracle.com Wed Apr 21 08:24:15 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 21 Apr 2021 08:24:15 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> Monitoring network connections can be done with JFR. It will tell you which classes perform the connections. It does not require a Java agent. Setting up the SM to *block* connections while also not allowing those libraries to disable the SM is not very easy. Those libraries are trusted, and monitoring is more effective than sandboxing for trusted code. ? Ron > On 21 Apr 2021, at 06:26, Lim wrote: > > Hi all, apologize if I interrupted this thread. > > I agreed on what Reinier has said and I have similar concerns about > the removal of SecurityManager. > > I have developed a "Mod" for a certain game to monitor which "Mods" > are using network connections. The mod is a kind of library since > other libraries can use them to extend the library functionality such > as add-on. In this context, library refers to Mod, a modification that > can provide extra features to the base game. These libraries are > usually obtained from reputable websites by the end user. However, not > all libraries can be obtained in these websites, some which are hosted > by the author themselves that are readily compiled. > > Most of the library in this game does not require network connections > to work except, for legitimate reasons such as version checker, > downloading required resources, but some requested network connections > anyway without reasons. This gives the concern, are the network calls > justified for a game that can be played offline? > > Besides that, Reinier gives good point of why the ability to > deny/allow network is important and I would like to give an example > when I am developing the library: > > On 2021-04-16 09:29, Reinier Zwitserloot wrote: >> * Any library could have the bright idea to 'phone home' and make a >> network call simply to give the library author some idea of how >> widespread their library is used. This could have an entirely innocuous >> purpose: The library author thought it'd be a cool idea to have a live >> map of the planet on their website, with a little animated blip every >> time their library is used to, say, parse some JSON. SecurityManager is >> the simplest way to spot this and stop it. > > Although most of the recent libraries do not have analytics that I've > seen, I have seen one older version of the library that has analytics > enabled without any way to disable except performing bytecode > modifications. This has implications to the users' privacy since they > do not anticipate it has analytics within them and libraries that have > analytics are frowned upon in the mod community. This also violates > some of the privacy laws in some countries. > > The security manager is the only viable way to control these libraries > from "phone home" in my opinion. Since the end user "install" these > libraries by putting into a specific folder for the loader to launch > the game with these modifications. They are not expected to change > their system just to know if a particular library has these > "features". For example, using firewall/hosts file/DNS/other > monitoring tools. It might help but it does not provide insight into > which class/package which Reinier has said and that's where the > SecurityManager can help. > > By using the "checkConnect" methods in SecurityManager, I can > allow/deny and notify appropriate messages in the log for the end user > to check. In addition, there is a configuration that allows the end > user to configure which hosts are allowed for the network connections. > > I hope that the core SecurityManager functionality will be preserved. > Will there be an alternative that is able to provide similar > functionality through programmatic means for my use case? I have read > the comments about using JFR stream/bytecode instrumentation but it > required the usage of Java Agent and command line flags which is not > acceptable in this use case. > > Thanks From lim.chainz11+mailing at gmail.com Wed Apr 21 12:28:06 2021 From: lim.chainz11+mailing at gmail.com (Lim) Date: Wed, 21 Apr 2021 20:28:06 +0800 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> Message-ID: > Monitoring network connections can be done with JFR. It will tell you which classes > perform the connections. It does not require a Java agent. Hi Ron, I read about the JFR and it required a command line argument "-XX:StartFlightRecording" and it is not suitable since it is distributed to the *end user*. Does JFR able capture the URLs performed by those libraries (which can be obtained by getting the name of URLPermission)? I have used it before in JMC and it only shows the hostname address only. Is there an alternative besides JFR that is capable of using programmatically means like SM such as setSecurityManager, ability to capture logs, perform blocking in real time? If JFR is capable of operating *without using command line flags*, can you please link it to the relevant documentation? Besides that, if using JFR streams, can it be used with JMC concurrently? > Setting up the SM to *block* connections while also not allowing those libraries to > disable the SM is not very easy. Well if those libraries are able to disable SM, those libraries are able to circumvent the native restrictions of the operating system too. But these mostly occur in malicious-like libraries that are less well known or in the worst possible case, popular libraries that are hijacked. >Those libraries are trusted, and monitoring is more effective than sandboxing for trusted code. I disagree to a degree, not all libraries can be vetted by the operators of the websites, especially those who do not use those distribution websites. This is because some of the libraries might be obfuscated by the library authors themselves and thus unable to determine the trustworthiness, or libraries are unknowingly tampered by 3rd parties. Not every end user will know how to perform hash checking of the downloaded library, even more on verifying the signature of the library. The users implicitly trust because they assume the distribution sites will perform checks on the library for malicious code. They rely on users reporting the library that is malicious. This means that there is a chance that untrustworthy code is executed before knowing it. In addition, assume if the end user needs to decide if the library is "trusted" before they introduce it to the game, but not everyone has the knowledge to audit those libraries themselves. For example, if I have downloaded a modpack that contains 100 mods (which are libraries that are bundled together), do I need to audit each one or will the producer of the pack perform the audit? I believe it will be a waste of time since some of the library is frequently updated with features and bug fixes. For a hypothetical scenario: I have developed a popular library that has intuitive APIs, and this library is constantly updated with features and in one day, I have added a "subtle feature" to gather and upload sensitive information of the monetization purpose and this code is not found in the source. Assuming the user has a monitoring library using the JFR streams, it was able to detect the unknown remote connection to the author server, but it is already too late since when you see the log, it has already happened. I would like to ask in this scenario, what is the best possible solution to mitigate it for the end user perspective besides not downloading it since it can be included implicitly as a dependency, and how can I help the end user to mitigate this scenario? - Lim On Wed, Apr 21, 2021 at 4:24 PM Ron Pressler wrote: > > Monitoring network connections can be done with JFR. It will tell you which classes > perform the connections. It does not require a Java agent. > > Setting up the SM to *block* connections while also not allowing those libraries to > disable the SM is not very easy. Those libraries are trusted, and monitoring is > more effective than sandboxing for trusted code. > > ? Ron > > > On 21 Apr 2021, at 06:26, Lim wrote: > > > > Hi all, apologize if I interrupted this thread. > > > > I agreed on what Reinier has said and I have similar concerns about > > the removal of SecurityManager. > > > > I have developed a "Mod" for a certain game to monitor which "Mods" > > are using network connections. The mod is a kind of library since > > other libraries can use them to extend the library functionality such > > as add-on. In this context, library refers to Mod, a modification that > > can provide extra features to the base game. These libraries are > > usually obtained from reputable websites by the end user. However, not > > all libraries can be obtained in these websites, some which are hosted > > by the author themselves that are readily compiled. > > > > Most of the library in this game does not require network connections > > to work except, for legitimate reasons such as version checker, > > downloading required resources, but some requested network connections > > anyway without reasons. This gives the concern, are the network calls > > justified for a game that can be played offline? > > > > Besides that, Reinier gives good point of why the ability to > > deny/allow network is important and I would like to give an example > > when I am developing the library: > > > > On 2021-04-16 09:29, Reinier Zwitserloot wrote: > >> * Any library could have the bright idea to 'phone home' and make a > >> network call simply to give the library author some idea of how > >> widespread their library is used. This could have an entirely innocuous > >> purpose: The library author thought it'd be a cool idea to have a live > >> map of the planet on their website, with a little animated blip every > >> time their library is used to, say, parse some JSON. SecurityManager is > >> the simplest way to spot this and stop it. > > > > Although most of the recent libraries do not have analytics that I've > > seen, I have seen one older version of the library that has analytics > > enabled without any way to disable except performing bytecode > > modifications. This has implications to the users' privacy since they > > do not anticipate it has analytics within them and libraries that have > > analytics are frowned upon in the mod community. This also violates > > some of the privacy laws in some countries. > > > > The security manager is the only viable way to control these libraries > > from "phone home" in my opinion. Since the end user "install" these > > libraries by putting into a specific folder for the loader to launch > > the game with these modifications. They are not expected to change > > their system just to know if a particular library has these > > "features". For example, using firewall/hosts file/DNS/other > > monitoring tools. It might help but it does not provide insight into > > which class/package which Reinier has said and that's where the > > SecurityManager can help. > > > > By using the "checkConnect" methods in SecurityManager, I can > > allow/deny and notify appropriate messages in the log for the end user > > to check. In addition, there is a configuration that allows the end > > user to configure which hosts are allowed for the network connections. > > > > I hope that the core SecurityManager functionality will be preserved. > > Will there be an alternative that is able to provide similar > > functionality through programmatic means for my use case? I have read > > the comments about using JFR stream/bytecode instrumentation but it > > required the usage of Java Agent and command line flags which is not > > acceptable in this use case. > > > > Thanks > From ron.pressler at oracle.com Wed Apr 21 12:38:11 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 21 Apr 2021 12:38:11 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> Message-ID: <44BEE615-D56A-4790-989A-2CDAE66F28FE@oracle.com> Using JFR does not require that command-line option; it?s required only for specific kinds of use. Its current events might be not have everything you want, but will be expanded, in part to address the functionality that will be lost with the removal of Security Manager. And yes, I believe it is possible to use JFR streaming and recording at the same time, but perhaps a JFR expert will chime in. Libraries that can disable the Security Manager aren?t able to circumvent OS-level sandboxing. If you?re not afraid of that, then they?re trusted and JFR is superior; if they?re untrusted, then configuring the Security Manager correctly for untrusted rich libraries is very difficult. There is no argument that this is a powerful capability *in theory*; the problem is that it?s difficult to correctly employ this capability correctly *in practice*. See this paper for an empirical study: http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf The point is that while you *think* SM gives you a useful sandboxing capability, in practice, in most cases it doesn?t. ? Ron On 21 Apr 2021, at 13:28, Lim > wrote: Monitoring network connections can be done with JFR. It will tell you which classes perform the connections. It does not require a Java agent. Hi Ron, I read about the JFR and it required a command line argument "-XX:StartFlightRecording" and it is not suitable since it is distributed to the *end user*. Does JFR able capture the URLs performed by those libraries (which can be obtained by getting the name of URLPermission)? I have used it before in JMC and it only shows the hostname address only. Is there an alternative besides JFR that is capable of using programmatically means like SM such as setSecurityManager, ability to capture logs, perform blocking in real time? If JFR is capable of operating *without using command line flags*, can you please link it to the relevant documentation? Besides that, if using JFR streams, can it be used with JMC concurrently? Setting up the SM to *block* connections while also not allowing those libraries to disable the SM is not very easy. Well if those libraries are able to disable SM, those libraries are able to circumvent the native restrictions of the operating system too. But these mostly occur in malicious-like libraries that are less well known or in the worst possible case, popular libraries that are hijacked. Those libraries are trusted, and monitoring is more effective than sandboxing for trusted code. I disagree to a degree, not all libraries can be vetted by the operators of the websites, especially those who do not use those distribution websites. This is because some of the libraries might be obfuscated by the library authors themselves and thus unable to determine the trustworthiness, or libraries are unknowingly tampered by 3rd parties. Not every end user will know how to perform hash checking of the downloaded library, even more on verifying the signature of the library. The users implicitly trust because they assume the distribution sites will perform checks on the library for malicious code. They rely on users reporting the library that is malicious. This means that there is a chance that untrustworthy code is executed before knowing it. In addition, assume if the end user needs to decide if the library is "trusted" before they introduce it to the game, but not everyone has the knowledge to audit those libraries themselves. For example, if I have downloaded a modpack that contains 100 mods (which are libraries that are bundled together), do I need to audit each one or will the producer of the pack perform the audit? I believe it will be a waste of time since some of the library is frequently updated with features and bug fixes. For a hypothetical scenario: I have developed a popular library that has intuitive APIs, and this library is constantly updated with features and in one day, I have added a "subtle feature" to gather and upload sensitive information of the monetization purpose and this code is not found in the source. Assuming the user has a monitoring library using the JFR streams, it was able to detect the unknown remote connection to the author server, but it is already too late since when you see the log, it has already happened. I would like to ask in this scenario, what is the best possible solution to mitigate it for the end user perspective besides not downloading it since it can be included implicitly as a dependency, and how can I help the end user to mitigate this scenario? - Lim On Wed, Apr 21, 2021 at 4:24 PM Ron Pressler > wrote: Monitoring network connections can be done with JFR. It will tell you which classes perform the connections. It does not require a Java agent. Setting up the SM to *block* connections while also not allowing those libraries to disable the SM is not very easy. Those libraries are trusted, and monitoring is more effective than sandboxing for trusted code. ? Ron On 21 Apr 2021, at 06:26, Lim > wrote: Hi all, apologize if I interrupted this thread. I agreed on what Reinier has said and I have similar concerns about the removal of SecurityManager. I have developed a "Mod" for a certain game to monitor which "Mods" are using network connections. The mod is a kind of library since other libraries can use them to extend the library functionality such as add-on. In this context, library refers to Mod, a modification that can provide extra features to the base game. These libraries are usually obtained from reputable websites by the end user. However, not all libraries can be obtained in these websites, some which are hosted by the author themselves that are readily compiled. Most of the library in this game does not require network connections to work except, for legitimate reasons such as version checker, downloading required resources, but some requested network connections anyway without reasons. This gives the concern, are the network calls justified for a game that can be played offline? Besides that, Reinier gives good point of why the ability to deny/allow network is important and I would like to give an example when I am developing the library: On 2021-04-16 09:29, Reinier Zwitserloot wrote: * Any library could have the bright idea to 'phone home' and make a network call simply to give the library author some idea of how widespread their library is used. This could have an entirely innocuous purpose: The library author thought it'd be a cool idea to have a live map of the planet on their website, with a little animated blip every time their library is used to, say, parse some JSON. SecurityManager is the simplest way to spot this and stop it. Although most of the recent libraries do not have analytics that I've seen, I have seen one older version of the library that has analytics enabled without any way to disable except performing bytecode modifications. This has implications to the users' privacy since they do not anticipate it has analytics within them and libraries that have analytics are frowned upon in the mod community. This also violates some of the privacy laws in some countries. The security manager is the only viable way to control these libraries from "phone home" in my opinion. Since the end user "install" these libraries by putting into a specific folder for the loader to launch the game with these modifications. They are not expected to change their system just to know if a particular library has these "features". For example, using firewall/hosts file/DNS/other monitoring tools. It might help but it does not provide insight into which class/package which Reinier has said and that's where the SecurityManager can help. By using the "checkConnect" methods in SecurityManager, I can allow/deny and notify appropriate messages in the log for the end user to check. In addition, there is a configuration that allows the end user to configure which hosts are allowed for the network connections. I hope that the core SecurityManager functionality will be preserved. Will there be an alternative that is able to provide similar functionality through programmatic means for my use case? I have read the comments about using JFR stream/bytecode instrumentation but it required the usage of Java Agent and command line flags which is not acceptable in this use case. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Apr 21 12:55:41 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 21 Apr 2021 12:55:41 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> Message-ID: <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> P.S. In your hypothetical scenario you?re treating the library as untrusted code. In that case, even today Security Manager is not the best option because correctly creating a sandbox that is both hermetically secure against *untrusted* code (i.e. possibly malicious) and allows it to use a rich set of APIs (i.e. it isn?t a self-contained Applet) is very, very hard, and usually requires the host application to be written with the SM in mind, i.e. to use AccessController.doPrivileged; how many applications/libraries do that correctly? For rich libraries and applications, your best bet is an OS-level sandbox. The Security Manager might give you a false sense of security. ? Ron > On 21 Apr 2021, at 13:28, Lim wrote: > >> Monitoring network connections can be done with JFR. It will tell you which classes >> perform the connections. It does not require a Java agent. > > Hi Ron, I read about the JFR and it required a command line argument > "-XX:StartFlightRecording" and it is not suitable since it is > distributed to the *end user*. Does JFR able capture the URLs > performed by those libraries (which can be obtained by getting the > name of URLPermission)? I have used it before in JMC and it only shows > the hostname address only. Is there an alternative besides JFR that is > capable of using programmatically means like SM such as > setSecurityManager, ability to capture logs, perform blocking in real > time? > If JFR is capable of operating *without using command line flags*, can > you please link it to the relevant documentation? Besides that, if > using JFR streams, can it be used with JMC concurrently? > >> Setting up the SM to *block* connections while also not allowing those libraries to >> disable the SM is not very easy. > > Well if those libraries are able to disable SM, those libraries are > able to circumvent the native restrictions of the operating system > too. But these mostly occur in malicious-like libraries that are less > well known or in the worst possible case, popular libraries that are > hijacked. > >> Those libraries are trusted, and monitoring is more effective than sandboxing for trusted code. > > I disagree to a degree, not all libraries can be vetted by the > operators of the websites, especially those who do not use those > distribution websites. This is because some of the libraries might be > obfuscated by the library authors themselves and thus unable to > determine the trustworthiness, or libraries are unknowingly tampered > by 3rd parties. Not every end user will know how to perform hash > checking of the downloaded library, even more on verifying the > signature of the library. The users implicitly trust because they > assume the distribution sites will perform checks on the library for > malicious code. They rely on users reporting the library that is > malicious. This means that there is a chance that untrustworthy code > is executed before knowing it. > > In addition, assume if the end user needs to decide if the library is > "trusted" before they introduce it to the game, but not everyone has > the knowledge to audit those libraries themselves. For example, if I > have downloaded a modpack that contains 100 mods (which are libraries > that are bundled together), do I need to audit each one or will the > producer of the pack perform the audit? I believe it will be a waste > of time since some of the library is frequently updated with features > and bug fixes. > > For a hypothetical scenario: I have developed a popular library that > has intuitive APIs, and this library is constantly updated with > features and in one day, I have added a "subtle feature" to gather and > upload sensitive information of the monetization purpose and this code > is not found in the source. Assuming the user has a monitoring library > using the JFR streams, it was able to detect the unknown remote > connection to the author server, but it is already too late since when > you see the log, it has already happened. > > I would like to ask in this scenario, what is the best possible > solution to mitigate it for the end user perspective besides not > downloading it since it can be included implicitly as a dependency, > and how can I help the end user to mitigate this scenario? > > - Lim > > > > > > > On Wed, Apr 21, 2021 at 4:24 PM Ron Pressler wrote: >> >> Monitoring network connections can be done with JFR. It will tell you which classes >> perform the connections. It does not require a Java agent. >> >> Setting up the SM to *block* connections while also not allowing those libraries to >> disable the SM is not very easy. Those libraries are trusted, and monitoring is >> more effective than sandboxing for trusted code. >> >> ? Ron >> >>> On 21 Apr 2021, at 06:26, Lim wrote: >>> >>> Hi all, apologize if I interrupted this thread. >>> >>> I agreed on what Reinier has said and I have similar concerns about >>> the removal of SecurityManager. >>> >>> I have developed a "Mod" for a certain game to monitor which "Mods" >>> are using network connections. The mod is a kind of library since >>> other libraries can use them to extend the library functionality such >>> as add-on. In this context, library refers to Mod, a modification that >>> can provide extra features to the base game. These libraries are >>> usually obtained from reputable websites by the end user. However, not >>> all libraries can be obtained in these websites, some which are hosted >>> by the author themselves that are readily compiled. >>> >>> Most of the library in this game does not require network connections >>> to work except, for legitimate reasons such as version checker, >>> downloading required resources, but some requested network connections >>> anyway without reasons. This gives the concern, are the network calls >>> justified for a game that can be played offline? >>> >>> Besides that, Reinier gives good point of why the ability to >>> deny/allow network is important and I would like to give an example >>> when I am developing the library: >>> >>> On 2021-04-16 09:29, Reinier Zwitserloot wrote: >>>> * Any library could have the bright idea to 'phone home' and make a >>>> network call simply to give the library author some idea of how >>>> widespread their library is used. This could have an entirely innocuous >>>> purpose: The library author thought it'd be a cool idea to have a live >>>> map of the planet on their website, with a little animated blip every >>>> time their library is used to, say, parse some JSON. SecurityManager is >>>> the simplest way to spot this and stop it. >>> >>> Although most of the recent libraries do not have analytics that I've >>> seen, I have seen one older version of the library that has analytics >>> enabled without any way to disable except performing bytecode >>> modifications. This has implications to the users' privacy since they >>> do not anticipate it has analytics within them and libraries that have >>> analytics are frowned upon in the mod community. This also violates >>> some of the privacy laws in some countries. >>> >>> The security manager is the only viable way to control these libraries >>> from "phone home" in my opinion. Since the end user "install" these >>> libraries by putting into a specific folder for the loader to launch >>> the game with these modifications. They are not expected to change >>> their system just to know if a particular library has these >>> "features". For example, using firewall/hosts file/DNS/other >>> monitoring tools. It might help but it does not provide insight into >>> which class/package which Reinier has said and that's where the >>> SecurityManager can help. >>> >>> By using the "checkConnect" methods in SecurityManager, I can >>> allow/deny and notify appropriate messages in the log for the end user >>> to check. In addition, there is a configuration that allows the end >>> user to configure which hosts are allowed for the network connections. >>> >>> I hope that the core SecurityManager functionality will be preserved. >>> Will there be an alternative that is able to provide similar >>> functionality through programmatic means for my use case? I have read >>> the comments about using JFR stream/bytecode instrumentation but it >>> required the usage of Java Agent and command line flags which is not >>> acceptable in this use case. >>> >>> Thanks >> From mullan at openjdk.java.net Wed Apr 21 13:23:35 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 21 Apr 2021 13:23:35 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:54:39 GMT, Sean Coffey wrote: > Trivial enough change. Improved the exception thrown from JceKeyStore also. src/java.base/share/classes/sun/security/provider/JavaKeyStore.java line 290: > 288: > 289: // Protect the encoding of the key > 290: if (password == null) { You could move this check earlier, before the try block. ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From duke at openjdk.java.net Wed Apr 21 13:38:41 2021 From: duke at openjdk.java.net (duke) Date: Wed, 21 Apr 2021 13:38:41 GMT Subject: Withdrawn: 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 been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From markus.gronlund at oracle.com Wed Apr 21 14:31:58 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 21 Apr 2021 14:31:58 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Hi Lim and Ron, Some information about JFR that can be pertinent to this discussion: JFR is flexible when it comes to control, with many entry points: command-line, jcmd, JMX, and programmatically via the Java API which I think is relevant for your use case [1] [2]. There is currently no support for JFR Event Streaming in JDK Mission Control. If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. A Java Agent can be loaded dynamically, without command-line options, see [4] "Starting and Agent after VM Startup". However, this dynamic approach requires bytecode programming to some extent. You might want to take a look at the new JMC Agent that was just released might be useful as a reference [5]. If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. Thank you Markus [1] https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jfr/jdk/jfr/Recording.html [2] https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jfr/jdk/jfr/consumer/RecordingStream.html [3] https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jfr/jdk/jfr/Event.html [4] https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/package-summary.html [5] https://developers.redhat.com/blog/2020/10/29/collect-jdk-flight-recorder-events-at-runtime-with-jmc-agent/ -----Original Message----- From: security-dev On Behalf Of Ron Pressler Sent: den 21 april 2021 14:56 To: Lim Cc: security-dev at openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries P.S. In your hypothetical scenario you?re treating the library as untrusted code. In that case, even today Security Manager is not the best option because correctly creating a sandbox that is both hermetically secure against *untrusted* code (i.e. possibly malicious) and allows it to use a rich set of APIs (i.e. it isn?t a self-contained Applet) is very, very hard, and usually requires the host application to be written with the SM in mind, i.e. to use AccessController.doPrivileged; how many applications/libraries do that correctly? For rich libraries and applications, your best bet is an OS-level sandbox. The Security Manager might give you a false sense of security. ? Ron > On 21 Apr 2021, at 13:28, Lim wrote: > >> Monitoring network connections can be done with JFR. It will tell you >> which classes perform the connections. It does not require a Java agent. > > Hi Ron, I read about the JFR and it required a command line argument > "-XX:StartFlightRecording" and it is not suitable since it is > distributed to the *end user*. Does JFR able capture the URLs > performed by those libraries (which can be obtained by getting the > name of URLPermission)? I have used it before in JMC and it only shows > the hostname address only. Is there an alternative besides JFR that is > capable of using programmatically means like SM such as > setSecurityManager, ability to capture logs, perform blocking in real > time? > If JFR is capable of operating *without using command line flags*, can > you please link it to the relevant documentation? Besides that, if > using JFR streams, can it be used with JMC concurrently? > >> Setting up the SM to *block* connections while also not allowing >> those libraries to disable the SM is not very easy. > > Well if those libraries are able to disable SM, those libraries are > able to circumvent the native restrictions of the operating system > too. But these mostly occur in malicious-like libraries that are less > well known or in the worst possible case, popular libraries that are > hijacked. > >> Those libraries are trusted, and monitoring is more effective than sandboxing for trusted code. > > I disagree to a degree, not all libraries can be vetted by the > operators of the websites, especially those who do not use those > distribution websites. This is because some of the libraries might be > obfuscated by the library authors themselves and thus unable to > determine the trustworthiness, or libraries are unknowingly tampered > by 3rd parties. Not every end user will know how to perform hash > checking of the downloaded library, even more on verifying the > signature of the library. The users implicitly trust because they > assume the distribution sites will perform checks on the library for > malicious code. They rely on users reporting the library that is > malicious. This means that there is a chance that untrustworthy code > is executed before knowing it. > > In addition, assume if the end user needs to decide if the library is > "trusted" before they introduce it to the game, but not everyone has > the knowledge to audit those libraries themselves. For example, if I > have downloaded a modpack that contains 100 mods (which are libraries > that are bundled together), do I need to audit each one or will the > producer of the pack perform the audit? I believe it will be a waste > of time since some of the library is frequently updated with features > and bug fixes. > > For a hypothetical scenario: I have developed a popular library that > has intuitive APIs, and this library is constantly updated with > features and in one day, I have added a "subtle feature" to gather and > upload sensitive information of the monetization purpose and this code > is not found in the source. Assuming the user has a monitoring library > using the JFR streams, it was able to detect the unknown remote > connection to the author server, but it is already too late since when > you see the log, it has already happened. > > I would like to ask in this scenario, what is the best possible > solution to mitigate it for the end user perspective besides not > downloading it since it can be included implicitly as a dependency, > and how can I help the end user to mitigate this scenario? > > - Lim > > > > > > > On Wed, Apr 21, 2021 at 4:24 PM Ron Pressler wrote: >> >> Monitoring network connections can be done with JFR. It will tell you >> which classes perform the connections. It does not require a Java agent. >> >> Setting up the SM to *block* connections while also not allowing >> those libraries to disable the SM is not very easy. Those libraries >> are trusted, and monitoring is more effective than sandboxing for trusted code. >> >> ? Ron >> >>> On 21 Apr 2021, at 06:26, Lim wrote: >>> >>> Hi all, apologize if I interrupted this thread. >>> >>> I agreed on what Reinier has said and I have similar concerns about >>> the removal of SecurityManager. >>> >>> I have developed a "Mod" for a certain game to monitor which "Mods" >>> are using network connections. The mod is a kind of library since >>> other libraries can use them to extend the library functionality >>> such as add-on. In this context, library refers to Mod, a >>> modification that can provide extra features to the base game. These >>> libraries are usually obtained from reputable websites by the end >>> user. However, not all libraries can be obtained in these websites, >>> some which are hosted by the author themselves that are readily compiled. >>> >>> Most of the library in this game does not require network >>> connections to work except, for legitimate reasons such as version >>> checker, downloading required resources, but some requested network >>> connections anyway without reasons. This gives the concern, are the >>> network calls justified for a game that can be played offline? >>> >>> Besides that, Reinier gives good point of why the ability to >>> deny/allow network is important and I would like to give an example >>> when I am developing the library: >>> >>> On 2021-04-16 09:29, Reinier Zwitserloot wrote: >>>> * Any library could have the bright idea to 'phone home' and make a >>>> network call simply to give the library author some idea of how >>>> widespread their library is used. This could have an entirely >>>> innocuous >>>> purpose: The library author thought it'd be a cool idea to have a >>>> live map of the planet on their website, with a little animated >>>> blip every time their library is used to, say, parse some JSON. >>>> SecurityManager is the simplest way to spot this and stop it. >>> >>> Although most of the recent libraries do not have analytics that >>> I've seen, I have seen one older version of the library that has >>> analytics enabled without any way to disable except performing >>> bytecode modifications. This has implications to the users' privacy >>> since they do not anticipate it has analytics within them and >>> libraries that have analytics are frowned upon in the mod community. >>> This also violates some of the privacy laws in some countries. >>> >>> The security manager is the only viable way to control these >>> libraries from "phone home" in my opinion. Since the end user >>> "install" these libraries by putting into a specific folder for the >>> loader to launch the game with these modifications. They are not >>> expected to change their system just to know if a particular library >>> has these "features". For example, using firewall/hosts >>> file/DNS/other monitoring tools. It might help but it does not >>> provide insight into which class/package which Reinier has said and >>> that's where the SecurityManager can help. >>> >>> By using the "checkConnect" methods in SecurityManager, I can >>> allow/deny and notify appropriate messages in the log for the end >>> user to check. In addition, there is a configuration that allows the >>> end user to configure which hosts are allowed for the network connections. >>> >>> I hope that the core SecurityManager functionality will be preserved. >>> Will there be an alternative that is able to provide similar >>> functionality through programmatic means for my use case? I have >>> read the comments about using JFR stream/bytecode instrumentation >>> but it required the usage of Java Agent and command line flags which >>> is not acceptable in this use case. >>> >>> Thanks >> From xuelei at openjdk.java.net Thu Apr 22 04:13:54 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 22 Apr 2021 04:13:54 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output [v2] In-Reply-To: References: Message-ID: > As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. > > The handshake status could have more precise status if the out bound. The patch was confirmed by the bug submitter. Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - improved fix - 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3292/files - new: https://git.openjdk.java.net/jdk/pull/3292/files/5f01932b..989e9ad3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3292&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3292&range=00-01 Stats: 103794 lines in 2432 files changed: 57154 ins; 38351 del; 8289 mod Patch: https://git.openjdk.java.net/jdk/pull/3292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3292/head:pull/3292 PR: https://git.openjdk.java.net/jdk/pull/3292 From fguallini at openjdk.java.net Thu Apr 22 11:52:33 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 22 Apr 2021 11:52:33 GMT Subject: RFR: 8228442: DHKeyExchange/LegacyDHEKeyExchange.java failed due to "SSLException: An established connection was aborted by the software in your host machine" Message-ID: Test DHKeyExchange/LegacyDHEKeyExchange.java has been seen to fail intermittently. There is a thread synchronisation issue that is fixed by: - Using SSLSocketTemplate that handles client/server socket configuration and synchronisation before connection - Making use of a CountDownLatch and socket linger to facilitate the socket to close gracefully after both ends have finished the transmission ------------- Commit messages: - add linger-on-close - LegacyDHEKeyExchange uses SSLSocketTemplate, fix intermittent failure Changes: https://git.openjdk.java.net/jdk/pull/3622/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3622&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228442 Stats: 287 lines in 1 file changed: 14 ins; 252 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3622.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3622/head:pull/3622 PR: https://git.openjdk.java.net/jdk/pull/3622 From rriggs at openjdk.java.net Thu Apr 22 15:21:45 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Apr 2021 15:21:45 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Tue, 20 Apr 2021 22:35:00 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato 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: > > - Refined the test case. > - Merge branch 'master' into JDK-8264208 > - Changed shell based test into java based > - Added link to Charset#defaultChaset() in InputStreamReader. > - Modified javadocs per suggestions. > - Added @see links. > - Added Console::charset() relation with System.in > - Added comment to System.out/err init. > - Reflected further review comments. > - Reverted PrintStream changes > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/72f17eb7...e585d16f src/java.base/share/classes/java/io/Console.java line 597: > 595: return null; > 596: } > 597: }); Please keep the charset() method and return CHARSET. I'm looking at a use case that needs to know the platform charset regardless of whether the console exists. When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case a Reader from that stream should be able to use the encoding of the platform. Its still a work in progress, but it would save some refactoring or duplication later. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From xuelei at openjdk.java.net Thu Apr 22 15:37:25 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 22 Apr 2021 15:37:25 GMT Subject: RFR: 8228442: DHKeyExchange/LegacyDHEKeyExchange.java failed due to "SSLException: An established connection was aborted by the software in your host machine" In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 11:41:40 GMT, Fernando Guallini wrote: > Test DHKeyExchange/LegacyDHEKeyExchange.java has been seen to fail intermittently. There is a thread synchronisation issue that is fixed by: > > - Using SSLSocketTemplate that handles client/server socket configuration and synchronisation before connection > - Making use of a CountDownLatch and socket linger to facilitate the socket to close gracefully after both ends have finished the transmission It looks good to me. Thank you! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3622 From naoto at openjdk.java.net Thu Apr 22 15:45:32 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 22 Apr 2021 15:45:32 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Thu, 22 Apr 2021 15:18:11 GMT, Roger Riggs wrote: >> Naoto Sato 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: >> >> - Refined the test case. >> - Merge branch 'master' into JDK-8264208 >> - Changed shell based test into java based >> - Added link to Charset#defaultChaset() in InputStreamReader. >> - Modified javadocs per suggestions. >> - Added @see links. >> - Added Console::charset() relation with System.in >> - Added comment to System.out/err init. >> - Reflected further review comments. >> - Reverted PrintStream changes >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/51627555...e585d16f > > src/java.base/share/classes/java/io/Console.java line 597: > >> 595: return null; >> 596: } >> 597: }); > > Please keep the charset() method and return CHARSET. > > I'm looking at a use case that needs to know the platform charset regardless of whether the console exists. > When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case > a Reader from that stream should be able to use the encoding of the platform. > Its still a work in progress, but it would save some refactoring or duplication later. Would the singleton `Console.cons` be instantiated in your use case? It is created only when isatty() (or Windows' equivalent) in the native code returns true. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From rriggs at openjdk.java.net Thu Apr 22 16:06:23 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Apr 2021 16:06:23 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Thu, 22 Apr 2021 15:42:02 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 597: >> >>> 595: return null; >>> 596: } >>> 597: }); >> >> Please keep the charset() method and return CHARSET. >> >> I'm looking at a use case that needs to know the platform charset regardless of whether the console exists. >> When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case >> a Reader from that stream should be able to use the encoding of the platform. >> Its still a work in progress, but it would save some refactoring or duplication later. > > Would the singleton `Console.cons` be instantiated in your use case? It is created only when isatty() (or Windows' equivalent) in the native code returns true. Not always, for example, if stderr was redirected to a terminal but not stdin and stdout. The istty check is only true if both stdin and stdout are ttys. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Thu Apr 22 16:14:22 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 22 Apr 2021 16:14:22 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com> On Thu, 22 Apr 2021 16:03:12 GMT, Roger Riggs wrote: >> Would the singleton `Console.cons` be instantiated in your use case? It is created only when isatty() (or Windows' equivalent) in the native code returns true. > > Not always, for example, if stderr was redirected to a terminal but not stdin and stdout. > The istty check is only true if both stdin and stdout are ttys. Then `charset()` in the shared secret would return `null`. Would that suffice your case? ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From rriggs at openjdk.java.net Thu Apr 22 16:32:31 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Apr 2021 16:32:31 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com> Message-ID: On Thu, 22 Apr 2021 16:11:16 GMT, Naoto Sato wrote: >> Not always, for example, if stderr was redirected to a terminal but not stdin and stdout. >> The istty check is only true if both stdin and stdout are ttys. > > Then `charset()` in the shared secret would return `null`. Would that suffice your case? I read lines 575-587 as initializing CHARSET regardless of whether the Console was created. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From reinier at zwitserloot.com Thu Apr 22 17:27:30 2021 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 22 Apr 2021 19:27:30 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: > Alan Bateman wrote: > security features for XML processing can be controlled programmatically, it doesn't require a security manager to do that. Yes, it would be nice, and it is feasible, for XML parser libraries to gain API calls to tell them to never hit the disk or the network to resolve external entities. However, that principle (of "Let the library itself grow configurable options to restrict whatever you feel you want to restrict on a case by case basis") does not generalize. For example, I may want to restrict access to the 'logs' directory. I can't restrict it at the OS level (because the JVM does need to write the log files, of course), at best I can restrict it at the module / package / code line level, allowing the log framework write-only access, and deny it everywhere else. The problem at hand ("I want to treat my log dir as unreadable and unwriteable to my own process, except for logging code, which should be allowed to write") cannot be address with a 'configure the library' solution, unless the java (new) files API grows a whole bunch of methods to redefine such things, and/or to try to shove into a custom FileSystem implementation some code that does stack trace introspection to try to make this happen.... and that still doesn't address the `java.io.File` API. --Reinier Zwitserloot On Sat, 17 Apr 2021 at 16:54, Alan Bateman wrote: > On 16/04/2021 02:29, Reinier Zwitserloot wrote: > > : > > > > * An XML parser library may make network calls or open files on disk > > due to e.g. XXE shenanigans: See > > > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing > > < > https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing> > > > ? this isn't just plausible, we have plenty of proof that this has > > caused significant security breaches multiple times in XML's history. > > A SecurityManager that monitors (or outright denies) specifically the > > network and disk access from an XML parser library would have meant > > XXE attacks could never have happened. > > > The Security Developer's Guide has a good chapter on this topic [1] as > there many configuration knobs to restrict or disable "external access" > during XML processing. As things stand, running with a security manager > enables FEATURE_SECURE_PROCESSING globally but that is unfortunate > coupling and perhaps masks that the security features for XML processing > can be controlled programmatically, it doesn't require a security > manager to do that. > > -Alan > > [1] > > https://docs.oracle.com/en/java/javase/16/security/java-api-xml-processing-jaxp-security-guide.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.java.net Thu Apr 22 17:38:43 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 22 Apr 2021 17:38:43 GMT Subject: RFR: 8264208: Console charset API [v12] In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Revived charset() in JavaIOAccess interface. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/e585d16f..2d90f8df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=10-11 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Thu Apr 22 17:38:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 22 Apr 2021 17:38:46 GMT Subject: RFR: 8264208: Console charset API [v11] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> <3_4lsGTfiYoi0PIeeiMFl1dLF0kaHHHldCBXilpWn78=.8a39f16c-9d57-4354-a89a-2356e537d465@github.com> Message-ID: On Thu, 22 Apr 2021 16:29:35 GMT, Roger Riggs wrote: >> Then `charset()` in the shared secret would return `null`. Would that suffice your case? > > I read lines 575-587 as initializing CHARSET regardless of whether the Console was created. OK, revived the charset() method. ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From ron.pressler at oracle.com Thu Apr 22 17:39:49 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 22 Apr 2021 17:39:49 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: On 22 Apr 2021, at 18:27, Reinier Zwitserloot > wrote: For example, I may want to restrict access to the 'logs' directory. I can't restrict it at the OS level (because the JVM does need to write the log files, of course), at best I can restrict it at the module / package / code line level, allowing the log framework write-only access, and deny it everywhere else. The problem at hand ("I want to treat my log dir as unreadable and unwriteable to my own process, except for logging code, which should be allowed to write") cannot be address with a 'configure the library' solution, unless the java (new) files API grows a whole bunch of methods to redefine such things, and/or to try to shove into a custom FileSystem implementation some code that does stack trace introspection to try to make this happen.... and that still doesn't address the `java.io.File` API. --Reinier Zwitserloot The problem is that this is not doable with the Security Manager, either, except in theory. That the Security Manager can do this *in principle* (depending on correct use of doPrivileged) is not in dispute. But experience over they years has shown that people, *in practice* aren?t able to get Security Manager to do that correctly; all the SM does is get people to *think* they can do it (see http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf). Such an approach to security based on a highly-flexible sandbox is, empirically, not secure regardless of how much we?d like it to work; Security Manager was designed so elaborately, because back then, when the approach was new, people believed it could work. But having gained a couple of decades? worth of experience with software security and various approaches to it, we now that, perhaps disappointingly, it just doesn?t work. In fact, it is worse than just not working ? it?s insecure while giving a false sense of security. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Thu Apr 22 18:09:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 22 Apr 2021 18:09:55 GMT Subject: RFR: 8258915: Temporary buffer cleanup [v10] In-Reply-To: References: Message-ID: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. Weijun Wang 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 8258915 - Merge - simpler spec creation, and one more clean - materials - TLS key generators - drbg only in patch2: unchanged: - cleanups for key generations - keyfactory operations on own keyspec - more wrap, less copy - rsa - ... and 2 more: https://git.openjdk.java.net/jdk/compare/657f1039...f3b0f298 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2070/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2070&range=09 Stats: 2020 lines in 79 files changed: 986 ins; 508 del; 526 mod Patch: https://git.openjdk.java.net/jdk/pull/2070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2070/head:pull/2070 PR: https://git.openjdk.java.net/jdk/pull/2070 From weijun at openjdk.java.net Thu Apr 22 18:14:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 22 Apr 2021 18:14:34 GMT Subject: Integrated: 8258915: Temporary buffer cleanup In-Reply-To: References: Message-ID: <1B6Qww8WSfjCqCvSmf7UlMswm_MXQ6Z6ojm2fhUiLEg=.2a322128-3bfa-4d7d-b82f-2d3c8530c441@github.com> On Wed, 13 Jan 2021 21:32:07 GMT, Weijun Wang wrote: > Clean up temporary byte array, char array, and keyspec around keys and passwords. > > No new regression test. This pull request has now been integrated. Changeset: f834557a Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/f834557a Stats: 2020 lines in 79 files changed: 986 ins; 508 del; 526 mod 8258915: Temporary buffer cleanup Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/2070 From rriggs at openjdk.java.net Thu Apr 22 19:22:25 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Apr 2021 19:22:25 GMT Subject: RFR: 8264208: Console charset API [v12] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: <_D7PFttIHJzn2sKkV23A86PNGc2briMw9XxLyJ1AGuY=.551cc460-3b90-4979-bb6a-db228a12f884@github.com> On Thu, 22 Apr 2021 17:38:43 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Revived charset() in JavaIOAccess interface. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From valeriep at openjdk.java.net Thu Apr 22 23:51:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 22 Apr 2021 23:51:00 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v4] In-Reply-To: References: Message-ID: > Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added more tests for checking IV values and interop test w/ SunJCE provider. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3420/files - new: https://git.openjdk.java.net/jdk/pull/3420/files/2e3b7968..17131ecc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3420&range=02-03 Stats: 142 lines in 2 files changed: 119 ins; 7 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3420.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3420/head:pull/3420 PR: https://git.openjdk.java.net/jdk/pull/3420 From valeriep at openjdk.java.net Thu Apr 22 23:55:29 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 22 Apr 2021 23:55:29 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v3] In-Reply-To: References: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> Message-ID: On Thu, 15 Apr 2021 14:25:13 GMT, Jamil Nimeh wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed an tagLen issue, no key+iv reuse check for decryption, and add regression test for ChaCha20 SKF. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 225: > >> 223: } >> 224: apAlgo = "ChaCha20-Poly1305"; >> 225: spec = new IvParameterSpec(iv); > > Are there protections further up the call stack that guarantee that iv will be non-null when encrypt == false? I assume there are but I figured I'd ask since a null iv could cause NPE. Yes, there are checks in engineInit() to ensure that IV must be supplied when init with Cipher.DECRYPT_MODE. I added some more checks for getIV() and getParameters() to TestChaChaPoly.java just to be safe. Also, I added more null checks to this method to ensure that NPE won't happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From valeriep at openjdk.java.net Fri Apr 23 00:01:24 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 23 Apr 2021 00:01:24 GMT Subject: RFR: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider [v3] In-Reply-To: References: <0fF-A6k-KkOMIitRVTxCYoMElkBNXBsIszVfkUHpVsM=.038d0bbd-3b05-40e2-a669-9635417de6b1@github.com> Message-ID: On Thu, 15 Apr 2021 10:27:25 GMT, Sibabrata Sahoo wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed an tagLen issue, no key+iv reuse check for decryption, and add regression test for ChaCha20 SKF. > > test/jdk/sun/security/pkcs11/Cipher/TestChaChaPoly.java line 1: > >> 1: /* > > There is no compatibility Test exist between SunJCE and SunPKCS11 providers. Do we need one here. Theoretically, these new regression tests are mostly adapted from the ChaCha20-Poly1305 cipher tests of existing SunJCE provider. The test vectors are also the same, so the compatibility is tested indirectly. I have added a testInterop() method which uses one for encryption and the other for decryption and vice versa, just to be safe. If there are specific scenarios which I missed, please let me know and I will add it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From reinier at zwitserloot.com Fri Apr 23 13:41:27 2021 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 23 Apr 2021 15:41:27 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: > Ron Pressler wrote: > The problem is that this is not doable with the Security Manager, either, except in theory. Security is not that simple. Yes, there are ways to beat the security manager - it is not a black and white scenario where a SecurityManager is a complete guarantee against any and all vulnerabilities. But a SecurityManager can stop many vulnerabilities (just not all of them; virtually no security policies get to reasonably make such a claim, though!). The paper appears to be primarily about how you can work around SecurityManager based restrictions in code. In other words, it requires either untrusted code to run (when we're talking applets or the running of plugins supplied by untrusted third parties - but as has been covered in this thread, that's not part of the use case here), or for a separate vulnerability to exist that allows an attacker to run arbitrary bytecode, (or perhaps a dev team that is exploiting their own mitigations, but if we are to assume a sufficiently dysfunctional team, the line between malicious attacker and authorised committer is as good as gone and there is not much point talking about attack mitigation strategies in the first place). That's quite the big axiom! In the vast majority of attack scenarios, the attacker does not (yet) have the ability to run arbitrary bytecode. But they did gain the ability to e.g. coerce some part of a web server to return the file content of a path chosen by the attacker. In other words, that's not the attack surface that the use-case 'use the SM to restrict access to files' is designed to protect against. Instead, it's targeted at a combination of careless coders / strong reminding of policy rules amongst a dev team, and to fight a large class of attacks, such as coercing the server to return file contents. That class does _not_ include attacks where the attacker runs arbitrary bytecode, however. To fight against attacks and to enforce directives amongst the dev team, I can restrict the process itself using OS-level mechanisms as being incapable of seeing any directories, except the ones it actually has a legitimate need to read and/or write to. Unfortunately, the log dir is one of those 'legitimate' dirs, so I can't restrict that at the OS level. With a SecurityManager, I can still restrict it. I can elect to install a SecurityManager that blanket denies any and all attempts to read from the log dir, and denies all attempts to list or write to the log dir unless stack trace analysis shows it's coming from the log system. This SecurityManager based mitigation, as far as I am aware, even taking into account the 'Evaluating the Flexibility of the Java Sandbox' paper, fully stops: * Misunderstandings within the dev team; it lets the design of the app encode, more or less as a guarantee, that neither any dev on the team directly (by programming it) or indirectly (by including a dependency and configuring it in such a way) is ever going to independently write logs, or that any code running anywhere in the VM is going to read from the log files, at least via the route of 'someone on the team thought it was an acceptable solution to some problem they had to do that'. *1 * Misunderstandings between dev team and third party dep authors: If library that does end up reading a log dir (or perhaps more likely: A misunderstanding about how an end-user supplied string value ends up being conveyed to the library such that it lets the end user make the library read log files). * Any vulnerabilities that allow an attacker to coerce the server to return the contents of files on the file system from being used to let the attacker see log files (or any other file from a directory not explicitly allowed by the SM setup). It (probably) does not stop: * A vulnerability that lets an attacker run arbitrary bytecode on the VM. * Malicious libraries *1. * a vulnerability which lets a user inject arbitrary strings into the log file by making some exploitable code run e.g. `LOG.d(stringUnderFullHackerControl);`, but this is vastly less significant than an attacker that can read them, or if e.g. the log system itself has a webserver view component for admins to directly view the logs, from vulnerabilities in this frontend system. I don't think a security measure should be mostly disregarded just because it doesn't stop _every_ imaginable attack. The ones this stops are surely worthwhile to stop (I have made these mitigations part of my security setup in server deployments and part of my ISO27k1-esque certification documentation on how to ensure that the dev team follows the security directives). *1) The only ways this guarantee can be broken is if a library is intentionally working around it e.g. using techniques as set forth in that paper, which feels like it falls in the same category and has the same mitigations as any third party dependency that decides to include intentionally malicious code in there: Code review, CVE, and guardianship from repo owners such as sonatype's maven-central. In other words, that's a different class of attack and is not something that the SM, at least for this use-case, is meant to mitigate. --Reinier Zwitserloot On Thu, 22 Apr 2021 at 19:43, Ron Pressler wrote: > > > On 22 Apr 2021, at 18:27, Reinier Zwitserloot > wrote: > > For example, I may want to restrict access to the 'logs' directory. I > can't restrict it at the OS level (because the JVM does need to write the > log files, of course), at best I can restrict it at the module / package / > code line level, allowing the log framework write-only access, and deny it > everywhere else. > > The problem at hand ("I want to treat my log dir as unreadable and > unwriteable to my own process, except for logging code, which should be > allowed to write") cannot be address with a 'configure the library' > solution, unless the java (new) files API grows a whole bunch of methods to > redefine such things, and/or to try to shove into a custom FileSystem > implementation some code that does stack trace introspection to try to make > this happen.... and that still doesn't address the `java.io.File` API. > > --Reinier Zwitserloot > > > The problem is that this is not doable with the Security Manager, either, > except in theory. That the > Security Manager can do this *in principle* (depending on correct use of > doPrivileged) is not in dispute. > But experience over they years has shown that people, *in practice* aren?t > able to get Security Manager > to do that correctly; all the SM does is get people to *think* they can do > it > (see http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf). > > Such an approach to security based on a highly-flexible sandbox is, > empirically, not secure regardless of how > much we?d like it to work; Security Manager was designed so elaborately, > because back then, when the approach > was new, people believed it could work. But having gained a couple of > decades? worth of experience with > software security and various approaches to it, we now that, perhaps > disappointingly, it just doesn?t work. > In fact, it is worse than just not working ? it?s insecure while giving a > false sense of security. > > > ? Ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Apr 23 14:29:31 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 23 Apr 2021 14:29:31 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: Message-ID: <21F92262-2DA0-4996-A136-3C7C1F068D91@oracle.com> What you?re saying is: SM is good to help with trusted code ? i.e. not the threat that shaped its design. I?m saying, perhaps, but other techniques are better, namely, OS-level sandboxing and deep monitoring (based on JFR, which will need to be extended). Why? Because the SM is a far too elaborate, complex, and sensitive mechanism to defend against careless coders or difficult to spot vulnerabilities. Again, the question isn?t about what?s possible in theory, but about what code people can be expected to write in practice, and what we actually see, in the very rare cases SM is used at all, is policy files clearly written by ?let?s add permissions until the code runs.? Such policy files don?t really do what you intend them to do. Your log-dir scenario precisely highlights this. You say that you can do something that OS-level sandboxing won?t allow, and while the SM does support this use-case, practice shows that it is used incorrectly. To control access to the log directory, *on top of guarding all access to the log dir with doPrivileged*, if the application uses CompletableFuture, any ?reactive? framework, or thread pools of any kind, really, the application must also be carefully programmed with AccessController.getContext() and doPrivileged(access, context) that are used anywhere a task might move among threads. Without this, access wouldn't be controlled correctly. Now, remember that because the code is otherwise trusted, you want to protect against problems due to bugs, but to protect against them, you mustn?t have bugs in this complex context setup process. How many applications that you know actually do that? Put simply, are you describing something that you envision people doing or one that you know people actually regularly do? If it isn?t done ? and there?s good reason why it isn?t ? then it provides no security at all. Here?s how you need to do it: set up an OS-level sandbox that allows access to the log directory, and use JFR to monitor file activity. If you see activity with a suspicious stack trace, investigate it and fix the bug that?s caused the vulnerability. The belief that complex code you have to write will save you from bugs you have in other complex code *before they can manifest* is one that needs good evidence that is actually effective in practice, not just possible in theory. If you want to make a compelling case, show us what people *do*, not what you think they *could* do. We already know what the SM was designed to do and what it could do, but by now we?re largely convinced that it doesn?t actually do it. You are absolutely right to worry about the things you mention, and because they are so worrisome they should be handled by components that can actually get the job done better than the SM. ? Ron On 23 Apr 2021, at 14:41, Reinier Zwitserloot > wrote: > Ron Pressler wrote: > The problem is that this is not doable with the Security Manager, either, except in theory. Security is not that simple. Yes, there are ways to beat the security manager - it is not a black and white scenario where a SecurityManager is a complete guarantee against any and all vulnerabilities. But a SecurityManager can stop many vulnerabilities (just not all of them; virtually no security policies get to reasonably make such a claim, though!). The paper appears to be primarily about how you can work around SecurityManager based restrictions in code. In other words, it requires either untrusted code to run (when we're talking applets or the running of plugins supplied by untrusted third parties - but as has been covered in this thread, that's not part of the use case here), or for a separate vulnerability to exist that allows an attacker to run arbitrary bytecode, (or perhaps a dev team that is exploiting their own mitigations, but if we are to assume a sufficiently dysfunctional team, the line between malicious attacker and authorised committer is as good as gone and there is not much point talking about attack mitigation strategies in the first place). That's quite the big axiom! In the vast majority of attack scenarios, the attacker does not (yet) have the ability to run arbitrary bytecode. But they did gain the ability to e.g. coerce some part of a web server to return the file content of a path chosen by the attacker. In other words, that's not the attack surface that the use-case 'use the SM to restrict access to files' is designed to protect against. Instead, it's targeted at a combination of careless coders / strong reminding of policy rules amongst a dev team, and to fight a large class of attacks, such as coercing the server to return file contents. That class does _not_ include attacks where the attacker runs arbitrary bytecode, however. To fight against attacks and to enforce directives amongst the dev team, I can restrict the process itself using OS-level mechanisms as being incapable of seeing any directories, except the ones it actually has a legitimate need to read and/or write to. Unfortunately, the log dir is one of those 'legitimate' dirs, so I can't restrict that at the OS level. With a SecurityManager, I can still restrict it. I can elect to install a SecurityManager that blanket denies any and all attempts to read from the log dir, and denies all attempts to list or write to the log dir unless stack trace analysis shows it's coming from the log system. This SecurityManager based mitigation, as far as I am aware, even taking into account the 'Evaluating the Flexibility of the Java Sandbox' paper, fully stops: * Misunderstandings within the dev team; it lets the design of the app encode, more or less as a guarantee, that neither any dev on the team directly (by programming it) or indirectly (by including a dependency and configuring it in such a way) is ever going to independently write logs, or that any code running anywhere in the VM is going to read from the log files, at least via the route of 'someone on the team thought it was an acceptable solution to some problem they had to do that'. *1 * Misunderstandings between dev team and third party dep authors: If library that does end up reading a log dir (or perhaps more likely: A misunderstanding about how an end-user supplied string value ends up being conveyed to the library such that it lets the end user make the library read log files). * Any vulnerabilities that allow an attacker to coerce the server to return the contents of files on the file system from being used to let the attacker see log files (or any other file from a directory not explicitly allowed by the SM setup). It (probably) does not stop: * A vulnerability that lets an attacker run arbitrary bytecode on the VM. * Malicious libraries *1. * a vulnerability which lets a user inject arbitrary strings into the log file by making some exploitable code run e.g. `LOG.d(stringUnderFullHackerControl);`, but this is vastly less significant than an attacker that can read them, or if e.g. the log system itself has a webserver view component for admins to directly view the logs, from vulnerabilities in this frontend system. I don't think a security measure should be mostly disregarded just because it doesn't stop _every_ imaginable attack. The ones this stops are surely worthwhile to stop (I have made these mitigations part of my security setup in server deployments and part of my ISO27k1-esque certification documentation on how to ensure that the dev team follows the security directives). *1) The only ways this guarantee can be broken is if a library is intentionally working around it e.g. using techniques as set forth in that paper, which feels like it falls in the same category and has the same mitigations as any third party dependency that decides to include intentionally malicious code in there: Code review, CVE, and guardianship from repo owners such as sonatype's maven-central. In other words, that's a different class of attack and is not something that the SM, at least for this use-case, is meant to mitigate. --Reinier Zwitserloot On Thu, 22 Apr 2021 at 19:43, Ron Pressler > wrote: On 22 Apr 2021, at 18:27, Reinier Zwitserloot > wrote: For example, I may want to restrict access to the 'logs' directory. I can't restrict it at the OS level (because the JVM does need to write the log files, of course), at best I can restrict it at the module / package / code line level, allowing the log framework write-only access, and deny it everywhere else. The problem at hand ("I want to treat my log dir as unreadable and unwriteable to my own process, except for logging code, which should be allowed to write") cannot be address with a 'configure the library' solution, unless the java (new) files API grows a whole bunch of methods to redefine such things, and/or to try to shove into a custom FileSystem implementation some code that does stack trace introspection to try to make this happen.... and that still doesn't address the `java.io.File` API. --Reinier Zwitserloot The problem is that this is not doable with the Security Manager, either, except in theory. That the Security Manager can do this *in principle* (depending on correct use of doPrivileged) is not in dispute. But experience over they years has shown that people, *in practice* aren?t able to get Security Manager to do that correctly; all the SM does is get people to *think* they can do it (see http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf). Such an approach to security based on a highly-flexible sandbox is, empirically, not secure regardless of how much we?d like it to work; Security Manager was designed so elaborately, because back then, when the approach was new, people believed it could work. But having gained a couple of decades? worth of experience with software security and various approaches to it, we now that, perhaps disappointingly, it just doesn?t work. In fact, it is worse than just not working ? it?s insecure while giving a false sense of security. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.java.net Fri Apr 23 18:41:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 23 Apr 2021 18:41:27 GMT Subject: RFR: 8264208: Console charset API [v12] In-Reply-To: References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: On Thu, 22 Apr 2021 17:38:43 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Revived charset() in JavaIOAccess interface. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From naoto at openjdk.java.net Fri Apr 23 19:00:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 23 Apr 2021 19:00:42 GMT Subject: Integrated: 8264208: Console charset API In-Reply-To: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> References: <2nLTqCXeEQpbRIWQjncp-w7G_weyvv2BpTWijpUBj00=.4b2acdfb-901f-47f0-8ce4-ee6f121d48b6@github.com> Message-ID: <1iJ4QzneevQxxAkO5kDUwjmhzolU0rXBd3hrte6Vy0g=.e61cdd55-fa9b-4678-ae21-8fee0aae3b72@github.com> On Fri, 9 Apr 2021 16:47:55 GMT, Naoto Sato wrote: > Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. This pull request has now been integrated. Changeset: bebfae48 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/bebfae48 Stats: 214 lines in 10 files changed: 184 ins; 12 del; 18 mod 8264208: Console charset API Reviewed-by: joehw, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3419 From mbalao at openjdk.java.net Fri Apr 23 19:37:34 2021 From: mbalao at openjdk.java.net (Martin Balao) Date: Fri, 23 Apr 2021 19:37:34 GMT Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod Message-ID: Hi, Please find in this PR a proposal to fix JDK-8265462 [1]. With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior. No regressions observed in the jdk/sun/security/pkcs11 tests category. A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8265462 ------------- Commit messages: - 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod Changes: https://git.openjdk.java.net/jdk/pull/3661/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3661&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265462 Stats: 159 lines in 4 files changed: 127 ins; 3 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/3661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3661/head:pull/3661 PR: https://git.openjdk.java.net/jdk/pull/3661 From abakhtin at openjdk.java.net Fri Apr 23 20:58:36 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 23 Apr 2021 20:58:36 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: Hello All, Could you please review the fix for the JDK-8241248? The issue happens during the TLSv1.3 handshake without server stateless session resumption in case of server receives several parallel requests with the same pre_shared_key. The main idea of the fix is to remove resuming session from the session cache in the early stage. JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ The test from the bug report using OpenSSL is passed ( -Djdk.tls.server.enableSessionTicketExtension=false ) javax/net/ssl and sun/security/ssl jtreg tests passed Regards Alexey ------------- Commit messages: - 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Changes: https://git.openjdk.java.net/jdk/pull/3664/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241248 Stats: 24 lines in 2 files changed: 11 ins; 5 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3664.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3664/head:pull/3664 PR: https://git.openjdk.java.net/jdk/pull/3664 From dcubed at openjdk.java.net Sat Apr 24 14:41:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 24 Apr 2021 14:41:50 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 Message-ID: A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. ------------- Commit messages: - Change 'linux-generic' -> 'linux-all'. - 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3668/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3668&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265890 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3668.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3668/head:pull/3668 PR: https://git.openjdk.java.net/jdk/pull/3668 From rriggs at openjdk.java.net Sat Apr 24 15:59:27 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 24 Apr 2021 15:59:27 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From xuelei at openjdk.java.net Sat Apr 24 16:24:27 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 24 Apr 2021 16:24:27 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From dcubed at openjdk.java.net Sun Apr 25 02:57:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 25 Apr 2021 02:57:05 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 15:56:55 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java >> on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs and @XueleiFan - Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From dcubed at openjdk.java.net Sun Apr 25 02:57:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 25 Apr 2021 02:57:06 GMT Subject: Integrated: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. This pull request has now been integrated. Changeset: f6e22d14 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/f6e22d14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 Reviewed-by: rriggs, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From github.com+18174180+yassinhajaj at openjdk.java.net Sun Apr 25 09:48:38 2021 From: github.com+18174180+yassinhajaj at openjdk.java.net (YassinHajaj) Date: Sun, 25 Apr 2021 09:48:38 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> Message-ID: On Mon, 12 Apr 2021 16:12:17 GMT, Daniel Fuchs wrote: >> Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright headers >> - Tidied up lambdas > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 400: > >> 398: private static final String getProperty(final String propName, final String defVal) { >> 399: PrivilegedAction pa = () -> System.getProperty(propName, defVal); >> 400: return AccessController.doPrivileged(pa); > > Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library? @dfuch I noticed the same about the swallowed exception that returns the default value. This wouldn't cause any regression? ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From norman.maurer at googlemail.com Mon Apr 26 08:31:30 2021 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 26 Apr 2021 10:31:30 +0200 Subject: [External] : Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug) In-Reply-To: <5b5e2813-49e6-30b4-5307-e5d3f350045a@oracle.com> References: <231bbe52-fa50-0370-c3d9-6aebaa7863aa@oracle.com> <5b5e2813-49e6-30b4-5307-e5d3f350045a@oracle.com> Message-ID: <436DA2A7-B265-4A8C-9B00-0E436504BEAD@googlemail.com> Sorry for the noise but is there any update ? The bug makes it ?impossible? for us to enable caching by default as it may cause issues on the remote peer which are hard to debug. Bye Norman > On 19. Mar 2021, at 16:34, Jamil Nimeh wrote: > > Hi Norman, I've been working a couple other bugs, but I should have some time to devote to it next week. > > --Jamil > > On 3/19/2021 6:15 AM, Norman Maurer wrote: >> I was wondering if there is any update or anything I can help with ? >> >> Bye >> Norman >> >>> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh : >>> >>> ? >>> I already replied to Norman directly (because apparently I cannot seem to find my Reply-all button before my morning caffeine!). It does look quite a bit like 8241248 and that issue is in my bug queue. I haven't started work on it yet, but now that Norman has provided me some links to a reproducer I can give it a spin and see if I can make the bug happen locally (Thanks Norman!) >>> >>> --Jamil >>> >>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote: >>>> Forward to security-dev. >>>> >>>> Xuelei >>>> >>>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer > wrote: >>>>> >>>>> Hi there, >>>>> >>>>> I think I found a bug in the TLSv1.3 session cache implementation which sometimes can cause failures during session resumption. >>>>> The cause of this sometimes show up as NPE: >>>>> >>>>> javax.net.ssl.SSLException: Session has no PSK >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336) >>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) >>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283) >>>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537) >>>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528) >>>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583) >>>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222) >>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539) >>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) >>>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) >>>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) >>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) >>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) >>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) >>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) >>>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) >>>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>>> java.lang.NullPointerException >>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93) >>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119) >>>>> at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1169) >>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547) >>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) >>>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) >>>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) >>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) >>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) >>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) >>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) >>>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) >>>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>>> >>>>> >>>>> Other times the NPE is not included but it still fails with something like: >>>>> >>>>> Caused by: javax.net.ssl.SSLException: Session has no PSK >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336) >>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) >>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283) >>>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537) >>>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528) >>>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583) >>>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222) >>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539) >>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>> ... 17 common frames omitted >>>>> >>>>> Looking at the first stacktrace this seems to be related to: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8241248 >>>>> >>>>> >>>>> Unfortunately I don?t have a reproducer which uses the JDK only here but I can reproduce this with Netty that uses OpenSSL on the client side and the JDK SSLEngine on the server side. >>>>> I can reproduce this with the latest JDK11 release but can't with JDK15. Also what makes me believe it may be a concurrency bug is that only some handshakes fail. Like 70 out of 2600 fail. >>>>> >>>>> While the reproducer also involves netty I am wondering if you would still be interested in it ? It should be quite straight forward to run locally for you. >>>>> >>>>> The code that can reproduce it is here: >>>>> https://github.com/netty/netty/pull/10994#issuecomment-787976965 >>>>> >>>>> Also you will need to use this branch: >>>>> https://github.com/netty/netty/tree/ssl_cache_revamp >>>>> >>>>> >>>>> Please don?t hesitate if you have questions, >>>>> Norman >>>>> >>>>> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconcannon at openjdk.java.net Mon Apr 26 08:59:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Mon, 26 Apr 2021 08:59:44 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable Message-ID: Hi, Could someone please review my code for updating the code in the `java.security` package to make use of the `instanceof` pattern variable? Kind regards, Patrick ------------- Commit messages: - 8265426: Update java.security to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/3687/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265426 Stats: 161 lines in 23 files changed: 1 ins; 68 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/3687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3687/head:pull/3687 PR: https://git.openjdk.java.net/jdk/pull/3687 From alexey at azul.com Mon Apr 26 11:24:52 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 26 Apr 2021 11:24:52 +0000 Subject: [External] : Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug) In-Reply-To: <436DA2A7-B265-4A8C-9B00-0E436504BEAD@googlemail.com> References: <231bbe52-fa50-0370-c3d9-6aebaa7863aa@oracle.com> <5b5e2813-49e6-30b4-5307-e5d3f350045a@oracle.com> <436DA2A7-B265-4A8C-9B00-0E436504BEAD@googlemail.com> Message-ID: <95B8A5B8-213E-4B62-978E-D5408198CFB6@azul.com> Hi Jamil, Norman, I?ve missed this thread discussing JDK-8241248 issue. Recently I have suggested a fix for this issue : https://github.com/openjdk/jdk/pull/3664 Regards Alexey > On 26 Apr 2021, at 11:31, Norman Maurer wrote: > > Sorry for the noise but is there any update ? The bug makes it ?impossible? for us to enable caching by default as it may cause issues on the remote peer which are hard to debug. > > Bye > Norman > > >> On 19. Mar 2021, at 16:34, Jamil Nimeh wrote: >> >> Hi Norman, I've been working a couple other bugs, but I should have some time to devote to it next week. >> >> --Jamil >> >> On 3/19/2021 6:15 AM, Norman Maurer wrote: >>> I was wondering if there is any update or anything I can help with ? >>> >>> Bye >>> Norman >>> >>>> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh : >>>> >>>> ? >>>> I already replied to Norman directly (because apparently I cannot seem to find my Reply-all button before my morning caffeine!). It does look quite a bit like 8241248 and that issue is in my bug queue. I haven't started work on it yet, but now that Norman has provided me some links to a reproducer I can give it a spin and see if I can make the bug happen locally (Thanks Norman!) >>>> >>>> --Jamil >>>> >>>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote: >>>>> Forward to security-dev. >>>>> >>>>> Xuelei >>>>> >>>>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer wrote: >>>>>> >>>>>> Hi there, >>>>>> >>>>>> I think I found a bug in the TLSv1.3 session cache implementation which sometimes can cause failures during session resumption. >>>>>> The cause of this sometimes show up as NPE: >>>>>> >>>>>> javax.net.ssl.SSLException: Session has no PSK >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283) >>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537) >>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528) >>>>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583) >>>>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222) >>>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539) >>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) >>>>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) >>>>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) >>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) >>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) >>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) >>>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) >>>>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) >>>>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>>>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>>>> java.lang.NullPointerException >>>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93) >>>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119) >>>>>> at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1169) >>>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547) >>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) >>>>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) >>>>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) >>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) >>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) >>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) >>>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) >>>>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) >>>>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>>>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>>>> >>>>>> >>>>>> Other times the NPE is not included but it still fails with something like: >>>>>> >>>>>> Caused by: javax.net.ssl.SSLException: Session has no PSK >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283) >>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537) >>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528) >>>>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583) >>>>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222) >>>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539) >>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>>> ... 17 common frames omitted >>>>>> >>>>>> Looking at the first stacktrace this seems to be related to: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241248 >>>>>> >>>>>> >>>>>> Unfortunately I don?t have a reproducer which uses the JDK only here but I can reproduce this with Netty that uses OpenSSL on the client side and the JDK SSLEngine on the server side. >>>>>> I can reproduce this with the latest JDK11 release but can't with JDK15. Also what makes me believe it may be a concurrency bug is that only some handshakes fail. Like 70 out of 2600 fail. >>>>>> >>>>>> While the reproducer also involves netty I am wondering if you would still be interested in it ? It should be quite straight forward to run locally for you. >>>>>> >>>>>> The code that can reproduce it is here: >>>>>> https://github.com/netty/netty/pull/10994#issuecomment-787976965 >>>>>> >>>>>> Also you will need to use this branch: >>>>>> https://github.com/netty/netty/tree/ssl_cache_revamp >>>>>> >>>>>> >>>>>> Please don?t hesitate if you have questions, >>>>>> Norman >>>>>> >>>>>> >>>>>> >>>>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From dfuchs at openjdk.java.net Mon Apr 26 12:01:32 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 26 Apr 2021 12:01:32 GMT Subject: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2] In-Reply-To: References: <4MiIiut56keVl4VSp4RMZQVZlcE1d00udYL0F7yJi_o=.b5dc0f2a-64db-4ef0-9400-7e4def682ba5@github.com> Message-ID: On Sun, 25 Apr 2021 09:45:15 GMT, YassinHajaj wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 400: >> >>> 398: private static final String getProperty(final String propName, final String defVal) { >>> 399: PrivilegedAction pa = () -> System.getProperty(propName, defVal); >>> 400: return AccessController.doPrivileged(pa); >> >> Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library? > > @dfuch I noticed the same about the swallowed exception that returns the default value. This wouldn't cause any regression? As I noted - the SecurityException should never occur so I don't expect this could cause a regression. ------------- PR: https://git.openjdk.java.net/jdk/pull/3416 From github.com+439362+normanmaurer at openjdk.java.net Mon Apr 26 17:24:48 2021 From: github.com+439362+normanmaurer at openjdk.java.net (Norman Maurer) Date: Mon, 26 Apr 2021 17:24:48 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: Message-ID: <4tN0wW9G7R1tRSbQv2bfNvOnrkT5wOfr_LjF5b82Owc=.9f9ddb63-3f6d-41c2-873e-b747ff676b6d@github.com> On Fri, 23 Apr 2021 20:51:19 GMT, Alexey Bakhtin wrote: > Hello All, > > Could you please review the fix for the JDK-8241248? > The issue happens during the TLSv1.3 handshake without server stateless session resumption in case of server receives several parallel requests with the same pre_shared_key. > The main idea of the fix is to remove resuming session from the session cache in the early stage. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ > > The test from the bug report using OpenSSL is passed ( -Djdk.tls.server.enableSessionTicketExtension=false ) > javax/net/ssl and sun/security/ssl jtreg tests passed > > Regards > Alexey I can test this one with our netty testcase... Would also be good to have a testcase in openjdk tho ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From jamil.j.nimeh at oracle.com Mon Apr 26 15:56:45 2021 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 26 Apr 2021 08:56:45 -0700 Subject: [External] : Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug) In-Reply-To: <95B8A5B8-213E-4B62-978E-D5408198CFB6@azul.com> References: <231bbe52-fa50-0370-c3d9-6aebaa7863aa@oracle.com> <5b5e2813-49e6-30b4-5307-e5d3f350045a@oracle.com> <436DA2A7-B265-4A8C-9B00-0E436504BEAD@googlemail.com> <95B8A5B8-213E-4B62-978E-D5408198CFB6@azul.com> Message-ID: <373752b7-bfe9-9946-ba68-cadc8b580aaa@oracle.com> Hi Alexey, I'm in the process of reviewing it. --Jamil On 4/26/21 4:24 AM, Alexey Bakhtin wrote: > Hi Jamil, Norman, > > I?ve missed this thread discussing JDK-8241248 issue. > Recently I have suggested a fix for this issue : > https://github.com/openjdk/jdk/pull/3664 > > Regards > Alexey > >> On 26 Apr 2021, at 11:31, Norman Maurer wrote: >> >> Sorry for the noise but is there any update ? The bug makes it ?impossible? for us to enable caching by default as it may cause issues on the remote peer which are hard to debug. >> >> Bye >> Norman >> >> >>> On 19. Mar 2021, at 16:34, Jamil Nimeh wrote: >>> >>> Hi Norman, I've been working a couple other bugs, but I should have some time to devote to it next week. >>> >>> --Jamil >>> >>> On 3/19/2021 6:15 AM, Norman Maurer wrote: >>>> I was wondering if there is any update or anything I can help with ? >>>> >>>> Bye >>>> Norman >>>> >>>>> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh : >>>>> >>>>> ? >>>>> I already replied to Norman directly (because apparently I cannot seem to find my Reply-all button before my morning caffeine!). It does look quite a bit like 8241248 and that issue is in my bug queue. I haven't started work on it yet, but now that Norman has provided me some links to a reproducer I can give it a spin and see if I can make the bug happen locally (Thanks Norman!) >>>>> >>>>> --Jamil >>>>> >>>>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote: >>>>>> Forward to security-dev. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer wrote: >>>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> I think I found a bug in the TLSv1.3 session cache implementation which sometimes can cause failures during session resumption. >>>>>>> The cause of this sometimes show up as NPE: >>>>>>> >>>>>>> javax.net.ssl.SSLException: Session has no PSK >>>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >>>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336) >>>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) >>>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283) >>>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537) >>>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528) >>>>>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583) >>>>>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222) >>>>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539) >>>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) >>>>>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) >>>>>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) >>>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) >>>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) >>>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) >>>>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) >>>>>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) >>>>>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>>>>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>>>>> java.lang.NullPointerException >>>>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93) >>>>>>> at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119) >>>>>>> at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1169) >>>>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547) >>>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) >>>>>>> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) >>>>>>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) >>>>>>> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) >>>>>>> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) >>>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) >>>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) >>>>>>> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) >>>>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) >>>>>>> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) >>>>>>> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>>>>>> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>>>>> >>>>>>> >>>>>>> Other times the NPE is not included but it still fails with something like: >>>>>>> >>>>>>> Caused by: javax.net.ssl.SSLException: Session has no PSK >>>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >>>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336) >>>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) >>>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283) >>>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537) >>>>>>> at java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528) >>>>>>> at java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583) >>>>>>> at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222) >>>>>>> at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539) >>>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) >>>>>>> at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) >>>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) >>>>>>> at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) >>>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>>>> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) >>>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>>> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) >>>>>>> at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557) >>>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571) >>>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455) >>>>>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) >>>>>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) >>>>>>> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) >>>>>>> ... 17 common frames omitted >>>>>>> >>>>>>> Looking at the first stacktrace this seems to be related to: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8241248 >>>>>>> >>>>>>> >>>>>>> Unfortunately I don?t have a reproducer which uses the JDK only here but I can reproduce this with Netty that uses OpenSSL on the client side and the JDK SSLEngine on the server side. >>>>>>> I can reproduce this with the latest JDK11 release but can't with JDK15. Also what makes me believe it may be a concurrency bug is that only some handshakes fail. Like 70 out of 2600 fail. >>>>>>> >>>>>>> While the reproducer also involves netty I am wondering if you would still be interested in it ? It should be quite straight forward to run locally for you. >>>>>>> >>>>>>> The code that can reproduce it is here: >>>>>>> https://github.com/netty/netty/pull/10994#issuecomment-787976965 >>>>>>> >>>>>>> Also you will need to use this branch: >>>>>>> https://github.com/netty/netty/tree/ssl_cache_revamp >>>>>>> >>>>>>> >>>>>>> Please don?t hesitate if you have questions, >>>>>>> Norman >>>>>>> >>>>>>> >>>>>>> From jespersm at openjdk.java.net Mon Apr 26 17:54:36 2021 From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=) Date: Mon, 26 Apr 2021 17:54:36 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Changes look good, except for the unneeded parenthesis? (but I'm not a committer, so it's less useful) src/java.base/share/classes/java/security/Provider.java line 2003: > 2001: return true; > 2002: } > 2003: if (!(cap.supportsParameter)) { Why the extra parens? src/java.base/share/classes/java/security/Provider.java line 2012: > 2010: ("Parameter must be instanceof Key for engine " + type); > 2011: } > 2012: if (!(hasKeyAttributes())) { Also here: Why the parens? ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From mullan at openjdk.java.net Mon Apr 26 17:55:50 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Apr 2021 17:55:50 GMT Subject: RFR: 8196415: Disable SHA-1 Signed JARs Message-ID: <8c9r1NkTiBoZWf-QnTZKOa4Sh-wKHWT_DCR8Wmc6EYY=.959f2c12-35cd-4d94-9775-57cc0087d88a@github.com> This change will restrict JARs signed with SHA-1 algorithms and treat them as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. In order to reduce the compatibility risk for applications that have been previously timestamped or use private CAs, there are two exceptions to this policy: - Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted. - Any JAR signed with a SHA-1 certificate that does not chain back to a Root CA included by default in the JDK `cacerts` keystore will not be restricted. These exceptions may be removed in a future JDK release. All tests are in the closed repo for now. CSR: https://bugs.openjdk.java.net/browse/JDK-8264362 ------------- Commit messages: - 8196415: Disable SHA-1 Signed JARs - Merge - 8196415: Disable SHA-1 Signed JARs Changes: https://git.openjdk.java.net/jdk/pull/3700/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3700&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196415 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3700/head:pull/3700 PR: https://git.openjdk.java.net/jdk/pull/3700 From rriggs at openjdk.java.net Mon Apr 26 18:26:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 26 Apr 2021 18:26:44 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Marked as reviewed by rriggs (Reviewer). src/java.base/share/classes/java/security/CodeSource.java line 174: > 172: // certs must match > 173: return matchCerts(other, true); > 174: } Can this (160-173) be collapsed to: return (obj instanceof CodeSource cs) && Objects.equals(location, other.location) && matchCerts(cs, true) ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From weijun at openjdk.java.net Mon Apr 26 23:20:35 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 26 Apr 2021 23:20:35 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable In-Reply-To: References: Message-ID: <4czSt6SulFch62jX8GmRkFis9TiaYxu9JqSVutj9nYY=.900687bb-11ce-4d44-9202-249ff0231f60@github.com> On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Two comments: 1. Why not reuse the existing variable name (Ex: `t` in `Type t = (Type)obj`) as much as possible to avoid unnecessary renames? 2. I'm not sure if modifying argument name in a public API is a good idea. This leads to unnecessary javadoc changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From weijun at openjdk.java.net Mon Apr 26 23:27:36 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 26 Apr 2021 23:27:36 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Two comments: 1. Why not reuse the existing variable name (Ex: `t` in `Type t = (Type)obj`) as much as possible to avoid unnecessary renames? 2. I'm not sure if modifying argument name in a public API is a good idea. This leads to unnecessary javadoc changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From valeriep at openjdk.java.net Tue Apr 27 02:47:46 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 02:47:46 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation Message-ID: Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class. Thanks, Valerie ------------- Commit messages: - JDK-6676643: Improve current C_GetAttributeValue native implementation Changes: https://git.openjdk.java.net/jdk/pull/3709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6676643 Stats: 453 lines in 14 files changed: 86 ins; 228 del; 139 mod Patch: https://git.openjdk.java.net/jdk/pull/3709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3709/head:pull/3709 PR: https://git.openjdk.java.net/jdk/pull/3709 From github.com+829871+salusasecondus at openjdk.java.net Tue Apr 27 04:35:34 2021 From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin) Date: Tue, 27 Apr 2021 04:35:34 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 02:41:12 GMT, Valerie Peng wrote: > Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class. > > Thanks, > Valerie src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 252: > 250: > 251: if (rv != CKR_OK) { > 252: if (rv == CKR_ATTRIBUTE_SENSITIVE || rv == CKR_ATTRIBUTE_TYPE_INVALID) { According to the PKCS#11v2.40 spec, `CKR_BUFFER_TOO_SMALL` should be handled in the same special ways as these too (in that it isn't a "true error"). src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 253: > 251: if (rv != CKR_OK) { > 252: if (rv == CKR_ATTRIBUTE_SENSITIVE || rv == CKR_ATTRIBUTE_TYPE_INVALID) { > 253: msg = malloc(80); // should be more than sufficient I'm worried about asserting that 80 is sufficient especially as extremely large numbers of attributes could be retrieved and the limit check later on seems a bit lax. src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 262: > 260: temp1 = msg; > 261: temp2 = msg + 80; > 262: for (i = 0; i < ckAttributesLength && temp1 < temp2; i++) { I think that this loop will append at most 11 bytes to the string each time (is this correct?), if so, we can make the check `temp1 < temp2 - 12` to count the final null and avoid running off the end with a buffer overflow. src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c line 189: > 187: * returnValue is CKR_OK. Otherwise, it returns the returnValue as a jLong. > 188: * > 189: * @param env - used to call JNI funktions and to get the Exception class NitPick: here and above some German seems to have slipped in. I think we want "functions" ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From github.com+50504152+punikekk at openjdk.java.net Tue Apr 27 04:44:40 2021 From: github.com+50504152+punikekk at openjdk.java.net (Punikekk) Date: Tue, 27 Apr 2021 04:44:40 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick src/java.base/share/classes/java/security/Identity.java line 345: > 343: if (this.fullName().equals(other.fullName())) { > 344: return true; > 345: } else { Suggestion: src/java.base/share/classes/java/security/Identity.java line 349: > 347: } > 348: } > 349: return false; Suggestion: return obj instanceof Identity other && (this.fullName().equals(other.fullName()) || identityEquals(other)); ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From valeriep at openjdk.java.net Tue Apr 27 06:29:46 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 06:29:46 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider In-Reply-To: References: Message-ID: <1w9xPVJd-YJRKiX9Wv62eWqhXYblOGCfd0SoP12CkuY=.ccb834f5-5155-46ef-a081-fce85f6682eb@github.com> On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote: > Added capability to allow the PKCS11 Token to be destroyed once a session is logged out from. New configuration properties via pkcs11 config file. Cleaned up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng Here are some comments. Mostly just nit. Will continue looking at the test changes. Thanks~ Valerie src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java line 434: > 432: throw excLine(word + " must be at least 100 ms"); > 433: } > 434: } else if (word.endsWith("cleaner.shortInterval")) { Why use endsWith()? Most of other parsing code are enforcing equality, i.e. equals()? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/KeyCache.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved. 2021? Same goes for other files. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 176: > 174: found = true; > 175: next.dispose(); > 176: } nit: maybe this can be shortened a little with: SessionKeyRef next; while ((next = (SessionKeyRef) SessionKeyRef.refQueue.poll()) != null) { found = true; next.dispose(); } Same goes for the other drainRefQueue() impl. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java line 133: > 131: } > 132: > 133: static boolean drainRefQueue() { Add a comment on this being called by the cleaner thread with the two interval configuration options? Sames goes for the one in P11Key.java. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java line 152: > 150: implements Comparable { > 151: > 152: static ReferenceQueue refQueue = nit: can now move the value assignment onto the same line. Same goes for the refQueue in P11Key.java. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java line 246: > 244: private final AbstractQueue pool; > 245: private final int SESSION_MAX = 5; > 246: // access is synchronized on 'this' Maybe old comment? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 963: > 961: private long sleepMillis = config.getResourceCleanerShortInterval(); > 962: private int count = 0; > 963: boolean p11RefFound, SessRefFound; nit: p11RefFound => keyRefFound? nit: SessRefFound => sessRefFound? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 992: > 990: // increase the sleep time > 991: sleepMillis = config.getResourceCleanerLongInterval(); > 992: } This if-check can be moved up to below the line "count++;"? ------------- PR: https://git.openjdk.java.net/jdk/pull/3544 From ssahoo at openjdk.java.net Tue Apr 27 08:04:05 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Tue, 27 Apr 2021 08:04:05 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v7] In-Reply-To: References: Message-ID: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Updated condition for check key equality Updated condition for check key equality ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/cce15c0b..7e4033e1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=05-06 Stats: 15 lines in 1 file changed: 4 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Tue Apr 27 08:13:03 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Tue, 27 Apr 2021 08:13:03 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v8] In-Reply-To: References: Message-ID: <98qiWa4FUPYMjcSEtJ2AVnzcp-rWRXRlf73oCoG1SU8=.b30fd564-bea1-49b0-bd82-5e207dc59787@github.com> > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update CompareKeys.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/7e4033e1..b990d100 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From coffeys at openjdk.java.net Tue Apr 27 13:02:35 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 27 Apr 2021 13:02:35 GMT Subject: RFR: 8196415: Disable SHA-1 Signed JARs In-Reply-To: <8c9r1NkTiBoZWf-QnTZKOa4Sh-wKHWT_DCR8Wmc6EYY=.959f2c12-35cd-4d94-9775-57cc0087d88a@github.com> References: <8c9r1NkTiBoZWf-QnTZKOa4Sh-wKHWT_DCR8Wmc6EYY=.959f2c12-35cd-4d94-9775-57cc0087d88a@github.com> Message-ID: On Mon, 26 Apr 2021 17:29:26 GMT, Sean Mullan wrote: > This change will restrict JARs signed with SHA-1 algorithms and treat them as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. > > In order to reduce the compatibility risk for applications that have been previously timestamped or use private CAs, there are two exceptions to this policy: > > - Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted. > - Any JAR signed with a SHA-1 certificate that does not chain back to a Root CA included by default in the JDK `cacerts` keystore will not be restricted. > > These exceptions may be removed in a future JDK release. > > All tests are in the closed repo for now. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8264362 Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3700 From github.com+829871+salusasecondus at openjdk.java.net Tue Apr 27 15:15:36 2021 From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin) Date: Tue, 27 Apr 2021 15:15:36 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 04:28:26 GMT, Greg Rubin wrote: >> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 262: > >> 260: temp1 = msg; >> 261: temp2 = msg + 80; >> 262: for (i = 0; i < ckAttributesLength && temp1 < temp2; i++) { > > I think that this loop will append at most 11 bytes to the string each time (is this correct?), if so, we can make the check `temp1 < temp2 - 12` to count the final null and avoid running off the end with a buffer overflow. I apologize. This counting code is correct and doesn't have any of the issues I claimed. `snprintf` takes care of everything and I just missed it last night. ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From jnimeh at openjdk.java.net Tue Apr 27 16:04:36 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 27 Apr 2021 16:04:36 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 20:51:19 GMT, Alexey Bakhtin wrote: > Hello All, > > Could you please review the fix for the JDK-8241248? > The issue happens during the TLSv1.3 handshake without server stateless session resumption in case of server receives several parallel requests with the same pre_shared_key. > The main idea of the fix is to remove resuming session from the session cache in the early stage. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ > > The test from the bug report using OpenSSL is passed ( -Djdk.tls.server.enableSessionTicketExtension=false ) > javax/net/ssl and sun/security/ssl jtreg tests passed > > Regards > Alexey Marked as reviewed by jnimeh (Reviewer). I think this looks good. Thank you. Since you've done all the work on this one, it seems fitting that you'd become the owner of the issue in JBS. Also this might be a noreg-hard candidate since the failure is intermittent and requires putting load on a server in order to run into the issue, correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From xuelei at openjdk.java.net Tue Apr 27 16:16:36 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 27 Apr 2021 16:16:36 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 20:51:19 GMT, Alexey Bakhtin wrote: > Hello All, > > Could you please review the fix for the JDK-8241248? > The issue happens during the TLSv1.3 handshake without server stateless session resumption in case of server receives several parallel requests with the same pre_shared_key. > The main idea of the fix is to remove resuming session from the session cache in the early stage. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ > > The test from the bug report using OpenSSL is passed ( -Djdk.tls.server.enableSessionTicketExtension=false ) > javax/net/ssl and sun/security/ssl jtreg tests passed > > Regards > Alexey src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 377: > 375: // If we are keeping state, see if the identity is in the cache > 376: if (requestedId.identity.length == SessionId.MAX_LENGTH) { > 377: synchronized (sessionCache) { Did you have a test if there is a performance regression by introducing the synchronization here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From valeriep at openjdk.java.net Tue Apr 27 17:28:40 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 17:28:40 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v8] In-Reply-To: <98qiWa4FUPYMjcSEtJ2AVnzcp-rWRXRlf73oCoG1SU8=.b30fd564-bea1-49b0-bd82-5e207dc59787@github.com> References: <98qiWa4FUPYMjcSEtJ2AVnzcp-rWRXRlf73oCoG1SU8=.b30fd564-bea1-49b0-bd82-5e207dc59787@github.com> Message-ID: On Tue, 27 Apr 2021 08:13:03 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update CompareKeys.java Update looks good. test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 123: > 121: for (Provider.Service s : p.getServices()) { > 122: // Ignore the algorithms from the list which require > 123: // pre-initialisation to make the Test generic across algorithms. nit: typo? initialisation => initialization ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3490 From mcimadamore at openjdk.java.net Tue Apr 27 18:01:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 18:01:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) Message-ID: This PR contains the API and implementation changes for JEP-412 [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/412 ------------- Commit messages: - Add linker test excludes for x86 and other platforms which do not support `CLinker` - Integrate latest API tweaks - Fix x86 build - Fix `TestLinkToNativeRBP` - Initial push Changes: https://git.openjdk.java.net/jdk/pull/3699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264774 Stats: 14083 lines in 213 files changed: 8502 ins; 3605 del; 1976 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue Apr 27 18:01:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 18:01:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [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/412 Here we list the main changes introduced in this PR. As usual, a big thank to all who helped along the way: @ChrisHegarty, @iwanowww, @JornVernee, @PaulSandoz and @sundararajana. ### Managing memory segments: `ResourceScope` This PR introduces a new abstraction (first discussed [here](https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/)), namely `ResourceScope` which is used to manage the lifecycle of resources associated with off-heap memory (such as `MemorySegment`, `VaList`, etc). This is probably the biggest change in the API, as `MemorySegment` is no longer `AutoCloseable`: it instead features a *scope accessor* which can be used to access the memory segment's `ResourceScope`; the `ResourceScope` is the new `AutoCloseable`. In other words, code like this: try (MemorySegment segment = MemorySegment.allocateNative(100)) { ... } Now becomes like this: try (ResourceScope scope = ResourceScope.ofConfinedScope()) { MemorySegment segment = MemorySegment.allocateNative(100, scope); ... } While simple cases where only one segment is allocated become a little more verbose, this new API idiom obviously scales much better when multiple segments are created with the same lifecycle. Another important fact, which is captured by the name of the `ResourceScope` factory in the above snippet, is that segments no longer feature dynamic ownership changes. These were cool, but ultimately too expensive to support in the shared case. Instead, the API now requires clients to make a choice upfront (confined, shared or *implicit* - where the latter means GC-managed, like direct buffers). Implementation-wise, `ResourceScope` is implemented by a bunch of internal classes: `ResourceScopeImpl`, `ConfinedScope` and `SharedScope`. A resource scope impl has a so called *resource list* which can be also shared or confined. This is where cleanup actions are added; the resource list can be attached to a `Cleaner` to get implicit deallocation. There is a new test `TestResourceScope` to stress test the behavior of resource scopes, as well as a couple of microbenchmarks to assess the cost of creating/closing scopes (`ResourceScopeClose`) and acquiring/releasing them (`BulkMismatchAcquire`). ### IO operation on shared buffer views In the previous iteration of the Memory Access API we have introduced the concept of *shared* segments. Shared segments are as easy to use as confined ones, and they are as fast. One problem with shared segments was that it wasn't clear how to support IO operations on byte buffers derived from such segments: since the segment memory could be released at any time, there was simply no way to guarantee that a shared segment could not be closed in the middle of a (possibly async) IO operation. In this iteration, shared segments are just segments backed by a *shared resource scope*. The new API introduces way to manage the new complexity, in the form of two methods `ResourceScope::acquire` and `ResourceScope::release`, respectively, which can be used to *acquire* a resource scope. When a resource scope is in the acquired state, it cannot be closed (you can think of it as some slightly better and asymmetric form of an atomic reference counter). This means we are now finally in a position to add support for IO operations on all byte buffers, including those derived from shared segments. A big thank to @ChrisHegarty who lead the effort here. More info on this work are included in his [writeup](https://inside.java/2021/04/21/fma-and-nio-channels/). Most of the implementation for this feature occurs in the internal NIO packages; a new method on `Buffer` has been added to facilitate acquiring from NIO code - most of the logic associated with acquiring is in the `IOUtil` class. @ChrisHegarty has added many good tests for scoped IO operations under the `foreign/channels` folder, to check for all possible buffer/scope flavors. ### Allocating at speed: `SegmentAllocator` Another abstraction introduced in this JEP is that of `SegmentAllocator`. A segment allocator is a functional interface which can be used to tell other APIs (and, crucially, the `CLinker` API) how segments should be allocated, if the need arise. For instance, think about some code which turns a Java string into a C string. Such code will invariably: 1. allocate a memory segment off heap 2. bulk copy (where possible) the content of the Java string into the off-heap segment 3. add a NULL terminator So, in (1) such string conversion routine need to allocate a new off-heap segment; how is that done? Is that a call to malloc? Or something else? In the previous iteration of the Foreign Linker API, the method `CLinker::toCString` had two overloads: a simple version, only taking a Java string parameter; and a more advanced version taking a `NativeScope`. A `NativeScope` was, at its core, a custom segment allocator - but the allocation scheme was fixed in `NativeScope` as that class always acted as an arena-style allocator. `SegmentAllocator` is like `NativeScope` in spirit, in that it helps programs allocating segments - but it does so in a more general way than `NativeScope`, since a `SegmentAllocator` is not tied to any specific allocation strategy: in fact the strategy is left there to be defined by the user. As before, `SegmentAllocator` does provide some common factories, e.g. to create an arena allocator similar to `NativeScope` - but the `CLinker` API is now free to work with _any_ implementations of the `SegmentAllocator` interface. This generalization is crucial, given that, when operating with off-heap memory, allocation performance is often the bottleneck. Not only is `SegmentAllocator` accepted by all methods in the `CLinker` API which need to allocate memory: even the behavior of downcall method handle can now be affected by segment allocators: when linking a native function which returns a struct by value, the `CLinker` API will in fact need to dynamically allocate a segment to hold the result. In such cases, the method handle generated by `CLinker` will now accept an additional *prefix* parameter of type `SegmentAllocator` which tells `CLinker` *how* should memory be allocated for the result value. For instance, now clients can tell `CLinker` to return structs by value in *heap* segments, by using a `SegmentAllocator` which allocates memory on the heap; this might be useful if the segment is quickly discarded after use. There's not much implementation for `SegmentAllocator` as most of it is defined in terms of `default` methods in the interface itself. However we do have implementation classes for the arena allocation scheme (`ArenaAllocator.java`). We support confined allocation and shared allocation. The shared allocation achieves lock-free by using a `ThreadLocal` of confined arena allocators. `TestSegmentAllocators` is the test which checks most of the arena allocation flavors. ### `MemoryAddress` as scoped entities A natural consequence of introducing the `ResourceScope` abstraction is that now not only `MemorySegment` are associated with a scope, but even instances of `MemoryAddress` can be. This means extra safety, because passing addresses which are associated with a closed scope to a native function will issue an exception. As before, it is possible to have memory addresses which the runtime knows nothing about (those returned by native calls, or those created via `MemoryAddress::ofLong`); these addresses are simply associated with the so called *global scope* - meaning that they are not actively managed by the user and are considered to be "always alive" by the runtime (as before). Implementation-wise, you will now see that `MemoryAddressImpl` is no longer a pair of `Object`/`long`. It is now a pair of `MemorySegment`/`long`. The `MemorySegment`, if present, tells us which segment this address has been obtained from (and hence which scope is associated with the address). If null, if means that the address has no segment, and therefore is associated with the global scope. The `long` part acts as an offset into the segment (if segment is non-null), or as an absolute address. A new test `SafeFunctionAccessTest` attempts to call native functions with (closed) scoped addresses to see if exceptions are thrown. ### *Virtual* downcall method handles There are cases where the address of a downcall handle cannot be specified when a downcall method handle is linked, but can only be known subsequently, by doing more native calls. To better support these use cases, `CLinker` now provides a factory for downcall method handles which does *not* require any function entry point. Instead, such entry point will be provided *dynamically*, via an additional prefix parameter (of type `MemoryAddress`). Many thanks to @JornVernee who implemented this improvement. The implementation changes for this range from tweaking the Java ABI support (to make sure that the prefix argument is handled as expected), to low-level hotspot changes to parameterize the generated compiled stub to use the address (dynamic) parameter. Note that regular downcall method handles (the ones that are bound to an address) are now simply obtained by getting a "virtual" method handle, and inserting a `MemoryAddress` coordinate in the first argument position. `TestVirtualCalls` has been written explicitly to test dynamic passing of address parameters but, in reality, all existing downcall tests are stressing the new implementation logic (since, as said before, the old logic is expressed as an adaptation of the new virtual method handles). The benchmark we used to test downcall performances `CallOverhead` has now been split into two: `CallOverheadConstant` vs. `CallOverheadVirtual`. ### Optimized upcall support The previous iteration of the Foreign Linker API supported intrinsification of downcall handles, which allows calls to downcall method handles to perform as fast as a regular JNI call. The dual case, calling Java code from native code (upcalls) was left unoptimized. In this iteration, @JornVernee has added intrinsics support for upcalls as well as downcalls, based on some prior work from @iwanowww. As for downcalls, a lot of the adaptation now happens in Java code, before we jump into the target method handle. As for the code which calls such target handle, changes have been made so that the native code can jump to the optimized entry point (if one exists) for such method handle more directly. The performance improvements with this new approach are rather nice, with `CLinker` upcalls being 3x-4x faster compared with regular upcalls via JNI. Again, here we have changes in the guts of the Java ABI support, as we needed to adjust the method handle specialization logic to be able to work in two directions (both from Java to native and from native to Java). On the Hotspot front, the optimization changes are in `universalUpcallHandler_x86_64.cpp`. ### Accessing restricted methods It is still the case that some of the methods in the API are "restricted" and access to these methods is disabled by default. In previous iterations, access to such methods was granted by setting a JDK read-only runtime property: `-Dforeign.restricted=permit`. In this iteration we have refined the story for accessing restricted methods (thanks @sundararajana ), by introducing a new experimental command line option in the Java launcher, namely `--enable-native-access=`. This options accepts a list of modules (separated by commas), where a module name can also be `ALL-UNNAMED` (for the unnamed module). Adding this command line flag to the launcher has the effect of allowing access to restricted methods to a given set of modules (the list of modules specified in the command line option). Access to restricted methods from any other module not in the list is disallowed and will result in an `IllegalAccessException`. When implementing this flag we considered two options: adding some resolution-time checks in the JVM (e.g. in `linkResolver`); or use `@CallerSensitive` methods. In the end we opted for the latter given that `@CallerSensitive` are generally well understood and optimized, and the general feeling was that inventing another form of callsite-dependent check might have been unnecessarily risky, given that the same checks can be implemented in Java using `@CallerSensitive`. We plan (not in 17) to add `javadoc` support by means of an annotation (like we do for preview API methods) so that the text that is currently copied and pasted in all restricted methods can be inferred automagically by javadoc. ### GitHub testing status Most platforms build and tests pass. There are a bunch of *additional* Linux platforms which do not yet work correctly: * Zero * arm * ppc * s390 The first two can be addresses easily by stubbing out few functions (I'll do that shortly). The last two are harder, as this patch moves some static functions (e.g. `long_move`, `float_move`) up to `SharedRuntime`; unfortunately, while most platforms use the same signatures for these function, on ppc and s390 that's not the case and function with same name, but incompatible signatures are defined there, leading to build issues. We will try to tweak the code around this, to make sure that these platforms remain buildable. Javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v1/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v1/specdiff/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From valeriep at openjdk.java.net Tue Apr 27 18:39:35 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 18:39:35 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: <33h9xgGUasgPFdxvgsnm4TpLQhIT4y0k77FOtctW_mM=.24808d1e-587c-4806-a4c9-849c23592519@github.com> On Tue, 27 Apr 2021 04:31:42 GMT, Greg Rubin wrote: >> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 252: > >> 250: >> 251: if (rv != CKR_OK) { >> 252: if (rv == CKR_ATTRIBUTE_SENSITIVE || rv == CKR_ATTRIBUTE_TYPE_INVALID) { > > According to the PKCS#11v2.40 spec, `CKR_BUFFER_TOO_SMALL` should be handled in the same special ways as these too (in that it isn't a "true error"). For this particular call, the pValue field is null, it's meant to query the exact length of the specified attribute. Thus, CKR_BUFFER_TOO_SMALL should not be returned. Afterwards, we then allocate the buffer based on this queried result, so CKR_BUFFER_TOO_SMALL should also not occur. So, based on the current API usage, CKR_BUFFER_TOO_SMALL should not happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From alanb at openjdk.java.net Tue Apr 27 18:51:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 27 Apr 2021 18:51:38 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [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/412 src/java.base/share/classes/java/lang/Module.java line 253: > 251: } > 252: > 253: boolean isEnableNativeAccess() { Would it be possible change isEnableNativeAccess and addNEnableNativeAccess to keep them consistent with the existing methods in this file. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 384: > 382: Module addEnableNativeAccess(Module m); > 383: > 384: boolean isEnableNativeAccess(Module m); Probably better to co-locate these with the other module methods, and add a comment so that it's consistent with the existing methods. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 272: > 270: BootLoader.loadModule(base); > 271: SharedSecrets.getJavaLangAccess() > 272: .addEnableNativeAccess(Modules.defineModule(null, base.descriptor(), baseUri)); This would be cleaner if you replace it with: Module baseModule = Modules.defineModule(null, base.descriptor(), baseUri); JLA.addEnableNativeAccess(baseModule); You can use JLA in addEnableNativeAccess too, no need for "jla". src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 876: > 874: } > 875: > 876: private static void addEnableNativeAccess(ModuleLayer layer) { It would be useful to add a method description in the same style as the existing methods, just to keep these methods consistent. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 57: > 55: > 56: static int write(FileDescriptor fd, ByteBuffer src, long position, > 57: boolean async, NativeDispatcher nd) UnixAsynchronousSocketChannel is an outlier user of IOUtil and I think we need to see if we can avoid extending this class to async if possible. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: > 464: } > 465: > 466: private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From github.com+829871+salusasecondus at openjdk.java.net Tue Apr 27 18:52:36 2021 From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin) Date: Tue, 27 Apr 2021 18:52:36 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: <33h9xgGUasgPFdxvgsnm4TpLQhIT4y0k77FOtctW_mM=.24808d1e-587c-4806-a4c9-849c23592519@github.com> References: <33h9xgGUasgPFdxvgsnm4TpLQhIT4y0k77FOtctW_mM=.24808d1e-587c-4806-a4c9-849c23592519@github.com> Message-ID: On Tue, 27 Apr 2021 18:36:28 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 252: >> >>> 250: >>> 251: if (rv != CKR_OK) { >>> 252: if (rv == CKR_ATTRIBUTE_SENSITIVE || rv == CKR_ATTRIBUTE_TYPE_INVALID) { >> >> According to the PKCS#11v2.40 spec, `CKR_BUFFER_TOO_SMALL` should be handled in the same special ways as these too (in that it isn't a "true error"). > > For this particular call, the pValue field is null, it's meant to query the exact length of the specified attribute. Thus, CKR_BUFFER_TOO_SMALL should not be returned. > Afterwards, we then allocate the buffer based on this queried result, so CKR_BUFFER_TOO_SMALL should also not occur. > So, based on the current API usage, CKR_BUFFER_TOO_SMALL should not happen. All my concerns are addressed then. So, while my review doesn't count towards acceptance of this change, everything LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From valeriep at openjdk.java.net Tue Apr 27 18:52:38 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 18:52:38 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 04:27:10 GMT, Greg Rubin wrote: >> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 253: > >> 251: if (rv != CKR_OK) { >> 252: if (rv == CKR_ATTRIBUTE_SENSITIVE || rv == CKR_ATTRIBUTE_TYPE_INVALID) { >> 253: msg = malloc(80); // should be more than sufficient > > I'm worried about asserting that 80 is sufficient especially as extremely large numbers of attributes could be retrieved and the limit check later on seems a bit lax. 80 should be sufficient, as we only include attribute type of those UNAVAILABLE ones. For example, there may be 6 attributes specified, but realistically only one or two being unavailable. Are you aware of any case which a large number of attributes are unavailable? I added the limit check to ensure no out-of-bound writes. In the worst case, the reported types may be incomplete, i.e. up to 80 bytes. Otherwise, we may need two passes, one to find out the number of unavailable attributes, and one to allocate and set the content. Or, do you have other suggestion? > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c line 189: > >> 187: * returnValue is CKR_OK. Otherwise, it returns the returnValue as a jLong. >> 188: * >> 189: * @param env - used to call JNI funktions and to get the Exception class > > NitPick: here and above some German seems to have slipped in. I think we want "functions" I didn't notice the German, just copy-n-paste. Will fix the typos. ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From valeriep at openjdk.java.net Tue Apr 27 18:52:39 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 18:52:39 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: <-fumiG4C41lqCtyt1Uk6l73wwVfvE-oUIAwqpdzTBVQ=.a24f8f50-4bb8-4e56-8977-0756976c7855@github.com> On Tue, 27 Apr 2021 15:13:10 GMT, Greg Rubin wrote: >> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 262: >> >>> 260: temp1 = msg; >>> 261: temp2 = msg + 80; >>> 262: for (i = 0; i < ckAttributesLength && temp1 < temp2; i++) { >> >> I think that this loop will append at most 11 bytes to the string each time (is this correct?), if so, we can make the check `temp1 < temp2 - 12` to count the final null and avoid running off the end with a buffer overflow. > > I apologize. This counting code is correct and doesn't have any of the issues I claimed. `snprintf` takes care of everything and I just missed it last night. It's alright, thanks for checking and review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From valeriep at openjdk.java.net Tue Apr 27 19:19:40 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 27 Apr 2021 19:19:40 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: <1iSPYdHXlpICvfFjYcWzGNFHECOjHkiZXfOj8ciAlVs=.2de78c69-9633-4a96-b0e7-a01191b52c38@github.com> On Tue, 27 Apr 2021 18:49:30 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c line 189: >> >>> 187: * returnValue is CKR_OK. Otherwise, it returns the returnValue as a jLong. >>> 188: * >>> 189: * @param env - used to call JNI funktions and to get the Exception class >> >> NitPick: here and above some German seems to have slipped in. I think we want "functions" > > I didn't notice the German, just copy-n-paste. Will fix the typos. Other PKCS#11 JNI sources have the same German typos, I prefer to leave them out of this. Will fix them when they are touched in other fixes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From github.com+829871+salusasecondus at openjdk.java.net Tue Apr 27 19:37:22 2021 From: github.com+829871+salusasecondus at openjdk.java.net (Greg Rubin) Date: Tue, 27 Apr 2021 19:37:22 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 02:41:12 GMT, Valerie Peng wrote: > Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class. > > Thanks, > Valerie Marked as reviewed by SalusaSecondus at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From mcimadamore at openjdk.java.net Tue Apr 27 20:23:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 20:23:10 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> References: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> Message-ID: On Tue, 27 Apr 2021 18:46:02 GMT, Alan Bateman wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > src/java.base/share/classes/java/lang/Module.java line 253: > >> 251: } >> 252: >> 253: boolean isEnableNativeAccess() { > > Would it be possible change isEnableNativeAccess and addNEnableNativeAccess to keep them consistent with the existing methods in this file. Change as in "adding javadoc" ? Or is the naming of the method something that's bothering? > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 384: > >> 382: Module addEnableNativeAccess(Module m); >> 383: >> 384: boolean isEnableNativeAccess(Module m); > > Probably better to co-locate these with the other module methods, and add a comment so that it's consistent with the existing methods. sure I'll fix this > src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 272: > >> 270: BootLoader.loadModule(base); >> 271: SharedSecrets.getJavaLangAccess() >> 272: .addEnableNativeAccess(Modules.defineModule(null, base.descriptor(), baseUri)); > > This would be cleaner if you replace it with: > > Module baseModule = Modules.defineModule(null, base.descriptor(), baseUri); > JLA.addEnableNativeAccess(baseModule); > > You can use JLA in addEnableNativeAccess too, no need for "jla". ok > src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 876: > >> 874: } >> 875: >> 876: private static void addEnableNativeAccess(ModuleLayer layer) { > > It would be useful to add a method description in the same style as the existing methods, just to keep these methods consistent. I'll fix ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From abakhtin at openjdk.java.net Tue Apr 27 23:48:52 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 27 Apr 2021 23:48:52 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: Message-ID: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> On Tue, 27 Apr 2021 16:13:31 GMT, Xue-Lei Andrew Fan wrote: >> Hello All, >> >> Could you please review the fix for the JDK-8241248? >> The issue happens during the TLSv1.3 handshake without server stateless session resumption in case of server receives several parallel requests with the same pre_shared_key. >> The main idea of the fix is to remove resuming session from the session cache in the early stage. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ >> >> The test from the bug report using OpenSSL is passed ( -Djdk.tls.server.enableSessionTicketExtension=false ) >> javax/net/ssl and sun/security/ssl jtreg tests passed >> >> Regards >> Alexey > > src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 377: > >> 375: // If we are keeping state, see if the identity is in the cache >> 376: if (requestedId.identity.length == SessionId.MAX_LENGTH) { >> 377: synchronized (sessionCache) { > > Did you have a test if there is a performance regression by introducing the synchronization here? > > I have to check the engineGetServerSessionContext() specification and implementation (if the sessionCache is a reference?), and the session cache implementation to make sure the synchronization works (if the synchronization on sessionCache is the same as the synchronization on the cache internal implementation) . Maybe, the improvement could in the cache implementation for readability? Yes, I?ve made a test that calculates total time spent by server to receive connections. Every server handshake is performed in a separate thread The client starts threads. Every thread sends one initial connection and renegotiated connections. So, the total number of connections is =* Results for the original and JDK-8241248 code are almost identical: =10 =100 Original OpenJDK: 1140 ms JDK-8241248 code: 1090 ms =50 =100 Original OpenJDK: 1164 ms JDK-8241248 code: 1108 ms =60 =100 Original OpenJDK: 1461 ms JDK-8241248 code: 1579 ms =70 =100 Original OpenJDK: 2058 ms JDK-8241248 code: 1999 ms =80 =100 Original OpenJDK: 2148 ms JDK-8241248 code: 2125 ms =90 =100 Original OpenJDK: 2540 ms JDK-8241248 code: 2514 ms =90 =100 Original OpenJDK: 3011 ms JDK-8241248 code: 3010 ms I can confirm that the synchronization code works. Without it I still catches exception from different threads trying to resume the same session from the cache ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From wetmore at openjdk.java.net Wed Apr 28 00:07:03 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 28 Apr 2021 00:07:03 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:13:54 GMT, Xue-Lei Andrew Fan wrote: >> As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. >> >> It is caused by a mismatching condition in the SSLEngineOutputRecord. The use hasAlert() method should be replaced with isEmpty(). Otherwise, there is conflicts of the closing status while checking with OutputRecord.isEmpty() in TransportContext.getHandshakeStatus() implementation. It is safe to remove hasAlert() method, as we don't allow creation of new output record if the closure is in progress, thus isEmpty() could be used instead. >> >> The patch passed the test provided by the bug submitter. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge > - improved fix > - 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output SSLEngineOutputRecord.java: Missing copyright date update. SSLEngineOutputRecord:77 Unnecessary extra line added. Please remove. src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1694: > 1692: if (cause instanceof SocketException) { > 1693: try { > 1694: throw conContext.fatal(alert, cause); Why did you change to a throw here? Isn't everything from fatal() going to be thrown anyway? src/java.base/share/classes/sun/security/ssl/TransportContext.java line 587: > 585: } > 586: > 587: // Note: HandshakeStatus.FINISHED status is retrieved in other places. I now see that v1 of this change had quite a few changes here, and what's left is now just compacting a line and making some old comment corrections. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3292 From xuelei at openjdk.java.net Wed Apr 28 00:16:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 28 Apr 2021 00:16:57 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 23:48:23 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge >> - improved fix >> - 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1694: > >> 1692: if (cause instanceof SocketException) { >> 1693: try { >> 1694: throw conContext.fatal(alert, cause); > > Why did you change to a throw here? Isn't everything from fatal() going to be thrown anyway? The fatal() will always throw an exception. We could use the method without throw. In some places, IDE or compiler could complain because it cannot detect that the fatal() method will throw and the program ends here. In the past, we use fatal() method without throw, later we change the fatal() return value form "void" to an exception so that throw could be used to mitigate the IDE or compiler complaints. It is not really necessary to make this code change here. I just want to make the coding style consistent for the fatal() calling. > src/java.base/share/classes/sun/security/ssl/TransportContext.java line 587: > >> 585: } >> 586: >> 587: // Note: HandshakeStatus.FINISHED status is retrieved in other places. > > I now see that v1 of this change had quite a few changes here, and what's left is now just compacting a line and making some old comment corrections. Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From psandoz at openjdk.java.net Wed Apr 28 00:17:54 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 28 Apr 2021 00:17:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [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/412 The Java changes are mostly familiar to me, having reviewed many PRs in the Panama repository, hence the lack of specific comments here. I did a pass through the changes and nothing major stood out to me. The new API changes make it much easy to build APIs around memory segments, exposing and reusing resource scope, acquiring/releasing on resource scope, where necessary. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3699 From xuelei at openjdk.java.net Wed Apr 28 00:19:53 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 28 Apr 2021 00:19:53 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 00:03:31 GMT, Bradford Wetmore wrote: > SSLEngineOutputRecord.java: > Missing copyright date update. > Yes, I missed the copyright date. > SSLEngineOutputRecord:77 > Unnecessary extra line added. Please remove. Oops, I will correct it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From xuelei at openjdk.java.net Wed Apr 28 00:26:15 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 28 Apr 2021 00:26:15 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output [v3] In-Reply-To: References: Message-ID: > As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. > > It is caused by a mismatching condition in the SSLEngineOutputRecord. The use hasAlert() method should be replaced with isEmpty(). Otherwise, there is conflicts of the closing status while checking with OutputRecord.isEmpty() in TransportContext.getHandshakeStatus() implementation. It is safe to remove hasAlert() method, as we don't allow creation of new output record if the closure is in progress, thus isEmpty() could be used instead. > > The patch passed the test provided by the bug submitter. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update copyright date and typo correction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3292/files - new: https://git.openjdk.java.net/jdk/pull/3292/files/989e9ad3..03a0dc60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3292&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3292&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3292/head:pull/3292 PR: https://git.openjdk.java.net/jdk/pull/3292 From xuelei at openjdk.java.net Wed Apr 28 03:24:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 28 Apr 2021 03:24:57 GMT Subject: Integrated: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 20:52:57 GMT, Xue-Lei Andrew Fan wrote: > As described in the bug, by connecting the SSLEngine with a misbehaving peer SSL implementation, it can get into a state where it calling `wrap` reports getStatus == OK, getHandshakeStatus === NEED_WRAP but still doesn't produce any further output. It happens when the output bound is not empty. > > It is caused by a mismatching condition in the SSLEngineOutputRecord. The use hasAlert() method should be replaced with isEmpty(). Otherwise, there is conflicts of the closing status while checking with OutputRecord.isEmpty() in TransportContext.getHandshakeStatus() implementation. It is safe to remove hasAlert() method, as we don't allow creation of new output record if the closure is in progress, thus isEmpty() could be used instead. > > The patch passed the test provided by the bug submitter. This pull request has now been integrated. Changeset: 1a37bce5 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/1a37bce5afc55ad13d1406a989dbf58992746204 Stats: 54 lines in 4 files changed: 10 ins; 14 del; 30 mod 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From ssahoo at openjdk.java.net Wed Apr 28 06:56:21 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 28 Apr 2021 06:56:21 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v9] In-Reply-To: References: Message-ID: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Typo error in comment section updated Typo error in comment section updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3490/files - new: https://git.openjdk.java.net/jdk/pull/3490/files/b990d100..09fe0dc5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3490&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3490/head:pull/3490 PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Wed Apr 28 06:56:22 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 28 Apr 2021 06:56:22 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v6] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 00:16:59 GMT, Valerie Peng wrote: >> Sibabrata Sahoo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update CompareKeys.java >> - Update CompareKeys.java > > test/jdk/javax/crypto/KeyGenerator/CompareKeys.java line 85: > >> 83: || origKey.hashCode() == copyKey.hashCode()) >> 84: && !Arrays.equals(origKey.getEncoded(), copyKey.getEncoded()) >> 85: && !origKey.getFormat().equals(copyKey.getFormat())) { > > So, all of these 3 checks have to fail in order to be considered key inequality? Could you spell out clearly what is expected here? I am not sure if this compound condition is correct. As it is now, the copy must have different format(2nd condition) AND different encoding(3rd condition) AND (not equals AND not same hash code)(1st condition), in order to trigger the RuntimeException. I have updated the condition to check for equality, hashCode, Format, Encoded bytes of original key against another copy of same. As the keys are same and the copy of key is a replica of original key, i am expecting all condition to match in same time. If there is any condition check fails then it will be treated as a mismatch. Please correct me if i am wrong here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From chegar at openjdk.java.net Wed Apr 28 08:22:52 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 08:22:52 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> References: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> Message-ID: On Tue, 27 Apr 2021 18:40:24 GMT, Alan Bateman wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: > >> 464: } >> 465: >> 466: private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); > > It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil. I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code. Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome. Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From chegar at openjdk.java.net Wed Apr 28 09:14:53 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 09:14:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [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/412 src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 135: > 133: } finally { > 134: segment.scope().release(segmentHandle); > 135: } I do like the symmetry in this example, but just to add an alternative idiom: `segmentHandle.scope().release(segmentHandle)` , which guarantees to avoid release throwing and IAE src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 186: > 184: *

  • this resource scope is confined, and this method is called from a thread other than the thread owning this resource scope
  • > 185: *
  • this resource scope is shared and a resource associated with this scope is accessed while this method is called
  • > 186: *
  • one or more handles (see {@link #acquire()}) associated with this resource scope have not been closed
  • Minor spec suggestion: "... associated with this resource scope have not been *released*" src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205: > 203: * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}. > 204: * @return a resource scope handle. > 205: */ Given recent changes, it might be good to generalise the opening sentence here. Maybe : " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... " Or some such. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From ssahoo at openjdk.java.net Wed Apr 28 09:52:54 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 28 Apr 2021 09:52:54 GMT Subject: RFR: 8185127: Add tests to cover hashCode() method for java supported crypto key types [v9] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 06:56:21 GMT, Sibabrata Sahoo wrote: >> This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Typo error in comment section updated > > Typo error in comment section updated Pushing the change after addressing minor typo issue in the review comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From ssahoo at openjdk.java.net Wed Apr 28 09:52:57 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 28 Apr 2021 09:52:57 GMT Subject: Integrated: 8185127: Add tests to cover hashCode() method for java supported crypto key types In-Reply-To: References: Message-ID: <6qV_KyNfX_ATkMr8G6SU8D8GH4AmUFwWw6fufwjyO5g=.312b08a0-eb60-4b39-867e-24bbda3902f6@github.com> On Wed, 14 Apr 2021 13:38:06 GMT, Sibabrata Sahoo wrote: > This is a simple Test to add few additional API coverage for all java supported key types. The objective of this Test is to cover equals() and hashcode() methods for each key types. This pull request has now been integrated. Changeset: 343a4a76 Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/343a4a76f273078f78897e8fb7e695bc2c111536 Stats: 149 lines in 1 file changed: 149 ins; 0 del; 0 mod 8185127: Add tests to cover hashCode() method for java supported crypto key types Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/3490 From lim.chainz11+mailing at gmail.com Wed Apr 28 10:18:06 2021 From: lim.chainz11+mailing at gmail.com (Lim) Date: Wed, 28 Apr 2021 18:18:06 +0800 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund wrote: > If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. > If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above. From lim.chainz11+mailing at gmail.com Wed Apr 28 10:19:11 2021 From: lim.chainz11+mailing at gmail.com (Lim) Date: Wed, 28 Apr 2021 18:19:11 +0800 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: On Wed, Apr 21, 2021 at 8:38 PM Ron Pressler wrote: > Its current events might be not have everything you want, but will be expanded, in > part to address the functionality that will be lost with the removal of Security Manager. I agree that monitoring needs to be improved since there is a lack of monitoring APIs except for JFR. Until those monitoring APIs are on par with the usage of SM "monitoring", it makes no sense to remove without providing alternatives. > Libraries that can disable the Security Manager aren?t able to circumvent OS-level > sandboxing. If you?re not afraid of that, then they?re trusted and JFR is superior; > if they?re untrusted, then configuring the Security Manager correctly for untrusted rich > libraries is very difficult. Since you said that it cannot circumvent OS-level sandboxing, what will prevent those libraries to monitor if there is JFR active and become dormant until there is no JFR present, then it will execute the malicious behavior; Or, the library attempts to hide or render the JFR useless so that it will not be recorded and noticed? On Wed, Apr 21, 2021 at 8:55 PM Ron Pressler wrote: > For rich libraries and applications, your best bet is an OS-level sandbox. The Security Manager > might give you a false sense of security. Yes, OS-level sandbox is good but can it be scalable for many types of end users that have different OS and hardware environments? In addition, how many end users out there have used sandbox to isolate their desktop applications except if the program has built-in sandbox such as web browsers? Programs such as Docker does not count. From mcimadamore at openjdk.java.net Wed Apr 28 10:20:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 10:20:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205: > >> 203: * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}. >> 204: * @return a resource scope handle. >> 205: */ > > Given recent changes, it might be good to generalise the opening sentence here. Maybe : > " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... " Or some such. I'm afraid I don't get this comment ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From markus.gronlund at oracle.com Wed Apr 28 10:38:37 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 28 Apr 2021 10:38:37 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-dev at openjdk.java.net Thanks Markus -----Original Message----- From: Lim Sent: den 28 april 2021 12:18 To: Markus Gronlund Cc: Ron Pressler ; security-dev at openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund wrote: > If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. > If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above. From mcimadamore at openjdk.java.net Wed Apr 28 10:42:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 10:42:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:10:37 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 135: > >> 133: } finally { >> 134: segment.scope().release(segmentHandle); >> 135: } > > I do like the symmetry in this example, but just to add an alternative idiom: > `segmentHandle.scope().release(segmentHandle)` > , which guarantees to avoid release throwing and IAE I see what you mean - I don't think I want to encourage that style too much by giving it prominence in the javadoc. It's true you can go back to the scope from the handle, so that you are guaranteed to release the right thing, but I think that should be unnecessary in most idiomatic uses. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 10:42:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 10:42:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [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/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address first batch of review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/7545f71f..a80d8180 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00-01 Stats: 42 lines in 4 files changed: 25 ins; 11 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From chegar at openjdk.java.net Wed Apr 28 10:42:56 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 10:42:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205: > >> 203: * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}. >> 204: * @return a resource scope handle. >> 205: */ > > Given recent changes, it might be good to generalise the opening sentence here. Maybe : > " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... " Or some such. The spec for the acquire method talks only of explicit resource scopes. The comment is suggesting that the spec could be generalised a little, since it is possible to acquire a resource scope handle associated with implicit scopes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From chris.hegarty at oracle.com Wed Apr 28 10:51:02 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Apr 2021 10:51:02 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: On 28 Apr 2021, at 11:38, Markus Gronlund > wrote: Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-dev at openjdk.java.net Thanks Markus. That is the appropriate list to send JFR feedback. Just to add, I filed an Enhancement Request in JIRA, 8265962: "Evaluate adding Networking JFR events? [1], to track the possibility of adding JFR events to the JDK libraries that perform low-level networking activity (which is mostly in the purview of the networking and libraries area). If we had such, then it would be possible to monitor *all* low-level network activity performed by the platform, regardless of which higher-level library is performing the activity. Clearly such would not capture URLs, but rather the network activity that would be triggered by, say, an HTTP Client library. This seems like a more fruitful and uniform approach, rather than trying to add JFR events to, say, every HTTP library. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8265962 Thanks Markus -----Original Message----- From: Lim > Sent: den 28 april 2021 12:18 To: Markus Gronlund > Cc: Ron Pressler >; security-dev at openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund > wrote: If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Wed Apr 28 11:04:25 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 28 Apr 2021 11:04:25 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Thanks Chris, I like that approach very much. Thanks again Markus From: Chris Hegarty Sent: den 28 april 2021 12:51 To: Markus Gronlund Cc: Lim ; Ron Pressler ; security-dev at openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries On 28 Apr 2021, at 11:38, Markus Gronlund > wrote: Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-dev at openjdk.java.net Thanks Markus. That is the appropriate list to send JFR feedback. Just to add, I filed an Enhancement Request in JIRA, 8265962: "Evaluate adding Networking JFR events? [1], to track the possibility of adding JFR events to the JDK libraries that perform low-level networking activity (which is mostly in the purview of the networking and libraries area). If we had such, then it would be possible to monitor *all* low-level network activity performed by the platform, regardless of which higher-level library is performing the activity. Clearly such would not capture URLs, but rather the network activity that would be triggered by, say, an HTTP Client library. This seems like a more fruitful and uniform approach, rather than trying to add JFR events to, say, every HTTP library. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8265962 Thanks Markus -----Original Message----- From: Lim > Sent: den 28 april 2021 12:18 To: Markus Gronlund > Cc: Ron Pressler >; security-dev at openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund > wrote: If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coffeys at openjdk.java.net Wed Apr 28 12:39:42 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 28 Apr 2021 12:39:42 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore [v2] In-Reply-To: References: Message-ID: > Trivial enough change. Improved the exception thrown from JceKeyStore also. Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Check for null before try block - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8236671-NPE - Fix white space - 8236671: NullPointerException in JKS keystore ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3588/files - new: https://git.openjdk.java.net/jdk/pull/3588/files/836ea7e7..54baaad7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3588&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3588&range=00-01 Stats: 42439 lines in 1504 files changed: 9588 ins; 28041 del; 4810 mod Patch: https://git.openjdk.java.net/jdk/pull/3588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3588/head:pull/3588 PR: https://git.openjdk.java.net/jdk/pull/3588 From chegar at openjdk.java.net Wed Apr 28 13:12:55 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 13:12:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments Like Paul, I tracked the changes to this API in the Panama repo. Most of my remaining comments are small and come from re-reading the API docs. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270: > 268: > 269: /** > 270: * Converts a Java string into a null-terminated C string, using the platform's default charset, Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited. For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 101: > 99: *

    Lifecycle and confinement

    > 100: * > 101: * Memory segments are associated to a resource scope (see {@link ResourceScope}), which can be accessed using Typo?? "Memory segments are associated *with* a resource scope" src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 112: > 110: MemoryAccess.getLong(segment); // already closed! > 111: * } > 112: * Additionally, access to a memory segment in subject to the thread-confinement checks enforced by the owning scope; that is, Typo?? "Additionally, access to a memory segment *is* subject to ..." src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 114: > 112: * Additionally, access to a memory segment in subject to the thread-confinement checks enforced by the owning scope; that is, > 113: * if the segment is associated with a shared scope, it can be accessed by multiple threads; if it is associated with a confined > 114: * scope, it can only be accessed by the thread which own the scope. Typo?? "it can only be accessed by the thread which ownS the scope." src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 693: > 691: */ > 692: static MemorySegment allocateNative(MemoryLayout layout, ResourceScope scope) { > 693: Objects.requireNonNull(scope); Should the allocateNative methods declare that they throw ISE, if the given ResourceScope is not alive? ( I found myself asking this q, then considering the behaviour of a SegmentAllocator that is asked to allocate after a RS has been closed ) ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 13:45:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 13:45:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 13:08:26 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 693: > >> 691: */ >> 692: static MemorySegment allocateNative(MemoryLayout layout, ResourceScope scope) { >> 693: Objects.requireNonNull(scope); > > Should the allocateNative methods declare that they throw ISE, if the given ResourceScope is not alive? ( I found myself asking this q, then considering the behaviour of a SegmentAllocator that is asked to allocate after a RS has been closed ) Good point, yes it should ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 13:50:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 13:50:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 12:47:36 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270: > >> 268: >> 269: /** >> 270: * Converts a Java string into a null-terminated C string, using the platform's default charset, > > Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited. For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one. I believe here the goal is to be consistent with `String::getBytes`: /** * Encodes this {@code String} into a sequence of bytes using the * platform's default charset, storing the result into a new byte array. * *

    The behavior of this method when this string cannot be encoded in * the default charset is unspecified. The {@link * java.nio.charset.CharsetEncoder} class should be used when more control * over the encoding process is required. * * @return The resultant byte array * * @since 1.1 */ public byte[] getBytes() { return encode(Charset.defaultCharset(), coder(), value); } So, you are right in that there's an element of platform-dependency here - but I think it's a dependency that users learned to "ignore" mostly. If developers want to be precise, and platform independent, they can always use the Charset-accepting method. Of course this could be revisited, but I think there is some consistency in what the API is trying to do. If, in the future, defaultCharset will just be Utf8 - well, that's ok too - as long as the method is specified to be "defaultCharset" dependent, what's behind "defaultCharset" is an implementation detail that the user will have to be aware of one way or another. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From sean.mullan at oracle.com Wed Apr 28 14:58:09 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 28 Apr 2021 10:58:09 -0400 Subject: JEP 411: methods in j.u.c.Executors In-Reply-To: <6936-607efc00-35b-51ef3d80@213965831> References: <6936-607efc00-35b-51ef3d80@213965831> Message-ID: On 4/20/21 12:06 PM, Anthony Vanelverdinghe wrote: > The JEP should also address the following methods in java.util.concurrent.Executors: privilegedCallable, privilegedCallableUsingCurrentClassLoader?, privilegedThreadFactory > Since AccessController et al. will be terminally deprecated, I'd assume these methods should be as well. Yes. I will add them to the Deprecated APIs section of the JEP. --Sean > > Kind regards, > Anthony > > On Thursday, April 15, 2021 20:05 CEST, mark.reinhold at oracle.com wrote: > >> https://openjdk.java.net/jeps/411 >> >> Summary: Deprecate the Security Manager for removal in a future >> release. The Security Manager dates from Java 1.0. It has not been the >> primary means of securing client-side Java code for many years, and it >> has rarely been used to secure server-side code. To move Java forward, >> we intend to deprecate the Security Manager for removal in concert with >> the legacy Applet API (JEP 398). >> >> - Mark > From weijun at openjdk.java.net Wed Apr 28 15:14:01 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 28 Apr 2021 15:14:01 GMT Subject: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified Message-ID: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. ------------- Commit messages: - 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified Changes: https://git.openjdk.java.net/jdk/pull/3764/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3764&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266220 Stats: 35 lines in 2 files changed: 27 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3764/head:pull/3764 PR: https://git.openjdk.java.net/jdk/pull/3764 From fguallini at openjdk.java.net Wed Apr 28 15:43:54 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 28 Apr 2021 15:43:54 GMT Subject: Integrated: 8228442: DHKeyExchange/LegacyDHEKeyExchange.java failed due to "SSLException: An established connection was aborted by the software in your host machine" In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 11:41:40 GMT, Fernando Guallini wrote: > Test DHKeyExchange/LegacyDHEKeyExchange.java has been seen to fail intermittently. There is a thread synchronisation issue that is fixed by: > > - Using SSLSocketTemplate that handles client/server socket configuration and synchronisation before connection > - Making use of a CountDownLatch and socket linger to facilitate the socket to close gracefully after both ends have finished the transmission This pull request has now been integrated. Changeset: 7e3bc4cb Author: Fernando Guallini Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/7e3bc4cb444c7b7f3cd3e514b4ad7d7137799401 Stats: 287 lines in 1 file changed: 14 ins; 252 del; 21 mod 8228442: DHKeyExchange/LegacyDHEKeyExchange.java failed due to "SSLException: An established connection was aborted by the software in your host machine" Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3622 From alanb at openjdk.java.net Wed Apr 28 16:17:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 28 Apr 2021 16:17:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: <0P9z_Fj6-ogctJUqlsZRC3JfOXGCbx0YLNh8me9grio=.0d53fd2d-d6b0-4c69-9da1-4781a1194405@github.com> On Wed, 28 Apr 2021 13:47:43 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270: >> >>> 268: >>> 269: /** >>> 270: * Converts a Java string into a null-terminated C string, using the platform's default charset, >> >> Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited. For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one. > > I believe here the goal is to be consistent with `String::getBytes`: > > > /** > * Encodes this {@code String} into a sequence of bytes using the > * platform's default charset, storing the result into a new byte array. > * > *

    The behavior of this method when this string cannot be encoded in > * the default charset is unspecified. The {@link > * java.nio.charset.CharsetEncoder} class should be used when more control > * over the encoding process is required. > * > * @return The resultant byte array > * > * @since 1.1 > */ > public byte[] getBytes() { > return encode(Charset.defaultCharset(), coder(), value); > } > > > So, you are right in that there's an element of platform-dependency here - but I think it's a dependency that users learned to "ignore" mostly. If developers want to be precise, and platform independent, they can always use the Charset-accepting method. Of course this could be revisited, but I think there is some consistency in what the API is trying to do. If, in the future, defaultCharset will just be Utf8 - well, that's ok too - as long as the method is specified to be "defaultCharset" dependent, what's behind "defaultCharset" is an implementation detail that the user will have to be aware of one way or another. Naoto is working on a couple of changes in advance of JEP 400. One of these is to expose a system property with the host charset and I suspect that the CLinker method will want to use that instead of Charset.defaultCharset. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mullan at openjdk.java.net Wed Apr 28 17:16:51 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 28 Apr 2021 17:16:51 GMT Subject: Integrated: 8196415: Disable SHA-1 Signed JARs In-Reply-To: <8c9r1NkTiBoZWf-QnTZKOa4Sh-wKHWT_DCR8Wmc6EYY=.959f2c12-35cd-4d94-9775-57cc0087d88a@github.com> References: <8c9r1NkTiBoZWf-QnTZKOa4Sh-wKHWT_DCR8Wmc6EYY=.959f2c12-35cd-4d94-9775-57cc0087d88a@github.com> Message-ID: On Mon, 26 Apr 2021 17:29:26 GMT, Sean Mullan wrote: > This change will restrict JARs signed with SHA-1 algorithms and treat them as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. > > In order to reduce the compatibility risk for applications that have been previously timestamped or use private CAs, there are two exceptions to this policy: > > - Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted. > - Any JAR signed with a SHA-1 certificate that does not chain back to a Root CA included by default in the JDK `cacerts` keystore will not be restricted. > > These exceptions may be removed in a future JDK release. > > All tests are in the closed repo for now. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8264362 This pull request has now been integrated. Changeset: 27805775 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/278057756a1a79a4b030750c48b821ba9735a0f9 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8196415: Disable SHA-1 Signed JARs Reviewed-by: coffeys ------------- PR: https://git.openjdk.java.net/jdk/pull/3700 From dfuchs at openjdk.java.net Wed Apr 28 17:28:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 17:28:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: <689o3jJsku_BVrUSQATPla7V0BfqOYZuzlJXtmy347E=.6871722d-66a7-4364-8e19-3eecb6df2e3a@github.com> On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 224: > 222: * Some methods in this package are considered restricted. Restricted methods are typically used to bind native > 223: * foreign data and/or functions to first-class Java API elements which can then be used directly by client. For instance > 224: * the restricted method {@link jdk.incubator.foreign.MemoryAddress#asSegment(long, ResourceScope)} can be used to create typo: `used directly by client.` => `used directly by clients.` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 18:04:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 18:04:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments I reviewed the `--enable-native-access` related change that looks fine. > Access to restricted methods from any other module not in the list is disallowed and will result in an IllegalAccessException. I think you meant to say `IllegalCallerException` instead of `IllegalAccessException`. Also do you intend to have javadoc to generate `@throw IllegalCallerException` for the restricted methods automatically besides the javadoc description? Making the restricted methods as `@CallerSensitive` in order to get the caller class for native access check is the proper approach. However, some interface methods are restricted methods such as `CLinker::downcallHandle` whose the implementation method is `@CallerSensitive`. I concern with the security issue with method handle and type aliasing. On the other hand, `CLinker` is a sealed interface and only implemented by the platform and so it's less of a concern. I think the interface method should also be `@CallerSensitive` so that for example a method handle for `CLinker::downcallHandle` will be produced with the proper caller-sensitive context. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Wed Apr 28 18:10:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 18:10:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 40: > 38: > 39: private IllegalNativeAccessChecker(Set allowedModuleNames, boolean allowAllUnnamedModules) { > 40: this.allowedModuleNames = Collections.unmodifiableSet(allowedModuleNames); Should that be Set.copyOf() to take advantage of the immutability of `SetN` (but at the expense of additional copying)... src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78: > 76: int index = 0; > 77: // the system property is removed after decoding > 78: String value = getAndRemoveProperty(prefix + index); I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:17:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:17:59 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:02:03 GMT, Mandy Chung wrote: > I reviewed the `--enable-native-access` related change that looks fine. > > > Access to restricted methods from any other module not in the list is disallowed and will result in an IllegalAccessException. > > I think you meant to say `IllegalCallerException` instead of `IllegalAccessException`. Also do you intend to have javadoc to generate `@throw IllegalCallerException` for the restricted methods automatically besides the javadoc description? > IllegalCalller is probably better yes - we started off with an access-like check, so things have evolved a bit. I'll also add the @throws. > Making the restricted methods as `@CallerSensitive` in order to get the caller class for native access check is the proper approach. However, some interface methods are restricted methods such as `CLinker::downcallHandle` whose the implementation method is `@CallerSensitive`. I concern with the security issue with method handle and type aliasing. On the other hand, `CLinker` is a sealed interface and only implemented by the platform and so it's less of a concern. I think the interface method should also be `@CallerSensitive` so that for example a method handle for `CLinker::downcallHandle` will be produced with the proper caller-sensitive context. I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @CS was not put on "virtual" methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:21:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:21:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: On Wed, 28 Apr 2021 18:07:32 GMT, Daniel Fuchs wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78: > >> 76: int index = 0; >> 77: // the system property is removed after decoding >> 78: String value = getAndRemoveProperty(prefix + index); > > I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker. I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 18:34:23 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 18:34:23 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments > I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @cs was not put on "virtual" methods. Good if we do have such test. We need to re-examine this with the security team. I suggest to create a JBS issue and follow up separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:33:36 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:33:36 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [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/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments: * fix typos in javadoc * document ISE being thrown in all methods accepting a scope; add more tests for that ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/a80d8180..24e554c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=01-02 Stats: 112 lines in 6 files changed: 50 ins; 0 del; 62 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:35:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:35:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: <9u5yskXth55699_itCsdggIyKauvUauftz9zy0svpLI=.744431e1-4a6d-4fe2-a664-09b35e53eaf7@github.com> On Wed, 28 Apr 2021 17:53:44 GMT, Daniel Fuchs wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 40: > >> 38: >> 39: private IllegalNativeAccessChecker(Set allowedModuleNames, boolean allowAllUnnamedModules) { >> 40: this.allowedModuleNames = Collections.unmodifiableSet(allowedModuleNames); > > Should that be Set.copyOf() to take advantage of the immutability of `SetN` (but at the expense of additional copying)... Honestly, I'm not even sure why we should be concerned about mutation of the set here - since we create this with a bunch of values read from a system property... e.g. should we just store `allowedModuleNames` period? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:34:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:34:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:23:41 GMT, Mandy Chung wrote: > > I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @cs was not put on "virtual" methods. > > Good if we do have such test. We need to re-examine this with the security team. I suggest to create a JBS issue and follow up separately. The test in question is: test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 18:38:28 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 18:38:28 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:26:30 GMT, Maurizio Cimadamore wrote: > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java Yes that's the test. That test misses to catch your case where aliasing may be possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Wed Apr 28 18:47:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 18:47:08 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: On Wed, 28 Apr 2021 18:19:14 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78: >> >>> 76: int index = 0; >>> 77: // the system property is removed after decoding >>> 78: String value = getAndRemoveProperty(prefix + index); >> >> I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker. > > I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread. I'll take your word for it - the use of a volatile variable to store the singleton instance made this suspicious. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Wed Apr 28 19:09:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 19:09:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 52: > 50: *

    > 51: * For {@link #lookup(String) memory addresses} obtained from a library lookup object, > 52: * since {@link CLinker#downcallHandle(Addressable, MethodType, FunctionDescriptor) native method handles} These should be `{@linkplain }` since the text of the link is plain text (and not code) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 88: > 86: * @return the memory segment associated with the library symbol (if any). > 87: * @throws IllegalArgumentException if the address associated with the lookup symbol do not match the > 88: * {@link MemoryLayout#byteAlignment() alignment constraints} in {@code layout}. Same remark here (`{@linkplain }`) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 43: > 41: * when performing memory dereference operations using a memory access var handle (see {@link MemoryHandles}). > 42: *

    > 43: * A memory address is associated with a {@link ResourceScope resource scope}; the resource scope determines the `{@linkplain }` src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 46: > 44: * lifecycle of the memory address, and whether the address can be used from multiple threads. Memory addresses > 45: * obtained from {@link #ofLong(long) numeric values}, or from native code, are associated with the > 46: * {@link ResourceScope#globalScope() global resource scope}. Memory addresses obtained from segments ... and here to (`{@linkplain }`) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 102: > 100: * @param segment the segment relative to which this address offset should be computed > 101: * @throws IllegalArgumentException if {@code segment} is not compatible with this address; this can happen, for instance, > 102: * when {@code segment} models an heap memory region, while this address is a {@link #isNative() native} address. `{@linkplain }` src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 209: > 207: /** > 208: * The native memory address instance modelling the {@code NULL} address, associated > 209: * with the {@link ResourceScope#globalScope() global} resource scope. `{@linkplain }` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From abakhtin at openjdk.java.net Wed Apr 28 20:35:53 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Wed, 28 Apr 2021 20:35:53 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 16:00:33 GMT, Jamil Nimeh wrote: > I think this looks good. Thank you. > Since you've done all the work on this one, it seems fitting that you'd become the owner of the issue in JBS. Also this might be a noreg-hard candidate since the failure is intermittent and requires putting load on a server in order to run into the issue, correct? @jnimeh , Thank you for review. I've assigned it to myself and added "noreg-hard" label as you suggested. The issue is intermittent and I don't know how to reproduce it without third-party libs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From mcimadamore at openjdk.java.net Wed Apr 28 20:38:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 20:38:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 19:02:57 GMT, Daniel Fuchs wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 209: > >> 207: /** >> 208: * The native memory address instance modelling the {@code NULL} address, associated >> 209: * with the {@link ResourceScope#globalScope() global} resource scope. > > `{@linkplain }` ? thanks - I'll do a pass - I think I probably got all of them wrong ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 20:43:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 20:43:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:33:36 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > * fix typos in javadoc > * document ISE being thrown in all methods accepting a scope; add more tests for that > > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java > > Yes that's the test. That test misses to catch your case where aliasing may be possible. > Yes that's the test. That test misses to catch your case where aliasing may be possible. To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 20:43:54 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 20:43:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:38:47 GMT, Maurizio Cimadamore wrote: > To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? Yes. The caller would be java.base if it's invoked via method handle. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 21:13:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 21:13:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:40:49 GMT, Mandy Chung wrote: > > To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? > > Yes. The caller would be java.base if it's invoked via method handle. I just did a test: public class TestLookup { public static void main(String[] args) throws Throwable { MethodHandle handle = MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", MethodType.methodType(MethodHandle.class, Addressable.class, MethodType.class, FunctionDescriptor.class)); CLinker linker = CLinker.getInstance(); handle.invoke(linker, MemoryAddress.NULL, MethodType.methodType(void.class), FunctionDescriptor.ofVoid()); } } this fails as expected when the handle is invoked. To test I had to disable the check on CLinker.getInstance - otherwise that would have always throw anyway. Also, on IllegalCaller vs. IllegalAccess - looking more, I think our impl throws IllegalCaller - now that was done because IllegalAccess is a checked exception and we don't want a checked exception here - but the option is called "enableNativeAccess" - is that still ok? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 21:49:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 21:49:50 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: On Wed, 28 Apr 2021 18:44:18 GMT, Daniel Fuchs wrote: >> I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread. > > I'll take your word for it - the use of a volatile variable to store the singleton instance made this suspicious. good point - I think that came in when I adapted the code from IllegalAccessLogger - which can indeed be accessed from multiple threads. In this case the initialization is effectively part of bootstrap, and volatile is not required. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 23:26:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 23:26:01 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 21:10:33 GMT, Maurizio Cimadamore wrote: > I just did a test: > > ``` > public class TestLookup { > public static void main(String[] args) throws Throwable { > MethodHandle handle = MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", MethodType.methodType(MethodHandle.class, Addressable.class, MethodType.class, FunctionDescriptor.class)); > CLinker linker = CLinker.getInstance(); > handle.invoke(linker, MemoryAddress.NULL, MethodType.methodType(void.class), FunctionDescriptor.ofVoid()); > } > } > ``` > > this fails as expected when the handle is invoked. To test I had to disable the check on CLinker.getInstance - otherwise that would have always throw anyway. My statement was overly simplified. If `handle` is invoked in another module B and invoked by a class in module B, which module (the `lookup`'s module or ) do you expect be the caller to check against for native access check? `CLinker::downcallHandle` is not caller-sensitive but its implementation is. The method handle of a caller-sensitive method behaves as if it were called from an instruction contained in the lookup class [1]. [1] https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#callsens > Also, on IllegalCaller vs. IllegalAccess - looking more, I think our impl throws IllegalCaller - now that was done because IllegalAccess is a checked exception and we don't want a checked exception here - but the option is called "enableNativeAccess" - is that still ok? Yes the implementation throws `IllegalCallerException` which is why I point out this. Hmm... this seems more of `IllegalAccess` as the caller does not have access to this restricted method. OTOH, `Module::addOpens` grants deep reflection access to the named module if the caller has access. Otherwise, `IllegalCallerException` is thrown. So I think it's okay to throw ICE. Others may have a different opinion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From peter.firmstone at zeus.net.au Thu Apr 29 05:37:53 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 29 Apr 2021 15:37:53 +1000 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Which version of Java is this planned for??? Will the last version supporting the security manager be a long term support version, eg back ports of security patches and TLS technologies? We have our own security manager implementation and policy provider implementations.? Both of these are high performance and non-blocking and we are able to dynamically grant and revoke some permissions.?? While I acknowledge the Java policy implementation has a significant performance impact, due to blocking permission checks, ours is less than 1%.? Our software doesn't share PermissionCollection instances among threads, or even have a Permissions cache, PermissionCollection's are generated for each permission check and discarded for garbage collection, the Permission object themselves are cached (after initialization and safe publication), as are the results of repeated permission checks.? We also have our own Permission implementations. We have tools that generate policy files with least privilege, although we will manually alter them with wildcards, for network connections for instance. In our software, dynamic permissions are granted after authentication of TLS connections. It is too early for me to tell if there are suitable replacement technologies available.? I can understand the motivation for reducing Java's software development burden, but I think this version of Java might be the last for us, it would certainly be good if a long term support version was available, perhaps indefinitely lol. Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > - Mark From geertjan at apache.org Thu Apr 29 06:44:32 2021 From: geertjan at apache.org (Geertjan Wielenga) Date: Thu, 29 Apr 2021 08:44:32 +0200 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: Also, from the point of view of Apache NetBeans, here?s a list of our concerns with these developments: https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security Apache NetBeans doesn't use java.lang.SecurityManager to guarantee security, but rather to gain additional insight into the JVM's behavior. Without having such insights, the IDE's user experience would be severely affected. Are replacement APIs being designed and will they be provided for evaluation before JEP-411 is integrated? Thanks, Gj On Thu, 29 Apr 2021 at 07:38, Peter Firmstone wrote: > Which version of Java is this planned for? Will the last version > supporting the security manager be a long term support version, eg back > ports of security patches and TLS technologies? > > We have our own security manager implementation and policy provider > implementations. Both of these are high performance and non-blocking > and we are able to dynamically grant and revoke some permissions. > While I acknowledge the Java policy implementation has a significant > performance impact, due to blocking permission checks, ours is less than > 1%. Our software doesn't share PermissionCollection instances among > threads, or even have a Permissions cache, PermissionCollection's are > generated for each permission check and discarded for garbage > collection, the Permission object themselves are cached (after > initialization and safe publication), as are the results of repeated > permission checks. We also have our own Permission implementations. > > We have tools that generate policy files with least privilege, although > we will manually alter them with wildcards, for network connections for > instance. > > In our software, dynamic permissions are granted after authentication of > TLS connections. > > It is too early for me to tell if there are suitable replacement > technologies available. I can understand the motivation for reducing > Java's software development burden, but I think this version of Java > might be the last for us, it would certainly be good if a long term > support version was available, perhaps indefinitely lol. > > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > > On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote: > > https://openjdk.java.net/jeps/411 > > > > Summary: Deprecate the Security Manager for removal in a future > > release. The Security Manager dates from Java 1.0. It has not been the > > primary means of securing client-side Java code for many years, and it > > has rarely been used to secure server-side code. To move Java forward, > > we intend to deprecate the Security Manager for removal in concert > with > > the legacy Applet API (JEP 398). > > > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Apr 29 06:47:15 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 29 Apr 2021 16:47:15 +1000 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: We also use the SecurityManager for caller sensitive method calls. I re-implemented a secure implementation of Java Serialization, using a public API and fewer features (eg no circular links), in this implementation, each class in an object's hierarchy has its own namespace, the calling class is discovered using a SecurityManager subclass. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. On 29/04/2021 3:37 pm, Peter Firmstone wrote: > Which version of Java is this planned for??? Will the last version > supporting the security manager be a long term support version, eg > back ports of security patches and TLS technologies? > > We have our own security manager implementation and policy provider > implementations.? Both of these are high performance and non-blocking > and we are able to dynamically grant and revoke some permissions.?? > While I acknowledge the Java policy implementation has a significant > performance impact, due to blocking permission checks, ours is less > than 1%.? Our software doesn't share PermissionCollection instances > among threads, or even have a Permissions cache, > PermissionCollection's are generated for each permission check and > discarded for garbage collection, the Permission object themselves are > cached (after initialization and safe publication), as are the results > of repeated permission checks.? We also have our own Permission > implementations. > > We have tools that generate policy files with least privilege, > although we will manually alter them with wildcards, for network > connections for instance. > > In our software, dynamic permissions are granted after authentication > of TLS connections. > > It is too early for me to tell if there are suitable replacement > technologies available.? I can understand the motivation for reducing > Java's software development burden, but I think this version of Java > might be the last for us, it would certainly be good if a long term > support version was available, perhaps indefinitely lol. > > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > > On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote: >> https://openjdk.java.net/jeps/411 >> >> ?? Summary: Deprecate the Security Manager for removal in a future >> ?? release. The Security Manager dates from Java 1.0. It has not been >> the >> ?? primary means of securing client-side Java code for many years, >> and it >> ?? has rarely been used to secure server-side code. To move Java >> forward, >> ?? we intend to deprecate the Security Manager for removal in concert >> with >> ?? the legacy Applet API (JEP 398). >> >> - Mark > From mcimadamore at openjdk.java.net Thu Apr 29 10:34:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 10:34:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 23:22:38 GMT, Mandy Chung wrote: > My statement was overly simplified, sorry. If `handle` is invoked in another module B and invoked by a class in module B, which module (the `lookup`'s module or ) do you expect be the caller to check against for native access check? `CLinker::downcallHandle` is not caller-sensitive but its implementation is. > > The method handle of a caller-sensitive method behaves as if it were called from an instruction contained in the lookup class [1]. I think I expect that, with caller sensitive, it is possible from a client in an "enabled" module to obtain a MethodHandle, and then pass it to an unprivileged module, which then calls it, and works ok. This matches my expectation (this trick could be used also to give a client access to an otherwise inaccessible - in the classic sense - method). So, when working with method handles, I'm completely fine working with the lookup class as context (and not with the real caller class). Given all this, do you agree that current checks are not affected by interface-ness of some of the methods involved? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Thu Apr 29 11:15:00 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 11:15:00 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [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/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments: * Fix all link vs. linkplain * Remove `volatile` and other defensive copying in `IllegalNativeAccessChecker` * Added @throws clauses in restricted methods for `IllegalCallerException` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/24e554c5..20671853 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=02-03 Stats: 102 lines in 8 files changed: 57 ins; 0 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Thu Apr 29 11:15:32 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 11:15:32 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:33:36 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [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/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > * fix typos in javadoc > * document ISE being thrown in all methods accepting a scope; add more tests for that Here's a new round of javadoc/specdiff with latest changes Javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v2/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v2/specdiff/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From peter.firmstone at zeus.net.au Thu Apr 29 12:06:37 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 29 Apr 2021 22:06:37 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Having implemented SecurityManager and Policy providers, I'd like to comment on some of the assessments, some thoughts: * Poor performance, this is specific to the Java Policy implementation, I have addressed this in my implementations, performance impact is imperceptible, I know how to address it. * Brittle permission model - Agreed, it is brittle. o Developers should use doPrivileged blocks to make security sensitive calls, so only one domain is on the call stack. Agreed when they don't do this it causes viral permission expansion. o Implementing Deny would address the example given. o Un-trusted code should never be run on the JVM, however some code is more trusted, or well audited, so we may wish to limit code that doesn't require privileges, based on principle of least privilege. o Is there a way to simplify Permission's?? We can write tools to generate policy files (I have). * Difficult programming model o If the library developer uses doPrivileged blocks and documents the permissions, then the application code doesn't require those permissions, as it is not on the call stack. o Agreed that most developers don't do this. o I use a tool to generate policy files that capture the viral growth of permissions, these still require some editing, eg to add system properties. Is there a simpler way to limit permissions of library code? I have gotten so used to secure coding, because we use it, I don't find it difficult, writing non blocking or good concurrent code is more difficult and developers make lots of mistakes with race conditions, visibility and synchronization. There are good static code analysis tools that identify poor coding practices, the same tools could be updated to include secure coding practices as well, to address viral permission expansion. Perhaps if we instead address the performance and usability issues, we could improve adoption,so it adds to Java's appeal, rather than detracting from it? Regards, Peter. Comments and code from one of my policy implementations (I have a few policy implementations that use the decorator pattern to add functionality, like dynamic permission grants): * If there is sufficient interest, we can implement a DENY clause, ?* in this case DENY cannot apply to GRANT clauses that contain ?* {@link java.security.AllPermission}, the domains to which a DENY clause ?* would apply will be a less privileged domain.? For example a user could be ?* granted SocketPermission("*", "connect"), while a DENY clause might ?* list specific SocketPermission domains that are disallowed, where a DENY ?* clause has precedence over all GRANT clause Permissions except for AllPermission. @Override ??? public boolean implies(ProtectionDomain domain, Permission permission) { ??????? if (permission == null) throw new NullPointerException("permission not allowed to be null"); ??????? if (domain == myDomain) { ??????????? PermissionCollection pc = myPermissions; ??????????? return pc.implies(permission); ??????? } ??????? Class klass = permission.getClass(); ??????? // Need to have a list of Permission's we can sort if permission is SocketPermission. ??????? NavigableSet perms = new TreeSet(comparator); ??????? PermissionGrant [] grantRefCopy = grantArray; ??????? int l = grantRefCopy.length; ??????? /* Check for privileged grants first to avoid recursion when ???????? * privileged domains become involved in policy decisions */ ??????? for (int j = 0; j < l; j++){ ??????????? PermissionGrant ge = grantRefCopy[j]; ??????????? if (ge.isPrivileged()){ ??????????????? if (ge.implies(domain)){ ??????????????????? return true; ??????????????? } ??????????? } ??????? } ??????? /* Merge the static Permissions, check for Privileged */ ??????? PermissionCollection staticPC = null; ??????? if (domain != null) { ??????????? staticPC =domain.getPermissions(); ??????????? if (staticPC != null){ ??????????????? Enumeration e = staticPC.elements(); ??????????????? while (e.hasMoreElements()){ ??????????????????? Permission p = e.nextElement(); ??????????????????? // return early if possible. ??????????????????? if (p instanceof AllPermission ) return true; ??????????????????? // Only add relevant permissions to minimise size. ??????????????????? if (klass.isInstance(permission) || permission instanceof UnresolvedPermission){ ??????????????????????? perms.add(p); ??????????????????? } ??????????????? } ??????????? } ??????? } ??????? /* Check less privileged grants */ ??????? for ( int j =0; j < l; j++ ){ ??????????? PermissionGrant ge = grantRefCopy[j]; ??????????? if (!ge.isPrivileged()){ ??????????????? if (ge.implies(domain)){ ??????????????????? Collection c = ge.getPermissions(); ??????????????????? Iterator i = c.iterator(); ??????????????????? while (i.hasNext()){ ??????????????????????? Permission p = i.next(); ??????????????????????? // Only add relevant permissions to minimise size. ??????????????????????? if (klass.isInstance(permission) || permission instanceof UnresolvedPermission){ ??????????????????????????? perms.add(p); ??????????????????????? } ??????????????????? } ??????????????? } ??????????? } ??????? } ??????? return convert(perms).implies(permission); ??? } On 28/04/2021 8:19 pm, Lim wrote: > On Wed, Apr 21, 2021 at 8:38 PM Ron Pressler wrote: >> Its current events might be not have everything you want, but will be expanded, in >> part to address the functionality that will be lost with the removal of Security Manager. > I agree that monitoring needs to be improved since there is a lack of > monitoring APIs except for JFR. Until those monitoring APIs are on par > with the usage of SM "monitoring", it makes no sense to remove without > providing alternatives. > >> Libraries that can disable the Security Manager aren?t able to circumvent OS-level >> sandboxing. If you?re not afraid of that, then they?re trusted and JFR is superior; >> if they?re untrusted, then configuring the Security Manager correctly for untrusted rich >> libraries is very difficult. > Since you said that it cannot circumvent OS-level sandboxing, what > will prevent those > libraries to monitor if there is JFR active and become dormant until > there is no JFR > present, then it will execute the malicious behavior; Or, the library > attempts to hide > or render the JFR useless so that it will not be recorded and noticed? > > On Wed, Apr 21, 2021 at 8:55 PM Ron Pressler wrote: >> For rich libraries and applications, your best bet is an OS-level sandbox. The Security Manager >> might give you a false sense of security. > Yes, OS-level sandbox is good but can it be scalable for many types of end > users that have different OS and hardware environments? In addition, how many > end users out there have used sandbox to isolate their desktop applications > except if the program has built-in sandbox such as web browsers? Programs > such as Docker does not count. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.java.net Thu Apr 29 12:22:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 12:22:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v5] In-Reply-To: References: Message-ID: <02OtcjUL7EtDhrlea772aQceCYVBpl3uMAWuwkgK6p0=.46f81497-dcc1-4ab2-b60a-84ee417f1301@github.com> > This PR contains the API and implementation changes for JEP-412 [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/412 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 ten additional commits since the last revision: - Merge branch 'master' into JEP-412 - Address review comments: * Fix all link vs. linkplain * Remove `volatile` and other defensive copying in `IllegalNativeAccessChecker` * Added @throws clauses in restricted methods for `IllegalCallerException` - Address review comments: * fix typos in javadoc * document ISE being thrown in all methods accepting a scope; add more tests for that - Address first batch of review comments - Add linker test excludes for x86 and other platforms which do not support `CLinker` - Integrate latest API tweaks - Fix x86 build - Fix `TestLinkToNativeRBP` - Initial push ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/20671853..f27db3f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=03-04 Stats: 477828 lines in 3664 files changed: 4983 ins; 470775 del; 2070 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From sean.mullan at oracle.com Thu Apr 29 12:57:07 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Apr 2021 08:57:07 -0400 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: On 4/29/21 1:37 AM, Peter Firmstone wrote: > Which version of Java is this planned for??? Will the last version > supporting the security manager be a long term support version, eg back > ports of security patches and TLS technologies? The JEP has not been targeted to a release yet, but the Security Manager (SM) will continue to be supported in current/previous releases, and its full functionality will be supported in the release it is targeted to (if approved). So, if it goes in 17, the SM will be deprecated but it will still be fully functional, although you may have to enable it on the command-line with the system property "-Djava.security.manager=allow". See the warnings section in the JEP for more details [1]. Subsequent releases may degrade the Security Manager APIs such that it is not fully supported but the intent is to try to preserve compatibility such that libraries that are coded with doPrivileged blocks continue to work without re-compilation for a number of releases before the APIs are actually removed. See the 2nd bullet of [2] in the JEP. > We have our own security manager implementation and policy provider > implementations.? Both of these are high performance and non-blocking > and we are able to dynamically grant and revoke some permissions. While > I acknowledge the Java policy implementation has a significant > performance impact, due to blocking permission checks, ours is less than > 1%.? Our software doesn't share PermissionCollection instances among > threads, or even have a Permissions cache, PermissionCollection's are > generated for each permission check and discarded for garbage > collection, the Permission object themselves are cached (after > initialization and safe publication), as are the results of repeated > permission checks.? We also have our own Permission implementations. Yes, you and I had discussions about this several years ago and I believe I asked if you would be willing to donate these performance improvements. I can't remember but I think you had interest in doing that but couldn't make it happen for some reason. > We have tools that generate policy files with least privilege, although > we will manually alter them with wildcards, for network connections for > instance. > > In our software, dynamic permissions are granted after authentication of > TLS connections. > > It is too early for me to tell if there are suitable replacement > technologies available.? I can understand the motivation for reducing > Java's software development burden, but I think this version of Java > might be the last for us, it would certainly be good if a long term > support version was available, perhaps indefinitely lol. Well, indefinitely is a strong word :), and this is really based on vendor's support models, but I think it is safe to say the SM will be supported for at least 5-10 years into the future on 17 or previous JDK releases. Thanks, Sean [1] https://openjdk.java.net/jeps/411#Issue-warnings [2] https://openjdk.java.net/jeps/411#Risks-and-Assumptions > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > > On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote: >> https://openjdk.java.net/jeps/411 >> >> ?? Summary: Deprecate the Security Manager for removal in a future >> ?? release. The Security Manager dates from Java 1.0. It has not been the >> ?? primary means of securing client-side Java code for many years, and it >> ?? has rarely been used to secure server-side code. To move Java forward, >> ?? we intend to deprecate the Security Manager for removal in concert >> with >> ?? the legacy Applet API (JEP 398). >> >> - Mark > From weijun at openjdk.java.net Thu Apr 29 13:31:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 29 Apr 2021 13:31:49 GMT Subject: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified In-Reply-To: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> References: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> Message-ID: <574RlP0j_OHGyVEhYyLcyDBIbz6sO1KgMgkD7LZRvSY=.68fe808a-90d6-42b8-99d2-cb19ebb94276@github.com> On Wed, 28 Apr 2021 15:07:14 GMT, Weijun Wang wrote: > It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. Test `sun/security/tools/keytool/KeyToolTest.java` failed on Windows. Looks like a file-not-closed issue. Will investigate if related to this code change. ------------- PR: https://git.openjdk.java.net/jdk/pull/3764 From sean.mullan at oracle.com Thu Apr 29 13:49:31 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Apr 2021 09:49:31 -0400 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: <6c4e70b0-f106-bf5f-86f2-661024994e2c@oracle.com> On 4/29/21 2:44 AM, Geertjan Wielenga wrote: > > Also, from the point of view of Apache NetBeans, here?s a list of our > concerns with these developments: > > https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security > > > Apache NetBeans doesn't use java.lang.SecurityManager to guarantee > security, but rather to gain additional insight into the JVM's behavior. > Without having such insights, the IDE's user experience would be > severely affected. > > Are replacement APIs being designed and will they be provided for > evaluation before JEP-411 is integrated? One of the Goals [1] in JEP 411 is: - Evaluate whether new APIs or mechanisms are needed to address specific narrow use cases for which the Security Manager has been employed, such as blocking System.exit(). Thus, it is not a goal of this JEP to design replacements; however it is a goal of the JEP to identify potential use cases that may need replacements. Those cases would be explored more and if considered important enough defined in other Enhancements or JEPs. The next update of the JEP will include additional text about some other SM use cases. Thanks, Sean [1] https://openjdk.java.net/jeps/411#Goals > > Thanks, > > Gj > > > On Thu, 29 Apr 2021 at 07:38, Peter Firmstone > > wrote: > > Which version of Java is this planned for??? Will the last version > supporting the security manager be a long term support version, eg back > ports of security patches and TLS technologies? > > We have our own security manager implementation and policy provider > implementations.? Both of these are high performance and non-blocking > and we are able to dynamically grant and revoke some permissions. > While I acknowledge the Java policy implementation has a significant > performance impact, due to blocking permission checks, ours is less > than > 1%.? Our software doesn't share PermissionCollection instances among > threads, or even have a Permissions cache, PermissionCollection's are > generated for each permission check and discarded for garbage > collection, the Permission object themselves are cached (after > initialization and safe publication), as are the results of repeated > permission checks.? We also have our own Permission implementations. > > We have tools that generate policy files with least privilege, although > we will manually alter them with wildcards, for network connections for > instance. > > In our software, dynamic permissions are granted after > authentication of > TLS connections. > > It is too early for me to tell if there are suitable replacement > technologies available.? I can understand the motivation for reducing > Java's software development burden, but I think this version of Java > might be the last for us, it would certainly be good if a long term > support version was available, perhaps indefinitely lol. > > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > > On 16/04/2021 4:05 am, mark.reinhold at oracle.com > wrote: > > https://openjdk.java.net/jeps/411 > > > >? ? Summary: Deprecate the Security Manager for removal in a future > >? ? release. The Security Manager dates from Java 1.0. It has not > been the > >? ? primary means of securing client-side Java code for many > years, and it > >? ? has rarely been used to secure server-side code. To move Java > forward, > >? ? we intend to deprecate the Security Manager for removal in > concert with > >? ? the legacy Applet API (JEP 398). > > > > - Mark > From david.lloyd at redhat.com Thu Apr 29 14:57:32 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 29 Apr 2021 09:57:32 -0500 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: If it helps, we've solved this particular problem in a couple of places by using an MR-JAR which selects an implementation using `StackWalker` when Java 9+ is used. I will say however that it appears to be slightly less performant, which is unfortunate (but hopefully fixable at some point in the future). On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone wrote: > We also use the SecurityManager for caller sensitive method calls. > > I re-implemented a secure implementation of Java Serialization, using a > public API and fewer features (eg no circular links), in this > implementation, each class in an object's hierarchy has its own > namespace, the calling class is discovered using a SecurityManager > subclass. > > -- > Regards, > > Peter Firmstone > 0498 286 363 > Zeus Project Services Pty Ltd. > > On 29/04/2021 3:37 pm, Peter Firmstone wrote: > > Which version of Java is this planned for? Will the last version > > supporting the security manager be a long term support version, eg > > back ports of security patches and TLS technologies? > > > > We have our own security manager implementation and policy provider > > implementations. Both of these are high performance and non-blocking > > and we are able to dynamically grant and revoke some permissions. > > While I acknowledge the Java policy implementation has a significant > > performance impact, due to blocking permission checks, ours is less > > than 1%. Our software doesn't share PermissionCollection instances > > among threads, or even have a Permissions cache, > > PermissionCollection's are generated for each permission check and > > discarded for garbage collection, the Permission object themselves are > > cached (after initialization and safe publication), as are the results > > of repeated permission checks. We also have our own Permission > > implementations. > > > > We have tools that generate policy files with least privilege, > > although we will manually alter them with wildcards, for network > > connections for instance. > > > > In our software, dynamic permissions are granted after authentication > > of TLS connections. > > > > It is too early for me to tell if there are suitable replacement > > technologies available. I can understand the motivation for reducing > > Java's software development burden, but I think this version of Java > > might be the last for us, it would certainly be good if a long term > > support version was available, perhaps indefinitely lol. > > > > Regards, > > > > Peter Firmstone > > Zeus Project Services Pty Ltd. > > > > > > On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote: > >> https://openjdk.java.net/jeps/411 > >> > >> Summary: Deprecate the Security Manager for removal in a future > >> release. The Security Manager dates from Java 1.0. It has not been > >> the > >> primary means of securing client-side Java code for many years, > >> and it > >> has rarely been used to secure server-side code. To move Java > >> forward, > >> we intend to deprecate the Security Manager for removal in concert > >> with > >> the legacy Applet API (JEP 398). > >> > >> - Mark > > > > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Thu Apr 29 15:24:45 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 29 Apr 2021 17:24:45 +0200 Subject: Ping? [8u] RFR: 8206925: Support the certificate_authorities extension In-Reply-To: References: Message-ID: <3ee97cc85d184730ed4d59ebb18529852105beda.camel@redhat.com> Anyone? On Tue, 2021-04-20 at 12:23 +0200, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport of the certificate_authorities > extensionj. The OpenJDK 11u patch didn't apply cleanly after path > unshuffeling, but was fairly trivial to resolve. Conflicts caused by: > > 1. X509Authentication.java copyright line conflict only. Resolved > ?? manually. > 2. SSLContextTemplate.java private interface methods not allowed in > ?? JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to > ?? default. Note: this is code used in tests only. > 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the > ?? test invocations since JDK 8u doesn't enable TLSv1.3 on the > ?? client side by default. See JDK-8248721, CSR of the TLSv1.3 8u > ?? backport. > > Other than that, the patch is identical to the OpenJDK 11.0.12 > version > of this patch. > > This introduces a new system property, > jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has > been reused from the Oracle JDK backport. See below. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248709 > webrev: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/ > > Testing: sun/security/ssl tests and tier1. No new regressions. > ???????? New tests pass. > > Thoughts? > > Thanks, > Severin From xuelei at openjdk.java.net Thu Apr 29 16:00:54 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 29 Apr 2021 16:00:54 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> References: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> Message-ID: On Tue, 27 Apr 2021 23:45:30 GMT, Alexey Bakhtin wrote: >> src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 377: >> >>> 375: // If we are keeping state, see if the identity is in the cache >>> 376: if (requestedId.identity.length == SessionId.MAX_LENGTH) { >>> 377: synchronized (sessionCache) { >> >> Did you have a test if there is a performance regression by introducing the synchronization here? >> >> I have to check the engineGetServerSessionContext() specification and implementation (if the sessionCache is a reference?), and the session cache implementation to make sure the synchronization works (if the synchronization on sessionCache is the same as the synchronization on the cache internal implementation) . Maybe, the improvement could in the cache implementation for readability? > > Yes, I?ve made a test that calculates total time spent by server to receive "N" connections. Every server handshake is performed in a separate thread > The client starts "T" threads. Every thread sends one initial connection and "R-1" renegotiated connections. So, the total number of connections is "N"="T"*"R" > > Results for the original and JDK-8241248 code are almost identical: > "T"=10 "R"=100 > Original OpenJDK: 1140 ms > JDK-8241248 code: 1090 ms > > "T"=50 "R"=100 > Original OpenJDK: 1164 ms > JDK-8241248 code: 1108 ms > > "T"=60 "R"=100 > Original OpenJDK: 1461 ms > JDK-8241248 code: 1579 ms > > "T"=70 "R"=100 > Original OpenJDK: 2058 ms > JDK-8241248 code: 1999 ms > > "T"=80 "R"=100 > Original OpenJDK: 2148 ms > JDK-8241248 code: 2125 ms > > "T"=90 "R"=100 > Original OpenJDK: 2540 ms > JDK-8241248 code: 2514 ms > > "T"=90 "R"=100 > Original OpenJDK: 3011 ms > JDK-8241248 code: 3010 ms > > I can confirm that the synchronization code works. Without it, I still catch exception from different threads trying to resume the same session from the cache Thank you for the update. I would like to have the synchronization in the cache class for easier maintainence. But please go ahead for the integration if you don't want to make the update now. We could file an enhancement later on. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From jnimeh at openjdk.java.net Thu Apr 29 16:04:52 2021 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 29 Apr 2021 16:04:52 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: References: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> Message-ID: On Thu, 29 Apr 2021 15:58:28 GMT, Xue-Lei Andrew Fan wrote: >> Yes, I?ve made a test that calculates total time spent by server to receive "N" connections. Every server handshake is performed in a separate thread >> The client starts "T" threads. Every thread sends one initial connection and "R-1" renegotiated connections. So, the total number of connections is "N"="T"*"R" >> >> Results for the original and JDK-8241248 code are almost identical: >> "T"=10 "R"=100 >> Original OpenJDK: 1140 ms >> JDK-8241248 code: 1090 ms >> >> "T"=50 "R"=100 >> Original OpenJDK: 1164 ms >> JDK-8241248 code: 1108 ms >> >> "T"=60 "R"=100 >> Original OpenJDK: 1461 ms >> JDK-8241248 code: 1579 ms >> >> "T"=70 "R"=100 >> Original OpenJDK: 2058 ms >> JDK-8241248 code: 1999 ms >> >> "T"=80 "R"=100 >> Original OpenJDK: 2148 ms >> JDK-8241248 code: 2125 ms >> >> "T"=90 "R"=100 >> Original OpenJDK: 2540 ms >> JDK-8241248 code: 2514 ms >> >> "T"=90 "R"=100 >> Original OpenJDK: 3011 ms >> JDK-8241248 code: 3010 ms >> >> I can confirm that the synchronization code works. Without it, I still catch exception from different threads trying to resume the same session from the cache > > Thank you for the update. > > I also expect the code easy to read and maintain in the future. But please go ahead for the integration if you don't want to make the update now. We could file an enhancement later on. There were some changes that @ascarpino did for RSA blinding to reduce lock contention within that cache. It doesn't look like we're running into a hot lock here based on the numbers above, but it might be worth looking at his solution down the road when we move synchronization into the Cache object. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From weijun at openjdk.java.net Thu Apr 29 17:51:17 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 29 Apr 2021 17:51:17 GMT Subject: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified [v2] In-Reply-To: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> References: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> Message-ID: > It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: close stream carefully ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3764/files - new: https://git.openjdk.java.net/jdk/pull/3764/files/b9c9b8ee..51bc2fc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3764&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3764&range=00-01 Stats: 9 lines in 1 file changed: 3 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3764/head:pull/3764 PR: https://git.openjdk.java.net/jdk/pull/3764 From weijun at openjdk.java.net Thu Apr 29 17:53:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 29 Apr 2021 17:53:49 GMT Subject: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified In-Reply-To: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> References: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> Message-ID: On Wed, 28 Apr 2021 15:07:14 GMT, Weijun Wang wrote: > It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. New commit pushed. When the file is opened the second time, uses a local variable and close it quickly. The `ksStream` global variable is only assigned once and is always closed in a finally block. ------------- PR: https://git.openjdk.java.net/jdk/pull/3764 From mchung at openjdk.java.net Thu Apr 29 18:20:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 29 Apr 2021 18:20:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 10:31:29 GMT, Maurizio Cimadamore wrote: > I think I expect that, with caller sensitive, it is possible from a client in an "enabled" module to obtain a MethodHandle, and then pass it to an unprivileged module, which then calls it, and works ok. This matches my expectation (this trick could be used also to give a client access to an otherwise inaccessible - in the classic sense - method). > > So, when working with method handles, I'm completely fine working with the lookup class as context (and not with the real caller class). Good, this matches the behavior of method handles for CSMs. However, I think the implementation does the opposite since we don't support interface method being CSM. Can you test that out? > Given all this, do you agree that current checks are not affected by interface-ness of some of the methods involved? I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From valeriep at openjdk.java.net Thu Apr 29 21:05:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 29 Apr 2021 21:05:53 GMT Subject: Integrated: 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:08:30 GMT, Valerie Peng wrote: > Could someone (perhaps Jamil?) please help review this change? This enhances SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation support. Majority of the regression tests are adapted from the existing ones for SunJCE provider's ChaCha20-Poly1305 cipher impl. When testing against NSS v3.57, it does not have support for ChaCha20 cipher, thus I did not add support for ChaCha20 cipher and the corresponding parameter. > > Thanks! > Valerie This pull request has now been integrated. Changeset: 5d8c1cc8 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/5d8c1cc8a05e0d9aedd6d54b8147d374c2290024 Stats: 1595 lines in 15 files changed: 1479 ins; 34 del; 82 mod 8255410: Add ChaCha20 and Poly1305 support to SunPKCS11 provider Reviewed-by: jnimeh ------------- PR: https://git.openjdk.java.net/jdk/pull/3420 From peter.firmstone at zeus.net.au Thu Apr 29 21:11:36 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 30 Apr 2021 07:11:36 +1000 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: On 29/04/2021 10:57 pm, Sean Mullan wrote: > > On 4/29/21 1:37 AM, Peter Firmstone wrote: > >> We have our own security manager implementation and policy provider >> implementations.? Both of these are high performance and non-blocking >> and we are able to dynamically grant and revoke some permissions. >> While I acknowledge the Java policy implementation has a significant >> performance impact, due to blocking permission checks, ours is less >> than 1%.? Our software doesn't share PermissionCollection instances >> among threads, or even have a Permissions cache, >> PermissionCollection's are generated for each permission check and >> discarded for garbage collection, the Permission object themselves >> are cached (after initialization and safe publication), as are the >> results of repeated permission checks. We also have our own >> Permission implementations. > > Yes, you and I had discussions about this several years ago and I > believe I asked if you would be willing to donate these performance > improvements. I can't remember but I think you had interest in doing > that but couldn't make it happen for some reason. > Licensing, parts of the code I could donate as I am the original author, but other parts were AL 2.0 licensed by others, I think I found some AL2.0 code in OpenJDK at the time, but I was having trouble getting clarity around licensing, I don't remember the details but I think I needed to contact the other authors and have them sign contributor agreements or rewrite their code. The two components that caused licensing issues were the policy parser (although Java has it's own, so not a major issue) and an RFC 3986 URI implementation which replaced URL, which was heavily utilised, it normalizes URI for policy implies checks, including RFC 5952 IPv6 address normalization, OS specific file based URI were normalized dependent on the underlying OS (eg uppercase for Microsoft).? Using Java's URI wasn't an option as it wouldn't normalize appropriately, while using URL would cause blocking network calls. It is a strict RFC 3986 implementation, Unicode characters beyond US-ASCII are escaped, and it utilises bit shift operations during normalization, it's also immutable and not serializable, so it wasn't a backward compatible replacement for Java's URI. The difference between URI and URL use in policy files, was that if two different domain names resolved to the same IP Address, they implied each other under a URL ( required blocking network dns calls), while they didn't imply one another under URI.?? This had the added benefit of allowing one domain name to resolve to multiple IP addresses without having to add multiple IP addresses to policy files, for example fail-over web server addresses. Some trivia, I also wrote a URIClassLoader that replaced URLClassLoader, specifically to override behaviour in SecureClassLoader, where URL's are used as key's in a cache, again for performance reasons. Re-implementing RFC 3986 URI functionality was a significant undertaking, I wasn't familiar with? OpenJDK's build system, was busy with other things so I put it off until later... which hasn't happened yet lol. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From xuelei at openjdk.java.net Thu Apr 29 21:18:57 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 29 Apr 2021 21:18:57 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey wrote: >> Trivial enough change. Improved the exception thrown from JceKeyStore also. > > Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Check for null before try block > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8236671-NPE > - Fix white space > - 8236671: NullPointerException in JKS keystore Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From valeriep at openjdk.java.net Thu Apr 29 21:35:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 29 Apr 2021 21:35:53 GMT Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation In-Reply-To: References: <33h9xgGUasgPFdxvgsnm4TpLQhIT4y0k77FOtctW_mM=.24808d1e-587c-4806-a4c9-849c23592519@github.com> Message-ID: On Tue, 27 Apr 2021 18:46:21 GMT, Greg Rubin wrote: >> For this particular call, the pValue field is null, it's meant to query the exact length of the specified attribute. Thus, CKR_BUFFER_TOO_SMALL should not be returned. >> Afterwards, we then allocate the buffer based on this queried result, so CKR_BUFFER_TOO_SMALL should also not occur. >> So, based on the current API usage, CKR_BUFFER_TOO_SMALL should not happen. > > All my concerns are addressed then. So, while my review doesn't count towards acceptance of this change, everything LGTM. Thanks for your review still. Good to have an extra pair of eyes to look over the changes... ------------- PR: https://git.openjdk.java.net/jdk/pull/3709 From peter.firmstone at zeus.net.au Fri Apr 30 05:25:04 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 30 Apr 2021 15:25:04 +1000 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <0de7f460-164f-28a8-f5bd-4d1ae22f397f@zeus.net.au> Message-ID: Thanks David, will make a note of it for future reference. Cheers, Peter. On 30/04/2021 12:57 am, David Lloyd wrote: > If it helps, we've solved this particular problem in a couple of > places by using an MR-JAR which selects an implementation using > `StackWalker` when Java 9+ is used.? I will say however that it > appears to be slightly less performant, which is unfortunate (but > hopefully fixable at some point in the future). > > On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone > > wrote: > > We also use the SecurityManager for caller sensitive method calls. > > I re-implemented a secure implementation of Java Serialization, > using a > public API and fewer features (eg no circular links), in this > implementation, each class in an object's hierarchy has its own > namespace, the calling class is discovered using a SecurityManager > subclass. > > -- > Regards, > > Peter Firmstone > 0498 286 363 > Zeus Project Services Pty Ltd. > > On 29/04/2021 3:37 pm, Peter Firmstone wrote: > > Which version of Java is this planned for??? Will the last version > > supporting the security manager be a long term support version, eg > > back ports of security patches and TLS technologies? > > > > We have our own security manager implementation and policy provider > > implementations.? Both of these are high performance and > non-blocking > > and we are able to dynamically grant and revoke some permissions. > > While I acknowledge the Java policy implementation has a > significant > > performance impact, due to blocking permission checks, ours is less > > than 1%.? Our software doesn't share PermissionCollection instances > > among threads, or even have a Permissions cache, > > PermissionCollection's are generated for each permission check and > > discarded for garbage collection, the Permission object > themselves are > > cached (after initialization and safe publication), as are the > results > > of repeated permission checks.? We also have our own Permission > > implementations. > > > > We have tools that generate policy files with least privilege, > > although we will manually alter them with wildcards, for network > > connections for instance. > > > > In our software, dynamic permissions are granted after > authentication > > of TLS connections. > > > > It is too early for me to tell if there are suitable replacement > > technologies available.? I can understand the motivation for > reducing > > Java's software development burden, but I think this version of > Java > > might be the last for us, it would certainly be good if a long term > > support version was available, perhaps indefinitely lol. > > > > Regards, > > > > Peter Firmstone > > Zeus Project Services Pty Ltd. > > > > > > On 16/04/2021 4:05 am, mark.reinhold at oracle.com > wrote: > >> https://openjdk.java.net/jeps/411 > > >> > >> ?? Summary: Deprecate the Security Manager for removal in a future > >> ?? release. The Security Manager dates from Java 1.0. It has > not been > >> the > >> ?? primary means of securing client-side Java code for many years, > >> and it > >> ?? has rarely been used to secure server-side code. To move Java > >> forward, > >> ?? we intend to deprecate the Security Manager for removal in > concert > >> with > >> ?? the legacy Applet API (JEP 398). > >> > >> - Mark > > > > > > -- > - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From coffeys at openjdk.java.net Fri Apr 30 09:22:52 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 30 Apr 2021 09:22:52 GMT Subject: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified [v2] In-Reply-To: References: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> Message-ID: On Thu, 29 Apr 2021 17:51:17 GMT, Weijun Wang wrote: >> It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > close stream carefully Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3764 From coffeys at openjdk.java.net Fri Apr 30 09:29:59 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 30 Apr 2021 09:29:59 GMT Subject: RFR: 8236671: NullPointerException in JKS keystore [v2] In-Reply-To: References: Message-ID: <3XV3VBENLppWqupCwu5BFLwQ6IK2wOjqY2LZMXzFlJM=.57139075-5af8-4ce8-a302-6ca0aeec2bcf@github.com> On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey wrote: >> Trivial enough change. Improved the exception thrown from JceKeyStore also. > > Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Check for null before try block > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8236671-NPE > - Fix white space > - 8236671: NullPointerException in JKS keystore KeyStore specification will be tightened up via another bug record: https://bugs.openjdk.java.net/browse/JDK-8266351 ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From coffeys at openjdk.java.net Fri Apr 30 09:35:52 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 30 Apr 2021 09:35:52 GMT Subject: Integrated: 8236671: NullPointerException in JKS keystore In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:54:39 GMT, Sean Coffey wrote: > Trivial enough change. Improved the exception thrown from JceKeyStore also. This pull request has now been integrated. Changeset: 276a1bf7 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/276a1bf7675e32784870f5559f6d3ac8bea07b6e Stats: 17 lines in 3 files changed: 14 ins; 0 del; 3 mod 8236671: NullPointerException in JKS keystore Reviewed-by: hchao, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3588 From hchao at openjdk.java.net Fri Apr 30 11:29:51 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 30 Apr 2021 11:29:51 GMT Subject: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified [v2] In-Reply-To: References: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> Message-ID: On Thu, 29 Apr 2021 17:51:17 GMT, Weijun Wang wrote: >> It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > close stream carefully Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3764 From mcimadamore at openjdk.java.net Fri Apr 30 12:23:45 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 30 Apr 2021 12:23:45 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [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/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Add @CS to interface methods in the Foreign API * Beef up test for methd handles and restricted methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/f27db3f3..75474a1f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=04-05 Stats: 306 lines in 8 files changed: 306 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Fri Apr 30 12:27:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 30 Apr 2021 12:27:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 18:18:00 GMT, Mandy Chung wrote: > I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration. I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module). Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From weijun at openjdk.java.net Fri Apr 30 14:06:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 30 Apr 2021 14:06:53 GMT Subject: Integrated: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified In-Reply-To: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> References: <8kKfEJYHwnWwKw-pYCr7_RucOYU2IXpwEcpXYXALovc=.7dac5ab5-bd1e-483f-9c47-c43784fda84f@github.com> Message-ID: <965z05dZwkVyASqdmc9foADaAQ4EJVEZAMMUDPIxrNQ=.ef75ea24-d1d8-443d-847c-5e2cae689b42@github.com> On Wed, 28 Apr 2021 15:07:14 GMT, Weijun Wang wrote: > It's awkward that for a password-less pkcs12 keystore, `keytool -list` does not prompt for a password but `keytool -list -storetype pkcs12` does. This pull request has now been integrated. Changeset: 48bb996a Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/48bb996ac9098fc33f6d52e2af15448b12a19572 Stats: 44 lines in 2 files changed: 30 ins; 5 del; 9 mod 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified Reviewed-by: coffeys, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/3764 From mcimadamore at openjdk.java.net Fri Apr 30 15:20:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 30 Apr 2021 15:20:42 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [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/412 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Revert bad change in benchmark copyright - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/75474a1f..793ea5c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=05-06 Stats: 23 lines in 3 files changed: 17 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From abakhtin at openjdk.java.net Fri Apr 30 16:04:24 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 30 Apr 2021 16:04:24 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v2] In-Reply-To: References: Message-ID: > Hello All, > > Could you please review the fix for the JDK-8241248? > The issue happens during the TLSv1.3 handshake without server stateless session resumption in case of server receives several parallel requests with the same pre_shared_key. > The main idea of the fix is to remove resuming session from the session cache in the early stage. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > Webrev 8u: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ > > The test from the bug report using OpenSSL is passed ( -Djdk.tls.server.enableSessionTicketExtension=false ) > javax/net/ssl and sun/security/ssl jtreg tests passed > > Regards > Alexey Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Use ReentrantLock for session cache synchronization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3664/files - new: https://git.openjdk.java.net/jdk/pull/3664/files/c3afeb18..aac8eee7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=00-01 Stats: 230 lines in 3 files changed: 125 ins; 96 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3664.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3664/head:pull/3664 PR: https://git.openjdk.java.net/jdk/pull/3664 From abakhtin at openjdk.java.net Fri Apr 30 16:15:52 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 30 Apr 2021 16:15:52 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v2] In-Reply-To: References: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> Message-ID: On Thu, 29 Apr 2021 15:58:28 GMT, Xue-Lei Andrew Fan wrote: >> Yes, I?ve made a test that calculates total time spent by server to receive "N" connections. Every server handshake is performed in a separate thread >> The client starts "T" threads. Every thread sends one initial connection and "R-1" renegotiated connections. So, the total number of connections is "N"="T"*"R" >> >> Results for the original and JDK-8241248 code are almost identical: >> "T"=10 "R"=100 >> Original OpenJDK: 1140 ms >> JDK-8241248 code: 1090 ms >> >> "T"=50 "R"=100 >> Original OpenJDK: 1164 ms >> JDK-8241248 code: 1108 ms >> >> "T"=60 "R"=100 >> Original OpenJDK: 1461 ms >> JDK-8241248 code: 1579 ms >> >> "T"=70 "R"=100 >> Original OpenJDK: 2058 ms >> JDK-8241248 code: 1999 ms >> >> "T"=80 "R"=100 >> Original OpenJDK: 2148 ms >> JDK-8241248 code: 2125 ms >> >> "T"=90 "R"=100 >> Original OpenJDK: 2540 ms >> JDK-8241248 code: 2514 ms >> >> "T"=90 "R"=100 >> Original OpenJDK: 3011 ms >> JDK-8241248 code: 3010 ms >> >> I can confirm that the synchronization code works. Without it, I still catch exception from different threads trying to resume the same session from the cache > > Thank you for the update. > > I also expect the code easy to read and maintain in the future. But please go ahead for the integration if you don't want to make the update now. We could file an enhancement later on. @XueleiFan , @jnimeh, thank you for your suggestions. I have updated synchronization using ReentrantLock in the Cache object. The performance test showed no issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From martin.doerr at sap.com Fri Apr 30 16:34:08 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 30 Apr 2021 16:34:08 +0000 Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms Message-ID: Hi, JDK-8153005 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8153005 CSR covering 11u: https://bugs.openjdk.java.net/browse/JDK-8228481 Original change: https://github.com/openjdk/jdk/commit/f77a6585 11u rejected hunks: http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/8153005_PKCS12_rej.txt Resolution: - Regular code is trivial to resolve, but the tests are tricky and the hunks were mostly integrated manually. - Introduce test/lib/jdk/test/lib/KnownOIDs.java as copy from jdk head src/java.base/share/classes/sun/security/util/KnownOIDs.java with last change from Oct 2020. Put into package jdk.test.lib and using System.out as debug output stream. This should make future backports easier, too. - DerUtils.java: ObjectIdentifier interface is diffent in 11u (different constructors). - Hunks in GenerateAll.java were skipped because the affected code is not in 11u (JDK-8242068). 11u backport: http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/webrev.00/ Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.sargent at gmail.com Fri Apr 30 16:54:25 2021 From: will.sargent at gmail.com (Will Sargent) Date: Fri, 30 Apr 2021 09:54:25 -0700 Subject: RFR: 8236671: NullPointerException in JKS keystore [v2] In-Reply-To: <3XV3VBENLppWqupCwu5BFLwQ6IK2wOjqY2LZMXzFlJM=.57139075-5af8-4ce8-a302-6ca0aeec2bcf@github.com> References: <3XV3VBENLppWqupCwu5BFLwQ6IK2wOjqY2LZMXzFlJM=.57139075-5af8-4ce8-a302-6ca0aeec2bcf@github.com> Message-ID: > KeyStore specification will be tightened up via another bug record This would be super helpful, as one thing that confuses me is what the relationship is between a key entry and a key alias -- in particular, the existence alias doesn't seem to guarantee a valid entry that can be retrieved. In JDK 11 it's possible to create a private key with a keystore using pkcs12 .setKeyEntry() (see link below): https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L135 and then have a null pointer exception when retrieving the entry from the alias because the certificate chain is null (see commented out "testSystem" use case): https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L27 I can write this up into a formal bug if that helps. On Fri, Apr 30, 2021 at 2:30 AM Sean Coffey wrote: > On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey wrote: > > >> Trivial enough change. Improved the exception thrown from JceKeyStore > also. > > > > Sean Coffey has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > > > - Check for null before try block > > - Merge branch 'master' of https://github.com/openjdk/jdk into > JDK-8236671-NPE > > - Fix white space > > - 8236671: NullPointerException in JKS keystore > > KeyStore specification will be tightened up via another bug record: > https://bugs.openjdk.java.net/browse/JDK-8266351 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3588 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.java.net Fri Apr 30 17:23:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 30 Apr 2021 17:23:01 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 12:24:38 GMT, Maurizio Cimadamore wrote: > I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module). Thanks. > Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing? I create JDK-8266383 and I will look into that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From weijun at openjdk.java.net Fri Apr 30 17:43:16 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 30 Apr 2021 17:43:16 GMT Subject: RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Message-ID: `PKCS12KeyStore` always uses a 20-byte salt in encryption but PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt used for this algorithm will be 8 bytes. RFC 2898 only requires the salt to be at least 8 bytes, but I don't intend to modify the `PBES1Core.java` to accept a long salt. Otherwise, a newly generated PKCS #12 file using a long salt will not be recognized by an old JDK. Also, although `PBES1Core.java` also take cares of another algorithm named PBEWithMD5AndDESede but it's not usable in a PKCS #12 keystore as we have not defined its Object Identifier anywhere. ------------- Commit messages: - 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Changes: https://git.openjdk.java.net/jdk/pull/3822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266293 Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3822/head:pull/3822 PR: https://git.openjdk.java.net/jdk/pull/3822 From wetmore at openjdk.java.net Fri Apr 30 17:56:51 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 30 Apr 2021 17:56:51 GMT Subject: RFR: 8263779: SSLEngine reports NEED_WRAP continuously without producing any further output [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 00:12:44 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1694: >> >>> 1692: if (cause instanceof SocketException) { >>> 1693: try { >>> 1694: throw conContext.fatal(alert, cause); >> >> Why did you change to a throw here? Isn't everything from fatal() going to be thrown anyway? > > The fatal() will always throw an exception. We could use the method without throw. In some places, IDE or compiler could complain because it cannot detect that the fatal() method will throw and the program ends here. In the past, we use fatal() method without throw, later we change the fatal() return value form "void" to an exception so that throw could be used to mitigate the IDE or compiler complaints. > > It is not really necessary to make this code change here. I just want to make the coding style consistent for the fatal() calling. Interesting, ok. I don't recall seeing such situations with the IDE I often use. (Netbeans) ------------- PR: https://git.openjdk.java.net/jdk/pull/3292 From sean.coffey at oracle.com Fri Apr 30 19:39:48 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 30 Apr 2021 20:39:48 +0100 Subject: RFR: 8236671: NullPointerException in JKS keystore [v2] In-Reply-To: References: <3XV3VBENLppWqupCwu5BFLwQ6IK2wOjqY2LZMXzFlJM=.57139075-5af8-4ce8-a302-6ca0aeec2bcf@github.com> Message-ID: Thanks for the feedback Will. It would be useful if you can provide a testcase and/or add comments to JDK-8266351 on your experience. regards, Sean. On 30/04/2021 17:54, Will Sargent wrote: > > KeyStore specification will be tightened up via another bug record > > This would be super helpful, as one thing that confuses me is what the > relationship is between a key entry and a key alias -- in particular, > the existence alias doesn't seem to guarantee a valid entry that can > be retrieved. > > In JDK 11 it's possible to create a private key with a keystore using > pkcs12.setKeyEntry() (see link below): > > https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L135 > > > and then have a null pointer exception when retrieving the entry from > the alias because the certificate chain is null (see commented out > "testSystem" use case): > > https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L27 > > > I can write this up into a formal bug if that helps. > > On Fri, Apr 30, 2021 at 2:30 AM Sean Coffey > wrote: > > On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey > wrote: > > >> Trivial enough change. Improved the exception thrown from > JceKeyStore also. > > > > Sean Coffey has updated the pull request with a new target base > due to a merge or a rebase. The incremental webrev excludes the > unrelated changes brought in by the merge/rebase. The pull request > contains four additional commits since the last revision: > > > >? - Check for null before try block > >? - Merge branch 'master' of https://github.com/openjdk/jdk > into JDK-8236671-NPE > >? - Fix white space > >? - 8236671: NullPointerException in JKS keystore > > KeyStore specification will be tightened up via another bug > record: https://bugs.openjdk.java.net/browse/JDK-8266351 > > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3588 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: