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

How about letting validateChain() throw a KeyStoreException directly? --Max > On Jul 6, 2016, at 2:44 AM, Vincent Ryan wrote: > > I’ve updated the webrev to also check for X509Certificate in both > engineSetKeyEntry methods and in engineSetEntry: > http://cr.openjdk.java.net/~vinnie/8068290/w

Re: Strange test failure when referencing a class in a deprivileged module

On 7/5/2016 23:50, Mandy Chung wrote: Max - are you running the test with exploded image (see JDK-8155858 [1])? No. The test also fails with recent promoted builds (ever since java.sql is de-priveleged). --Max

Re: [9] RFR 8135114: sun/security/krb5/auto tests failed for tr locale.

Looks like safe update to me. Thanks, Xuelei On 7/6/2016 3:28 AM, Artem Kosarev wrote: > Could you please review the proposed fix for regression tests > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8135114 > WEBREV: > http://cr.open

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

> On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline > wrote: > > >> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: >> >> >>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline >>> wrote: >>> >>> This made sense, than you, Mandy. >>> >>> Please review new version: >>> http://cr.openj

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

Pleas review the new version of the fix. http://cr.openjdk.java.net/~shurailine/8158670/webrev.01/ I have executed the changed test successfully on linux, windows, mac os x and solaris. Shura > On Jun 29, 2016, at 10:43 AM, Alexandre (Shura) Iline > wrote: > > >> On Jun 29, 2016, at 10:41 A

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

> On Jul 1, 2016, at 6:20 PM, Alexandre (Shura) Iline > wrote: > > Pleas review the new version of the fix. > http://cr.openjdk.java.net/~shurailine/8158670/webrev.01/ > > I have executed the changed test successfully on linux, windows, mac os x and > solaris. I have also executed it manuall

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

> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: > > >> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline >> wrote: >> >> This made sense, than you, Mandy. >> >> Please review new version: >> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ > > You can use Layer::findModule ins

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

This made sense, than you, Mandy. Please review new version: http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ Shura > On Jul 2, 2016, at 3:26 PM, Mandy Chung wrote: > > >> On Jul 1, 2016, at 6:20 PM, Alexandre (Shura) Iline >> wrote: >> >> Please review the new version of the fix.

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

Jon, > On Jul 1, 2016, at 6:44 PM, Jonathan Gibbons > wrote: > > The test can also report which providers it is testing and/or skipping, so > that anyone checking the .jtr file can verify the behavior. I have added some debug output, pls take a look. http://cr.openjdk.java.net/~shurailine/815

Re: Questions on deprivileging a module

The other solution is to use a VarHandle instead of Unsafe for setting the final field, i don't think that letting unprivileged module to access to Unsafe is a good idea. cheers, Rémi - Mail original - > De: "Alan Bateman" > À: "Wang Weijun" > Cc: "jigsaw-dev" , "OpenJDK" > > Envoyé

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

> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline > wrote: > > This made sense, than you, Mandy. > > Please review new version: > http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ You can use Layer::findModule instead of Configuration::findModule. You can also use List::equals.

[9] RFR 8135114: sun/security/krb5/auto tests failed for tr locale.

Could you please review the proposed fix for regression tests BUGURL: https://bugs.openjdk.java.net/browse/JDK-8135114 WEBREV: http://cr.openjdk.java.net/~akosarev/8135114/webrev.00 DESCRIPTION: **toLowerCase & toUpperCase methods were

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

I’ve updated the webrev to also check for X509Certificate in both engineSetKeyEntry methods and in engineSetEntry: http://cr.openjdk.java.net/~vinnie/8068290/webrev.01/ > On 4 Jul 2016, at 10:25, Vincent Ryan wrote: > > Good catch Max. I’ll add the check there too. > > >> On 2 Jul 2016, at

Re: RFR 8158589: Possible integer overflow issues for DRBG

Looks fine, just a couple of typos: - HashDrbg.java 84 * Note: In each current calle, requested is seedLen, therefore small, s/calle/call/ - CtrDrbg.java 399 "entropy plus additonal input is too long"); s/additonal/additional/ --Sean On 06/16/2016 10:00 P

Re: Strange test failure when referencing a class in a deprivileged module

> On Jul 5, 2016, at 8:11 AM, Alan Bateman wrote: > > On 05/07/2016 09:22, Wang Weijun wrote: > >>> On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: >>> >>> The exception is at the end of this mail. The test passes if I change >>> X.go() to calling a method inside this class >> Update: any ca

Re: Strange test failure when referencing a class in a deprivileged module

On 05/07/2016 09:22, Wang Weijun wrote: On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class Update: any call that triggers a permission check will do. For example: Yes, tricky iss

Re: Questions on deprivileging a module

> On Jul 5, 2016, at 12:15 AM, Wang Weijun wrote: > >>> 1. How does updating /make/common/Modules.gmk affect an exploded build? >> The mappings are used for both exploded and images build so the >> configuration in this make file is for both. > > I see. BTW, which file contain the mappings? I

[9] RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]"

Hi, Please review the patch for "8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]"" JBS: https://bugs.openjdk.java.net/browse/JDK-8079441 Webrev: http://cr.openjdk.java.net/~ssahoo/8079441/webrev.00/ Description: This is a rare failure

Re: [9] RFR: 8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly"

You may also want to dump the SSL record so that we can analysis the record directly. -Djavax.net.debug=ssl,handshake,record This update does not actually address the potential problem. Please file a new bug for this update, and keep this bug open so that the issue can be tracked. Thanks, X

[9] RFR: JDK-7052815 Finish checking of 7052537

Hi , Please help to review the path for "JDK-7052815 :Finish checking of 7052537" . A few test are using removedProvider() to removed the security provider,like JDK-7052537, If the tests not in othervm,it will affect other tests. Checking tests which are using removedProvider() for security

[9] RFR: 8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly"

Hi, Please review the patch for "8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly"" JBS: https://bugs.openjdk.java.net/browse/JDK-8160210 Webrev: http://cr.openjdk.java.net/~ssahoo/8160210/webrev.00/ Description: This is a rare failur

Re: [9] RFR:8160333:Remove intermittent key from javax/net/ssl/TLSv12/ShortRSAKey512.java

looks fine to me. Xuelei > On Jul 5, 2016, at 2:45 PM, Tim Du wrote: > > Hi, > > Please help to review the path for javax/net/ssl/TLSv12/ShortRSAKey512.java , > JDK-8159501 has been fixed, and no bug is tracking issue on this test, @key > intermittent can be removed.Thanks. > > JBS: https:/

Re: Strange test failure when referencing a class in a deprivileged module

> On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: > > The exception is at the end of this mail. The test passes if I change X.go() > to calling a method inside this class Update: any call that triggers a permission check will do. For example: import java.security.Permission; import java.sql.

Re: Questions on deprivileging a module

On 05/07/2016 09:03, Remi Forax wrote: The other solution is to use a VarHandle instead of Unsafe for setting the final field, i don't think that letting unprivileged module to access to Unsafe is a good idea. Very true, I wasn't paying attending to why it is using Unsafe in the first place.

Re: Questions on deprivileging a module

On 05/07/2016 08:15, Wang Weijun wrote: : It's a runtime error. @CallerSensitive public static Unsafe getUnsafe() { Class caller = Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(caller.getClassLoader())) throw new SecurityException("Unsafe"); << The exception t

Re: Questions on deprivileging a module

> On Jul 5, 2016, at 2:52 PM, Alan Bateman wrote: > > On 04/07/2016 07:03, Wang Weijun wrote: > >> I am working on >> >>JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and >> jdk.security.auth >>https://bugs.openjdk.java.net/browse/JDK-8159528 >> >> Several questions: >