Re: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred

Why does the test have a 2009,2011 copyright? Otherwise, looks ok to me. --Sean On 07/07/2014 10:12 PM, Wang Weijun wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8048194/webrev.00 The original code goes on accepting the input mechToken even if it's of an unsu

Re: RFR 8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred

ither TO or CC. On Jul 21, 2014, at 19:12, Sean Mullan wrote: Why does the test have a 2009,2011 copyright? Otherwise, looks ok to me. I copied a test nearby and modified it into the new test. Will fix. Thanks Max --Sean On 07/07/2014 10:12 PM, Wang Weijun wrote: Please review the cod

Re: RFR 8049834: Two security tools tests do not run with only JRE

This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some regression tests with just the JRE instead of the full JDK? --Sean On 07/21/2014 07:12 AM, Wang Weijun wrote: Ping again. On Jul 10, 2014, at 16:36, Wang Weijun wrote: Hi All Please

Re: RFR 8049834: Two security tools tests do not run with only JRE

On 07/21/2014 08:19 AM, Wang Weijun wrote: On Jul 21, 2014, at 20:11, Sean Mullan wrote: This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some regression tests with just the JRE instead of the full JDK? The embedded team has the

Re: Policy provider comparison

Hi Peter, This list of optimizations looks very useful - thank you for sending more details! I am going to spend some time thinking about your suggestions in more detail and how they apply to the OpenJDK JavaPolicy provider and will get back to you with any further questions ... --Sean On 0

Re: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider

Can you also change the following comment in sun/security/ssl/SupportedEllipticCurvesExtension.java: // See sun.security.ec.NamedCurve for the OIDs to // See sun.security.util.NamedCurve for the OIDs Rest looks good to me. Please add a noreg label though. --Sean On 07/18/2014 01:13

Re: RFR 8049834: Two security tools tests do not run with only JRE

On 07/21/2014 09:41 AM, Wang Weijun wrote: On Jul 21, 2014, at 20:24, Sean Mullan wrote: On 07/21/2014 08:19 AM, Wang Weijun wrote: On Jul 21, 2014, at 20:11, Sean Mullan wrote: This looks fine to me, but I was wondering why you needed to do this - are there requirements to run some

Re: [9] RFR 8035166: Remove dependency on EC classes from pkcs11 provider

Looks good. --Sean On 07/21/2014 06:33 PM, Valerie Peng wrote: Done, webrev updated at http://cr.openjdk.java.net/~valeriep/8035166/webrev.01/ Thanks, Valerie On 7/21/2014 11:18 AM, Sean Mullan wrote: Can you also change the following comment in sun/security/ssl

RFR: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode

This is a fix for a test that was on the problem list. The fix is simple, I just changed the test to run in othervm mode, it was failing due to a classloader issue running in agentvm mode. Was able to get a clean jprt run on all systems. http://cr.openjdk.java.net/~mullan/webrevs/7147060/webre

Re: RFR: 8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux

Looks fine to me. --Sean On 07/22/2014 01:44 PM, Rob McKenna wrote: Hi folks, When repeatedly gathering small amounts of random data the SUN provider is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto / pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to

Re: RFR 8051953: Add Unreachable.java test to ProblemList on Windows

On 07/24/2014 09:51 PM, Wang Weijun wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html which add one item into test/ProblemList.txt +# 8051952: Unreachable.java test failing on Windows +sun/security/krb5/auto/Unreac

Re: RFR 8051953: Add Unreachable.java test to ProblemList on Windows

On 07/25/2014 07:29 AM, Wang Weijun wrote: On Jul 25, 2014, at 19:20, Sean Mullan wrote: On 07/24/2014 09:51 PM, Wang Weijun wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8051953/webrev.00/test/ProblemList.txt.udiff.html which add one item into test

Re: RFR 6997010: Consolidate java.security files into one file with modifications

On 07/22/2014 10:28 PM, Wang Weijun wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ The fix consolidates java.security- files into one with #ifdef directives. There are several major changes: 1. Creation of file is moved from CopyFiles to Generat

Re: Policy provider comparison

On 07/19/2014 10:06 PM, Peter Firmstone wrote: There doesn't seem to be much interest in adopting an external policy provider, so I'll explain how to achieve a significant performance improvement, in case someone's interested in improving performance of the default jvm policy provider. 1. Thr

Re: java.security.DigestInputStream does not implement skip(long)

On 08/01/2014 06:06 AM, Florian Weimer wrote: I noticed that the implementation of DigestInputStream does not feed skipped-over bytes to the message digest. The specification is silent on this, and I'm not sure if this a specification deficiency or an implementation bug. Yes, this is a known i

Re: [9] request for review 8051972: sun/security/pkcs11/ec/ReadCertificates.java fails intermittently

Looks good. Please add a noreg label (noreg-self probably). Also, the subcomponent should probably be javax.security:pkcs11 --Sean On 07/29/2014 11:02 AM, Vincent Ryan wrote: Please review this simple fix to eliminate an intermittent test failure. Bug: https://bugs.openjdk.java.net/browse/JDK

Re: apple.security.KeychainStore does not load private key (when called from javaws)

On 08/04/2014 11:10 AM, Florian Bruckner (3kraft) wrote: Hey guys, any feedback/comments on this? This seems like a reasonable change to me. In order to proceed with accepting your patch, you will first need to sign an OCA. See step 0 of http://openjdk.java.net/contribute/ Thanks, Sean

Re: RFR 6997010: Consolidate java.security files into one file with modifications

n wrote: On Jul 25, 2014, at 22:30, Sean Mullan wrote: http://cr.openjdk.java.net/~weijun/6997010/webrev.00/ 4. *IMPORTANT*: In order to easily maintain platform-related entries, every line (including the last line) in package.access and package.definition MUST end with ',\' no

Re: [9] RFR: 8054380: X.509 cert extension SubjectAltName should allow digits as first character of dNSName

On 08/07/2014 08:47 AM, Florian Weimer wrote: I wonder why using the HTTPS to access works with the current jdk9-dev code. The name "www.3com.com" is only present in the SAN. Is the SAN extension non-critical? If so, that could explain why. We allow X509Certificates to

Re: RFR 8054366: Broken link in SecureRandom.html

On 08/07/2014 05:03 PM, Jamil Nimeh wrote: Hello all, This is just a quick broken-link fix for SecureRandom's javadoc. http://cr.openjdk.java.net/~ascarpino/8054366/webrev.01 The fix for the broken link looks fine. I think you should double-check with Brad as to whether changing the RFC refe

Review Request for 7026255 : Methods of Subject that throw SecurityException do not specify what permissions are required

This is a clarification in the javax.security.auth.Subject javadocs to indicate what permissions are required for methods that throw SecurityException: http://cr.openjdk.java.net/~mullan/webrevs/7026255/webrev.00/ I also took the opportunity to fix a couple of other minor issues: added @Overr

Re: Review Request for 7026255 : Methods of Subject that throw SecurityException do not specify what permissions are required

ile in that case. I don't think there are any major benefits switching to an enum here, but I did add the final keyword to the class. Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/7026255/webrev.01/ Thanks, Sean Otherwise, looks fine to me. Xuelei On 8/12/2014 11:08 PM,

JEP Review Request: Improve Security Manager Performance

Hello all, I have submitted a JEP for "Improve Security Manager Performance" that I am seeking further review and feedback: https://bugs.openjdk.java.net/browse/JDK-8043631 This is very similar to a draft I posted earlier [1], but has been re-drafted using the JEP 2.0 process. The JEP is i

Re: Review Request for 7026255 : Methods of Subject that throw SecurityException do not specify what permissions are required

On 08/14/2014 10:49 AM, Xuelei Fan wrote: I meant to pointed out the modification permissions as well. As update to the returned value needs the related permissions as the following line talked about: 149 * To modify the Principals Set, the caller must have 150 * {@code AuthPermi

Re: RFR 8048052: Permission tests for "setFactory"

On 07/28/2014 05:04 AM, FELIX YANG wrote: Please review a new test to "setFactory" permission. It is to address that "setFactory" permission is required or not as expected in a series of classes/methods under java.net. JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048052 Webrev: http://cr

Re: RFR 8054817: File ccache only recognizes Linux and Solaris defaults

Looks fine to me. Do you still need to import java.lang.reflect.* though? --Sean On 08/11/2014 10:14 AM, Wang Weijun wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8054817/webrev.00 since we have a new getuid() now for all Unix systems. It does return -1 on Windows, b

Re: RFR 8055373: Typo in InquireType.java

Looks good. --Sean On 08/19/2014 04:59 AM, Wang Weijun wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8055373/webrev.00/ Just a typo. I have no idea how I wrote that wrong class name. Thanks Max

Re: RFR J8050281: New permission tests for JEP 140

On 08/06/2014 06:25 PM, Amanda Jiang wrote: Sorry, wrong webrev link, it should be: http://cr.openjdk.java.net/~tyan/amandaj/8050281/webrev.01/ Mostly looks good, just a few comments: * NullPerms I suggest renaming this test to LimitedDoPrivilegedWithNullPerms [27-28] Suggest rewording as: "

Re: [9] request for review: 8048512: Uninitialised memory in jdk/src/share/native/sun/security/ec/ECC_JNI.cpp

Looks fine to me. --Sean On 08/13/2014 11:28 AM, Vincent Ryan wrote: Hello, Please review this fix to cleanup ECC native code. When returning early from two methods, some data structures do not get initialized before use. This fix initializes those structs explicitly. Thanks. Bug: https://

Re: [8u] RFR 8054817: File ccache only recognizes Linux and Solaris defaults

Looks fine to me. --Sean On 08/19/2014 10:59 PM, Wang Weijun wrote: Please review the fix for the same bug for jdk8u-dev: http://cr.openjdk.java.net/~weijun/8054817/8u/webrev.00/ We don't have sun.misc.VM.getuid() in jdk8 so the fix is even simpler. The test is identical though. Thanks M

Re: RFR 8048052: Permission tests for "setFactory"

The updated webrev looks fine. However I do have a general comment. There are other methods that require a permission to be granted in order to invoke them. It may make more sense to create a very general test that can be used to test all of these methods, or perhaps subclassed or overridden

Re: [9] RFR: 8054380: X.509 cert extension SubjectAltName should allow digits as first character of dNSName

a component ends in a digit or letter (RFC 952 grammar rules) Thanks, Jason On 08/08/2014 01:59 AM, Florian Weimer wrote: On 08/07/2014 03:32 PM, Sean Mullan wrote: On 08/07/2014 08:47 AM, Florian Weimer wrote: I wonder why using the HTTPS to access <https://www.3com.com> works with the curr

Re: [9] RFR: 8054380: X.509 cert extension SubjectAltName should allow digits as first character of dNSName

On 08/25/2014 04:05 PM, Jason Uh wrote: On 08/25/2014 03:41 PM, Sean Mullan wrote: Just a couple of comments: 1. I think the check on lines 106-110 can be done prior to the for loop on line 94 I think that check is actually where it should be because the for loop on line 94 loops over each

Re: [9] RFR: 8054380: X.509 cert extension SubjectAltName should allow digits as first character of dNSName

Looks good. --Sean On 08/25/2014 04:44 PM, Jason Uh wrote: On 08/25/2014 04:14 PM, Sean Mullan wrote: On 08/25/2014 04:05 PM, Jason Uh wrote: On 08/25/2014 03:41 PM, Sean Mullan wrote: Just a couple of comments: 1. I think the check on lines 106-110 can be done prior to the for loop on

Re: Request for review : 8054817: File ccache only recognizes Linux and Solaris defaults

Looks fine to me. --Sean On 09/02/2014 05:55 AM, mala bankal wrote: HI Max, All, Request to review the changes for the backport of 8054817 to jdk7u-dev. webrev : http://cr.openjdk.java.net/~mbankal/8054817/webrev.00/ JDK9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec98f141c757 J

Re: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509

That seems fine to me. While you are in there, it would also be nice to fix the grammar of the exception message, ex: "public key format is " + publicKey.getFormat() + ", must be X.509/X509"); and open another bug to correct that in JDK 9. Thanks, Sean On 09/02/2014 11:52 AM, Seán Coffey wrot

Re: RFR (XS) : 8057076 : Correct exception message in CertAndKeyGen.java

Looks good. --Sean On 09/02/2014 02:47 PM, Seán Coffey wrote: https://bugs.openjdk.java.net/browse/JDK-8057076 As per earlier discussion today, a simple update to the exception message used in JDK 9. diff --git a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java b/src/

Re: RFR(XXS) : 8057813: Alterations to jdk_security3 test target

This seems like a good idea to me. Looks ok to me. --Sean On 09/09/2014 01:10 PM, Seán Coffey wrote: On some recent JPRT test jobs, I've noticed that the jdk_security3 test target is taking 40+ mins on some systems. Looking closer at test times, I see that sun/security/krb5 tests alone can take

Re: RFR(XXS) : 8057813: Alterations to jdk_security3 test target

On 09/10/2014 11:09 AM, Wang Weijun wrote: The change looks good. Ditto. --Sean Thanks Max On Sep 10, 2014, at 20:02, Seán Coffey wrote: Sounds reasonable Max. I've made those changes and sec3 and sec4 test groups seem to be averaging out to ~15 mins each now. http://cr.openjdk.java.n

Re: [9] RFR: 8047223: Add algorithm parameter to EncodedKeySpec class and its two subclasses

On line 83 of EncodedKeySpec, call algorithm.isEmpty() instead. Looks good otherwise. --Sean On 09/10/2014 07:14 PM, Jason Uh wrote: Please review this change, which adds a constructor taking an algorithm name parameter to EncodedKeySpec and its subclasses. This allows the algorithm name to be

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

Can you also add similar log messages for MessageDigest, SecureRandom, and KeyStore? Otherwise looks good. Please add a noreg label. Also the fix is helpful to any platform and not just solaris/sparc so you should change those fields to be generic. --Sean On 09/12/2014 11:11 AM, Vincent Rya

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

eystore type so the JCE provider which has been selected is obvious. I’ll add support for KeyStore. Ok. I think it would be primarily useful to see the KeyStore when PKCS11 is used with unextractable keys to help debug any subsequent delayed provider selection. --Sean On 15 Sep 2014, at 16:

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

debug=provider:engine=MessageDigest,Signature and use the following to trace all supported engines: -Djava.security.debug=provider or -Djava.security.debug=all On 15/09/2014 16:57, Vincent Ryan wrote: On 15 Sep 2014, at 16:50, Sean Mullan wrote: On 09/15/2014 11:34 AM, Vincent

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

ngine=") && !Debug.isOn(“XXX”); Updated webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.02/ Docs bug: https://bugs.openjdk.java.net/browse/JDK-8058624 On 16 Sep 2014, at 22:07, Sean Mullan mailto:sean.mul...@oracle.com>> wrote: On 09/16/2014 11:27 AM, Vincent Ryan

Re: RFR: 8057813: Alterations to jdk_security3 test target

On 09/18/2014 10:52 AM, Seán Coffey wrote: Continuation of the security test target clean up for jdk7u. 7u doesn't have the test groups concept so I had to break down some test targets to explicit directory names. Also found that the javax/xml/crypto was missing for 7u testing. Good catch, loo

Re: TLS extensions API, ALPN and HTTP 2.0

On 09/17/2014 01:18 PM, Simone Bordet wrote: For the server to differentiate between those 2 connections he would need the SNI information, which I don't think it's currently available in JDK 8, right ? No. It is. We added support for SNI in JDK 8. See: http://docs.oracle.com/javase/8/docs/tec

Re: RFR (XS) : 8031191 Warning exception when XMLSignature logging is enabled

Also looks fine to me. --Sean On 10/02/2014 06:25 AM, Chris Hegarty wrote: On 2 Oct 2014, at 06:00, Seán Coffey wrote: Simple fix to the issue reported in the bug report. I've moved the logging calls past the 'sa.initVerify(pk);" call. bug : https://bugs.openjdk.java.net/browse/JDK-8031191

Re: [9] Request for review: 8041740: Test sun/security/tools/keytool/ListKeychainStore.sh fails on Mac

Looks fine to me. --Sean On 10/02/2014 09:45 AM, Vincent Ryan wrote: Please review this fix to a test for KeychainStore keystores on Mac OSX. It adjusts the keychain search order to include the temporary keychain created by this test. Bug: https://bugs.openjdk.java.net/browse/JDK-8041740 Webb

Re: [9] RFR: 8037550: Update RFC references in javadoc to RFC 5280

Looks good to me. --Sean On 09/18/2014 06:27 PM, Jason Uh wrote: Please review this changeset, which updates references to RFC 3280 to RFC 5280. RFC 5280 has obsoleted 3280. http://cr.openjdk.java.net/~juh/8037550/webrev.03/ Thanks, Jason

Re: [tls] On 8059818 Keytool does not recognize jssecacerts for -trustcacerts command line option

On 10/08/2014 01:57 AM, Wang Weijun wrote: On Oct 8, 2014, at 16:01, Xuelei Fan wrote: It looks strange to me now that this keytool command cannot specify the customized trusted anchor sources. Normally, the key store of the trust anchor should be customizable so that users can use the trust

Re: [tls] On 8059818 Keytool does not recognize jssecacerts for -trustcacerts command line option

On 10/08/2014 08:14 AM, Wang Weijun wrote: On Oct 8, 2014, at 23:00, Sean Mullan wrote: I agree that we should not read jssecacerts by default. My vote would be to extend -trustcacerts to take an optional path to a cacerts file but fallback on lib/security/cacerts if not specified. No

Re: RFR 8046002: Move Ucrypto to the open jdk repo

You should change the @since tags to 1.9 since this is its first inclusion in OpenJDK. Looks good otherwise. --Sean On 10/13/2014 07:54 PM, Valerie Peng wrote: Hi, Sean, Could you please review the changes for 8046002: Move Ucrypto to the open jdk repo? Once you reviewed it, I will request a

Re: RFR 8046002: Move Ucrypto to the open jdk repo

Looks good. --Sean On 10/15/2014 12:56 PM, Valerie Peng wrote: Sure, webrev updated at http://cr.openjdk.java.net/~valeriep/8046002/webrev.01. Thanks for the prompt review, Valerie On 10/14/2014 5:18 AM, Sean Mullan wrote: You should change the @since tags to 1.9 since this is its first

Re: apple.security.KeychainStore does not load private key (when called from javaws)

Looks fine to me. --Sean On 10/28/2014 02:42 PM, Vincent Ryan wrote: OK thanks. I had been looking for your name in that list. In addition, changesets require a testcase to verify the fix so I've modified an existing keychain testcase. I’ve updated the previous webrev, in place: http://cr.ope

JDK 9 Review Request for 8046949: Generify the javax.xml.crypto API

Earlier this year, we dropped the requirement to deliver JSR 105 (XML Digital Signature API) as a standalone JSR [1], which will make it easier to add some long-standing enhancements to the API. The first of those is to finally add support for generics to the API: - all Collection and Iterator

Re: [9] request for review 8062548: Support duplicate Extended Key Usage certificate extensions

Well, sorry, but this is not a bug so we should not fix it. The certificate is not compliant with RFC 5280. See Section 4.2: "A certificate MUST NOT include more than one instance of a particular extension." The EKU extension is already designed to specify more than one key purpose, so it doesn

CFV: New Security Group Member: Anthony Scarpino

or further evaluation. Votes are due by November 17, 2014, 10:00 AM PST. Only current Members of the Security Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Sean Mullan

Re: CFV: New Security Group Member: Anthony Scarpino

Vote: yes --Sean On 11/03/2014 12:28 PM, Sean Mullan wrote: I hereby nominate Anthony Scarpino to Membership in the Security Group. Anthony is a member of the Java Security Libraries team at Oracle and has been an active contributor to the OpenJDK Security Group for approximately two years

Re: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11

It looks ok to me although I think Valerie should also review it. Is it possible to add a simple regression test for this and not be dependent on the JCK tests? --Sean On 11/06/2014 05:14 PM, Anthony Scarpino wrote: Hi, I need a review of this change to the pkcs11 wrapper code. The changes

Re: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11

k:jni ... There are a handful of tests that do that. Is there an existing test you could add that run tag to to reproduce the issue? --Sean Tony On 11/06/2014 02:37 PM, Sean Mullan wrote: It looks ok to me although I think Valerie should also review it. Is it possible to add a simple regression tes

Re: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11

Updated webrev looks good. --Sean On 11/07/2014 12:08 PM, Anthony Scarpino wrote: On 11/07/2014 04:44 AM, Sean Mullan wrote: On 11/06/2014 07:06 PM, Anthony Scarpino wrote: It's completely dependent on Xcheck:jni. I figured that was an option part of the testing process. Not something

Re: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities

A few comments: * KeystoreImpl.m - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? - update copyright year * KeychainStore.java 297-304 I think it would be cleaner to write these lines as: } else

Re: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities

at 16:50, Sean Mullan wrote: A few comments: * KeystoreImpl.m - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? - update copyright year * KeychainStore.java 297-304 I think it would be cleaner to write these

Re: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities

Looks good. --Sean On 11/10/2014 04:53 PM, Vincent Ryan wrote: I’ve updated the fix to reduce the casts to KeyEntry: http://cr.openjdk.java.net/~vinnie/8046777/webrev.02/ On 10 Nov 2014, at 18:48, Vincent Ryan wrote: On 10 Nov 2014, at 18:13, Sean Mullan wrote: You missed one of my

Re: JDK 9 Review Request for 8046949: Generify the javax.xml.crypto API

throw new NullPointerException("namespaceMap cannot be null"); 161 } I would like to check "namespaceMap == null" before the assignment of this.expression and this.filter. I will fix that before I push the changeset. Thanks, Sean Thanks, Xuelei On 10/3

Result: New Security Group Member: Anthony Scarpino

The vote for Anthony Scarpino [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011378.html

Re: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25

On 11/18/2014 02:47 AM, Wang Weijun wrote: Re-request for code review at http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ * Principal: This should also be included in the @implSpec, is it? You might need another implSpec tag before this, or remove the as it isn't really necessary. S

Re: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25

On 11/24/2014 03:59 AM, Wang Weijun wrote: On Nov 19, 2014, at 22:10, Sean Mullan wrote: On 11/18/2014 02:47 AM, Wang Weijun wrote: Re-request for code review at http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ * Principal: This should also be included in the @implSpec, is it? You

Re: [9] request for review 8044445: Create PKCS12 Keystores by Default

Comments: * JceKeyStore [906] add @Override to engineProbe method * KeyStore [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. You need to define what happens if the File does not exist. You could either throw a KeyStore

Re: Detecting whether an algorithm is supported without creating one?

On 12/12/2014 12:04 AM, Bernd Eckenfels wrote: Just get it and throw it away, it is easier than iterating the algorithms of the providers. Yes, probably. But as you note, the other way is to iterate over the Providers returned by Security.getProviders(), and call p.getService("MessageDigest"

Re: [9] request for review 8044445: Create PKCS12 Keystores by Default

ev.02/ On 2 Dec 2014, at 15:10, Sean Mullan wrote: Comments: * JceKeyStore [906] add @Override to engineProbe method * KeyStore [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. You need to define what happens if the

Re: [9] request for review 8044445: Create PKCS12 Keystores by Default

On 12/16/2014 07:12 PM, Vincent Ryan wrote: I’ve generated a new webrev to address your comments below: http://cr.openjdk.java.net/~vinnie/805/webrev.04/ Thanks. On 16 Dec 2014, at 21:11, Sean Mullan wrote: Here are my comments on the latest webrev: * General - for the

Re: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled

Just a few comments: - some of the methods (encodePoint, trimZeroes, ...) can be made private static. 451: if getCurveOid returns null, you should throw MarshalException instead of outputting a null Oid 486: if getECParameterSpec returns null, you should throw MarshalException (otherwise a

Re: [9] request for review 8044445: Create PKCS12 Keystores by Default

On 12/17/2014 06:58 PM, Vincent Ryan wrote: FYI I’ve updated the webrev to include the changes below: http://cr.openjdk.java.net/~vinnie/805/webrev.05/ The updated webrev looks good. --Sean

Re: [9] request for review 8044445: Create PKCS12 Keystores by Default

: Thanks Sean. I have a testcase that I’d like to add to the changeset. I’ll send that out later today. On 18 Dec 2014, at 18:18, Sean Mullan wrote: On 12/17/2014 06:58 PM, Vincent Ryan wrote: FYI I’ve updated the webrev to include the changes below: http://cr.openjdk.java.net/~vinnie/805

Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary

Please add a noreg-doc label to the bug. Looks fine otherwise. --Sean On 01/06/2015 09:59 PM, Jamil Nimeh wrote: Hello all, This is a quick fix to deal with a broken link for the RC5ParameterSpec javadoc. Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 Webrev: http://cr.openjdk.java.net

Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary

On 01/07/2015 09:02 PM, Jamil Nimeh wrote: Sure. I did a little looking into this as well between email exchanges and I think Mike has it right. According to http://www.ietf.org/rfc.html the RFC Editor site is the authoritative source. Kind of a bummer as I prefer the xml2rfc format. But if R

Re: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled

mment. Can you remove the comment on line 169 of KeySelectors.java? It is no longer true now that all 3 key types are supported. Thanks, Sean Thanks, Jason On 12/18/2014 07:02 AM, Sean Mullan wrote: Just a few comments: - some of the methods (encodePoint, trimZeroes, ...) can be made private s

Re: [9] RFR: 8059916: Change default criticality of policy mappings and policy constraints certificate extensions

Looks good to me. --Sean On 01/12/2015 06:56 PM, Jason Uh wrote: Please review this change, which changes the default criticality of the policy mappings and policy constraints certificate extensions. This change makes both extensions critical by default, per RFC 5280. webrev: http://cr.openjdk

Re: [9] RFR: 8059916: Change default criticality of policy mappings and policy constraints certificate extensions

false; +extensionId = PKIXExtensions.PolicyMappings_Id; +critical = true; (Good catch, Jamil.) Jason On 1/13/15 4:55 AM, Sean Mullan wrote: Looks good to me. --Sean On 01/12/2015 06:56 PM, Jason Uh wrote: Please review this change, which changes the default criticality of the p

Re: Request for review : 8032573 - CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input

On 01/16/2015 07:32 AM, Ivan Gerasimov wrote: Hi everyone! I'm taking over this backport by Mala. Can I consider it reviewed, given the comment is corrected? Yes, you can add me as the reviewer. --Sean Sincerely yours, Ivan On 24.12.2014 22:18, Jamil Nimeh wrote: Hi Mala, the backport lo

Re: RFR 8071313: krb5.conf not read if SCDynamicStore krb5 config is empty

Looks ok to me. --Sean On 01/22/2015 05:46 AM, Wang Weijun wrote: Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8071313/webrev.00 On a Mac OS X, when Open Directory is installed but disabled, Java should be able to use other Kerberos settings. Noreg-hard but I added

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

Hi Jason, Just a few comments: * DOMSignatureMethod - If setParameter throws an exception, I think we should fallback and try the old code. This will allow 3rd party JCE providers to continue to work until they update their implementations to support the new ParameterSpec. * DSA, ECDSASign

Re: RFR 8055045: StringIndexOutOfBoundsException while reading krb5.conf

Looks good to me. --Sean On 01/22/2015 09:33 AM, Wang Weijun wrote: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8055045/webrev.00/ The old code has an error is the value is a single " or '. Thanks Max

Re: RFR 8022582: Relax response flags checking in sun.security.krb5.KrbKdcRep.check.

Typo on line 941 of KDC.java: s/senstives/sensitives Also the OS component of the bug is set to "solaris_10", which doesn't seem right. Looks ok otherwise. --Sean On 01/14/2015 11:10 PM, Wang Weijun wrote: Hi All Please review the code changes at http://cr.openjdk.java.net/~weijun/8022

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

On 01/25/2015 11:15 PM, Michael StJohns wrote: Sorry - I missed this the first time around I think this may not be the right approach... I'm concerned with trying to overload ECDSA and DSA which have always had relationships with very specific specifications and trying to make them also cov

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

tParameter(SignatureFormatParameterSpec.P1363); sig.setParameter(curve2519Params); We shall rethink this and see if we can come up with a better design. Thanks for reviewing this. --Sean On 01/26/2015 05:42 PM, Sean Mullan wrote: On 01/25/2015 11:15 PM, Michael StJohns wrote: Sorry - I missed this the first time aro

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

On 01/27/2015 05:40 PM, Michael StJohns wrote: So what I'm concerned with is surprise. I'm also concerned with "default signature formats" from new providers. Right now, I know if I ask for ECDSA, the output of Signature will be in a very specific format, and the math will match what's in FIPS

Re: Review request 8069551: Move java.security.acl from compact3 to java.base

Looks fine to me. --Sean On 01/29/2015 03:58 PM, Mandy Chung wrote: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 java.security.acl is superceded by java.security package since 1.2. This patch proposes to move java.security.acl package to java.base module rather

Re: RFR 8071643: sun.security.krb5.KrbApReq.authenticate() is not thread safe

Looks fine to me. --Sean On 02/02/2015 08:47 AM, Weijun Wang wrote: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8071643/webrev.00/ The static field is removed and a local MessageDigest is used. The getInstance() method might spend some time but since there a

Re: RFR 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC

The copyright on the test should be at the top. Otherwise, this fix looks good to me. --Sean On 02/03/2015 04:42 AM, Jaroslav Bachorik wrote: > Please, review the following change to j.s.ProtectionDomain > > Issue : https://bugs.openjdk.java.net/browse/JDK-8064331 > Webrev: http://cr.openjdk.jav

Re: RFR 8069072: GHASH performance improvement

This updated webrev looks good to me. --Sean On 02/09/2015 02:15 PM, Florian Weimer wrote: Micro-benchmarks show a ten-fold performance increase, which is very noticeable with TLS connections using the AES-GCM cipher suites, as discussed here:

Re: RFR 8072932: Test fails with java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getDomainCombiner")

Looks fine to me. Can you add a noreg-trivial label to the bug? --Sean On 02/11/2015 11:10 AM, Jaroslav Bachorik wrote: Please, review the following simple change. Issue : https://bugs.openjdk.java.net/browse/JDK-8072932 Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00 This pat

Re: RFR 8022313: sun/security/pkcs11/rsa/TestKeyPairGenerator.java failed in aurora

Looks good. Add noreg-self label to bug. --Sean On 02/12/2015 07:03 PM, Anthony Scarpino wrote: Hi, Please review the quick change that from my testing stops the intermittent failure of this test, which I believe is caused by it colliding with other concurrently running tests http://cr.openjd

Re: RFR 8072394: Performance improvement for X.509 certificate parsing

This fix looks fine, but I am trying to remember why a Set/LinkedHashSet was used in the first place, it seem like an List/ArrayList would have been more suitable. Even though PolicyInformation is an internal class, it's probably better to not change that detail at this point unless we have a b

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

to append "Format" to the format name. Would you be ok with this solution? Thanks, Jason On 1/29/15 7:27 AM, Sean Mullan wrote: On 01/27/2015 05:40 PM, Michael StJohns wrote: So what I'm concerned with is surprise. I'm also concerned with "default signature formats" from

Re: RFR 8072394: Performance improvement for X.509 certificate parsing

On 02/13/2015 03:16 PM, Florian Weimer wrote: On 02/13/2015 08:43 PM, Sean Mullan wrote: This fix looks fine, but I am trying to remember why a Set/LinkedHashSet was used in the first place, it seem like an List/ArrayList would have been more suitable. Even though PolicyInformation is an

Re: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java failed due to CloneNotSupportedException: SHA-256

On 02/16/2015 02:57 PM, Anthony Scarpino wrote: FYI, the bug number should be JDK-8043951. The one I listed was the backport ID. The link below is still valid Normally, the bug in the comment above a problem list entry is the bug that remains open and still needs to be fixed for the problem

Re: RFR 8073113: sun/security/pkcs11/MessageDigest/TestCloning.java failed due to CloneNotSupportedException: SHA-256

On 02/16/2015 06:32 PM, Anthony Scarpino wrote: On 02/16/2015 02:48 PM, Sean Mullan wrote: On 02/16/2015 02:57 PM, Anthony Scarpino wrote: FYI, the bug number should be JDK-8043951. The one I listed was the backport ID. The link below is still valid Normally, the bug in the comment above a

Re: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

Looks good. --Sean On 02/16/2015 01:53 PM, Jason Uh wrote: Thanks Sean. Here it is with your suggested changes: http://cr.openjdk.java.net/~juh/8042967/04/ Opened an issue to track the docs changes: https://bugs.openjdk.java.net/browse/JDK-8073261 Jason On 02/16/2015 10:22 AM, Sean Mullan

<    1   2   3   4   5   6   7   8   9   10   >