Is there anything else I can do to have anyone look into this?
I just want to make sure this does not fall through before the final JDK 12
release is done.
Bye
Norman
> On 4. Mar 2019, at 21:15, Norman Maurer wrote:
>
> Any comments here ?
>
> Bye
> Norman
>
>
>> On 28. Feb 2019, at 09:
On 3/12/2019 7:57 PM, Valerie Peng wrote:
Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8220549
I added myself as reviewer.
Webrev updated in place for this new approach:
http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
It looks fine to me.
Xuelei
I changed th
The change looks fine.
--Max
> On Mar 13, 2019, at 2:14 AM, Xuelei Fan wrote:
>
> Hi,
>
> Could I get the following update reviewed?
> http://cr.openjdk.java.net/~xuelei/8160247/webrev.00/
>
> The javax.security.cert API has been deprecated. The classes in this package
> should no longer b
Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8220549
Webrev updated in place for this new approach:
http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
I changed the synopsis to clarify that we are now removing these
duplicated RSA support.
Thanks,
Valerie
On 3/
Hi,
I'd like to propose a fix for JDK-8220513 [1]:
* http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.00/
Testing:
* No regressions found in sun/security/pkcs11
* This bug was exposed by TestTLS12 test, in jdk11u [2]. I'm working in
re-introducing this test to JDK (after JD
Hi,
There is an issue that I'd like to bring here for discussion.
I've been trying to reproduce a purely-OpenJDK TLS 1.2 exchange between
a client and server using SunPKCS11 crypto provider -with NSS software
token configured in FIPS mode-, after JDK-8217835 change [1].
My 1st preference crypto
Hello all,
Please review the CSR for the behavioral change to SunJCE's PBKDF2
implementaion. This change will make the underlying Mac also come from
SunJCE. This change only affects the SunJCE implementation of PBKDF2,
not any other implementation from any different provider.
https://bugs.
Looks fine to me.
--Sean
On 3/11/19 6:31 AM, Weijun Wang wrote:
Hi Jon,
Please take a look at the patch below.
*diff --git
a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java
b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java*
*---
a/src/j
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8160247/webrev.00/
The javax.security.cert API has been deprecated. The classes in this
package should no longer be used. In the changeset, the
"forRemoval=true" was added to the Deprecated annotation of the
On 3/12/19 1:12 PM, Xuelei Fan wrote:
On 3/12/2019 6:05 AM, Sean Mullan wrote:
Looks good, but a couple of comments:
In the Solution section, it says: "Applications can change the
behavior with the existing SSLParameters.setUseCipherSuitesOrder()
method."
I think you should be more clear t
On 3/12/2019 6:05 AM, Sean Mullan wrote:
Looks good, but a couple of comments:
In the Solution section, it says: "Applications can change the behavior
with the existing SSLParameters.setUseCipherSuitesOrder() method."
I think you should be more clear that this means applications can change
Looks good, but a couple of comments:
In the Solution section, it says: "Applications can change the behavior
with the existing SSLParameters.setUseCipherSuitesOrder() method."
I think you should be more clear that this means applications can change
the order of the server's preferred cipher
Adding security-dev as reviews should happen on the corresponding area
lists. Even for 8.
On Mon, 2019-03-11 at 07:50 +, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/
This looks OK to
13 matches
Mail list logo
