[15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property

2020-02-20 Thread Sean Mullan
Please review this change to cleanup and consolidate the default value of the jdk.tls.legacyAlgorithms security property. The following changes have been made: 1. Changed K_NULL, C_NULL, M_NULL to NULL, which will cover all null cipher suites. The *_NULL algorithms were implementation details

Re: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property

2020-02-20 Thread Xuelei Fan
Thanks for the cleanup. I added myself as reviewer for the CSR, and the webrev looks fine to me. Xuelei On 2/20/2020 5:01 AM, Sean Mullan wrote: Please review this change to cleanup and consolidate the default value of the jdk.tls.legacyAlgorithms security property. The following changes hav

Re: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property

2020-02-20 Thread Bernd Eckenfels
Hello Sean, Are the separate entries for 3DES and DES needed or can they also be collapsed? BTW i am always unsre about the interactions of setting the Protocol and the enabled ciphers so I am in the habit to set the protocols before using getEnabled or setting enabled ciphers. I guess it makes

Re: RFR 8160818: GssKrb5Client violates RFC 4752

2020-02-20 Thread Michael Osipov
Am 2020-02-20 um 03:57 schrieb Weijun Wang:> Ping again. > >> On Feb 14, 2020, at 10:51 PM, Weijun Wang wrote: >> >> >> >>> On Feb 14, 2020, at 9:42 PM, Michael Osipov <[email protected]> wrote: >>> >>> Am 2020-02-14 um 10:58 schrieb Weijun Wang: Webrev updated at https://cr.ope

Re: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS

2020-02-20 Thread Michael Osipov
Has there been any progress on this? I can see that JDK-8162628 is targeted for 15, but not fixed yet. This would be a tremendous improvement in JDK 15 and in 8/11 if backported. I don't expect PEM to be the default in 8/11, but configurable for PEM. Michael Am 2019-08-16 um 03:36 schrieb Weij

Re: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property

2020-02-20 Thread Sean Mullan
Hi Bernd, On 2/20/20 12:48 PM, Bernd Eckenfels wrote: Hello Sean, Are the separate entries for 3DES and DES needed or can they also be collapsed? DES will not match 3DES if that's what you mean, so yes the separate entries are needed. BTW i am always unsre about the interactions of settin

Re: RFR 8237218: Support NIST Curves verification in java implementation

2020-02-20 Thread Anthony Scarpino
I'm ok with this update Tony On 2/19/20 5:35 AM, Weijun Wang wrote: New webrev at http://cr.openjdk.java.net/~weijun/8237218/webrev.04/ Only test change. For each signature, modify it a little and check if verify fails. Thanks, Max On Feb 18, 2020, at 2:09 AM, Anthony Scarpino wrote:

Re: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS

2020-02-20 Thread Weijun Wang
> On Feb 21, 2020, at 2:44 AM, Michael Osipov <[email protected]> wrote: > > Has there been any progress on this? No. There might be some performance impact. Also, we thought about embedding the certs inside JDK code. Users can still add their own trusted CA cert to the cacerts file, but t

Re: RFR 8160818: GssKrb5Client violates RFC 4752

2020-02-20 Thread Weijun Wang
> On Feb 21, 2020, at 2:41 AM, Michael Osipov <[email protected]> wrote: > > Am 2020-02-20 um 03:57 schrieb Weijun Wang:> Ping again. > > > >> On Feb 14, 2020, at 10:51 PM, Weijun Wang > wrote: > >> > >> > >> > >>> On Feb 14, 2020, at 9:42 PM, Michael Osipov <[email protected]> wrote: > >>>