> Hi everyone,
>
> Please review my fix for JDK-8211227
>
> This supportability fix will result in a more consistent debug format when
> reading and writing TLS protocol versions.
>
> Thanks,
> Evan
Evan Whelan has updated the pull request incrementally with one additional
commit since the la
> 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/a
On Mon, 22 Feb 2021 07:12:57 GMT, Valerie Peng wrote:
> Changes look good. Thanks~
Thanks a lot for your patience and precious feedback.
-
PR: https://git.openjdk.java.net/jdk/pull/2070
On Fri, 19 Feb 2021 08:39:23 GMT, John Jiang wrote:
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
Changes requested by rhalade (Reviewer).
test/jdk/javax/net/ssl/Serve
Kerberos new replay cache format released in 1.18 (installed in OL8.3) is
causing the tests failures:
`https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html`
New and old format are not compatible, that means they cannot share a rcache
file. Since there is no interopera
> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client |
> server].SignatureSchemes property and its effect on messages that assert the
> signature_algorithms and signature_algorithms_cert extensions, or
> supported_signature_algorithms vectors like those used in TLS 1.2
> Ce
Hi,
I need a code review of this change to ECDH. It is a combination of fixing the
implementation to not only accept ECPrivateKeyImpl along with a fix to the
exception handling. They started as two fixes, but with the exception handling
the underlying code changed significantly that made the
On Fri, 19 Feb 2021 21:44:15 GMT, Weijun Wang wrote:
> `InetAddress` is loading native library `net` and at the same time
> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
> deadlock.
>
> W
On Wed, 13 Jan 2021 06:19:18 GMT, Clive Verghese wrote:
> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears
> to not be fully fixed
>
> This also fixes JDK-8259516: Alerts sent by peer may not be received
> correctly during TLS handshake
This pull request has now bee
On Mon, 22 Feb 2021 09:47:16 GMT, Evan Whelan wrote:
>> Hi everyone,
>>
>> Please review my fix for JDK-8211227
>>
>> This supportability fix will result in a more consistent debug format when
>> reading and writing TLS protocol versions.
>>
>> Thanks,
>> Evan
>
> Evan Whelan has updated the
On Mon, 22 Feb 2021 17:07:58 GMT, Jamil Nimeh wrote:
>> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client |
>> server].SignatureSchemes property and its effect on messages that assert the
>> signature_algorithms and signature_algorithms_cert extensions, or
>> supported_si
On Mon, 22 Feb 2021 18:33:17 GMT, Xue-Lei Andrew Fan wrote:
>> `InetAddress` is loading native library `net` and at the same time
>> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
>> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
>> deadl
On Mon, 22 Feb 2021 18:56:10 GMT, Xue-Lei Andrew Fan wrote:
>> Jamil Nimeh has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary import
>
> test/jdk/sun/security/ssl/SignatureScheme/SigSchemePropOrdering.java line 90:
>
>>
On Tue, 16 Feb 2021 19:38:50 GMT, djelinski
wrote:
>>> I may think it differently. It may be hard to know the future frequency of
>>> an cached item based on the past behaviors. For the above case, I'm not
>>> sure that K=3 is used less frequently than K=1. Maybe, next few seconds,
>>> K=1 co
> `InetAddress` is loading native library `net` and at the same time
> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
> deadlock.
>
> We can access `InetAddress` in `SunNativeProvider.` befo
On Mon, 22 Feb 2021 18:44:15 GMT, Rajan Halade wrote:
>> Evan Whelan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8211227: Re-wrote LoggingFormatConsistency to leverage SSLSocketTemplate
>
> Thanks for developing test for this change
On Mon, 1 Feb 2021 10:37:35 GMT, Evan Whelan wrote:
> Hi everyone,
>
> Please review my fix for JDK-8211227
>
> This supportability fix will result in a more consistent debug format when
> reading and writing TLS protocol versions.
>
> Thanks,
> Evan
This pull request has now been integrated
> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client |
> server].SignatureSchemes property and its effect on messages that assert the
> signature_algorithms and signature_algorithms_cert extensions, or
> supported_signature_algorithms vectors like those used in TLS 1.2
> Ce
On Mon, 22 Feb 2021 20:36:53 GMT, djelinski
wrote:
> Actually there's a much easier solution to reduce the number of slow `put()`s
> without making any behavioral changes.
> The cache object could store the earliest expire time, and then exit
> `expungeExpiredEntries()` early when current time
On Mon, 22 Feb 2021 20:56:09 GMT, Weijun Wang wrote:
>> `InetAddress` is loading native library `net` and at the same time
>> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
>> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
>> deadlock.
>>
On Mon, 22 Feb 2021 21:28:57 GMT, Jamil Nimeh wrote:
>> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client |
>> server].SignatureSchemes property and its effect on messages that assert the
>> signature_algorithms and signature_algorithms_cert extensions, or
>> supported_si
On Sat, 20 Feb 2021 01:56:37 GMT, Jamil Nimeh wrote:
> This fix adjusts the SunJSSE provider's handling of the jdk.tls.[client |
> server].SignatureSchemes property and its effect on messages that assert the
> signature_algorithms and signature_algorithms_cert extensions, or
> supported_signat
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
John Jiang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes
On Mon, 22 Feb 2021 16:17:28 GMT, Rajan Halade wrote:
>> John Jiang 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 two additional
>> commits si
On Fri, 19 Feb 2021 21:44:15 GMT, Weijun Wang wrote:
> `InetAddress` is loading native library `net` and at the same time
> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
> deadlock.
>
> W
> This is a multi-commits PR that upgrades xmldsig to be equivalent to
> Santuario 2.2.0.
>
> The first step is an auto-import. The JDK implementation is removed first and
> Santuario code are imported. Some unrelated files (Ex: encryption) are
> removed, and package names are renamed to be int
All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be
backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most
cases, the requested KeySpec is equal to the concrete implementation so the
inversion does not matter. But there are few cases, as presented in the
On Tue, 23 Feb 2021 01:38:36 GMT, Ziyi Luo wrote:
> All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be
> backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most
> cases, the requested KeySpec is equal to the concrete implementation so the
> inversion do
On Tue, 23 Feb 2021 01:38:36 GMT, Ziyi Luo wrote:
> All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be
> backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most
> cases, the requested KeySpec is equal to the concrete implementation so the
> inversion do
All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be
backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most
cases, the requested KeySpec is equal to the concrete implementation so the
inversion does not matter. But there are few cases, as presented in the
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
John Jiang has updated the pull request incrementally with one additional
commit since the last revision:
Throw RuntimeE
On Mon, 11 Jan 2021 17:58:03 GMT, Weijun Wang wrote:
>> I've force pushed a new series of commits from scratch. The difference:
>>
>> 1. The `s/Portions copyright/Copyright/` change is inside auto import.
>> 2. Some `s/Sun Microsystems/Oracle/` change in auto import
>> 3. No more deprecated `new
32 matches
Mail list logo
