8282534: Remove redundant null check in ChaCha20Cipher.engineInit
-
Commit messages:
- [PATCH] Remove redundant null check in ChaCha20Cipher.engineInit
Changes: https://git.openjdk.java.net/jdk/pull/7424/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7424&range=00
Is
On Thu, 10 Feb 2022 13:20:34 GMT, Andrey Turbanov wrote:
> 8282534: Remove redundant null check in ChaCha20Cipher.engineInit
@turbanoff I've created an entry for you in the tracker, for your PR to be
marked as ready for review please rename your PR title to 8282534 and the rest
should be taken
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 chang
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was
> introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() /
> Socket.shutdownOutput() and InputStream.close() / OutputStream.close()
> performed half-cl
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()
>> perfo
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
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
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
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 (Review
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was
> introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() /
> Socket.shutdownOutput() and InputStream.close() / OutputStream.close()
> performed half-cl
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 i
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 i
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 i
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 i
> This fixes jarsigner to enforce checking against algorithm constraint
> properties so when the signature algorithms parameters use disabled or legacy
> algorithms, it will emit warnings accordingly. If the algorithm used in
> parameters is disabled, jarsigner treats the jar as unsigned.
Hai-M
On Wed, 2 Mar 2022 15:30:22 GMT, Sean Mullan wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unneeded import and updated -verbose output
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.j
On Wed, 2 Mar 2022 16:20:53 GMT, Weijun Wang wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unneeded import and updated -verbose output
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.j
On Wed, 2 Mar 2022 17:46:26 GMT, Hai-May Chao wrote:
>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line
>> 1414:
>>
>>> 1412: } catch (CertPathValidatorException e) {
>>> 1413: disabledAlgFound = true;
>>> 1414: return String
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, strip
The comment said "pad it w/ leading 0s". So let's pad it.
-
Commit messages:
- remove x bits
- 8281628: KeyAgreement : generateSecret intermittently not resetting
Changes: https://git.openjdk.java.net/jdk/pull/7665/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7665&r
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 < e
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 sur
On Wed, 2 Mar 2022 21:47:06 GMT, Valerie Peng wrote:
>> The comment said "pad it w/ leading 0s". So let's pad it.
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line
> 347:
>
>> 345: // Array too short, pad it w/ leading 0s
>> 346: if (secret
> The comment said "pad it w/ leading 0s". So let's pad it.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
wrap and comment
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7665/files
- new: https://git.openjd
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 fir
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 = gene
> The comment said "pad it w/ leading 0s". So let's pad it.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
check length as well
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7665/files
- new: https://git.op
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 thi
On Wed, 2 Mar 2022 23:03:44 GMT, Weijun Wang wrote:
>> The comment said "pad it w/ leading 0s". So let's pad it.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> check length as well
Changes look good.
-
Marked
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 remi
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was
> introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() /
> Socket.shutdownOutput() and InputStream.close() / OutputStream.close()
> performed half-cl
On Tue, 1 Mar 2022 17:09:57 GMT, zzambers wrote:
> Fixed API Note in javadoc for javax.net.ssl.SSLSocket class. API Note was
> introduced by JDK-8208526 [1]. At that point both Socket.shutdownInput() /
> Socket.shutdownOutput() and InputStream.close() / OutputStream.close()
> performed half-cl
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
Sta
Hi Xuelei,
I am working on some close code including the recent PR[1] for:
8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket
and ran into a change I hadn't noticed before.
* @apiNote
* When the connection is no longer needed, the client and server
* applications should each
> This fixes jarsigner to enforce checking against algorithm constraint
> properties so when the signature algorithms parameters use disabled or legacy
> algorithms, it will emit warnings accordingly. If the algorithm used in
> parameters is disabled, jarsigner treats the jar as unsigned.
Hai-M
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?
> This fixes jarsigner to enforce checking against algorithm constraint
> properties so when the signature algorithms parameters use disabled or legacy
> algorithms, it will emit warnings accordingly. If the algorithm used in
> parameters is disabled, jarsigner treats the jar as unsigned.
Hai-M
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();
38 matches
Mail list logo
