Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

The test can also report which providers it is testing and/or skipping, so that anyone checking the .jtr file can verify the behavior. Maybe it fails if expected modules or providers are not found. -- Jon On 06/29/2016 10:50 AM, Mandy Chung wrote: Valerie’s suggestion is a good one. The

Re: [9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail

Should engineSetKeyEntry make the same check? --Max > On Jul 2, 2016, at 5:52 AM, Vincent Ryan wrote: > > Please review this change to correct two failing JCK tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068290 > Webrev:

[9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail

Please review this change to correct two failing JCK tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8068290 Webrev: http://cr.openjdk.java.net/~vinnie/8068290/webrev.00/ PKCS12 is the default keystore type in JDK 9 and its implementation stores only X.509 certificates although the

Re: [9] RFR 8136459: MessageDigest.isEqual is not a "simple byte compare"

Looks fine. --Sean On 07/01/2016 05:32 PM, Valerie Peng wrote: Sean, Do you have one minute to spare for this trivial javadoc update? Can you please take a look at the CCC too? I plan to fast track it once you reviewed it. Bug: https://bugs.openjdk.java.net/browse/JDK-8136459 Webrev:

[9] RFR 8136459: MessageDigest.isEqual is not a "simple byte compare"

Sean, Do you have one minute to spare for this trivial javadoc update? Can you please take a look at the CCC too? I plan to fast track it once you reviewed it. Bug: https://bugs.openjdk.java.net/browse/JDK-8136459 Webrev: http://cr.openjdk.java.net/~valeriep/8136459/webrev.00/ Thanks,

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

Mystery solved. Didn't notice that. :P Valerie On 6/30/2016 7:00 PM, Wang Weijun wrote: On Jul 1, 2016, at 9:16 AM, Valerie Peng wrote: Weird, I still see -provider on the link below.

Re: RFR: 8159180 Remove default setting for jdk.security.provider.preferred

Thanks Tony On 06/29/2016 05:16 PM, Xuelei Fan wrote: Looks fine to me. Thanks, Xuelei On 6/30/2016 2:50 AM, Anthony Scarpino wrote: Hi, I need a review of this simple change to to undo the default settings for the jdk.security.provider.preferred. The only code changes are test related.

Re: RFR: 8154015 Apply algorithm constraints to timestamped code

On 07/01/2016 12:39 PM, Sean Mullan wrote: Looks good, just one comment below ... On 06/30/2016 05:31 PM, Anthony Scarpino wrote: Unless otherwise specified below, it was accepted.. http://cr.openjdk.java.net/~ascarpino/8154015/webrev.02/ Tony PKIX.java: 107 this.params

Re: RFR: 8154015 Apply algorithm constraints to timestamped code

Looks good, just one comment below ... On 06/30/2016 05:31 PM, Anthony Scarpino wrote: Unless otherwise specified below, it was accepted.. http://cr.openjdk.java.net/~ascarpino/8154015/webrev.02/ Tony PKIX.java: 107 this.params = ((PKIXTimestampParameters)

Re: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true

On 07/01/2016 12:41 PM, Mandy Chung wrote: On Jul 1, 2016, at 5:31 AM, Sean Mullan wrote: Please review the changes for this RFE to mark the java.security.acl API with forRemoval=true. The intention is to remove this API in JDK 10. The APIs in java.security.acl were

Re: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true

> On Jul 1, 2016, at 5:31 AM, Sean Mullan wrote: > > Please review the changes for this RFE to mark the java.security.acl API with > forRemoval=true. The intention is to remove this API in JDK 10. > > The APIs in java.security.acl were deprecated in 1.9 but have had

Re: [9] RFR 8157667: sun/security/x509/URICertStore/ExtensionsWithLDAP.java has to be updated due to JDK-8134577

Ping again ;-) John Jiang On 2016/6/28 6:42, John Jiang wrote: Please review this patch. Thanks! John Jiang On 2016/6/24 16:55, John Jiang wrote: Hi, Due to JDK-8134577, the test sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve hosts from a local name service

Re: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true

Change looks fine. Thanks Max > On Jul 1, 2016, at 8:31 PM, Sean Mullan wrote: > > Please review the changes for this RFE to mark the java.security.acl API with > forRemoval=true. The intention is to remove this API in JDK 10. > > The APIs in java.security.acl were

RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true

Please review the changes for this RFE to mark the java.security.acl API with forRemoval=true. The intention is to remove this API in JDK 10. The APIs in java.security.acl were deprecated in 1.9 but have had the following warning in the package description for many releases: "The classes and

Re: RFR: 8157707: Deprecate the java.security.Certificate API with forRemoval=true

looks fine to me. Xuelei > On Jul 1, 2016, at 8:08 PM, Sean Mullan wrote: > > Please review the changes for this RFE to mark the java.security.Certificate > API with forRemoval=true. The intention is to remove this API in JDK 10. > > The java.security.Certificate API

RFR: 8157707: Deprecate the java.security.Certificate API with forRemoval=true

Please review the changes for this RFE to mark the java.security.Certificate API with forRemoval=true. The intention is to remove this API in JDK 10. The java.security.Certificate API has been deprecated since 1.2 and has been superseded by java.security.cert.Certificate and related classes