RFR 8133910: Some sun/security/tools tests failed.

Please review the fix at http://cr.openjdk.java.net/~weijun/8133910/webrev.00/ Basically, "-J-Duser.language=en -J-Duser.country=US" is added to keytool and jarsigner calls wherever output needs to be compared to some English text. *Siba*: I modified quite some tests by you. Please confirm it

Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"

DeprivilegedModuleLoaderTest.java looks good to me. I am not sure why you picked those 2 javax.xml.crypto tests. Have they have covered the common functions? I'll let someone else to judge it. BTW, I would prefer "java.security.policy==test.policy" (or just policy=test.policy) to "java.security

[jdk9] RFR: 8153438: Avoid repeated "Please insert a smart card" popup windows

Hello! In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step. Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently). Would you please

Re: JDK-8152524

Hi Sheon, only see your mail now. The issue turned out to be a McAfee issue. They issued a new patch. You'll have to contact them. Regards, Sean. On 13/07/2016 23:57, sheon banks wrote: Hi All, This message is actually for Sean Coffey in relation to the JDK-8152524. I saw the incident on

Re: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on solaris12(sparcv9 and x86)

Is there any way to split the Ucrypto MessageDigest implementation into 2 classes, one that implements Cloneable and the other which doesn't, and use the appropriate one depending on which OS version you are on? This way, instead of calling clone and catching CloneNotSupportedException, you co

RFR 8163489: Avoid using Utils.getFreePort() in TsacertOptionTest.java test

http://cr.openjdk.java.net/~weijun/8163489/webrev.00

Re: RFR 8133910: Some sun/security/tools tests failed.

I was wrong. The test were written by Artem. --Max On 8/9/2016 15:37, Wang Weijun wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8133910/webrev.00/ Basically, "-J-Duser.language=en -J-Duser.country=US" is added to keytool and jarsigner calls wherever output needs to be

Re: RFR 8163489: Avoid using Utils.getFreePort() in TsacertOptionTest.java test

On 9 Aug 2016, at 16:37, Weijun Wang wrote: > > http://cr.openjdk.java.net/~weijun/8163489/webrev.00 Thanks Max, this looks good( one less use of the get free port anti-pattern! ). -Chris.

Re: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on solaris12(sparcv9 and x86)

Or better yet, just change the ucrypto impl to not implement Cloneable regardless what Solaris version you are on. Then you can just check each MessageDigest impl to see if it is an instanceof Cloneable rather than calling clone on each. --Sean On 08/09/2016 09:38 AM, Sean Mullan wrote: Is t

Re: RFR 8163489: Avoid using Utils.getFreePort() in TsacertOptionTest.java test

+1 Minor: no need a semicolon in "try" block, I originally added it by mistake. You also may want to update a copyright year. Artem On 08/09/2016 08:46 AM, Chris Hegarty wrote: On 9 Aug 2016, at 16:37, Weijun Wang wrote: http://cr.openjdk.java.net/~weijun/8163489/webrev.00 Thanks Max, th

Re: RFR 8133910: Some sun/security/tools tests failed.

Hi Max, The update looks good to me. Artem On 08/09/2016 08:39 AM, Weijun Wang wrote: I was wrong. The test were written by Artem. --Max On 8/9/2016 15:37, Wang Weijun wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8133910/webrev.00/ Basically, "-J-Duser.language=en

[9] RFR 8163503: PKCS12 keystore cannot store non-X.509 certificates

Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore. The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects. This fix rejects attempts to store non-X.509 certif

Re: RFR 8162739: Create new keytool option to access cacerts file

- src/java.base/share/classes/sun/security/tools/keytool/Resources.java 131 "operates on the cacerts keystore"}, // -cacerts "operates" sounds a little odd. How about "access the cacerts keystore" (so it is consistent with the warning below). 133 "Warning: use

Re: [Update] RFR 8132943: ServerHandshaker may select non-empty OCSPStatusRequest structures when Responder ID selection is not supported

Looks fine to me. Thanks, Xuelei On 8/9/2016 5:50 AM, Jamil Nimeh wrote: > Hello all, this update removes an unnecessary change in > test/javax/net/ssl, adds in some additional logging, and an early exit > condition from the loop if an acceptable status_request_v2 item is found > (favoring OCSP_M

Re: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on solaris12(sparcv9 and x86)

Thanks for the review~ Your point is valid for default configuration. But in the rare case where the new jdk.security.provider.preferred property is set, the most preferred provider may not be the one which supplied the digest object for the generic getInstance() call. So, instead of removin

Re: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509 certificates

I thought I've seen this webrev before. Why not just throw a KeyStoreException in validateChain()? --Max On 8/10/2016 2:14, Vincent Ryan wrote: Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore. The PKCS12 keystore implementatio

Re: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509 certificates

The for loop at line 1507 and 1520 may be merged together. Xuelei On 8/10/2016 8:38 AM, Weijun Wang wrote: > I thought I've seen this webrev before. > > Why not just throw a KeyStoreException in validateChain()? > > --Max > > On 8/10/2016 2:14, Vincent Ryan wrote: >> Please review this fix to

Re: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on solaris12(sparcv9 and x86)

OracleUcrypto provider already separates them in two classes: The cloneable libMD digest impls are encapsulated by a class which implements Cloneable and the new un-cloneable Ucrypto digest impls are in a class which does not. I wasn't sure if we can safely assume that an instance supports clo

Re: 8163104: Unexpected NPE still possible on some Kerberos ticket calls

Change looks fine. Sorry for the late reply. Thanks Max On 8/5/2016 22:25, Seán Coffey wrote: Post JDK-8147772 , I think we still have a possibility of hitting an NPE in Kerberos ticket management. Could only find one method affected. bug repor