From claes.redestad at oracle.com Sun May 1 23:35:40 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 May 2016 01:35:40 +0200 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties Message-ID: <572692CC.8040902@oracle.com> Hi, JDK-8154231 added methods to simplify access to system properties from internal code, but after some discussion it's been decided to rename these methods and document them to make it abundantly clear that they are performing a privileged action and that care needs to be taken to tread the input and output accordingly: Webrev: http://cr.openjdk.java.net/~redestad/8155775/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8155775 Thanks! /Claes From sean.mullan at oracle.com Mon May 2 14:15:29 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 2 May 2016 10:15:29 -0400 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <572692CC.8040902@oracle.com> References: <572692CC.8040902@oracle.com> Message-ID: <57276101.7040306@oracle.com> This looks good. Just a couple of comments: * src/java.base/share/classes/java/util/TimeZone.java 698 props.setProperty("user.timezone", id); This will only change the local copy of the property. I think you want to keep the original code which does a System.setProperty. * src/java.base/share/classes/jdk/Version.java This is not an issue in your changes, but the current javadoc for Version.current() says: 266 * @throws SecurityException 267 * If a security manager exists and its {@link 268 * SecurityManager#checkPropertyAccess(String) 269 * checkPropertyAccess} method does not allow access to the 270 * system property "java.version" but this can never occur since the code is wrapping the call to System.getProperty("java.version") in doPrivileged, so the caller's permissions are never checked. I think that this is a bug in the javadoc of this method and that it should not be specified to throw SecurityException. All code already has permission to read "java.version" in the default java.policy file. Can you file a followon bug to have this fixed? Thanks, Sean On 05/01/2016 07:35 PM, Claes Redestad wrote: > Hi, > > JDK-8154231 added methods to simplify access to system properties from > internal code, but after some discussion it's been decided to rename > these methods and document them to make it abundantly clear that they > are performing a privileged action and that care needs to be taken to > tread the input and output accordingly: > > Webrev: http://cr.openjdk.java.net/~redestad/8155775/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8155775 > > Thanks! > > /Claes From sean.mullan at oracle.com Mon May 2 15:01:22 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 2 May 2016 11:01:22 -0400 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <57276101.7040306@oracle.com> References: <572692CC.8040902@oracle.com> <57276101.7040306@oracle.com> Message-ID: <57276BC2.4080203@oracle.com> On 05/02/2016 10:15 AM, Sean Mullan wrote: > This looks good. Just a couple of comments: > > * src/java.base/share/classes/java/util/TimeZone.java > > 698 props.setProperty("user.timezone", id); > > This will only change the local copy of the property. I think you want > to keep the original code which does a System.setProperty. Ignore this comment. I missed the fact that System.getProperties() returns the props field without any defensive cloning. --Sean From claes.redestad at oracle.com Mon May 2 18:21:07 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 May 2016 20:21:07 +0200 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <57276101.7040306@oracle.com> References: <572692CC.8040902@oracle.com> <57276101.7040306@oracle.com> Message-ID: <57279A93.40206@oracle.com> On 2016-05-02 16:15, Sean Mullan wrote: > This looks good. Thanks! > > * src/java.base/share/classes/jdk/Version.java > > This is not an issue in your changes, but the current javadoc for > Version.current() says: > > 266 * @throws SecurityException > 267 * If a security manager exists and its {@link > 268 * SecurityManager#checkPropertyAccess(String) > 269 * checkPropertyAccess} method does not allow access > to the > 270 * system property "java.version" > > but this can never occur since the code is wrapping the call to > System.getProperty("java.version") in doPrivileged, so the caller's > permissions are never checked. > > I think that this is a bug in the javadoc of this method and that it > should not be specified to throw SecurityException. All code already > has permission to read "java.version" in the default java.policy file. > Can you file a followon bug to have this fixed? Filed: https://bugs.openjdk.java.net/browse/JDK-8155853 /Claes From weijun.wang at oracle.com Tue May 3 02:26:49 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 3 May 2016 10:26:49 +0800 Subject: RFR 8154523: SHA1PRNG output should change after reset Message-ID: Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8154523/webrev.00 Basically, a reset in SHA1PRNG should forget the internal state and cached output. Thanks Max From ivan.gerasimov at oracle.com Wed May 4 13:35:10 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 4 May 2016 16:35:10 +0300 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them In-Reply-To: <571F73A3.5060409@oracle.com> References: <571A5ACE.1010905@oracle.com> <571F49B7.30307@oracle.com> <571F73A3.5060409@oracle.com> Message-ID: <49d4960b-540f-3f95-ca2b-007147b2ec76@oracle.com> Thank you Se?n for looking into this! On 26.04.2016 16:56, Se?n Coffey wrote: > Looks like a fair approach to solving this issue Ivan. A few comments > from me : > > typo : authoririesOverflow --> authoritiesOverflow > typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow > typo : jdk.tls.handleCertReqAuthoritesOverflow --> > jdk.tls.handleCertReqAuthoritiesOverflow > Fixed. It's just amazing how many typos can fit into one word! > + throw new RuntimeException("Value of " + prop > + + " must be one of '" + HAO_NONE + "', '" > + + HAO_EMPTY + "', '" + HAO_TRUNC + "'"); > > I think it would be good to print the value of s in above exception > also. something like + ". Received: \"" + s + "\""); Added. > == > > s.println("Cert Authorities:" + (authoririesOverflow ? " (overflow)" : > "")); > > I would also be good to indicate the handleAuthoritiesOverflow string > value in above printing *if* authoritiesOverflow turns out to be true. > We should be able to determine from the next message printed - but no > harm to future proof. > Maybe : > > s.println("Cert Authorities:" + (authoritiesOverflow ? " (overflow" + > "[" + handleAuthoritiesOverflow + "])" : "")); > Added this too. Please find the updated webrev here: http://cr.openjdk.java.net/~igerasim/8154947/02/webrev/ With kind regards, Ivan > Regards, > Sean. > > On 26/04/2016 11:57, Ivan Gerasimov wrote: >> Here's a modified version of the fix. >> >> Instead of a boolean-type property, a string-type property is >> introduced. >> It is used to specify the strategy to use, if we encounter the >> overflow during filling the list of authorities. >> >> The default strategy is to throw an exception (just like the >> currently implemented behavior.) >> >> It can also be set to the values 'empty' or 'truncate', which will >> make the server to send an empty or truncated list upon overflow. >> >> Would you please help review it? >> >> http://cr.openjdk.java.net/~igerasim/8154947/01/webrev/ >> >> With kind regards, >> Ivan >> >> >> On 22.04.2016 20:09, Ivan Gerasimov wrote: >>> Hello everyone! >>> >>> During TLS handshake, a server may be required to send a >>> CertificateRequest, which contains a list of authorities. >>> If the list happens to be too long, the server is throwing an >>> exception, indicating an overflow. >>> >>> It may be convenient to be able to just drop the list altogether, >>> and let the client to choose a certificate randomly. >>> In certain situation this may be more preferable that just block >>> communication. >>> >>> Would you please help review a patch, which introduces an >>> command-line option that controls this behavior of the server? >>> If the approach is approved, I'll file a CCC request for that option. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ >>> >>> With the proposed fix all the security-related regression tests, >>> including the modified one, passed on all supported platforms. >>> >>> With kind regards, >>> Ivan >>> >>> >> > > From ivan.gerasimov at oracle.com Wed May 4 13:38:28 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 4 May 2016 16:38:28 +0300 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them In-Reply-To: <571F7C31.6010004@oracle.com> References: <571A5ACE.1010905@oracle.com> <571F49B7.30307@oracle.com> <571F73A3.5060409@oracle.com> <571F7C31.6010004@oracle.com> Message-ID: <487f2498-b83e-df1d-eb35-957ab74fb290@oracle.com> Thank you Xuelei for looking into this! On 26.04.2016 17:33, Xuelei Fan wrote: > jdk.tls.handleCertReqAuthoritesOverflow is a little bit long. > jdk.tls.server.overFlowAuthorites? Yes, I agree. Changed to a shorter property name. > May not need to define the "none" property value. > > Using enum for HAO_NONE, HAO_EMPTY and HAO_TRUNC? Changed to enum. Have to keep NONE, though, as we need to represent it in the enum somehow. > line 1920: Overflow should be rare, what about print only when overflow? It the indication of overflow is printed only when it has happened. Please find the updated version of webrev: http://cr.openjdk.java.net/~igerasim/8154947/02/webrev/ With kind regards, Ivan > Xuelei > > On 4/26/2016 9:56 PM, Se?n Coffey wrote: >> Looks like a fair approach to solving this issue Ivan. A few comments >> from me : >> >> typo : authoririesOverflow --> authoritiesOverflow >> typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow >> typo : jdk.tls.handleCertReqAuthoritesOverflow --> >> jdk.tls.handleCertReqAuthoritiesOverflow >> >> + throw new RuntimeException("Value of " + prop >> + + " must be one of '" + HAO_NONE + "', '" >> + + HAO_EMPTY + "', '" + HAO_TRUNC + "'"); >> >> I think it would be good to print the value of s in above exception >> also. something like + ". Received: \"" + s + "\""); >> == >> >> s.println("Cert Authorities:" + (authoririesOverflow ? " (overflow)" : >> "")); >> >> I would also be good to indicate the handleAuthoritiesOverflow string >> value in above printing *if* authoritiesOverflow turns out to be true. >> We should be able to determine from the next message printed - but no >> harm to future proof. >> Maybe : >> >> s.println("Cert Authorities:" + (authoritiesOverflow ? " (overflow" + >> "[" + handleAuthoritiesOverflow + "])" : "")); >> >> Regards, >> Sean. >> >> On 26/04/2016 11:57, Ivan Gerasimov wrote: >>> Here's a modified version of the fix. >>> >>> Instead of a boolean-type property, a string-type property is introduced. >>> It is used to specify the strategy to use, if we encounter the >>> overflow during filling the list of authorities. >>> >>> The default strategy is to throw an exception (just like the currently >>> implemented behavior.) >>> >>> It can also be set to the values 'empty' or 'truncate', which will >>> make the server to send an empty or truncated list upon overflow. >>> >>> Would you please help review it? >>> >>> http://cr.openjdk.java.net/~igerasim/8154947/01/webrev/ >>> >>> With kind regards, >>> Ivan >>> >>> >>> On 22.04.2016 20:09, Ivan Gerasimov wrote: >>>> Hello everyone! >>>> >>>> During TLS handshake, a server may be required to send a >>>> CertificateRequest, which contains a list of authorities. >>>> If the list happens to be too long, the server is throwing an >>>> exception, indicating an overflow. >>>> >>>> It may be convenient to be able to just drop the list altogether, and >>>> let the client to choose a certificate randomly. >>>> In certain situation this may be more preferable that just block >>>> communication. >>>> >>>> Would you please help review a patch, which introduces an >>>> command-line option that controls this behavior of the server? >>>> If the approach is approved, I'll file a CCC request for that option. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ >>>> >>>> With the proposed fix all the security-related regression tests, >>>> including the modified one, passed on all supported platforms. >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> > From valerie.peng at oracle.com Thu May 5 02:08:52 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 04 May 2016 19:08:52 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 Message-ID: <572AAB34.9030809@oracle.com> 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 be reviewed in a week or so, that'd be great. The changes for SUN providers are quite straight-forward, e.g. SHA-3 digest impls based on FIPS PUB 202. As for OracleUcrypto provider, Solaris SHA-3 support is through new libucrypto digest APIs (added in Solaris 12) instead of the libmd. When running on Solaris 12, the new libucrypto APIs will be used. Otherwise, libmd will be used. Changes for OracleUcrypto providers: - add JNI code for the new libucrypto digest APIs - code refactoring, e.g. move the libmd-related code to classes with MD suffix - run-time mechanism number assignment (used to be hardcoded values) - better error reporting RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Thu May 5 03:06:34 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 May 2016 11:06:34 +0800 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <572AAB34.9030809@oracle.com> References: <572AAB34.9030809@oracle.com> Message-ID: <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> Hi Valerie This is not exactly a code review. I noticed you've updated static void l2bBig(long[] in, int inOfs, byte[] out, int outOfs, int len) in ByteArrayAccess.java. I also updated it during the implementation of SHA-512/224 (a part of DRBG) because here len is 28 but the original l2bBig assumes len % 8 == 0. My change is @@ -448,10 +448,12 @@ - out[outOfs++] = (byte)(i >> 24); - out[outOfs++] = (byte)(i >> 16); - out[outOfs++] = (byte)(i >> 8); - out[outOfs++] = (byte)(i ); + if (outOfs < len) { // SHA-512/224 is 28 bytes + out[outOfs++] = (byte) (i >> 24); + out[outOfs++] = (byte) (i >> 16); + out[outOfs++] = (byte) (i >> 8); + out[outOfs++] = (byte) (i); + } So this assumes len % 4 == 0. If you follow this, you might need to add Unsafe.putInt for the last 4 bytes. On the other hand, if you think len % 8 == 0 should always be true, I can do some expand-and-shrink inside SHA5.java. My DRBG chanegset is not pushed yet. Thanks Max > On May 5, 2016, at 10:08 AM, 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 be reviewed in a week or so, that'd be great. > > The changes for SUN providers are quite straight-forward, e.g. SHA-3 digest impls based on FIPS PUB 202. > As for OracleUcrypto provider, Solaris SHA-3 support is through new libucrypto digest APIs (added in Solaris 12) instead of the libmd. > When running on Solaris 12, the new libucrypto APIs will be used. Otherwise, libmd will be used. > Changes for OracleUcrypto providers: > - add JNI code for the new libucrypto digest APIs > - code refactoring, e.g. move the libmd-related code to classes with MD suffix > - run-time mechanism number assignment (used to be hardcoded values) > - better error reporting > > RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 > Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ > > Thanks, > Valerie From weijun.wang at oracle.com Thu May 5 08:16:11 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 May 2016 16:16:11 +0800 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> References: <572AAB34.9030809@oracle.com> <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> Message-ID: <2E3D9C73-D599-4ACA-B078-321E32FFCDD7@oracle.com> > On May 5, 2016, at 11:06 AM, Wang Weijun wrote: > > So this assumes len % 4 == 0. > > If you follow this, you might need to add Unsafe.putInt for the last 4 bytes. > > On the other hand, if you think len % 8 == 0 should always be true, I can do some expand-and-shrink inside SHA5.java. My DRBG chanegset is not pushed yet. I decided not to touch ByteArrayAccess.java. Instead, for SHA-512/224, I will use int len = engineGetDigestLength(); if (len == 28) { // Special case for SHA-512/224 l2bBig(state, 0, out, ofs, 24); i2bBig4((int)(state[3] >> 32), out, ofs + 24); } else { l2bBig(state, 0, out, ofs, len); } Maybe we should add a check in l2bBig etc. Thanks Max From weijun.wang at oracle.com Thu May 5 08:34:55 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 May 2016 16:34:55 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <89757dba-98b1-9208-df00-7647a880e9ea@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> <50FC89C3-C2E1-4DB3-BE40-BC118AF3945F@oracle.com> <89757dba-98b1-9208-df00-7647a880e9ea@oracle.com> Message-ID: <77929847-9FE2-442E-B736-6F578B2CB697@oracle.com> Hi Brad I did't expect I need a new updated version at http://cr.openjdk.java.net/~weijun/8051408/webrev.14/ Changes include: 1. The new wording you suggested below. 2. All health-test related codes (even if they were not called in webrev.13 at all) removed. 3. Revert the change in ByteArrayAccess.java [1] and make proper change in SHA5.java. Valerie will be making more changes to this file and I'd better not touch it. No new spec/ and specdiff/ generated. In fact, I haven't grayed out webrev.13/index.html at all. Bonus: new interdiff link [2]. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8051408/webrev.13/src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java.udiff.html [2] http://cr.openjdk.java.net/~weijun/8051408/webrev.14/interdiff.patch.html > On Apr 29, 2016, at 2:46 AM, Bradford Wetmore wrote: > > We were on the same page after all. I completely misunderstood your point in a previous email. What you have is fine (change limit->limited), or a minor suggestion below (take it or leave it): > > Some random number generators can only generate a limit amount > of random bytes per invocation. If the size of {@code bytes} > is greater than this limit, the implementation should invoke > the process multiple times to generate enough random bytes > in a single {@code engineNextBytes} call. > -> > Some random number generators can only generate a limited amount > of random bytes per invocation. If the size of {@code bytes} > is greater than this limit, the implementation should invoke > its generation process multiple times to completely fill the > buffer before returning from this method. From mstjohns at comcast.net Thu May 5 17:57:49 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 5 May 2016 13:57:49 -0400 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <572AAB34.9030809@oracle.com> References: <572AAB34.9030809@oracle.com> Message-ID: Quick side question - how does the "Standard Algorithm Names" doc get updated to include SHA3 stuff? Should it be folded into this change or? Mike On 5/4/2016 10: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 be reviewed in a week or so, that'd be great. > > The changes for SUN providers are quite straight-forward, e.g. SHA-3 > digest impls based on FIPS PUB 202. > As for OracleUcrypto provider, Solaris SHA-3 support is through new > libucrypto digest APIs (added in Solaris 12) instead of the libmd. > When running on Solaris 12, the new libucrypto APIs will be used. > Otherwise, libmd will be used. > Changes for OracleUcrypto providers: > - add JNI code for the new libucrypto digest APIs > - code refactoring, e.g. move the libmd-related code to classes with > MD suffix > - run-time mechanism number assignment (used to be hardcoded values) > - better error reporting > > RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 > Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ > > Thanks, > Valerie From valerie.peng at oracle.com Thu May 5 23:38:01 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 05 May 2016 16:38:01 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: References: <572AAB34.9030809@oracle.com> Message-ID: <572BD959.3080906@oracle.com> There is a separate bug id to keep track of the doc changes, see https://bugs.openjdk.java.net/browse/JDK-8004078 Valerie On 5/5/2016 10:57 AM, Michael StJohns wrote: > Quick side question - how does the "Standard Algorithm Names" doc get > updated to include SHA3 stuff? Should it be folded into this change or? > > Mike > > > On 5/4/2016 10: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 be reviewed in a week or so, that'd be great. >> >> The changes for SUN providers are quite straight-forward, e.g. SHA-3 >> digest impls based on FIPS PUB 202. >> As for OracleUcrypto provider, Solaris SHA-3 support is through new >> libucrypto digest APIs (added in Solaris 12) instead of the libmd. >> When running on Solaris 12, the new libucrypto APIs will be used. >> Otherwise, libmd will be used. >> Changes for OracleUcrypto providers: >> - add JNI code for the new libucrypto digest APIs >> - code refactoring, e.g. move the libmd-related code to classes with >> MD suffix >> - run-time mechanism number assignment (used to be hardcoded values) >> - better error reporting >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 >> Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ >> >> Thanks, >> Valerie > > From valerie.peng at oracle.com Thu May 5 23:42:42 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 05 May 2016 16:42:42 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> References: <572AAB34.9030809@oracle.com> <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> Message-ID: <572BDA72.4020107@oracle.com> I think we should continue with the "len should be multiples of 8" assumption for l2bBig. Just like other methods in ByteArrayAccess.java, when len should be multiples of 4 when dealing with int[], and multiples of 8 when dealing with long[]. Valerie On 5/4/2016 8:06 PM, Wang Weijun wrote: > Hi Valerie > > This is not exactly a code review. > > I noticed you've updated > > static void l2bBig(long[] in, int inOfs, byte[] out, int outOfs, int len) > > in ByteArrayAccess.java. > > I also updated it during the implementation of SHA-512/224 (a part of DRBG) because here len is 28 but the original l2bBig assumes len % 8 == 0. > > My change is > > @@ -448,10 +448,12 @@ > - out[outOfs++] = (byte)(i>> 24); > - out[outOfs++] = (byte)(i>> 16); > - out[outOfs++] = (byte)(i>> 8); > - out[outOfs++] = (byte)(i ); > + if (outOfs< len) { // SHA-512/224 is 28 bytes > + out[outOfs++] = (byte) (i>> 24); > + out[outOfs++] = (byte) (i>> 16); > + out[outOfs++] = (byte) (i>> 8); > + out[outOfs++] = (byte) (i); > + } > > So this assumes len % 4 == 0. > > If you follow this, you might need to add Unsafe.putInt for the last 4 bytes. > > On the other hand, if you think len % 8 == 0 should always be true, I can do some expand-and-shrink inside SHA5.java. My DRBG chanegset is not pushed yet. > > Thanks > Max > >> On May 5, 2016, at 10:08 AM, 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 be reviewed in a week or so, that'd be great. >> >> The changes for SUN providers are quite straight-forward, e.g. SHA-3 digest impls based on FIPS PUB 202. >> As for OracleUcrypto provider, Solaris SHA-3 support is through new libucrypto digest APIs (added in Solaris 12) instead of the libmd. >> When running on Solaris 12, the new libucrypto APIs will be used. Otherwise, libmd will be used. >> Changes for OracleUcrypto providers: >> - add JNI code for the new libucrypto digest APIs >> - code refactoring, e.g. move the libmd-related code to classes with MD suffix >> - run-time mechanism number assignment (used to be hardcoded values) >> - better error reporting >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 >> Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ >> >> Thanks, >> Valerie From valerie.peng at oracle.com Thu May 5 23:44:26 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 05 May 2016 16:44:26 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <2E3D9C73-D599-4ACA-B078-321E32FFCDD7@oracle.com> References: <572AAB34.9030809@oracle.com> <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> <2E3D9C73-D599-4ACA-B078-321E32FFCDD7@oracle.com> Message-ID: <572BDADA.2090000@oracle.com> Yes, I think it's better to deal with this before you call the methods in ByteArrayAccess class. Your code snippet looks good. Valerie On 5/5/2016 1:16 AM, Wang Weijun wrote: >> On May 5, 2016, at 11:06 AM, Wang Weijun wrote: >> >> So this assumes len % 4 == 0. >> >> If you follow this, you might need to add Unsafe.putInt for the last 4 bytes. >> >> On the other hand, if you think len % 8 == 0 should always be true, I can do some expand-and-shrink inside SHA5.java. My DRBG chanegset is not pushed yet. > I decided not to touch ByteArrayAccess.java. Instead, for SHA-512/224, I will use > > int len = engineGetDigestLength(); > if (len == 28) { > // Special case for SHA-512/224 > l2bBig(state, 0, out, ofs, 24); > i2bBig4((int)(state[3]>> 32), out, ofs + 24); > } else { > l2bBig(state, 0, out, ofs, len); > } > > Maybe we should add a check in l2bBig etc. > > Thanks > Max > From weijun.wang at oracle.com Fri May 6 00:50:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 May 2016 08:50:32 +0800 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <572BDADA.2090000@oracle.com> References: <572AAB34.9030809@oracle.com> <39CB6975-974C-43BB-BECA-D1536FEB03A1@oracle.com> <2E3D9C73-D599-4ACA-B078-321E32FFCDD7@oracle.com> <572BDADA.2090000@oracle.com> Message-ID: > On May 6, 2016, at 7:44 AM, Valerie Peng wrote: > > > Yes, I think it's better to deal with this before you call the methods in ByteArrayAccess class. > Your code snippet looks good. > Valerie > Good. Then the only conflict between our changesets is we both updated copyright year of SunEntries.java. This is the reason why I don't like updating the year myself but seems every reviewer wants me to do that. :-) --Max From xuelei.fan at oracle.com Fri May 6 04:14:03 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 6 May 2016 12:14:03 +0800 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them In-Reply-To: <487f2498-b83e-df1d-eb35-957ab74fb290@oracle.com> References: <571A5ACE.1010905@oracle.com> <571F49B7.30307@oracle.com> <571F73A3.5060409@oracle.com> <571F7C31.6010004@oracle.com> <487f2498-b83e-df1d-eb35-957ab74fb290@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 5/4/2016 9:38 PM, Ivan Gerasimov wrote: > Thank you Xuelei for looking into this! > > > On 26.04.2016 17:33, Xuelei Fan wrote: >> jdk.tls.handleCertReqAuthoritesOverflow is a little bit long. >> jdk.tls.server.overFlowAuthorites? > Yes, I agree. > Changed to a shorter property name. > >> May not need to define the "none" property value. >> >> Using enum for HAO_NONE, HAO_EMPTY and HAO_TRUNC? > Changed to enum. > Have to keep NONE, though, as we need to represent it in the enum somehow. > >> line 1920: Overflow should be rare, what about print only when overflow? > It the indication of overflow is printed only when it has happened. > > Please find the updated version of webrev: > http://cr.openjdk.java.net/~igerasim/8154947/02/webrev/ > > With kind regards, > Ivan > >> Xuelei >> >> On 4/26/2016 9:56 PM, Se?n Coffey wrote: >>> Looks like a fair approach to solving this issue Ivan. A few comments >>> from me : >>> >>> typo : authoririesOverflow --> authoritiesOverflow >>> typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow >>> typo : jdk.tls.handleCertReqAuthoritesOverflow --> >>> jdk.tls.handleCertReqAuthoritiesOverflow >>> >>> + throw new RuntimeException("Value of " + prop >>> + + " must be one of '" + HAO_NONE + "', '" >>> + + HAO_EMPTY + "', '" + HAO_TRUNC + "'"); >>> >>> I think it would be good to print the value of s in above exception >>> also. something like + ". Received: \"" + s + "\""); >>> == >>> >>> s.println("Cert Authorities:" + (authoririesOverflow ? " (overflow)" : >>> "")); >>> >>> I would also be good to indicate the handleAuthoritiesOverflow string >>> value in above printing *if* authoritiesOverflow turns out to be true. >>> We should be able to determine from the next message printed - but no >>> harm to future proof. >>> Maybe : >>> >>> s.println("Cert Authorities:" + (authoritiesOverflow ? " (overflow" + >>> "[" + handleAuthoritiesOverflow + "])" : "")); >>> >>> Regards, >>> Sean. >>> >>> On 26/04/2016 11:57, Ivan Gerasimov wrote: >>>> Here's a modified version of the fix. >>>> >>>> Instead of a boolean-type property, a string-type property is >>>> introduced. >>>> It is used to specify the strategy to use, if we encounter the >>>> overflow during filling the list of authorities. >>>> >>>> The default strategy is to throw an exception (just like the currently >>>> implemented behavior.) >>>> >>>> It can also be set to the values 'empty' or 'truncate', which will >>>> make the server to send an empty or truncated list upon overflow. >>>> >>>> Would you please help review it? >>>> >>>> http://cr.openjdk.java.net/~igerasim/8154947/01/webrev/ >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> >>>> On 22.04.2016 20:09, Ivan Gerasimov wrote: >>>>> Hello everyone! >>>>> >>>>> During TLS handshake, a server may be required to send a >>>>> CertificateRequest, which contains a list of authorities. >>>>> If the list happens to be too long, the server is throwing an >>>>> exception, indicating an overflow. >>>>> >>>>> It may be convenient to be able to just drop the list altogether, and >>>>> let the client to choose a certificate randomly. >>>>> In certain situation this may be more preferable that just block >>>>> communication. >>>>> >>>>> Would you please help review a patch, which introduces an >>>>> command-line option that controls this behavior of the server? >>>>> If the approach is approved, I'll file a CCC request for that option. >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ >>>>> >>>>> With the proposed fix all the security-related regression tests, >>>>> including the modified one, passed on all supported platforms. >>>>> >>>>> With kind regards, >>>>> Ivan >>>>> >>>>> >> > From xuelei.fan at oracle.com Fri May 6 14:40:20 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 6 May 2016 22:40:20 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris Message-ID: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> Hi, Please review this simple test failure fix: http://cr.openjdk.java.net/~xuelei/8154344/webrev.00/ The underlying crypto lib may generate DH private keys out of the normal expected range. This fix removes the range checking for DH private keys. Thanks, Xuelei From mstjohns at comcast.net Fri May 6 17:17:14 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 6 May 2016 13:17:14 -0400 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> Message-ID: On 5/6/2016 10:40 AM, Xuelei Fan wrote: > Hi, > > Please review this simple test failure fix: > > http://cr.openjdk.java.net/~xuelei/8154344/webrev.00/ > > The underlying crypto lib may generate DH private keys out of the normal > expected range. This fix removes the range checking for DH private keys. > > Thanks, > Xuelei I'm confused about this. I read the code and reviewed NIST SP800-56A Rev 1, section 5.6.2.4 and the check you're commenting out is the correct check for validity. If the provider is failing this check, shouldn't the provider be fixed? I.e. the test is failing as expected. If you still want to open up this code, then I'd probably add the second test for the public key: if (y.modPow(q,p).compareTo(BigInteger.ONE) != 0) throw new Exception (...); I'd probably also compare the params in both public and private keys for equality at the beginning of the checkKeyPair test and then dump the second check for p.bitSize(). From svetlana.nikandrova at oracle.com Fri May 6 18:14:06 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 06 May 2016 21:14:06 +0300 Subject: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings In-Reply-To: <572249EB.8090808@oracle.com> References: <572249EB.8090808@oracle.com> Message-ID: <572CDEEE.80108@oracle.com> Hello, I would be grateful if someone could find time to review this. I received few off-line notes and decided to rework this backport a little. Here is my new webrev: http://cr.openjdk.java.net/~snikandrova/8049171/webrev.01/ List of current changes from original patch: 1) No ProcessTools.java changes in webrev as they have been backported earlier. 2) Utils.java : new utility method transferBetweenStreams meant to be used instead of InputStream's transferTo method that is present since 9. 3) JarUtils.java: changes in createJar method to consider a situation then files aren't located in current directory. 4) NestedActions.java: refactored to use JarUtils method to create jars. 5) TimestampCheck.java - omitted System.getProperty("test.tool.vm.opts") that is not used in jdk 8 testing. 6) Used System.getProperty("test.jdk") instead of System.getProperty("java.home") in tests. Thank you, Svetlana On 28.04.2016 20:35, Svetlana Nikandrova wrote: > Hello, > > please review and approve the backport of tests enhancement: > Original tests from > https://bugs.openjdk.java.net/browse/JDK-8049171 > jdk 9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031006.html > jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5c61ccd9c162 > Originally reviewed by Max Wang > > Webrev: > http://cr.openjdk.java.net/~snikandrova/8049171/webrev.00/ > > > List of changes between original patch and current webrev: > > 1) No ProcessTools.java changes as they have been backported earlier. > 2) JarUtils.java : private method transferToOutputStream instead > ofInputStream's transferTo method (present since 9). > 3) TimestampCheck.java - changes applied by hand to omit > System.getProperty("test.tool.vm.opts") that is not used in jdk 8 testing > 4) Used System.getProperty("test.jdk") instead of > System.getProperty("java.home") > > Tested with JPRT. > > Thank you, > Svetlana -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 6 18:43:51 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 6 May 2016 14:43:51 -0400 Subject: Review Request: 8150468: ClassCircularityError on error in security policy file Message-ID: <572CE5E7.1020606@oracle.com> Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8150468: http://cr.openjdk.java.net/~mullan/webrevs/8150468/webrev.00/ The fix is to record bad policy files as they are parsed and ignore them during any subsequent permission checks. Thanks, Sean From xuelei.fan at oracle.com Fri May 6 23:19:01 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 7 May 2016 07:19:01 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> Message-ID: <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> On 5/7/2016 1:17 AM, Michael StJohns wrote: > On 5/6/2016 10:40 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this simple test failure fix: >> >> http://cr.openjdk.java.net/~xuelei/8154344/webrev.00/ >> >> The underlying crypto lib may generate DH private keys out of the normal >> expected range. This fix removes the range checking for DH private keys. >> >> Thanks, >> Xuelei > > I'm confused about this. I read the code and reviewed NIST SP800-56A > Rev 1, section 5.6.2.4 and the check you're commenting out is the > correct check for validity. If the provider is failing this check, > shouldn't the provider be fixed? > Yes. This is might be a platform crypto lib issue. I want to bring back the testing at first, and open the test again after the issue get fixed. > I.e. the test is failing as expected. > > If you still want to open up this code, then I'd probably add the second > test for the public key: > > if (y.modPow(q,p).compareTo(BigInteger.ONE) != 0) > throw new Exception (...); > > I'd probably also compare the params in both public and private keys for > equality at the beginning of the checkKeyPair test and then dump the > second check for p.bitSize(). > Hm, good suggestions! I will make the update if the test opens later. Thanks, Xuelei From weijun.wang at oracle.com Sat May 7 03:31:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 7 May 2016 11:31:48 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> Message-ID: <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> Or can we put it into problem list for Solaris now? > ? 2016?5?7??07:19?Xuelei Fan ??? > > Yes. This is might be a platform crypto lib issue. I want to bring > back the testing at first, and open the test again after the issue get > fixed. From xuelei.fan at oracle.com Sat May 7 23:59:00 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 8 May 2016 07:59:00 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> Message-ID: <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> I still want the rest part (public key checking) get executed and noticed. I will keep track of the evaluation of the underlying platform crypto lib. Thanks, Xuelei On 5/7/2016 11:31 AM, Wang Weijun wrote: > Or can we put it into problem list for Solaris now? > >> ? 2016?5?7??07:19?Xuelei Fan ??? >> >> Yes. This is might be a platform crypto lib issue. I want to bring >> back the testing at first, and open the test again after the issue get >> fixed. > From weijun.wang at oracle.com Sun May 8 13:06:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 8 May 2016 21:06:28 +0800 Subject: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: References: Message-ID: Ping again. > On May 3, 2016, at 10:26 AM, Wang Weijun wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8154523/webrev.00 > > Basically, a reset in SHA1PRNG should forget the internal state and cached output. > > Thanks > Max > From sibabrata.sahoo at oracle.com Sun May 8 13:57:27 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Sun, 8 May 2016 06:57:27 -0700 (PDT) Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations Message-ID: Hello, Please review the tests for "JDK-8141039:Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations". Bug: https://bugs.openjdk.java.net/browse/JDK-8141039 Webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.00/ The tests covers the new DRBG API with different set of parameters. It also covers the behavior of all SecureRandom mechanism supported in Java in Serialized as well as in multithread context. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sun May 8 14:26:50 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 8 May 2016 22:26:50 +0800 Subject: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: References: Message-ID: <4217aed7-2855-50d1-4f8d-3c639826d60f@oracle.com> On 5/8/2016 9:06 PM, Wang Weijun wrote: > Ping again. > >> On May 3, 2016, at 10:26 AM, Wang Weijun wrote: >> >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8154523/webrev.00 >> >> Basically, a reset in SHA1PRNG should forget the internal state and cached output. >> The spec of SecureRandomSpi.engineSetSeed() says: The given seed supplements, rather than replaces, the existing seed. If I'm understand correctly, reseed is not the same as reset. It should be OK to use the cached output for performance if the previous seed is OK. Xuelei From xuelei.fan at oracle.com Sun May 8 15:12:06 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 8 May 2016 23:12:06 +0800 Subject: Code Review Request: 8156502, Use short name of SupportedEllipticCurvesExtension.java Message-ID: Hi, Please review this class name update: http://cr.openjdk.java.net/~xuelei/8156502/webrev.00/ The class names of SupportedEllipticCurvesExtension and SupportedEllipticPointFormatsExtension are very long. The source codes using the class names are likely to exceed 80 characters each line. Better to use short names. Thanks, Xuelei From vincent.x.ryan at oracle.com Sun May 8 15:26:29 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sun, 8 May 2016 16:26:29 +0100 Subject: Code Review Request: 8156502, Use short name of SupportedEllipticCurvesExtension.java In-Reply-To: References: Message-ID: <642AC96D-BA17-475A-B222-9DB0B214C1AE@oracle.com> Your change looks fine to me. Thanks. > On 8 May 2016, at 16:12, Xuelei Fan wrote: > > Hi, > > Please review this class name update: > > http://cr.openjdk.java.net/~xuelei/8156502/webrev.00/ > > The class names of SupportedEllipticCurvesExtension and > SupportedEllipticPointFormatsExtension are very long. The source codes > using the class names are likely to exceed 80 characters each line. > Better to use short names. > > Thanks, > Xuelei From mstjohns at comcast.net Sun May 8 20:22:46 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Sun, 8 May 2016 16:22:46 -0400 Subject: SecureRandom serializable?? was: Re: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: References: Message-ID: <92df3fc0-ec54-716f-bb36-7d021d0dbfb7@comcast.net> Does anyone else think there's something wrong with SecureRandom being serializable? In general, the internal state of a random number generator shouldn't be extract-able or even saveable. I realize this behavior has probably been in the class since the beginning - but I hadn't actually read this code until I saw the review request. Mike On 5/8/2016 9:06 AM, Wang Weijun wrote: > Ping again. > >> On May 3, 2016, at 10:26 AM, Wang Weijun wrote: >> >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8154523/webrev.00 >> >> Basically, a reset in SHA1PRNG should forget the internal state and cached output. >> >> Thanks >> Max >> From weijun.wang at oracle.com Sun May 8 23:08:35 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 May 2016 07:08:35 +0800 Subject: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: <4217aed7-2855-50d1-4f8d-3c639826d60f@oracle.com> References: <4217aed7-2855-50d1-4f8d-3c639826d60f@oracle.com> Message-ID: <88C52600-69F1-4FC8-8289-790B1E8ED8B2@oracle.com> > On May 8, 2016, at 10:26 PM, Xuelei Fan wrote: > > On 5/8/2016 9:06 PM, Wang Weijun wrote: >> Ping again. >> >>> On May 3, 2016, at 10:26 AM, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8154523/webrev.00 >>> >>> Basically, a reset in SHA1PRNG should forget the internal state and cached output. >>> > The spec of SecureRandomSpi.engineSetSeed() says: > > The given seed supplements, rather than replaces, the existing seed. I think this is to encourage people to call setSeed() even if the caller cannot find a perfect seed, as any new call won't make randomness worse. > > If I'm understand correctly, reseed is not the same as reset. It should > be OK to use the cached output for performance if the previous seed is OK. Well, it's almost reset. One calls setSeed() hoping new entropy is added and the output changes. Calling setSeed() is not a common thing and I think it's OK to ignore the performance impact here. Non predictability is quite crucial for a SecureRandom. Thanks Max > > Xuelei From weijun.wang at oracle.com Sun May 8 23:09:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 May 2016 07:09:45 +0800 Subject: SecureRandom serializable?? was: Re: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: <92df3fc0-ec54-716f-bb36-7d021d0dbfb7@comcast.net> References: <92df3fc0-ec54-716f-bb36-7d021d0dbfb7@comcast.net> Message-ID: <5FBB0520-3DEC-464C-B75D-2A8551E0F47F@oracle.com> > On May 9, 2016, at 4:22 AM, Michael StJohns wrote: > > Does anyone else think there's something wrong with SecureRandom being serializable? In general, the internal state of a random number generator shouldn't be extract-able or even savable. You are right. That's why we decide to make DRBG not so serializable. Settings are saved but not the internal states. --Max > > I realize this behavior has probably been in the class since the beginning - but I hadn't actually read this code until I saw the review request. > > Mike From jim.manico at owasp.org Mon May 9 02:48:12 2016 From: jim.manico at owasp.org (Jim Manico) Date: Sun, 8 May 2016 16:48:12 -1000 Subject: SecureRandom serializable?? was: Re: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: <92df3fc0-ec54-716f-bb36-7d021d0dbfb7@comcast.net> References: <92df3fc0-ec54-716f-bb36-7d021d0dbfb7@comcast.net> Message-ID: I would say that there are certain member-objects of SecureRandom that should be transient like the seed, but some things like the provider implementation might have a legit use case to serialize. I'd rather there be an error in Deserializing a SecureRandom instance with a provider error than a different JVM/JRE downgrading to a weak provider without an error. - Jim On 5/8/16 10:22 AM, Michael StJohns wrote: > Does anyone else think there's something wrong with SecureRandom being > serializable? In general, the internal state of a random number > generator shouldn't be extract-able or even saveable. > > I realize this behavior has probably been in the class since the > beginning - but I hadn't actually read this code until I saw the > review request. > > Mike > > > On 5/8/2016 9:06 AM, Wang Weijun wrote: >> Ping again. >> >>> On May 3, 2016, at 10:26 AM, Wang Weijun >>> wrote: >>> >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8154523/webrev.00 >>> >>> Basically, a reset in SHA1PRNG should forget the internal state and >>> cached output. >>> >>> Thanks >>> Max >>> > From weijun.wang at oracle.com Mon May 9 03:51:13 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 May 2016 11:51:13 +0800 Subject: RFR 8156501: DRBG not synchronized at reseeding Message-ID: Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8156501/webrev.00 Many thanks to Siba for discovering this problem. I have only benchmarked nextBytes() before. Some clarifications: 1. No need to synchronize configure anymore() because it's always called inside a constructor. 2. synchronized-between-double-check in engineNextBytes() to protect reseedCounter. Thanks Max From xuelei.fan at oracle.com Mon May 9 14:36:01 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 9 May 2016 22:36:01 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> Message-ID: Updated to ignore the test on Solaris only: http://cr.openjdk.java.net/~xuelei/8154344/webrev.01/ Thanks, Xuelei On 5/8/2016 7:59 AM, Xuelei Fan wrote: > I still want the rest part (public key checking) get executed and > noticed. I will keep track of the evaluation of the underlying platform > crypto lib. > > Thanks, > Xuelei > > On 5/7/2016 11:31 AM, Wang Weijun wrote: >> Or can we put it into problem list for Solaris now? >> >>> ? 2016?5?7??07:19?Xuelei Fan ??? >>> >>> Yes. This is might be a platform crypto lib issue. I want to bring >>> back the testing at first, and open the test again after the issue get >>> fixed. >> > From weijun.wang at oracle.com Mon May 9 14:54:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 May 2016 22:54:32 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> Message-ID: <5819A927-F69E-420C-8820-50327D309564@oracle.com> This looks good. Thanks Max > ? 2016?5?9??22:36?Xuelei Fan ??? > > Updated to ignore the test on Solaris only: > > http://cr.openjdk.java.net/~xuelei/8154344/webrev.01/ > > Thanks, > Xuelei > >> On 5/8/2016 7:59 AM, Xuelei Fan wrote: >> I still want the rest part (public key checking) get executed and >> noticed. I will keep track of the evaluation of the underlying platform >> crypto lib. >> >> Thanks, >> Xuelei >> >>> On 5/7/2016 11:31 AM, Wang Weijun wrote: >>> Or can we put it into problem list for Solaris now? >>> >>>> ? 2016?5?7??07:19?Xuelei Fan ??? >>>> >>>> Yes. This is might be a platform crypto lib issue. I want to bring >>>> back the testing at first, and open the test again after the issue get >>>> fixed. > From mstjohns at comcast.net Mon May 9 16:16:00 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 9 May 2016 12:16:00 -0400 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> Message-ID: <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> You're going to hate me, but shouldn't this be checking the Provider rather than the OS when trying to determine which test to ignore? Mike On 5/9/2016 10:36 AM, Xuelei Fan wrote: > Updated to ignore the test on Solaris only: > > http://cr.openjdk.java.net/~xuelei/8154344/webrev.01/ > > Thanks, > Xuelei > > On 5/8/2016 7:59 AM, Xuelei Fan wrote: >> I still want the rest part (public key checking) get executed and >> noticed. I will keep track of the evaluation of the underlying platform >> crypto lib. >> >> Thanks, >> Xuelei >> >> On 5/7/2016 11:31 AM, Wang Weijun wrote: >>> Or can we put it into problem list for Solaris now? >>> >>>> ? 2016?5?7??07:19?Xuelei Fan ??? >>>> >>>> Yes. This is might be a platform crypto lib issue. I want to bring >>>> back the testing at first, and open the test again after the issue get >>>> fixed. From xuelei.fan at oracle.com Mon May 9 23:58:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 May 2016 07:58:18 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> Message-ID: On 5/10/2016 12:16 AM, Michael StJohns wrote: > You're going to hate me, but shouldn't this be checking the Provider > rather than the OS when trying to determine which test to ignore? > It's more accurate to check the provider, too. - if (!System.getProperty("os.name").equals("SunOS")) { + if (provider.getName().equals("SunPKCS11-Solaris") && + !System.getProperty("os.name").equals("SunOS")) { One of the purpose of code review is asking for suggestions or even objections. I appreciate you feedback very much! Thanks, Xuelei > Mike > > > On 5/9/2016 10:36 AM, Xuelei Fan wrote: >> Updated to ignore the test on Solaris only: >> >> http://cr.openjdk.java.net/~xuelei/8154344/webrev.01/ >> >> Thanks, >> Xuelei >> >> On 5/8/2016 7:59 AM, Xuelei Fan wrote: >>> I still want the rest part (public key checking) get executed and >>> noticed. I will keep track of the evaluation of the underlying platform >>> crypto lib. >>> >>> Thanks, >>> Xuelei >>> >>> On 5/7/2016 11:31 AM, Wang Weijun wrote: >>>> Or can we put it into problem list for Solaris now? >>>> >>>>> ? 2016?5?7??07:19?Xuelei Fan ??? >>>>> >>>>> Yes. This is might be a platform crypto lib issue. I want to bring >>>>> back the testing at first, and open the test again after the issue get >>>>> fixed. > > From xuelei.fan at oracle.com Tue May 10 00:25:53 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 May 2016 08:25:53 +0800 Subject: Review Request: 8150468: ClassCircularityError on error in security policy file In-Reply-To: <572CE5E7.1020606@oracle.com> References: <572CE5E7.1020606@oracle.com> Message-ID: Looks fine to me except a minor comment. PolicyParser.java ================= 1366 return i18nMessage != null ? i18nMessage : form.format(source); May be nice to set the i18nMessage if it is not set yet. Thanks, Xuelei On 5/7/2016 2:43 AM, Sean Mullan wrote: > Please review this fix for > https://bugs.openjdk.java.net/browse/JDK-8150468: > > http://cr.openjdk.java.net/~mullan/webrevs/8150468/webrev.00/ > > The fix is to record bad policy files as they are parsed and ignore them > during any subsequent permission checks. > > Thanks, > Sean From mandy.chung at oracle.com Tue May 10 01:20:17 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 May 2016 18:20:17 -0700 Subject: Review Request: 8150468: ClassCircularityError on error in security policy file In-Reply-To: <572CE5E7.1020606@oracle.com> References: <572CE5E7.1020606@oracle.com> Message-ID: <09C4DB07-1429-4FBB-AC49-A571343B097C@oracle.com> > On May 6, 2016, at 11:43 AM, Sean Mullan wrote: > > Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8150468: > > http://cr.openjdk.java.net/~mullan/webrevs/8150468/webrev.00/ > > The fix is to record bad policy files as they are parsed and ignore them during any subsequent permission checks. Looks okay. PolicyFile::init catches ParsingException that always calls ParsingException::getLocalizedMessage and prints the localized message. Is that necessary? We don?t typically localize the exception message if thrown at runtime. Mandy From xueming.shen at oracle.com Tue May 10 05:36:29 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 9 May 2016 22:36:29 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <56EC5F76.4080106@oracle.com> References: <56EC5F76.4080106@oracle.com> Message-ID: <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears sun.security.util.Debug is being initialized even before the lambda is ready for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated to use lambda function in the proposed regex change. Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to solve/workaround this specific initialization issue. The webrev below has been updated to include such a change. http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ The sun.security.util.Debug related change is at http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html Can security-dev guys help take a look if this is an acceptable/reasonable approach. Thanks, Sherman ----------------------------------------------------------------------------- Caused by: java.lang.ExceptionInInitializerError at jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110) at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497) at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492) ... at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) at java.util.regex.Pattern.(java.base/Pattern.java:5682) at sun.security.util.Debug.marshal(java.base/Debug.java:247) at sun.security.util.Debug.(java.base/Debug.java:59) at java.security.ProtectionDomain.(java.base/ProtectionDomain.java:142) at jdk.internal.misc.InnocuousThread.(java.base/InnocuousThread.java:129) at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48) at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45) at java.security.AccessController.doPrivileged(java.base/Native Method) at jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45) at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116) at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203) at jdk.internal.ref.CleanerFactory.(java.base/CleanerFactory.java:42) at sun.nio.fs.NativeBuffer.(java.base/NativeBuffer.java:60) at sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49) at sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44) at sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306) at sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514) at java.nio.file.Files.isRegularFile(java.base/Files.java:2244) at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105) at java.lang.System.initPhase2(java.base/System.java:1924) --------------------------------------------------------------------------------- On 3/18/16 1:05 PM, Xueming Shen wrote: > Hi, > > There are couple regex related changes waiting for review. I have pull > them > together here (with the notes) to make it easy to review. > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > (1) Exponential backtracking > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking > > https://bugs.openjdk.java.net/browse/JDK-6328855 > https://bugs.openjdk.java.net/browse/JDK-6192895 > https://bugs.openjdk.java.net/browse/JDK-6345469 > https://bugs.openjdk.java.net/browse/JDK-6988218 > https://bugs.openjdk.java.net/browse/JDK-6693451 > https://bugs.openjdk.java.net/browse/JDK-7006761 > https://bugs.openjdk.java.net/browse/JDK-8140212 > > (2) Anonymous class to lambda function cleanup > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction > > https://bugs.openjdk.java.net/browse/JDK-8151481 > https://bugs.openjdk.java.net/browse/JDK-6609854 > > (3) Canonical Equivalents > > Note: > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ > > https://bugs.openjdk.java.net/browse/JDK-4916384 > https://bugs.openjdk.java.net/browse/JDK-4867170 > https://bugs.openjdk.java.net/browse/JDK-6995635 > https://bugs.openjdk.java.net/browse/JDK-6728861 > https://bugs.openjdk.java.net/browse/JDK-6736245 > https://bugs.openjdk.java.net/browse/JDK-7080302 > > Thanks > Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 10 06:33:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 May 2016 14:33:45 +0800 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> Message-ID: <58DED32A-5F2B-4DA2-ABFD-523049922EDE@oracle.com> Security-dev, If we can live with "engine=keystore" happily, why not just make the whole string lowercase and search for "permission=java.io.filepermission"? I don't think there are permission types or URL names that are only different in cases. Although file names are case-sensitive in Unix, I doubt if any customer will complain if we show him info on /ETC even if what he sets is "codebase=/etc". We can add new methods like hasCodebase(URL) and hasPermission(Class) to hide the search details inside Debug. Thanks Max > On May 10, 2016, at 1:36 PM, Xueming Shen wrote: > > Hi, > > While testing for the attached regex changes, a fatal vm init error was triggered for test > case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. > > It appears sun.security.util.Debug is being initialized even before the lambda is ready > for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated > to use lambda function in the proposed regex change. > > Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it > is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to > solve/workaround this specific initialization issue. > > The webrev below has been updated to include such a change. > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > The sun.security.util.Debug related change is at > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html > > Can security-dev guys help take a look if this is an acceptable/reasonable approach. > > Thanks, > Sherman > > ----------------------------------------------------------------------------- > Caused by: java.lang.ExceptionInInitializerError > > > at jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110) > at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497) > at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492) > ... > at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) > at java.util.regex.Pattern.(java.base/Pattern.java:5682) > at sun.security.util.Debug.marshal(java.base/Debug.java:247) > at sun.security.util.Debug.(java.base/Debug.java:59) > at java.security.ProtectionDomain.(java.base/ProtectionDomain.java:142) > at jdk.internal.misc.InnocuousThread.(java.base/InnocuousThread.java:129) > at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48) > at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45) > at java.security.AccessController.doPrivileged(java.base/Native Method) > at jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45) > at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116) > at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203) > at jdk.internal.ref.CleanerFactory.(java.base/CleanerFactory.java:42) > at sun.nio.fs.NativeBuffer.(java.base/NativeBuffer.java:60) > at sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49) > at sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44) > at sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306) > at sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514) > at java.nio.file.Files.isRegularFile(java.base/Files.java:2244) > at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) > at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105) > at java.lang.System.initPhase2(java.base/System.java:1924) > > --------------------------------------------------------------------------------- > > > On 3/18/16 1:05 PM, Xueming Shen wrote: >> Hi, >> >> There are couple regex related changes waiting for review. I have pull them >> together here (with the notes) to make it easy to review. >> >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> >> (1) Exponential backtracking >> >> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking >> >> https://bugs.openjdk.java.net/browse/JDK-6328855 >> https://bugs.openjdk.java.net/browse/JDK-6192895 >> https://bugs.openjdk.java.net/browse/JDK-6345469 >> https://bugs.openjdk.java.net/browse/JDK-6988218 >> https://bugs.openjdk.java.net/browse/JDK-6693451 >> https://bugs.openjdk.java.net/browse/JDK-7006761 >> https://bugs.openjdk.java.net/browse/JDK-8140212 >> >> (2) Anonymous class to lambda function cleanup >> >> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction >> >> https://bugs.openjdk.java.net/browse/JDK-8151481 >> https://bugs.openjdk.java.net/browse/JDK-6609854 >> >> (3) Canonical Equivalents >> >> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ >> >> https://bugs.openjdk.java.net/browse/JDK-4916384 >> https://bugs.openjdk.java.net/browse/JDK-4867170 >> https://bugs.openjdk.java.net/browse/JDK-6995635 >> https://bugs.openjdk.java.net/browse/JDK-6728861 >> https://bugs.openjdk.java.net/browse/JDK-6736245 >> https://bugs.openjdk.java.net/browse/JDK-7080302 >> >> Thanks >> Sherman > From weijun.wang at oracle.com Tue May 10 06:37:17 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 May 2016 14:37:17 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> Message-ID: <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> > On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: > > On 5/10/2016 12:16 AM, Michael StJohns wrote: >> You're going to hate me, but shouldn't this be checking the Provider >> rather than the OS when trying to determine which test to ignore? >> > It's more accurate to check the provider, too. > > - if (!System.getProperty("os.name").equals("SunOS")) { > + if (provider.getName().equals("SunPKCS11-Solaris") && > + !System.getProperty("os.name").equals("SunOS")) { There is SunPKCS11-Solaris not on SunOS? From weijun.wang at oracle.com Tue May 10 06:44:16 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 May 2016 14:44:16 +0800 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <57276101.7040306@oracle.com> References: <572692CC.8040902@oracle.com> <57276101.7040306@oracle.com> Message-ID: <3C25307D-175A-4306-9B14-8220964C9403@oracle.com> I have a question related. There are some places in JDK that use doPrivileged to read "os.name" etc. This system property is in the default java.policy file > On May 2, 2016, at 10:15 PM, Sean Mullan wrote: > > This is not an issue in your changes, but the current javadoc for Version.current() says: > > 266 * @throws SecurityException > 267 * If a security manager exists and its {@link > 268 * SecurityManager#checkPropertyAccess(String) > 269 * checkPropertyAccess} method does not allow access to the > 270 * system property "java.version" > > but this can never occur since the code is wrapping the call to System.getProperty("java.version") in doPrivileged, so the caller's permissions are never checked. > > I think that this is a bug in the javadoc of this method and that it should not be specified to throw SecurityException. All code already has permission to read "java.version" in the default java.policy file. Can you clarify? If a system property is listed in the default java.policy file, shall we use or not use doPrivileged() to read it inside JDK? I thought the answer is yes because the policy file could be modified. Thanks Max From weijun.wang at oracle.com Tue May 10 07:43:52 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 May 2016 15:43:52 +0800 Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: Message-ID: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> For all: - If you can remember the old "securerandom.drbg.config" value to reset it in a finally clause, there is no need to othervm. - All DRBG mechanism names contain "_DRBG", therefore I'd rather change NON_DRBG.contains(mech) to !mech.contains("_DRBG"). The same technique can be applied everywhere. In fact, you can also add "DRBG" as a test algorithm, i.e. using the default "securerandom.drbg.config". If so, you have to reset the value after every call. GetAlgorithm.java: - You can but check on line 60 into lines 51 and 54, something like check(name, SecureRandom.getInstance(...)) ApiTest.java: - Please remove tests for SHA-1 and "3KEYTDEA" ("3 KEY TDEA", "DESEDE"), we are going to remove them soon. - I don't fully understand what lines 144-147 mean. If an NSAE is thrown, checkException() only fails if alg is invalid. Maybe you should also fail if strength check inside it is false? For example, line 192, it's OK for SHA-1 to fail if strength > 128, but not if it's less. - MoreDrbgParameters is internal. I suggest you stuff info about alg and df inside "securerandom.drbg.config". Probably no need to test nonce and es then. Or, if you still want to test on MoreDrbgParameters, move the test inside sun/security/provider/SecureRandom. EnoughSeedTest.java: - What if SUCCESS has been false once, but turns true in the last loop? Is that a success? Maybe you should "SUCCESS &= ..."? - same with "success" inside forEachSeedBytes? - What's the theory behind this test? Who said seed cannot ends with one or more zero? Zero is just as normal as any other byte which has its own 1/256 of probability to appear. GetInstanceTest.java: - Why name it DRBG_SEC_PROP? - You use MoreDrbgParameters again. Is this necessary? I don't see how the 2 EntropySource are different. MultiThreadTest.java: - Lines 135-144: If it's out System.out.printf, then it's useless. There are theories on quality of RNGs. For example: https://www.random.org/analysis/. SerializedSeedTest.java: - The SHA1PRNG bug is pending. At the moment, can you just generate 32 bytes of data with nextBytes() inside check()? Thanks Max > On May 8, 2016, at 9:57 PM, Sibabrata Sahoo wrote: > > Hello, > > Please review the tests for ?JDK-8141039:Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations?. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8141039 > Webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.00/ > > The tests covers the new DRBG API with different set of parameters. It also covers the behavior of all SecureRandom mechanism supported in Java in Serialized as well as in multithread context. > > Thanks, > Siba From dirk.henselin at autovision-gmbh.com Tue May 10 07:47:04 2016 From: dirk.henselin at autovision-gmbh.com (Henselin, Dirk (A-GDTO-B4)) Date: Tue, 10 May 2016 07:47:04 +0000 Subject: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but... Message-ID: ... I still get the same alias for all of my 3 certificates, even though I use 8u92. Code: KeyStore keyStore = KeyStore.getInstance("Windows-MY", "SunMSCAPI"); keyStore.load(null, null); System.out.println(keyStore.getProvider()); List keyStoreAliases = Collections.list(keyStore.aliases()); for (String alias : keyStoreAliases) { System.out.println(alias + ";@" + System.identityHashCode(alias)); } Output: SunMSCAPI version 1.8 Henselin Dirk VWPKI B768543E5D512393;@14802193 Henselin Dirk VWPKI B768543E5D512393;@564015 Henselin Dirk VWPKI B768543E5D512393;@26856761 Thanks in advance! Mit freundlichen Gr??en / Kind regards Dirk Henselin Diplom-Mathematiker AutoVision GmbH Major-Hirst-Stra?e 11 38442 Wolfsburg dirk.henselin at autovision-gmbh.com www.autovision-gmbh.com Sitz der Gesellschaft: Wolfsburg Amtsgericht Braunschweig: HRB 100516 Gesch?ftsf?hrung: Martin Rosik (Vorsitzender), J?rgen Kl?pffer Ein Unternehmen im Volkswagen Konzern | A Volkswagen Group Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue May 10 08:23:48 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 May 2016 11:23:48 +0300 Subject: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but... In-Reply-To: References: Message-ID: Hello Dirk! On 10.05.2016 10:47, Henselin, Dirk (A-GDTO-B4) wrote: > ? I still get the same alias for all of my 3 certificates, even though > I use 8u92. What is the build number of JDK in use? Could you please provide the output of `java -version`? If it's possible, could you also try the 8u102 early access release, and see if the issue is replicated? It can be downloaded here: https://jdk8.java.net/download.html With kind regards, Ivan > Code: > /KeyStore keyStore = KeyStore.getInstance("Windows-MY", "SunMSCAPI");/ > /keyStore.load(null, null);/ > /System.out.println(keyStore.getProvider());/ > /List keyStoreAliases = Collections.list(keyStore.aliases());/ > /for (String alias : keyStoreAliases) {/ > /System.out.println(alias + ";@" + System.identityHashCode(alias));/ > /}/ > Output: > /SunMSCAPI version 1.8/ > /Henselin Dirk VWPKI B768543E5D512393;@14802193/ > /Henselin Dirk VWPKI B768543E5D512393;@564015/ > /Henselin Dirk VWPKI B768543E5D512393;@26856761/ > Thanks in advance! > Mit freundlichen Gr??en / Kind regards > *Dirk Henselin > *Diplom-Mathematiker > AutoVision GmbH > Major-Hirst-Stra?e 11 > 38442 Wolfsburg > _dirk.henselin at autovision-gmbh.com_ > > _www.autovision-gmbh.com_ > Sitz der Gesellschaft: Wolfsburg > Amtsgericht Braunschweig: HRB 100516 > Gesch?ftsf?hrung: Martin Rosik (Vorsitzender), J?rgen Kl?pffer > *Ein Unternehmen im Volkswagen Konzern | A Volkswagen Group Company* -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue May 10 08:23:51 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 May 2016 16:23:51 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> Message-ID: On 5/10/2016 2:37 PM, Wang Weijun wrote: > >> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: >> >> On 5/10/2016 12:16 AM, Michael StJohns wrote: >>> You're going to hate me, but shouldn't this be checking the Provider >>> rather than the OS when trying to determine which test to ignore? >>> >> It's more accurate to check the provider, too. >> >> - if (!System.getProperty("os.name").equals("SunOS")) { >> + if (provider.getName().equals("SunPKCS11-Solaris") && >> + !System.getProperty("os.name").equals("SunOS")) { > > There is SunPKCS11-Solaris not on SunOS? > SunPKPCS11-NSS may be on SunOS. Xuelei From Alan.Bateman at oracle.com Tue May 10 08:30:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2016 09:30:04 +0100 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> Message-ID: <57319C0C.8070702@oracle.com> On 10/05/2016 06:36, Xueming Shen wrote: > Hi, > > While testing for the attached regex changes, a fatal vm init error > was triggered for test > case with -Djava.security.debug=xyz turned on, as showed in following > stacktrace. > > It appears sun.security.util.Debug is being initialized even before > the lambda is ready > for use, and unfortunately it uses j.u.regex (for its args parsing), > which is being migrated > to use lambda function in the proposed regex change. > > Since Debug is the only class now triggers j.u.regex -> lambda during > initialization, it > is suggested to update/rewrite the related method in Debug to NOT use > j.u.regex to > solve/workaround this specific initialization issue. This is always tricky but I wonder how far we could get by initializing ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move them to a holder class where I wouldn't expect they will be initialized until much later, esp. as the security manager won't be set until later in the initialization (or init phase 3 as we've come to name it). -Alan From dirk.henselin at autovision-gmbh.com Tue May 10 11:55:50 2016 From: dirk.henselin at autovision-gmbh.com (Henselin, Dirk (A-GDTO-B4)) Date: Tue, 10 May 2016 11:55:50 +0000 Subject: AW: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but... In-Reply-To: References: Message-ID: Hello Ivan, Thank you for your quick response! I didn't know, that there are different official builds. I only looked at the version number and used the primary download at http://www.oracle.com/technetwork/java/javase/downloads/index.html which is still b14, but the bug is fixed in b31. I assume that VW is a Java SE customers, so hopefully I can get this build. Thanks a lot! Dirk Von: Ivan Gerasimov [mailto:ivan.gerasimov at oracle.com] Gesendet: Dienstag, 10. Mai 2016 10:24 An: Henselin, Dirk (A-GDTO-B4); security-dev at openjdk.java.net Betreff: Re: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but... Hello Dirk! On 10.05.2016 10:47, Henselin, Dirk (A-GDTO-B4) wrote: ... I still get the same alias for all of my 3 certificates, even though I use 8u92. What is the build number of JDK in use? Could you please provide the output of `java -version`? If it's possible, could you also try the 8u102 early access release, and see if the issue is replicated? It can be downloaded here: https://jdk8.java.net/download.html With kind regards, Ivan Code: KeyStore keyStore = KeyStore.getInstance("Windows-MY", "SunMSCAPI"); keyStore.load(null, null); System.out.println(keyStore.getProvider()); List keyStoreAliases = Collections.list(keyStore.aliases()); for (String alias : keyStoreAliases) { System.out.println(alias + ";@" + System.identityHashCode(alias)); } Output: SunMSCAPI version 1.8 Henselin Dirk VWPKI B768543E5D512393;@14802193 Henselin Dirk VWPKI B768543E5D512393;@564015 Henselin Dirk VWPKI B768543E5D512393;@26856761 Thanks in advance! Mit freundlichen Gr??en / Kind regards Dirk Henselin Diplom-Mathematiker AutoVision GmbH Major-Hirst-Stra?e 11 38442 Wolfsburg dirk.henselin at autovision-gmbh.com www.autovision-gmbh.com Sitz der Gesellschaft: Wolfsburg Amtsgericht Braunschweig: HRB 100516 Gesch?ftsf?hrung: Martin Rosik (Vorsitzender), J?rgen Kl?pffer Ein Unternehmen im Volkswagen Konzern | A Volkswagen Group Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue May 10 12:13:15 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 May 2016 15:13:15 +0300 Subject: AW: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but... In-Reply-To: References: Message-ID: <4ee727f4-83b2-d749-3d7d-7473ef464b46@oracle.com> Thanks for the update! Please let us know, if you encounter any problem with later releases/builds of JDK, which should include the fix. With kind regards, Ivan On 10.05.2016 14:55, Henselin, Dirk (A-GDTO-B4) wrote: > > Hello Ivan, > > Thank you for your quick response! > > I didn?t know, that there are different official builds. I only looked > at the version number and used the primary download at > http://www.oracle.com/technetwork/java/javase/downloads/index.html > > which is still b14, but the bug is fixed in b31. I assume that VW is a > Java SE customers, so hopefully I can get this build. > > Thanks a lot! > > Dirk > > *Von:*Ivan Gerasimov [mailto:ivan.gerasimov at oracle.com] > *Gesendet:* Dienstag, 10. Mai 2016 10:24 > *An:* Henselin, Dirk (A-GDTO-B4); security-dev at openjdk.java.net > *Betreff:* Re: Bug JDK-8153924 "MSCAPI provider does not create unique > alias names" should be fixed in 8u92, but... > > Hello Dirk! > > On 10.05.2016 10:47, Henselin, Dirk (A-GDTO-B4) wrote: > > ? I still get the same alias for all of my 3 certificates, even > though I use 8u92. > > > What is the build number of JDK in use? > Could you please provide the output of `java -version`? > > If it's possible, could you also try the 8u102 early access release, > and see if the issue is replicated? > It can be downloaded here: https://jdk8.java.net/download.html > > With kind regards, > Ivan > > > Code: > > /KeyStore keyStore = KeyStore.getInstance("Windows-MY", "SunMSCAPI");/ > > /keyStore.load(null, null);/ > > /System.out.println(keyStore.getProvider());/ > > /List keyStoreAliases = Collections.list(keyStore.aliases());/ > > /for (String alias : keyStoreAliases) {/ > > /System.out.println(alias + ";@" + System.identityHashCode(alias));/ > > /}/ > > Output: > > /SunMSCAPI version 1.8/ > > /Henselin Dirk VWPKI B768543E5D512393;@14802193/ > > /Henselin Dirk VWPKI B768543E5D512393;@564015/ > > /Henselin Dirk VWPKI B768543E5D512393;@26856761/ > > Thanks in advance! > > Mit freundlichen Gr??en / Kind regards > > *Dirk Henselin > *Diplom-Mathematiker > > AutoVision GmbH > > Major-Hirst-Stra?e 11 > > 38442 Wolfsburg > > dirk.henselin at autovision-gmbh.com > > > www.autovision-gmbh.com > > Sitz der Gesellschaft: Wolfsburg > > Amtsgericht Braunschweig: HRB 100516 > > Gesch?ftsf?hrung: Martin Rosik (Vorsitzender), J?rgen Kl?pffer > > *Ein Unternehmen im Volkswagen Konzern | A Volkswagen Group Company* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 10 13:34:35 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 May 2016 21:34:35 +0800 Subject: RFR 8149521: automatic discovery of LDAP servers with Kerberos authentication Message-ID: <52237C98-3F96-4986-9FF3-22C47234B6EE@oracle.com> Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8149521/webrev.00/ While the bug report [1] suggests we can fix com.sun.jndi.ldap.ServiceLocator to emit a trail-dot-less hostname, I am not sure if it's safe to do so. Anyway, the failure is on the Kerberos side and I believe this is a regression since we stop canonicalizing the hostname. Therefore I prefer to do a small "normalization" inside PrincipalName. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8149521 From markt at apache.org Tue May 10 13:51:44 2016 From: markt at apache.org (Mark Thomas) Date: Tue, 10 May 2016 14:51:44 +0100 Subject: Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread Message-ID: <4284e745-0a8f-09ff-fd96-5bb0027627b6@apache.org> Hi, While working my way through Tomcat's memory leak protection / detection / fixing code, I have found an issue that remains unresolved in the latest JDK 9 source. The poller thread created by the SunPKCS11 class does not explicitly set the context class loader so it inherits the current context class loader. If the current context class loader when this code is triggered happens to be one that is meant to be disposable (e.g. a web application class loader) the class loader will be pinned in memory until the Thread stops. This prevents the class loader from being GC'd when no longer required and triggers a mmeory leak. Given that the creation of this thread depends on various factors, including hardware configuration, the issue is fairly rare but we have seen instances of it reported [1]. The fix looks to be trivial. Something along the lines of the following around line 820 of SunPKCS11: t.setContextClassLoader(SunPKCS11.class.getClassLoader()); If I can provide any further information or if there is better place / way to submit this then please do let me know. Mark [1] http://markmail.org/message/sykuo32eeknwsaqk From vincent.x.ryan at oracle.com Tue May 10 13:52:32 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 May 2016 14:52:32 +0100 Subject: RFR 8149521: automatic discovery of LDAP servers with Kerberos authentication In-Reply-To: <52237C98-3F96-4986-9FF3-22C47234B6EE@oracle.com> References: <52237C98-3F96-4986-9FF3-22C47234B6EE@oracle.com> Message-ID: Looks fine to me Max. Thanks. > On 10 May 2016, at 14:34, Wang Weijun wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8149521/webrev.00/ > > While the bug report [1] suggests we can fix com.sun.jndi.ldap.ServiceLocator to emit a trail-dot-less hostname, I am not sure if it's safe to do so. Anyway, the failure is on the Kerberos side and I believe this is a regression since we stop canonicalizing the hostname. Therefore I prefer to do a small "normalization" inside PrincipalName. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8149521 From sean.mullan at oracle.com Tue May 10 14:57:46 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 May 2016 07:57:46 -0700 Subject: RFR: 8155775: Re-examine naming of privileged methods to access System properties In-Reply-To: <3C25307D-175A-4306-9B14-8220964C9403@oracle.com> References: <572692CC.8040902@oracle.com> <57276101.7040306@oracle.com> <3C25307D-175A-4306-9B14-8220964C9403@oracle.com> Message-ID: <5731F6EA.3090201@oracle.com> On 5/9/16 11:44 PM, Wang Weijun wrote: > I have a question related. > > There are some places in JDK that use doPrivileged to read "os.name" etc. This system property is in the default java.policy file >> On May 2, 2016, at 10:15 PM, Sean Mullan wrote: >> >> This is not an issue in your changes, but the current javadoc for Version.current() says: >> >> 266 * @throws SecurityException >> 267 * If a security manager exists and its {@link >> 268 * SecurityManager#checkPropertyAccess(String) >> 269 * checkPropertyAccess} method does not allow access to the >> 270 * system property "java.version" >> >> but this can never occur since the code is wrapping the call to System.getProperty("java.version") in doPrivileged, so the caller's permissions are never checked. >> >> I think that this is a bug in the javadoc of this method and that it should not be specified to throw SecurityException. All code already has permission to read "java.version" in the default java.policy file. > > Can you clarify? > > If a system property is listed in the default java.policy file, shall we use or not use doPrivileged() to read it inside JDK? I thought the answer is yes because the policy file could be modified. Yes, you should use doPrivileged in that case, since the policy can be modified so you don't necessarily know that the caller has permission to read that property. System.getProperty will still perform a security check. --Sean From mstjohns at comcast.net Tue May 10 14:59:48 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 10 May 2016 10:59:48 -0400 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> Message-ID: On 5/10/2016 2:37 AM, Wang Weijun wrote: >> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: >> >> On 5/10/2016 12:16 AM, Michael StJohns wrote: >>> You're going to hate me, but shouldn't this be checking the Provider >>> rather than the OS when trying to determine which test to ignore? >>> >> It's more accurate to check the provider, too. >> >> - if (!System.getProperty("os.name").equals("SunOS")) { >> + if (provider.getName().equals("SunPKCS11-Solaris") && >> + !System.getProperty("os.name").equals("SunOS")) { > There is SunPKCS11-Solaris not on SunOS? > There may be other Providers on SunOS besides the broken SunPKCS11... Mike From steffen.mueller4 at kit.edu Tue May 10 16:48:11 2016 From: steffen.mueller4 at kit.edu (=?iso-8859-1?Q?M=FCller=2C_Steffen_=28AIFB=29?=) Date: Tue, 10 May 2016 16:48:11 +0000 Subject: AES-NI support Message-ID: Hi, I have a short ? but probably not easy ? question to the sec-dev community, since we have a research project dealing with the performance impact and performance optimizations for TLS: What TLS cipher suites and ciphers, modes of operation, security providers, etc. in general benefit from AES-NI in Java 8/9? I know that the TLS cipher suites using AES-GCM benefit from AES-NI in Java 8. The performance impact in various experiments can be considerable ? measured with OpenJDK and OracleJDK 8u92. Furthermore, I can enable or disable AES-NI support (see, e.g.: https://stackoverflow.com/questions/23058309/aes-ni-intrinsics-enabled-by-de fault). I found the globals.hpp where the UseAES and UseAESIntrinsics is defined, but no further information. The Intel sources stemming from 2012, on the other side, only mention the NSS library (see, e.g.: https://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-o n-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm). In sum, the documentation regarding AES-NI support in Java is very inconsistent. I tried to find more information about this topic, but Is there any further up-to-date documentation regarding AES-NI in Java 8/9? Is there anybody who can give me more information about this topic? Thanks Steffen Mueller -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6281 bytes Desc: not available URL: From sean.mullan at oracle.com Tue May 10 17:23:21 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 May 2016 10:23:21 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57319C0C.8070702@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> Message-ID: <57321909.5080804@oracle.com> On 5/10/16 1:30 AM, Alan Bateman wrote: > On 10/05/2016 06:36, Xueming Shen wrote: >> Hi, >> >> While testing for the attached regex changes, a fatal vm init error >> was triggered for test >> case with -Djava.security.debug=xyz turned on, as showed in following >> stacktrace. >> >> It appears sun.security.util.Debug is being initialized even before >> the lambda is ready >> for use, and unfortunately it uses j.u.regex (for its args parsing), >> which is being migrated >> to use lambda function in the proposed regex change. >> >> Since Debug is the only class now triggers j.u.regex -> lambda during >> initialization, it >> is suggested to update/rewrite the related method in Debug to NOT use >> j.u.regex to >> solve/workaround this specific initialization issue. > This is always tricky but I wonder how far we could get by initializing > ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move > them to a holder class where I wouldn't expect they will be initialized > until much later, esp. as the security manager won't be set until later > in the initialization (or init phase 3 as we've come to name it). Actually, ProtectionDomain already does something like this. It only writes to debug if the policy has been set. See toString(): PermissionCollection pc = Policy.isSet() && seeAllp() ? mergePermissions(): getPermissions(); So, a simpler fix is to extend that concept and not initialize the debug field until Policy.isSet is true. This should resolve this bootstrapping issue. --Sean From sean.mullan at oracle.com Tue May 10 17:53:50 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 May 2016 10:53:50 -0700 Subject: Review Request: 8150468: ClassCircularityError on error in security policy file In-Reply-To: <09C4DB07-1429-4FBB-AC49-A571343B097C@oracle.com> References: <572CE5E7.1020606@oracle.com> <09C4DB07-1429-4FBB-AC49-A571343B097C@oracle.com> Message-ID: <5732202E.40103@oracle.com> On 5/9/16 6:20 PM, Mandy Chung wrote: > >> On May 6, 2016, at 11:43 AM, Sean Mullan >> wrote: >> >> Please review this fix for >> https://bugs.openjdk.java.net/browse/JDK-8150468: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8150468/webrev.00/ >> >> The fix is to record bad policy files as they are parsed and ignore >> them during any subsequent permission checks. > > Looks okay. > > PolicyFile::init catches ParsingException that always calls > ParsingException::getLocalizedMessage and prints the localized > message. Is that necessary? We don?t typically localize the > exception message if thrown at runtime. That's a good question. My initial thought was to simply not localize the exception message: problem solved. But then I noticed that PolicyFile prints the exception message to System.err, which is probably why it is localized: } catch (PolicyParser.ParsingException pe) { MessageFormat form = new MessageFormat(ResourcesMgr.getString (POLICY + ".error.parsing.policy.message")); Object[] source = {policy, pe.getLocalizedMessage()}; System.err.println(form.format(source)); if (debug != null) pe.printStackTrace(); I could remove the printing to System.err (which is generally frowned on anyway), but it has worked this way for a long time, so I don't want to change it. --Sean From xueming.shen at oracle.com Tue May 10 18:04:41 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 May 2016 11:04:41 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57321909.5080804@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57321909.5080804@oracle.com> Message-ID: <573222B9.4020503@oracle.com> Sean, Given the "debug" is a private field and it is used only for debug != null in toString() -> seeAllp(), can the following change be a valid update? with the assumption that (1) the toString() is really not performance critical here, as we are changing from debug != null to public static boolean isOn(String option) { if (args == null) return false; else { if (args.indexOf("all") != -1) return true; else return (args.indexOf(option) != -1); } } (2) the "debug" field is not being accessed via reflect --------------------------------------------------------------------------------------- src/java.base/share/classes/java/security/ProtectionDomain.java @@ -137,12 +137,10 @@ /* * An object used as a key when the ProtectionDomain is stored in a Map. */ final Key key = new Key(); - private static final Debug debug = Debug.getInstance("domain"); - /** * Creates a new ProtectionDomain with the given CodeSource and * Permissions. If the permissions object is not null, then * {@code setReadOnly())} will be called on the passed in * Permissions object. The only permissions granted to this domain @@ -357,11 +355,11 @@ SecurityManager sm = System.getSecurityManager(); if (sm == null) { return true; } else { - if (debug != null) { + if (Debug.isOn("domain")) { if (sm.getClass().getClassLoader() == null && Policy.getPolicyNoCheck().getClass().getClassLoader() == null) { return true; } -------------------------------------------------------------------------------------------------- On 05/10/2016 10:23 AM, Sean Mullan wrote: > > > On 5/10/16 1:30 AM, Alan Bateman wrote: >> On 10/05/2016 06:36, Xueming Shen wrote: >>> Hi, >>> >>> While testing for the attached regex changes, a fatal vm init error >>> was triggered for test >>> case with -Djava.security.debug=xyz turned on, as showed in following >>> stacktrace. >>> >>> It appears sun.security.util.Debug is being initialized even before >>> the lambda is ready >>> for use, and unfortunately it uses j.u.regex (for its args parsing), >>> which is being migrated >>> to use lambda function in the proposed regex change. >>> >>> Since Debug is the only class now triggers j.u.regex -> lambda during >>> initialization, it >>> is suggested to update/rewrite the related method in Debug to NOT use >>> j.u.regex to >>> solve/workaround this specific initialization issue. >> This is always tricky but I wonder how far we could get by initializing >> ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move >> them to a holder class where I wouldn't expect they will be initialized >> until much later, esp. as the security manager won't be set until later >> in the initialization (or init phase 3 as we've come to name it). > > Actually, ProtectionDomain already does something like this. It only writes to debug if the policy has been set. See toString(): > > PermissionCollection pc = Policy.isSet() && seeAllp() ? > mergePermissions(): > getPermissions(); > > So, a simpler fix is to extend that concept and not initialize the debug field until Policy.isSet is true. This should resolve this bootstrapping issue. > > --Sean From svetlana.nikandrova at oracle.com Tue May 10 18:16:01 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Tue, 10 May 2016 21:16:01 +0300 Subject: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings In-Reply-To: <572CDEEE.80108@oracle.com> References: <572249EB.8090808@oracle.com> <572CDEEE.80108@oracle.com> Message-ID: <57322561.3080309@oracle.com> Little remainder. On 06.05.2016 21:14, Svetlana Nikandrova wrote: > Hello, > > I would be grateful if someone could find time to review this backport > of tests enhancement. > I received few off-line notes and decided to rework this backport a > little. > > Here is my new webrev: > http://cr.openjdk.java.net/~snikandrova/8049171/webrev.01/ > > > List of changes from original patch: > 1) No ProcessTools.java changes in webrev as they have been backported > earlier. > 2) Utils.java : new utility method transferBetweenStreams meant to be > used instead of InputStream's transferTo method that is present since 9. > 3) JarUtils.java: changes in createJar method to consider a situation > then files aren't located in current directory. > 4) NestedActions.java: refactored to use JarUtils method to create jars. > 5) TimestampCheck.java - omitted > System.getProperty("test.tool.vm.opts") that is not used in jdk 8 > testing. > 6) Used System.getProperty("test.jdk") instead of > System.getProperty("java.home") in tests. > > Thank you, > Svetlana > > On 28.04.2016 20:35, Svetlana Nikandrova wrote: >> Hello, >> >> please review and approve the backport of tests enhancement: >> Original tests from >> https://bugs.openjdk.java.net/browse/JDK-8049171 >> jdk 9 review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031006.html >> jdk 9 changeset: >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5c61ccd9c162 >> Originally reviewed by Max Wang >> >> Webrev: >> http://cr.openjdk.java.net/~snikandrova/8049171/webrev.00/ >> >> >> List of changes between original patch and current webrev: >> >> 1) No ProcessTools.java changes as they have been backported earlier. >> 2) JarUtils.java : private method transferToOutputStream instead >> ofInputStream's transferTo method (present since 9). >> 3) TimestampCheck.java - changes applied by hand to omit >> System.getProperty("test.tool.vm.opts") that is not used in jdk 8 >> testing >> 4) Used System.getProperty("test.jdk") instead of >> System.getProperty("java.home") >> >> Tested with JPRT. >> >> Thank you, >> Svetlana > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueming.shen at oracle.com Tue May 10 18:57:58 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 May 2016 11:57:58 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57319C0C.8070702@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> Message-ID: <57322F36.2060709@oracle.com> webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ Thanks! Sherman On 05/10/2016 01:30 AM, Alan Bateman wrote: > On 10/05/2016 06:36, Xueming Shen wrote: >> Hi, >> >> While testing for the attached regex changes, a fatal vm init error was triggered for test >> case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. >> >> It appears sun.security.util.Debug is being initialized even before the lambda is ready >> for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated >> to use lambda function in the proposed regex change. >> >> Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it >> is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to >> solve/workaround this specific initialization issue. > This is always tricky but I wonder how far we could get by initializing ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move them to a holder class where I wouldn't expect they will be initialized until much later, esp. as the security manager won't be set until later in the initialization (or init phase 3 as we've come to name it). > > -Alan From ecki at zusammenkunft.net Tue May 10 19:40:04 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Tue, 10 May 2016 21:40:04 +0200 Subject: AES-NI support In-Reply-To: References: Message-ID: <343a42bf-f99e-410d-b80f-139dc682994b.maildroid@localhost> If you look at the builtin support it is only AES/CBC with the SunJCE (the AES/GCM has still a long way to go). With external/platform specific providers (ucrypto on Solaris, libnss via PKCS11 and Windows Crypto API) you might get more hw support. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: "M?ller, Steffen (AIFB)" To: "security-dev at openjdk.java.net" Sent: Di., 10 Mai 2016 20:18 Subject: AES-NI support Hi, I have a short ? but probably not easy ? question to the sec-dev community, since we have a research project dealing with the performance impact and performance optimizations for TLS: What TLS cipher suites and ciphers, modes of operation, security providers, etc. in general benefit from AES-NI in Java 8/9? I know that the TLS cipher suites using AES-GCM benefit from AES-NI in Java 8. The performance impact in various experiments can be considerable ? measured with OpenJDK and OracleJDK 8u92. Furthermore, I can enable or disable AES-NI support (see, e.g.: https://stackoverflow.com/questions/23058309/aes-ni-intrinsics-enabled-by-de fault). I found the globals.hpp where the UseAES and UseAESIntrinsics is defined, but no further information. The Intel sources stemming from 2012, on the other side, only mention the NSS library (see, e.g.: https://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-o n-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm). In sum, the documentation regarding AES-NI support in Java is very inconsistent. I tried to find more information about this topic, but Is there any further up-to-date documentation regarding AES-NI in Java 8/9? Is there anybody who can give me more information about this topic? Thanks Steffen Mueller From martinrb at google.com Tue May 10 19:43:28 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 May 2016 12:43:28 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get Message-ID: https://bugs.openjdk.java.net/browse/JDK-8156584 http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ I'm not a crypto engineer, so I'm hoping someone on security-dev adopts this fix. But current webrev is intended to be a complete fix for jdk8. From anthony.scarpino at oracle.com Tue May 10 20:02:47 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 10 May 2016 13:02:47 -0700 Subject: AES-NI support In-Reply-To: References: Message-ID: <57323E67.5040909@oracle.com> 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 AM, M?ller, Steffen (AIFB) wrote: > Hi, > > I have a short ? but probably not easy ? question to the sec-dev > community, since we have a research project dealing with the performance > impact and performance optimizations for TLS: > > What TLS cipher suites and ciphers, modes of operation, security > providers, etc. in general benefit from AES-NI in Java 8/9? > > I know that the TLS cipher suites using AES-GCM benefit from AES-NI in > Java 8. The performance impact in various experiments can be > considerable ? measured with OpenJDK and OracleJDK 8u92. Furthermore, I > can enable or disable AES-NI support (see, e.g.: > https://stackoverflow.com/questions/23058309/aes-ni-intrinsics-enabled-by-default). > I found the globals.hpp where the UseAES and UseAESIntrinsics is > defined, but no further information. The Intel sources stemming from > 2012, on the other side, only mention the NSS library (see, e.g.: > https://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm). > > In sum, the documentation regarding AES-NI support in Java is very > inconsistent. I tried to find more information about this topic, but? Is > there any further up-to-date documentation regarding AES-NI in Java 8/9? > Is there anybody who can give me more information about this topic? > > Thanks > > Steffen Mueller > From Alan.Bateman at oracle.com Tue May 10 20:10:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2016 21:10:24 +0100 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57322F36.2060709@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> Message-ID: <57324030.6000509@oracle.com> On 10/05/2016 19:57, Xueming Shen wrote: > webrev has been updated as suggested, now the lazily-init-class-holder > is used > to delay the Debug initialization. Tests all passed locally. A jprt > job is out to confirm. > > Here is the updated webrev > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ This looks okay, are exploded builds okay too? -Alan From xueming.shen at oracle.com Tue May 10 20:44:18 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 10 May 2016 13:44:18 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57324030.6000509@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> <57324030.6000509@oracle.com> Message-ID: On 5/10/16 1:10 PM, Alan Bateman wrote: > > > On 10/05/2016 19:57, Xueming Shen wrote: >> webrev has been updated as suggested, now the >> lazily-init-class-holder is used >> to delay the Debug initialization. Tests all passed locally. A jprt >> job is out to confirm. >> >> Here is the updated webrev >> >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> > This looks okay, are exploded builds okay too? > > -Alan jprt job appears to be OK. exploded build failed here and there for various reasons, for example "access denied". but it has nothing to do with the regex change. a jdk9_dev build without any update fails as well with the same reason at same place. here is one example http://javaweb.us.oracle.com/~xueshen/JTreport2/html/failed.html sherman From ecki at zusammenkunft.net Tue May 10 22:00:37 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 11 May 2016 00:00:37 +0200 Subject: ISO10126PADDING, minor optimizations and random question Message-ID: <20160511000037.00002c67.ecki@zusammenkunft.net> Hello, while looking at ISO10126Padding I noticed a few minor optimizations are possible: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/crypto/provider/ISO10126Padding.java?av=f unpad() - there is already a int cast done to this value: 104 int start = off + len - ((int)lastByte & 0x0ff); can be changed into "int start = off + len - padValue;" padWithLen() - we can request one byte less from PRNG and copy one less: 71 byte[] padding = new byte[len]; 72 SunJCE.getRandom().nextBytes(padding); 73 padding[len-1] = paddingOctet; 74 System.arraycopy(padding, 0, in, off, len); byte[] padding = new byte[len-1]; SunJCE.getRandom().nextBytes(padding); System.arraycopy(padding, 0, in, off, len-1); in[off+len-1] = paddingOctet; BTW: the JCA Standards Names documentation refer to W3C XML Encryption Standard 5.2 which does not mandate or suggest to use random padding. It allows any value. So a possible optimization would be to not use random bytes. If you think random bytes (and therefore non deterministic padding) is a desireable property I would suggest to actually document it in the SunJCE documentation. "This implements padding as defined by the JCA Standard Names using random padding bytes. Greetings Bernd From ecki at zusammenkunft.net Tue May 10 22:01:30 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 11 May 2016 00:01:30 +0200 Subject: Non constant time padding check in SunJCE PKCS5Padding Message-ID: <20160511000130.00002480.ecki@zusammenkunft.net> Hello, I had a look at the PKCS5Padding because I had the problem that AES/CBC/NOPADDING is much faster than AES/CBC/PKCS5PADDING (for larger single block with doFinal() encryptions). I havent found out the reason for that (I suspect it does a unecesary input copy). (opening another thread for this) But whhat I have seen is that the unpad() method does a non constant-time compare of the padding. I guess it cant be entirely avoided that the padding check tells anything about the cleartext (and EtM schemes are there for a reason). But I still think the final "are all padding bytes correct" can be changed into a xor comparision with no early return: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/crypto/provider/PKCS5Padding.java/ 108 for (int i = 0; i < ((int)lastByte & 0x0ff); i++) { 109 if (in[start+i] != lastByte) { 110 return -1; 111 } 112 } use this: int difference = 0; for(int i = 0; i < ((int)astByte & 0xff); i++) { difference |= in[start+1] ^ lastByte; } return difference == 0?start:-1; This would be minor (preventive) security hardening. Gruss Bernd From weijun.wang at oracle.com Tue May 10 23:23:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 May 2016 07:23:08 +0800 Subject: RFR 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom Message-ID: Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8156709/webrev.00/ On *nix, we open EGD and write into it when setSeed() is called. We were aware of the device not openable and have been ignoring it (Note we still write to a mix random). Now it seems on a Mac is can be opened for write but not writable. See this jshell output, the exception is thrown on write(). -> new FileOutputStream("/dev/urandom").write(12) | java.io.IOException thrown: Operation not permitted | at FileOutputStream.write (Native Method) | at FileOutputStream.write (FileOutputStream.java:291) | at (#17:1) Thanks Max From bradford.wetmore at oracle.com Tue May 10 23:55:38 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 10 May 2016 16:55:38 -0700 Subject: RFR 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom In-Reply-To: References: Message-ID: <419a34c7-139b-ee36-fa42-6b99cbc1fc26@oracle.com> What a stupid bug in MacOS. You can write to /dev/random, but not /dev/urandom. Yosemite: $ uname -a Darwin smarks 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 (4:51:18 PM) $ ls -al /dev/*random crw-rw-rw- 1 root wheel 11, 0 May 10 16:50 /dev/random crw-rw-rw- 1 root wheel 11, 1 May 10 16:39 /dev/urandom Change looks good. Brad On 5/10/2016 4:23 PM, Wang Weijun wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8156709/webrev.00/ > > On *nix, we open EGD and write into it when setSeed() is called. We were aware of the device not openable and have been ignoring it (Note we still write to a mix random). Now it seems on a Mac is can be opened for write but not writable. > > See this jshell output, the exception is thrown on write(). > > -> new FileOutputStream("/dev/urandom").write(12) > | java.io.IOException thrown: Operation not permitted > | at FileOutputStream.write (Native Method) > | at FileOutputStream.write (FileOutputStream.java:291) > | at (#17:1) > > Thanks > Max > From weijun.wang at oracle.com Wed May 11 00:35:19 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 May 2016 08:35:19 +0800 Subject: RFR 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom In-Reply-To: <419a34c7-139b-ee36-fa42-6b99cbc1fc26@oracle.com> References: <419a34c7-139b-ee36-fa42-6b99cbc1fc26@oracle.com> Message-ID: <23524D50-77C5-43F6-8EA3-CDBD1F16C851@oracle.com> > On May 11, 2016, at 7:55 AM, Bradford Wetmore wrote: > > What a stupid bug in MacOS. You can write to /dev/random, but not /dev/urandom. My understanding is that the entropy pool is on the /dev/random side, so you can write into it. On the /dev/urandom side, it seed from /dev/random and there is no meaning write into it, hence forbidden. --Max > > Yosemite: > $ uname -a > Darwin smarks 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 > (4:51:18 PM) $ ls -al /dev/*random > crw-rw-rw- 1 root wheel 11, 0 May 10 16:50 /dev/random > crw-rw-rw- 1 root wheel 11, 1 May 10 16:39 /dev/urandom > > Change looks good. > > Brad > > > > On 5/10/2016 4:23 PM, Wang Weijun wrote: >> Hi All >> >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8156709/webrev.00/ >> >> On *nix, we open EGD and write into it when setSeed() is called. We were aware of the device not openable and have been ignoring it (Note we still write to a mix random). Now it seems on a Mac is can be opened for write but not writable. >> >> See this jshell output, the exception is thrown on write(). >> >> -> new FileOutputStream("/dev/urandom").write(12) >> | java.io.IOException thrown: Operation not permitted >> | at FileOutputStream.write (Native Method) >> | at FileOutputStream.write (FileOutputStream.java:291) >> | at (#17:1) >> >> Thanks >> Max >> From sean.mullan at oracle.com Wed May 11 00:36:44 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 May 2016 17:36:44 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: <57322F36.2060709@oracle.com> References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> Message-ID: <57327E9C.3060904@oracle.com> Hi Xueming, It looks ok to me, but I'm curious if there may be other security classes that are initialized quite early and write to debug and may run into similar issues. Did you run all of the security regression tests in the jprt job? --Sean On 5/10/16 11:57 AM, Xueming Shen wrote: > webrev has been updated as suggested, now the lazily-init-class-holder > is used > to delay the Debug initialization. Tests all passed locally. A jprt job > is out to confirm. > > Here is the updated webrev > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > Thanks! > Sherman > > On 05/10/2016 01:30 AM, Alan Bateman wrote: >> On 10/05/2016 06:36, Xueming Shen wrote: >>> Hi, >>> >>> While testing for the attached regex changes, a fatal vm init error >>> was triggered for test >>> case with -Djava.security.debug=xyz turned on, as showed in following >>> stacktrace. >>> >>> It appears sun.security.util.Debug is being initialized even before >>> the lambda is ready >>> for use, and unfortunately it uses j.u.regex (for its args parsing), >>> which is being migrated >>> to use lambda function in the proposed regex change. >>> >>> Since Debug is the only class now triggers j.u.regex -> lambda during >>> initialization, it >>> is suggested to update/rewrite the related method in Debug to NOT use >>> j.u.regex to >>> solve/workaround this specific initialization issue. >> This is always tricky but I wonder how far we could get by >> initializing ProtectionDomain.debug and SecureClassLoader.debug >> lazily. That is, move them to a holder class where I wouldn't expect >> they will be initialized until much later, esp. as the security >> manager won't be set until later in the initialization (or init phase >> 3 as we've come to name it). >> >> -Alan > > > From mandy.chung at oracle.com Wed May 11 03:24:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 20:24:35 -0700 Subject: RFR: regex changes -- sun.security.util.Debug issue In-Reply-To: References: <56EC5F76.4080106@oracle.com> <5d904e08-6675-eb1e-b916-5fcd2e707b50@oracle.com> <57319C0C.8070702@oracle.com> <57322F36.2060709@oracle.com> <57324030.6000509@oracle.com> Message-ID: <114F0626-D41B-41F2-A2A5-644D5C4A430D@oracle.com> > On May 10, 2016, at 1:44 PM, Xueming Shen wrote: > > On 5/10/16 1:10 PM, Alan Bateman wrote: >> >> >> On 10/05/2016 19:57, Xueming Shen wrote: >>> webrev has been updated as suggested, now the lazily-init-class-holder is used >>> to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. >>> >>> Here is the updated webrev >>> >>> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> This looks okay, are exploded builds okay too? >> >> -Alan > > > jprt job appears to be OK. > > exploded build failed here and there for various reasons, for example "access denied". but it has > nothing to do with the regex change. a jdk9_dev build without any update fails as well with the same > reason at same place. here is one example > The security policy in the build only grants to jrt: code source and running with the exploded image won?t work with that. It?d be nice to avoid running with a different java.policy: https://bugs.openjdk.java.net/browse/JDK-8155858 Mandy From xuelei.fan at oracle.com Wed May 11 04:18:13 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 May 2016 12:18:13 +0800 Subject: RFR 8154523: SHA1PRNG output should change after reset In-Reply-To: <88C52600-69F1-4FC8-8289-790B1E8ED8B2@oracle.com> References: <4217aed7-2855-50d1-4f8d-3c639826d60f@oracle.com> <88C52600-69F1-4FC8-8289-790B1E8ED8B2@oracle.com> Message-ID: <940ba8ce-ec92-31d6-6234-f9d57923b891@oracle.com> OK, go ahead! Thanks, Xuelei On 5/9/2016 7:08 AM, Wang Weijun wrote: > >> On May 8, 2016, at 10:26 PM, Xuelei Fan wrote: >> >> On 5/8/2016 9:06 PM, Wang Weijun wrote: >>> Ping again. >>> >>>> On May 3, 2016, at 10:26 AM, Wang Weijun wrote: >>>> >>>> Hi All >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8154523/webrev.00 >>>> >>>> Basically, a reset in SHA1PRNG should forget the internal state and cached output. >>>> >> The spec of SecureRandomSpi.engineSetSeed() says: >> >> The given seed supplements, rather than replaces, the existing seed. > > I think this is to encourage people to call setSeed() even if the caller cannot find a perfect seed, as any new call won't make randomness worse. > >> >> If I'm understand correctly, reseed is not the same as reset. It should >> be OK to use the cached output for performance if the previous seed is OK. > > Well, it's almost reset. One calls setSeed() hoping new entropy is added and the output changes. Calling setSeed() is not a common thing and I think it's OK to ignore the performance impact here. Non predictability is quite crucial for a SecureRandom. > > Thanks > Max > > >> >> Xuelei > From xuelei.fan at oracle.com Wed May 11 04:31:33 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 May 2016 12:31:33 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> Message-ID: <19fbd55d-92d4-b10b-dc7f-4644759d53e6@oracle.com> On 5/10/2016 4:23 PM, Xuelei Fan wrote: > On 5/10/2016 2:37 PM, Wang Weijun wrote: >> >>> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: >>> >>> On 5/10/2016 12:16 AM, Michael StJohns wrote: >>>> You're going to hate me, but shouldn't this be checking the Provider >>>> rather than the OS when trying to determine which test to ignore? >>>> >>> It's more accurate to check the provider, too. >>> >>> - if (!System.getProperty("os.name").equals("SunOS")) { >>> + if (provider.getName().equals("SunPKCS11-Solaris") && >>> + !System.getProperty("os.name").equals("SunOS")) { >> >> There is SunPKCS11-Solaris not on SunOS? >> > SunPKPCS11-NSS may be on SunOS. > Update the block to: - if (provider.getName().equals("SunPKCS11-Solaris") && - !System.getProperty("os.name").equals("SunOS")) { + if (!provider.getName().equals("SunPKCS11-Solaris")) { This update will be integrated with JDK-8156716. As this is a simple fix, will not open another thread any more. Thanks, Xuelei From weijun.wang at oracle.com Wed May 11 04:40:06 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 May 2016 12:40:06 +0800 Subject: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings In-Reply-To: <57322561.3080309@oracle.com> References: <572249EB.8090808@oracle.com> <572CDEEE.80108@oracle.com> <57322561.3080309@oracle.com> Message-ID: <71FD37EF-CD8D-4FD8-89C3-6367CA9A3BF6@oracle.com> Looks fine to me. Just curious, why choose BUFFER_SIZE = 1024 in Utils.java? In JDK 9, DEFAULT_BUFFER_SIZE = 8192. Thanks Max > On May 11, 2016, at 2:16 AM, Svetlana Nikandrova wrote: > > Little remainder. > > On 06.05.2016 21:14, Svetlana Nikandrova wrote: >> Hello, >> >> I would be grateful if someone could find time to review this backport of tests enhancement. >> I received few off-line notes and decided to rework this backport a little. >> >> Here is my new webrev: >> http://cr.openjdk.java.net/~snikandrova/8049171/webrev.01/ >> From weijun.wang at oracle.com Wed May 11 04:42:44 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 May 2016 12:42:44 +0800 Subject: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris In-Reply-To: <19fbd55d-92d4-b10b-dc7f-4644759d53e6@oracle.com> References: <88851dc7-8af9-0950-95d0-ea9bf05ce3df@oracle.com> <21ef02e8-0f57-d2a1-efc5-70ae2ebff5c1@oracle.com> <13B7663D-9D31-459D-832B-ABE659D023AA@oracle.com> <7ab5788c-62e4-6a00-f95c-bfecac99e9ed@oracle.com> <4cb9945a-6500-c327-998a-2dca8addb21b@comcast.net> <0FAACCAE-2036-411A-9638-7AD976450F28@oracle.com> <19fbd55d-92d4-b10b-dc7f-4644759d53e6@oracle.com> Message-ID: This looks good. You might need to add a noreg-self to the bug. Thanks Max > On May 11, 2016, at 12:31 PM, Xuelei Fan wrote: > > On 5/10/2016 4:23 PM, Xuelei Fan wrote: >> On 5/10/2016 2:37 PM, Wang Weijun wrote: >>> >>>> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: >>>> >>>> On 5/10/2016 12:16 AM, Michael StJohns wrote: >>>>> You're going to hate me, but shouldn't this be checking the Provider >>>>> rather than the OS when trying to determine which test to ignore? >>>>> >>>> It's more accurate to check the provider, too. >>>> >>>> - if (!System.getProperty("os.name").equals("SunOS")) { >>>> + if (provider.getName().equals("SunPKCS11-Solaris") && >>>> + !System.getProperty("os.name").equals("SunOS")) { >>> >>> There is SunPKCS11-Solaris not on SunOS? >>> >> SunPKPCS11-NSS may be on SunOS. >> > > Update the block to: > - if (provider.getName().equals("SunPKCS11-Solaris") && > - !System.getProperty("os.name").equals("SunOS")) { > + if (!provider.getName().equals("SunPKCS11-Solaris")) { > > This update will be integrated with JDK-8156716. As this is a simple > fix, will not open another thread any more. > > Thanks, > Xuelei From svetlana.nikandrova at oracle.com Wed May 11 10:15:47 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Wed, 11 May 2016 13:15:47 +0300 Subject: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings In-Reply-To: <71FD37EF-CD8D-4FD8-89C3-6367CA9A3BF6@oracle.com> References: <572249EB.8090808@oracle.com> <572CDEEE.80108@oracle.com> <57322561.3080309@oracle.com> <71FD37EF-CD8D-4FD8-89C3-6367CA9A3BF6@oracle.com> Message-ID: <57330653.3060400@oracle.com> Thank you! About buffer size - there's nothing special about it. I believe I just took 1024 from some java code example. Thank you, Svetlana On 11.05.2016 7:40, Wang Weijun wrote: > Looks fine to me. > > Just curious, why choose BUFFER_SIZE = 1024 in Utils.java? In JDK 9, DEFAULT_BUFFER_SIZE = 8192. > > Thanks > Max > >> On May 11, 2016, at 2:16 AM, Svetlana Nikandrova wrote: >> >> Little remainder. >> >> On 06.05.2016 21:14, Svetlana Nikandrova wrote: >>> Hello, >>> >>> I would be grateful if someone could find time to review this backport of tests enhancement. >>> I received few off-line notes and decided to rework this backport a little. >>> >>> Here is my new webrev: >>> http://cr.openjdk.java.net/~snikandrova/8049171/webrev.01/ >>> From martinrb at google.com Wed May 11 17:01:13 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 May 2016 10:01:13 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: Message-ID: Webrev updated. Still looking for crypto-collaborator. On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: > https://bugs.openjdk.java.net/browse/JDK-8156584 > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ > > I'm not a crypto engineer, so I'm hoping someone on security-dev > adopts this fix. But current webrev is intended to be a complete fix > for jdk8. From sibabrata.sahoo at oracle.com Wed May 11 17:46:01 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 11 May 2016 10:46:01 -0700 (PDT) Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> Message-ID: <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> Hi Max, Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/ Changes includes: - Removed otherVM option and default "securerandom.drbg.config" will get reset after each DRBG test run. This change affected to all test files. - Addressed all the following comments for GetAlgorithm.java, EnoughSeedTest.java, MultiThreadTest.java. - Moved ApiTest.java, into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. - remove SHA1 and TDEA, 3KEYTDEA" ("3 KEY TDEA", "DESEDE") - corrected the logic for checkException() reported bellow. - Moved GetInstanceTest.java into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. - I am using default as well as custom entropy source just to make sure the extension works for getInstance() method. - Again, I use MoreDrbgParameter, just to make sure the instance of it can be acceptable by corresponding getInstance() method. - About SerializedSeedTest.java, I think the SHA1PRNG bug fix will get pushed to repo very soon. So the test is expected to work as the fix pushed into repo. But if you wish, I can change it accordingly. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Tuesday, May 10, 2016 1:14 PM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations For all: - If you can remember the old "securerandom.drbg.config" value to reset it in a finally clause, there is no need to othervm. - All DRBG mechanism names contain "_DRBG", therefore I'd rather change NON_DRBG.contains(mech) to !mech.contains("_DRBG"). The same technique can be applied everywhere. In fact, you can also add "DRBG" as a test algorithm, i.e. using the default "securerandom.drbg.config". If so, you have to reset the value after every call. GetAlgorithm.java: - You can but check on line 60 into lines 51 and 54, something like check(name, SecureRandom.getInstance(...)) ApiTest.java: - Please remove tests for SHA-1 and "3KEYTDEA" ("3 KEY TDEA", "DESEDE"), we are going to remove them soon. - I don't fully understand what lines 144-147 mean. If an NSAE is thrown, checkException() only fails if alg is invalid. Maybe you should also fail if strength check inside it is false? For example, line 192, it's OK for SHA-1 to fail if strength > 128, but not if it's less. - MoreDrbgParameters is internal. I suggest you stuff info about alg and df inside "securerandom.drbg.config". Probably no need to test nonce and es then. Or, if you still want to test on MoreDrbgParameters, move the test inside sun/security/provider/SecureRandom. EnoughSeedTest.java: - What if SUCCESS has been false once, but turns true in the last loop? Is that a success? Maybe you should "SUCCESS &= ..."? - same with "success" inside forEachSeedBytes? - What's the theory behind this test? Who said seed cannot ends with one or more zero? Zero is just as normal as any other byte which has its own 1/256 of probability to appear. GetInstanceTest.java: - Why name it DRBG_SEC_PROP? - You use MoreDrbgParameters again. Is this necessary? I don't see how the 2 EntropySource are different. MultiThreadTest.java: - Lines 135-144: If it's out System.out.printf, then it's useless. There are theories on quality of RNGs. For example: https://www.random.org/analysis/. SerializedSeedTest.java: - The SHA1PRNG bug is pending. At the moment, can you just generate 32 bytes of data with nextBytes() inside check()? Thanks Max > On May 8, 2016, at 9:57 PM, Sibabrata Sahoo wrote: > > Hello, > > Please review the tests for ?JDK-8141039:Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations?. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8141039 > Webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.00/ > > The tests covers the new DRBG API with different set of parameters. It also covers the behavior of all SecureRandom mechanism supported in Java in Serialized as well as in multithread context. > > Thanks, > Siba From rajan.halade at oracle.com Wed May 11 21:33:59 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 11 May 2016 14:33:59 -0700 Subject: RFR: 9: 8156671: Refactor sun/security/rsa/SignatureTest.java Message-ID: <5733A547.7050401@oracle.com> Please provide your review of patch to refactor SignatureTest. This test now runs all signature algorithms with key generated once resulting in saving 75% of execution time. Bug: https://bugs.openjdk.java.net/browse/JDK-8156671 Webrev: http://cr.openjdk.java.net/~rhalade/8156671/webrev.00/ Thanks, Rajan From anthony.scarpino at oracle.com Wed May 11 22:46:21 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 11 May 2016 15:46:21 -0700 Subject: RFR 8155847: SHA groups needed for jdk.security.provider.preferred Message-ID: <5733B63D.9020802@oracle.com> 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 From anthony.scarpino at oracle.com Wed May 11 22:46:24 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 11 May 2016 15:46:24 -0700 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date Message-ID: <5733B640.40408@oracle.com> 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 From ecki at zusammenkunft.net Wed May 11 23:55:29 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 12 May 2016 01:55:29 +0200 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date In-Reply-To: <5733B640.40408@oracle.com> References: <5733B640.40408@oracle.com> Message-ID: <71c0c6df-c230-4ac4-b7c0-98638ea63358.maildroid@localhost> Hello, In AlgorithmChecker the Javadoc seems to not follow "@param name desc" format (in two places). Also it should most likely describe something like "time the signature claimed to be made to check time range limited ciphers after that date or similiar) * @param PKIXParameter timestamp (or null) DisabledAlgorithmConstrained: The regular expression allows denyafter20160101 its clear, but \s+ might be clearer? Can optional iso Idate seperators, be added. "(\d {4})-?(\d {2})-?...." The lowercase constraint classes are rather strange, but fits into existing code... I dont see in the patch how the date param is certified. Is this only the issued date as certified (by the weak) signature or does it look at timestamps (especially codesigning) too? There are a few conditions which could be unit tested: RSA keySize <= 1024 & disablesAfter 20160101 SHA1 disabledAfter 20160102 // valid RSA disabledAfter 20160101 & disabledAfter 20160101 // not valid Etc Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Anthony Scarpino To: OpenJDK Security Sent: Do., 12 Mai 2016 1:16 Subject: 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 From weijun.wang at oracle.com Thu May 12 01:16:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 May 2016 09:16:45 +0800 Subject: RFR 8156501: DRBG not synchronized at reseeding In-Reply-To: References: Message-ID: Ping again, and webrev updated at http://cr.openjdk.java.net/~weijun/8156501/webrev.01/ Volatile keyword added to reseedCounter. Thanks Max > On May 9, 2016, at 11:51 AM, Wang Weijun wrote: > > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8156501/webrev.00 > > Many thanks to Siba for discovering this problem. I have only benchmarked nextBytes() before. > > Some clarifications: > > 1. No need to synchronize configure anymore() because it's always called inside a constructor. > > 2. synchronized-between-double-check in engineNextBytes() to protect reseedCounter. > > Thanks > Max > From xuelei.fan at oracle.com Thu May 12 01:31:41 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 May 2016 09:31:41 +0800 Subject: RFR 8156501: DRBG not synchronized at reseeding In-Reply-To: References: Message-ID: <5dbd513b-4982-c606-ecbd-7fe829af716f@oracle.com> Looks fine to me except a minor comment: AbstractDrbg.java ================= 54 * Since 8098581, there is no more synchronized keyword on SecureRandom APIs. 55 * An implementation is required to protect shared access to instantiate states 56 * (instantiated, nonce) and DRBG states (v, c, key, reseedCounter). This looks more like a code review description and may not suitable in source code as the code reader may not want to search for 8098581 and look back the history. I would suggest remove these lines. Thanks, Xuelei On 5/12/2016 9:16 AM, Wang Weijun wrote: > Ping again, and webrev updated at > > http://cr.openjdk.java.net/~weijun/8156501/webrev.01/ > > Volatile keyword added to reseedCounter. > > Thanks > Max > >> On May 9, 2016, at 11:51 AM, Wang Weijun wrote: >> >> Hi All >> >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8156501/webrev.00 >> >> Many thanks to Siba for discovering this problem. I have only benchmarked nextBytes() before. >> >> Some clarifications: >> >> 1. No need to synchronize configure anymore() because it's always called inside a constructor. >> >> 2. synchronized-between-double-check in engineNextBytes() to protect reseedCounter. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu May 12 01:41:20 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 May 2016 09:41:20 +0800 Subject: RFR 8156501: DRBG not synchronized at reseeding In-Reply-To: <5dbd513b-4982-c606-ecbd-7fe829af716f@oracle.com> References: <5dbd513b-4982-c606-ecbd-7fe829af716f@oracle.com> Message-ID: <7D419F6E-EDE4-4587-8C1D-D91B05401059@oracle.com> > On May 12, 2016, at 9:31 AM, Xuelei Fan wrote: > > Looks fine to me except a minor comment: > > AbstractDrbg.java > ================= > 54 * Since 8098581, there is no more synchronized keyword on > SecureRandom APIs. > 55 * An implementation is required to protect shared access to > instantiate states > 56 * (instantiated, nonce) and DRBG states (v, c, key, reseedCounter). > > This looks more like a code review description and may not suitable in > source code as the code reader may not want to search for 8098581 and > look back the history. I would suggest remove these lines. I'll do. Thanks. --Max > > Thanks, > Xuelei > > On 5/12/2016 9:16 AM, Wang Weijun wrote: >> Ping again, and webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8156501/webrev.01/ >> >> Volatile keyword added to reseedCounter. >> >> Thanks >> Max >> >>> On May 9, 2016, at 11:51 AM, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please review the fix at >>> >>> http://cr.openjdk.java.net/~weijun/8156501/webrev.00 >>> >>> Many thanks to Siba for discovering this problem. I have only benchmarked nextBytes() before. >>> >>> Some clarifications: >>> >>> 1. No need to synchronize configure anymore() because it's always called inside a constructor. >>> >>> 2. synchronized-between-double-check in engineNextBytes() to protect reseedCounter. >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Thu May 12 02:27:26 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 May 2016 10:27:26 +0800 Subject: 8156213: Remove SHA-1 and 3KeyTDEA algorithms from DRBG Message-ID: <2BA396E8-3AF7-465A-AAD1-542CB47E2404@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8156213/webrev.00/ In its initial changeset, The SUN implementation of DRBG supports all algorithms described in NIST SP 800-90Ar1. However, one algorithm is already considered weak today (3KeyTDEA) and another is likely to be consider weak quite soon (SHA-1). We should stop supporting them right from the beginning. It's a relief to say default strength is 128 for all mech/alg combinations. There is no interoperability or compatibility problem for SecureRandom. Thanks Max From weijun.wang at oracle.com Thu May 12 03:43:53 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 May 2016 11:43:53 +0800 Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> Message-ID: <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> > On May 12, 2016, at 1:46 AM, Sibabrata Sahoo wrote: > > Hi Max, > > Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/ > > Changes includes: > - Removed otherVM option and default "securerandom.drbg.config" will get reset after each DRBG test run. This change affected to all test files. > - Addressed all the following comments for GetAlgorithm.java, EnoughSeedTest.java, MultiThreadTest.java. > - Moved ApiTest.java, into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. > - remove SHA1 and TDEA, 3KEYTDEA" ("3 KEY TDEA", "DESEDE") > - corrected the logic for checkException() reported bellow. I don't see a difference. You print out messages in those "if (strength > n)" blocks but there is no other action. What are the messages for? Information or warning? In my opinion, a test should print out as little as possible unless an error occurs. (Sometimes "Testing XYZ..." is OK). > - Moved GetInstanceTest.java into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. > - I am using default as well as custom entropy source just to make sure the extension works for getInstance() method. > - Again, I use MoreDrbgParameter, just to make sure the instance of it can be acceptable by corresponding getInstance() method. Well, I have a different opinion. I think most of your tests should be categorized as functional (or conformance) tests, so they should be focused on public APIs. In this case, the test should set "securerandom.drbg.config" to Hash_DRBG/SHA-512 instead of using MoreDrbgParameters to set algorithm to SHA-512. In fact, there is no requirement that MoreDrbgParameters must be accepted by getInstance(). MoreDrbgParameters and EntropySource are implementation details. Sometimes they are necessary (For example, CAVP tests), but you'd better avoid touching them. I did wrote some tests on them (DRBGAlg, AbstractDrbgSpec) in an implementor's perspective but you can ignore them. > - About SerializedSeedTest.java, I think the SHA1PRNG bug fix will get pushed to repo very soon. So the test is expected to work as the fix pushed into repo. But if you wish, I can change it accordingly. Both the SHA1PRNG setSeed bug and the DRBG synchronization bug are already fixed and pushed. Thanks Max From bradford.wetmore at oracle.com Thu May 12 04:24:59 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 11 May 2016 21:24:59 -0700 Subject: 8156213: Remove SHA-1 and 3KeyTDEA algorithms from DRBG In-Reply-To: <2BA396E8-3AF7-465A-AAD1-542CB47E2404@oracle.com> References: <2BA396E8-3AF7-465A-AAD1-542CB47E2404@oracle.com> Message-ID: <46520b00-51db-3dd2-4d52-35c81ea19fb6@oracle.com> Looks good. Brad On 5/11/2016 7:27 PM, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8156213/webrev.00/ > > In its initial changeset, The SUN implementation of DRBG supports all algorithms described in NIST SP 800-90Ar1. However, one algorithm is already considered weak today (3KeyTDEA) and another is likely to be consider weak quite soon (SHA-1). We should stop supporting them right from the beginning. > > It's a relief to say default strength is 128 for all mech/alg combinations. > > There is no interoperability or compatibility problem for SecureRandom. > > Thanks > Max > From xuelei.fan at oracle.com Thu May 12 04:33:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 May 2016 12:33:18 +0800 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: Message-ID: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> AlgorithmId.java ================ Line 582-587, about the capacity of hash map, applications may customize Security providers and more OID numbers may get removed/added later, so the oid number may be not a fixed hard-coded number. It may be easier to maintain the code if using the default initial capacity of HashMap. Thanks, Xuelei On 5/12/2016 1:01 AM, Martin Buchholz wrote: > Webrev updated. > Still looking for crypto-collaborator. > > On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >> https://bugs.openjdk.java.net/browse/JDK-8156584 >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >> >> I'm not a crypto engineer, so I'm hoping someone on security-dev >> adopts this fix. But current webrev is intended to be a complete fix >> for jdk8. From xuelei.fan at oracle.com Thu May 12 04:38:11 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 May 2016 12:38:11 +0800 Subject: 8156213: Remove SHA-1 and 3KeyTDEA algorithms from DRBG In-Reply-To: <46520b00-51db-3dd2-4d52-35c81ea19fb6@oracle.com> References: <2BA396E8-3AF7-465A-AAD1-542CB47E2404@oracle.com> <46520b00-51db-3dd2-4d52-35c81ea19fb6@oracle.com> Message-ID: <83711399-5eb9-ab21-6e89-0b1604b3f9a9@oracle.com> On 5/12/2016 12:24 PM, Bradford Wetmore wrote: > Looks good. > +1. Xuelei > Brad > > > On 5/11/2016 7:27 PM, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8156213/webrev.00/ >> >> In its initial changeset, The SUN implementation of DRBG supports all >> algorithms described in NIST SP 800-90Ar1. However, one algorithm is >> already considered weak today (3KeyTDEA) and another is likely to be >> consider weak quite soon (SHA-1). We should stop supporting them right >> from the beginning. >> >> It's a relief to say default strength is 128 for all mech/alg >> combinations. >> >> There is no interoperability or compatibility problem for SecureRandom. >> >> Thanks >> Max >> From martinrb at google.com Thu May 12 05:21:21 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 May 2016 22:21:21 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> Message-ID: Hi Xuelei, I think the non-test code will work well with any set of providers, but is optimized for the default set of providers. If the user removes a provider, then the hashmap will be auto-compacted. The OidTableSize test will fail if the default providers are changed, but that actually helps maintenance efforts (if you care about optimizing startup; it's also reasonable not to care, and to delete the OidTableSize test entirely). On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: > AlgorithmId.java > ================ > Line 582-587, about the capacity of hash map, applications may customize > Security providers and more OID numbers may get removed/added later, so > the oid number may be not a fixed hard-coded number. It may be easier > to maintain the code if using the default initial capacity of HashMap. > > Thanks, > Xuelei > > > On 5/12/2016 1:01 AM, Martin Buchholz wrote: >> Webrev updated. >> Still looking for crypto-collaborator. >> >> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>> >>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>> adopts this fix. But current webrev is intended to be a complete fix >>> for jdk8. > From xuelei.fan at oracle.com Thu May 12 05:54:51 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 May 2016 13:54:51 +0800 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> Message-ID: On 5/12/2016 1:21 PM, Martin Buchholz wrote: > Hi Xuelei, > > I think the non-test code will work well with any set of providers, > but is optimized for the default set of providers. If the user > removes a provider, then the hashmap will be auto-compacted. The > OidTableSize test will fail if the default providers are changed, but > that actually helps maintenance efforts (if you care about optimizing > startup; it's also reasonable not to care, and to delete the > OidTableSize test entirely). > The test is used to test JDK default providers, but not the application customized configurations. Application customized providers may be different. And the providers may also be different from platform to platform. So sometimes, the hard-coded size code may make the startup performance worse. For maintenance, even if the OidTableSize test failed in the future, it may be hard to find the need to update the code here. Xuelei > On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >> AlgorithmId.java >> ================ >> Line 582-587, about the capacity of hash map, applications may customize >> Security providers and more OID numbers may get removed/added later, so >> the oid number may be not a fixed hard-coded number. It may be easier >> to maintain the code if using the default initial capacity of HashMap. >> >> Thanks, >> Xuelei >> >> >> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>> Webrev updated. >>> Still looking for crypto-collaborator. >>> >>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>> >>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>> adopts this fix. But current webrev is intended to be a complete fix >>>> for jdk8. >> From martinrb at google.com Thu May 12 06:27:50 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 May 2016 23:27:50 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> Message-ID: Xuelei, I again invite you to take ownership of this change. It needs to be ported to jdk9. If we simply delete OidTableSize then the initialization code will be close to optimal for the default configuration, and it will still work well if configured a little differently, so I would keep it. But we can also use the default initial capacity (16) if you prefer. On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: > On 5/12/2016 1:21 PM, Martin Buchholz wrote: >> Hi Xuelei, >> >> I think the non-test code will work well with any set of providers, >> but is optimized for the default set of providers. If the user >> removes a provider, then the hashmap will be auto-compacted. The >> OidTableSize test will fail if the default providers are changed, but >> that actually helps maintenance efforts (if you care about optimizing >> startup; it's also reasonable not to care, and to delete the >> OidTableSize test entirely). >> > The test is used to test JDK default providers, but not the application > customized configurations. Application customized providers may be > different. And the providers may also be different from platform to > platform. So sometimes, the hard-coded size code may make the startup > performance worse. For maintenance, even if the OidTableSize test > failed in the future, it may be hard to find the need to update the code > here. > > Xuelei > >> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>> AlgorithmId.java >>> ================ >>> Line 582-587, about the capacity of hash map, applications may customize >>> Security providers and more OID numbers may get removed/added later, so >>> the oid number may be not a fixed hard-coded number. It may be easier >>> to maintain the code if using the default initial capacity of HashMap. >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>> Webrev updated. >>>> Still looking for crypto-collaborator. >>>> >>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>> >>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>> for jdk8. >>> > From xuelei.fan at oracle.com Thu May 12 06:41:43 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 May 2016 14:41:43 +0800 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> Message-ID: <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> Hi Martin, If you agree with the update, I will sponsor your contribution for the testing and integration for JDK 9. Thanks, Xuelei On 5/12/2016 2:27 PM, Martin Buchholz wrote: > Xuelei, > > I again invite you to take ownership of this change. > It needs to be ported to jdk9. > > If we simply delete OidTableSize then the initialization code will be > close to optimal for the default configuration, and it will still work > well if configured a little differently, so I would keep it. But we > can also use the default initial capacity (16) if you prefer. > > On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: >> On 5/12/2016 1:21 PM, Martin Buchholz wrote: >>> Hi Xuelei, >>> >>> I think the non-test code will work well with any set of providers, >>> but is optimized for the default set of providers. If the user >>> removes a provider, then the hashmap will be auto-compacted. The >>> OidTableSize test will fail if the default providers are changed, but >>> that actually helps maintenance efforts (if you care about optimizing >>> startup; it's also reasonable not to care, and to delete the >>> OidTableSize test entirely). >>> >> The test is used to test JDK default providers, but not the application >> customized configurations. Application customized providers may be >> different. And the providers may also be different from platform to >> platform. So sometimes, the hard-coded size code may make the startup >> performance worse. For maintenance, even if the OidTableSize test >> failed in the future, it may be hard to find the need to update the code >> here. >> >> Xuelei >> >>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>>> AlgorithmId.java >>>> ================ >>>> Line 582-587, about the capacity of hash map, applications may customize >>>> Security providers and more OID numbers may get removed/added later, so >>>> the oid number may be not a fixed hard-coded number. It may be easier >>>> to maintain the code if using the default initial capacity of HashMap. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>>> Webrev updated. >>>>> Still looking for crypto-collaborator. >>>>> >>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>>> >>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>>> for jdk8. >>>> >> From sean.coffey at oracle.com Thu May 12 11:40:21 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 12 May 2016 12:40:21 +0100 Subject: Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread In-Reply-To: <4284e745-0a8f-09ff-fd96-5bb0027627b6@apache.org> References: <4284e745-0a8f-09ff-fd96-5bb0027627b6@apache.org> Message-ID: Logged https://bugs.openjdk.java.net/browse/JDK-8156841 Regards, Sean. On 10/05/2016 14:51, Mark Thomas wrote: > Hi, > > While working my way through Tomcat's memory leak protection / detection > / fixing code, I have found an issue that remains unresolved in the > latest JDK 9 source. > > The poller thread created by the SunPKCS11 class does not explicitly set > the context class loader so it inherits the current context class > loader. If the current context class loader when this code is triggered > happens to be one that is meant to be disposable (e.g. a web application > class loader) the class loader will be pinned in memory until the Thread > stops. This prevents the class loader from being GC'd when no longer > required and triggers a mmeory leak. > > Given that the creation of this thread depends on various factors, > including hardware configuration, the issue is fairly rare but we have > seen instances of it reported [1]. > > The fix looks to be trivial. Something along the lines of the following > around line 820 of SunPKCS11: > > t.setContextClassLoader(SunPKCS11.class.getClassLoader()); > > If I can provide any further information or if there is better place / > way to submit this then please do let me know. > > Mark > > [1] http://markmail.org/message/sykuo32eeknwsaqk -------------- next part -------------- An HTML attachment was scrubbed... URL: From markt at apache.org Thu May 12 12:50:17 2016 From: markt at apache.org (Mark Thomas) Date: Thu, 12 May 2016 13:50:17 +0100 Subject: Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread In-Reply-To: References: <4284e745-0a8f-09ff-fd96-5bb0027627b6@apache.org> Message-ID: On 12/05/2016 12:40, Se?n Coffey wrote: > Logged https://bugs.openjdk.java.net/browse/JDK-8156841 > > Regards, > Sean. Many thanks, Mark > > On 10/05/2016 14:51, Mark Thomas wrote: >> Hi, >> >> While working my way through Tomcat's memory leak protection / detection >> / fixing code, I have found an issue that remains unresolved in the >> latest JDK 9 source. >> >> The poller thread created by the SunPKCS11 class does not explicitly set >> the context class loader so it inherits the current context class >> loader. If the current context class loader when this code is triggered >> happens to be one that is meant to be disposable (e.g. a web application >> class loader) the class loader will be pinned in memory until the Thread >> stops. This prevents the class loader from being GC'd when no longer >> required and triggers a mmeory leak. >> >> Given that the creation of this thread depends on various factors, >> including hardware configuration, the issue is fairly rare but we have >> seen instances of it reported [1]. >> >> The fix looks to be trivial. Something along the lines of the following >> around line 820 of SunPKCS11: >> >> t.setContextClassLoader(SunPKCS11.class.getClassLoader()); >> >> If I can provide any further information or if there is better place / >> way to submit this then please do let me know. >> >> Mark >> >> [1] http://markmail.org/message/sykuo32eeknwsaqk > From claes.redestad at oracle.com Thu May 12 13:37:54 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 May 2016 15:37:54 +0200 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: <571E53B5.3060409@oracle.com> References: <571E53B5.3060409@oracle.com> Message-ID: <57348732.6020705@oracle.com> Hi, the API this improvement depends on was updated to reflect more clearly that this is taking a privileged action: https://bugs.openjdk.java.net/browse/JDK-8155775 Here's the updated webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.01/ Thanks! /Claes On 2016-04-25 19:28, Claes Redestad wrote: > Hi, > > SSLContextImpl and TrustManagerFactoryImpl has some setup code that > could be > simplified, getting rid of a couple of anonymous classes in the process. > > Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00 > Bug: https://bugs.openjdk.java.net/browse/JDK-8155039 > > Alternatively we could remove OpenFileInputStreamAction instead since > these two uses > introduced here are actually the only active uses of this old > convenience class. > > Thanks! > > /Claes From anthony.scarpino at oracle.com Thu May 12 17:38:02 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 12 May 2016 10:38:02 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <572AAB34.9030809@oracle.com> References: <572AAB34.9030809@oracle.com> Message-ID: <5734BF7A.5070706@oracle.com> 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 > be reviewed in a week or so, that'd be great. > > The changes for SUN providers are quite straight-forward, e.g. SHA-3 > digest impls based on FIPS PUB 202. > As for OracleUcrypto provider, Solaris SHA-3 support is through new > libucrypto digest APIs (added in Solaris 12) instead of the libmd. > When running on Solaris 12, the new libucrypto APIs will be used. > Otherwise, libmd will be used. > Changes for OracleUcrypto providers: > - add JNI code for the new libucrypto digest APIs > - code refactoring, e.g. move the libmd-related code to classes with MD > suffix > - run-time mechanism number assignment (used to be hardcoded values) > - better error reporting > > RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 > Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ > > Thanks, > Valerie Just a few minor things. UcryptoProvider.java:161 Did you mean to only comment it out and not delete it? nativeFunc.c: I noticed it is checking the library functions via dlsym. You could have a conditional check on the version of the library via ucrypto_version, then do the dlsym calls if it is supported. I think there is a performance enhancement that I would not hold up for this changeset. Changing the byte[]'s to long[] might give a good performance gain. A similar change was done to GHASH.java which resulted in a 10x performance increase. Given the internal methods appear to use long[][], and lanes are in longs it would probably help. But it most likely require a change to add DigestBase.implCompress(long[], int) and DigestBase.and implDigest(long[], int). Probably a low priority RFE. Tony From jamil.j.nimeh at oracle.com Thu May 12 18:39:40 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 12 May 2016 11:39:40 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <5734BF7A.5070706@oracle.com> References: <572AAB34.9030809@oracle.com> <5734BF7A.5070706@oracle.com> Message-ID: <5734CDEC.9090506@oracle.com> On 5/12/2016 10:38 AM, Anthony Scarpino wrote: > 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 >> be reviewed in a week or so, that'd be great. >> >> The changes for SUN providers are quite straight-forward, e.g. SHA-3 >> digest impls based on FIPS PUB 202. >> As for OracleUcrypto provider, Solaris SHA-3 support is through new >> libucrypto digest APIs (added in Solaris 12) instead of the libmd. >> When running on Solaris 12, the new libucrypto APIs will be used. >> Otherwise, libmd will be used. >> Changes for OracleUcrypto providers: >> - add JNI code for the new libucrypto digest APIs >> - code refactoring, e.g. move the libmd-related code to classes with MD >> suffix >> - run-time mechanism number assignment (used to be hardcoded values) >> - better error reporting >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 >> Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ >> >> Thanks, >> Valerie > > Just a few minor things. > > UcryptoProvider.java:161 > Did you mean to only comment it out and not delete it? > > nativeFunc.c: > I noticed it is checking the library functions via dlsym. You could > have a conditional check on the version of the library via > ucrypto_version, then do the dlsym calls if it is supported. > > > I think there is a performance enhancement that I would not hold up > for this changeset. Changing the byte[]'s to long[] might give a good > performance gain. A similar change was done to GHASH.java which > resulted in a 10x performance increase. Given the internal methods > appear to use long[][], and lanes are in longs it would probably help. > But it most likely require a change to add > DigestBase.implCompress(long[], int) and DigestBase.and > implDigest(long[], int). Probably a low priority RFE. > > Tony > Hi Valerie, just a few additional nits - not a big deal either way: * nativeCryptoMD.c: o 47, 53, 59, 65, etc.: You don't need to cast the pointer from malloc since you're assigning it to a void *. The casting only needs to happen when you go to use the pointer with a function that expects a concrete type. I tried it with gcc and cc with full warnings just to be sure. But it's no problem to leave it in there as-is. o 123, 125: I think these may be unnecessary casts, too. o 133,135,137: pretty sure free doesn't need casts. It likes all pointers regardless of type. * nativeCrypto.c: o 40,42: I'm surprised you're not getting warnings on these, as "0x0x" isn't a valid format specifier so you have a mismatch in terms of arguments vs format specifiers. Do you mean 0x%0x? The latter works ok. o 357: Just a question, does ucryptoDigestFinal automatically free the context as part of the finalize? Otherwise you're only freeing the context on a non-zero return value from that function. I'm assuming that the context should be freed regardless of the outcome given the header comment. o 362: Since context is a pointer, better to use NULL rather than zero. --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 12 19:00:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 May 2016 12:00:43 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> Message-ID: I have a new simpler webrev following your suggestion: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ Old one available at http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/ On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan wrote: > Hi Martin, > > If you agree with the update, I will sponsor your contribution for the > testing and integration for JDK 9. > > Thanks, > Xuelei > > On 5/12/2016 2:27 PM, Martin Buchholz wrote: >> Xuelei, >> >> I again invite you to take ownership of this change. >> It needs to be ported to jdk9. >> >> If we simply delete OidTableSize then the initialization code will be >> close to optimal for the default configuration, and it will still work >> well if configured a little differently, so I would keep it. But we >> can also use the default initial capacity (16) if you prefer. >> >> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: >>> On 5/12/2016 1:21 PM, Martin Buchholz wrote: >>>> Hi Xuelei, >>>> >>>> I think the non-test code will work well with any set of providers, >>>> but is optimized for the default set of providers. If the user >>>> removes a provider, then the hashmap will be auto-compacted. The >>>> OidTableSize test will fail if the default providers are changed, but >>>> that actually helps maintenance efforts (if you care about optimizing >>>> startup; it's also reasonable not to care, and to delete the >>>> OidTableSize test entirely). >>>> >>> The test is used to test JDK default providers, but not the application >>> customized configurations. Application customized providers may be >>> different. And the providers may also be different from platform to >>> platform. So sometimes, the hard-coded size code may make the startup >>> performance worse. For maintenance, even if the OidTableSize test >>> failed in the future, it may be hard to find the need to update the code >>> here. >>> >>> Xuelei >>> >>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>>>> AlgorithmId.java >>>>> ================ >>>>> Line 582-587, about the capacity of hash map, applications may customize >>>>> Security providers and more OID numbers may get removed/added later, so >>>>> the oid number may be not a fixed hard-coded number. It may be easier >>>>> to maintain the code if using the default initial capacity of HashMap. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>>>> Webrev updated. >>>>>> Still looking for crypto-collaborator. >>>>>> >>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>>>> >>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>>>> for jdk8. >>>>> >>> > From valerie.peng at oracle.com Thu May 12 20:57:12 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 May 2016 13:57:12 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <5734BF7A.5070706@oracle.com> References: <572AAB34.9030809@oracle.com> <5734BF7A.5070706@oracle.com> Message-ID: <5734EE28.70201@oracle.com> Hi Tony, Thanks for the review. I have deleted line 161 of UcryptoProvider.java as that's the intention. As for ucrypto_version enhancement, it's not that critical for this. I will note it in another ucrypto bug and we can do it there. Hmm, the internal operations of SHA-3 are already operating on long[][] and I doubt that we will have the same performance gain as in the GHASH case here, The java APIs passes data in byte[], so at some point, we have to convert all the longs back to bytes. But I agree that we should avoid unnecessary conversions. Performance task has been planned and we will do a closer inspection on this. Valerie On 5/12/2016 10:38 AM, Anthony Scarpino wrote: > 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 >> be reviewed in a week or so, that'd be great. >> >> The changes for SUN providers are quite straight-forward, e.g. SHA-3 >> digest impls based on FIPS PUB 202. >> As for OracleUcrypto provider, Solaris SHA-3 support is through new >> libucrypto digest APIs (added in Solaris 12) instead of the libmd. >> When running on Solaris 12, the new libucrypto APIs will be used. >> Otherwise, libmd will be used. >> Changes for OracleUcrypto providers: >> - add JNI code for the new libucrypto digest APIs >> - code refactoring, e.g. move the libmd-related code to classes with MD >> suffix >> - run-time mechanism number assignment (used to be hardcoded values) >> - better error reporting >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 >> Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ >> >> Thanks, >> Valerie > > Just a few minor things. > > UcryptoProvider.java:161 > Did you mean to only comment it out and not delete it? > > nativeFunc.c: > I noticed it is checking the library functions via dlsym. You could > have a conditional check on the version of the library via > ucrypto_version, then do the dlsym calls if it is supported. > > > I think there is a performance enhancement that I would not hold up > for this changeset. Changing the byte[]'s to long[] might give a good > performance gain. A similar change was done to GHASH.java which > resulted in a 10x performance increase. Given the internal methods > appear to use long[][], and lanes are in longs it would probably help. > But it most likely require a change to add > DigestBase.implCompress(long[], int) and DigestBase.and > implDigest(long[], int). Probably a low priority RFE. > > Tony > From valerie.peng at oracle.com Thu May 12 21:25:25 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 May 2016 14:25:25 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <5734CDEC.9090506@oracle.com> References: <572AAB34.9030809@oracle.com> <5734BF7A.5070706@oracle.com> <5734CDEC.9090506@oracle.com> Message-ID: <5734F4C5.3080509@oracle.com> Hi Jamil, Thanks for the review. Good catch on the formatting typo. I have fixed it. Removed some of the casting that you mentioned also. As for only free'ing context upon non-zero return value, it's more for allowing the java objects to be used again without re-initialization. When an error/exception occur, we can throw away everything. However, when operations finish successfully, we re-use the context for subsequent operations. The context will later be freed through explicit nativeFree(long) call when the object is being GC'ed. Valerie On 5/12/2016 11:39 AM, Jamil Nimeh wrote: > > > On 5/12/2016 10:38 AM, Anthony Scarpino wrote: >> 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 >>> be reviewed in a week or so, that'd be great. >>> >>> The changes for SUN providers are quite straight-forward, e.g. SHA-3 >>> digest impls based on FIPS PUB 202. >>> As for OracleUcrypto provider, Solaris SHA-3 support is through new >>> libucrypto digest APIs (added in Solaris 12) instead of the libmd. >>> When running on Solaris 12, the new libucrypto APIs will be used. >>> Otherwise, libmd will be used. >>> Changes for OracleUcrypto providers: >>> - add JNI code for the new libucrypto digest APIs >>> - code refactoring, e.g. move the libmd-related code to classes with MD >>> suffix >>> - run-time mechanism number assignment (used to be hardcoded values) >>> - better error reporting >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ >>> >>> Thanks, >>> Valerie >> >> Just a few minor things. >> >> UcryptoProvider.java:161 >> Did you mean to only comment it out and not delete it? >> >> nativeFunc.c: >> I noticed it is checking the library functions via dlsym. You could >> have a conditional check on the version of the library via >> ucrypto_version, then do the dlsym calls if it is supported. >> >> >> I think there is a performance enhancement that I would not hold up >> for this changeset. Changing the byte[]'s to long[] might give a >> good performance gain. A similar change was done to GHASH.java which >> resulted in a 10x performance increase. Given the internal methods >> appear to use long[][], and lanes are in longs it would probably >> help. But it most likely require a change to add >> DigestBase.implCompress(long[], int) and DigestBase.and >> implDigest(long[], int). Probably a low priority RFE. >> >> Tony >> > Hi Valerie, just a few additional nits - not a big deal either way: > > * nativeCryptoMD.c: > o 47, 53, 59, 65, etc.: You don't need to cast the pointer from > malloc since you're assigning it to a void *. The casting > only needs to happen when you go to use the pointer with a > function that expects a concrete type. I tried it with gcc > and cc with full warnings just to be sure. But it's no > problem to leave it in there as-is. > o 123, 125: I think these may be unnecessary casts, too. > o 133,135,137: pretty sure free doesn't need casts. It likes > all pointers regardless of type. > * nativeCrypto.c: > o 40,42: I'm surprised you're not getting warnings on these, as > "0x0x" isn't a valid format specifier so you have a mismatch > in terms of arguments vs format specifiers. Do you mean > 0x%0x? The latter works ok. > o 357: Just a question, does ucryptoDigestFinal automatically > free the context as part of the finalize? Otherwise you're > only freeing the context on a non-zero return value from that > function. I'm assuming that the context should be freed > regardless of the outcome given the header comment. > o 362: Since context is a pointer, better to use NULL rather > than zero. > > --Jamil > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Thu May 12 21:34:49 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 12 May 2016 14:34:49 -0700 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date In-Reply-To: <71c0c6df-c230-4ac4-b7c0-98638ea63358.maildroid@localhost> References: <5733B640.40408@oracle.com> <71c0c6df-c230-4ac4-b7c0-98638ea63358.maildroid@localhost> Message-ID: <5734F6F9.1090501@oracle.com> 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, ecki at zusammenkunft.net wrote: > Hello, > > In AlgorithmChecker the Javadoc seems to not follow "@param name > desc" format (in two places). Also it should most likely describe > something like "time the signature claimed to be made to check time > range limited ciphers after that date or similiar) > > * @param PKIXParameter timestamp (or null) Thanks for seeing that.. I updated them. > > DisabledAlgorithmConstrained: The regular expression allows > denyafter20160101 its clear, but \s+ might be clearer? Can optional > iso Idate seperators, be added. "(\d {4})-?(\d {2})-?...." I think I prefer to require '-' as standard syntax and not use YYYYMMDD. Sometimes YYYYMMDD not as clear to read as YYYY-MM-DD. I would like to not have two valid formats. > > The lowercase constraint classes are rather strange, but fits into > existing code... > > I dont see in the patch how the date param is certified. Is this only > the issued date as certified (by the weak) signature or does it look > at timestamps (especially codesigning) too? The date is passed as part of PKIX, it's optional that PKIX can have a date parameter set to specify a time date. The date disallows a certificate with the disabled algorithm on that date. It does not check validity of the certificate. This is meant to shutoff the algorithm in certificate checking. There maybe a exception to this to allowing codesigning certificates a bit longer, but that hasn't been completely decided yet. > > There are a few conditions which could be unit tested: > > RSA keySize <= 1024 & disablesAfter 20160101 SHA1 disabledAfter > 20160102 // valid RSA disabledAfter 20160101 & disabledAfter 20160101 > // not valid Etc Yes. There are a number of tests that are in the closed test repo because they use certificates that are not for public use. thanks Tony > > Gruss > > Bernd > From joe.darcy at oracle.com Thu May 12 22:11:23 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 12 May 2016 15:11:23 -0700 Subject: JDK 9 RFR of JDK-8156897: Problem list ShortRSAKey1024.sh on windows Message-ID: <2442245e-2ab4-d0a8-ea03-d4067ba8bcff@oracle.com> Hello, The test sun/security/mscapi/ShortRSAKey1024.sh has been seen to fail with some frequency on windows. Until JDK-8153948 is addressed, the test should be problem listed. Please review the patch below which does this. Thanks, -Joe diff -r b14b89e259ac test/ProblemList.txt --- a/test/ProblemList.txt Thu May 12 14:45:06 2016 -0700 +++ b/test/ProblemList.txt Thu May 12 15:10:53 2016 -0700 @@ -212,6 +212,8 @@ sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all +sun/security/mscapi/ShortRSAKey1024.sh 8153948 windows-all + java/security/Security/ClassLoaderDeadlock/Deadlock2.sh 8062758 generic-all sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all From valerie.peng at oracle.com Thu May 12 22:35:00 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 May 2016 15:35:00 -0700 Subject: RFR: 9: 8156671: Refactor sun/security/rsa/SignatureTest.java In-Reply-To: <5733A547.7050401@oracle.com> References: <5733A547.7050401@oracle.com> Message-ID: <57350514.9060202@oracle.com> Looks good to me. Thanks, Valerie On 5/11/2016 2:33 PM, Rajan Halade wrote: > Please provide your review of patch to refactor SignatureTest. This > test now runs all signature algorithms with key generated once > resulting in saving 75% of execution time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156671 > Webrev: http://cr.openjdk.java.net/~rhalade/8156671/webrev.00/ > > Thanks, > Rajan From sean.mullan at oracle.com Thu May 12 22:38:12 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 May 2016 15:38:12 -0700 Subject: JDK 9 RFR of JDK-8156897: Problem list ShortRSAKey1024.sh on windows In-Reply-To: <2442245e-2ab4-d0a8-ea03-d4067ba8bcff@oracle.com> References: <2442245e-2ab4-d0a8-ea03-d4067ba8bcff@oracle.com> Message-ID: <573505D4.10103@oracle.com> Looks fine to me. --Sean On 5/12/16 3:11 PM, joe darcy wrote: > Hello, > > The test > > sun/security/mscapi/ShortRSAKey1024.sh > > has been seen to fail with some frequency on windows. Until JDK-8153948 > is addressed, the test should be problem listed. > > Please review the patch below which does this. > > Thanks, > > -Joe > > diff -r b14b89e259ac test/ProblemList.txt > --- a/test/ProblemList.txt Thu May 12 14:45:06 2016 -0700 > +++ b/test/ProblemList.txt Thu May 12 15:10:53 2016 -0700 > @@ -212,6 +212,8 @@ > > sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all > > +sun/security/mscapi/ShortRSAKey1024.sh 8153948 windows-all > + > java/security/Security/ClassLoaderDeadlock/Deadlock2.sh 8062758 > generic-all > > sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 > generic-all > From ivan.gerasimov at oracle.com Thu May 12 23:13:02 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 13 May 2016 02:13:02 +0300 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date In-Reply-To: <5734F6F9.1090501@oracle.com> References: <5733B640.40408@oracle.com> <71c0c6df-c230-4ac4-b7c0-98638ea63358.maildroid@localhost> <5734F6F9.1090501@oracle.com> Message-ID: <6f777865-d40c-5f76-fe95-65ee317a95b1@oracle.com> Hi Anthony! A few minor comments: *AlgorithmChecker.java* It would be more consistent to use {@code ...} tags in place of ... *DisabledAlgorithmConstraints.java* 275 Matcher dmatch = denyAfterPattern.matcher(entry); 296 } else if (dmatch.matches()) { It might be a bit more efficient to reuse already 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... > > On 05/11/2016 04:55 PM, ecki at zusammenkunft.net wrote: >> Hello, >> >> In AlgorithmChecker the Javadoc seems to not follow "@param name >> desc" format (in two places). Also it should most likely describe >> something like "time the signature claimed to be made to check time >> range limited ciphers after that date or similiar) >> >> * @param PKIXParameter timestamp (or null) > > Thanks for seeing that.. I updated them. > >> >> DisabledAlgorithmConstrained: The regular expression allows >> denyafter20160101 its clear, but \s+ might be clearer? Can optional >> iso Idate seperators, be added. "(\d {4})-?(\d {2})-?...." > > I think I prefer to require '-' as standard syntax and not use > YYYYMMDD. Sometimes YYYYMMDD not as clear to read as YYYY-MM-DD. I > would like to not have two valid formats. > >> >> The lowercase constraint classes are rather strange, but fits into >> existing code... >> >> I dont see in the patch how the date param is certified. Is this only >> the issued date as certified (by the weak) signature or does it look >> at timestamps (especially codesigning) too? > > The date is passed as part of PKIX, it's optional that PKIX can have a > date parameter set to specify a time date. > The date disallows a certificate with the disabled algorithm on that > date. It does not check validity of the certificate. This is meant > to shutoff the algorithm in certificate checking. There maybe a > exception to this to allowing codesigning certificates a bit longer, > but that hasn't been completely decided yet. > >> >> There are a few conditions which could be unit tested: >> >> RSA keySize <= 1024 & disablesAfter 20160101 SHA1 disabledAfter >> 20160102 // valid RSA disabledAfter 20160101 & disabledAfter 20160101 >> // not valid Etc > > Yes. There are a number of tests that are in the closed test repo > because they use certificates that are not for public use. > > thanks > > Tony > >> >> Gruss > > >> Bernd >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri May 13 00:01:09 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 13 May 2016 08:01:09 +0800 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> Message-ID: <9006df74-1aba-6c86-5953-f948f4dec066@oracle.com> On 5/13/2016 3:00 AM, Martin Buchholz wrote: > I have a new simpler webrev following your suggestion: > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ Looks fine to me. Thanks, Xuelei > Old one available at > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/ > > On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan wrote: >> Hi Martin, >> >> If you agree with the update, I will sponsor your contribution for the >> testing and integration for JDK 9. >> >> Thanks, >> Xuelei >> >> On 5/12/2016 2:27 PM, Martin Buchholz wrote: >>> Xuelei, >>> >>> I again invite you to take ownership of this change. >>> It needs to be ported to jdk9. >>> >>> If we simply delete OidTableSize then the initialization code will be >>> close to optimal for the default configuration, and it will still work >>> well if configured a little differently, so I would keep it. But we >>> can also use the default initial capacity (16) if you prefer. >>> >>> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: >>>> On 5/12/2016 1:21 PM, Martin Buchholz wrote: >>>>> Hi Xuelei, >>>>> >>>>> I think the non-test code will work well with any set of providers, >>>>> but is optimized for the default set of providers. If the user >>>>> removes a provider, then the hashmap will be auto-compacted. The >>>>> OidTableSize test will fail if the default providers are changed, but >>>>> that actually helps maintenance efforts (if you care about optimizing >>>>> startup; it's also reasonable not to care, and to delete the >>>>> OidTableSize test entirely). >>>>> >>>> The test is used to test JDK default providers, but not the application >>>> customized configurations. Application customized providers may be >>>> different. And the providers may also be different from platform to >>>> platform. So sometimes, the hard-coded size code may make the startup >>>> performance worse. For maintenance, even if the OidTableSize test >>>> failed in the future, it may be hard to find the need to update the code >>>> here. >>>> >>>> Xuelei >>>> >>>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>>>>> AlgorithmId.java >>>>>> ================ >>>>>> Line 582-587, about the capacity of hash map, applications may customize >>>>>> Security providers and more OID numbers may get removed/added later, so >>>>>> the oid number may be not a fixed hard-coded number. It may be easier >>>>>> to maintain the code if using the default initial capacity of HashMap. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> >>>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>>>>> Webrev updated. >>>>>>> Still looking for crypto-collaborator. >>>>>>> >>>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>>>>> >>>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>>>>> for jdk8. >>>>>> >>>> >> From sean.coffey at oracle.com Fri May 13 16:00:08 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 13 May 2016 17:00:08 +0100 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <572AAB34.9030809@oracle.com> References: <572AAB34.9030809@oracle.com> Message-ID: <5735FA08.6050202@oracle.com> Valerie, some comments on supportability of the new code. Some handling could be improved to contain context perhaps : sun/security/provider/SHA3.java + if (numOfPadding < 1) { + throw new ProviderException("Incorrect pad size"); Can we print the numOfPadding value ? + private static long[][] bytes2Lanes(byte[] s) { + if (s.length != WIDTH) { + throw new ProviderException("Error: incorrect input size"); can we print the relevant values of interest ? On the test front, are you planning to update these tests to cater for the new SHA-3 algorithms ? ./pkcs11/MessageDigest/DigestKAT.java ./provider/MessageDigest/DigestKAT.java Regards, Sean. On 05/05/16 03:08, 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 be reviewed in a week or so, that'd be great. > > The changes for SUN providers are quite straight-forward, e.g. SHA-3 > digest impls based on FIPS PUB 202. > As for OracleUcrypto provider, Solaris SHA-3 support is through new > libucrypto digest APIs (added in Solaris 12) instead of the libmd. > When running on Solaris 12, the new libucrypto APIs will be used. > Otherwise, libmd will be used. > Changes for OracleUcrypto providers: > - add JNI code for the new libucrypto digest APIs > - code refactoring, e.g. move the libmd-related code to classes with > MD suffix > - run-time mechanism number assignment (used to be hardcoded values) > - better error reporting > > RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 > Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ > > Thanks, > Valerie From anthony.scarpino at oracle.com Fri May 13 16:04:45 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 13 May 2016 09:04:45 -0700 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date In-Reply-To: <6f777865-d40c-5f76-fe95-65ee317a95b1@oracle.com> References: <5733B640.40408@oracle.com> <71c0c6df-c230-4ac4-b7c0-98638ea63358.maildroid@localhost> <5734F6F9.1090501@oracle.com> <6f777865-d40c-5f76-fe95-65ee317a95b1@oracle.com> Message-ID: <5735FB1D.9010201@oracle.com> Hi Ivan, I added your comments.. I had thought usePattern() wouldn't reuse the entry, but apparently the description is not the way I read it. You comments are incorporated into the webrev.01 that I posted previously thanks Tony On 05/12/2016 04:13 PM, Ivan Gerasimov wrote: > Hi Anthony! > > > A few minor comments: > > *AlgorithmChecker.java* > > It would be more consistent to use {@code ...} tags in place of > ... > > > *DisabledAlgorithmConstraints.java* > > 275 Matcher dmatch = denyAfterPattern.matcher(entry); > > 296 } else if (dmatch.matches()) { > > > It might be a bit more efficient to reuse already 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... >> >> On 05/11/2016 04:55 PM, ecki at zusammenkunft.net wrote: >>> Hello, >>> >>> In AlgorithmChecker the Javadoc seems to not follow "@param name >>> desc" format (in two places). Also it should most likely describe >>> something like "time the signature claimed to be made to check time >>> range limited ciphers after that date or similiar) >>> >>> * @param PKIXParameter timestamp (or null) >> >> Thanks for seeing that.. I updated them. >> >>> >>> DisabledAlgorithmConstrained: The regular expression allows >>> denyafter20160101 its clear, but \s+ might be clearer? Can optional >>> iso Idate seperators, be added. "(\d {4})-?(\d {2})-?...." >> >> I think I prefer to require '-' as standard syntax and not use >> YYYYMMDD. Sometimes YYYYMMDD not as clear to read as YYYY-MM-DD. I >> would like to not have two valid formats. >> >>> >>> The lowercase constraint classes are rather strange, but fits into >>> existing code... >>> >>> I dont see in the patch how the date param is certified. Is this only >>> the issued date as certified (by the weak) signature or does it look >>> at timestamps (especially codesigning) too? >> >> The date is passed as part of PKIX, it's optional that PKIX can have a >> date parameter set to specify a time date. >> The date disallows a certificate with the disabled algorithm on that >> date. It does not check validity of the certificate. This is meant >> to shutoff the algorithm in certificate checking. There maybe a >> exception to this to allowing codesigning certificates a bit longer, >> but that hasn't been completely decided yet. >> >>> >>> There are a few conditions which could be unit tested: >>> >>> RSA keySize <= 1024 & disablesAfter 20160101 SHA1 disabledAfter >>> 20160102 // valid RSA disabledAfter 20160101 & disabledAfter 20160101 >>> // not valid Etc >> >> Yes. There are a number of tests that are in the closed test repo >> because they use certificates that are not for public use. >> >> thanks >> >> Tony >> >>> >>> Gruss >> > >>> Bernd >>> >> >> > From valerie.peng at oracle.com Fri May 13 19:50:02 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 13 May 2016 12:50:02 -0700 Subject: RFR JDK-8000415: Add support for SHA-3 In-Reply-To: <5735FA08.6050202@oracle.com> References: <572AAB34.9030809@oracle.com> <5735FA08.6050202@oracle.com> Message-ID: <57362FEA.2040408@oracle.com> Sean, I have added the values to the exception message as u suggested. As for the test vectors, I already put them (some of them) in separate internal tests for SUN and OracleUcrypto provider respectively. PKCS11 provider is not yet updated with the SHA-3 support, when it does, it will has its own test for covering the test vectors. Also Amanda from SQE will cover quite some more test vectors in her putback. Thanks, Valerie On 5/13/2016 9:00 AM, Se?n Coffey wrote: > Valerie, > > some comments on supportability of the new code. Some handling could > be improved to contain context perhaps : > > sun/security/provider/SHA3.java > + if (numOfPadding < 1) { > + throw new ProviderException("Incorrect pad size"); > > Can we print the numOfPadding value ? > > > + private static long[][] bytes2Lanes(byte[] s) { > + if (s.length != WIDTH) { > + throw new ProviderException("Error: incorrect input size"); > > can we print the relevant values of interest ? > > On the test front, are you planning to update these tests to cater for > the new SHA-3 algorithms ? > > ./pkcs11/MessageDigest/DigestKAT.java > ./provider/MessageDigest/DigestKAT.java > > Regards, > Sean. > > On 05/05/16 03:08, 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 be reviewed in a week or so, that'd be great. >> >> The changes for SUN providers are quite straight-forward, e.g. SHA-3 >> digest impls based on FIPS PUB 202. >> As for OracleUcrypto provider, Solaris SHA-3 support is through new >> libucrypto digest APIs (added in Solaris 12) instead of the libmd. >> When running on Solaris 12, the new libucrypto APIs will be used. >> Otherwise, libmd will be used. >> Changes for OracleUcrypto providers: >> - add JNI code for the new libucrypto digest APIs >> - code refactoring, e.g. move the libmd-related code to classes with >> MD suffix >> - run-time mechanism number assignment (used to be hardcoded values) >> - better error reporting >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8000415 >> Webrev: http://cr.openjdk.java.net/~valeriep/8000415/webrev.00/ >> >> Thanks, >> Valerie > From martinrb at google.com Fri May 13 19:50:36 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 May 2016 12:50:36 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: <9006df74-1aba-6c86-5953-f948f4dec066@oracle.com> References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> <9006df74-1aba-6c86-5953-f948f4dec066@oracle.com> Message-ID: Hi Xuelei, The jdk9 version is still up in the air. I propose committing: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AlgorithmId-get-race/ On Thu, May 12, 2016 at 5:01 PM, Xuelei Fan wrote: > On 5/13/2016 3:00 AM, Martin Buchholz wrote: >> I have a new simpler webrev following your suggestion: >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ > Looks fine to me. > > Thanks, > Xuelei > >> Old one available at >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/ >> >> On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan wrote: >>> Hi Martin, >>> >>> If you agree with the update, I will sponsor your contribution for the >>> testing and integration for JDK 9. >>> >>> Thanks, >>> Xuelei >>> >>> On 5/12/2016 2:27 PM, Martin Buchholz wrote: >>>> Xuelei, >>>> >>>> I again invite you to take ownership of this change. >>>> It needs to be ported to jdk9. >>>> >>>> If we simply delete OidTableSize then the initialization code will be >>>> close to optimal for the default configuration, and it will still work >>>> well if configured a little differently, so I would keep it. But we >>>> can also use the default initial capacity (16) if you prefer. >>>> >>>> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: >>>>> On 5/12/2016 1:21 PM, Martin Buchholz wrote: >>>>>> Hi Xuelei, >>>>>> >>>>>> I think the non-test code will work well with any set of providers, >>>>>> but is optimized for the default set of providers. If the user >>>>>> removes a provider, then the hashmap will be auto-compacted. The >>>>>> OidTableSize test will fail if the default providers are changed, but >>>>>> that actually helps maintenance efforts (if you care about optimizing >>>>>> startup; it's also reasonable not to care, and to delete the >>>>>> OidTableSize test entirely). >>>>>> >>>>> The test is used to test JDK default providers, but not the application >>>>> customized configurations. Application customized providers may be >>>>> different. And the providers may also be different from platform to >>>>> platform. So sometimes, the hard-coded size code may make the startup >>>>> performance worse. For maintenance, even if the OidTableSize test >>>>> failed in the future, it may be hard to find the need to update the code >>>>> here. >>>>> >>>>> Xuelei >>>>> >>>>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>>>>>> AlgorithmId.java >>>>>>> ================ >>>>>>> Line 582-587, about the capacity of hash map, applications may customize >>>>>>> Security providers and more OID numbers may get removed/added later, so >>>>>>> the oid number may be not a fixed hard-coded number. It may be easier >>>>>>> to maintain the code if using the default initial capacity of HashMap. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> >>>>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>>>>>> Webrev updated. >>>>>>>> Still looking for crypto-collaborator. >>>>>>>> >>>>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>>>>>> >>>>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>>>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>>>>>> for jdk8. >>>>>>> >>>>> >>> > From rajan.halade at oracle.com Fri May 13 19:56:28 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 13 May 2016 12:56:28 -0700 Subject: RFR: 9: 8155049: New tests from 8144566 fail with "No expected Server Name Indication" Message-ID: <5736316C.8040605@oracle.com> Please provide your review of this one line fix. These tests fail on machine where non-FQDN hostname is returned. As per RFC for SNI extension, hostname needs to be fully qualified DNS hostname and same is asserted in JDK when it adds hostname to SNI extension. This fix skips test execution if hostname returned is not fully qualified. Bug: https://bugs.openjdk.java.net/browse/JDK-8155049 Webrev: http://cr.openjdk.java.net/~rhalade/8155049/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Fri May 13 23:58:33 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 14 May 2016 07:58:33 +0800 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> <9006df74-1aba-6c86-5953-f948f4dec066@oracle.com> Message-ID: <1f9e33ac-d1db-3bc8-8c30-c4428abf3916@oracle.com> On 5/14/2016 3:50 AM, Martin Buchholz wrote: > Hi Xuelei, > > The jdk9 version is still up in the air. I propose committing: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AlgorithmId-get-race/ > Looks fine to me. Thanks! Xuelei > On Thu, May 12, 2016 at 5:01 PM, Xuelei Fan wrote: >> On 5/13/2016 3:00 AM, Martin Buchholz wrote: >>> I have a new simpler webrev following your suggestion: >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >> Looks fine to me. >> >> Thanks, >> Xuelei >> >>> Old one available at >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/ >>> >>> On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan wrote: >>>> Hi Martin, >>>> >>>> If you agree with the update, I will sponsor your contribution for the >>>> testing and integration for JDK 9. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 5/12/2016 2:27 PM, Martin Buchholz wrote: >>>>> Xuelei, >>>>> >>>>> I again invite you to take ownership of this change. >>>>> It needs to be ported to jdk9. >>>>> >>>>> If we simply delete OidTableSize then the initialization code will be >>>>> close to optimal for the default configuration, and it will still work >>>>> well if configured a little differently, so I would keep it. But we >>>>> can also use the default initial capacity (16) if you prefer. >>>>> >>>>> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: >>>>>> On 5/12/2016 1:21 PM, Martin Buchholz wrote: >>>>>>> Hi Xuelei, >>>>>>> >>>>>>> I think the non-test code will work well with any set of providers, >>>>>>> but is optimized for the default set of providers. If the user >>>>>>> removes a provider, then the hashmap will be auto-compacted. The >>>>>>> OidTableSize test will fail if the default providers are changed, but >>>>>>> that actually helps maintenance efforts (if you care about optimizing >>>>>>> startup; it's also reasonable not to care, and to delete the >>>>>>> OidTableSize test entirely). >>>>>>> >>>>>> The test is used to test JDK default providers, but not the application >>>>>> customized configurations. Application customized providers may be >>>>>> different. And the providers may also be different from platform to >>>>>> platform. So sometimes, the hard-coded size code may make the startup >>>>>> performance worse. For maintenance, even if the OidTableSize test >>>>>> failed in the future, it may be hard to find the need to update the code >>>>>> here. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>>>>>>> AlgorithmId.java >>>>>>>> ================ >>>>>>>> Line 582-587, about the capacity of hash map, applications may customize >>>>>>>> Security providers and more OID numbers may get removed/added later, so >>>>>>>> the oid number may be not a fixed hard-coded number. It may be easier >>>>>>>> to maintain the code if using the default initial capacity of HashMap. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> >>>>>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>>>>>>> Webrev updated. >>>>>>>>> Still looking for crypto-collaborator. >>>>>>>>> >>>>>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>>>>>>> >>>>>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>>>>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>>>>>>> for jdk8. >>>>>>>> >>>>>> >>>> >> From xuelei.fan at oracle.com Sat May 14 00:02:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 14 May 2016 08:02:37 +0800 Subject: RFR: 9: 8155049: New tests from 8144566 fail with "No expected Server Name Indication" In-Reply-To: <5736316C.8040605@oracle.com> References: <5736316C.8040605@oracle.com> Message-ID: <2c78f8a8-ef97-e32f-44e2-feb71b7a013c@oracle.com> Looks fine to me. hostname.indexOf('.') == -1 May be more straightforward to use hostname.contains("."). Thanks, Xuelei On 5/14/2016 3:56 AM, Rajan Halade wrote: > Please provide your review of this one line fix. > > These tests fail on machine where non-FQDN hostname is returned. As per > RFC for SNI extension, hostname needs to be fully qualified DNS hostname > and same is asserted in JDK when it adds hostname to SNI extension. This > fix skips test execution if hostname returned is not fully qualified. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155049 > Webrev: http://cr.openjdk.java.net/~rhalade/8155049/webrev.00/ > > Thanks, > Rajan From martinrb at google.com Sat May 14 02:16:25 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 May 2016 19:16:25 -0700 Subject: RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: <1f9e33ac-d1db-3bc8-8c30-c4428abf3916@oracle.com> References: <00666409-7854-c526-fbbd-225416f211b0@oracle.com> <5861b55c-7cbe-76c3-05b9-0c13f6b627cd@oracle.com> <9006df74-1aba-6c86-5953-f948f4dec066@oracle.com> <1f9e33ac-d1db-3bc8-8c30-c4428abf3916@oracle.com> Message-ID: Pushed. Xuelei, would you like to do the paperwork for the follow-on jdk8 backport? On Fri, May 13, 2016 at 4:58 PM, Xuelei Fan wrote: > On 5/14/2016 3:50 AM, Martin Buchholz wrote: >> Hi Xuelei, >> >> The jdk9 version is still up in the air. I propose committing: >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AlgorithmId-get-race/ >> > Looks fine to me. Thanks! > > Xuelei > >> On Thu, May 12, 2016 at 5:01 PM, Xuelei Fan wrote: >>> On 5/13/2016 3:00 AM, Martin Buchholz wrote: >>>> I have a new simpler webrev following your suggestion: >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>> Looks fine to me. >>> >>> Thanks, >>> Xuelei >>> >>>> Old one available at >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/ >>>> >>>> On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan wrote: >>>>> Hi Martin, >>>>> >>>>> If you agree with the update, I will sponsor your contribution for the >>>>> testing and integration for JDK 9. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 5/12/2016 2:27 PM, Martin Buchholz wrote: >>>>>> Xuelei, >>>>>> >>>>>> I again invite you to take ownership of this change. >>>>>> It needs to be ported to jdk9. >>>>>> >>>>>> If we simply delete OidTableSize then the initialization code will be >>>>>> close to optimal for the default configuration, and it will still work >>>>>> well if configured a little differently, so I would keep it. But we >>>>>> can also use the default initial capacity (16) if you prefer. >>>>>> >>>>>> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote: >>>>>>> On 5/12/2016 1:21 PM, Martin Buchholz wrote: >>>>>>>> Hi Xuelei, >>>>>>>> >>>>>>>> I think the non-test code will work well with any set of providers, >>>>>>>> but is optimized for the default set of providers. If the user >>>>>>>> removes a provider, then the hashmap will be auto-compacted. The >>>>>>>> OidTableSize test will fail if the default providers are changed, but >>>>>>>> that actually helps maintenance efforts (if you care about optimizing >>>>>>>> startup; it's also reasonable not to care, and to delete the >>>>>>>> OidTableSize test entirely). >>>>>>>> >>>>>>> The test is used to test JDK default providers, but not the application >>>>>>> customized configurations. Application customized providers may be >>>>>>> different. And the providers may also be different from platform to >>>>>>> platform. So sometimes, the hard-coded size code may make the startup >>>>>>> performance worse. For maintenance, even if the OidTableSize test >>>>>>> failed in the future, it may be hard to find the need to update the code >>>>>>> here. >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan wrote: >>>>>>>>> AlgorithmId.java >>>>>>>>> ================ >>>>>>>>> Line 582-587, about the capacity of hash map, applications may customize >>>>>>>>> Security providers and more OID numbers may get removed/added later, so >>>>>>>>> the oid number may be not a fixed hard-coded number. It may be easier >>>>>>>>> to maintain the code if using the default initial capacity of HashMap. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote: >>>>>>>>>> Webrev updated. >>>>>>>>>> Still looking for crypto-collaborator. >>>>>>>>>> >>>>>>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>>>>>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>>>>>>>>>> >>>>>>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>>>>>>>>>> adopts this fix. But current webrev is intended to be a complete fix >>>>>>>>>>> for jdk8. >>>>>>>>> >>>>>>> >>>>> >>> > From xuelei.fan at oracle.com Sat May 14 09:30:58 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 14 May 2016 17:30:58 +0800 Subject: Request for Review of JDK-8156991: Problem list UnsupportedDHKeys.java on windows Message-ID: <3385edeb-2a9b-420c-d7c2-1688fa41ae5c@oracle.com> Hi, The test sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java has been seen to fail with some frequency on windows. Until JDK-8154910 is addressed, the test should be problem listed. Please review the patch below: sun/security/pkcs11/KeyAgreement/TestShort.java 8077138,8023434 windows-all + sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8154910 windows-all sun/security/pkcs11/KeyGenerator/DESParity.java 8077138,8023434 windows-all Thanks, Xuelei From yozons at gmail.com Sat May 14 18:11:45 2016 From: yozons at gmail.com (Yozons) Date: Sat, 14 May 2016 11:11:45 -0700 (MST) Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552D66D2.2040805@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> <552D584E.50201@oracle.com> <552D66D2.2040805@oracle.com> Message-ID: <1463249505676-271376.post@n7.nabble.com> Has this fix been incorporated in a release yet? If so, which one? Thanks! -- View this message in context: http://openjdk.5641.n7.nabble.com/9-RFR-S-8067648-JVM-crashes-reproducable-with-GCM-cipher-suites-in-GCTR-doFinal-tp222764p271376.html Sent from the OpenJDK Security Development mailing list archive at Nabble.com. From ivan.gerasimov at oracle.com Sun May 15 11:13:46 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 15 May 2016 14:13:46 +0300 Subject: Request for Review of JDK-8156991: Problem list UnsupportedDHKeys.java on windows In-Reply-To: <3385edeb-2a9b-420c-d7c2-1688fa41ae5c@oracle.com> References: <3385edeb-2a9b-420c-d7c2-1688fa41ae5c@oracle.com> Message-ID: <307a4a8d-22dc-0dfe-7e62-67e6f4934104@oracle.com> Hi Xuelei! Looks good. I assume you want to problem-list both SupportedDHKeys and UnsupportedDHKeys? The former is in the patch, and the later -- in the synopsis. I see mentioning both of them in the bug report. With kind regards, Ivan On 14.05.2016 12:30, Xuelei Fan wrote: > Hi, > > The test sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java has been > seen to fail with some frequency on windows. Until JDK-8154910 is > addressed, the test should be problem listed. > > Please review the patch below: > > sun/security/pkcs11/KeyAgreement/TestShort.java 8077138,8023434 > windows-all > + sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8154910 windows-all > sun/security/pkcs11/KeyGenerator/DESParity.java 8077138,8023434 > windows-all > > Thanks, > Xuelei > From xuelei.fan at oracle.com Mon May 16 00:20:06 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 May 2016 08:20:06 +0800 Subject: Request for Review of JDK-8156991: Problem list UnsupportedDHKeys.java on windows In-Reply-To: <307a4a8d-22dc-0dfe-7e62-67e6f4934104@oracle.com> References: <3385edeb-2a9b-420c-d7c2-1688fa41ae5c@oracle.com> <307a4a8d-22dc-0dfe-7e62-67e6f4934104@oracle.com> Message-ID: <1fbd40ac-4d4d-68cf-05c7-a8991aaab43e@oracle.com> On 5/15/2016 7:13 PM, Ivan Gerasimov wrote: > Hi Xuelei! > > Looks good. > > I assume you want to problem-list both SupportedDHKeys and > UnsupportedDHKeys? > > The former is in the patch, and the later -- in the synopsis. > I see mentioning both of them in the bug report. > Yes. Both should be problem listed. sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8154910 windows-all sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java 8154910 windows-all Thanks, Xuelei > With kind regards, > Ivan > > > On 14.05.2016 12:30, Xuelei Fan wrote: >> Hi, >> >> The test sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java has been >> seen to fail with some frequency on windows. Until JDK-8154910 is >> addressed, the test should be problem listed. >> >> Please review the patch below: >> >> sun/security/pkcs11/KeyAgreement/TestShort.java 8077138,8023434 >> windows-all >> + sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8154910 >> windows-all >> sun/security/pkcs11/KeyGenerator/DESParity.java 8077138,8023434 >> windows-all >> >> Thanks, >> Xuelei >> > From sibabrata.sahoo at oracle.com Mon May 16 10:40:09 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 16 May 2016 03:40:09 -0700 (PDT) Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> Message-ID: <356e7ae7-44b9-4038-92d2-82912de6db43@default> Hi Max, Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.02/ The changes includes, - ApiTest.java : Removed printing unnecessary message inside checkException() method. - GetInstanceTest.java - Moved the test back into " java/security/SecureRandom/ ". - Removed all reference to MoreDrbgParameters and EntropySource. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Thursday, May 12, 2016 9:14 AM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > On May 12, 2016, at 1:46 AM, Sibabrata Sahoo wrote: > > Hi Max, > > Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/ > > Changes includes: > - Removed otherVM option and default "securerandom.drbg.config" will get reset after each DRBG test run. This change affected to all test files. > - Addressed all the following comments for GetAlgorithm.java, EnoughSeedTest.java, MultiThreadTest.java. > - Moved ApiTest.java, into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. > - remove SHA1 and TDEA, 3KEYTDEA" ("3 KEY TDEA", "DESEDE") > - corrected the logic for checkException() reported bellow. I don't see a difference. You print out messages in those "if (strength > n)" blocks but there is no other action. What are the messages for? Information or warning? In my opinion, a test should print out as little as possible unless an error occurs. (Sometimes "Testing XYZ..." is OK). > - Moved GetInstanceTest.java into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. > - I am using default as well as custom entropy source just to make sure the extension works for getInstance() method. > - Again, I use MoreDrbgParameter, just to make sure the instance of it can be acceptable by corresponding getInstance() method. Well, I have a different opinion. I think most of your tests should be categorized as functional (or conformance) tests, so they should be focused on public APIs. In this case, the test should set "securerandom.drbg.config" to Hash_DRBG/SHA-512 instead of using MoreDrbgParameters to set algorithm to SHA-512. In fact, there is no requirement that MoreDrbgParameters must be accepted by getInstance(). MoreDrbgParameters and EntropySource are implementation details. Sometimes they are necessary (For example, CAVP tests), but you'd better avoid touching them. I did wrote some tests on them (DRBGAlg, AbstractDrbgSpec) in an implementor's perspective but you can ignore them. > - About SerializedSeedTest.java, I think the SHA1PRNG bug fix will get pushed to repo very soon. So the test is expected to work as the fix pushed into repo. But if you wish, I can change it accordingly. Both the SHA1PRNG setSeed bug and the DRBG synchronization bug are already fixed and pushed. Thanks Max From sean.mullan at oracle.com Mon May 16 11:50:27 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 May 2016 07:50:27 -0400 Subject: Result: New Security Group Member: Jamil Nimeh Message-ID: <5739B403.2000308@oracle.com> The vote for Jamil Nimeh [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/2016-April/013781.html From xuelei.fan at oracle.com Mon May 16 12:52:40 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 May 2016 20:52:40 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing Message-ID: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> Hi, Please review this test update: http://cr.openjdk.java.net/~xuelei/8157035/webrev.00/ test/javax/net/ssl/etc/keystore and truststore are used a lot for X.509 cert based SSL/TLS authentication in JDK testing. MD5 and SHA1 are used as the signature algorithms. The key size of EC certs is 192 bits. MD5 has been disabled, and 192-bits EC keys will be disabled in the near future(see JDK-8148516). It's time to use stronger algorithms (SHA256) and keys (2048-bits for RSA and 256-bits for EC). This update renew the RSA cert with 2048-bits key and the EC cert with 256-bits key. And the hash algorithms of the signatures are now SHA256. Note that the DSA entry is not updated this time. Thanks, Xuelei From weijun.wang at oracle.com Mon May 16 13:05:41 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 May 2016 21:05:41 +0800 Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <356e7ae7-44b9-4038-92d2-82912de6db43@default> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> Message-ID: <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> Sorry, I might be not clear enough about the usage of MoreDrbgParameters and securerandom.drbg.config. You are still using MoreDrbgParameters in ApiTest.java. For example, 131 SecureRandomParameters mParam = new MoreDrbgParameters( 132 null, mech, alg, nonce, df, (Instantiation) param); 133 Security.setProperty(DRBG_CONFIG, mech); 134 SecureRandom sr = SecureRandom.getInstance("DRBG", mParam); What I wish to see is something like Security.setProperty(DRBG_CONFIG, mech + "," + alg + "," + (df ? "use_df" : "no_df")); SecureRandom sr = SecureRandom.getInstance("DRBG", param); So you are still able to iterate through different combinations of mech + alg + df using a publicly supported API. (Nonce will not be tested, it's not a part of the API.) Thanks Max > On May 16, 2016, at 6:40 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.02/ > > The changes includes, > - ApiTest.java : Removed printing unnecessary message inside checkException() method. > - GetInstanceTest.java > - Moved the test back into " java/security/SecureRandom/ ". > - Removed all reference to MoreDrbgParameters and EntropySource. > > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Thursday, May 12, 2016 9:14 AM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > > >> On May 12, 2016, at 1:46 AM, Sibabrata Sahoo wrote: >> >> Hi Max, >> >> Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/ >> >> Changes includes: >> - Removed otherVM option and default "securerandom.drbg.config" will get reset after each DRBG test run. This change affected to all test files. >> - Addressed all the following comments for GetAlgorithm.java, EnoughSeedTest.java, MultiThreadTest.java. >> - Moved ApiTest.java, into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. >> - remove SHA1 and TDEA, 3KEYTDEA" ("3 KEY TDEA", "DESEDE") >> - corrected the logic for checkException() reported bellow. > > I don't see a difference. You print out messages in those "if (strength > n)" blocks but there is no other action. What are the messages for? Information or warning? In my opinion, a test should print out as little as possible unless an error occurs. (Sometimes "Testing XYZ..." is OK). > >> - Moved GetInstanceTest.java into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. >> - I am using default as well as custom entropy source just to make sure the extension works for getInstance() method. >> - Again, I use MoreDrbgParameter, just to make sure the instance of it can be acceptable by corresponding getInstance() method. > > Well, I have a different opinion. > > I think most of your tests should be categorized as functional (or conformance) tests, so they should be focused on public APIs. In this case, the test should set "securerandom.drbg.config" to Hash_DRBG/SHA-512 instead of using MoreDrbgParameters to set algorithm to SHA-512. > > In fact, there is no requirement that MoreDrbgParameters must be accepted by getInstance(). > > MoreDrbgParameters and EntropySource are implementation details. Sometimes they are necessary (For example, CAVP tests), but you'd better avoid touching them. I did wrote some tests on them (DRBGAlg, AbstractDrbgSpec) in an implementor's perspective but you can ignore them. > >> - About SerializedSeedTest.java, I think the SHA1PRNG bug fix will get pushed to repo very soon. So the test is expected to work as the fix pushed into repo. But if you wish, I can change it accordingly. > > Both the SHA1PRNG setSeed bug and the DRBG synchronization bug are already fixed and pushed. > > Thanks > Max > > From weijun.wang at oracle.com Mon May 16 13:13:15 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 May 2016 21:13:15 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> Message-ID: I downloaded the files and they match what you described below. Can you please added a text file describing how they are generated. Also, I see a unknown_keystore in the same directory still using the weak algorithms. Do you also intent to update it? Thanks Max > On May 16, 2016, at 8:52 PM, Xuelei Fan wrote: > > Hi, > > Please review this test update: > http://cr.openjdk.java.net/~xuelei/8157035/webrev.00/ > > test/javax/net/ssl/etc/keystore and truststore are used a lot for X.509 > cert based SSL/TLS authentication in JDK testing. MD5 and SHA1 are used > as the signature algorithms. The key size of EC certs is 192 bits. > > MD5 has been disabled, and 192-bits EC keys will be disabled in the near > future(see JDK-8148516). It's time to use stronger algorithms (SHA256) > and keys (2048-bits for RSA and 256-bits for EC). > > This update renew the RSA cert with 2048-bits key and the EC cert with > 256-bits key. And the hash algorithms of the signatures are now SHA256. > > Note that the DSA entry is not updated this time. > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon May 16 13:34:01 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 May 2016 21:34:01 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> Message-ID: <20837152-26f9-e8df-3e4d-757291652299@oracle.com> On 5/16/2016 9:13 PM, Wang Weijun wrote: > I downloaded the files and they match what you described below. > > Can you please added a text file describing how they are generated. The generation is straightforward with keytool. May not need an additional text file any more. > Also, I see a unknown_keystore in the same directory still using the weak algorithms. Do you also intent to update it? > Not sure of the use cases for unknown_keystore. No plan to touch it this time. Thanks, Xuelei > Thanks > Max > >> On May 16, 2016, at 8:52 PM, Xuelei Fan wrote: >> >> Hi, >> >> Please review this test update: >> http://cr.openjdk.java.net/~xuelei/8157035/webrev.00/ >> >> test/javax/net/ssl/etc/keystore and truststore are used a lot for X.509 >> cert based SSL/TLS authentication in JDK testing. MD5 and SHA1 are used >> as the signature algorithms. The key size of EC certs is 192 bits. >> >> MD5 has been disabled, and 192-bits EC keys will be disabled in the near >> future(see JDK-8148516). It's time to use stronger algorithms (SHA256) >> and keys (2048-bits for RSA and 256-bits for EC). >> >> This update renew the RSA cert with 2048-bits key and the EC cert with >> 256-bits key. And the hash algorithms of the signatures are now SHA256. >> >> Note that the DSA entry is not updated this time. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Mon May 16 14:24:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 May 2016 22:24:33 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <20837152-26f9-e8df-3e4d-757291652299@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> <20837152-26f9-e8df-3e4d-757291652299@oracle.com> Message-ID: <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> > On May 16, 2016, at 9:34 PM, Xuelei Fan wrote: > > On 5/16/2016 9:13 PM, Wang Weijun wrote: >> I downloaded the files and they match what you described below. >> >> Can you please added a text file describing how they are generated. > The generation is straightforward with keytool. May not need an > additional text file any more. Binary files are usually not allowed in OpenJDK. If you have to include some, add some description. > >> Also, I see a unknown_keystore in the same directory still using the weak algorithms. Do you also intent to update it? >> > Not sure of the use cases for unknown_keystore. No plan to touch it > this time. It is used by CheckMyTrustedKeystore.java which has @ignore. So let it be. --Max > > Thanks, > Xuelei > >> Thanks >> Max >> >>> On May 16, 2016, at 8:52 PM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Please review this test update: >>> http://cr.openjdk.java.net/~xuelei/8157035/webrev.00/ >>> >>> test/javax/net/ssl/etc/keystore and truststore are used a lot for X.509 >>> cert based SSL/TLS authentication in JDK testing. MD5 and SHA1 are used >>> as the signature algorithms. The key size of EC certs is 192 bits. >>> >>> MD5 has been disabled, and 192-bits EC keys will be disabled in the near >>> future(see JDK-8148516). It's time to use stronger algorithms (SHA256) >>> and keys (2048-bits for RSA and 256-bits for EC). >>> >>> This update renew the RSA cert with 2048-bits key and the EC cert with >>> 256-bits key. And the hash algorithms of the signatures are now SHA256. >>> >>> Note that the DSA entry is not updated this time. >>> >>> Thanks, >>> Xuelei >> > From xuelei.fan at oracle.com Mon May 16 14:37:17 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 May 2016 22:37:17 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> <20837152-26f9-e8df-3e4d-757291652299@oracle.com> <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> Message-ID: <9b4a5e68-a533-f3c0-2de5-f32071e6b278@oracle.com> On 5/16/2016 10:24 PM, Wang Weijun wrote: >> > On May 16, 2016, at 9:34 PM, Xuelei Fan wrote: >> > >> > On 5/16/2016 9:13 PM, Wang Weijun wrote: >>> >> I downloaded the files and they match what you described below. >>> >> >>> >> Can you please added a text file describing how they are generated. >> > The generation is straightforward with keytool. May not need an >> > additional text file any more. > Binary files are usually not allowed in OpenJDK. If you have to include some, add some description. > OK. I will add a README as follow: The keystore and truststore are generated with keytool. new webrev: http://cr.openjdk.java.net/~xuelei/8157035/webrev.01/ Thanks, Xuelei From weijun.wang at oracle.com Tue May 17 02:06:06 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 May 2016 10:06:06 +0800 Subject: RFR 8138766: New default -sigalg for keytool Message-ID: <8E21DEE3-F300-4B5F-8087-9819C300E2A6@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8138766/webrev.00/ Now both jarsigner and keytool use AlgorithmId::getDefaultSigAlgForKey to decide what the default sigalg should be. Thanks Max From xuelei.fan at oracle.com Tue May 17 03:44:27 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 17 May 2016 11:44:27 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <9b4a5e68-a533-f3c0-2de5-f32071e6b278@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> <20837152-26f9-e8df-3e4d-757291652299@oracle.com> <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> <9b4a5e68-a533-f3c0-2de5-f32071e6b278@oracle.com> Message-ID: <6ce4de2c-af06-da3b-d1aa-de9272190f90@oracle.com> Update the README with more information about the stores. http://cr.openjdk.java.net/~xuelei/8157035/webrev.02/ Thanks, Xuelei On 5/16/2016 10:37 PM, Xuelei Fan wrote: > On 5/16/2016 10:24 PM, Wang Weijun wrote: >>>> On May 16, 2016, at 9:34 PM, Xuelei Fan wrote: >>>> >>>> On 5/16/2016 9:13 PM, Wang Weijun wrote: >>>>>> I downloaded the files and they match what you described below. >>>>>> >>>>>> Can you please added a text file describing how they are generated. >>>> The generation is straightforward with keytool. May not need an >>>> additional text file any more. >> Binary files are usually not allowed in OpenJDK. If you have to include some, add some description. >> > OK. I will add a README as follow: > > The keystore and truststore are generated with keytool. > > new webrev: > http://cr.openjdk.java.net/~xuelei/8157035/webrev.01/ > > Thanks, > Xuelei > From weijun.wang at oracle.com Tue May 17 03:50:37 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 May 2016 11:50:37 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <6ce4de2c-af06-da3b-d1aa-de9272190f90@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> <20837152-26f9-e8df-3e4d-757291652299@oracle.com> <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> <9b4a5e68-a533-f3c0-2de5-f32071e6b278@oracle.com> <6ce4de2c-af06-da3b-d1aa-de9272190f90@oracle.com> Message-ID: <93A2213C-194B-457A-A2B3-E48A9379D179@oracle.com> You mentioned hacked keytool. So the X.509 v3 certs cannot be used? Thanks Max > On May 17, 2016, at 11:44 AM, Xuelei Fan wrote: > > Update the README with more information about the stores. > http://cr.openjdk.java.net/~xuelei/8157035/webrev.02/ > > Thanks, > Xuelei > > On 5/16/2016 10:37 PM, Xuelei Fan wrote: >> On 5/16/2016 10:24 PM, Wang Weijun wrote: >>>>> On May 16, 2016, at 9:34 PM, Xuelei Fan wrote: >>>>> >>>>> On 5/16/2016 9:13 PM, Wang Weijun wrote: >>>>>>> I downloaded the files and they match what you described below. >>>>>>> >>>>>>> Can you please added a text file describing how they are generated. >>>>> The generation is straightforward with keytool. May not need an >>>>> additional text file any more. >>> Binary files are usually not allowed in OpenJDK. If you have to include some, add some description. >>> >> OK. I will add a README as follow: >> >> The keystore and truststore are generated with keytool. >> >> new webrev: >> http://cr.openjdk.java.net/~xuelei/8157035/webrev.01/ >> >> Thanks, >> Xuelei >> > From xuelei.fan at oracle.com Tue May 17 04:03:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 17 May 2016 12:03:28 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <93A2213C-194B-457A-A2B3-E48A9379D179@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> <20837152-26f9-e8df-3e4d-757291652299@oracle.com> <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> <9b4a5e68-a533-f3c0-2de5-f32071e6b278@oracle.com> <6ce4de2c-af06-da3b-d1aa-de9272190f90@oracle.com> <93A2213C-194B-457A-A2B3-E48A9379D179@oracle.com> Message-ID: <8fa1c244-68bb-443e-528b-cd1f749ef5a5@oracle.com> On 5/17/2016 11:50 AM, Wang Weijun wrote: > You mentioned hacked keytool. So the X.509 v3 certs cannot be used? > In order to simplify the update (as less update as possible), I would like to keep the root certs version 1 although most of the test case should accept version 3. BTW, it would be nice to have an option to support version 1 cert generation. Thanks, Xuelei > Thanks > Max > >> On May 17, 2016, at 11:44 AM, Xuelei Fan wrote: >> >> Update the README with more information about the stores. >> http://cr.openjdk.java.net/~xuelei/8157035/webrev.02/ >> >> Thanks, >> Xuelei >> >> On 5/16/2016 10:37 PM, Xuelei Fan wrote: >>> On 5/16/2016 10:24 PM, Wang Weijun wrote: >>>>>> On May 16, 2016, at 9:34 PM, Xuelei Fan wrote: >>>>>> >>>>>> On 5/16/2016 9:13 PM, Wang Weijun wrote: >>>>>>>> I downloaded the files and they match what you described below. >>>>>>>> >>>>>>>> Can you please added a text file describing how they are generated. >>>>>> The generation is straightforward with keytool. May not need an >>>>>> additional text file any more. >>>> Binary files are usually not allowed in OpenJDK. If you have to include some, add some description. >>>> >>> OK. I will add a README as follow: >>> >>> The keystore and truststore are generated with keytool. >>> >>> new webrev: >>> http://cr.openjdk.java.net/~xuelei/8157035/webrev.01/ >>> >>> Thanks, >>> Xuelei >>> >> > From weijun.wang at oracle.com Tue May 17 04:11:06 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 May 2016 12:11:06 +0800 Subject: Code Review Request of JDK-8157035 Use stronger algorithms and keys for JSSE testing In-Reply-To: <8fa1c244-68bb-443e-528b-cd1f749ef5a5@oracle.com> References: <7e6db245-f4e2-ec2a-527e-cebb22f48e3c@oracle.com> <20837152-26f9-e8df-3e4d-757291652299@oracle.com> <51CB145E-2C63-4AE0-8FDA-068EB83917E2@oracle.com> <9b4a5e68-a533-f3c0-2de5-f32071e6b278@oracle.com> <6ce4de2c-af06-da3b-d1aa-de9272190f90@oracle.com> <93A2213C-194B-457A-A2B3-E48A9379D179@oracle.com> <8fa1c244-68bb-443e-528b-cd1f749ef5a5@oracle.com> Message-ID: <980E8300-92AF-4684-90ED-BF30AA1873AC@oracle.com> OK, it's fine. Please go on. > On May 17, 2016, at 12:03 PM, Xuelei Fan wrote: > > On 5/17/2016 11:50 AM, Wang Weijun wrote: >> You mentioned hacked keytool. So the X.509 v3 certs cannot be used? >> > In order to simplify the update (as less update as possible), I would > like to keep the root certs version 1 although most of the test case > should accept version 3. > > BTW, it would be nice to have an option to support version 1 cert > generation. I'll think about it. Can you give some reason (in another mail)? I need to convince myself this is useful enough. Thanks Max > > Thanks, > Xuelei > >> Thanks >> Max >> >>> On May 17, 2016, at 11:44 AM, Xuelei Fan wrote: >>> >>> Update the README with more information about the stores. >>> http://cr.openjdk.java.net/~xuelei/8157035/webrev.02/ >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Tue May 17 04:25:38 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 17 May 2016 12:25:38 +0800 Subject: Support version 1 cert generation Message-ID: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> Hi, Keytool used to generate version 1 self-signed certificates. Now it is mandatory to be version 3. Default version 3 should be OK. However, in some circumstances (for example for testing purpose), version 1 self-signed certificate may still be useful. It would be a low priority, but may be nice to add an option to support specified certificate version number for certificate generation. Thanks, Xuelei From weijun.wang at oracle.com Tue May 17 04:44:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 May 2016 12:44:42 +0800 Subject: Support version 1 cert generation In-Reply-To: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> References: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> Message-ID: <93BA69C8-4ECA-4D64-BB2D-4982194B416E@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8157109 filed. --Max > On May 17, 2016, at 12:25 PM, Xuelei Fan wrote: > > Hi, > > Keytool used to generate version 1 self-signed certificates. Now it is > mandatory to be version 3. Default version 3 should be OK. However, in > some circumstances (for example for testing purpose), version 1 > self-signed certificate may still be useful. > > It would be a low priority, but may be nice to add an option to support > specified certificate version number for certificate generation. > > Thanks, > Xuelei From zoltan.majo at oracle.com Tue May 17 05:37:49 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 17 May 2016 07:37:49 +0200 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <1463249505676-271376.post@n7.nabble.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> <552D584E.50201@oracle.com> <552D66D2.2040805@oracle.com> <1463249505676-271376.post@n7.nabble.com> Message-ID: <573AAE2D.2070300@oracle.com> Hi, On 05/14/2016 08:11 PM, Yozons wrote: > Has this fix been incorporated in a release yet? If so, which one? Thanks! I think it's out with 8u60. Best regards, Zoltan > > > > -- > View this message in context: http://openjdk.5641.n7.nabble.com/9-RFR-S-8067648-JVM-crashes-reproducable-with-GCM-cipher-suites-in-GCTR-doFinal-tp222764p271376.html > Sent from the OpenJDK Security Development mailing list archive at Nabble.com. From sibabrata.sahoo at oracle.com Tue May 17 08:13:13 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 17 May 2016 01:13:13 -0700 (PDT) Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> Message-ID: <634258e3-1928-4eb8-ac7c-e80003383692@default> Hi Max, Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.03/ I misinterpreted your previous comment that the following change is only applicable to getInstanceTest.java and not applicable to ApiTest.java. The change includes, - ApiTest.java moved to " java/security/SecureRandom ". - Removed reference to MoreDrbgParameters from ApiTest.java Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Monday, May 16, 2016 6:36 PM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations Sorry, I might be not clear enough about the usage of MoreDrbgParameters and securerandom.drbg.config. You are still using MoreDrbgParameters in ApiTest.java. For example, 131 SecureRandomParameters mParam = new MoreDrbgParameters( 132 null, mech, alg, nonce, df, (Instantiation) param); 133 Security.setProperty(DRBG_CONFIG, mech); 134 SecureRandom sr = SecureRandom.getInstance("DRBG", mParam); What I wish to see is something like Security.setProperty(DRBG_CONFIG, mech + "," + alg + "," + (df ? "use_df" : "no_df")); SecureRandom sr = SecureRandom.getInstance("DRBG", param); So you are still able to iterate through different combinations of mech + alg + df using a publicly supported API. (Nonce will not be tested, it's not a part of the API.) Thanks Max > On May 16, 2016, at 6:40 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.02/ > > The changes includes, > - ApiTest.java : Removed printing unnecessary message inside checkException() method. > - GetInstanceTest.java > - Moved the test back into " java/security/SecureRandom/ ". > - Removed all reference to MoreDrbgParameters and EntropySource. > > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Thursday, May 12, 2016 9:14 AM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > > >> On May 12, 2016, at 1:46 AM, Sibabrata Sahoo wrote: >> >> Hi Max, >> >> Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.01/ >> >> Changes includes: >> - Removed otherVM option and default "securerandom.drbg.config" will get reset after each DRBG test run. This change affected to all test files. >> - Addressed all the following comments for GetAlgorithm.java, EnoughSeedTest.java, MultiThreadTest.java. >> - Moved ApiTest.java, into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. >> - remove SHA1 and TDEA, 3KEYTDEA" ("3 KEY TDEA", "DESEDE") >> - corrected the logic for checkException() reported bellow. > > I don't see a difference. You print out messages in those "if (strength > n)" blocks but there is no other action. What are the messages for? Information or warning? In my opinion, a test should print out as little as possible unless an error occurs. (Sometimes "Testing XYZ..." is OK). > >> - Moved GetInstanceTest.java into "sun/security/provider/SecureRandom" because it uses MoreDrbgParameters. >> - I am using default as well as custom entropy source just to make sure the extension works for getInstance() method. >> - Again, I use MoreDrbgParameter, just to make sure the instance of it can be acceptable by corresponding getInstance() method. > > Well, I have a different opinion. > > I think most of your tests should be categorized as functional (or conformance) tests, so they should be focused on public APIs. In this case, the test should set "securerandom.drbg.config" to Hash_DRBG/SHA-512 instead of using MoreDrbgParameters to set algorithm to SHA-512. > > In fact, there is no requirement that MoreDrbgParameters must be accepted by getInstance(). > > MoreDrbgParameters and EntropySource are implementation details. Sometimes they are necessary (For example, CAVP tests), but you'd better avoid touching them. I did wrote some tests on them (DRBGAlg, AbstractDrbgSpec) in an implementor's perspective but you can ignore them. > >> - About SerializedSeedTest.java, I think the SHA1PRNG bug fix will get pushed to repo very soon. So the test is expected to work as the fix pushed into repo. But if you wish, I can change it accordingly. > > Both the SHA1PRNG setSeed bug and the DRBG synchronization bug are already fixed and pushed. > > Thanks > Max > > From sean.mullan at oracle.com Tue May 17 11:45:26 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 May 2016 07:45:26 -0400 Subject: Support version 1 cert generation In-Reply-To: <93BA69C8-4ECA-4D64-BB2D-4982194B416E@oracle.com> References: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> <93BA69C8-4ECA-4D64-BB2D-4982194B416E@oracle.com> Message-ID: <573B0456.5000507@oracle.com> Hi Xuelei, Can you elaborate under what circumstances this is useful for testing? X.509 v3 was first published in 1996, and v1 certificates should be pretty much non-existent these days (although there are some root certs that are still v1). v1 certificates do not support extensions. Adding support may cause users to (accidentally) start using them in practice, which would not be good. PKIX (RFC 3280) states that "Conforming implementations may choose to reject all version 1 and version 2 intermediate certificates." (RFC 5280, section 6.1.4 step k). Thanks, Sean On 05/17/2016 12:44 AM, Wang Weijun wrote: > https://bugs.openjdk.java.net/browse/JDK-8157109 filed. > > --Max > >> On May 17, 2016, at 12:25 PM, Xuelei Fan wrote: >> >> Hi, >> >> Keytool used to generate version 1 self-signed certificates. Now it is >> mandatory to be version 3. Default version 3 should be OK. However, in >> some circumstances (for example for testing purpose), version 1 >> self-signed certificate may still be useful. >> >> It would be a low priority, but may be nice to add an option to support >> specified certificate version number for certificate generation. >> >> Thanks, >> Xuelei > From Xuelei.Fan at Oracle.Com Tue May 17 16:12:27 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 18 May 2016 00:12:27 +0800 Subject: Support version 1 cert generation In-Reply-To: <573B0456.5000507@oracle.com> References: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> <93BA69C8-4ECA-4D64-BB2D-4982194B416E@oracle.com> <573B0456.5000507@oracle.com> Message-ID: JDK still support version 1 cert. Developers may want to test version 1 support of their applications. I agree that version 1 should be fade out although it is still actively used the practice, especially as self signed cert. It may be something that we only want to consider for self-signed cert on request. Thanks, Xuelei > On May 17, 2016, at 7:45 PM, Sean Mullan wrote: > > Hi Xuelei, > > Can you elaborate under what circumstances this is useful for testing? X.509 v3 was first published in 1996, and v1 certificates should be pretty much non-existent these days (although there are some root certs that are still v1). v1 certificates do not support extensions. Adding support may cause users to (accidentally) start using them in practice, which would not be good. PKIX (RFC 3280) states that "Conforming implementations may choose to reject all version 1 and version 2 intermediate certificates." (RFC 5280, section 6.1.4 step k). > > Thanks, > Sean > >> On 05/17/2016 12:44 AM, Wang Weijun wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157109 filed. >> >> --Max >> >>> On May 17, 2016, at 12:25 PM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Keytool used to generate version 1 self-signed certificates. Now it is >>> mandatory to be version 3. Default version 3 should be OK. However, in >>> some circumstances (for example for testing purpose), version 1 >>> self-signed certificate may still be useful. >>> >>> It would be a low priority, but may be nice to add an option to support >>> specified certificate version number for certificate generation. >>> >>> Thanks, >>> Xuelei >> From valerie.peng at oracle.com Tue May 17 20:09:33 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 17 May 2016 13:09:33 -0700 Subject: RFR 8155847: SHA groups needed for jdk.security.provider.preferred In-Reply-To: <5733B63D.9020802@oracle.com> References: <5733B63D.9020802@oracle.com> Message-ID: <573B7A7D.50205@oracle.com> Hi Tony, Here are some comments/questions: - make PreferredEntry class static? Are these fields accessed directly by other classes? If not, then we can mark them private? - "alternateName" should be "alternativeNames" now that it contains multiple values? - In the match method, ls it really necessary to print value of (t,a) on line 739 for all alternateName values? It's already printed out earlier. - with the current webrev, the Group.XXX entries will have type = null, algorithm = null, its toString() will print out [, null: provName]. Doesn't seem quite right? Maybe it's worthwhile to keep the type and algorithm but then detect and special handling it in the match()? - line 81 - 85, shouldn't it be "SunJCE" instead of "SUN"? Would this not lead to a test failure? - So, as we add more algorithms, say RSA or DSA signatures using SHA-512/224 or SHA-3 family of digests to the default list of providers, then we update the values here again (Currently, Group.SHA2 contains different values to the rest of SHA2 application (Hmac, Signature) groups) and again file CCCs for this? Would this limit our capability to add more algorithms to update releases? Thanks, Valerie On 5/11/2016 3:46 PM, Anthony Scarpino wrote: > 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 From anthony.scarpino at oracle.com Tue May 17 21:04:27 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 May 2016 14:04:27 -0700 Subject: RFR 8155847: SHA groups needed for jdk.security.provider.preferred In-Reply-To: <573B7A7D.50205@oracle.com> References: <5733B63D.9020802@oracle.com> <573B7A7D.50205@oracle.com> Message-ID: <573B875B.2000601@oracle.com> On 05/17/2016 01:09 PM, Valerie Peng wrote: > Hi Tony, > > Here are some comments/questions: > > - make PreferredEntry class static? Are these fields accessed directly > by other classes? If not, then we can mark them private? Yes they can be private and the class static. > - "alternateName" should be "alternativeNames" now that it contains > multiple values? sure > - In the match method, ls it really necessary to print value of (t,a) on > line 739 for all alternateName values? It's already printed out earlier. removing that part of the debug is fine. > - with the current webrev, the Group.XXX entries will have type = null, > algorithm = null, its toString() will print out [, null: provName]. > Doesn't seem quite right? Maybe it's worthwhile to keep the type and > algorithm but then detect and special handling it in the match()? I was trying to avoid using another variable, but I admit the debug prints suffer without a boolean. I added a boolean called "group" that will be the check. > > > - line 81 - 85, shouldn't it be "SunJCE" instead of "SUN"? Would this > not lead to a test failure? Yes.. thanks.. > > > - So, as we add more algorithms, say RSA or DSA signatures using > SHA-512/224 or SHA-3 family of digests to the default list of providers, > then we update the values here again (Currently, Group.SHA2 contains > different values to the rest of SHA2 application (Hmac, Signature) > groups) and again file CCCs for 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 provider list for processing. > > Thanks, > Valerie > > On 5/11/2016 3:46 PM, Anthony Scarpino wrote: >> 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 From weijun.wang at oracle.com Wed May 18 08:07:22 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 May 2016 16:07:22 +0800 Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <634258e3-1928-4eb8-ac7c-e80003383692@default> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> <634258e3-1928-4eb8-ac7c-e80003383692@default> Message-ID: ApiTest.java: - Please move line 128-130 (the System.out.println) line before line 127, so that if getInstance() fails, we can see what parameters are failing. - Useless line 69. - Inside verifyAPI(), you call nextBytes(.., DrbgParameters.nextBytes(-1, false, ..)). Can you also call nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..))? It should fail unless the instantiation parameters has PR_AND_RESEED. You can use Capability::supportsPredictionResistance to check it. Same with reseed(DrbgParameters.reseed(true,..)). - Can you use Supplier instead of creating a new RunnableCode type? Same in GetInstanceTest.java. - If matchExc always calls checkException, why not use a single method? Same in GetInstanceTest.java. - SUCESS is not final, you shouldn't use ALL CAPITAL letters for it. Same in GetInstanceTest.java. SerializedSeedTest.java: - The SHA1PRNG bug is fixed and has its own regression test. You can remove related codes here. Thanks Max > On May 17, 2016, at 4:13 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.03/ > I misinterpreted your previous comment that the following change is only applicable to getInstanceTest.java and not applicable to ApiTest.java. > > The change includes, > - ApiTest.java moved to " java/security/SecureRandom ". > - Removed reference to MoreDrbgParameters from ApiTest.java > > Thanks, > Siba From sean.mullan at oracle.com Wed May 18 14:55:32 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 May 2016 10:55:32 -0400 Subject: RFR 8138766: New default -sigalg for keytool In-Reply-To: <8E21DEE3-F300-4B5F-8087-9819C300E2A6@oracle.com> References: <8E21DEE3-F300-4B5F-8087-9819C300E2A6@oracle.com> Message-ID: <573C8264.805@oracle.com> Looks good to me. Please create a release-note subtask so that this change in keytool defaults gets documented in the JDK 9 release notes. (There should also be one for the jarsigner tool). Thanks, Sean On 05/16/2016 10:06 PM, Wang Weijun wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8138766/webrev.00/ > > Now both jarsigner and keytool use AlgorithmId::getDefaultSigAlgForKey to decide what the default sigalg should be. > > Thanks > Max > From weijun.wang at oracle.com Wed May 18 15:03:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 May 2016 23:03:28 +0800 Subject: RFR 8138766: New default -sigalg for keytool In-Reply-To: <573C8264.805@oracle.com> References: <8E21DEE3-F300-4B5F-8087-9819C300E2A6@oracle.com> <573C8264.805@oracle.com> Message-ID: <9B0248C8-48CC-4869-9DFF-8C27754F7A2F@oracle.com> A subtask? So the release-note=yes label is not enough now? --Max > ? 2016?5?18??22:55?Sean Mullan ??? > > Please create a release-note subtask so that this change in keytool defaults gets documented in the JDK 9 release notes. (There should also be one for the jarsigner tool). From sean.mullan at oracle.com Wed May 18 15:05:01 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 May 2016 11:05:01 -0400 Subject: Support version 1 cert generation In-Reply-To: References: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> <93BA69C8-4ECA-4D64-BB2D-4982194B416E@oracle.com> <573B0456.5000507@oracle.com> Message-ID: <573C849D.5060902@oracle.com> On 05/17/2016 12:12 PM, Xuelei Fan wrote: > JDK still support version 1 cert. Developers may want to test > version 1 support of their applications. I agree that version 1 > should be fade out although it is still actively used the practice, > especially as self signed cert. I agree that we need to continue supporting them in our implementation. However, I don't think we should add new tool support for creating v1 certs as that may encourage continued use of them (or misuse where it would be better to use extensions). I guess I don't really see a compelling need to support this, as a V3 certificate can also be used as a self-signed cert. --Sean > > It may be something that we only want to consider for self-signed > cert on request. > > Thanks, Xuelei > >> On May 17, 2016, at 7:45 PM, Sean Mullan >> wrote: >> >> Hi Xuelei, >> >> Can you elaborate under what circumstances this is useful for >> testing? X.509 v3 was first published in 1996, and v1 certificates >> should be pretty much non-existent these days (although there are >> some root certs that are still v1). v1 certificates do not support >> extensions. Adding support may cause users to (accidentally) start >> using them in practice, which would not be good. PKIX (RFC 3280) >> states that "Conforming implementations may choose to reject all >> version 1 and version 2 intermediate certificates." (RFC 5280, >> section 6.1.4 step k). >> >> Thanks, Sean >> >>> On 05/17/2016 12:44 AM, Wang Weijun wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8157109 filed. >>> >>> --Max >>> >>>> On May 17, 2016, at 12:25 PM, Xuelei Fan >>>> wrote: >>>> >>>> Hi, >>>> >>>> Keytool used to generate version 1 self-signed certificates. >>>> Now it is mandatory to be version 3. Default version 3 should >>>> be OK. However, in some circumstances (for example for testing >>>> purpose), version 1 self-signed certificate may still be >>>> useful. >>>> >>>> It would be a low priority, but may be nice to add an option to >>>> support specified certificate version number for certificate >>>> generation. >>>> >>>> Thanks, Xuelei >>> > From xuelei.fan at oracle.com Wed May 18 15:19:53 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 May 2016 23:19:53 +0800 Subject: Code Review Request JDK-8151856, Note that disabledAlgorithms override the same algorithms of legacyAlgorithm Message-ID: Hi, Please review this spec update of the "jdk.tls.legacyAlgorithms" Security Property: http://cr.openjdk.java.net/~xuelei/8151856/webrev/ This updated spec clarifies the impact between the "jdk.tls.legacyAlgorithms" and "jdk.tls.disabledAlgorithms" Security Properties. Thanks, Xuelei From mstjohns at comcast.net Wed May 18 17:25:53 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 18 May 2016 13:25:53 -0400 Subject: Support version 1 cert generation In-Reply-To: <573B0456.5000507@oracle.com> References: <7819c2a6-aee0-85c5-cf92-c3ae69de7a26@oracle.com> <93BA69C8-4ECA-4D64-BB2D-4982194B416E@oracle.com> <573B0456.5000507@oracle.com> Message-ID: <1f75a023-7a2f-6636-09cd-f26912d5f360@comcast.net> Hi - To be very specific here - if a certificate has extensions, it MUST be version 3, otherwise it SHOULD be version 1, but may be version 2 or 3. (If a certificate has either of the issuer or subject unique ID fields, it must be at least version 2 - but those fields are deprecated as a MUST NOT for conforming CAs, so you should never issue a certificate with those fields). A CA certificate (i.e. an intermediate certificate) is required to have a basicConstraints extension - and must be a version three certificate. If you do this (support V1 cert gen), I'd make it a side effect of whether or not you add extensions instead of a discrete option. Later, Mike On 5/17/2016 7:45 AM, Sean Mullan wrote: > Hi Xuelei, > > Can you elaborate under what circumstances this is useful for testing? > X.509 v3 was first published in 1996, and v1 certificates should be > pretty much non-existent these days (although there are some root > certs that are still v1). v1 certificates do not support extensions. > Adding support may cause users to (accidentally) start using them in > practice, which would not be good. PKIX (RFC 3280) states that > "Conforming implementations may choose to reject all version 1 and > version 2 intermediate certificates." (RFC 5280, section 6.1.4 step k). > > Thanks, > Sean > > On 05/17/2016 12:44 AM, Wang Weijun wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157109 filed. >> >> --Max >> >>> On May 17, 2016, at 12:25 PM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Keytool used to generate version 1 self-signed certificates. Now it is >>> mandatory to be version 3. Default version 3 should be OK. However, in >>> some circumstances (for example for testing purpose), version 1 >>> self-signed certificate may still be useful. >>> >>> It would be a low priority, but may be nice to add an option to support >>> specified certificate version number for certificate generation. >>> >>> Thanks, >>> Xuelei >> From rajan.halade at oracle.com Wed May 18 17:41:07 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 18 May 2016 10:41:07 -0700 Subject: RFR: 9: 8156035: Remove intermittent key from sun/security/rsa/SpecTest.java Message-ID: <573CA933.8000201@oracle.com> Please review this small change to remove intermittent key from this test. JDK-8137231 addressed intermittent failure and we haven't seen test failure for a long time and with frequent runs. Bug: https://bugs.openjdk.java.net/browse/JDK-8156035 diff -r 3675fb8573d4 test/sun/security/rsa/SpecTest.java --- a/test/sun/security/rsa/SpecTest.java Wed May 18 18:46:14 2016 +0200 +++ b/test/sun/security/rsa/SpecTest.java Wed May 18 10:37:42 2016 -0700 @@ -24,7 +24,6 @@ /** * @test * @bug 8044199 8137231 - * @key intermittent * @summary Check same KeyPair's private key and public key have same modulus. * also check public key's public exponent equals to given spec's public * exponent. Only key size 1024 is tested with RSAKeyGenParameterSpec.F0 (3). Thanks, Rajan From sean.mullan at oracle.com Wed May 18 20:24:57 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 May 2016 16:24:57 -0400 Subject: RFR: 9: 8156035: Remove intermittent key from sun/security/rsa/SpecTest.java In-Reply-To: <573CA933.8000201@oracle.com> References: <573CA933.8000201@oracle.com> Message-ID: <573CCF99.9070802@oracle.com> Looks fine to me. --Sean On 05/18/2016 01:41 PM, Rajan Halade wrote: > Please review this small change to remove intermittent key from this > test. JDK-8137231 addressed intermittent failure and we haven't seen > test failure for a long time and with frequent runs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156035 > > diff -r 3675fb8573d4 test/sun/security/rsa/SpecTest.java > --- a/test/sun/security/rsa/SpecTest.java Wed May 18 18:46:14 2016 +0200 > +++ b/test/sun/security/rsa/SpecTest.java Wed May 18 10:37:42 2016 -0700 > @@ -24,7 +24,6 @@ > /** > * @test > * @bug 8044199 8137231 > - * @key intermittent > * @summary Check same KeyPair's private key and public key have same > modulus. > * also check public key's public exponent equals to given spec's public > * exponent. Only key size 1024 is tested with > RSAKeyGenParameterSpec.F0 (3). > > Thanks, > Rajan From sean.mullan at oracle.com Wed May 18 20:39:53 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 May 2016 16:39:53 -0400 Subject: Code Review Request JDK-8151856, Note that disabledAlgorithms override the same algorithms of legacyAlgorithm In-Reply-To: References: Message-ID: <573CD319.8020305@oracle.com> 719 # javax.net.ssl.SSLParameters.getAlgorithmConstraints()), I think it should be setAlgorithmConstraints. Otherwise, looks fine to me. --Sean On 05/18/2016 11:19 AM, Xuelei Fan wrote: > Hi, > > Please review this spec update of the "jdk.tls.legacyAlgorithms" > Security Property: > > http://cr.openjdk.java.net/~xuelei/8151856/webrev/ > > This updated spec clarifies the impact between the > "jdk.tls.legacyAlgorithms" and "jdk.tls.disabledAlgorithms" Security > Properties. > > Thanks, > Xuelei > From artem.smotrakov at oracle.com Wed May 18 21:57:45 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 18 May 2016 14:57:45 -0700 Subject: [9] RFR: 8134267: javax/net/ssl/TLS/TestJSSE.java fails intermittently with BindException: Address already in use Message-ID: <573CE559.5000502@oracle.com> Hello, Please review the following patch for javax/net/ssl/TLS/TestJSSE.java test. The test fails intermittently with BindException because it can use a busy port. The test uses jdk.testlibrary.Utils.getFreePort() which creates a server socket, and returns its local port number. Then this port number is used to creates a new SSL server socket. It looks like the port may be already busy when a new SSL socket is being created. The patch removes usage of jdk.testlibrary.Utils.getFreePort(). Now the SSL server creates a server socket by calling SSLServerSocketFactory.createServerSocket(0) which opens a socket on a free port. Then this port number is passed to the client. Bug: https://bugs.openjdk.java.net/browse/JDK-8134267 Webrev: http://cr.openjdk.java.net/~asmotrak/8134267/webrev.00/ Artem From xuelei.fan at oracle.com Wed May 18 22:52:13 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 May 2016 06:52:13 +0800 Subject: Code Review Request JDK-8151856, Note that disabledAlgorithms override the same algorithms of legacyAlgorithm In-Reply-To: <573CD319.8020305@oracle.com> References: <573CD319.8020305@oracle.com> Message-ID: <4dd7daf8-14e8-8e31-2d65-ce889e8c2dd4@oracle.com> On 5/19/2016 4:39 AM, Sean Mullan wrote: > 719 # javax.net.ssl.SSLParameters.getAlgorithmConstraints()), > > I think it should be setAlgorithmConstraints. > Yes. Thanks, Xuelei > Otherwise, looks fine to me. > > --Sean > > On 05/18/2016 11:19 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this spec update of the "jdk.tls.legacyAlgorithms" >> Security Property: >> >> http://cr.openjdk.java.net/~xuelei/8151856/webrev/ >> >> This updated spec clarifies the impact between the >> "jdk.tls.legacyAlgorithms" and "jdk.tls.disabledAlgorithms" Security >> Properties. >> >> Thanks, >> Xuelei >> From weijun.wang at oracle.com Wed May 18 23:15:01 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 May 2016 07:15:01 +0800 Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> <634258e3-1928-4eb8-ac7c-e80003383692@default> Message-ID: <6FAD79A6-721E-4103-B48F-6BF94A9CB696@oracle.com> > On May 18, 2016, at 4:07 PM, Wang Weijun wrote: > > - Can you use Supplier instead of creating a new RunnableCode type? Same in GetInstanceTest.java. You're right. We need a new type because of that checkedException. --Max From artem.smotrakov at oracle.com Thu May 19 03:28:46 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 18 May 2016 20:28:46 -0700 Subject: [9] RFR: 8129389: javax/net/ssl/DTLS tests fail intermittently Message-ID: <573D32EE.3050504@oracle.com> Hello, Please review the following patch for DTLS tests. A couple of DTLS tests which are based on DTLSOverDatagram.java fail intermittently. I was not able to reproduce these failures. I am proposing to update the tests to print more information to logs, so that more information will be available if they fail next time. I also noticed that the tests doesn't check for FINISHED handshake status which can be returned by wrap/unwrap methods. This status should indicate that handshake finished. Changes: - enabled debug output by setting "javax.net.debug" system property to "ssl" - added more logging to handshaking code - updated handshaking code to check for FINISHED status - added more checks to handshaking code - added try-with-resources blocks for sockets and file input streams - removed suppressed exceptions to make logs clearer Bug: https://bugs.openjdk.java.net/browse/JDK-8129389 Webrev: http://cr.openjdk.java.net/~asmotrak/8129389/webrev.00/ Artem From sibabrata.sahoo at oracle.com Thu May 19 07:16:39 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 19 May 2016 00:16:39 -0700 (PDT) Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> <634258e3-1928-4eb8-ac7c-e80003383692@default> Message-ID: Hi Max, Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.04/ Changes included: - Added new cases in ApiTest.java to address " nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..)) " and " reseed(DrbgParameters.reseed(true,..)) " - Decoration comments defined bellow. - Removed unnecessary checkException() call. - I have not addressed using " Supplier " because some of API method throws checked exception. - Also I am thinking the test case for SHA1PRNG bug inside SerializedSeedTest.java, still a valid case for other DRBG. So I am keeping the file unchanged. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Wednesday, May 18, 2016 1:37 PM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations ApiTest.java: - Please move line 128-130 (the System.out.println) line before line 127, so that if getInstance() fails, we can see what parameters are failing. - Useless line 69. - Inside verifyAPI(), you call nextBytes(.., DrbgParameters.nextBytes(-1, false, ..)). Can you also call nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..))? It should fail unless the instantiation parameters has PR_AND_RESEED. You can use Capability::supportsPredictionResistance to check it. Same with reseed(DrbgParameters.reseed(true,..)). - Can you use Supplier instead of creating a new RunnableCode type? Same in GetInstanceTest.java. - If matchExc always calls checkException, why not use a single method? Same in GetInstanceTest.java. - SUCESS is not final, you shouldn't use ALL CAPITAL letters for it. Same in GetInstanceTest.java. SerializedSeedTest.java: - The SHA1PRNG bug is fixed and has its own regression test. You can remove related codes here. Thanks Max > On May 17, 2016, at 4:13 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.03/ > I misinterpreted your previous comment that the following change is only applicable to getInstanceTest.java and not applicable to ApiTest.java. > > The change includes, > - ApiTest.java moved to " java/security/SecureRandom ". > - Removed reference to MoreDrbgParameters from ApiTest.java > > Thanks, > Siba From weijun.wang at oracle.com Thu May 19 07:49:29 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 May 2016 15:49:29 +0800 Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> <634258e3-1928-4eb8-ac7c-e80003383692@default> Message-ID: <5DBC44ED-0DBE-4820-ACD1-3C9727E06DE9@oracle.com> SerializedTest.java: 140: s/Atleast/At least/ 51: I don't think TRY_FOR is needed, you can only check once. Everything else is fine. Thanks Max > On May 19, 2016, at 3:16 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.04/ > > Changes included: > - Added new cases in ApiTest.java to address " nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..)) " and " reseed(DrbgParameters.reseed(true,..)) " > - Decoration comments defined bellow. > - Removed unnecessary checkException() call. > > > - I have not addressed using " Supplier " because some of API method throws checked exception. > - Also I am thinking the test case for SHA1PRNG bug inside SerializedSeedTest.java, still a valid case for other DRBG. So I am keeping the file unchanged. > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Wednesday, May 18, 2016 1:37 PM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > > ApiTest.java: > > - Please move line 128-130 (the System.out.println) line before line 127, so that if getInstance() fails, we can see what parameters are failing. > > - Useless line 69. > > - Inside verifyAPI(), you call nextBytes(.., DrbgParameters.nextBytes(-1, false, ..)). Can you also call nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..))? It should fail unless the instantiation parameters has PR_AND_RESEED. You can use Capability::supportsPredictionResistance to check it. Same with reseed(DrbgParameters.reseed(true,..)). > > - Can you use Supplier instead of creating a new RunnableCode type? Same in GetInstanceTest.java. > > - If matchExc always calls checkException, why not use a single method? Same in GetInstanceTest.java. > > - SUCESS is not final, you shouldn't use ALL CAPITAL letters for it. Same in GetInstanceTest.java. > > SerializedSeedTest.java: > > - The SHA1PRNG bug is fixed and has its own regression test. You can remove related codes here. > > Thanks > Max > >> On May 17, 2016, at 4:13 PM, Sibabrata Sahoo wrote: >> >> Hi Max, >> >> Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.03/ >> I misinterpreted your previous comment that the following change is only applicable to getInstanceTest.java and not applicable to ApiTest.java. >> >> The change includes, >> - ApiTest.java moved to " java/security/SecureRandom ". >> - Removed reference to MoreDrbgParameters from ApiTest.java >> >> Thanks, >> Siba > From chris.hegarty at oracle.com Thu May 19 08:03:33 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 May 2016 09:03:33 +0100 Subject: [9] RFR: 8134267: javax/net/ssl/TLS/TestJSSE.java fails intermittently with BindException: Address already in use In-Reply-To: <573CE559.5000502@oracle.com> References: <573CE559.5000502@oracle.com> Message-ID: <42625F1B-AA47-412B-B09B-2C53330FC367@oracle.com> On 18 May 2016, at 22:57, Artem Smotrakov wrote: > Hello, > > Please review the following patch for javax/net/ssl/TLS/TestJSSE.java test. > > The test fails intermittently with BindException because it can use a busy port. The test uses jdk.testlibrary.Utils.getFreePort() which creates a server socket, and returns its local port number. Then this port number is used to creates a new SSL server socket. It looks like the port may be already busy when a new SSL socket is being created. Thank you for changing this. getFreePort is a bad pattern that leads to intermittent failures. We should remove its usage wherever possible. > The patch removes usage of jdk.testlibrary.Utils.getFreePort(). Now the SSL server creates a server socket by calling SSLServerSocketFactory.createServerSocket(0) which opens a socket on a free port. Then this port number is passed to the client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134267 > Webrev: http://cr.openjdk.java.net/~asmotrak/8134267/webrev.00/ The changes look good to me. -Chris. From weijun.wang at oracle.com Thu May 19 08:21:25 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 May 2016 16:21:25 +0800 Subject: RFR 8157308: DRBG serialization fix Message-ID: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ Now that DRBG does not save any internal state during serialization, all DRBG implementations (HashDrbg, HmacDrbg, CtrDrbg) still extends SecureRandomSpi and contain quite some @serial fields. If some of them is corrupted a deserialized DRBG may run expectedly, it also prevents class evolution. The fix is to make AbstractDrbg no more a SecureRandomSpi child so no more serializable. DRBG is still a SecureRandomSpi child and its only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is also made serializable. One new test is added. Since AbstractDrbg is no longer a SecureRandomSpi, its child class can no longer be registered in a SecureRandom provider, and the AbstractDrbgSpec.java test is removed. Thanks Max From sibabrata.sahoo at oracle.com Thu May 19 08:39:56 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 19 May 2016 01:39:56 -0700 (PDT) Subject: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5DBC44ED-0DBE-4820-ACD1-3C9727E06DE9@oracle.com> References: <08686A57-0428-48D6-88DE-CB33A270E867@oracle.com> <4499f424-ed72-4fc8-9b6b-1227c4e7a4ef@default> <34577326-C6CB-41E2-87E0-40E54D32CCEC@oracle.com> <356e7ae7-44b9-4038-92d2-82912de6db43@default> <92A64978-6AE0-4BCE-9FAA-96D038E680F4@oracle.com> <634258e3-1928-4eb8-ac7c-e80003383692@default> <5DBC44ED-0DBE-4820-ACD1-3C9727E06DE9@oracle.com> Message-ID: <15a5a2bf-6242-42ac-94b3-33d0d013f792@default> Hi Max, Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.05/ Can you please help me push the change. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Thursday, May 19, 2016 1:19 PM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations SerializedTest.java: 140: s/Atleast/At least/ 51: I don't think TRY_FOR is needed, you can only check once. Everything else is fine. Thanks Max > On May 19, 2016, at 3:16 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.04/ > > Changes included: > - Added new cases in ApiTest.java to address " nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..)) " and " reseed(DrbgParameters.reseed(true,..)) " > - Decoration comments defined bellow. > - Removed unnecessary checkException() call. > > > - I have not addressed using " Supplier " because some of API method throws checked exception. > - Also I am thinking the test case for SHA1PRNG bug inside SerializedSeedTest.java, still a valid case for other DRBG. So I am keeping the file unchanged. > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Wednesday, May 18, 2016 1:37 PM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > > ApiTest.java: > > - Please move line 128-130 (the System.out.println) line before line 127, so that if getInstance() fails, we can see what parameters are failing. > > - Useless line 69. > > - Inside verifyAPI(), you call nextBytes(.., DrbgParameters.nextBytes(-1, false, ..)). Can you also call nextBytes(.., DrbgParameters.nextBytes(-1, *true*, ..))? It should fail unless the instantiation parameters has PR_AND_RESEED. You can use Capability::supportsPredictionResistance to check it. Same with reseed(DrbgParameters.reseed(true,..)). > > - Can you use Supplier instead of creating a new RunnableCode type? Same in GetInstanceTest.java. > > - If matchExc always calls checkException, why not use a single method? Same in GetInstanceTest.java. > > - SUCESS is not final, you shouldn't use ALL CAPITAL letters for it. Same in GetInstanceTest.java. > > SerializedSeedTest.java: > > - The SHA1PRNG bug is fixed and has its own regression test. You can remove related codes here. > > Thanks > Max > >> On May 17, 2016, at 4:13 PM, Sibabrata Sahoo wrote: >> >> Hi Max, >> >> Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.03/ >> I misinterpreted your previous comment that the following change is only applicable to getInstanceTest.java and not applicable to ApiTest.java. >> >> The change includes, >> - ApiTest.java moved to " java/security/SecureRandom ". >> - Removed reference to MoreDrbgParameters from ApiTest.java >> >> Thanks, >> Siba > From xuelei.fan at oracle.com Thu May 19 12:42:27 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 May 2016 20:42:27 +0800 Subject: Code Review Request JDK-8148516: Improve the default strength of EC in JDK Message-ID: <4cf7d3ab-7ada-a183-42d6-860db4ed13ed@oracle.com> Hi, Please review this enhancement. The feature complete date is coming up next week. I appreciate very much if I can get your feedback before next Monday: http://cr.openjdk.java.net/~xuelei/8148516/webrev.00/ In this update, EC keys less than 224 bits are disabled and EC curves weaker than 256 bits are removed from the default enabled list in JDK. Plan backport the update to JDK 8u/7u/6u, too. Thanks, Xuelei Updates: ======= 1. Restrict EC keys less than 224 bits in certification path processing and SSL/TLS/DTLS connections. In this update, we are proposing to restrict the use of EC keys less than 224 bits in length. This restriction is applied via the Java Security properties, "jdk.certpath.disabledAlgorithms" and "jdk.tls.disabledAlgorithms". This will impact providers that adhere to the Security Properties, for example, the Sun provider and the SunJSSE provider. With this key size restriction, those who use X.509 certificates based on EC keys less than 224 bits will encounter compatibility issues with certification path building and validation. This key size restriction also impacts JDK components that validate X.509 certificates, for example signed JAR verification, LDAP over SSL/TLS connections, HTTPS connections, etc. In order to avoid the compatibility issue, users who use X.509 certificates with EC keys less than 224 bits are recommended to renew their certificates with stronger keys. As a workaround, at their own risk, users can adjust the key size restriction Security Properties ("jdk.certpath.disabledAlgorithms", and "jdk.tls.disabledAlgorithms" if using SSL/TLS/DTLS connections) to permit smaller key sizes. 2. Remove curves weaker than 256 bits from the default enabled list in JDK. In the SSL/TLS/DTLS implementation in JDK, potentially weak curves would be removed from the enabled curves list. The new default enabled curves include, in preference order: // recommended secp256r1 (23) secp384r1 (24) secp521r1 (25) // NIST curves sect283k1 (9) sect283r1 (10) sect409k1 (11) sect409r1 (12) sect571k1 (13) sect571r1 (14) // Non-FIPS curves secp256k1 (22) 3. Add a new System Property to customize the enabled curves. The compatibility impact should be limited. However, if applications want to use curves other than the default ones, or want to use different preference, a new System Property, "jdk.tls.namedGroups" is defined to make the customization. The value of the System Property defines a list of enabled named curves in preference order, separated with comma. For example: jdk.tls.namedGroups="secp521r1, secp256r1, secp384r1" If the System Property is not defined or the value is empty, the default curves and preferences (see #2) will be used in JDK. Note: the default enabled curves (#2) and customized curves (#3) cannot be used to re-activate the disabled EC keys defined by the Java Security Properties(#1). From amanda.jiang at oracle.com Thu May 19 18:34:38 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 19 May 2016 11:34:38 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms Message-ID: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> Hi All, Please help to review tests for JEP287: SHA-3 Hash Alogrithms. BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 Thanks, Amanda From artem.smotrakov at oracle.com Thu May 19 21:29:43 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 19 May 2016 14:29:43 -0700 Subject: [9] RFR: 8157344: Multiple test timeouts after push for JDK-8141039 Message-ID: <573E3047.406@oracle.com> Hello, Please review this patch for SecureRandom tests which may fail with timeout because SeedGenerator. generateSeed() may block on /dev/random. The tests now use /dev/urandom instead. They also run in othervm mode since "java.security.egd" system property seems to be read once while initialization of security providers, see sun/security/provider/SunEntries.java for details. I was not able to reproduce sun/security/provider/SecureRandom/StrongSecureRandom.java failure. This test sets "securerandom.source" to "/dev/urandom", but "java.security.egd" system property may override it (see comments in java.security file). I just updated the test to reset "java.security.egd" system property. The patch also fixes https://bugs.openjdk.java.net/browse/JDK-8156606 Most of other SecureRandom tests modify security properties (for example "securerandom.drbg.config"), and then restore them. It seems to be fine if some properties can be updated at runtime. But it still may affect other tests which run in the same JVM if the original value was not restored properly. For example, see java/security/SecureRandom/GetInstanceTest.java: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f0c1d4d90df6/test/java/security/SecureRandom/GetInstanceTest.java#l80 ... Security.setProperty(STRONG_ALG_SEC_PROP, "DRBG:SUN"); sr = matchExc(() -> SecureRandom.getInstanceStrong(), PASS, NoSuchAlgorithmException.class, "PASS - Undefined security Property " + "'securerandom.strongAlgorithms'"); checkAttributes(sr, "DRBG"); Security.setProperty(STRONG_ALG_SEC_PROP, origDRBGConfig); ... It doesn't use try-finally block to restore the security property. So the risk that it may affect other tests is higher. It may be better to run all tests which modify system/security properties to run in othervm mode to avoid potential issues. Although it would slow down test execution. Bugs: https://bugs.openjdk.java.net/browse/JDK-8157344 https://bugs.openjdk.java.net/browse/JDK-8156606 Webrev: http://cr.openjdk.java.net/~asmotrak/8157344/webrev.00/ Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu May 19 21:49:55 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 May 2016 14:49:55 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> Message-ID: <573E3503.9010006@oracle.com> Hi Amanda, Tests look fine. Thanks for covering all these test vectors. One thing that I am not sure is the usage of @library, see below. Is this really used? I see the same in in both tests (.java) file. 21 * @library /sun/security/pkcs11 Thanks, Valerie On 5/19/2016 11:34 AM, Amanda Jiang wrote: > Hi All, > > Please help to review tests for JEP287: SHA-3 Hash Alogrithms. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 > Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ > Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 > > Thanks, > Amanda From rajan.halade at oracle.com Thu May 19 22:18:33 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 19 May 2016 15:18:33 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> Message-ID: <573E3BB9.5030307@oracle.com> Hi Amanda, I have following comments: - UnsupportedProvider.java line 55: this assumes that it is okay to have NoSuchAlgorithmException for all providers. - Update MessageDigest tests to use RandomFactory from http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f8a3c1510f95/test/lib/testlibrary/jdk/testlibrary. It logs seed information which will be helpful to reproduce failure. - Also, MessageDigest tests have no provider checks. Rest of tests look fine to me. Note, I am not a official reviewer so please wait for official reviewer to integrate changes. Thanks, Rajan On 5/19/16 11:34 AM, Amanda Jiang wrote: > Hi All, > > Please help to review tests for JEP287: SHA-3 Hash Alogrithms. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 > Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ > Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 > > Thanks, > Amanda From valerie.peng at oracle.com Thu May 19 22:21:10 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 May 2016 15:21:10 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <573E3503.9010006@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> <573E3503.9010006@oracle.com> Message-ID: <573E3C56.6040403@oracle.com> Hmm, please ignore this. The comment is for another review... Valerie On 5/19/2016 2:49 PM, Valerie Peng wrote: > Hi Amanda, > > Tests look fine. Thanks for covering all these test vectors. > One thing that I am not sure is the usage of @library, see below. Is > this really used? I see the same in in both tests (.java) file. > > 21 * @library /sun/security/pkcs11 > > > Thanks, > Valerie > > On 5/19/2016 11:34 AM, Amanda Jiang wrote: >> Hi All, >> >> Please help to review tests for JEP287: SHA-3 Hash Alogrithms. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 >> Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ >> Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 >> >> Thanks, >> Amanda From valerie.peng at oracle.com Thu May 19 22:31:09 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 May 2016 15:31:09 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <573E3BB9.5030307@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> <573E3BB9.5030307@oracle.com> Message-ID: <573E3EAD.30206@oracle.com> True, I think the UnsupportedProvider.java should assume SUN provider to support SHA-3 and not allow NSAE. OracleUcrypto provider only supports SHA-3 on Solaris 12 or later, so what you have is fine. As for other tests, as long as SHA-3 algos are covered, it's up to you to make the enhancements that Rajan suggested. Thanks, Valerie On 5/19/2016 3:18 PM, Rajan Halade wrote: > Hi Amanda, > > I have following comments: > - UnsupportedProvider.java line 55: this assumes that it is okay to > have NoSuchAlgorithmException for all providers. > - Update MessageDigest tests to use RandomFactory from > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f8a3c1510f95/test/lib/testlibrary/jdk/testlibrary. > It logs seed information which will be helpful to reproduce failure. > - Also, MessageDigest tests have no provider checks. > > Rest of tests look fine to me. Note, I am not a official reviewer so > please wait for official reviewer to integrate changes. > > Thanks, > Rajan > > On 5/19/16 11:34 AM, Amanda Jiang wrote: >> Hi All, >> >> Please help to review tests for JEP287: SHA-3 Hash Alogrithms. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 >> Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ >> Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 >> >> Thanks, >> Amanda > From artem.smotrakov at oracle.com Fri May 20 01:49:37 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 19 May 2016 18:49:37 -0700 Subject: [9] RFR: 8129389: javax/net/ssl/DTLS tests fail intermittently In-Reply-To: <573D32EE.3050504@oracle.com> References: <573D32EE.3050504@oracle.com> Message-ID: <573E6D31.4040707@oracle.com> I added more output for debugging intermittent failures in https://bugs.openjdk.java.net/browse/JDK-8132320 I also updated produceHandshakePackets() to handle NEED_UNWRAP_AGAIN. http://cr.openjdk.java.net/~asmotrak/8129389/webrev.01/ Artem On 05/18/2016 08:28 PM, Artem Smotrakov wrote: > Hello, > > Please review the following patch for DTLS tests. > > A couple of DTLS tests which are based on DTLSOverDatagram.java fail > intermittently. I was not able to reproduce these failures. I am > proposing to update the tests to print more information to logs, so > that more information will be available if they fail next time. > > I also noticed that the tests doesn't check for FINISHED handshake > status which can be returned by wrap/unwrap methods. This status > should indicate that handshake finished. > > Changes: > - enabled debug output by setting "javax.net.debug" system property to > "ssl" > - added more logging to handshaking code > - updated handshaking code to check for FINISHED status > - added more checks to handshaking code > - added try-with-resources blocks for sockets and file input streams > - removed suppressed exceptions to make logs clearer > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129389 > Webrev: http://cr.openjdk.java.net/~asmotrak/8129389/webrev.00/ > > Artem From xuelei.fan at oracle.com Fri May 20 09:00:22 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 20 May 2016 17:00:22 +0800 Subject: [9] RFR: 8129389: javax/net/ssl/DTLS tests fail intermittently In-Reply-To: <573E6D31.4040707@oracle.com> References: <573D32EE.3050504@oracle.com> <573E6D31.4040707@oracle.com> Message-ID: <81ebdbda-ce15-c42a-23ee-c4132440bf87@oracle.com> Looks fine to me. Thanks, Xuelei On 5/20/2016 9:49 AM, Artem Smotrakov wrote: > I added more output for debugging intermittent failures in > https://bugs.openjdk.java.net/browse/JDK-8132320 > > I also updated produceHandshakePackets() to handle NEED_UNWRAP_AGAIN. > > http://cr.openjdk.java.net/~asmotrak/8129389/webrev.01/ > > Artem > > On 05/18/2016 08:28 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review the following patch for DTLS tests. >> >> A couple of DTLS tests which are based on DTLSOverDatagram.java fail >> intermittently. I was not able to reproduce these failures. I am >> proposing to update the tests to print more information to logs, so >> that more information will be available if they fail next time. >> >> I also noticed that the tests doesn't check for FINISHED handshake >> status which can be returned by wrap/unwrap methods. This status >> should indicate that handshake finished. >> >> Changes: >> - enabled debug output by setting "javax.net.debug" system property to >> "ssl" >> - added more logging to handshaking code >> - updated handshaking code to check for FINISHED status >> - added more checks to handshaking code >> - added try-with-resources blocks for sockets and file input streams >> - removed suppressed exceptions to make logs clearer >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129389 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8129389/webrev.00/ >> >> Artem > From sibabrata.sahoo at oracle.com Fri May 20 09:35:43 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 20 May 2016 02:35:43 -0700 (PDT) Subject: [9] RFR: 8157417: Some of SecureRandom test might get timed out in linux. Message-ID: <4c81fc52-b19b-4e58-b587-7264b03247f6@default> Hi, Please review the following fix for SecureRandom test which might cause timeout in Linux. webrev: http://cr.openjdk.java.net/~ssahoo/8157417/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8157417 The change includes: - Added "-Djava.security.egd=file:/dev/urandom" without which the test might timeout in Linux. The change included in "MultiThreadTest.java" and "SerializedSeedTest.java". - Added finally inside "GetInstanceTest.java" to preserve the original security property correctly in case of rare failure. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Fri May 20 10:11:53 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 20 May 2016 03:11:53 -0700 (PDT) Subject: [9] RFR: 8157417: Some of SecureRandom test might get timed out in linux. In-Reply-To: <4c81fc52-b19b-4e58-b587-7264b03247f6@default> References: <4c81fc52-b19b-4e58-b587-7264b03247f6@default> Message-ID: <3bd55b52-efa6-44d1-b21c-055bb5d8a8ee@default> I missed to include one more test. Here is the updated one: http://cr.openjdk.java.net/~ssahoo/8157417/webrev.01/ sun/security/provider/SeedGenerator/SeedGeneratorChoice.java might also fail in Linux without the fix provided. Thanks, Siba From: Sibabrata Sahoo Sent: Friday, May 20, 2016 3:06 PM To: Weijun Wang; security-dev at openjdk.java.net Subject: [9] RFR: 8157417: Some of SecureRandom test might get timed out in linux. Hi, Please review the following fix for SecureRandom test which might cause timeout in Linux. webrev: http://cr.openjdk.java.net/~ssahoo/8157417/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8157417 The change includes: - Added "-Djava.security.egd=file:/dev/urandom" without which the test might timeout in Linux. The change included in "MultiThreadTest.java" and "SerializedSeedTest.java". - Added finally inside "GetInstanceTest.java" to preserve the original security property correctly in case of rare failure. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri May 20 12:52:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 May 2016 20:52:09 +0800 Subject: [9] RFR: 8157417: Some of SecureRandom test might get timed out in linux. In-Reply-To: <3bd55b52-efa6-44d1-b21c-055bb5d8a8ee@default> References: <4c81fc52-b19b-4e58-b587-7264b03247f6@default> <3bd55b52-efa6-44d1-b21c-055bb5d8a8ee@default> Message-ID: <46888E9E-0B56-40C6-A39D-D394A18BCFD7@oracle.com> Change looks fine. Thanks Max > On May 20, 2016, at 6:11 PM, Sibabrata Sahoo wrote: > > I missed to include one more test. > Here is the updated one: http://cr.openjdk.java.net/~ssahoo/8157417/webrev.01/ > > sun/security/provider/SeedGenerator/SeedGeneratorChoice.java might also fail in Linux without the fix provided. > > Thanks, > Siba > > From: Sibabrata Sahoo > Sent: Friday, May 20, 2016 3:06 PM > To: Weijun Wang; security-dev at openjdk.java.net > Subject: [9] RFR: 8157417: Some of SecureRandom test might get timed out in linux. > > Hi, > > Please review the following fix for SecureRandom test which might cause timeout in Linux. > > webrev: http://cr.openjdk.java.net/~ssahoo/8157417/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8157417 > > The change includes: > - Added ?-Djava.security.egd=file:/dev/urandom? without which the test might timeout in Linux. The change included in ?MultiThreadTest.java? and ?SerializedSeedTest.java?. > - Added finally inside ?GetInstanceTest.java? to preserve the original security property correctly in case of rare failure. > > Thanks, > Siba From svetlana.nikandrova at oracle.com Fri May 20 14:13:18 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 20 May 2016 17:13:18 +0300 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda Message-ID: <573F1B7E.1090103@oracle.com> 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 one affected. http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ Thank you, Svetlana -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Fri May 20 14:24:29 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 20 May 2016 07:24:29 -0700 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: <573F1B7E.1090103@oracle.com> References: <573F1B7E.1090103@oracle.com> Message-ID: <573F1E1D.4060600@oracle.com> 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 one affected. > > http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ > > > Thank you, > Svetlana Your changes look fine.. Tony From svetlana.nikandrova at oracle.com Fri May 20 15:42:17 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 20 May 2016 18:42:17 +0300 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: <573F1E1D.4060600@oracle.com> References: <573F1B7E.1090103@oracle.com> <573F1E1D.4060600@oracle.com> Message-ID: <573F3059.7030807@oracle.com> 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 characters) lines. Also >> examined other classes in**the java.security package, but seems like >> Provider.java is the only one affected. >> >> http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ >> >> >> Thank you, >> Svetlana > > > Your changes look fine.. > > Tony > From rajan.halade at oracle.com Fri May 20 22:22:00 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 20 May 2016 15:22:00 -0700 Subject: RFR: 9: 8157469: DefaultProviderList.java fails with no provider class apple.security.AppleProvider found Message-ID: <573F8E08.6040106@oracle.com> Please review following fix. AppleProvider is in java.base module so will not be loaded by ServiceLoader. 8157489 is filed to fix java.base/macosx/classes/module-info.java.extra. Bug: https://bugs.openjdk.java.net/browse/JDK-8157469 Webrev: http://cr.openjdk.java.net/~rhalade/8157469/webrev.00/ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri May 20 22:30:44 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 20 May 2016 15:30:44 -0700 Subject: RFR: 9: 8157469: DefaultProviderList.java fails with no provider class apple.security.AppleProvider found In-Reply-To: <573F8E08.6040106@oracle.com> References: <573F8E08.6040106@oracle.com> Message-ID: <573F9014.5090603@oracle.com> Changes look fine. Thanks, Valerie On 5/20/2016 3:22 PM, Rajan Halade wrote: > Please review following fix. > > AppleProvider is in java.base module so will not be loaded by > ServiceLoader. 8157489 is filed to fix > java.base/macosx/classes/module-info.java.extra. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157469 > Webrev: http://cr.openjdk.java.net/~rhalade/8157469/webrev.00/ > > Thanks, > Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat May 21 05:11:07 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 21 May 2016 13:11:07 +0800 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: <573F3059.7030807@oracle.com> References: <573F1B7E.1090103@oracle.com> <573F1E1D.4060600@oracle.com> <573F3059.7030807@oracle.com> Message-ID: <0BC3E4FA-3CED-4877-8848-93340A57A14D@oracle.com> I am not sure if it's good to break inside a type name. I grep through JDK and seems nowhere else is doing it. --Max > On May 20, 2016, at 11:42 PM, Svetlana 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 characters) lines. Also >>> examined other classes in**the java.security package, but seems like >>> Provider.java is the only one affected. >>> >>> http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ >>> >>> >>> Thank you, >>> Svetlana >> >> >> Your changes look fine.. >> >> Tony >> > From anthony.scarpino at oracle.com Sat May 21 06:11:01 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 20 May 2016 23:11:01 -0700 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: <0BC3E4FA-3CED-4877-8848-93340A57A14D@oracle.com> References: <573F1B7E.1090103@oracle.com> <573F1E1D.4060600@oracle.com> <573F3059.7030807@oracle.com> <0BC3E4FA-3CED-4877-8848-93340A57A14D@oracle.com> Message-ID: <573FFBF5.4090304@oracle.com> If breaks were not allowed, I would hope the compiler and/or tests would have failed. Tony On 05/20/2016 10:11 PM, Wang Weijun wrote: > I am not sure if it's good to break inside a type name. I grep through JDK and seems nowhere else is doing it. > > --Max > >> On May 20, 2016, at 11:42 PM, Svetlana 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 characters) lines. Also >>>> examined other classes in**the java.security package, but seems like >>>> Provider.java is the only one affected. >>>> >>>> http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ >>>> >>>> >>>> Thank you, >>>> Svetlana >>> >>> >>> Your changes look fine.. >>> >>> Tony >>> >> > From weijun.wang at oracle.com Sat May 21 09:01:18 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 21 May 2016 17:01:18 +0800 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: <573FFBF5.4090304@oracle.com> References: <573F1B7E.1090103@oracle.com> <573F1E1D.4060600@oracle.com> <573F3059.7030807@oracle.com> <0BC3E4FA-3CED-4877-8848-93340A57A14D@oracle.com> <573FFBF5.4090304@oracle.com> Message-ID: <7C33B7CD-3240-4064-84B2-F893C1938963@oracle.com> I meant coding style. --Max > On May 21, 2016, at 2:11 PM, Anthony Scarpino wrote: > > If breaks were not allowed, I would hope the compiler and/or tests would have failed. > > Tony > > On 05/20/2016 10:11 PM, Wang Weijun wrote: >> I am not sure if it's good to break inside a type name. I grep through JDK and seems nowhere else is doing it. >> >> --Max >> >>> On May 20, 2016, at 11:42 PM, Svetlana 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 characters) lines. Also >>>>> examined other classes in**the java.security package, but seems like >>>>> Provider.java is the only one affected. >>>>> >>>>> http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ >>>>> >>>>> >>>>> Thank you, >>>>> Svetlana >>>> >>>> >>>> Your changes look fine.. >>>> >>>> Tony >>>> >>> >> > From mstjohns at comcast.net Sun May 22 14:29:50 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Sun, 22 May 2016 10:29:50 -0400 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: <7C33B7CD-3240-4064-84B2-F893C1938963@oracle.com> References: <573F1B7E.1090103@oracle.com> <573F1E1D.4060600@oracle.com> <573F3059.7030807@oracle.com> <0BC3E4FA-3CED-4877-8848-93340A57A14D@oracle.com> <573FFBF5.4090304@oracle.com> <7C33B7CD-3240-4064-84B2-F893C1938963@oracle.com> Message-ID: On 5/21/2016 5:01 AM, Wang Weijun wrote: > I meant coding style. > > --Max I agree with Max. I'd rather have too long lines than break in the middle of an arg definition. In the current case, for all except the first line - replaceAll, break before "BiFunction" or "Function". For the replaceAll definition, if the coding style permits it, break after the "(" and before "BiFunction" and then place the closing ") {" on its own line. Otherwise leave it alone. Hmm... have the coding style guidelines been revised for lambda's? Later, Mike > >> On May 21, 2016, at 2:11 PM, Anthony Scarpino wrote: >> >> If breaks were not allowed, I would hope the compiler and/or tests would have failed. >> >> Tony >> >> On 05/20/2016 10:11 PM, Wang Weijun wrote: >>> I am not sure if it's good to break inside a type name. I grep through JDK and seems nowhere else is doing it. >>> >>> --Max >>> >>>> On May 20, 2016, at 11:42 PM, Svetlana 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 characters) lines. Also >>>>>> examined other classes in**the java.security package, but seems like >>>>>> Provider.java is the only one affected. >>>>>> >>>>>> http://cr.openjdk.java.net/~snikandrova/8155575/webrev.00/ >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Svetlana >>>>> >>>>> Your changes look fine.. >>>>> >>>>> Tony >>>>> From weijun.wang at oracle.com Sun May 22 23:11:07 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 May 2016 07:11:07 +0800 Subject: [9] RFR: 8155575: Provider.java contains very long lines because of lambda In-Reply-To: References: <573F1B7E.1090103@oracle.com> <573F1E1D.4060600@oracle.com> <573F3059.7030807@oracle.com> <0BC3E4FA-3CED-4877-8848-93340A57A14D@oracle.com> <573FFBF5.4090304@oracle.com> <7C33B7CD-3240-4064-84B2-F893C1938963@oracle.com> Message-ID: > On May 22, 2016, at 10:29 PM, Michael StJohns wrote: > > Hmm... have the coding style guidelines been revised for lambda's? http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html --Max From weijun.wang at oracle.com Mon May 23 01:12:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 May 2016 09:12:28 +0800 Subject: RFR 8157526: 3KeyTDEA word left in DRBG after JDK-8156213 Message-ID: <839FF5A4-5D28-4EA3-9B7A-712BD4E8F7A6@oracle.com> Hi All The removal of 3KeyTDEA in JDK-8156213 is not clean. This bug removes the "(112 bits for CTR_DRBG with 3KeyTDEA)" words in class spec of DrbgParameters.java. No webrev, just the patch below. Please review. diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java --- a/src/java.base/share/classes/java/security/DrbgParameters.java +++ b/src/java.base/share/classes/java/security/DrbgParameters.java @@ -216,10 +216,9 @@ *

* If a DRBG is not instantiated with a {@link DrbgParameters.Instantiation} * object explicitly, this implementation instantiates it with a default - * requested strength of 128 bits (112 bits for CTR_DRBG with 3KeyTDEA), - * no prediction resistance request, and no personalization string. - * These default instantiation parameters can also be customized with - * the {@code securerandom.drbg.config} security property. + * requested strength of 128 bits, no prediction resistance request, and + * no personalization string. These default instantiation parameters can also + * be customized with the {@code securerandom.drbg.config} security property. *

* This implementation reads fresh entropy from the system default entropy * source determined by the security property {@code securerandom.source}. Thanks Max p.s. Although this changes the spec part, it's a bug fix, and therefore no CCC. From xuelei.fan at oracle.com Mon May 23 01:29:12 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 23 May 2016 09:29:12 +0800 Subject: RFR 8157526: 3KeyTDEA word left in DRBG after JDK-8156213 In-Reply-To: <839FF5A4-5D28-4EA3-9B7A-712BD4E8F7A6@oracle.com> References: <839FF5A4-5D28-4EA3-9B7A-712BD4E8F7A6@oracle.com> Message-ID: <6f005f84-f96c-443e-6c8c-af1b5a1544d0@oracle.com> Looks fine to me. Xuelei On 5/23/2016 9:12 AM, Wang Weijun wrote: > Hi All > > The removal of 3KeyTDEA in JDK-8156213 is not clean. This bug removes the "(112 bits for CTR_DRBG with 3KeyTDEA)" words in class spec of DrbgParameters.java. > > No webrev, just the patch below. Please review. > > diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java > --- a/src/java.base/share/classes/java/security/DrbgParameters.java > +++ b/src/java.base/share/classes/java/security/DrbgParameters.java > @@ -216,10 +216,9 @@ > *

> * If a DRBG is not instantiated with a {@link DrbgParameters.Instantiation} > * object explicitly, this implementation instantiates it with a default > - * requested strength of 128 bits (112 bits for CTR_DRBG with 3KeyTDEA), > - * no prediction resistance request, and no personalization string. > - * These default instantiation parameters can also be customized with > - * the {@code securerandom.drbg.config} security property. > + * requested strength of 128 bits, no prediction resistance request, and > + * no personalization string. These default instantiation parameters can also > + * be customized with the {@code securerandom.drbg.config} security property. > *

> * This implementation reads fresh entropy from the system default entropy > * source determined by the security property {@code securerandom.source}. > > Thanks > Max > > p.s. Although this changes the spec part, it's a bug fix, and therefore no CCC. > From xuelei.fan at oracle.com Mon May 23 03:36:51 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 23 May 2016 11:36:51 +0800 Subject: Code Review Request JDK-8046294 Generate the 4-byte timestamp randomly Message-ID: <0e8f3248-32a9-fb1c-4700-c1129423b435@oracle.com> Hi, Please review the update of SunJSSE provider in JDK 9: http://cr.openjdk.java.net/~xuelei/8046294/webrev/ In TLS 1.2 and previous protocols, the client and server random value are defined as: struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; NIST SP 800-52 is suggesting to replace gmt_unix_time with random values. In TLS 1.3, the value will be updated to: struct { opaque random_bytes[32]; } Random; The 4-byte timestamp will not be used any more. Per the NIST recommendation, this update will replace timestamp with random values. Considering the coming update of TLS 1.3, the compatibility impact should be minimal. Thanks, Xuelei From weijun.wang at oracle.com Mon May 23 06:11:25 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 May 2016 14:11:25 +0800 Subject: RFR 8157544: Typo in CtrDrbg::toString Message-ID: Once upon a time securerandom.drbg.config looks like "Hash_DRBG/SHA-256" and it was changed to "Hash_DRBG,SHA-256" because "Hash_DRBG/SHA-512/224" is ambiguous. DRBG::toString follows this style, but I forgot to update one case. Now, it is fixed. @Override public String toString() { - return super.toString() + "/" + return super.toString() + "," + (usedf ? "use_df" : "no_df"); } No webrev, just the patch above. Please take a review. Thanks Max From weijun.wang at oracle.com Mon May 23 06:26:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 May 2016 14:26:48 +0800 Subject: Code Review Request JDK-8046294 Generate the 4-byte timestamp randomly In-Reply-To: <0e8f3248-32a9-fb1c-4700-c1129423b435@oracle.com> References: <0e8f3248-32a9-fb1c-4700-c1129423b435@oracle.com> Message-ID: <417636F4-A5CA-4AE4-8ACA-34E30FD33F46@oracle.com> Code change looks good. Thanks Max > On May 23, 2016, at 11:36 AM, Xuelei Fan wrote: > > Hi, > > Please review the update of SunJSSE provider in JDK 9: > > http://cr.openjdk.java.net/~xuelei/8046294/webrev/ > > In TLS 1.2 and previous protocols, the client and server random value > are defined as: > > struct { > uint32 gmt_unix_time; > opaque random_bytes[28]; > } Random; > > NIST SP 800-52 is suggesting to replace gmt_unix_time with random > values. In TLS 1.3, the value will be updated to: > > struct { > opaque random_bytes[32]; > } Random; > > The 4-byte timestamp will not be used any more. > > Per the NIST recommendation, this update will replace timestamp with > random values. Considering the coming update of TLS 1.3, the > compatibility impact should be minimal. > > Thanks, > Xuelei From sha.jiang at oracle.com Mon May 23 06:43:41 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 23 May 2016 14:43:41 +0800 Subject: (9) RFR: JDK-8137255: sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts intermittently Message-ID: Hi, Please review the patch for sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts intermittently. TestDSAGenParameterSpec.java tests DSA parameter generation, so it's no need to generate keys. This patch also fixes https://bugs.openjdk.java.net/browse/JDK-8157333. After push for JDK-8072452, SUN provider has supported DSA size (3072, 256), so it's unnecessary to regard this size as an exception for the provider. And because generating parameters for this size may take much time, therefore run this case separately. Issues: https://bugs.openjdk.java.net/browse/JDK-8137255 https://bugs.openjdk.java.net/browse/JDK-8157333 Webrev: http://cr.openjdk.java.net/~jjiang/8137255/webrev.00 Best regards, John Jiang -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon May 23 08:53:19 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 23 May 2016 16:53:19 +0800 Subject: RFR 8157544: Typo in CtrDrbg::toString In-Reply-To: References: Message-ID: <803cba6e-fa04-5f5a-4219-2c16bf1cfa25@oracle.com> Looks fine to me. Xuelei On 5/23/2016 2:11 PM, Wang Weijun wrote: > Once upon a time securerandom.drbg.config looks like "Hash_DRBG/SHA-256" and it was changed to "Hash_DRBG,SHA-256" because "Hash_DRBG/SHA-512/224" is ambiguous. > > DRBG::toString follows this style, but I forgot to update one case. > > Now, it is fixed. > > @Override > public String toString() { > - return super.toString() + "/" > + return super.toString() + "," > + (usedf ? "use_df" : "no_df"); > } > > No webrev, just the patch above. Please take a review. > > Thanks > Max > From ivan.gerasimov at oracle.com Mon May 23 11:21:26 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 23 May 2016 14:21:26 +0300 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date In-Reply-To: <5735FB1D.9010201@oracle.com> References: <5733B640.40408@oracle.com> <71c0c6df-c230-4ac4-b7c0-98638ea63358.maildroid@localhost> <5734F6F9.1090501@oracle.com> <6f777865-d40c-5f76-fe95-65ee317a95b1@oracle.com> <5735FB1D.9010201@oracle.com> Message-ID: <72e5f352-a2bb-34b3-d77e-5e2b9bc63c3d@oracle.com> Thanks Anthony! On 13.05.2016 19:04, Anthony Scarpino wrote: > Hi Ivan, > > I added your comments.. I had thought usePattern() wouldn't reuse the > entry, but apparently the description is not the way I read it. > > You comments are incorporated into the webrev.01 that I posted previously > Looks good to me. Though, as I'm not a member of the security group, you may want to get a review from someone with that kind of power :) With kind regards, Ivan > thanks > > Tony > > > On 05/12/2016 04:13 PM, Ivan Gerasimov wrote: >> Hi Anthony! >> >> >> A few minor comments: >> >> *AlgorithmChecker.java* >> >> It would be more consistent to use {@code ...} tags in place of >> ... >> >> >> *DisabledAlgorithmConstraints.java* >> >> 275 Matcher dmatch = denyAfterPattern.matcher(entry); >> >> 296 } else if (dmatch.matches()) { >> >> >> It might be a bit more efficient to reuse already 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... >>> >>> On 05/11/2016 04:55 PM, ecki at zusammenkunft.net wrote: >>>> Hello, >>>> >>>> In AlgorithmChecker the Javadoc seems to not follow "@param name >>>> desc" format (in two places). Also it should most likely describe >>>> something like "time the signature claimed to be made to check time >>>> range limited ciphers after that date or similiar) >>>> >>>> * @param PKIXParameter timestamp (or null) >>> >>> Thanks for seeing that.. I updated them. >>> >>>> >>>> DisabledAlgorithmConstrained: The regular expression allows >>>> denyafter20160101 its clear, but \s+ might be clearer? Can optional >>>> iso Idate seperators, be added. "(\d {4})-?(\d {2})-?...." >>> >>> I think I prefer to require '-' as standard syntax and not use >>> YYYYMMDD. Sometimes YYYYMMDD not as clear to read as YYYY-MM-DD. I >>> would like to not have two valid formats. >>> >>>> >>>> The lowercase constraint classes are rather strange, but fits into >>>> existing code... >>>> >>>> I dont see in the patch how the date param is certified. Is this only >>>> the issued date as certified (by the weak) signature or does it look >>>> at timestamps (especially codesigning) too? >>> >>> The date is passed as part of PKIX, it's optional that PKIX can have a >>> date parameter set to specify a time date. >>> The date disallows a certificate with the disabled algorithm on that >>> date. It does not check validity of the certificate. This is meant >>> to shutoff the algorithm in certificate checking. There maybe a >>> exception to this to allowing codesigning certificates a bit longer, >>> but that hasn't been completely decided yet. >>> >>>> >>>> There are a few conditions which could be unit tested: >>>> >>>> RSA keySize <= 1024 & disablesAfter 20160101 SHA1 disabledAfter >>>> 20160102 // valid RSA disabledAfter 20160101 & disabledAfter 20160101 >>>> // not valid Etc >>> >>> Yes. There are a number of tests that are in the closed test repo >>> because they use certificates that are not for public use. >>> >>> thanks >>> >>> Tony >>> >>>> >>>> Gruss >>> > >>>> Bernd >>>> >>> >>> >> > > From ivan.gerasimov at oracle.com Mon May 23 11:41:29 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 23 May 2016 14:41:29 +0300 Subject: [jdk9] RFR: 8080273: JCA Signature provider service loading bottlenecks Message-ID: <7c02d7f6-6492-018f-d087-51dfc7fd6023@oracle.com> Hello! It has been observed that under some circumstances a scalability bottleneck may be observed, when accessing the internal BlindingParameters structure in the sun.security.rsa.RSACore class. It is proposed to slightly reorganize the code around, to reduce the possible contention. Would you please help review the proposal? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080273 WEBREV: http://cr.openjdk.java.net/~igerasim/8080273/00/webrev/ Three things are done here: 1) The instance of BlindingParameters is confined to the current thread, so no synchronization is necessary when creating the next BlindingRandomPair; 2) Extra instances of BlindingParameters, which are created due to concurency, aren't thrown away but reused; 3) Only perform { u = u.modPow(BIG_TWO, n); v = v.modPow(BIG_TWO, n); } when needed, thus save the last unused calculation. Comments, suggestions are very welcome! With kind regards, Ivan From jvanek at redhat.com Mon May 23 11:51:53 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 23 May 2016 13:51:53 +0200 Subject: Fwd: Re: RFE/RFC reproducible policies In-Reply-To: <2fff94c8-c2b0-067e-b19c-863ac20d63c0@redhat.com> References: <2fff94c8-c2b0-067e-b19c-863ac20d63c0@redhat.com> Message-ID: Hello security team! How do yo feel about lower suggested patch - reproducible policies? Thanx in advance, Bets regards from CZ J. -------- Forwarded Message -------- Subject: Re: RFE/RFC reproducible policies Date: Fri, 20 May 2016 11:04:25 +0200 From: Jiri Vanek To: Erik Joelsson , build-dev , Bradford Wetmore On 05/20/2016 10:12 AM, Erik Joelsson wrote: > (Adding Brad from the team owning these files) > > I think I understand the problem now. Each time we create the jars, they come out with binary > differences because there are different timestamps on the file inside them, while the files inside Exactly. > them are actually the same. Does the timestamp on the jar files matter or just the contents of the Timestamp of the file itself does not meter in this case. My idea was, that once the jars become artificially reproducible, they may keep the artificial timestamps too and so really relay only the changed policies inside whose will be keepers of the change. > jar files? I can't imagine jlink/jmod affecting the timestamps inside the jars, only the jars > themselves. You are of course right - jlink/jmod is not affecting timestamps inside, but is affecting only outside timestamp. I consider it as bad, as although the file is somehow generated, it should reflect the policies themselves. And so keep the timestamp. Anyway - I don't insists on this part. It just give me (a lot of) sense. > > Regarding GendataPolicyJars.gmk vs CreateSecurityJars.gmk, one is in JDK 8, the other in JDK 9. Aaargh. My apologize. I wonted to blame you that CreateSecurityJars is rotten dead code in Jdk9, but It was me, I copied CreateSecurityJars nex to GendataPolicyJars.gmk. And that CreateSecurityJars come from icedtea, but I forget. So.. Sorry! > > Regarding your proposed change, I think the security team needs to approve the approach before I > judge it from a build point of view. That would be really nice! Thank you very much! J. > > /Erik > > On 2016-05-20 09:25, Jiri Vanek wrote: >> Hello! >> >> Thank you for quick answer. >> >> However. .not exactly the one I hoped for:( >> >> Generally - IMHO the CreateSecurityJars.gmk is never used to generate policies, only the >> GendataPolicyJars.gmk is used for that. >> >> Thats why my unhappy patch is here. >> >> In one way or another - the GendataPolicyJars should be removed, or he lines regarding policies' >> jars from CreateSecurityJars should e removed (second is probably more correct way, If you light >> on green light to this patch, I will remove the lines from CreateSecurityJars and test) >> >> jmod? jlink? Crap :) The policies had remained simple jars, and are nothing but copied into image. >> I was looking to Images.gmk pretty much, and found quite a usages of JLINK_TOOL but found much >> less looking to it,, not its usages nor it documentation did not resolved how the jars get to the >> old good.../lib/security/ directory. It does not have much to do with modules.... >> >> And even if the jlink tool should be responsible for copying the jars (which is pretty obfuscated >> way) then perhaps it should keep time stamps? (just thought) >> >> >> I'm much much more troubled about way how the GendataPolicyJars and CreateSecurityJars are mixed up:( >> >> Again, thank you very much for looking into it! >> J. >> >> >> On 05/19/2016 07:07 PM, Erik Joelsson wrote: >>> Hello Jiri, >>> >>> If I understand the question correctly, you are wondering how the policy files from >>> CreateSecurityJars.gmk end up in the final image? This is done in two steps. First the new JDK 9 >>> tool jmod packages each module into a distribution format (typically java.base.jmod). Then the next >>> new tool jlink links all the jmods together to create an image. Somewhere inside those tools, I >>> assume timestamps are changing. >>> >>> /Erik >>> >>> On 2016-05-19 18:52, Jiri Vanek wrote: >>>> Hello again! >>>> >>>> webrev https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ >>>> >>>> Recent Feature Complete milestone have scared me, as I have long-time persisting issue when >>>> packaging openjdk (6..7...8 and 9) >>>> >>>> The policy jars, always from same source, never the same. As they are considered as configure >>>> files, the RPM update treat them alike. >>>> >>>> Not so do jdk build system, and every build have its "special" but still the same. .policies. >>>> >>>> This is fixed in my RPMS since [1] like [2] >>>> >>>> Well, not nice. I checked icedtea, and they since [3] already have this change [4] >>>> >>>> So I looked into JDK9 and.. it ahave teh change in CreateSecurityJars.gmk ! Not whole, but >>>> definitely not used. I really do not understand why. >>>> >>>> So there is patch for jdk9's - >>>> https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ which is making the >>>> policies truly static even with all this necessary stamping. >>>> >>>> However, I must apologise for missing part, which I had not found how to solve. >>>> Up to "make" (build) everything is ok. but "make images" corrupts the timestamps, I did not >>>> found, where the built files flow to images:(to stamp them again, and last time) >>>> >>>> Best regards from CZ >>>> J. >>>> >>>> >>>> [1] >>>> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?h=f21&id=ae70e5d64fbe2fb042c0cee088316b39ee8bf8c9 >>>> >>>> >>>> [2]http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/repackReproduciblePolycies >>>> >>>> [3] >>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/afd392dfaed5 >>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/edf1cacfe015 >>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/9b6cfe5f5078 >>>> >>>> [4] >>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/file/tip/make/CreateSecurityJars.gmk >>> >> > From bradford.wetmore at oracle.com Mon May 23 22:19:48 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 23 May 2016 15:19:48 -0700 Subject: RFR 8157544: Typo in CtrDrbg::toString In-Reply-To: <803cba6e-fa04-5f5a-4219-2c16bf1cfa25@oracle.com> References: <803cba6e-fa04-5f5a-4219-2c16bf1cfa25@oracle.com> Message-ID: <62f66bd1-8770-115f-3495-24dba76f868a@oracle.com> +1 Brad On 5/23/2016 1:53 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 5/23/2016 2:11 PM, Wang Weijun wrote: >> Once upon a time securerandom.drbg.config looks like "Hash_DRBG/SHA-256" and it was changed to "Hash_DRBG,SHA-256" because "Hash_DRBG/SHA-512/224" is ambiguous. >> >> DRBG::toString follows this style, but I forgot to update one case. >> >> Now, it is fixed. >> >> @Override >> public String toString() { >> - return super.toString() + "/" >> + return super.toString() + "," >> + (usedf ? "use_df" : "no_df"); >> } >> >> No webrev, just the patch above. Please take a review. >> >> Thanks >> Max >> > From bradford.wetmore at oracle.com Mon May 23 22:20:28 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 23 May 2016 15:20:28 -0700 Subject: RFR 8157526: 3KeyTDEA word left in DRBG after JDK-8156213 In-Reply-To: <6f005f84-f96c-443e-6c8c-af1b5a1544d0@oracle.com> References: <839FF5A4-5D28-4EA3-9B7A-712BD4E8F7A6@oracle.com> <6f005f84-f96c-443e-6c8c-af1b5a1544d0@oracle.com> Message-ID: <23b577cf-dcb6-b7ac-544c-5ecfef0c8e62@oracle.com> +1. Brad On 5/22/2016 6:29 PM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 5/23/2016 9:12 AM, Wang Weijun wrote: >> Hi All >> >> The removal of 3KeyTDEA in JDK-8156213 is not clean. This bug removes the "(112 bits for CTR_DRBG with 3KeyTDEA)" words in class spec of DrbgParameters.java. >> >> No webrev, just the patch below. Please review. >> >> diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java >> --- a/src/java.base/share/classes/java/security/DrbgParameters.java >> +++ b/src/java.base/share/classes/java/security/DrbgParameters.java >> @@ -216,10 +216,9 @@ >> *

>> * If a DRBG is not instantiated with a {@link DrbgParameters.Instantiation} >> * object explicitly, this implementation instantiates it with a default >> - * requested strength of 128 bits (112 bits for CTR_DRBG with 3KeyTDEA), >> - * no prediction resistance request, and no personalization string. >> - * These default instantiation parameters can also be customized with >> - * the {@code securerandom.drbg.config} security property. >> + * requested strength of 128 bits, no prediction resistance request, and >> + * no personalization string. These default instantiation parameters can also >> + * be customized with the {@code securerandom.drbg.config} security property. >> *

>> * This implementation reads fresh entropy from the system default entropy >> * source determined by the security property {@code securerandom.source}. >> >> Thanks >> Max >> >> p.s. Although this changes the spec part, it's a bug fix, and therefore no CCC. >> > From amanda.jiang at oracle.com Mon May 23 22:24:30 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 23 May 2016 15:24:30 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <573E3EAD.30206@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> <573E3BB9.5030307@oracle.com> <573E3EAD.30206@oracle.com> Message-ID: <6e1d1ff3-2533-bf83-f060-b56224a3bab0@oracle.com> Hi Valerie , Rajan, Thanks for reviewing the webrev. I have updaed UnsupportedProvider.java to check NSAE for SUN and OracleUcrypto providers. Other tests has been updated by Rajan's comments as well. Please check the latest webrev and let me know if there are any other problems. http://cr.openjdk.java.net/~amjiang/8156059/webrev.02/ Thanks, Amanda On 16/5/19 ??3:31, Valerie Peng wrote: > > True, I think the UnsupportedProvider.java should assume SUN provider > to support SHA-3 and not allow NSAE. > OracleUcrypto provider only supports SHA-3 on Solaris 12 or later, so > what you have is fine. > > As for other tests, as long as SHA-3 algos are covered, it's up to you > to make the enhancements that Rajan suggested. > Thanks, > Valerie > > On 5/19/2016 3:18 PM, Rajan Halade wrote: >> Hi Amanda, >> >> I have following comments: >> - UnsupportedProvider.java line 55: this assumes that it is okay to >> have NoSuchAlgorithmException for all providers. >> - Update MessageDigest tests to use RandomFactory from >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f8a3c1510f95/test/lib/testlibrary/jdk/testlibrary. >> It logs seed information which will be helpful to reproduce failure. >> - Also, MessageDigest tests have no provider checks. >> >> Rest of tests look fine to me. Note, I am not a official reviewer so >> please wait for official reviewer to integrate changes. >> >> Thanks, >> Rajan >> >> On 5/19/16 11:34 AM, Amanda Jiang wrote: >>> Hi All, >>> >>> Please help to review tests for JEP287: SHA-3 Hash Alogrithms. >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 >>> Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ >>> Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 >>> >>> Thanks, >>> Amanda >> From weijun.wang at oracle.com Mon May 23 22:39:38 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 May 2016 06:39:38 +0800 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> Message-ID: <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> Ping again. > ? 2016?5?19??16:21?Wang Weijun ??? > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ > > Now that DRBG does not save any internal state during serialization, all DRBG implementations (HashDrbg, HmacDrbg, CtrDrbg) still extends SecureRandomSpi and contain quite some @serial fields. If some of them is corrupted a deserialized DRBG may run expectedly, it also prevents class evolution. > > The fix is to make AbstractDrbg no more a SecureRandomSpi child so no more serializable. DRBG is still a SecureRandomSpi child and its only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is also made serializable. > > One new test is added. Since AbstractDrbg is no longer a SecureRandomSpi, its child class can no longer be registered in a SecureRandom provider, and the AbstractDrbgSpec.java test is removed. > > Thanks > Max > From valerie.peng at oracle.com Mon May 23 23:12:52 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 23 May 2016 16:12:52 -0700 Subject: (9) RFR: JDK-8137255: sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts intermittently In-Reply-To: References: Message-ID: <57438E74.9090909@oracle.com> Looks fine to me. Do you have approximate info on how long it took? I am curious as to how long it takes for the 3072 case. Thanks, Valerie On 5/22/2016 11:43 PM, John Jiang wrote: > > Hi, > Please review the patch for > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts > intermittently. > TestDSAGenParameterSpec.java tests DSA parameter generation, so it's > no need to generate keys. > > This patch also fixes https://bugs.openjdk.java.net/browse/JDK-8157333. > After push for JDK-8072452, SUN provider has supported DSA size (3072, > 256), so it's unnecessary to regard this size as an exception for the > provider. And because generating parameters for this size may take > much time, therefore run this case separately. > > Issues: > https://bugs.openjdk.java.net/browse/JDK-8137255 > https://bugs.openjdk.java.net/browse/JDK-8157333 > > Webrev: http://cr.openjdk.java.net/~jjiang/8137255/webrev.00 > > Best regards, > John Jiang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Tue May 24 02:26:28 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 24 May 2016 10:26:28 +0800 Subject: (9) RFR: JDK-8137255: sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts intermittently In-Reply-To: <57438E74.9090909@oracle.com> References: <57438E74.9090909@oracle.com> Message-ID: Hi, On 2016/5/24 7:12, Valerie Peng wrote: > Looks fine to me. Thanks! > Do you have approximate info on how long it took? I am curious as to > how long it takes for the 3072 case. I run this test 100 times in a loop, and got much different elapsed time for 3072 case: 2.316s ~ 160.616s. Best regards, John Jiang > Thanks, > Valerie > > On 5/22/2016 11:43 PM, John Jiang wrote: >> >> Hi, >> Please review the patch for >> sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts >> intermittently. >> TestDSAGenParameterSpec.java tests DSA parameter generation, so it's >> no need to generate keys. >> >> This patch also fixes https://bugs.openjdk.java.net/browse/JDK-8157333. >> After push for JDK-8072452, SUN provider has supported DSA size >> (3072, 256), so it's unnecessary to regard this size as an exception >> for the provider. And because generating parameters for this size may >> take much time, therefore run this case separately. >> >> Issues: >> https://bugs.openjdk.java.net/browse/JDK-8137255 >> https://bugs.openjdk.java.net/browse/JDK-8157333 >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8137255/webrev.00 >> >> Best regards, >> John Jiang >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed May 25 09:00:11 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 25 May 2016 17:00:11 +0800 Subject: Code Review Request JDK-8148516: Improve the default strength of EC in JDK In-Reply-To: <4cf7d3ab-7ada-a183-42d6-860db4ed13ed@oracle.com> References: <4cf7d3ab-7ada-a183-42d6-860db4ed13ed@oracle.com> Message-ID: <1d9d0c83-47b0-bbb4-b1d8-ca2a71e82988@oracle.com> Ping ... On 5/19/2016 8:42 PM, Xuelei Fan wrote: > Hi, > > Please review this enhancement. The feature complete date is coming up > next week. I appreciate very much if I can get your feedback before > next Monday: > > http://cr.openjdk.java.net/~xuelei/8148516/webrev.00/ > > In this update, EC keys less than 224 bits are disabled and EC curves > weaker than 256 bits are removed from the default enabled list in JDK. > Plan backport the update to JDK 8u/7u/6u, too. > > Thanks, > Xuelei > > Updates: > ======= > 1. Restrict EC keys less than 224 bits in certification path processing > and SSL/TLS/DTLS connections. > > In this update, we are proposing to restrict the use of EC keys less > than 224 bits in length. This restriction is applied via the Java > Security properties, "jdk.certpath.disabledAlgorithms" and > "jdk.tls.disabledAlgorithms". This will impact providers that adhere to > the Security Properties, for example, the Sun provider and the SunJSSE > provider. > > With this key size restriction, those who use X.509 certificates based > on EC keys less than 224 bits will encounter compatibility issues with > certification path building and validation. This key size restriction > also impacts JDK components that validate X.509 certificates, for > example signed JAR verification, LDAP over SSL/TLS connections, HTTPS > connections, etc. > > In order to avoid the compatibility issue, users who use X.509 > certificates with EC keys less than 224 bits are recommended to renew > their certificates with stronger keys. As a workaround, at their own > risk, users can adjust the key size restriction Security Properties > ("jdk.certpath.disabledAlgorithms", and "jdk.tls.disabledAlgorithms" if > using SSL/TLS/DTLS connections) to permit smaller key sizes. > > 2. Remove curves weaker than 256 bits from the default enabled list in JDK. > > In the SSL/TLS/DTLS implementation in JDK, potentially weak curves would > be removed from the enabled curves list. The new default enabled curves > include, in preference order: > // recommended > secp256r1 (23) > secp384r1 (24) > secp521r1 (25) > > // NIST curves > sect283k1 (9) > sect283r1 (10) > sect409k1 (11) > sect409r1 (12) > sect571k1 (13) > sect571r1 (14) > > // Non-FIPS curves > secp256k1 (22) > > 3. Add a new System Property to customize the enabled curves. > > The compatibility impact should be limited. However, if applications > want to use curves other than the default ones, or want to use different > preference, a new System Property, "jdk.tls.namedGroups" is defined to > make the customization. > > The value of the System Property defines a list of enabled named curves > in preference order, separated with comma. For example: > > jdk.tls.namedGroups="secp521r1, secp256r1, secp384r1" > > > If the System Property is not defined or the value is empty, the default > curves and preferences (see #2) will be used in JDK. > > Note: the default enabled curves (#2) and customized curves (#3) cannot > be used to re-activate the disabled EC keys defined by the Java Security > Properties(#1). > From rajan.halade at oracle.com Wed May 25 19:31:17 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 25 May 2016 12:31:17 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <6e1d1ff3-2533-bf83-f060-b56224a3bab0@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> <573E3BB9.5030307@oracle.com> <573E3EAD.30206@oracle.com> <6e1d1ff3-2533-bf83-f060-b56224a3bab0@oracle.com> Message-ID: <5745FD85.7070903@oracle.com> Hi Amanda, Thanks for the update. Few more comments after review: - TestSameLength.java: line 93-103, check here should use provider used with test instance of MessageDigest, call md.getProvider(). You will need to reorganize test code for this. Security.getProvider() returns provider installed with specified name. - It will be good if you have a function isSHA3Supported() to check SHA3 supported or not Same comments applies from other MessageDigest tests in your review. Thanks, Rajan On 5/23/16 3:24 PM, Amanda Jiang wrote: > Hi Valerie , Rajan, > > Thanks for reviewing the webrev. I have updaed > UnsupportedProvider.java to check NSAE for SUN and OracleUcrypto > providers. > > Other tests has been updated by Rajan's comments as well. > > Please check the latest webrev and let me know if there are any other > problems. > > http://cr.openjdk.java.net/~amjiang/8156059/webrev.02/ > > > Thanks, > Amanda > > > On 16/5/19 ??3:31, Valerie Peng wrote: >> >> True, I think the UnsupportedProvider.java should assume SUN provider >> to support SHA-3 and not allow NSAE. >> OracleUcrypto provider only supports SHA-3 on Solaris 12 or later, so >> what you have is fine. >> >> As for other tests, as long as SHA-3 algos are covered, it's up to >> you to make the enhancements that Rajan suggested. >> Thanks, >> Valerie >> >> On 5/19/2016 3:18 PM, Rajan Halade wrote: >>> Hi Amanda, >>> >>> I have following comments: >>> - UnsupportedProvider.java line 55: this assumes that it is okay to >>> have NoSuchAlgorithmException for all providers. >>> - Update MessageDigest tests to use RandomFactory from >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f8a3c1510f95/test/lib/testlibrary/jdk/testlibrary. >>> It logs seed information which will be helpful to reproduce failure. >>> - Also, MessageDigest tests have no provider checks. >>> >>> Rest of tests look fine to me. Note, I am not a official reviewer so >>> please wait for official reviewer to integrate changes. >>> >>> Thanks, >>> Rajan >>> >>> On 5/19/16 11:34 AM, Amanda Jiang wrote: >>>> Hi All, >>>> >>>> Please help to review tests for JEP287: SHA-3 Hash Alogrithms. >>>> >>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 >>>> Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ >>>> Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 >>>> >>>> Thanks, >>>> Amanda >>> > From jvanek at redhat.com Thu May 26 06:38:52 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 26 May 2016 08:38:52 +0200 Subject: Fwd: Re: RFE/RFC reproducible policies In-Reply-To: References: <2fff94c8-c2b0-067e-b19c-863ac20d63c0@redhat.com> Message-ID: <892cb5a6-19e1-9e31-c0af-2495e77dc702@redhat.com> Ping? J. On 05/23/2016 01:51 PM, Jiri Vanek wrote: > > Hello security team! > > How do yo feel about lower suggested patch - reproducible policies? > > Thanx in advance, > Bets regards from CZ > J. > > -------- Forwarded Message -------- > Subject: Re: RFE/RFC reproducible policies > Date: Fri, 20 May 2016 11:04:25 +0200 > From: Jiri Vanek > To: Erik Joelsson , build-dev , Bradford > Wetmore > > On 05/20/2016 10:12 AM, Erik Joelsson wrote: >> (Adding Brad from the team owning these files) >> >> I think I understand the problem now. Each time we create the jars, they come out with binary >> differences because there are different timestamps on the file inside them, while the files inside > > Exactly. > >> them are actually the same. Does the timestamp on the jar files matter or just the contents of the > > Timestamp of the file itself does not meter in this case. My idea was, that once the jars become > artificially reproducible, they may keep the artificial timestamps too and so really relay only the > changed policies inside whose will be keepers of the change. > >> jar files? I can't imagine jlink/jmod affecting the timestamps inside the jars, only the jars >> themselves. > > You are of course right - jlink/jmod is not affecting timestamps inside, but is affecting only > outside timestamp. I consider it as bad, as although the file is somehow generated, it should > reflect the policies themselves. And so keep the timestamp. > > Anyway - I don't insists on this part. It just give me (a lot of) sense. >> >> Regarding GendataPolicyJars.gmk vs CreateSecurityJars.gmk, one is in JDK 8, the other in JDK 9. > > Aaargh. My apologize. I wonted to blame you that CreateSecurityJars is rotten dead code in Jdk9, but > It was me, I copied CreateSecurityJars nex to GendataPolicyJars.gmk. And that CreateSecurityJars > come from icedtea, but I forget. So.. Sorry! >> >> Regarding your proposed change, I think the security team needs to approve the approach before I >> judge it from a build point of view. > > That would be really nice! Thank you very much! > > J. >> >> /Erik >> >> On 2016-05-20 09:25, Jiri Vanek wrote: >>> Hello! >>> >>> Thank you for quick answer. >>> >>> However. .not exactly the one I hoped for:( >>> >>> Generally - IMHO the CreateSecurityJars.gmk is never used to generate policies, only the >>> GendataPolicyJars.gmk is used for that. >>> >>> Thats why my unhappy patch is here. >>> >>> In one way or another - the GendataPolicyJars should be removed, or he lines regarding policies' >>> jars from CreateSecurityJars should e removed (second is probably more correct way, If you light >>> on green light to this patch, I will remove the lines from CreateSecurityJars and test) >>> >>> jmod? jlink? Crap :) The policies had remained simple jars, and are nothing but copied into image. >>> I was looking to Images.gmk pretty much, and found quite a usages of JLINK_TOOL but found much >>> less looking to it,, not its usages nor it documentation did not resolved how the jars get to the >>> old good.../lib/security/ directory. It does not have much to do with modules.... >>> >>> And even if the jlink tool should be responsible for copying the jars (which is pretty obfuscated >>> way) then perhaps it should keep time stamps? (just thought) >>> >>> >>> I'm much much more troubled about way how the GendataPolicyJars and CreateSecurityJars are mixed >>> up:( >>> >>> Again, thank you very much for looking into it! >>> J. >>> >>> >>> On 05/19/2016 07:07 PM, Erik Joelsson wrote: >>>> Hello Jiri, >>>> >>>> If I understand the question correctly, you are wondering how the policy files from >>>> CreateSecurityJars.gmk end up in the final image? This is done in two steps. First the new JDK 9 >>>> tool jmod packages each module into a distribution format (typically java.base.jmod). Then the next >>>> new tool jlink links all the jmods together to create an image. Somewhere inside those tools, I >>>> assume timestamps are changing. >>>> >>>> /Erik >>>> >>>> On 2016-05-19 18:52, Jiri Vanek wrote: >>>>> Hello again! >>>>> >>>>> webrev https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ >>>>> >>>>> Recent Feature Complete milestone have scared me, as I have long-time persisting issue when >>>>> packaging openjdk (6..7...8 and 9) >>>>> >>>>> The policy jars, always from same source, never the same. As they are considered as configure >>>>> files, the RPM update treat them alike. >>>>> >>>>> Not so do jdk build system, and every build have its "special" but still the same. .policies. >>>>> >>>>> This is fixed in my RPMS since [1] like [2] >>>>> >>>>> Well, not nice. I checked icedtea, and they since [3] already have this change [4] >>>>> >>>>> So I looked into JDK9 and.. it ahave teh change in CreateSecurityJars.gmk ! Not whole, but >>>>> definitely not used. I really do not understand why. >>>>> >>>>> So there is patch for jdk9's - >>>>> https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ which is making the >>>>> policies truly static even with all this necessary stamping. >>>>> >>>>> However, I must apologise for missing part, which I had not found how to solve. >>>>> Up to "make" (build) everything is ok. but "make images" corrupts the timestamps, I did not >>>>> found, where the built files flow to images:(to stamp them again, and last time) >>>>> >>>>> Best regards from CZ >>>>> J. >>>>> >>>>> >>>>> [1] >>>>> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?h=f21&id=ae70e5d64fbe2fb042c0cee088316b39ee8bf8c9 >>>>> >>>>> >>>>> >>>>> [2]http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/repackReproduciblePolycies >>>>> >>>>> [3] >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/afd392dfaed5 >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/edf1cacfe015 >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/9b6cfe5f5078 >>>>> >>>>> [4] >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/file/tip/make/CreateSecurityJars.gmk >>>> >>> >> > From sean.mullan at oracle.com Thu May 26 15:12:03 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 May 2016 11:12:03 -0400 Subject: RFR 8154005: Add algorithm constraint that specifies the restriction date In-Reply-To: <5733B640.40408@oracle.com> References: <5733B640.40408@oracle.com> Message-ID: <57471243.4020709@oracle.com> On 05/11/2016 06:46 PM, Anthony Scarpino wrote: > 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/ A few minor comments on the updated webrev: http://cr.openjdk.java.net/~ascarpino/8154005/webrev.01/ * AlgorithmChecker 186 * given {@code TrustAnchor} and {@code PKIXParameter}. s/{@code PKIXParameter}/{@code PKIXParameter} date/ * DisabledAlgorithmConstraints 393 * If the class constains multiple constraints, the next constraint s/constains/contains/ 446 * CertConstraintParameter. 449 * {@code next()} with the same {@code CertConstraintParameter} s/CertConstraintParameter/CertConstraintParameters/ 448 * If the check inside of {@code permit()} fails, it must call 463 * call {@code nextConstraint}'s {@code permit()} to check if the 465 * {@code permit()} is allowed, this method will exit this and any s/permit/permits/ 453 * @return 'true' if constraint is allowed, 'false' if disallowed. This should be an @throws. 460 * Recursively check the constraints is allowed. s/check the constraints is allowed/check if the constraints are allowed/ 472 * we are at the end of the constraint list, {@code nextConstraint} is s/list,/list or/ 543 private static class denyAfterConstraint extends Constraint { s/denyAfterConstraint/DenyAfterConstraint/ 607 throw new CertPathValidatorException( indented one space too far 619 * in UTC timezone, s/,/./ --Sean From ayaskant.swain at gmail.com Thu May 26 07:31:31 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Thu, 26 May 2016 13:01:31 +0530 Subject: Help Needed - Need source code bundle of jsse.jar library Message-ID: Hi All, I am in urgent need of the source code bundle of *jsse.jar* library to debug a javax.net.ssl.SSLHandshakeException error. Our java application is a webservice and deployed in Mule container. Our application in turn calls another external SOAP service over a https URL. So our application becomes a client in the SSL conversation. And I am seeing the below errors only when using *JDK_1.8.0_60* as the Java runtime for our application. I do not see this problem when i set JDK_1.7.0_71 as the running env for our application and everything works fine. ----------------------------------------------------- done seeding SecureRandom Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 *Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) * at sun.security.ssl.Handshaker.activate(Handshaker.java:503) ~[?:1.8.0_60] at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482) ~[?:1.8.0_60] at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351) ~[?:1.8.0_60] ----------------------------------------------------------- The Handshaker.class & SSLSocketImpl.class are inside jsse.jar file. The above error is being thrown from the "*activate(ProtocolVersion helloVersion)*" method of the Handshaker.class. I checked out this site - http://download.java.net/openjdk/jdk8/ to get the source bundle for jsse.jar & downloaded the "openjdk-8-src-b132-03_mar_2014.zip" file. But the steps given to build the openjdk is bit difficult to run and failing due to gcc compiler issues on my Mac OS laptop. So, can someone please provide me the jsse jar file source bundle (*.zip or *.jar) that will help in debugging the error . I am stuck at this error since last 4 days. Thanks Ayas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Thu May 26 22:37:56 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 26 May 2016 15:37:56 -0700 Subject: RFE/RFC reproducible policies In-Reply-To: <2fff94c8-c2b0-067e-b19c-863ac20d63c0@redhat.com> References: <573DF2C0.7070000@oracle.com> <573EC702.7050608@oracle.com> <2fff94c8-c2b0-067e-b19c-863ac20d63c0@redhat.com> Message-ID: Hi Jiri, This is open issue #2 from JEP-220 [1] that we still need to address for JDK 9, so your patch will likely be moot soon. It's possible that the jar will be going away. If you would like to watch the progress, please add yourself to: JDK-8061842: Package jurisdiction policy files as something other than JAR Thanks for the forward Erik, I'm not able to follow build-dev all that closely lately. Brad [1] http://openjdk.java.net/jeps/220 On 5/20/2016 2:04 AM, Jiri Vanek wrote: > On 05/20/2016 10:12 AM, Erik Joelsson wrote: >> (Adding Brad from the team owning these files) >> >> I think I understand the problem now. Each time we create the jars, >> they come out with binary >> differences because there are different timestamps on the file inside >> them, while the files inside > > Exactly. > >> them are actually the same. Does the timestamp on the jar files matter >> or just the contents of the > > Timestamp of the file itself does not meter in this case. My idea was, > that once the jars become artificially reproducible, they may keep the > artificial timestamps too and so really relay only the changed policies > inside whose will be keepers of the change. > >> jar files? I can't imagine jlink/jmod affecting the timestamps inside >> the jars, only the jars >> themselves. > > You are of course right - jlink/jmod is not affecting timestamps inside, > but is affecting only outside timestamp. I consider it as bad, as > although the file is somehow generated, it should reflect the policies > themselves. And so keep the timestamp. > > Anyway - I don't insists on this part. It just give me (a lot of) sense. >> >> Regarding GendataPolicyJars.gmk vs CreateSecurityJars.gmk, one is in >> JDK 8, the other in JDK 9. > > Aaargh. My apologize. I wonted to blame you that CreateSecurityJars is > rotten dead code in Jdk9, but It was me, I copied CreateSecurityJars > nex to GendataPolicyJars.gmk. And that CreateSecurityJars come from > icedtea, but I forget. So.. Sorry! >> >> Regarding your proposed change, I think the security team needs to >> approve the approach before I >> judge it from a build point of view. > > That would be really nice! Thank you very much! > > J. >> >> /Erik >> >> On 2016-05-20 09:25, Jiri Vanek wrote: >>> Hello! >>> >>> Thank you for quick answer. >>> >>> However. .not exactly the one I hoped for:( >>> >>> Generally - IMHO the CreateSecurityJars.gmk is never used to generate >>> policies, only the >>> GendataPolicyJars.gmk is used for that. >>> >>> Thats why my unhappy patch is here. >>> >>> In one way or another - the GendataPolicyJars should be removed, or >>> he lines regarding policies' >>> jars from CreateSecurityJars should e removed (second is probably >>> more correct way, If you light >>> on green light to this patch, I will remove the lines from >>> CreateSecurityJars and test) >>> >>> jmod? jlink? Crap :) The policies had remained simple jars, and are >>> nothing but copied into image. >>> I was looking to Images.gmk pretty much, and found quite a usages of >>> JLINK_TOOL but found much >>> less looking to it,, not its usages nor it documentation did not >>> resolved how the jars get to the >>> old good.../lib/security/ directory. It does not have much to do with >>> modules.... >>> >>> And even if the jlink tool should be responsible for copying the jars >>> (which is pretty obfuscated >>> way) then perhaps it should keep time stamps? (just thought) >>> >>> >>> I'm much much more troubled about way how the GendataPolicyJars and >>> CreateSecurityJars are mixed up:( >>> >>> Again, thank you very much for looking into it! >>> J. >>> >>> >>> On 05/19/2016 07:07 PM, Erik Joelsson wrote: >>>> Hello Jiri, >>>> >>>> If I understand the question correctly, you are wondering how the >>>> policy files from >>>> CreateSecurityJars.gmk end up in the final image? This is done in >>>> two steps. First the new JDK 9 >>>> tool jmod packages each module into a distribution format (typically >>>> java.base.jmod). Then the next >>>> new tool jlink links all the jmods together to create an image. >>>> Somewhere inside those tools, I >>>> assume timestamps are changing. >>>> >>>> /Erik >>>> >>>> On 2016-05-19 18:52, Jiri Vanek wrote: >>>>> Hello again! >>>>> >>>>> webrev >>>>> https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ >>>>> >>>>> >>>>> Recent Feature Complete milestone have scared me, as I have >>>>> long-time persisting issue when >>>>> packaging openjdk (6..7...8 and 9) >>>>> >>>>> The policy jars, always from same source, never the same. As they >>>>> are considered as configure >>>>> files, the RPM update treat them alike. >>>>> >>>>> Not so do jdk build system, and every build have its "special" but >>>>> still the same. .policies. >>>>> >>>>> This is fixed in my RPMS since [1] like [2] >>>>> >>>>> Well, not nice. I checked icedtea, and they since [3] already have >>>>> this change [4] >>>>> >>>>> So I looked into JDK9 and.. it ahave teh change in >>>>> CreateSecurityJars.gmk ! Not whole, but >>>>> definitely not used. I really do not understand why. >>>>> >>>>> So there is patch for jdk9's - >>>>> https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ >>>>> which is making the >>>>> policies truly static even with all this necessary stamping. >>>>> >>>>> However, I must apologise for missing part, which I had not found >>>>> how to solve. >>>>> Up to "make" (build) everything is ok. but "make images" corrupts >>>>> the timestamps, I did not >>>>> found, where the built files flow to images:(to stamp them again, >>>>> and last time) >>>>> >>>>> Best regards from CZ >>>>> J. >>>>> >>>>> >>>>> [1] >>>>> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?h=f21&id=ae70e5d64fbe2fb042c0cee088316b39ee8bf8c9 >>>>> >>>>> >>>>> >>>>> [2]http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/repackReproduciblePolycies >>>>> >>>>> >>>>> [3] >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/afd392dfaed5 >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/edf1cacfe015 >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/9b6cfe5f5078 >>>>> >>>>> [4] >>>>> http://icedtea.classpath.org/hg/icedtea8-forest/jdk/file/tip/make/CreateSecurityJars.gmk >>>>> >>>> >>> >> > From amanda.jiang at oracle.com Thu May 26 23:58:24 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 26 May 2016 16:58:24 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <5745FD85.7070903@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> <573E3BB9.5030307@oracle.com> <573E3EAD.30206@oracle.com> <6e1d1ff3-2533-bf83-f060-b56224a3bab0@oracle.com> <5745FD85.7070903@oracle.com> Message-ID: <6aae8920-8892-8a68-fd5b-a8a473afca62@oracle.com> Hi Rajan, Thanks for your suggestions, I have updated tests with your comments. For TestSampleLength.java, please see my reply inline. webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.03/ Thanks, Amanda On 16/5/25 ??12:31, Rajan Halade wrote: > Hi Amanda, > > Thanks for the update. Few more comments after review: > > - TestSameLength.java: line 93-103, check here should use provider > used with test instance of MessageDigest, call md.getProvider(). You > will need to reorganize test code for this. Security.getProvider() > returns provider installed with specified name. the block in line93-103 is for checking if system supports SHA-3, not related to a specific provider. md.getProvider() won't work since if NSAE thrown, md = null. > - It will be good if you have a function isSHA3Supported() to check > SHA3 supported or not > > Same comments applies from other MessageDigest tests in your review. > > Thanks, > Rajan > > On 5/23/16 3:24 PM, Amanda Jiang wrote: >> Hi Valerie , Rajan, >> >> Thanks for reviewing the webrev. I have updaed >> UnsupportedProvider.java to check NSAE for SUN and OracleUcrypto >> providers. >> >> Other tests has been updated by Rajan's comments as well. >> >> Please check the latest webrev and let me know if there are any other >> problems. >> >> http://cr.openjdk.java.net/~amjiang/8156059/webrev.02/ >> >> >> Thanks, >> Amanda >> >> >> On 16/5/19 ??3:31, Valerie Peng wrote: >>> >>> True, I think the UnsupportedProvider.java should assume SUN >>> provider to support SHA-3 and not allow NSAE. >>> OracleUcrypto provider only supports SHA-3 on Solaris 12 or later, >>> so what you have is fine. >>> >>> As for other tests, as long as SHA-3 algos are covered, it's up to >>> you to make the enhancements that Rajan suggested. >>> Thanks, >>> Valerie >>> >>> On 5/19/2016 3:18 PM, Rajan Halade wrote: >>>> Hi Amanda, >>>> >>>> I have following comments: >>>> - UnsupportedProvider.java line 55: this assumes that it is okay to >>>> have NoSuchAlgorithmException for all providers. >>>> - Update MessageDigest tests to use RandomFactory from >>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f8a3c1510f95/test/lib/testlibrary/jdk/testlibrary. >>>> It logs seed information which will be helpful to reproduce failure. >>>> - Also, MessageDigest tests have no provider checks. >>>> >>>> Rest of tests look fine to me. Note, I am not a official reviewer >>>> so please wait for official reviewer to integrate changes. >>>> >>>> Thanks, >>>> Rajan >>>> >>>> On 5/19/16 11:34 AM, Amanda Jiang wrote: >>>>> Hi All, >>>>> >>>>> Please help to review tests for JEP287: SHA-3 Hash Alogrithms. >>>>> >>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 >>>>> Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ >>>>> Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 >>>>> >>>>> Thanks, >>>>> Amanda >>>> >> > From rajan.halade at oracle.com Fri May 27 00:09:16 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 26 May 2016 17:09:16 -0700 Subject: RFR 8156059: Update/Develop new tests for JEP 287: SHA-3 Hash Algorithms In-Reply-To: <6aae8920-8892-8a68-fd5b-a8a473afca62@oracle.com> References: <639c00da-2bb8-0b87-eaec-eb6bf4bd20ed@oracle.com> <573E3BB9.5030307@oracle.com> <573E3EAD.30206@oracle.com> <6e1d1ff3-2533-bf83-f060-b56224a3bab0@oracle.com> <5745FD85.7070903@oracle.com> <6aae8920-8892-8a68-fd5b-a8a473afca62@oracle.com> Message-ID: <5747902C.7080806@oracle.com> Thanks, I have no more comments. - Rajan On 5/26/2016 16:58, Amanda Jiang wrote: > Hi Rajan, > > Thanks for your suggestions, I have updated tests with your comments. > For TestSampleLength.java, please see my reply inline. > > webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.03/ > > Thanks, > Amanda > > On 16/5/25 ??12:31, Rajan Halade wrote: >> Hi Amanda, >> >> Thanks for the update. Few more comments after review: >> >> - TestSameLength.java: line 93-103, check here should use provider >> used with test instance of MessageDigest, call md.getProvider(). You >> will need to reorganize test code for this. Security.getProvider() >> returns provider installed with specified name. > the block in line93-103 is for checking if system supports SHA-3, not > related to a specific provider. md.getProvider() won't work since if > NSAE thrown, md = null. >> - It will be good if you have a function isSHA3Supported() to check >> SHA3 supported or not >> >> Same comments applies from other MessageDigest tests in your review. >> >> Thanks, >> Rajan >> >> On 5/23/16 3:24 PM, Amanda Jiang wrote: >>> Hi Valerie , Rajan, >>> >>> Thanks for reviewing the webrev. I have updaed >>> UnsupportedProvider.java to check NSAE for SUN and OracleUcrypto >>> providers. >>> >>> Other tests has been updated by Rajan's comments as well. >>> >>> Please check the latest webrev and let me know if there are any >>> other problems. >>> >>> http://cr.openjdk.java.net/~amjiang/8156059/webrev.02/ >>> >>> >>> Thanks, >>> Amanda >>> >>> >>> On 16/5/19 ??3:31, Valerie Peng wrote: >>>> >>>> True, I think the UnsupportedProvider.java should assume SUN >>>> provider to support SHA-3 and not allow NSAE. >>>> OracleUcrypto provider only supports SHA-3 on Solaris 12 or later, >>>> so what you have is fine. >>>> >>>> As for other tests, as long as SHA-3 algos are covered, it's up to >>>> you to make the enhancements that Rajan suggested. >>>> Thanks, >>>> Valerie >>>> >>>> On 5/19/2016 3:18 PM, Rajan Halade wrote: >>>>> Hi Amanda, >>>>> >>>>> I have following comments: >>>>> - UnsupportedProvider.java line 55: this assumes that it is okay >>>>> to have NoSuchAlgorithmException for all providers. >>>>> - Update MessageDigest tests to use RandomFactory from >>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f8a3c1510f95/test/lib/testlibrary/jdk/testlibrary. >>>>> It logs seed information which will be helpful to reproduce failure. >>>>> - Also, MessageDigest tests have no provider checks. >>>>> >>>>> Rest of tests look fine to me. Note, I am not a official reviewer >>>>> so please wait for official reviewer to integrate changes. >>>>> >>>>> Thanks, >>>>> Rajan >>>>> >>>>> On 5/19/16 11:34 AM, Amanda Jiang wrote: >>>>>> Hi All, >>>>>> >>>>>> Please help to review tests for JEP287: SHA-3 Hash Alogrithms. >>>>>> >>>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8156059 >>>>>> Webrev: http://cr.openjdk.java.net/~amjiang/8156059/webrev.01/ >>>>>> Test Plan: https://bugs.openjdk.java.net/browse/JDK-8068855 >>>>>> >>>>>> Thanks, >>>>>> Amanda >>>>> >>> >> > From weijun.wang at oracle.com Fri May 27 01:08:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 27 May 2016 09:08:45 +0800 Subject: Help Needed - Need source code bundle of jsse.jar library In-Reply-To: References: Message-ID: <756ED863-E663-47AA-93E0-53C5139D79AE@oracle.com> You can find the latest jdk7u source code at http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src, which includes JSSE. --Max > On May 26, 2016, at 3:31 PM, Ayaskant Swain wrote: > > Hi All, > > I am in urgent need of the source code bundle of jsse.jar library to debug a javax.net.ssl.SSLHandshakeException error. > > Our java application is a webservice and deployed in Mule container. Our application in turn calls another external SOAP service over a https URL. So our application becomes a client in the SSL conversation. And I am seeing the below errors only when using JDK_1.8.0_60 as the Java runtime for our application. I do not see this problem when i set JDK_1.7.0_71 as the running env for our application and everything works fine. > ----------------------------------------------------- > done seeding SecureRandom > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA > Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 > > Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) > at sun.security.ssl.Handshaker.activate(Handshaker.java:503) ~[?:1.8.0_60] > at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482) ~[?:1.8.0_60] > at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351) ~[?:1.8.0_60] > ----------------------------------------------------------- > > The Handshaker.class & SSLSocketImpl.class are inside jsse.jar file. The above error is being thrown from the "activate(ProtocolVersion helloVersion)" method of the Handshaker.class. I checked out this site - http://download.java.net/openjdk/jdk8/ to get the source bundle for jsse.jar & downloaded the "openjdk-8-src-b132-03_mar_2014.zip" file. But the steps given to build the openjdk is bit difficult to run and failing due to gcc compiler issues on my Mac OS laptop. > > So, can someone please provide me the jsse jar file source bundle (*.zip or *.jar) that will help in debugging the error . I am stuck at this error since last 4 days. > > Thanks > Ayas From dalibor.topic at oracle.com Fri May 27 10:40:32 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 27 May 2016 12:40:32 +0200 Subject: Help Needed - Need source code bundle of jsse.jar library In-Reply-To: References: Message-ID: On 26.05.2016 09:31, Ayaskant Swain wrote: > Hi All, > > I am in urgent need of the source code bundle of *jsse.jar* library to > debug a javax.net.ssl.SSLHandshakeException error. You'll need to ask whoever provided you the jsse.jar you're having problems with. OpenJDK didn't, as it provides source code, rather than binaries. Whoever provided you the binary file that you are having some problem with may (or may not) have changed it in some way, so just blindly downloading source from OpenJDK repositories is unlikely to be a good idea to resolve whatever problem you may have. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ivan.gerasimov at oracle.com Mon May 30 08:48:02 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 30 May 2016 11:48:02 +0300 Subject: RFR: 8158111: Make handling of 3rd party providers more stable Message-ID: <1a9f30e0-b7cd-9ad5-1a28-21a9b242b825@oracle.com> Hello! In the file src/java.base/share/classes/sun/security/ssl/RSAClientKeyExchange.java: When doing the debug printing: System.out.println("The Cipher provider " + cipher.getProvider().getName() + " caused exception: " + iue.getMessage()); cipher.getProvider() may throw an exception, which will cause the fail-over branch get skipped. Furthermore, in the fail-over branch it is better to re-acquire an instance of the cipher, as the previous call to init() might have left the current instance in inconsistent state. Would you please help review the proposed fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8158111 WEBREV: http://cr.openjdk.java.net/~igerasim/8158111/00/webrev/ With kind regards, Ivan From xuelei.fan at oracle.com Mon May 30 09:14:38 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 May 2016 17:14:38 +0800 Subject: RFR: 8158111: Make handling of 3rd party providers more stable In-Reply-To: <1a9f30e0-b7cd-9ad5-1a28-21a9b242b825@oracle.com> References: <1a9f30e0-b7cd-9ad5-1a28-21a9b242b825@oracle.com> Message-ID: Looks fine to me. Thanks! Xuelei On 5/30/2016 4:48 PM, Ivan Gerasimov wrote: > Hello! > > In the file > src/java.base/share/classes/sun/security/ssl/RSAClientKeyExchange.java: > > When doing the debug printing: > System.out.println("The Cipher provider " + > cipher.getProvider().getName() + > " caused exception: " + iue.getMessage()); > > cipher.getProvider() may throw an exception, which will cause the > fail-over branch get skipped. > > > Furthermore, in the fail-over branch it is better to re-acquire an > instance of the cipher, as the previous call to init() might have left > the current instance in inconsistent state. > > Would you please help review the proposed fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8158111 > WEBREV: http://cr.openjdk.java.net/~igerasim/8158111/00/webrev/ > > > With kind regards, > Ivan > > From artem.kosarev at oracle.com Mon May 30 13:03:51 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Mon, 30 May 2016 16:03:51 +0300 Subject: RFR: 8154009: Some methods of java.security.Security require more permissions, than necessary Message-ID: <574C3A37.7010607@oracle.com> Hello. Could you please review the proposed fix issue which is NOT applicable for JDK 9: BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154009 WEBREV: http://cr.openjdk.java.net/~akosarev/8154009/webrev.00/ PROBLEM: **/AddProvider/, /RemoveProvider///& /GetProviders///methods of*//**/java.security.Security/* class results in calling /doLoadProvider /method of *ProviderConfig *class for each Security Provider. And in this method we have a problem that it catches and processes *Exception*, but doesn't process *ExceptionInInitializerError *which is thrown in case of missing permissions: permission java.lang.RuntimePermission "loadLibrary.*"; permission java.io.FilePermission "<>", "read"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*"; Those permissions are unavailable if we switch-off *jre/lib/security/java.policy* file by running program with option: /-Djava.security.policy==/ FIX: In JDK9 *ProviderConfig *class is changed in the scope of JDK-8043406 enhancement (that is why JDK-8154009 is not applicable for JDK 9). And in order to fix above problem in JDK 8 we just require to take same changes for *ProviderConfig *class in JDK 9: See changeset from JDK 9: http://hg.openjdk.java.net/jdk9/dev/jdk/diff/7f8294841146/src/share/classes/sun/security/jca/ProviderConfig.java REGRESSION TESTS: 2 existing tests (*AddProvider*, *RemoveStaticProvider*) were used and modified so that they provide testing for fixed situation (additional permissions are not required any longer for /AddProvider /&**/RemoveProvider /methods.) 1 new test was written for checking /GetProviders /method under restricted permissions. Changes were successfully tested by JPRT. Best regards, Artem Kosarev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon May 30 16:06:20 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 30 May 2016 17:06:20 +0100 Subject: RFR: 8158111: Make handling of 3rd party providers more stable In-Reply-To: References: <1a9f30e0-b7cd-9ad5-1a28-21a9b242b825@oracle.com> Message-ID: <574C64FC.3070205@oracle.com> Looks good Ivan. Given that we know that the cipher transformation is RSA/ECB/PKCS1Padding, maybe you can consider printing that in the exception. As a result, maybe something like : + System.out.println("Retrieval of RSA/ECB/PKCS1Padding cipher transformation" + + " provider caused exception " + e.getMessage()); The cipher.toString() call might be unnecessary as a result then. Will leave that up to you/Xuelei. You might want to consider marking the bug public. Regards, Sean. On 30/05/16 10:14, Xuelei Fan wrote: > Looks fine to me. Thanks! > > Xuelei > > On 5/30/2016 4:48 PM, Ivan Gerasimov wrote: >> Hello! >> >> In the file >> src/java.base/share/classes/sun/security/ssl/RSAClientKeyExchange.java: >> >> When doing the debug printing: >> System.out.println("The Cipher provider " + >> cipher.getProvider().getName() + >> " caused exception: " + iue.getMessage()); >> >> cipher.getProvider() may throw an exception, which will cause the >> fail-over branch get skipped. >> >> >> Furthermore, in the fail-over branch it is better to re-acquire an >> instance of the cipher, as the previous call to init() might have left >> the current instance in inconsistent state. >> >> Would you please help review the proposed fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8158111 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8158111/00/webrev/ >> >> >> With kind regards, >> Ivan >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 31 13:33:54 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 31 May 2016 21:33:54 +0800 Subject: RFR 8152108: Correct jarsigner warning message about missing timestamp Message-ID: <85FDD552-C22C-408D-81BA-50A9867A89BC@oracle.com> Please review this string change for https://bugs.openjdk.java.net/browse/JDK-8152108 Correct jarsigner warning message about missing timestamp --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java @@ -247,9 +247,9 @@ {"This.jar.contains.entries.whose.certificate.chain.is.not.validated.reason.1", "This jar contains entries whose certificate chain is not validated. Reason: %s"}, {"no.timestamp.signing", - "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td) or after any future revocation date."}, + "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, {"no.timestamp.verifying", - "This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td) or after any future revocation date."}, + "This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, {"Unknown.password.type.", "Unknown password type: "}, {"Cannot.find.environment.variable.", "Cannot find environment variable: "}, The two resource strings are used in signing and verifying, respectively. Thanks Max From sean.mullan at oracle.com Tue May 31 14:36:58 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 May 2016 10:36:58 -0400 Subject: RFR 8152108: Correct jarsigner warning message about missing timestamp In-Reply-To: <85FDD552-C22C-408D-81BA-50A9867A89BC@oracle.com> References: <85FDD552-C22C-408D-81BA-50A9867A89BC@oracle.com> Message-ID: <574DA18A.1030409@oracle.com> Looks fine. Bug should have a noreg label. --Sean On 05/31/2016 09:33 AM, Wang Weijun wrote: > Please review this string change for > > https://bugs.openjdk.java.net/browse/JDK-8152108 > Correct jarsigner warning message about missing timestamp > > --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > @@ -247,9 +247,9 @@ > {"This.jar.contains.entries.whose.certificate.chain.is.not.validated.reason.1", > "This jar contains entries whose certificate chain is not validated. Reason: %s"}, > {"no.timestamp.signing", > - "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td) or after any future revocation date."}, > + "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, > {"no.timestamp.verifying", > - "This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td) or after any future revocation date."}, > + "This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, > {"Unknown.password.type.", "Unknown password type: "}, > {"Cannot.find.environment.variable.", > "Cannot find environment variable: "}, > > The two resource strings are used in signing and verifying, respectively. > > Thanks > Max > From sibabrata.sahoo at oracle.com Tue May 31 15:04:59 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 31 May 2016 08:04:59 -0700 (PDT) Subject: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout Message-ID: Hi, Please review the fix for the following JBS bugs, JBS: https://bugs.openjdk.java.net/browse/JDK-8157896 https://bugs.openjdk.java.net/browse/JDK-8157898 webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.00/ Description: These Tests takes a lots of time to generate DSA parameter when the prime and subprime values are greater in some machine with some platform. The reason is being the operations are CPU intensive, which causes the Tests to timeout in rare occasion. But the Test performance can be improved by, instead of generating DSA parameter with all supported input in a single run, it can be divided for each input as a separate run, so that each run can complete much before compared to all input at once. It also provides the flexibility to associate test options like "timeout" for specific input type where the execution time is expected to exceed the default. Note: The fix won't give a guarantee that the timeout will never happen but it can surely help reduce the timeout in greater extent. Please provide your suggestion, in case any. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Tue May 31 17:55:28 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 May 2016 18:55:28 +0100 Subject: [jdk9] RFR: 8080273: JCA Signature provider service loading bottlenecks In-Reply-To: <7c02d7f6-6492-018f-d087-51dfc7fd6023@oracle.com> References: <7c02d7f6-6492-018f-d087-51dfc7fd6023@oracle.com> Message-ID: Ivan, apologies for late review. I like the approach taken. It should help minimize contention. I'd have to highlight though that most contention seen in this area will be probably down to lack of raw CPU power. As RSA key lengths continue to grow, more CPU calculations will become necessary. The new intrinsics work recently completed will also benefit this area. [1] I was a bit confused around why you're calling modPow earlier in iterBlindingRandomPair now but got it in the end. It won't be a wasted cycle in any case as per your notes. Looks good to me. It would be good for you to get a member of Security team to review this. [1] https://bugs.openjdk.java.net/browse/JDK-8153189 Regards, Sean. On 23/05/2016 12:41, Ivan Gerasimov wrote: > Hello! > > It has been observed that under some circumstances a scalability > bottleneck may be observed, when accessing the internal > BlindingParameters structure in the sun.security.rsa.RSACore class. > > It is proposed to slightly reorganize the code around, to reduce the > possible contention. > > Would you please help review the proposal? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080273 > WEBREV: http://cr.openjdk.java.net/~igerasim/8080273/00/webrev/ > > Three things are done here: > 1) The instance of BlindingParameters is confined to the current > thread, so no synchronization is necessary when creating the next > BlindingRandomPair; > 2) Extra instances of BlindingParameters, which are created due to > concurency, aren't thrown away but reused; > 3) Only perform { u = u.modPow(BIG_TWO, n); v = v.modPow(BIG_TWO, n); > } when needed, thus save the last unused calculation. > > Comments, suggestions are very welcome! > > With kind regards, > Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue May 31 19:53:32 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 31 May 2016 22:53:32 +0300 Subject: RFR: 8158111: Make handling of 3rd party providers more stable In-Reply-To: <574C64FC.3070205@oracle.com> References: <1a9f30e0-b7cd-9ad5-1a28-21a9b242b825@oracle.com> <574C64FC.3070205@oracle.com> Message-ID: <96f42013-7a96-f94e-8c52-ef56ed65dc92@oracle.com> Thanks Xuelei, thanks Se?n! With kind regards, Ivan On 30.05.2016 19:06, Se?n Coffey wrote: > Looks good Ivan. Given that we know that the cipher transformation is > RSA/ECB/PKCS1Padding, maybe you can consider printing that in the > exception. As a result, maybe something like : > > + System.out.println("Retrieval of > RSA/ECB/PKCS1Padding cipher transformation" + > + " provider caused exception " + e.getMessage()); > > The cipher.toString() call might be unnecessary as a result then. Will > leave that up to you/Xuelei. > > You might want to consider marking the bug public. > Regards, > Sean. > On 30/05/16 10:14, Xuelei Fan wrote: >> Looks fine to me. Thanks! >> >> Xuelei >> >> On 5/30/2016 4:48 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> In the file >>> src/java.base/share/classes/sun/security/ssl/RSAClientKeyExchange.java: >>> >>> When doing the debug printing: >>> System.out.println("The Cipher provider " + >>> cipher.getProvider().getName() + >>> " caused exception: " + iue.getMessage()); >>> >>> cipher.getProvider() may throw an exception, which will cause the >>> fail-over branch get skipped. >>> >>> >>> Furthermore, in the fail-over branch it is better to re-acquire an >>> instance of the cipher, as the previous call to init() might have left >>> the current instance in inconsistent state. >>> >>> Would you please help review the proposed fix? >>> >>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8158111 >>> WEBREV:http://cr.openjdk.java.net/~igerasim/8158111/00/webrev/ >>> >>> >>> With kind regards, >>> Ivan >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Tue May 31 20:26:06 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 31 May 2016 13:26:06 -0700 Subject: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout In-Reply-To: References: Message-ID: <574DF35E.4050106@oracle.com> Thanks for the patch, Siba! This fix looks confusing to me. TestDSAGenParameterSpec has timeout specified for 2048 but not for 3072/224 and 4096 case. Why would these run faster than smaller lengths? May be there is some other reason, area experts can help here. Thanks, Rajan On 5/31/2016 08:04, Sibabrata Sahoo wrote: > > Hi, > > Please review the fix for the following JBS bugs, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157896 > > https://bugs.openjdk.java.net/browse/JDK-8157898 > > webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.00/ > > > Description: > > These Tests takes a lots of time to generate DSA parameter when the > prime and subprime values are greater in some machine with some > platform. The reason is being the operations are CPU intensive, which > causes the Tests to timeout in rare occasion. But the Test performance > can be improved by, instead of generating DSA parameter with all > supported input in a single run, it can be divided for each input as a > separate run, so that each run can complete much before compared to > all input at once. It also provides the flexibility to associate test > options like ?timeout? for specific input type where the execution > time is expected to exceed the default. > > Note: The fix won?t give a guarantee that the timeout will never > happen but it can surely help reduce the timeout in greater extent. > Please provide your suggestion, in case any. > > Thanks, > > Siba > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayaskant.swain at gmail.com Fri May 27 08:45:19 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Fri, 27 May 2016 14:15:19 +0530 Subject: Help Needed - Need source code bundle of jsse.jar library In-Reply-To: <756ED863-E663-47AA-93E0-53C5139D79AE@oracle.com> References: <756ED863-E663-47AA-93E0-53C5139D79AE@oracle.com> Message-ID: Hi Wang, I did not find the package* sun.security.ssl* in the location you have provided. I am looking for source code for the package that has classes such as SSLSocketImpl.java , HandShaker.java etc. Thanks Ayas On Fri, May 27, 2016 at 6:38 AM, Wang Weijun wrote: > You can find the latest jdk7u source code at > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src, > which includes JSSE. > > --Max > > > On May 26, 2016, at 3:31 PM, Ayaskant Swain > wrote: > > > > Hi All, > > > > I am in urgent need of the source code bundle of jsse.jar library to > debug a javax.net.ssl.SSLHandshakeException error. > > > > Our java application is a webservice and deployed in Mule container. Our > application in turn calls another external SOAP service over a https URL. > So our application becomes a client in the SSL conversation. And I am > seeing the below errors only when using JDK_1.8.0_60 as the Java runtime > for our application. I do not see this problem when i set JDK_1.7.0_71 as > the running env for our application and everything works fine. > > ----------------------------------------------------- > > done seeding SecureRandom > > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 > > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 > > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA > > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 > > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA > > Ignoring unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 > > > > Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol > (protocol is disabled or cipher suites are inappropriate) > > at sun.security.ssl.Handshaker.activate(Handshaker.java:503) > ~[?:1.8.0_60] > > at > sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482) > ~[?:1.8.0_60] > > at > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351) > ~[?:1.8.0_60] > > ----------------------------------------------------------- > > > > The Handshaker.class & SSLSocketImpl.class are inside jsse.jar file. The > above error is being thrown from the "activate(ProtocolVersion > helloVersion)" method of the Handshaker.class. I checked out this site - > http://download.java.net/openjdk/jdk8/ to get the source bundle for > jsse.jar & downloaded the "openjdk-8-src-b132-03_mar_2014.zip" file. But > the steps given to build the openjdk is bit difficult to run and failing > due to gcc compiler issues on my Mac OS laptop. > > > > So, can someone please provide me the jsse jar file source bundle (*.zip > or *.jar) that will help in debugging the error . I am stuck at this error > since last 4 days. > > > > Thanks > > Ayas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayaskant.swain at gmail.com Fri May 27 08:47:36 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Fri, 27 May 2016 14:17:36 +0530 Subject: Help Needed - Need source code bundle of jsse.jar library In-Reply-To: References: <756ED863-E663-47AA-93E0-53C5139D79AE@oracle.com> Message-ID: Hi Wang, Sorry. Upon looking carefully i found the required classes at this place http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src/share/classes/sun/security/ssl Thanks for helping. Appreciate. Ayas On Fri, May 27, 2016 at 2:15 PM, Ayaskant Swain wrote: > Hi Wang, > > I did not find the package* sun.security.ssl* in the location you have > provided. I am looking for source code for the package that has classes > such as SSLSocketImpl.java , HandShaker.java etc. > > Thanks > Ayas > > On Fri, May 27, 2016 at 6:38 AM, Wang Weijun > wrote: > >> You can find the latest jdk7u source code at >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/70e3553d9d6e/src, >> which includes JSSE. >> >> --Max >> >> > On May 26, 2016, at 3:31 PM, Ayaskant Swain >> wrote: >> > >> > Hi All, >> > >> > I am in urgent need of the source code bundle of jsse.jar library to >> debug a javax.net.ssl.SSLHandshakeException error. >> > >> > Our java application is a webservice and deployed in Mule container. >> Our application in turn calls another external SOAP service over a https >> URL. So our application becomes a client in the SSL conversation. And I am >> seeing the below errors only when using JDK_1.8.0_60 as the Java runtime >> for our application. I do not see this problem when i set JDK_1.7.0_71 as >> the running env for our application and everything works fine. >> > ----------------------------------------------------- >> > done seeding SecureRandom >> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 >> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 >> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 >> > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA >> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 >> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >> > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA >> > Ignoring unsupported cipher suite: >> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 >> > >> > Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol >> (protocol is disabled or cipher suites are inappropriate) >> > at sun.security.ssl.Handshaker.activate(Handshaker.java:503) >> ~[?:1.8.0_60] >> > at >> sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482) >> ~[?:1.8.0_60] >> > at >> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351) >> ~[?:1.8.0_60] >> > ----------------------------------------------------------- >> > >> > The Handshaker.class & SSLSocketImpl.class are inside jsse.jar file. >> The above error is being thrown from the "activate(ProtocolVersion >> helloVersion)" method of the Handshaker.class. I checked out this site - >> http://download.java.net/openjdk/jdk8/ to get the source bundle for >> jsse.jar & downloaded the "openjdk-8-src-b132-03_mar_2014.zip" file. But >> the steps given to build the openjdk is bit difficult to run and failing >> due to gcc compiler issues on my Mac OS laptop. >> > >> > So, can someone please provide me the jsse jar file source bundle >> (*.zip or *.jar) that will help in debugging the error . I am stuck at this >> error since last 4 days. >> > >> > Thanks >> > Ayas >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayaskant.swain at gmail.com Mon May 30 06:02:09 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Mon, 30 May 2016 11:32:09 +0530 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? Message-ID: Hi, Can anyone please help me know about this - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? I see the jsse.jar library shipped with the JDK. I read the the Oracle document about JSSE - http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction So my question is - does the JSSE implement the Ciphers or Algorithms that are used for a successful SSL handshake , server authentication, data integrity & data confidentiality (Application data encryption). Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or * *TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* So is the coding of the above ciphers have been done in the JSSE library? Thanks Ayaskant Bangalore -------------- next part -------------- An HTML attachment was scrubbed... URL: