Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR

Before this change, you require default policy in neither export nor import to be empty but do not care about the getMinimum() result. In this change, you make sure the final result is not empty. I assume this is a fix? 283 // Did we find a default perms? What does this

Re: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey after RSA KeyPair Generation

Regression tests are still running, but thought that I will send the updated webrev out and see if there are more comments. Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/ Thanks, Valerie On 8/17/2016 9:55 AM, Michael StJohns wrote: On 8/16/2016 9:24 PM,

Re: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

If I recall correctly, there should be a way to specify a policy file in @run without overriding the default one. May be it is "@run main/othervm/java.security.policy=unbound.ssl.policy_new" Yes, I think this should work. I've also just learned about it and don't know from which jtreg it is

Re: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey after RSA KeyPair Generation

Thanks for the input. SunPKCS11 provider always generate RSA CRT keys if I recall correctly, so it's hard to test the non-CRT scenarios. Thus, I made the changes basing on the suggestions in the bug report. I will update the webrev accordingly. Valerie On 8/17/2016 9:55 AM, Michael StJohns

Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR

New webrev: https://bugs.openjdk.java.net/browse/JDK-8061842 http://cr.openjdk.java.net/~wetmore/8061842/webrev.01/ On 8/10/2016 11:19 AM, Sean Mullan wrote: Hi Brad, Looks pretty good. You should also send this to build-dev to review the Makefile changes. Just a few comments: -

Re: RFR: 8156192: Provider#compute and #merge methods expect wrong permission & #compute ClassCastException even with wrong permission.

Thanks Tony On 08/17/2016 01:47 PM, Sean Mullan wrote: Looks fine to me. --Sean On 08/17/2016 04:11 PM, Anthony Scarpino wrote: Hi, I need a simple review on fixing some cut-n-paste errors that the JCK tests found. I didn't include the tests because the functionality is covered by the JCK

Re: RFR: 8156192: Provider#compute and #merge methods expect wrong permission & #compute ClassCastException even with wrong permission.

Looks fine to me. --Sean On 08/17/2016 04:11 PM, Anthony Scarpino wrote: Hi, I need a simple review on fixing some cut-n-paste errors that the JCK tests found. I didn't include the tests because the functionality is covered by the JCK tests and I don't feel typos need a regression test.

RFR: 8156192: Provider#compute and #merge methods expect wrong permission & #compute ClassCastException even with wrong permission.

Hi, I need a simple review on fixing some cut-n-paste errors that the JCK tests found. I didn't include the tests because the functionality is covered by the JCK tests and I don't feel typos need a regression test. http://cr.openjdk.java.net/~ascarpino/8156192/webrev/ Tony

Re: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group

On 8/17/16 11:36 AM, Chris Hegarty wrote: On 17 Aug 2016, at 18:54, Rajan Halade wrote: sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group. Yes they are, but it is very important that anyone touching TLS verify

Re: [9] RFR 6877937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE.

Looks ok, probably better than the initial proposed fix from April 2014. Brad On 8/11/2016 4:55 AM, Vincent Ryan wrote: Please review this change to unpin the Mac implementation from the SunJCE provider. Since the Mac is a private field there are no issues regarding Clonable implementations

Re: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group

On 17 Aug 2016, at 18:54, Rajan Halade wrote: > > sun/net/www/protocol/https tests are redundant in jdk_security3 group, these > are included in jdk_net group. Yes they are, but it is very important that anyone touching TLS verify that HTTPS still works. If the jdk_net

[9] RFR: 8164100: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java fails with java.util.concurrent.TimeoutException

Hello, Please review the following patch for com/sun/crypto/provider/KeyFactory/TestProviderLeak.java test. This is a request to make the test take into account a test timeout factor. Timeout factor can be specified with "-timeout" jtreg's command line option. This option is used in some

RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group

sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group. Webrev: http://cr.openjdk.java.net/~rhalade/8164229/webrev.00/ Thanks, Rajan

Re: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

Sorry, my bad, I didn't notice '9-na' label. I suppose that code from ext directory should have all permissions: artem@artem-laptop:$ cat ~/jdk/jdk1.8.0_92b14/jre/lib/security/java.policy // Standard extensions get all permissions by default grant codeBase "file:${{java.ext.dirs}}/*" {

Re: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

Hi Sean, If I remember correctly, there is no ext directory in JDK 9 any more. I don't see in jtr file that "java.ext.dirs" system property is passed to the test. If I understand correctly, "file:${{java.ext.dirs}}/*" becomes "file:/*" which seems to grand all permissions to all the code. It

Re: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey after RSA KeyPair Generation

On 8/16/2016 9:24 PM, Valerie Peng wrote: Anyone has time to review a straightforward fix? The current PKCS11 code assume that if public exponent is available for RSA Private Key, then it's a RSA CRT key. However, not all vendor implementation works this way. Changing to a tighter check and

RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

A recently added test case lacks sufficient permissions to read a conf file when running with security manager. bug report : https://bugs.openjdk.java.net/browse/JDK-8162916 proposed patch : diff --git a/test/sun/security/krb5/auto/unbound.ssl.policy

Re: RFR: 8164071: Default.policy file missing content for solaris

On 2016-08-17 18:43, Sean Mullan wrote: On 8/17/2016 12:33 PM, Erik Joelsson wrote: Hello Sean, The change looks ok, but it could also be expressed like this to avoid duplication: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) DEF_POLICY_SRC_LIST +=

Re: RFR: 8164071: Default.policy file missing content for solaris

On 8/17/2016 12:33 PM, Erik Joelsson wrote: Hello Sean, The change looks ok, but it could also be expressed like this to avoid duplication: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) DEF_POLICY_SRC_LIST +=

Re: RFR: 8163126 Wrong @modules in some of jdk/* tests

Thank you! Fixed in place: http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/test/jdk/security/jarsigner/Spec.java.sdiff.html Shura > On Aug 16, 2016, at 6:48 PM, Wang Weijun wrote: > > >> On Aug 17, 2016, at 9:26 AM, Alexandre (Shura) Iline >>

Re: RFR: 8164071: Default.policy file missing content for solaris

Hello Sean, The change looks ok, but it could also be expressed like this to avoid duplication: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) DEF_POLICY_SRC_LIST += $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy endif /Erik On 2016-08-17 18:18,

RFR: 8164071: Default.policy file missing content for solaris

Please review this simple fix to append the solaris default.policy file to the overall default.policy file. Bug: https://bugs.openjdk.java.net/browse/JDK-8164071 diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk --- a/make/copy/Copy-java.base.gmk Wed Aug 17 10:08:18 2016 +0800 +++