Re: RFR 8173410: Add commented config line for jdk.security.provider.preferred

he comment formating consistent. Why did you move the RMI Registry Serial Filter? Offhand, this seems gratuitous, and will make ift more difficult for folks trying to maintain a single or slightly modified java.security across release families. Looks good otherwise. Brad On 2/6/2017 11:26 A

RFR 8173410: Add commented config line for jdk.security.provider.preferred

Please review this change for Solaris SPARC configurations to add an optional configuration line. There are a few minor changes which didn't change any content. Changing some "#"'s for a bit more consistency and readability across the file. Also moving an RMI entry to the end that was merged

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

ittedAlgs Map - that will certainly benefit logging. regards, Sean. On 30/01/2017 18:21, Anthony Scarpino wrote: Hi Sean, Actually Sean M and I were talking about that offline on thursday. That file is changing a lot. The three sections you mention have changed a lot, but the general idea is the d

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

On 01/23/2017 03:27 PM, Anthony Scarpino wrote: Hi, I need a code review of this change that brings more detail constraints checking and control to certpath and jar disabled algorithm Security properties. http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ thanks Tony Updated review

Re: RFR: 8160655 Fix denyAfter and usage types for security properties

SigAlgName() instead * SignatureFileVerifier.java 294 Timestamp[] timestamp = new Timestamp[newSigners.length]; "timestamps" would be more clear as a variable name 299 System.out.println("Timestamp[" + (i - 1) + "] = " + debug.println --Sea

Re: Code Review Request, JDK-8172869 4096 is not supported yet for the DH Parameter Generator

On 01/24/2017 11:24 AM, Xuelei Fan wrote: Hi, Please review this spec documentation update: http://cr.openjdk.java.net/~xuelei/8172869/webrev.00/ In the java.security.AlgorithmParameterGenerator specification, 4096 bits DH parameter generator is specified as a required feature. However, th

RFR: 8160655 Fix denyAfter and usage types for security properties

Hi, I need a code review of this change that brings more detail constraints checking and control to certpath and jar disabled algorithm Security properties. http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ thanks Tony

Re: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki

On 01/19/2017 11:50 AM, Mandy Chung wrote: On Jan 19, 2017, at 11:39 AM, Anthony Scarpino wrote: Hi, I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. For those not familiar with

RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki

Hi, I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. For those not familiar with discussions elsewhere, the term "token" is confusing and unclear as it can mean many things cryptographical

Re: Code Review Request, JDK-8171003, A couple of JSSE tests have been failing after JDK-8170329

Looks good. Tony On 12/09/2016 12:54 PM, Xuelei Fan wrote: Hi, Please review this typo issue introduced in JDK-8170329. $ hg diff test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java @Override -protected boolean isCustomizeClientConnection() { +protected boolean isCust

Re: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto

On 12/07/2016 03:21 PM, Valerie Peng wrote: Anyone can help reviewing this? The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to address the E_MACRO_REDEFINED warning. In addition, I also updated the nativeCrypto.h to remove the workaround for a Solaris12-specific issue which has

Re: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property

ithms or the jdk.certpath.disabledAlgorithms > property. Please take another look and let me know if you are ok with it: > > http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.01/ > > Thanks, > Sean > >> On 11/22/16 11:00 AM, Anthony Scarpino wrote: >&g

Re: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property

On 11/22/2016 05:19 AM, Sean Mullan wrote: On 11/21/16 5:43 PM, Anthony Scarpino wrote: On 11/21/2016 01:09 PM, Sean Mullan wrote: Please review this fix for a bug where certificates were not being blocked if the algorithm is only listed in the jdk.tls.disabledAlgorithms property and not the

Re: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property

On 11/21/2016 01:09 PM, Sean Mullan wrote: Please review this fix for a bug where certificates were not being blocked if the algorithm is only listed in the jdk.tls.disabledAlgorithms property and not the jdk.certpath.disabledAlgorithms property. I have modified an existing regression test to te

RFR 8168931: Few OCSP related test failed with "Response is unreliable: its validity interval is out-of-date"

Hi, I need a review of a one liner to revert the PKIXParameter date argument back to null, aka current time. http://cr.openjdk.java.net/~ascarpino/8168931/webrev/ thanks Tony

RFR: 8168861 AnchorCertificates uses hardcoded password for cacerts keystore

Hi, I need a one line review to null out the password field in the keystore load op.. http://cr.openjdk.java.net/~ascarpino/8168861/webrev/ thanks Tony

Re: RFR: 8168911: Increased number of classes initialized during initialization of SignatureFileVerifier

On 11/04/2016 08:09 AM, Claes Redestad wrote: Hi, changes to SignatureFileVerifier in 9+142 has some startup implications, and a small cleanup to avoid some trivial regexes etc reduces number of classes initialized in affected startup tests by 61, undoing most of the observed regression. Webrev

Re: RFR: 8168313: Tighten permissions granted to jdk.crypto.pkcs11 module

On 10/20/2016 08:22 AM, Sean Mullan wrote: Please review this change to tighten or remove unnecessary permissions granted to the jdk.crypto.pkcs11 module: http://cr.openjdk.java.net/~mullan/webrevs/8168313/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8168313 In doing so, I refactored the

Re: [8u-dev] Request for Review and Approval to backport: 8167591: Add MD5 to signed JAR restrictions

On 10/20/2016 11:15 AM, Ivan Gerasimov wrote: Hello! Would you please help review and give the approval to backport this fix? The changes in the backport, comparing to the fix in 9, are due to different file structure and the different previous value of the property. Bug: https://bugs.openjdk.

RFR 8167591: Add MD5 to signed JAR restrictions

Hi, I need a simple review of adding MD5 to the jdk.jar.disabledAlgorithms security property. It's really a one line change, the comments got moved to a different location in the file which makes it look bigger. http://cr.openjdk.java.net/~ascarpino/8167591/webrev/ Tony

Re: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate

On 10/12/2016 01:41 PM, Sean Mullan wrote: On 10/12/2016 04:06 PM, Anthony Scarpino wrote: Later in the verify(), AlgorithmChecker needs a TrustAnchor object. In this case, because it's the old method that deploy is using, I have to manufacture a TrustAnchor until they can use the new m

Re: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate

On 10/12/2016 12:15 PM, Sean Mullan wrote: On 10/12/2016 01:47 PM, Anthony Scarpino wrote: New webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.02/ * DisabledAlgorithmConstraints 700 "Algorithm constraints check failed on keysize limits.&q

Re: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate

has a TrustAnchor as PKIXCertPathValidator passes it. AlgorithmChecker always needs a TrustAnchor, which PKIXCertPathValidator call. So I don't see a situation where we don't always have an TrustAnchor. 1061 return anchor; should be indented 4 spaces --Sean On 10/10/2016 02

Re: RFR: JDK-8162723 : Array index overflow in Base64 utility class

On 10/10/2016 12:29 PM, Sean Mullan wrote: Please review this change to fix a potential array index overflow in the XML security Base64 encoding class. This is a direct import of the corresponding patch that has already been made to the Apache code. webrev: http://cr.openjdk.java.net/~mullan/web

RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate

Hi, I need a review of a fix to JEP 288 were certpath algorithm checking wasn't checking OCSP certs against the jdkCA keyword. http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ thanks Tony

Re: 8165103: Update to "denyAfter constraint check" exception message

st my preference, Valerie On 10/5/2016 8:29 PM, Anthony Scarpino wrote: This is intentional as an optimization. Setting the String is only needed in the failure case, so I separated them to optimize the success case. That's why I have the comment there. Tony On 10/05/2016 04:58 PM, Valerie

Re: 8165103: Update to "denyAfter constraint check" exception message

just add another String variable "dateType" and assign value to it in the first if-check block? Rest looks fine. Valerie On 10/5/2016 1:20 PM, Anthony Scarpino wrote: Hi, I'd like a review of this change away from a generic error messages in the denyAfter constraint. The message

8165103: Update to "denyAfter constraint check" exception message

Hi, I'd like a review of this change away from a generic error messages in the denyAfter constraint. The message better specify which date was checked against the constraint now. Testing is handled elsewhere. http://cr.openjdk.java.net/~ascarpino/8165103/webrev/ Tony

RFR: 8165101 AnchorCertificates throws NPE when cacerts file not found

Hi, I'd like a review of this simple fix. There's no test as the fix is trivial and it's not practical to test a non-existent cacerts file in a concurrent testing environment http://cr.openjdk.java.net/~ascarpino/8165101/webrev/ Tony

RFR 8074838: Resolve disabled warnings for libj2pkcs11

Hi, Can I get a review of this change to remove the warning suppression and fix the minor compiler issues that it was hiding in the pkcs11 wrapper library. http://cr.openjdk.java.net/~ascarpino/8074838/webrev/ thanks Tony

Re: RFR: 8150158: Update bugs.sun.com references to bugs.java.com

Looks fine to me. Tony On 08/25/2016 12:55 PM, Sean Mullan wrote: Real trivial fix, just updating obsolete bug URLs in code comments. bug: https://bugs.openjdk.java.net/browse/JDK-8150158 $ hg diff --nodates -a -U 1 diff -r 9c7eb3e1799f src/java.xml.crypto/share/classes/com/sun/org/apache/xml

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

eijun Wang wrote: I guess we need a lawyer to answer this question. :-) On 8/25/2016 9:58, Anthony Scarpino wrote: So by having no crypto.policy defined we have no JCA? Does that mean no operations at all (No MessageDigest, etc) or no restrictable crypto ops? Since we know a limited number of

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

On 08/24/2016 05:21 PM, Bradford Wetmore wrote: [...] Sean Mullan wrote: > What about setting the default value to "limited"? And then this > would only be changed to "unlimited" if the build --enable-unlimited- > crypto option is specified? I could, but I'm concerned that a build with -

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 th

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

RFR: 8060224 Enable SHA-1 CertPath Restrictions

Please review the configuration change for the java.security file. http://cr.openjdk.java.net/~ascarpino/8060224/webrev/ Tony

Re: RFR: 9: 8161233: ProblemList sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java on macOS

looks good. Tony On 07/12/2016 02:31 PM, Rajan Halade wrote: Please review following patch. Test is failing consistently on macOS due toJDK-8161232 . Until this issue is fixed, test should be in ProblemList. diff -r fa9e1202a3cd test/ProblemLis

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

imestampTrustAnchors(Set t) Does anyone call this method? Can it be removed? yes it can... --Sean On 06/28/2016 05:17 PM, Anthony Scarpino wrote: Hi, I need a review of the below code. It's a continuation of the previous certpath related changes. Additional constraints checking on

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

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. The test now sets the property to test the previous default functionality. http://cr.openjdk.java.net/~ascarpino/8159180/webrev/ thank

RFR: 8154015 Apply algorithm constraints to timestamped code

Hi, I need a review of the below code. It's a continuation of the previous certpath related changes. Additional constraints checking on timestamped jars being checked by the deploy code http://cr.openjdk.java.net/~ascarpino/8154015/webrev.01/ thanks Tony

Re: [9] RFR 8157627: Ucrypto prov need to workaround the renaming of CK_AES_GCM_PARAMS starting S11.3

The changes look fine.. thanks Tony On 06/09/2016 06:01 PM, Valerie Peng wrote: Hi Tony, Could you please help reviewing this? Solaris crypto team made some changes in the Ucrypto area since S11.3 which breaks JDK build. This is the workaround (and some minor clean up) for S11.3. This incompa

Re: Review: 8157925: Fix typo in X509KeyManager javadoc

Looks fine to me. Tony > On Jun 9, 2016, at 9:49 PM, Jamil Nimeh wrote: > > Hi folks, can I please get a quick review for a very simple javadoc fix in > X509KeyManager? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157925 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/web

Re: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup)

s this later > if needed. > Thanks for the review, > Valerie > >> On 6/9/2016 4:36 PM, Anthony Scarpino wrote: >>> On 06/08/2016 10:28 AM, Valerie Peng wrote: >>> Tony, >>> >>> Can u please help reviewing this? Most if not all of the changes her

Re: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup)

On 06/08/2016 10:28 AM, Valerie Peng wrote: Tony, Can u please help reviewing this? Most if not all of the changes here are performance enhancements suggestions from the performance team. I polished them and then updated the java.security file to add SHA-3. Webrev: http://cr.openjdk.java.net/~v

Re: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup)

On 06/08/2016 12:49 PM, e...@zusammenkunft.net wrote: Hello, I would not mix performance and policy commits, but maybe those changes are related to the same task? What about Group.HmacSHA2:SunJCE is that needed as well? BTW the preferences are only set for Solaris, why are there no preference

Re: [9] RFR: 8155575: Provider.java contains very long lines because of lambda

tlana Nikandrova wrote: Glad to hear it. Thank you! Svetlana On 20.05.2016 17:24, Anthony Scarpino wrote: On 05/20/2016 07:13 AM, Svetlana Nikandrova wrote: Hello, please review this code format fix for Provider.java. No code changes, just a few breaks in a really long (like > 120 ch

Re: [9] RFR: 8155575: Provider.java contains very long lines because of lambda

On 05/20/2016 07:13 AM, Svetlana Nikandrova wrote: Hello, please review this code format fix for Provider.java. No code changes, just a few breaks in a really long (like > 120 characters) lines. Also examined other classes in**the java.security package, but seems like Provider.java is the only o

Re: RFR 8155847: SHA groups needed for jdk.security.provider.preferred

this? Would this limit our capability to add more algorithms to update releases? We would have to file a CCC for the change to the config, but there would be no problems with adding to updates. Anything that doesn't match a preferred provider entry is passed onto the normal security provi

Re: RFR 8154005: Add algorithm constraint that specifies the restriction date

ready declared `Matcher matcher` like this: } else if (matcher.usePattern(denyAfterPattern).matches()) { With kind regards, Ivan On 13.05.2016 0:34, Anthony Scarpino wrote: I've updated the webrev to at: http://cr.openjdk.java.net/~ascarpino/8154005/webrev.01/ Comments addressed below

Re: RFR 8154005: Add algorithm constraint that specifies the restriction date

I've updated the webrev to at: http://cr.openjdk.java.net/~ascarpino/8154005/webrev.01/ Comments addressed below... On 05/11/2016 04:55 PM, e...@zusammenkunft.net wrote: Hello, In AlgorithmChecker the Javadoc seems to not follow "@param name desc" format (in two places). Also it should most

Re: RFR JDK-8000415: Add support for SHA-3

On 05/04/2016 07:08 PM, Valerie Peng wrote: Hi, Can someone help reviewing the changes for SHA-3? The result has been validated against the NIST test vectors (for BYTE-ONLY impls, i.g. input which are multiples of bytes). The feature complete date is coming up in a week or two. So, if this can

RFR 8154005: Add algorithm constraint that specifies the restriction date

Please review the changes related to 8154005. This is a continuation JEP-288. It adds a denyAfter constraint the stops PKIX algorithm support at a specified date. http://cr.openjdk.java.net/~ascarpino/8154005/webrev/ thanks Tony

RFR 8155847: SHA groups needed for jdk.security.provider.preferred

Hi I need a review of my changes to jdk.security.preferred.provider to add Groups. This makes it a lot cleaner for support a group of algorithms that are very similar, such as SHA2 (aka SHA224, SHA256, SHA384, ... ) http://cr.openjdk.java.net/~ascarpino/8155847/webrev/ thanks Tony

Re: AES-NI support

Hi, JEP 246 goes into some of these details but, particularly for AES-GCM for jdk9 with the GHASH intrinsics. Also jdk supports intrinsics for SHA1/2 and RSA. For jdk8, AES block ops use AES-NI and AES-CBC has been parallelized. http://openjdk.java.net/jeps/246 Tony On 05/10/2016 09:48 A

Re: CFV: New Security Group Member: Jamil Nimeh

Vote: Yes > On Apr 29, 2016, at 7:43 AM, Sean Mullan wrote: > > Vote: yes > >> On 04/29/2016 10:40 AM, Sean Mullan wrote: >> I hereby nominate Jamil Nimeh to Membership in the Security Group. >> >> Jamil is a member of the Java Security Libraries team at Oracle and has >> been an active contr

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

On 04/26/2016 12:27 PM, Bradford Wetmore wrote: On 4/25/2016 11:25 PM, Wang Weijun wrote: On Apr 26, 2016, at 8:48 AM, Bradford Wetmore wrote: but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: I haven't touched this area yet

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

Comments addressed in: http://cr.openjdk.java.net/~ascarpino/webrev.04/ Tony On 04/12/2016 12:39 PM, Sean Mullan wrote: On 04/11/2016 11:59 AM, Anthony Scarpino wrote: I believe I have addressed all previous comments and some changes were made to rename cacerts to jdkCA and how it works

Re: RFR 8152205: jdk.security.provider.preferred is ambiguously documented

Thanks Tony On 04/12/2016 05:36 PM, Xuelei Fan wrote: Looks fine to me. Thanks, Xuelei On 4/11/2016 11:59 PM, Anthony Scarpino wrote: Ok.. I changed it to: {@code jdk.security.provider.preferred} {@link Security#getProperty(String) Security} I updated it at the same link if someone wants

Re: RFR 8152205: jdk.security.provider.preferred is ambiguously documented

} But I see it done that way in other places, so this is fine. Brad On 4/6/2016 3:47 PM, Xuelei Fan wrote: Looks fine to me. Xuelei On 4/7/2016 5:23 AM, Anthony Scarpino wrote: I need a review of this very simple doc clarification. Calling out jdk.security.provider.preferred as a "secu

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

I believe I have addressed all previous comments and some changes were made to rename cacerts to jdkCA and how it works AnchorCertificates.java http://cr.openjdk.java.net/~ascarpino/8140422/webrev.03/ Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: I need a code review of this change

RFR 8152205: jdk.security.provider.preferred is ambiguously documented

I need a review of this very simple doc clarification. Calling out jdk.security.provider.preferred as a "security property" instead of just a "property". http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ thanks. Tony

Re: RFR 8098580: drainRefQueueBounds() puts pressure on pool.size()

in so that it will avoid doing a pkcs11 operations if the token isn't available. - The two dispose methods do entirely different things, it'd be better to name them differently. Ok.. I changed the one that takes the session to disposeNative. Thanks, Valerie On 3/1/2016 2:29 PM, A

Re: RFR(M): 8152172: PPC64: Support AES intrinsics

- protected the generation of the AES-stubs by "if (UseAES)" tp prevent them from beeing generated on ppc64 big endian. We need a sponsor to push these two changes in sync to hs-comp. Thank you and best regards, Volker On Tue, Mar 29, 2016 at 10:58 PM, Anthony Scarpino wrote: Volker,

Re: RFR(M): 8152172: PPC64: Support AES intrinsics

ppc64 AES intrinsics. Do you agree? Regards, Volker On Mon, Mar 28, 2016 at 7:41 PM, Anthony Scarpino wrote: [Switching to security-dev, core-lib-dev was bcc'ed] I don't see any problem changing it to int[][]. Being an Object[] is odd in my opinion. Tony On 03/25/2016 04:00 PM, V

Re: RFR(M): 8152172: PPC64: Support AES intrinsics

[Switching to security-dev, core-lib-dev was bcc'ed] I don't see any problem changing it to int[][]. Being an Object[] is odd in my opinion. Tony On 03/25/2016 04:00 PM, Vladimir Kozlov wrote: This question is for core libs. For JIT to generate optimal code we want to change type of AESCry

Re: [9] RFR: 8150512:Update test for jdk.security.provider.preferred security property.

Hi, The updated changes look fine. Thanks Tony On 03/15/2016 03:24 AM, Sibabrata Sahoo wrote: Hi Anthony, Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8150512/webrev.01/ Following comments associated. Thanks, Siba --- Here are my comments... - Pref

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

+4spaces for the second line. No need to resend webrev for that. See [1] for our build system code conventions. [1] http://openjdk.java.net/groups/build/doc/code-conventions.html /Erik On 2016-03-18 18:09, Anthony Scarpino wrote: I believe I got everyone's comments. I've updated the web

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

I believe I got everyone's comments. I've updated the webrev. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/ Thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: Currently CertPath algorithm restrictions allow or deny all certificates. This change adds the

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

I updated the webrev and added the build-dev list as there are two makefile changes. http://cr.openjdk.java.net/~ascarpino/8140422/webrev.01/ thanks Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: I need a code review of this change: Currently CertPath algorithm restrictions allow

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

On 03/08/2016 01:55 PM, Sean Mullan wrote: You should also copy build-dev on the next iteration since there are a few Makefile changes. On 02/29/2016 11:55 AM, Anthony Scarpino wrote: I need a code review of this change: http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ Currently

RFR 8098580: drainRefQueueBounds() puts pressure on pool.size()

Hi, I need a review of this change to SunPKCS11 where it's a bit smarter in disposing of native library object by reusing the same pkcs11 session is possible. Additionally changes to the session pool to fix a performance bottleneck. http://cr.openjdk.java.net/~ascarpino/8098580/webrev/ tha

RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

I need a code review of this change: http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ Currently CertPath algorithm restrictions allow or deny all certificates. This change adds the ability to reject certificate chains that contain a restricted algorithm and the chain terminates at a root

Re: [9] RFR: 8150512:Update test for jdk.security.provider.preferred security property.

On 02/25/2016 04:01 AM, Sibabrata Sahoo wrote: Hello, Please review the updated test to verify “jdk.security.provider.preferred” security property in all platform. Bug: https://bugs.openjdk.java.net/browse/JDK-8150512 Webrev: http://cr.openjdk.java.net/~ssahoo/8150512/webrev.00/ These test we

Code Review Request: 8145344: Add SHA1/224 to preferred provider list in java.security for solaris-sparc

Hi, Could I have a review of the quick change that adds SHA1 and SHA224 to the solaris-sparc preferred providers list and a minor change to handle algorithms with two names, like SHA1 and SHA-1. http://cr.openjdk.java.net/~ascarpino/8145334/webrev/ thanks Tony

Re: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4

The problems are different. The PKCS11 error means everything in this case. Tony > On Dec 18, 2015, at 12:20 PM, Sean Mullan wrote: > > The fix looks good, although this test is already on the ProblemList due to > JDK-8074580. Do you know if that bug is caused by the same issue? The > underl

Re: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests

On 12/03/2015 02:40 PM, e...@zusammenkunft.net wrote: Hello, That buffer sizing/expiring is a bit strange (the dynmic version stranger than the old one), I do not understand the need for it. The requests should not varry so much in size. Just reading something like 64bytes at a time (possibly no

Re: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests

. Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. Would you agree that JDK-8058455 could be closed out as a duplicate ? Regards, Sean. On 01/12/2015 23:44, Anthony Scarpino wrote: Hi all, I'd like a review of this change. It improves nextBytes() performance by all

Re: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests

ne on. > > Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. Would > you agree that JDK-8058455 could be closed out as a duplicate ? > > Regards, > Sean. > >> On 01/12/2015 23:44, Anthony Scarpino wrote: >> Hi all, >> >> I'd l

RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests

Hi all, I'd like a review of this change. It improves nextBytes() performance by allowing the random buffer to grow and shrink as random data is needed and remove the high level synchronization. Also disable SecureRandom for Solaris PKCS11 as it's not as fast as native. http://cr.openjdk.j

Re: Design review: JEP 273: DRBG-Based SecureRandom Implementations

On 11/18/2015 05:32 AM, Sean Mullan wrote: The getInstance methods can now take a SecureRandomParameterSpec object (rather than an AlgorithmParameterSpec). They should throw InvalidAlgorithmParameterException (not IllegalArgumentException) if the parameters are null or not the right type to be co

Re: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA

11/5/2015 6:19 AM, Anthony Scarpino wrote: On 11/03/2015 05:55 PM, Tim Du wrote: Hi All: Please help to review testing Preferred provider configuration feature for JCE . JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 https://bugs.openjdk.java.net/browse/JDK-8133151 webrev: http

Re: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA

On 11/03/2015 05:55 PM, Tim Du wrote: Hi All: Please help to review testing Preferred provider configuration feature for JCE . JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 https://bugs.openjdk.java.net/browse/JDK-8133151 webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/

RFR: 8139859 :TestRSA.java: 'message larger than modulus' using SunRsaSign KeyFactory

Hi I need a review of this test change that makes TestRSA.java work properly after the Preferred Provider code push. I also added some extra testing to make sure it runs in more situations. http://cr.openjdk.java.net/~ascarpino/8139859/webrev/ thanks Tony

RFR 8139860: Add ucrypto/TestRSA.java to ProblemList: Message is larger than modulus

Hi, I need a review of an addition to the ProblemList. http://cr.openjdk.java.net/~ascarpino/8139860/webrev/ The relates to SunRSASign bug found (8139859) which showed up during test of Preferred Provider changes.. thanks Tony

Re: RFR 8133151: Preferred provider configuration for JCE

lready reported on line 671, line 683 doesn't need to repeat this info? Thanks, Valerie On 10/16/2015 10:53 AM, Anthony Scarpino wrote: On 10/15/2015 05:20 PM, Valerie Peng wrote: Hi Tony, Here are the comments for the remaining file. - line 621, is there a particular reason to return im

Re: RFR 8133151: Preferred provider configuration for JCE

r. - line 262 - 267, given that there is an argument specifying provider name, I don't think your changes applies to this method. If correct, the javadoc change should be removed. - looks fine. I will continue to look at ProviderList.java and send u comments in a separate email. Thanks, Vale

Re: RFR 8133151: Preferred provider configuration for JCE

mments in a separate email. Thanks, Valerie On 10/9/2015 10:06 AM, Anthony Scarpino wrote: Ping for a security review.. Tony On 10/02/2015 10:08 AM, Anthony Scarpino wrote: Hi all, I'm need a review of the last developement piece to JEP 246, the configuration changes. I've copied th

Re: RFR 8133151: Preferred provider configuration for JCE

Ping for a security review.. Tony On 10/02/2015 10:08 AM, Anthony Scarpino wrote: Hi all, I'm need a review of the last developement piece to JEP 246, the configuration changes. I've copied the build-dev in case there were any comments on the minor changes in the make directory

RFR 8133151: Preferred provider configuration for JCE

Hi all, I'm need a review of the last developement piece to JEP 246, the configuration changes. I've copied the build-dev in case there were any comments on the minor changes in the make directory related to the java.security file. http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ than

Re: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256

Len value is generated by VM based on > bufOut. Anyway, just to play it safe, I added a line to set outLen to 0 just > to match what is done for line 657. > > http://cr.openjdk.java.net/~valeriep/8130875/webrev.01/ > > Thanks, > Valerie > > On 9/3/2015 7:20 AM,

Re: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256

> On Sep 2, 2015, at 10:50 PM, Anthony Scarpino > wrote: > > >> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: >> >> >> Can someone help review this java workaround for Solaris memory leak bug in >> Ucrypto library? >> Essentially, the

Re: [9] RFR: 8130875 Out of memory when using TLS_RSA_WITH_AES_128_GCM_SHA256

> On Sep 2, 2015, at 3:45 PM, Valerie Peng wrote: > > > Can someone help review this java workaround for Solaris memory leak bug in > Ucrypto library? > Essentially, the memory leak occurs when a null output buffer is specified > when doing encryption/decryption. > So, the workaround in Oracl

Re: GCM performance and Unsafe byte array accesses

Hi Andrew, Does your alignment changes affect x86 only or should this help all architectures? In general I don't see a disadvantage and that it could be expanded to other places in crypto too. But I have think about the effects on sparc, so that would need to be tested. Right now the sparc in

Re: RFR: 8046943: RSA Acceleration

On 06/18/2015 10:07 AM, Andrew Haley wrote: On 06/18/2015 06:00 PM, Anthony Scarpino wrote: Question, on the hotspot side you said in a previous post this was C2-only. Was there a reason you don't have it for all? None. It's up for negotiation. What do you want? C1, inter

Re: RFR: 8046943: RSA Acceleration

On 06/16/2015 07:33 AM, Andrew Haley wrote: On 06/15/2015 05:58 PM, Andrew Haley wrote: 3. I fused squaring and multiplication into a single montgomeryMultiply method. ... I don't agree with fusing them together. I think there should two separate intrinsics. For one, SPARC has a montsqr a

Re: RFR: 8073108: GHASH Intrinsics [need second reviewer]

On 06/15/2015 05:20 PM, John Rose wrote: Thanks for taking this on. It looks good, except for one thing. The intrinsic does not need to be an instance method, and doing so creates an undesirable coupling between the JVM and JDK. Specifically, the JDK should not need to know about subkeyH and s

Re: RFR: 8073108: GHASH Intrinsics [need second reviewer]

On 06/15/2015 05:20 PM, John Rose wrote: Thanks for taking this on. It looks good, except for one thing. The intrinsic does not need to be an instance method, and doing so creates an undesirable coupling between the JVM and JDK. Specifically, the JDK should not need to know about subkeyH and sta

RFR: 8073108: GHASH Intrinsics [need second reviewer]

Hi other reviewers, I'm hoping someone else can review this. Tony On 06/12/2015 03:16 PM, Vladimir Kozlov wrote: This implementation looks good to me. You need second review since changes are big. Thanks, Vladimir On 6/11/15 11:01 AM, Anthony Scarpino wrote: Now that JEP 246 is tar

<    1   2   3   4   5   6   7   8   >