On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote:
> This issue adds a new event to improve diagnostic information of Java
> deserialization. The event captures the details of deserialization activity
> from ObjectInputStream. The event details are similar to that of the serial
> filter, bu
On Thu, 11 Feb 2021 01:54:53 GMT, John Jiang wrote:
>> This is a simple cleanup for sun.security.ssl.SSLExtension.
>> It converts protocol or draft names to RFC numbers correspondingly.
>> It also removes a trailing space in extension token_binding, and move
>> signature_algorithms_cert to RFC 8
> This is a simple cleanup for sun.security.ssl.SSLExtension.
> It converts protocol or draft names to RFC numbers correspondingly.
> It also removes a trailing space in extension token_binding, and move
> signature_algorithms_cert to RFC 8446 extension group.
John Jiang has updated the pull requ
On Wed, 10 Feb 2021 21:22:03 GMT, John Jiang wrote:
> This is a simple cleanup for sun.security.ssl.SSLExtension.
> It converts protocol or draft names to RFC numbers correspondingly.
> It also removes a trailing space in extension token_binding, and move
> signature_algorithms_cert to RFC 8446
On Wed, 10 Feb 2021 23:25:45 GMT, Weijun Wang wrote:
>> The current method serves the need to verify the accuracy of the AKID for
>> this PR, and it looks straightforward to perceive I think. The API such as
>> cert.getExtensionValue(KnownOIDs.AuthorityKeyID.value()), and new DerValue
>> to ge
> This change is made for compliance with RFC 5280 section 4.2.1.1 for
> Authority Key Identifier extension.
Hai-May Chao has updated the pull request incrementally with one additional
commit since the last revision:
API used to get AKID
-
Changes:
- all: https://git.openjdk.j
This is a simple cleanup for sun.security.ssl.SSLExtension.
It converts protocol or draft names to RFC numbers correspondingly.
It also removes a trailing space in extension token_binding, and move
signature_algorithms_cert to RFC 8446 extension group.
-
Commit messages:
- JDK-82615
Fix exception in test
sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java:
java.security.AccessControlException: access denied
("java.security.SecurityPermission" "removeProvider.SUN")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java
On Wed, 10 Feb 2021 23:07:51 GMT, Hai-May Chao wrote:
>> test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69:
>>
>>> 67: .shouldContain(": 00 01 02 03 04 05 06 07 08 09
>>> 10 11 12 13 14 15")
>>> 68: .shouldContain("0010: 16 17 18 19")
>>> 69:
On Wed, 10 Feb 2021 22:41:26 GMT, Weijun Wang wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test case added and not overriding -ext fix
>
> test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69:
>
>> 67
On Wed, 10 Feb 2021 21:52:01 GMT, Hai-May Chao wrote:
>> This change is made for compliance with RFC 5280 section 4.2.1.1 for
>> Authority Key Identifier extension.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Test case
> This change is made for compliance with RFC 5280 section 4.2.1.1 for
> Authority Key Identifier extension.
Hai-May Chao has updated the pull request incrementally with one additional
commit since the last revision:
Test case added and not overriding -ext fix
-
Changes:
- all
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote:
> This issue adds a new event to improve diagnostic information of Java
> deserialization. The event captures the details of deserialization activity
> from ObjectInputStream. The event details are similar to that of the serial
> filter, bu
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote:
> This issue adds a new event to improve diagnostic information of Java
> deserialization. The event captures the details of deserialization activity
> from ObjectInputStream. The event details are similar to that of the serial
> filter, bu
On Wed, 10 Feb 2021 00:44:57 GMT, Xue-Lei Andrew Fan 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 could
On Wed, 10 Feb 2021 16:33:54 GMT, Jamil Nimeh wrote:
> This is a spec-only change that clarifies the requirement on KeyAgreement
> implementations for multi-party support where there are 3 or more parties
> involved. This change states that 3+ party support is
> implementation-specific unless
This is a spec-only change that clarifies the requirement on KeyAgreement
implementations for multi-party support where there are 3 or more parties
involved. This change states that 3+ party support is implementation-specific
unless the underlying specification for that algorithm requires suppo
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote:
> This issue adds a new event to improve diagnostic information of Java
> deserialization. The event captures the details of deserialization activity
> from ObjectInputStream. The event details are similar to that of the serial
> filter, bu
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote:
> This issue adds a new event to improve diagnostic information of Java
> deserialization. The event captures the details of deserialization activity
> from ObjectInputStream. The event details are similar to that of the serial
> filter, bu
This issue adds a new event to improve diagnostic information of Java
deserialization. The event captures the details of deserialization activity
from ObjectInputStream. The event details are similar to that of the serial
filter, but is agnostic of whether a filter is installed or not. The event
Hi,
I'd like to propose a fix for JDK-8261355 [1].
The scheme used for holding data and padding while performing encryption
operations is almost the same than the existing one for decryption. The only
difference is that encryption does not require a block-sized buffer to be
always held because
On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis
wrote:
>>> Hi Claes,
>>> Would flattening the state of MD5 bring any further improvements?
>>> [plevart@92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083)
>>
>> I think it might, marginally, but it seemed to m
On Wed, 10 Feb 2021 01:52:21 GMT, Jamil Nimeh wrote:
>> Print out "no limit" instead. This is the words RFC 5280 uses: "Where
>> pathLenConstraint does not appear, no limit is imposed".
>>
>> No regression test. Trivial.
>
> Looks fine to me.
> Sorry - not quite right, it's not quite that triv
On Thu, 7 Jan 2021 17:09:14 GMT, Claes Redestad wrote:
>> Hi Claes,
>> Would flattening the state of MD5 bring any further improvements?
>> https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083
>
>> Hi Claes,
>> Would flattening the state of MD5 bring any further improvem
On Fri, 5 Feb 2021 20:48:56 GMT, Fernando Guallini
wrote:
>> The server side is binding to the wildcard address which has been a source
>> of instability in many networking tests due to javax.net.ssl.SSLException:
>> Connection reset. Changing the following tests to bind to loopback address
>
25 matches
Mail list logo
