Re: [Internet]Recent SSLSocket close() @apiNote Changes.

2022-03-02 Thread xueleifan(XueleiFan)
Hi Brad, I think you are right that this design is actually for TLSv1.3 half-close mode. For TLS 1.3, there is no duplex closure design. The close() implementation in JDK is actually a workaround for compatibility. Application can use either the half-close mode socket.shutdownOutput();

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v4]

2022-03-02 Thread Hai-May Chao
> This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters is disabled, jarsigner treats the jar as unsigned.

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v3]

2022-03-02 Thread Hai-May Chao
On Wed, 2 Mar 2022 19:54:13 GMT, Weijun Wang wrote: >> What does it look like now? Also, you might need to create a mapping in >> `Resources.java` because "using" should only be shown when system language >> is English. > > Also, what if it's another algorithm using another type of parameters?

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v3]

2022-03-02 Thread Hai-May Chao
> This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters is disabled, jarsigner treats the jar as unsigned.

Recent SSLSocket close() @apiNote Changes.

2022-03-02 Thread Bradford Wetmore
Hi Xuelei, I am working on some close code including the recent PR[1] for: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket and ran into a change I hadn't noticed before. * @apiNote * When the connection is no longer needed, the client and server * applications should

Integrated: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 19:35:50 GMT, Weijun Wang wrote: > The comment said "pad it w/ leading 0s". So let's pad it. This pull request has now been integrated. Changeset: 1485883c Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/1485883c9e6e24315bb21f20604b1c326e862a5b

Re: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

2022-03-02 Thread Bradford Wetmore
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was > introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / > Socket.shutdownOutput() and InputStream.close() / OutputStream.close() > performed

Re: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

2022-03-02 Thread Bradford Wetmore
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was > introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / > Socket.shutdownOutput() and InputStream.close() / OutputStream.close() > performed

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3]

2022-03-02 Thread Valerie Peng
On Wed, 2 Mar 2022 23:00:02 GMT, Weijun Wang wrote: >> After `n = generateSecret(secret, offset)` is called, only `n` bytes from >> `offset` should be touched, and in this case `n` is 64. Even if you allocate >> 80 bytes of data, we should not compare those after the 64th byte. > > But you

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3]

2022-03-02 Thread Valerie Peng
On Wed, 2 Mar 2022 23:03:44 GMT, Weijun Wang wrote: >> The comment said "pad it w/ leading 0s". So let's pad it. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > check length as well Changes look good. -

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 22:48:36 GMT, Weijun Wang wrote: >> With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect >> a difference and higher reproducibility... > > After `n = generateSecret(secret, offset)` is called, only `n` bytes from > `offset` should be touched, and in

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3]

2022-03-02 Thread Weijun Wang
> The comment said "pad it w/ leading 0s". So let's pad it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: check length as well - Changes: - all: https://git.openjdk.java.net/jdk/pull/7665/files - new:

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 22:31:02 GMT, Valerie Peng wrote: >> Maybe not. When the generated secret is shorter, the padded bytes are always >> at the beginning. > > With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect a > difference and higher reproducibility... After `n =

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2]

2022-03-02 Thread Valerie Peng
On Wed, 2 Mar 2022 22:26:45 GMT, Weijun Wang wrote: >> test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java >> line 56: >> >>> 54: // Different stale data >>> 55: aliceSecret[0] = 0; >>> 56: bobSecret[0] = 1; >> >> Instead of only the

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2]

2022-03-02 Thread Weijun Wang
> The comment said "pad it w/ leading 0s". So let's pad it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: wrap and comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/7665/files - new:

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 21:47:06 GMT, Valerie Peng wrote: >> The comment said "pad it w/ leading 0s". So let's pad it. > > src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line > 347: > >> 345: // Array too short, pad it w/ leading 0s >> 346: if

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA

2022-03-02 Thread Valerie Peng
On Wed, 2 Mar 2022 04:02:45 GMT, Anthony Scarpino wrote: > I have some compatibility concerns about the AES change breaking code that > expects a SecretKeySpec of 16 bytes. I can see situations where > '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, > I'm pretty

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Valerie Peng
On Wed, 2 Mar 2022 19:35:50 GMT, Weijun Wang wrote: > The comment said "pad it w/ leading 0s". So let's pad it. src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line 347: > 345: // Array too short, pad it w/ leading 0s > 346: if (secret.length <

RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Weijun Wang
The comment said "pad it w/ leading 0s". So let's pad it. - Commit messages: - remove x bits - 8281628: KeyAgreement : generateSecret intermittently not resetting Changes: https://git.openjdk.java.net/jdk/pull/7665/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7665=00

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 18:01:04 GMT, Weijun Wang wrote: >> I add "RA-PSS using “ to the `-verbose` output as suggested, and keep >> the remaining output as the parameters for the RSASSA-PSS contain >> hashAlgorithm and maskGenAlgorithm that could be disabled or weak. At the >> same time,

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 17:46:26 GMT, Hai-May Chao wrote: >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line >> 1414: >> >>> 1412: } catch (CertPathValidatorException e) { >>> 1413: disabledAlgFound = true; >>> 1414: return

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Hai-May Chao
On Wed, 2 Mar 2022 16:20:53 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Removed unneeded import and updated -verbose output > >

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Hai-May Chao
> This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters is disabled, jarsigner treats the jar as unsigned.

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Hai-May Chao
On Wed, 2 Mar 2022 15:30:22 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Removed unneeded import and updated -verbose output > >

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Weijun Wang
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Weijun Wang
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Weijun Wang
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Sean Mullan
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Re: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

2022-03-02 Thread Xue-Lei Andrew Fan
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was > introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / > Socket.shutdownOutput() and InputStream.close() / OutputStream.close() > performed

Re: RFR: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit

2022-03-02 Thread Xue-Lei Andrew Fan
On Thu, 10 Feb 2022 13:20:34 GMT, Andrey Turbanov wrote: > 8282534: Remove redundant null check in ChaCha20Cipher.engineInit Looks good to me. Please add a noreg-clean label in [JDK-8282534](https://bugs.openjdk.java.net/browse/JDK-8282534). - Marked as reviewed by xuelei

Integrated: 8281234: The -protected option is not always checked in keytool and jarsigner

2022-03-02 Thread Weijun Wang
On Thu, 3 Feb 2022 18:23:55 GMT, Weijun Wang wrote: > The option means there is no need to provide a password when loading a > keystore. In some places in jarsigner and keytool, even with the option > specified, password is still prompted for or warnings are still shown. This pull request has

RFR: 8282538: PKCS11 tests fail on CentOS Stream 9

2022-03-02 Thread Olga Mikhaltsova
I would like to add cert9.db and key4.db to /test/jdk/sun/security/pkcs11/nss/db/ to fix the PKCS11 tests failure on CentOS Stream 9. Starting from NSS 3.35 cert9.db and key4.db files may be targeted instead of cert8.db and key3.db. In case of CentOS Stream 9 the lowest available version of NSS

Re: RFR: 8281234: The -protected option is not always checked in keytool and jarsigner [v2]

2022-03-02 Thread Sean Mullan
On Fri, 4 Feb 2022 01:19:51 GMT, Weijun Wang wrote: >> The option means there is no need to provide a password when loading a >> keystore. In some places in jarsigner and keytool, even with the option >> specified, password is still prompted for or warnings are still shown. > > Weijun Wang has

Re: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

2022-03-02 Thread zzambers
On Wed, 2 Mar 2022 07:13:36 GMT, TheShermanTanker wrote: >> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was >> introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / >> Socket.shutdownOutput() and InputStream.close() / OutputStream.close() >>

Re: RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

2022-03-02 Thread TheShermanTanker
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote: > Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was > introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / > Socket.shutdownOutput() and InputStream.close() / OutputStream.close() > performed

RFR: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket

2022-03-02 Thread zzambers
Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() / Socket.shutdownOutput() and InputStream.close() / OutputStream.close() performed half-close of TLS-1.3 connection. However this behaviour has

Re: RFR: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit

2022-03-02 Thread TheShermanTanker
On Thu, 10 Feb 2022 13:20:34 GMT, Andrey Turbanov wrote: > 8282534: Remove redundant null check in ChaCha20Cipher.engineInit @turbanoff I've created an entry for you in the tracker, for your PR to be marked as ready for review please rename your PR title to 8282534 and the rest should be

RFR: 8282534: Remove redundant null check in ChaCha20Cipher.engineInit

2022-03-02 Thread Andrey Turbanov
8282534: Remove redundant null check in ChaCha20Cipher.engineInit - Commit messages: - [PATCH] Remove redundant null check in ChaCha20Cipher.engineInit Changes: https://git.openjdk.java.net/jdk/pull/7424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7424=00 Issue: