Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

On Tue, 3 May 2022 02:02:58 GMT, Xue-Lei Andrew Fan wrote: >>> Thanks for the rewording. Updated. >> >> I made one more tweak that reads better. > > Yes, it looks better. Updated. Thanks! Looks good, thanks. - PR: https://git.openjdk.java.net/jdk/pull/8065

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v14]

On Mon, 2 May 2022 22:35:08 GMT, Brent Christian wrote: > Hi. Sorry, I should have brought this up earlier, but there is a jtreg test > library to help with ensuring the GC runs, > `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the > test code that runs/checks the GC

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

On Mon, 2 May 2022 17:55:56 GMT, Bradford Wetmore wrote: >> Thanks for the rewording. Updated. > >> Thanks for the rewording. Updated. > > I made one more tweak that reads better. Yes, it looks better. Updated. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/8065

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5]

> Please review the update to remove finalizer method in the SunJSSE provider > implementation. It is one of the efforts to clean up the use of finalizer > method in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: More

Re: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v4]

On Mon, 2 May 2022 22:39:09 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the >> umbrella bug for this bug. The changes were too large for a single code >> review, so it was decided to split

Re: zlib before 1.2.12 allows memory corruption (CVE-2018-25032)

Volker, Bernd, thanks for the replies - they were really useful Vitaly > On 27 Apr 2022, at 14:59, Volker Simonis wrote: > > Hi Bernd, Vitaly, > > Amazon Corretto [1] also includes the fixes for CVE-2018-25032. This > is our statement: > > "Based upon our analysis, OpenJDK/Corretto is not

Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]

On Mon, 2 May 2022 21:14:21 GMT, Valerie Peng wrote: >> Then what does "cannot generate parameter values" mean? Any example? > > An example is RSASSA-PSS, i.e. it requires the caller to explicitly state > which message digest to use, etc. You listed 2 cases when null is returned: 1) not

Re: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v4]

> Anyone can help review this javadoc update? The main change is the wording > for the method javadoc of > Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording > is somewhat restrictive and request is to broaden this to accommodate more > scenarios such as when null can

Re: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5]

On Mon, 2 May 2022 22:38:18 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updated spec in java.security > > test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java line 66: > >> 64:

Integrated: 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry

On Mon, 2 May 2022 17:41:52 GMT, Weijun Wang wrote: > PKCS12 stores the object identifier of a SecretKey along with it, and when > retrieved, translate the object identifier to an algorithm name. > Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered >

Re: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5]

On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to >> `jdk.security.legacyAlgorithms` security property, and to add the legacy >> algorithm constraint checking to `keytool` commands that are associated with >> secret key entries stored

Re: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v4]

> https://bugs.openjdk.java.net/browse/JDK-8284688 > > [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the > umbrella bug for this bug. The changes were too large for a single code > review, so it was decided to split into smaller chunks. This is one such > chunk: > >

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v14]

On Mon, 2 May 2022 15:27:39 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry

On Mon, 2 May 2022 17:41:52 GMT, Weijun Wang wrote: > PKCS12 stores the object identifier of a SecretKey along with it, and when > retrieved, translate the object identifier to an algorithm name. > Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered >

Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]

On Fri, 29 Apr 2022 04:27:36 GMT, Xue-Lei Andrew Fan wrote: >> What kind of additional sentence do you have in mind? > >> What kind of additional sentence do you have in mind? > > It may be fine to put it into the state for 'null" returned value. For > example: > > > The returned parameters

Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]

On Thu, 28 Apr 2022 23:28:39 GMT, Weijun Wang wrote: >> The impl does not need to generate parameter values, but rather cannot >> convert the supplied parameter values into AlgorithmParameter objects. By >> parameter values, I mean the components of the parameters. > > Then what does "cannot

RFR: 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry

PKCS12 stores the object identifier of a SecretKey along with it, and when retrieved, translate the object identifier to an algorithm name. Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered

Re: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3]

On Fri, 29 Apr 2022 15:23:47 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/Cipher.java line 1053: > >> 1051: * The

Re: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3]

On Fri, 29 Apr 2022 15:18:34 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/Cipher.java line 1055: > >> 1053: *

Re: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3]

On Thu, 28 Apr 2022 19:23:18 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/CipherSpi.java line 449: > >> 447: * >>

Re: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3]

On Thu, 28 Apr 2022 19:17:08 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/Cipher.java line 1056: > >> 1054: *

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

On Mon, 2 May 2022 17:45:44 GMT, Xue-Lei Andrew Fan wrote: > Thanks for the rewording. Updated. I made one more tweak that reads better. - PR: https://git.openjdk.java.net/jdk/pull/8065

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

On Mon, 2 May 2022 16:46:17 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> comment about remove finalize() method > >

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v4]

> Please review the update to remove finalizer method in the SunJSSE provider > implementation. It is one of the efforts to clean up the use of finalizer > method in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5]

On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to >> `jdk.security.legacyAlgorithms` security property, and to add the legacy >> algorithm constraint checking to `keytool` commands that are associated with >> secret key entries stored

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

On Mon, 2 May 2022 05:01:21 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider >> implementation. It is one of the efforts to clean up the use of finalizer >> method in JDK. > > Xue-Lei Andrew Fan has updated the pull request

Re: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5]

On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to >> `jdk.security.legacyAlgorithms` security property, and to add the legacy >> algorithm constraint checking to `keytool` commands that are associated with >> secret key entries stored

Interesting in TLS Ticket Requests

Hi, A new standard, RFC 9149 TLS Ticket Requests, was published on April 2022. Is anyone interested in have it implemented in JDK? As described in RFC 8446/TLS 1.3, TLS servers vend clients an arbitrary number of session tickets for session resumption. However, the number may be not what

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v14]

> Please review the update to remove finalizer method in the java.security.jgss > module. It is one of the efforts to clean up the use of finalizer method in > JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: add

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v13]

On Thu, 28 Apr 2022 18:32:31 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Interesting in DTLS 1.3

Hi, The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 (DTLS 1.3) has been published on April 2022. The specification describes the most current version of the DTLS protocol as a delta from TLS 1.3 and obsoletes DTLS 1.2. In JDK, the

Integrated: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file

On Thu, 28 Apr 2022 14:35:54 GMT, Weijun Wang wrote: > We added a new system property back in > https://bugs.openjdk.java.net/browse/JDK-8153005 but it's better to describe > it in the `java.security` file as well. > > Please review the text. I especially added the last sentence so that

Re: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file [v2]

On Fri, 29 Apr 2022 21:49:32 GMT, Weijun Wang wrote: >> We added a new system property back in >> https://bugs.openjdk.java.net/browse/JDK-8153005 but it's better to describe >> it in the `java.security` file as well. >> >> Please review the text. I especially added the last sentence so that

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

Hi Arjan, Java 8 is supported until 2030, and 17 to 2029, we would be unable to continue testing against new Java releases. https://bugs.openjdk.java.net/browse/JDK-8272340 With this choice, there will be incompatible Java versions we must prevent our software from running on, until it

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

Hi, On Monday, May 2, 2022, Peter Firmstone wrote: I guess I'm just trying to say we need more time, the process of > extricating SM for security will take years, if we can leave SM as it is in > deprecated form for a number of years, that would be greatly appreciated. Just wondering, but