On Thu, 18 Mar 2021 01:27:26 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 86:
>>
>>> 84: SecureRandom result = def;
>>> 85: if (result == null) {
>>> 86: synchronized (JCAUtil.class) {
>>
>> Could this lock be avoided if
On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote:
>> Can someone help review this somewhat trivial change?
>>
>> Updated JCAUtil class to return the cached SecureRandom object only when the
>> provider configuration has not changed.
>> Added a regression test to check the affected classes,
On Wed, 17 Mar 2021 20:40:16 GMT, Xue-Lei Andrew Fan wrote:
>> To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I
>> suppose this is more for JDK internal code which is not required to use the
>> most preferred SecureRandom impl. There are quite a few callers to this
>
On Wed, 17 Mar 2021 20:49:41 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed a null race condition
>
> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 86:
>
>> 84:
On Wed, 17 Mar 2021 21:03:38 GMT, Anthony Scarpino
wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed a null race condition
>
> Marked as reviewed by ascarpino (Reviewer).
Thanks all for the review and feedbac
> This is a P2 regression introduced by JDK-8254717.
>
> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the
> KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is
> described as follow:
>
> X-axis: type of `keySpec`
> Y-axis: type of `key`
>
> Before
On Wed, 17 Mar 2021 20:13:43 GMT, SalusaSecondus
wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed a null race condition
>
> Not that my review counts towards approval, but this looks good to me (and
> fixes
On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote:
>> Can someone help review this somewhat trivial change?
>>
>> Updated JCAUtil class to return the cached SecureRandom object only when the
>> provider configuration has not changed.
>> Added a regression test to check the affected classes,
On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote:
>> Can someone help review this somewhat trivial change?
>>
>> Updated JCAUtil class to return the cached SecureRandom object only when the
>> provider configuration has not changed.
>> Added a regression test to check the affected classes,
On Wed, 17 Mar 2021 19:55:13 GMT, Valerie Peng wrote:
> To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I
> suppose this is more for JDK internal code which is not required to use the
> most preferred SecureRandom impl. There are quite a few callers to this
> method a
On Wed, 17 Mar 2021 20:09:04 GMT, Valerie Peng wrote:
>> Can someone help review this somewhat trivial change?
>>
>> Updated JCAUtil class to return the cached SecureRandom object only when the
>> provider configuration has not changed.
>> Added a regression test to check the affected classes,
> Can someone help review this somewhat trivial change?
>
> Updated JCAUtil class to return the cached SecureRandom object only when the
> provider configuration has not changed.
> Added a regression test to check the affected classes, i.e.
> AlgorithmParameterGenerator, KeyPairGenerator, Ciphe
Np, tagged.
-Original Message-
From: Daniel Jeliński
Date: Tuesday, March 16, 2021 at 11:40 PM
To: "Hohensee, Paul"
Cc: "[email protected]" ,
"[email protected]"
Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and
scalability
Thanks a
On Wed, 17 Mar 2021 19:34:54 GMT, SalusaSecondus
wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changed to use volatile for the default SecureRandom object reference
>
> src/java.base/share/classes/sun/security/j
On Wed, 17 Mar 2021 19:25:13 GMT, Valerie Peng wrote:
>> Can someone help review this somewhat trivial change?
>>
>> Updated JCAUtil class to return the cached SecureRandom object only when the
>> provider configuration has not changed.
>> Added a regression test to check the affected classes,
On Wed, 17 Mar 2021 19:32:56 GMT, SalusaSecondus
wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changed to use volatile for the default SecureRandom object reference
>
> src/java.base/share/classes/sun/security/j
> Can someone help review this somewhat trivial change?
>
> Updated JCAUtil class to return the cached SecureRandom object only when the
> provider configuration has not changed.
> Added a regression test to check the affected classes, i.e.
> AlgorithmParameterGenerator, KeyPairGenerator, Ciphe
Remove redundant lock in SSLSocketImpl.
In the SSLSocketImpl, there is a socket level lock while reading application
data (see readApplicationRecord).
socketLock.lock();
try {
plainText = decode(buffer);
} finally {
On Thu, 18 Feb 2021 14:30:15 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
> joined Strings.
>
> This applies for the cases when all joined Strings as well as delimiter,
> prefix and suffix contain only ASCII symbols.
>
> As
On Mon, 15 Mar 2021 21:47:28 GMT, Сергей Цыпанов
wrote:
>> Hello,
>>
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
>> joined Strings.
>>
>> This applies for the cases when all joined Strings as well as delimiter,
>> prefix and suffix contain only ASCII symbols.
>
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt
wrote:
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the `java.base
Sonar displays a warning message that modifiers should be declared in the order
listed in the JLS; specifically, that isntead of using `final static` the
`static final` should be preferred.
This fixes the issues in the `java.base` package for ease of reviewing.
https://sonarcloud.io/project/iss
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt
wrote:
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the `java.base
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.
How does this apply to TLS versions befor
24 matches
Mail list logo
