From artem.smotrakov at oracle.com Mon Dec 1 18:10:54 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 01 Dec 2014 21:10:54 +0300 Subject: [9] request for review 8059009: LDAPCertStore fails to retrieve CRL after LDAP server closes idle connection Message-ID: <547CAF2E.6000408@oracle.com> Please review this fix for 9. It corrects the following issues: - InitialLdapContext and LDAPCertStore does not recover connection if it was closed, for example, by server, or due to some network issue - A cache of CertStore instances in LDAPCertStore does not work if LDAPCertStoreParameters is used Changes: - updated LdapCtx to make re-connect possible - updated LDAPCertStore to use InitialLdapContext that supports re-connect - updated LDAPCertStore to use only SunLDAPCertStoreParameters objects for cache of CertStore instances Bug: https://bugs.openjdk.java.net/browse/JDK-8059009 Webrev: http://cr.openjdk.java.net/~asmotrak/8059009/webrev.01/ Artem From weijun.wang at oracle.com Tue Dec 2 08:21:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 2 Dec 2014 16:21:46 +0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <12D71E87-EF4B-492F-8436-A954165F31E1@oracle.com> References: <545BBE8A.6060306@oracle.com> <5466AB75.1040807@oracle.com> <8A2041CF-EE21-44F1-AE81-ECF46758EB3F@oracle.com> <546A8804.9070907@oracle.com> <12D71E87-EF4B-492F-8436-A954165F31E1@oracle.com> Message-ID: <670E6B81-D921-46EB-B3C9-8423778FE4D8@oracle.com> Are you OK with this difference? Thanks Max > On Nov 18, 2014, at 15:02, Wang Weijun wrote: > > >> On Nov 18, 2014, at 07:43, Valerie Peng wrote: >> >> >> The default value 0 for the "renew_lifetime" is documented in MIT's Kerberos conf documentation. http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html >> However, I am not sure how this 0 value should be interpreted/handled. > > From what I observe, MIT kinit by default sends a null rtime. So it is the same as us. > > On the other hand, MIT kinit default sets RENEWABLE_OK, so it always receives a renewable ticket and the renewable lifetime set by KDC. In Java, we only set it when "renewable = true" is included in krb5.conf (see KDCOptions::setDefault), so by default java kinit gets a non-renewable ticket. > > Thanks > Max > > >> Valerie >> On 11/17/2014 12:23 AM, Wang Weijun wrote: >>>> On Nov 15, 2014, at 09:25, Valerie Peng wrote: >>>> >>>> Max, >>>> >>>> Most looks fine, just some questions. >>>> >>>> - Kinit.java: line 56, it should be "sun.security.krb5.internal.tools.Kinit"? >>> Correct. >>> >>>> - Kinit.java: for the switch block from 135 - 142: add a default case to catch illegal values? >>> Done. >>> >>>> - Kinit.java: line 163, doesn't the credentials cache exist already? >>> This line would remove all existing service tickets so they will be re-acquired using the new TGT. I copied this behavior from other vendors. >>> >>>> - KrbAsReq.java: line 128, what if rtime is 0 (default value)? >>> Not sure if I understand. There is no default value for "renew_lifetime". If it does not exist inside krb5.conf, then rtime is not reassigned, which is still null. >>> >>>> - KDC.java: line 879-883, how can you be sure that there is always more than 1 eType and that the 2nd eType is supported. >>> I'll throw KDC_ERR_ETYPE_NOSUPP. >>> >>> Thanks >>> Max >>> >>>> Valerie >>>> >>>> On 11/6/2014 10:31 AM, Valerie Peng wrote: >>>>> OK, I will take a look. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 11/5/2014 10:04 PM, Wang Weijun wrote: >>>>>> Ping ping... >>>>>> >>>>>>> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >>>>>>> >>>>>>> Anyone can take a look? >>>>>>> >>>>>>>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>>>>>>> >>>>>>>> Hi All >>>>>>>> >>>>>>>> Please review the code change at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>>>>>>> >>>>>>>> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> > From vincent.x.ryan at oracle.com Tue Dec 2 11:23:41 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 2 Dec 2014 11:23:41 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default Message-ID: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> Please review the following enhancement to improve keystore security by creating PKCS12 keystores by default. Previously, JKS keystores were created by default. PKCS12 has the advantage of supporting stronger crypto and hashing algorithms. It is also an open, extensible format and supports associating arbitrary attributes with keystore entries. Webrev: http://cr.openjdk.java.net/~vinnie/8044445/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8044445 To assist with compatibility across JDK releases, both JKS and PKCS12 keystore implementations have been extended to support both file formats. Applications that access keystores created by earlier releases should require no code changes. This changeset also includes a new convenience method for instantiating a file-based keystore: KeyStore.getInstance - it takes a File argument. The specified file is probed by each supported keystore implementation to determine its keystore type. KeyStoreSpi has been enhanced with a boolean engineProbe method to perform the actual probing. Finally, to improve performance, the PKCS12 keystore implementation has been moved from the SunJSSE provider to the SUN provider (as it appears earlier in the default list of installed JCE providers). From sean.mullan at oracle.com Tue Dec 2 15:10:33 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 02 Dec 2014 10:10:33 -0500 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> Message-ID: <547DD669.7010808@oracle.com> Comments: * JceKeyStore [906] add @Override to engineProbe method * KeyStore [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. You need to define what happens if the File does not exist. You could either throw a KeyStoreException, or you could instantiate a KeyStore using the default keystore type. Each have their pros/cons. The latter seems a little better as this method could then be used to open existing keystores or for creating new keystores. [1638] This is a provider configuration error, but there still may be other KeyStoreSpis that can parse the file. I would probably just log this and continue to check other providers. [1654] Same here. I would log this and continue to check other providers. Method currently say it throws KeyStoreExc only if no Provider supports the file, but we have not necessarily checked all providers yet. * KeyStoreSpi [606] s/@exception/@throws/. Should probably also add an @throws NullPointerException if stream is null. You need to define that the method returns false by default. * PKCS12KeyStore [2340] @Override [2342-51] indentation should be 4 spaces [2353,2364] these should be static fields * JavaKeyStore [54] why did you make this public? [816] @Override * keytool/Main [814, 1919] I'm not sure if it is correct to ignore the storetype. I think getInstance(File) should only be called if the storetype is not specified. * KeyStoreDelegator overridden methods should have @Override tag Can you make this class final with a private ctor, and instead have a static method to return instances? The engine methods throw NPE if the keystore has not been loaded. This is not consistent with the current JKS Keystore and PKCS12 Keystore impls and looks like it is not compliant with the KeyStoreSpi spec. I think you need to modify the methods to return null, etc instead if the keystore has not been loaded yet. --Sean On 12/02/2014 06:23 AM, Vincent Ryan wrote: > > Please review the following enhancement to improve keystore security by creating PKCS12 keystores by default. > Previously, JKS keystores were created by default. PKCS12 has the advantage of supporting stronger crypto > and hashing algorithms. It is also an open, extensible format and supports associating arbitrary attributes with > keystore entries. > > Webrev: http://cr.openjdk.java.net/~vinnie/8044445/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8044445 > > > To assist with compatibility across JDK releases, both JKS and PKCS12 keystore implementations have been > extended to support both file formats. Applications that access keystores created by earlier releases should > require no code changes. > > This changeset also includes a new convenience method for instantiating a file-based keystore: KeyStore.getInstance > - it takes a File argument. The specified file is probed by each supported keystore implementation to determine its > keystore type. KeyStoreSpi has been enhanced with a boolean engineProbe method to perform the actual probing. > > Finally, to improve performance, the PKCS12 keystore implementation has been moved from the SunJSSE provider > to the SUN provider (as it appears earlier in the default list of installed JCE providers). > From valerie.peng at oracle.com Tue Dec 2 21:42:58 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 02 Dec 2014 13:42:58 -0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <670E6B81-D921-46EB-B3C9-8423778FE4D8@oracle.com> References: <545BBE8A.6060306@oracle.com> <5466AB75.1040807@oracle.com> <8A2041CF-EE21-44F1-AE81-ECF46758EB3F@oracle.com> <546A8804.9070907@oracle.com> <12D71E87-EF4B-492F-8436-A954165F31E1@oracle.com> <670E6B81-D921-46EB-B3C9-8423778FE4D8@oracle.com> Message-ID: <547E3262.6010905@oracle.com> The difference seems minor enough to me. Just wondering, have any one reported/complained about this though? Thanks, Valerie On 12/2/2014 12:21 AM, Wang Weijun wrote: > Are you OK with this difference? > > Thanks > Max > >> On Nov 18, 2014, at 15:02, Wang Weijun wrote: >> >> >>> On Nov 18, 2014, at 07:43, Valerie Peng wrote: >>> >>> >>> The default value 0 for the "renew_lifetime" is documented in MIT's Kerberos conf documentation. http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html >>> However, I am not sure how this 0 value should be interpreted/handled. >> From what I observe, MIT kinit by default sends a null rtime. So it is the same as us. >> >> On the other hand, MIT kinit default sets RENEWABLE_OK, so it always receives a renewable ticket and the renewable lifetime set by KDC. In Java, we only set it when "renewable = true" is included in krb5.conf (see KDCOptions::setDefault), so by default java kinit gets a non-renewable ticket. >> >> Thanks >> Max >> >> >>> Valerie >>> On 11/17/2014 12:23 AM, Wang Weijun wrote: >>>>> On Nov 15, 2014, at 09:25, Valerie Peng wrote: >>>>> >>>>> Max, >>>>> >>>>> Most looks fine, just some questions. >>>>> >>>>> - Kinit.java: line 56, it should be "sun.security.krb5.internal.tools.Kinit"? >>>> Correct. >>>> >>>>> - Kinit.java: for the switch block from 135 - 142: add a default case to catch illegal values? >>>> Done. >>>> >>>>> - Kinit.java: line 163, doesn't the credentials cache exist already? >>>> This line would remove all existing service tickets so they will be re-acquired using the new TGT. I copied this behavior from other vendors. >>>> >>>>> - KrbAsReq.java: line 128, what if rtime is 0 (default value)? >>>> Not sure if I understand. There is no default value for "renew_lifetime". If it does not exist inside krb5.conf, then rtime is not reassigned, which is still null. >>>> >>>>> - KDC.java: line 879-883, how can you be sure that there is always more than 1 eType and that the 2nd eType is supported. >>>> I'll throw KDC_ERR_ETYPE_NOSUPP. >>>> >>>> Thanks >>>> Max >>>> >>>>> Valerie >>>>> >>>>> On 11/6/2014 10:31 AM, Valerie Peng wrote: >>>>>> OK, I will take a look. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 11/5/2014 10:04 PM, Wang Weijun wrote: >>>>>>> Ping ping... >>>>>>> >>>>>>>> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >>>>>>>> >>>>>>>> Anyone can take a look? >>>>>>>> >>>>>>>>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>>>>>>>> >>>>>>>>> Hi All >>>>>>>>> >>>>>>>>> Please review the code change at >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>>>>>>>> >>>>>>>>> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> From zaiyao.liu at oracle.com Wed Dec 3 02:26:31 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 03 Dec 2014 10:26:31 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores In-Reply-To: <54211C5F.3080409@oracle.com> References: <5403CDE6.6070006@oracle.com> <541B9D20.3030006@oracle.com> <327859DE-91C4-4EE6-B16E-CDD715FCD318@oracle.com> <541FD9BF.3090206@oracle.com> <65393CFA-9AA6-4969-9291-165937EF7415@oracle.com> <54211C5F.3080409@oracle.com> Message-ID: <547E74D7.5040201@oracle.com> Hi Max, Please help to review the update: http://cr.openjdk.java.net/~rhalade/8048619/webrev.02/ Thanks Kevin ? 2014/9/23 15:08, zaiyao liu ??: > Hi Max, > > Please help to check this > update:http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/ > > Thanks > > Kevin > ? 2014/9/22 17:10, Wang Weijun ??: >> On Sep 22, 2014, at 16:11, zaiyao liu wrote: >> >>> Hi Max, >>> >>> Thanks for review. please review the update: >>> http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/, >>> I will ask Rajan to create open webrev link after you passed. >> 194 if (a.size() != b.size()) { >> >> How about "if (a.size() != 1 || b.size() != 1)"? >> >> 239-250 >> >> This can be as simple as Arrays.equals(certsA, certsB). >> >> I would still like a single compareKeyStore() no matter what the size >> of the keystore is. >> >> --Max >> >>> Thanks >>> >>> Kevin >>> ? 2014/9/19 15:34, Wang Weijun ??: >>>> In compareCerts(), you should not compare Certificate.toString(), >>>> its equals() method is more reliable. There is no need to define >>>> compareKeys() and compareCerts(). Instead, you should try not to >>>> repeat lines 223-231 on 252-260. >>>> >>>> The two calls on lines 204 and 205 have keystore names exchanged >>>> but keypass order is the same. Also, with two calls it means the >>>> comparisons of keys and certs are duplicated. The else block on >>>> line 206 looks strange. Do you mean the size is always 1 here? If >>>> so, check it. Otherwise, there is no guarantee the aliases appear >>>> in the same order. >>>> >>>> I would be glad to see a generalized comparison method no matter >>>> what the keystore size is. >>>> >>>> Minor issues: >>>> >>>> It will be clear if you divide the constant strings at the >>>> beginning into 2 parts, one for provider names, and one for >>>> algorithms. >>>> >>>> Line 143 and 145, there should be spaces around the testCase name. >>>> >>>> --Max >>>> >>>> On Sep 19, 2014, at 11:04, zaiyao liu wrote: >>>> >>>>> Hi Max, >>>>> >>>>> Can you help to review it? >>>>> >>>>> Thanks >>>>> >>>>> Kevin >>>>> ? 2014/9/1 13:25, Wang Weijun ??: >>>>>> On vacation now. Can you look for someone else? I will be back in >>>>>> Sep 17 if you are not in a hurry. >>>>>> >>>>>> --Max >>>>>> >>>>>> On Sep 1, 2014, at 9:37, zaiyao liu wrote: >>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> Please review the code change,the purpose of this fix is >>>>>>> implement tests that convert PKCS12 keystores to other formats. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Kevin > From zaiyao.liu at oracle.com Wed Dec 3 06:15:47 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 03 Dec 2014 14:15:47 +0800 Subject: RFR JDK-8049432: Need new tests for testing TLS property jdk.tls.client.protocols with various protocols and values In-Reply-To: <540FB78D.2070101@oracle.com> References: <540FB78D.2070101@oracle.com> Message-ID: <547EAA93.6040308@oracle.com> Hi Xuelei, Can you help to review this code change? Thanks and Regards. Kevin ? 2014/9/10 10:29, zaiyao liu ??: > Hi All, > > Please review the code change,the purpose of this fix is to address > following: > -Sets the property jdk.tls.client.protocols to one of this > protocols:SSLv3,TLSv1,TLSv1,TLSv1.1,TLSv1.2 and TLSV(invalid) or > removes this > property (if any),then validates the default, supported and current > protocols in the SSLContext. > > Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8049432/webrev01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049432 > > Thanks > > Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Dec 3 07:37:41 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 3 Dec 2014 15:37:41 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores In-Reply-To: <547E74D7.5040201@oracle.com> References: <5403CDE6.6070006@oracle.com> <541B9D20.3030006@oracle.com> <327859DE-91C4-4EE6-B16E-CDD715FCD318@oracle.com> <541FD9BF.3090206@oracle.com> <65393CFA-9AA6-4969-9291-165937EF7415@oracle.com> <54211C5F.3080409@oracle.com> <547E74D7.5040201@oracle.com> Message-ID: <08E2DBF1-690B-42B9-A732-30880BBD21D6@oracle.com> Looks fine. One nit, line 231, remove "Certs don't match ". Thanks Max > On Dec 3, 2014, at 10:26, zaiyao liu wrote: > > Hi Max, > > Please help to review the update: > http://cr.openjdk.java.net/~rhalade/8048619/webrev.02/ > > Thanks > Kevin > ? 2014/9/23 15:08, zaiyao liu ??: >> Hi Max, >> >> Please help to check this update:http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/ >> >> Thanks >> >> Kevin >> ? 2014/9/22 17:10, Wang Weijun ??: >>> On Sep 22, 2014, at 16:11, zaiyao liu wrote: >>> >>>> Hi Max, >>>> >>>> Thanks for review. please review the update: http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/, I will ask Rajan to create open webrev link after you passed. >>> 194 if (a.size() != b.size()) { >>> >>> How about "if (a.size() != 1 || b.size() != 1)"? >>> >>> 239-250 >>> >>> This can be as simple as Arrays.equals(certsA, certsB). >>> >>> I would still like a single compareKeyStore() no matter what the size of the keystore is. >>> >>> --Max >>> >>>> Thanks >>>> >>>> Kevin >>>> ? 2014/9/19 15:34, Wang Weijun ??: >>>>> In compareCerts(), you should not compare Certificate.toString(), its equals() method is more reliable. There is no need to define compareKeys() and compareCerts(). Instead, you should try not to repeat lines 223-231 on 252-260. >>>>> >>>>> The two calls on lines 204 and 205 have keystore names exchanged but keypass order is the same. Also, with two calls it means the comparisons of keys and certs are duplicated. The else block on line 206 looks strange. Do you mean the size is always 1 here? If so, check it. Otherwise, there is no guarantee the aliases appear in the same order. >>>>> >>>>> I would be glad to see a generalized comparison method no matter what the keystore size is. >>>>> >>>>> Minor issues: >>>>> >>>>> It will be clear if you divide the constant strings at the beginning into 2 parts, one for provider names, and one for algorithms. >>>>> >>>>> Line 143 and 145, there should be spaces around the testCase name. >>>>> >>>>> --Max >>>>> >>>>> On Sep 19, 2014, at 11:04, zaiyao liu wrote: >>>>> >>>>>> Hi Max, >>>>>> >>>>>> Can you help to review it? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Kevin >>>>>> ? 2014/9/1 13:25, Wang Weijun ??: >>>>>>> On vacation now. Can you look for someone else? I will be back in Sep 17 if you are not in a hurry. >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>> On Sep 1, 2014, at 9:37, zaiyao liu wrote: >>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Please review the code change,the purpose of this fix is implement tests that convert PKCS12 keystores to other formats. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Kevin >> > From xuelei.fan at oracle.com Wed Dec 3 08:50:10 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 03 Dec 2014 16:50:10 +0800 Subject: RFR JDK-8049432: Need new tests for testing TLS property jdk.tls.client.protocols with various protocols and values In-Reply-To: <547EAA93.6040308@oracle.com> References: <540FB78D.2070101@oracle.com> <547EAA93.6040308@oracle.com> Message-ID: <547ECEC2.5000109@oracle.com> Looks fine to me. Only a few minor comments: 1. 201 String[] expecteSupported_protos = new String[] { 202 "SSLv2Hello", "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" 203 }; This variable can be define as a static class variable: public class TLSClientPropertyTest { private String[] expecteSupportedProtos = new String[] { "SSLv2Hello", "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" }; } Per Java coding conversions, better to use "theVariableName" style, rather than link with "-" or "_" (expecteSupported_protos vs expecteSupportedProtos). 2. 60 String protocol; I think, in the test, this is used as SSLContext protocol. It would be nice if the variable name is instinctive. I may suggest to use "contextProtocol". The same for the "expectedProto" parameter name. 3. 67 expectedDefaultProtos = new String[] { 68 "TLSv1.1", "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" 69 }; Is it intend to have duplicated "TLSv1.1"? It's OK to me, but better to add a comment about why duplicated protocols are listed here. 4. Do you want to test the "SSL" and "TLS" protocol of SSLContext ()? Thanks, Xuelei On 12/3/2014 2:15 PM, zaiyao liu wrote: > Hi Xuelei, > > Can you help to review this code change? > > Thanks and Regards. > > Kevin > ? 2014/9/10 10:29, zaiyao liu ??: >> Hi All, >> >> Please review the code change,the purpose of this fix is to address >> following: >> -Sets the property jdk.tls.client.protocols to one of this >> protocols:SSLv3,TLSv1,TLSv1,TLSv1.1,TLSv1.2 and TLSV(invalid) or >> removes this >> property (if any),then validates the default, supported and current >> protocols in the SSLContext. >> >> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8049432/webrev01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8049432 >> >> Thanks >> >> Kevin > From weijun.wang at oracle.com Wed Dec 3 09:50:07 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 3 Dec 2014 17:50:07 +0800 Subject: Fwd: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom References: <547DEC01.2050501@gmail.com> Message-ID: <8CACE9B3-5B8B-4859-9ACC-172A3AF85163@oracle.com> Hi Brad Is this the same as your Non-blocking SecureRandom? They have a webrev at http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/ Thanks Max > Begin forwarded message: > > Date: December 3, 2014 at 00:42:41 GMT+8 > From: Peter Levart > To: Paul Sandoz , core-libs-dev Libs > Subject: Re: RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom > > On 12/02/2014 11:02 AM, Paul Sandoz wrote: >> Hi, >> >> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom. >> >> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*. >> >> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40. >> >> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR. > > Hi, > > Here's a proof of concept for an API that just delegates to system-provided "cryptographically secure" (as declared by the system(s)) pseudo random number generator: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/ > > On UNIX-es this uses /dev/urandom (which is non-blocking and uses system entropy at least for it's seed): > > http://en.wikipedia.org/?title=/dev/random > > On Windows it uses MS Crypto API's function CryptGenRandom (the JNI code is ripped from the sun.security.provider.NativeSeedGenerator), which also seeds from various system sources of entropy: > > http://en.wikipedia.org/wiki/CryptGenRandom > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942%28v=vs.85%29.aspx > > The initialization overhead is low on UNIX (the enclosed test run on 64 bit Fedora 20, i7 PC): > > SystemRandomTest... (8 bytes / invocation) > 1st invocation: 112315 ns, result: [25, 61, -12, -106, 75, -7, -73, -55] > Following 1000000 invocations: 0.636644474 s, (636 ns/invocation) > > The same test run on 32 bit Windows 7 (as VirtualBox guest on the same machine): > > SystemRandomTest... (8 bytes / invocation) > 1st invocation: 4880788 ns, result: [-32, 53, -31, 62, 51, 83, 9, -5] > Following 1000000 invocations: 1.761087512 s, (1761 ns/invocation) > > I think the initialization on Windows has an initial latency of approx 5ms because it has to initialize the whole MS Crypto API with it's providers. But CryptGenRandom, which is part of this API, actually delegates it's work to RtlGenRandom function: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa387694%28v=vs.85%29.aspx > > ...which might have lower initialization costs. Unfortunately, the wording in the Microsoft document states that it might be removed in the future. Perhaps we could try to use it and fallback to CryptGenRandom if it is not available... > > > Regards, Peter > > >> >> Paul. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8060435 >> >> diff -r 1b599b4755bd src/java.base/share/classes/java/util/SplittableRandom.java >> --- a/src/java.base/share/classes/java/util/SplittableRandom.java Mon Dec 01 17:59:39 2014 -0800 >> +++ b/src/java.base/share/classes/java/util/SplittableRandom.java Tue Dec 02 10:53:47 2014 +0100 >> @@ -237,34 +237,7 @@ >> s = (s << 8) | ((long)(seedBytes[i]) & 0xffL); >> return s; >> } >> - long h = 0L; >> - try { >> - Enumeration ifcs = >> - NetworkInterface.getNetworkInterfaces(); >> - boolean retry = false; // retry once if getHardwareAddress is null >> - while (ifcs.hasMoreElements()) { >> - NetworkInterface ifc = ifcs.nextElement(); >> - if (!ifc.isVirtual()) { // skip fake addresses >> - byte[] bs = ifc.getHardwareAddress(); >> - if (bs != null) { >> - int n = bs.length; >> - int m = Math.min(n >>> 1, 4); >> - for (int i = 0; i < m; ++i) >> - h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i]; >> - if (m < 4) >> - h = (h << 8) ^ bs[n-1-m]; >> - h = mix64(h); >> - break; >> - } >> - else if (!retry) >> - retry = true; >> - else >> - break; >> - } >> - } >> - } catch (Exception ignore) { >> - } >> - return (h ^ mix64(System.currentTimeMillis()) ^ >> + return (mix64(System.currentTimeMillis()) ^ >> mix64(System.nanoTime())); >> } >> diff -r 1b599b4755bd src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java >> --- a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java Mon Dec 01 17:59:39 2014 -0800 >> +++ b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue Dec 02 10:53:47 2014 +0100 >> @@ -147,34 +147,7 @@ >> s = (s << 8) | ((long)(seedBytes[i]) & 0xffL); >> return s; >> } >> - long h = 0L; >> - try { >> - Enumeration ifcs = >> - NetworkInterface.getNetworkInterfaces(); >> - boolean retry = false; // retry once if getHardwareAddress is null >> - while (ifcs.hasMoreElements()) { >> - NetworkInterface ifc = ifcs.nextElement(); >> - if (!ifc.isVirtual()) { // skip fake addresses >> - byte[] bs = ifc.getHardwareAddress(); >> - if (bs != null) { >> - int n = bs.length; >> - int m = Math.min(n >>> 1, 4); >> - for (int i = 0; i < m; ++i) >> - h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i]; >> - if (m < 4) >> - h = (h << 8) ^ bs[n-1-m]; >> - h = mix64(h); >> - break; >> - } >> - else if (!retry) >> - retry = true; >> - else >> - break; >> - } >> - } >> - } catch (Exception ignore) { >> - } >> - return (h ^ mix64(System.currentTimeMillis()) ^ >> + return (mix64(System.currentTimeMillis()) ^ >> mix64(System.nanoTime())); >> } From fengzm at sg.ibm.com Wed Dec 3 14:05:12 2014 From: fengzm at sg.ibm.com (Zhemin Feng) Date: Wed, 3 Dec 2014 22:05:12 +0800 Subject: AUTO: Zhemin Feng is out of the office (returning 08/12/2014) Message-ID: I am out of the office until 08/12/2014. I will take leave from 3rd Dec, and will be back on 8th Dec. Please contact Ke Pi/Singapore/IBM for Java Security L3 work. Best regards, Feng Zhemin Note: This is an automated response to your message "security-dev Digest, Vol 90, Issue 2" sent on 12/03/2014 17:50:17. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Dec 4 04:09:49 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 4 Dec 2014 12:09:49 +0800 Subject: Is it reasonable to compare outputs between JMH and hprof? Message-ID: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> Hi All I am comparing the difference of SHA-1 and SHA-256. First I wrote a JMH benchmark: @Benchmark public void sig1(Blackhole bh) throws Exception { bh.consume(sig("SHA-1")); } @Benchmark public void sig2(Blackhole bh) throws Exception { bh.consume(sig("SHA-256")); } byte[] sig(String alg) throws Exception { MessageDigest md = MessageDigest.getInstance(alg); md.update(new byte[10000]); return md.digest(); } The output is Benchmark Mode Samples Score Error Units o.o.b.Weird.sig1 thrpt 5 20984.435 ? 3356.455 ops/s o.o.b.Weird.sig2 thrpt 5 13130.330 ? 976.824 ops/s so the difference is there but not huge. Then I wrote a simple app with public static void main(String args[]) throws Exception { int i = Arrays.hashCode(sig("SHA-1")); i += Arrays.hashCode(sig("SHA-256")); System.out.println(i); } static byte[] sig(String alg) throws Exception { MessageDigest md = MessageDigest.getInstance(alg); md.update(new byte[10000]); return md.digest(); } and then profile it with -agentlib:hprof=cpu=times, and get SHA2 1 10.16% 10.16% 156 303276 sun.security.provider.SHA2.implCompress SHA2 2 6.91% 17.07% 9984 303274 sun.security.provider.SHA2.lf_sigma0 SHA2 3 5.28% 22.36% 9984 303271 sun.security.provider.SHA2.lf_sigma1 SHA2 4 4.61% 26.96% 7488 303269 sun.security.provider.SHA2.lf_delta0 SHA2 5 4.20% 31.17% 29952 303273 sun.security.provider.SHA2.lf_S SHA2 7 3.79% 39.16% 7488 303266 sun.security.provider.SHA2.lf_delta1 SHA2 9 2.85% 44.99% 29952 303270 sun.security.provider.SHA2.lf_S SHA2 13 1.90% 54.47% 14976 303267 sun.security.provider.SHA2.lf_S SHA2 17 1.49% 61.25% 14976 303264 sun.security.provider.SHA2.lf_S SHA2 22 0.81% 66.12% 7488 303265 sun.security.provider.SHA2.lf_R SHA2 23 0.81% 66.94% 9984 303275 sun.security.provider.SHA2.lf_maj SHA2 25 0.81% 68.56% 156 303263 sun.security.provider.ByteArrayAccess.b2iBig64 SHA2 27 0.68% 70.05% 9984 303272 sun.security.provider.SHA2.lf_ch SHA2 31 0.54% 72.63% 7488 303268 sun.security.provider.SHA2.lf_R SHA1 34 0.54% 74.25% 156 303224 sun.security.provider.SHA.implCompress SHA1 43 0.41% 78.05% 156 303223 sun.security.provider.ByteArrayAccess.b2iBig64 SHA2 60 0.27% 82.66% 2496 303262 java.lang.Integer.reverseBytes SHA2 61 0.27% 82.93% 64 303290 sun.security.provider.SHA2.lf_sigma1 SHA1 116 0.14% 91.06% 2496 303222 java.lang.Integer.reverseBytes These are calls with SHA (i.e. SHA1) or SHA2 in the stack (depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%. With such a small app I don't think SHA or SHA2 is called anywhere else. This is jdk9 b40. Why is the output so different from JMH? Is it reasonable comparing them? Thanks Max From ecki at zusammenkunft.net Thu Dec 4 05:38:20 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 4 Dec 2014 06:38:20 +0100 Subject: Is it reasonable to compare outputs between JMH and hprof? In-Reply-To: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> References: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> Message-ID: <20141204063820.000063ce.ecki@zusammenkunft.net> Hello, I would use the power of JMH to test this with different array sizes and with and without provider instantiation. I did that a while back for MDC/MAC, and SHA256 is not that attractive anymore as SHA512 is faster (and with SHA512-256 not bigger) (Java7Windows7:) https://gist.github.com/ecki/a4d598c4231a0165d0a1 Benchmark (bufsize) Mode Samples Score Score error Units n.e.t.j.HashBenchmark.testHmacSHA1 1 avgt 3 0,005 0,001 ms/op n.e.t.j.HashBenchmark.testHmacSHA1 1024 avgt 3 0,015 0,005 ms/op n.e.t.j.HashBenchmark.testHmacSHA1 1048576 avgt 3 9,479 1,836 ms/op n.e.t.j.HashBenchmark.testHmacSHA256 1 avgt 3 0,006 0,003 ms/op n.e.t.j.HashBenchmark.testHmacSHA256 1024 avgt 3 0,021 0,010 ms/op n.e.t.j.HashBenchmark.testHmacSHA256 1048576 avgt 3 14,211 2,847 ms/op n.e.t.j.HashBenchmark.testHmacSHA512 1 avgt 3 0,009 0,002 ms/op n.e.t.j.HashBenchmark.testHmacSHA512 1024 avgt 3 0,021 0,011 ms/op n.e.t.j.HashBenchmark.testHmacSHA512 1048576 avgt 3 11,727 11,595 ms/op n.e.t.j.HashBenchmark.testMD5 1 avgt 3 0,001 0,001 ms/op n.e.t.j.HashBenchmark.testMD5 1024 avgt 3 0,007 0,001 ms/op n.e.t.j.HashBenchmark.testMD5 1048576 avgt 3 6,102 0,360 ms/op n.e.t.j.HashBenchmark.testMD5Reuse 1 avgt 3 0,000 0,000 ms/op n.e.t.j.HashBenchmark.testMD5Reuse 1024 avgt 3 0,007 0,004 ms/op n.e.t.j.HashBenchmark.testMD5Reuse 1048576 avgt 3 6,210 2,319 ms/op n.e.t.j.HashBenchmark.testSHA1 1 avgt 3 0,001 0,003 ms/op n.e.t.j.HashBenchmark.testSHA1 1024 avgt 3 0,011 0,018 ms/op n.e.t.j.HashBenchmark.testSHA1 1048576 avgt 3 9,446 0,750 ms/op n.e.t.j.HashBenchmark.testSHA1Reuse 1 avgt 3 0,001 0,000 ms/op n.e.t.j.HashBenchmark.testSHA1Reuse 1024 avgt 3 0,010 0,002 ms/op n.e.t.j.HashBenchmark.testSHA1Reuse 1048576 avgt 3 9,455 3,341 ms/op n.e.t.j.HashBenchmark.testSHA256 1 avgt 3 0,002 0,000 ms/op n.e.t.j.HashBenchmark.testSHA256 1024 avgt 3 0,016 0,008 ms/op n.e.t.j.HashBenchmark.testSHA256 1048576 avgt 3 13,938 2,390 ms/op n.e.t.j.HashBenchmark.testSHA256Reuse 1 avgt 3 0,001 0,001 ms/op n.e.t.j.HashBenchmark.testSHA256Reuse 1024 avgt 3 0,017 0,007 ms/op n.e.t.j.HashBenchmark.testSHA256Reuse 1048576 avgt 3 15,431 14,422 ms/op n.e.t.j.HashBenchmark.testSHA512 1 avgt 3 0,003 0,001 ms/op n.e.t.j.HashBenchmark.testSHA512 1024 avgt 3 0,015 0,010 ms/op n.e.t.j.HashBenchmark.testSHA512 1048576 avgt 3 11,532 1,528 ms/op n.e.t.j.HashBenchmark.testSHA512Reuse 1 avgt 3 0,002 0,000 ms/op n.e.t.j.HashBenchmark.testSHA512Reuse 1024 avgt 3 0,013 0,009 ms/op n.e.t.j.HashBenchmark.testSHA512Reuse 1048576 avgt 3 10,801 2,124 ms/op But to your question. They way the Profiler samples the stack and the fact that SHA1 and SHA2 are implementations with different depths, they are hard to compare. You would actually have to compare the time spent in high level methods (main/sig/update) not the low level code. And you need to run the test longer otherwise you see only startup/shutdown samples. Besides that Profilers greatly influence the runtime and behavior, its not at all useable for micro benchmarkings (at least not unless you have less intrusive profilers like cpu counter assisted kernel stuff (Linux perf)). Somewhat related a recent article: http://psy-lob-saw.blogspot.de/2014/12/the-escape-of-arraylistiterator.html I see this: public static void main(String args[]) throws Exception { int i=0; MessageDigest md256 = MessageDigest.getInstance("SHA-256"); MessageDigest md1 = MessageDigest.getInstance("SHA-1"); for(int t=0;t<100;t++) { i = Arrays.hashCode(sig1(md1)); i += Arrays.hashCode(sig256(md256));} System.out.println(i); } static byte[] sig1(MessageDigest md) throws Exception { md.update(new byte[10000]); return md.digest(); } static byte[] sig256(MessageDigest md) throws Exception { md.update(new byte[10000]); return md.digest(); } rank self accum count trace method 23 0.05% 99.25% 100 303130 sun.security.provider.DigestBase.engineUpdate ... 27 0.05% 99.45% 100 303096 sun.security.provider.DigestBase.engineUpdate TRACE 303130: sun.security.provider.DigestBase.engineUpdate(DigestBase.java:Unknown line) java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:Unknown line) java.security.MessageDigest.update(MessageDigest.java:Unknown line) net.eckenfels.test.jmh.HashMain.sig256(HashMain.java:Unknown line) net.eckenfels.test.jmh.HashMain.main(HashMain.java:Unknown line) TRACE 303096: sun.security.provider.DigestBase.engineUpdate(DigestBase.java:Unknown line) java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:Unknown line) java.security.MessageDigest.update(MessageDigest.java:Unknown line) net.eckenfels.test.jmh.HashMain.sig1(HashMain.java:Unknown line) net.eckenfels.test.jmh.HashMain.main(HashMain.java:Unknown line) The test runs 1s without and 40s with profiler. That does tell all IMHO. Gruss Bernd Am Thu, 4 Dec 2014 12:09:49 +0800 schrieb Wang Weijun : > Hi All > > I am comparing the difference of SHA-1 and SHA-256. First I wrote a > JMH benchmark: > > @Benchmark > public void sig1(Blackhole bh) throws Exception { > bh.consume(sig("SHA-1")); > } > > @Benchmark > public void sig2(Blackhole bh) throws Exception { > bh.consume(sig("SHA-256")); > } > > byte[] sig(String alg) throws Exception { > MessageDigest md = MessageDigest.getInstance(alg); > md.update(new byte[10000]); > return md.digest(); > } > > The output is > > Benchmark Mode Samples Score Error Units > o.o.b.Weird.sig1 thrpt 5 20984.435 ? 3356.455 ops/s > o.o.b.Weird.sig2 thrpt 5 13130.330 ? 976.824 ops/s > > so the difference is there but not huge. > > Then I wrote a simple app with > > public static void main(String args[]) throws Exception { > int i = Arrays.hashCode(sig("SHA-1")); > i += Arrays.hashCode(sig("SHA-256")); > System.out.println(i); > } > > static byte[] sig(String alg) throws Exception { > MessageDigest md = MessageDigest.getInstance(alg); > md.update(new byte[10000]); > return md.digest(); > } > > and then profile it with -agentlib:hprof=cpu=times, and get > > SHA2 1 10.16% 10.16% 156 303276 > sun.security.provider.SHA2.implCompress SHA2 2 6.91% 17.07% > 9984 303274 sun.security.provider.SHA2.lf_sigma0 SHA2 3 5.28% > 22.36% 9984 303271 sun.security.provider.SHA2.lf_sigma1 SHA2 4 > 4.61% 26.96% 7488 303269 sun.security.provider.SHA2.lf_delta0 > SHA2 5 4.20% 31.17% 29952 303273 > sun.security.provider.SHA2.lf_S SHA2 7 3.79% 39.16% 7488 > 303266 sun.security.provider.SHA2.lf_delta1 SHA2 9 2.85% 44.99% > 29952 303270 sun.security.provider.SHA2.lf_S SHA2 13 1.90% > 54.47% 14976 303267 sun.security.provider.SHA2.lf_S SHA2 17 > 1.49% 61.25% 14976 303264 sun.security.provider.SHA2.lf_S SHA2 > 22 0.81% 66.12% 7488 303265 sun.security.provider.SHA2.lf_R > SHA2 23 0.81% 66.94% 9984 303275 > sun.security.provider.SHA2.lf_maj SHA2 25 0.81% 68.56% 156 > 303263 sun.security.provider.ByteArrayAccess.b2iBig64 SHA2 27 > 0.68% 70.05% 9984 303272 sun.security.provider.SHA2.lf_ch SHA2 > 31 0.54% 72.63% 7488 303268 sun.security.provider.SHA2.lf_R > SHA1 34 0.54% 74.25% 156 303224 > sun.security.provider.SHA.implCompress SHA1 43 0.41% 78.05% > 156 303223 sun.security.provider.ByteArrayAccess.b2iBig64 SHA2 60 > 0.27% 82.66% 2496 303262 java.lang.Integer.reverseBytes SHA2 61 > 0.27% 82.93% 64 303290 sun.security.provider.SHA2.lf_sigma1 > SHA1 116 0.14% 91.06% 2496 303222 java.lang.Integer.reverseBytes > > These are calls with SHA (i.e. SHA1) or SHA2 in the stack (depth=4), > and time for SHA2 vs SHA1 is 45.38% vs 1.09%. With such a small app I > don't think SHA or SHA2 is called anywhere else. This is jdk9 b40. > > Why is the output so different from JMH? Is it reasonable comparing > them? > > Thanks > Max > From zaiyao.liu at oracle.com Thu Dec 4 08:22:40 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Thu, 04 Dec 2014 16:22:40 +0800 Subject: RFR 8048619: Implement tests for converting PKCS12 keystores In-Reply-To: <08E2DBF1-690B-42B9-A732-30880BBD21D6@oracle.com> References: <5403CDE6.6070006@oracle.com> <541B9D20.3030006@oracle.com> <327859DE-91C4-4EE6-B16E-CDD715FCD318@oracle.com> <541FD9BF.3090206@oracle.com> <65393CFA-9AA6-4969-9291-165937EF7415@oracle.com> <54211C5F.3080409@oracle.com> <547E74D7.5040201@oracle.com> <08E2DBF1-690B-42B9-A732-30880BBD21D6@oracle.com> Message-ID: <548019D0.8080708@oracle.com> Hi Max, Please help to check again: http://cr.openjdk.java.net/~rhalade/8048619/webrev.04/ Also please help to push it if ok: Full comments: 8048619: Implement tests for converting PKCS12 keystores Reviewed-by: weijun Contributed-by: Zaiyao Liu Thanks and Regards. Kevin ? 2014/12/3 15:37, Wang Weijun ??: > Looks fine. > > One nit, line 231, remove "Certs don't match ". > > Thanks > Max > >> On Dec 3, 2014, at 10:26, zaiyao liu wrote: >> >> Hi Max, >> >> Please help to review the update: >> http://cr.openjdk.java.net/~rhalade/8048619/webrev.02/ >> >> Thanks >> Kevin >> ? 2014/9/23 15:08, zaiyao liu ??: >>> Hi Max, >>> >>> Please help to check this update:http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/ >>> >>> Thanks >>> >>> Kevin >>> ? 2014/9/22 17:10, Wang Weijun ??: >>>> On Sep 22, 2014, at 16:11, zaiyao liu wrote: >>>> >>>>> Hi Max, >>>>> >>>>> Thanks for review. please review the update: http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/, I will ask Rajan to create open webrev link after you passed. >>>> 194 if (a.size() != b.size()) { >>>> >>>> How about "if (a.size() != 1 || b.size() != 1)"? >>>> >>>> 239-250 >>>> >>>> This can be as simple as Arrays.equals(certsA, certsB). >>>> >>>> I would still like a single compareKeyStore() no matter what the size of the keystore is. >>>> >>>> --Max >>>> >>>>> Thanks >>>>> >>>>> Kevin >>>>> ? 2014/9/19 15:34, Wang Weijun ??: >>>>>> In compareCerts(), you should not compare Certificate.toString(), its equals() method is more reliable. There is no need to define compareKeys() and compareCerts(). Instead, you should try not to repeat lines 223-231 on 252-260. >>>>>> >>>>>> The two calls on lines 204 and 205 have keystore names exchanged but keypass order is the same. Also, with two calls it means the comparisons of keys and certs are duplicated. The else block on line 206 looks strange. Do you mean the size is always 1 here? If so, check it. Otherwise, there is no guarantee the aliases appear in the same order. >>>>>> >>>>>> I would be glad to see a generalized comparison method no matter what the keystore size is. >>>>>> >>>>>> Minor issues: >>>>>> >>>>>> It will be clear if you divide the constant strings at the beginning into 2 parts, one for provider names, and one for algorithms. >>>>>> >>>>>> Line 143 and 145, there should be spaces around the testCase name. >>>>>> >>>>>> --Max >>>>>> >>>>>> On Sep 19, 2014, at 11:04, zaiyao liu wrote: >>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> Can you help to review it? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Kevin >>>>>>> ? 2014/9/1 13:25, Wang Weijun ??: >>>>>>>> On vacation now. Can you look for someone else? I will be back in Sep 17 if you are not in a hurry. >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>> On Sep 1, 2014, at 9:37, zaiyao liu wrote: >>>>>>>> >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> Please review the code change,the purpose of this fix is implement tests that convert PKCS12 keystores to other formats. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048619/webrev01/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048619 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Kevin From xuelei.fan at oracle.com Thu Dec 4 11:57:58 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Dec 2014 19:57:58 +0800 Subject: Is it reasonable to compare outputs between JMH and hprof? In-Reply-To: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> References: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> Message-ID: <54804C46.4080505@oracle.com> > These are calls with SHA (i.e. SHA1) or SHA2 in the stack > (depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%. Where is the other 98.91% cost for SHA1? You only call message digest in the test, instinctively, shall most of the resources are cost by the message digest, directly or indirectly? Xuelei On 12/4/2014 12:09 PM, Wang Weijun wrote: > Hi All > > I am comparing the difference of SHA-1 and SHA-256. First I wrote a JMH benchmark: > > @Benchmark > public void sig1(Blackhole bh) throws Exception { > bh.consume(sig("SHA-1")); > } > > @Benchmark > public void sig2(Blackhole bh) throws Exception { > bh.consume(sig("SHA-256")); > } > > byte[] sig(String alg) throws Exception { > MessageDigest md = MessageDigest.getInstance(alg); > md.update(new byte[10000]); > return md.digest(); > } > > The output is > > Benchmark Mode Samples Score Error Units > o.o.b.Weird.sig1 thrpt 5 20984.435 ? 3356.455 ops/s > o.o.b.Weird.sig2 thrpt 5 13130.330 ? 976.824 ops/s > > so the difference is there but not huge. > > Then I wrote a simple app with > > public static void main(String args[]) throws Exception { > int i = Arrays.hashCode(sig("SHA-1")); > i += Arrays.hashCode(sig("SHA-256")); > System.out.println(i); > } > > static byte[] sig(String alg) throws Exception { > MessageDigest md = MessageDigest.getInstance(alg); > md.update(new byte[10000]); > return md.digest(); > } > > and then profile it with -agentlib:hprof=cpu=times, and get > > SHA2 1 10.16% 10.16% 156 303276 sun.security.provider.SHA2.implCompress > SHA2 2 6.91% 17.07% 9984 303274 sun.security.provider.SHA2.lf_sigma0 > SHA2 3 5.28% 22.36% 9984 303271 sun.security.provider.SHA2.lf_sigma1 > SHA2 4 4.61% 26.96% 7488 303269 sun.security.provider.SHA2.lf_delta0 > SHA2 5 4.20% 31.17% 29952 303273 sun.security.provider.SHA2.lf_S > SHA2 7 3.79% 39.16% 7488 303266 sun.security.provider.SHA2.lf_delta1 > SHA2 9 2.85% 44.99% 29952 303270 sun.security.provider.SHA2.lf_S > SHA2 13 1.90% 54.47% 14976 303267 sun.security.provider.SHA2.lf_S > SHA2 17 1.49% 61.25% 14976 303264 sun.security.provider.SHA2.lf_S > SHA2 22 0.81% 66.12% 7488 303265 sun.security.provider.SHA2.lf_R > SHA2 23 0.81% 66.94% 9984 303275 sun.security.provider.SHA2.lf_maj > SHA2 25 0.81% 68.56% 156 303263 sun.security.provider.ByteArrayAccess.b2iBig64 > SHA2 27 0.68% 70.05% 9984 303272 sun.security.provider.SHA2.lf_ch > SHA2 31 0.54% 72.63% 7488 303268 sun.security.provider.SHA2.lf_R > SHA1 34 0.54% 74.25% 156 303224 sun.security.provider.SHA.implCompress > SHA1 43 0.41% 78.05% 156 303223 sun.security.provider.ByteArrayAccess.b2iBig64 > SHA2 60 0.27% 82.66% 2496 303262 java.lang.Integer.reverseBytes > SHA2 61 0.27% 82.93% 64 303290 sun.security.provider.SHA2.lf_sigma1 > SHA1 116 0.14% 91.06% 2496 303222 java.lang.Integer.reverseBytes > > These are calls with SHA (i.e. SHA1) or SHA2 in the stack (depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%. With such a small app I don't think SHA or SHA2 is called anywhere else. This is jdk9 b40. > > Why is the output so different from JMH? Is it reasonable comparing them? > > Thanks > Max > From weijun.wang at oracle.com Thu Dec 4 12:20:37 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Dec 2014 20:20:37 +0800 Subject: Is it reasonable to compare outputs between JMH and hprof? In-Reply-To: <54804C46.4080505@oracle.com> References: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> <54804C46.4080505@oracle.com> Message-ID: <54805195.1060304@oracle.com> On 12/4/2014 19:57, Xuelei Fan wrote: >> These are calls with SHA (i.e. SHA1) or SHA2 in the stack >> (depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%. > > Where is the other 98.91% cost for SHA1? You only call message digest > in the test, instinctively, shall most of the resources are cost by the > message digest, directly or indirectly? The program call SHA2 and SHA1, they together spend 46% of time. The other 54% is spent on file reading, unzip, char/string manipulation etc. --Max > > Xuelei > > > On 12/4/2014 12:09 PM, Wang Weijun wrote: >> Hi All >> >> I am comparing the difference of SHA-1 and SHA-256. First I wrote a JMH benchmark: >> >> @Benchmark >> public void sig1(Blackhole bh) throws Exception { >> bh.consume(sig("SHA-1")); >> } >> >> @Benchmark >> public void sig2(Blackhole bh) throws Exception { >> bh.consume(sig("SHA-256")); >> } >> >> byte[] sig(String alg) throws Exception { >> MessageDigest md = MessageDigest.getInstance(alg); >> md.update(new byte[10000]); >> return md.digest(); >> } >> >> The output is >> >> Benchmark Mode Samples Score Error Units >> o.o.b.Weird.sig1 thrpt 5 20984.435 ? 3356.455 ops/s >> o.o.b.Weird.sig2 thrpt 5 13130.330 ? 976.824 ops/s >> >> so the difference is there but not huge. >> >> Then I wrote a simple app with >> >> public static void main(String args[]) throws Exception { >> int i = Arrays.hashCode(sig("SHA-1")); >> i += Arrays.hashCode(sig("SHA-256")); >> System.out.println(i); >> } >> >> static byte[] sig(String alg) throws Exception { >> MessageDigest md = MessageDigest.getInstance(alg); >> md.update(new byte[10000]); >> return md.digest(); >> } >> >> and then profile it with -agentlib:hprof=cpu=times, and get >> >> SHA2 1 10.16% 10.16% 156 303276 sun.security.provider.SHA2.implCompress >> SHA2 2 6.91% 17.07% 9984 303274 sun.security.provider.SHA2.lf_sigma0 >> SHA2 3 5.28% 22.36% 9984 303271 sun.security.provider.SHA2.lf_sigma1 >> SHA2 4 4.61% 26.96% 7488 303269 sun.security.provider.SHA2.lf_delta0 >> SHA2 5 4.20% 31.17% 29952 303273 sun.security.provider.SHA2.lf_S >> SHA2 7 3.79% 39.16% 7488 303266 sun.security.provider.SHA2.lf_delta1 >> SHA2 9 2.85% 44.99% 29952 303270 sun.security.provider.SHA2.lf_S >> SHA2 13 1.90% 54.47% 14976 303267 sun.security.provider.SHA2.lf_S >> SHA2 17 1.49% 61.25% 14976 303264 sun.security.provider.SHA2.lf_S >> SHA2 22 0.81% 66.12% 7488 303265 sun.security.provider.SHA2.lf_R >> SHA2 23 0.81% 66.94% 9984 303275 sun.security.provider.SHA2.lf_maj >> SHA2 25 0.81% 68.56% 156 303263 sun.security.provider.ByteArrayAccess.b2iBig64 >> SHA2 27 0.68% 70.05% 9984 303272 sun.security.provider.SHA2.lf_ch >> SHA2 31 0.54% 72.63% 7488 303268 sun.security.provider.SHA2.lf_R >> SHA1 34 0.54% 74.25% 156 303224 sun.security.provider.SHA.implCompress >> SHA1 43 0.41% 78.05% 156 303223 sun.security.provider.ByteArrayAccess.b2iBig64 >> SHA2 60 0.27% 82.66% 2496 303262 java.lang.Integer.reverseBytes >> SHA2 61 0.27% 82.93% 64 303290 sun.security.provider.SHA2.lf_sigma1 >> SHA1 116 0.14% 91.06% 2496 303222 java.lang.Integer.reverseBytes >> >> These are calls with SHA (i.e. SHA1) or SHA2 in the stack (depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%. With such a small app I don't think SHA or SHA2 is called anywhere else. This is jdk9 b40. >> >> Why is the output so different from JMH? Is it reasonable comparing them? >> >> Thanks >> Max >> > From xuelei.fan at oracle.com Thu Dec 4 12:40:24 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 04 Dec 2014 20:40:24 +0800 Subject: Is it reasonable to compare outputs between JMH and hprof? In-Reply-To: <54805195.1060304@oracle.com> References: <0823DBD6-4049-4BA3-8219-13FF72427805@oracle.com> <54804C46.4080505@oracle.com> <54805195.1060304@oracle.com> Message-ID: <54805638.5050008@oracle.com> On 12/4/2014 8:20 PM, Weijun Wang wrote: > > > On 12/4/2014 19:57, Xuelei Fan wrote: >>> These are calls with SHA (i.e. SHA1) or SHA2 in the stack >>> (depth=4), and time for SHA2 vs SHA1 is 45.38% vs 1.09%. >> >> Where is the other 98.91% cost for SHA1? You only call message digest >> in the test, instinctively, shall most of the resources are cost by the >> message digest, directly or indirectly? > > The program call SHA2 and SHA1, they together spend 46% of time. > Oh, I see. > The other 54% is spent on file reading, unzip, char/string manipulation > etc. > Hm, should some of the 54% be actually counted for SHA-1? Maybe you can dump more stack depth, and look at whether car/string/etc manipulation are actually called by SHA-1. Xuelei > --Max > >> >> Xuelei >> >> >> On 12/4/2014 12:09 PM, Wang Weijun wrote: >>> Hi All >>> >>> I am comparing the difference of SHA-1 and SHA-256. First I wrote a >>> JMH benchmark: >>> >>> @Benchmark >>> public void sig1(Blackhole bh) throws Exception { >>> bh.consume(sig("SHA-1")); >>> } >>> >>> @Benchmark >>> public void sig2(Blackhole bh) throws Exception { >>> bh.consume(sig("SHA-256")); >>> } >>> >>> byte[] sig(String alg) throws Exception { >>> MessageDigest md = MessageDigest.getInstance(alg); >>> md.update(new byte[10000]); >>> return md.digest(); >>> } >>> >>> The output is >>> >>> Benchmark Mode Samples Score Error Units >>> o.o.b.Weird.sig1 thrpt 5 20984.435 ? 3356.455 ops/s >>> o.o.b.Weird.sig2 thrpt 5 13130.330 ? 976.824 ops/s >>> >>> so the difference is there but not huge. >>> >>> Then I wrote a simple app with >>> >>> public static void main(String args[]) throws Exception { >>> int i = Arrays.hashCode(sig("SHA-1")); >>> i += Arrays.hashCode(sig("SHA-256")); >>> System.out.println(i); >>> } >>> >>> static byte[] sig(String alg) throws Exception { >>> MessageDigest md = MessageDigest.getInstance(alg); >>> md.update(new byte[10000]); >>> return md.digest(); >>> } >>> >>> and then profile it with -agentlib:hprof=cpu=times, and get >>> >>> SHA2 1 10.16% 10.16% 156 303276 >>> sun.security.provider.SHA2.implCompress >>> SHA2 2 6.91% 17.07% 9984 303274 >>> sun.security.provider.SHA2.lf_sigma0 >>> SHA2 3 5.28% 22.36% 9984 303271 >>> sun.security.provider.SHA2.lf_sigma1 >>> SHA2 4 4.61% 26.96% 7488 303269 >>> sun.security.provider.SHA2.lf_delta0 >>> SHA2 5 4.20% 31.17% 29952 303273 sun.security.provider.SHA2.lf_S >>> SHA2 7 3.79% 39.16% 7488 303266 >>> sun.security.provider.SHA2.lf_delta1 >>> SHA2 9 2.85% 44.99% 29952 303270 sun.security.provider.SHA2.lf_S >>> SHA2 13 1.90% 54.47% 14976 303267 sun.security.provider.SHA2.lf_S >>> SHA2 17 1.49% 61.25% 14976 303264 sun.security.provider.SHA2.lf_S >>> SHA2 22 0.81% 66.12% 7488 303265 sun.security.provider.SHA2.lf_R >>> SHA2 23 0.81% 66.94% 9984 303275 sun.security.provider.SHA2.lf_maj >>> SHA2 25 0.81% 68.56% 156 303263 >>> sun.security.provider.ByteArrayAccess.b2iBig64 >>> SHA2 27 0.68% 70.05% 9984 303272 sun.security.provider.SHA2.lf_ch >>> SHA2 31 0.54% 72.63% 7488 303268 sun.security.provider.SHA2.lf_R >>> SHA1 34 0.54% 74.25% 156 303224 >>> sun.security.provider.SHA.implCompress >>> SHA1 43 0.41% 78.05% 156 303223 >>> sun.security.provider.ByteArrayAccess.b2iBig64 >>> SHA2 60 0.27% 82.66% 2496 303262 java.lang.Integer.reverseBytes >>> SHA2 61 0.27% 82.93% 64 303290 >>> sun.security.provider.SHA2.lf_sigma1 >>> SHA1 116 0.14% 91.06% 2496 303222 java.lang.Integer.reverseBytes >>> >>> These are calls with SHA (i.e. SHA1) or SHA2 in the stack (depth=4), >>> and time for SHA2 vs SHA1 is 45.38% vs 1.09%. With such a small app I >>> don't think SHA or SHA2 is called anywhere else. This is jdk9 b40. >>> >>> Why is the output so different from JMH? Is it reasonable comparing >>> them? >>> >>> Thanks >>> Max >>> >> From joe.darcy at oracle.com Thu Dec 4 23:41:53 2014 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 04 Dec 2014 15:41:53 -0800 Subject: JDK 9 RFR of JDK-8066638: Suppress deprecation warnings in jdk.crypto module Message-ID: <5480F141.5060608@oracle.com> Hello, Please review my changes to fix JDK-8066638: Suppress deprecation warnings in jdk.crypto module http://cr.openjdk.java.net/~darcy/8066638.0/ Patch inline below. (Background effort on the overall deprecation suppression effort written up at http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html) Thanks, -Joe --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java 2014-12-04 15:39:05.353994901 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java 2014-12-04 15:39:05.170086892 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -445,6 +445,7 @@ } } + @SuppressWarnings("deprecation") private static class P11TlsMasterSecretKey extends P11SecretKey implements TlsMasterSecret { private static final long serialVersionUID = -1318560923770573441L; --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java 2014-12-04 15:39:05.865738926 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java 2014-12-04 15:39:05.685828917 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -169,6 +169,7 @@ } // see JCE spec + @SuppressWarnings("deprecation") protected void engineInit(int opmode, Key key, AlgorithmParameterSpec params, SecureRandom random) throws InvalidKeyException, InvalidAlgorithmParameterException { @@ -461,6 +462,7 @@ } // see JCE spec + @SuppressWarnings("deprecation") protected Key engineUnwrap(byte[] wrappedKey, String algorithm, int type) throws InvalidKeyException, NoSuchAlgorithmException { --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java 2014-12-04 15:39:06.429456952 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java 2014-12-04 15:39:06.221560942 -0800 @@ -765,12 +765,14 @@ } // see JCA spec + @SuppressWarnings("deprecation") protected void engineSetParameter(String param, Object value) throws InvalidParameterException { throw new UnsupportedOperationException("setParameter() not supported"); } // see JCA spec + @SuppressWarnings("deprecation") protected Object engineGetParameter(String param) throws InvalidParameterException { throw new UnsupportedOperationException("getParameter() not supported"); --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java 2014-12-04 15:39:06.989176978 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java 2014-12-04 15:39:06.777282969 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -62,6 +62,7 @@ private long mechanism; // parameter spec + @SuppressWarnings("deprecation") private TlsKeyMaterialParameterSpec spec; // master secret as a P11Key @@ -82,6 +83,7 @@ throw new InvalidParameterException(MSG); } + @SuppressWarnings("deprecation") protected void engineInit(AlgorithmParameterSpec params, SecureRandom random) throws InvalidAlgorithmParameterException { if (params instanceof TlsKeyMaterialParameterSpec == false) { @@ -107,6 +109,7 @@ throw new InvalidParameterException(MSG); } + @SuppressWarnings("deprecation") protected SecretKey engineGenerateKey() { if (spec == null) { throw new IllegalStateException --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java 2014-12-04 15:39:07.540901004 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java 2014-12-04 15:39:07.337002994 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -57,6 +57,7 @@ // mechanism id private long mechanism; + @SuppressWarnings("deprecation") private TlsMasterSecretParameterSpec spec; private P11Key p11Key; @@ -74,6 +75,7 @@ throw new InvalidParameterException(MSG); } + @SuppressWarnings("deprecation") protected void engineInit(AlgorithmParameterSpec params, SecureRandom random) throws InvalidAlgorithmParameterException { if (params instanceof TlsMasterSecretParameterSpec == false) { --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java 2014-12-04 15:39:08.068637029 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java 2014-12-04 15:39:07.848747019 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -63,6 +63,7 @@ // mechanism id private final long mechanism; + @SuppressWarnings("deprecation") private TlsPrfParameterSpec spec; private P11Key p11Key; @@ -79,6 +80,7 @@ throw new InvalidParameterException(MSG); } + @SuppressWarnings("deprecation") protected void engineInit(AlgorithmParameterSpec params, SecureRandom random) throws InvalidAlgorithmParameterException { if (params instanceof TlsPrfParameterSpec == false) { --- old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java 2014-12-04 15:39:08.672335057 -0800 +++ new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java 2014-12-04 15:39:08.480431048 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -57,6 +57,7 @@ // mechanism id private long mechanism; + @SuppressWarnings("deprecation") private TlsRsaPremasterSecretParameterSpec spec; P11TlsRsaPremasterSecretGenerator(Token token, String algorithm, long mechanism) @@ -71,6 +72,7 @@ throw new InvalidParameterException(MSG); } + @SuppressWarnings("deprecation") protected void engineInit(AlgorithmParameterSpec params, SecureRandom random) throws InvalidAlgorithmParameterException { if (!(params instanceof TlsRsaPremasterSecretParameterSpec)) { From bradford.wetmore at oracle.com Fri Dec 5 00:07:24 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 04 Dec 2014 16:07:24 -0800 Subject: JDK 9 RFR of JDK-8066638: Suppress deprecation warnings in jdk.crypto module In-Reply-To: <5480F141.5060608@oracle.com> References: <5480F141.5060608@oracle.com> Message-ID: <5480F73C.3010704@oracle.com> Joe, This looks good to me, but Valerie (PKCS11 owner) and Xuelei (TLS owner) should also have a look at this. Brad On 12/4/2014 3:41 PM, joe darcy wrote: > Hello, > > Please review my changes to fix > > JDK-8066638: Suppress deprecation warnings in jdk.crypto module > http://cr.openjdk.java.net/~darcy/8066638.0/ > > Patch inline below. > > (Background effort on the overall deprecation suppression effort written > up at > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html) > > > Thanks, > > -Joe > > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java > 2014-12-04 15:39:05.353994901 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java > 2014-12-04 15:39:05.170086892 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -445,6 +445,7 @@ > } > } > > + @SuppressWarnings("deprecation") > private static class P11TlsMasterSecretKey extends P11SecretKey > implements TlsMasterSecret { > private static final long serialVersionUID = > -1318560923770573441L; > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java > 2014-12-04 15:39:05.865738926 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java > 2014-12-04 15:39:05.685828917 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -169,6 +169,7 @@ > } > > // see JCE spec > + @SuppressWarnings("deprecation") > protected void engineInit(int opmode, Key key, > AlgorithmParameterSpec params, SecureRandom random) > throws InvalidKeyException, > InvalidAlgorithmParameterException { > @@ -461,6 +462,7 @@ > } > > // see JCE spec > + @SuppressWarnings("deprecation") > protected Key engineUnwrap(byte[] wrappedKey, String algorithm, > int type) throws InvalidKeyException, > NoSuchAlgorithmException { > > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java > 2014-12-04 15:39:06.429456952 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java > 2014-12-04 15:39:06.221560942 -0800 > @@ -765,12 +765,14 @@ > } > > // see JCA spec > + @SuppressWarnings("deprecation") > protected void engineSetParameter(String param, Object value) > throws InvalidParameterException { > throw new UnsupportedOperationException("setParameter() not > supported"); > } > > // see JCA spec > + @SuppressWarnings("deprecation") > protected Object engineGetParameter(String param) > throws InvalidParameterException { > throw new UnsupportedOperationException("getParameter() not > supported"); > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java > 2014-12-04 15:39:06.989176978 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java > 2014-12-04 15:39:06.777282969 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -62,6 +62,7 @@ > private long mechanism; > > // parameter spec > + @SuppressWarnings("deprecation") > private TlsKeyMaterialParameterSpec spec; > > // master secret as a P11Key > @@ -82,6 +83,7 @@ > throw new InvalidParameterException(MSG); > } > > + @SuppressWarnings("deprecation") > protected void engineInit(AlgorithmParameterSpec params, > SecureRandom random) throws > InvalidAlgorithmParameterException { > if (params instanceof TlsKeyMaterialParameterSpec == false) { > @@ -107,6 +109,7 @@ > throw new InvalidParameterException(MSG); > } > > + @SuppressWarnings("deprecation") > protected SecretKey engineGenerateKey() { > if (spec == null) { > throw new IllegalStateException > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java > 2014-12-04 15:39:07.540901004 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java > 2014-12-04 15:39:07.337002994 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -57,6 +57,7 @@ > // mechanism id > private long mechanism; > > + @SuppressWarnings("deprecation") > private TlsMasterSecretParameterSpec spec; > private P11Key p11Key; > > @@ -74,6 +75,7 @@ > throw new InvalidParameterException(MSG); > } > > + @SuppressWarnings("deprecation") > protected void engineInit(AlgorithmParameterSpec params, > SecureRandom random) throws > InvalidAlgorithmParameterException { > if (params instanceof TlsMasterSecretParameterSpec == false) { > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java > 2014-12-04 15:39:08.068637029 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java > 2014-12-04 15:39:07.848747019 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -63,6 +63,7 @@ > // mechanism id > private final long mechanism; > > + @SuppressWarnings("deprecation") > private TlsPrfParameterSpec spec; > > private P11Key p11Key; > @@ -79,6 +80,7 @@ > throw new InvalidParameterException(MSG); > } > > + @SuppressWarnings("deprecation") > protected void engineInit(AlgorithmParameterSpec params, > SecureRandom random) throws > InvalidAlgorithmParameterException { > if (params instanceof TlsPrfParameterSpec == false) { > --- > old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java > 2014-12-04 15:39:08.672335057 -0800 > +++ > new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java > 2014-12-04 15:39:08.480431048 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -57,6 +57,7 @@ > // mechanism id > private long mechanism; > > + @SuppressWarnings("deprecation") > private TlsRsaPremasterSecretParameterSpec spec; > > P11TlsRsaPremasterSecretGenerator(Token token, String algorithm, > long mechanism) > @@ -71,6 +72,7 @@ > throw new InvalidParameterException(MSG); > } > > + @SuppressWarnings("deprecation") > protected void engineInit(AlgorithmParameterSpec params, > SecureRandom random) throws > InvalidAlgorithmParameterException { > if (!(params instanceof TlsRsaPremasterSecretParameterSpec)) { > From xuelei.fan at oracle.com Fri Dec 5 00:10:01 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 05 Dec 2014 08:10:01 +0800 Subject: JDK 9 RFR of JDK-8066638: Suppress deprecation warnings in jdk.crypto module In-Reply-To: <5480F73C.3010704@oracle.com> References: <5480F141.5060608@oracle.com> <5480F73C.3010704@oracle.com> Message-ID: <5480F7D9.5030605@oracle.com> Looks fine to me, too. Thanks, Xuelei On 12/5/2014 8:07 AM, Bradford Wetmore wrote: > Joe, > > This looks good to me, but Valerie (PKCS11 owner) and Xuelei (TLS owner) > should also have a look at this. > > Brad > > > > On 12/4/2014 3:41 PM, joe darcy wrote: >> Hello, >> >> Please review my changes to fix >> >> JDK-8066638: Suppress deprecation warnings in jdk.crypto module >> http://cr.openjdk.java.net/~darcy/8066638.0/ >> >> Patch inline below. >> >> (Background effort on the overall deprecation suppression effort written >> up at >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html) >> >> >> >> Thanks, >> >> -Joe >> >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java >> 2014-12-04 15:39:05.353994901 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java >> 2014-12-04 15:39:05.170086892 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -445,6 +445,7 @@ >> } >> } >> >> + @SuppressWarnings("deprecation") >> private static class P11TlsMasterSecretKey extends P11SecretKey >> implements TlsMasterSecret { >> private static final long serialVersionUID = >> -1318560923770573441L; >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java >> >> 2014-12-04 15:39:05.865738926 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java >> >> 2014-12-04 15:39:05.685828917 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -169,6 +169,7 @@ >> } >> >> // see JCE spec >> + @SuppressWarnings("deprecation") >> protected void engineInit(int opmode, Key key, >> AlgorithmParameterSpec params, SecureRandom random) >> throws InvalidKeyException, >> InvalidAlgorithmParameterException { >> @@ -461,6 +462,7 @@ >> } >> >> // see JCE spec >> + @SuppressWarnings("deprecation") >> protected Key engineUnwrap(byte[] wrappedKey, String algorithm, >> int type) throws InvalidKeyException, >> NoSuchAlgorithmException { >> >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java >> >> 2014-12-04 15:39:06.429456952 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java >> >> 2014-12-04 15:39:06.221560942 -0800 >> @@ -765,12 +765,14 @@ >> } >> >> // see JCA spec >> + @SuppressWarnings("deprecation") >> protected void engineSetParameter(String param, Object value) >> throws InvalidParameterException { >> throw new UnsupportedOperationException("setParameter() not >> supported"); >> } >> >> // see JCA spec >> + @SuppressWarnings("deprecation") >> protected Object engineGetParameter(String param) >> throws InvalidParameterException { >> throw new UnsupportedOperationException("getParameter() not >> supported"); >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java >> >> 2014-12-04 15:39:06.989176978 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java >> >> 2014-12-04 15:39:06.777282969 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -62,6 +62,7 @@ >> private long mechanism; >> >> // parameter spec >> + @SuppressWarnings("deprecation") >> private TlsKeyMaterialParameterSpec spec; >> >> // master secret as a P11Key >> @@ -82,6 +83,7 @@ >> throw new InvalidParameterException(MSG); >> } >> >> + @SuppressWarnings("deprecation") >> protected void engineInit(AlgorithmParameterSpec params, >> SecureRandom random) throws >> InvalidAlgorithmParameterException { >> if (params instanceof TlsKeyMaterialParameterSpec == false) { >> @@ -107,6 +109,7 @@ >> throw new InvalidParameterException(MSG); >> } >> >> + @SuppressWarnings("deprecation") >> protected SecretKey engineGenerateKey() { >> if (spec == null) { >> throw new IllegalStateException >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java >> >> 2014-12-04 15:39:07.540901004 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java >> >> 2014-12-04 15:39:07.337002994 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2007, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -57,6 +57,7 @@ >> // mechanism id >> private long mechanism; >> >> + @SuppressWarnings("deprecation") >> private TlsMasterSecretParameterSpec spec; >> private P11Key p11Key; >> >> @@ -74,6 +75,7 @@ >> throw new InvalidParameterException(MSG); >> } >> >> + @SuppressWarnings("deprecation") >> protected void engineInit(AlgorithmParameterSpec params, >> SecureRandom random) throws >> InvalidAlgorithmParameterException { >> if (params instanceof TlsMasterSecretParameterSpec == false) { >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java >> >> 2014-12-04 15:39:08.068637029 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java >> >> 2014-12-04 15:39:07.848747019 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -63,6 +63,7 @@ >> // mechanism id >> private final long mechanism; >> >> + @SuppressWarnings("deprecation") >> private TlsPrfParameterSpec spec; >> >> private P11Key p11Key; >> @@ -79,6 +80,7 @@ >> throw new InvalidParameterException(MSG); >> } >> >> + @SuppressWarnings("deprecation") >> protected void engineInit(AlgorithmParameterSpec params, >> SecureRandom random) throws >> InvalidAlgorithmParameterException { >> if (params instanceof TlsPrfParameterSpec == false) { >> --- >> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java >> >> 2014-12-04 15:39:08.672335057 -0800 >> +++ >> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java >> >> 2014-12-04 15:39:08.480431048 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -57,6 +57,7 @@ >> // mechanism id >> private long mechanism; >> >> + @SuppressWarnings("deprecation") >> private TlsRsaPremasterSecretParameterSpec spec; >> >> P11TlsRsaPremasterSecretGenerator(Token token, String algorithm, >> long mechanism) >> @@ -71,6 +72,7 @@ >> throw new InvalidParameterException(MSG); >> } >> >> + @SuppressWarnings("deprecation") >> protected void engineInit(AlgorithmParameterSpec params, >> SecureRandom random) throws >> InvalidAlgorithmParameterException { >> if (!(params instanceof TlsRsaPremasterSecretParameterSpec)) { >> From valerie.peng at oracle.com Fri Dec 5 21:05:54 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 05 Dec 2014 13:05:54 -0800 Subject: JDK 9 RFR of JDK-8066638: Suppress deprecation warnings in jdk.crypto module In-Reply-To: <5480F7D9.5030605@oracle.com> References: <5480F141.5060608@oracle.com> <5480F73C.3010704@oracle.com> <5480F7D9.5030605@oracle.com> Message-ID: <54821E32.8010307@oracle.com> Looks fine. Thanks, Valerie On 12/4/2014 4:10 PM, Xuelei Fan wrote: > Looks fine to me, too. > > Thanks, > Xuelei > > On 12/5/2014 8:07 AM, Bradford Wetmore wrote: >> Joe, >> >> This looks good to me, but Valerie (PKCS11 owner) and Xuelei (TLS owner) >> should also have a look at this. >> >> Brad >> >> >> >> On 12/4/2014 3:41 PM, joe darcy wrote: >>> Hello, >>> >>> Please review my changes to fix >>> >>> JDK-8066638: Suppress deprecation warnings in jdk.crypto module >>> http://cr.openjdk.java.net/~darcy/8066638.0/ >>> >>> Patch inline below. >>> >>> (Background effort on the overall deprecation suppression effort written >>> up at >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html) >>> >>> >>> >>> Thanks, >>> >>> -Joe >>> >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java >>> 2014-12-04 15:39:05.353994901 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Key.java >>> 2014-12-04 15:39:05.170086892 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -445,6 +445,7 @@ >>> } >>> } >>> >>> + @SuppressWarnings("deprecation") >>> private static class P11TlsMasterSecretKey extends P11SecretKey >>> implements TlsMasterSecret { >>> private static final long serialVersionUID = >>> -1318560923770573441L; >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java >>> >>> 2014-12-04 15:39:05.865738926 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11RSACipher.java >>> >>> 2014-12-04 15:39:05.685828917 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -169,6 +169,7 @@ >>> } >>> >>> // see JCE spec >>> + @SuppressWarnings("deprecation") >>> protected void engineInit(int opmode, Key key, >>> AlgorithmParameterSpec params, SecureRandom random) >>> throws InvalidKeyException, >>> InvalidAlgorithmParameterException { >>> @@ -461,6 +462,7 @@ >>> } >>> >>> // see JCE spec >>> + @SuppressWarnings("deprecation") >>> protected Key engineUnwrap(byte[] wrappedKey, String algorithm, >>> int type) throws InvalidKeyException, >>> NoSuchAlgorithmException { >>> >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java >>> >>> 2014-12-04 15:39:06.429456952 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Signature.java >>> >>> 2014-12-04 15:39:06.221560942 -0800 >>> @@ -765,12 +765,14 @@ >>> } >>> >>> // see JCA spec >>> + @SuppressWarnings("deprecation") >>> protected void engineSetParameter(String param, Object value) >>> throws InvalidParameterException { >>> throw new UnsupportedOperationException("setParameter() not >>> supported"); >>> } >>> >>> // see JCA spec >>> + @SuppressWarnings("deprecation") >>> protected Object engineGetParameter(String param) >>> throws InvalidParameterException { >>> throw new UnsupportedOperationException("getParameter() not >>> supported"); >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java >>> >>> 2014-12-04 15:39:06.989176978 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java >>> >>> 2014-12-04 15:39:06.777282969 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -62,6 +62,7 @@ >>> private long mechanism; >>> >>> // parameter spec >>> + @SuppressWarnings("deprecation") >>> private TlsKeyMaterialParameterSpec spec; >>> >>> // master secret as a P11Key >>> @@ -82,6 +83,7 @@ >>> throw new InvalidParameterException(MSG); >>> } >>> >>> + @SuppressWarnings("deprecation") >>> protected void engineInit(AlgorithmParameterSpec params, >>> SecureRandom random) throws >>> InvalidAlgorithmParameterException { >>> if (params instanceof TlsKeyMaterialParameterSpec == false) { >>> @@ -107,6 +109,7 @@ >>> throw new InvalidParameterException(MSG); >>> } >>> >>> + @SuppressWarnings("deprecation") >>> protected SecretKey engineGenerateKey() { >>> if (spec == null) { >>> throw new IllegalStateException >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java >>> >>> 2014-12-04 15:39:07.540901004 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java >>> >>> 2014-12-04 15:39:07.337002994 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2005, 2007, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -57,6 +57,7 @@ >>> // mechanism id >>> private long mechanism; >>> >>> + @SuppressWarnings("deprecation") >>> private TlsMasterSecretParameterSpec spec; >>> private P11Key p11Key; >>> >>> @@ -74,6 +75,7 @@ >>> throw new InvalidParameterException(MSG); >>> } >>> >>> + @SuppressWarnings("deprecation") >>> protected void engineInit(AlgorithmParameterSpec params, >>> SecureRandom random) throws >>> InvalidAlgorithmParameterException { >>> if (params instanceof TlsMasterSecretParameterSpec == false) { >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java >>> >>> 2014-12-04 15:39:08.068637029 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java >>> >>> 2014-12-04 15:39:07.848747019 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -63,6 +63,7 @@ >>> // mechanism id >>> private final long mechanism; >>> >>> + @SuppressWarnings("deprecation") >>> private TlsPrfParameterSpec spec; >>> >>> private P11Key p11Key; >>> @@ -79,6 +80,7 @@ >>> throw new InvalidParameterException(MSG); >>> } >>> >>> + @SuppressWarnings("deprecation") >>> protected void engineInit(AlgorithmParameterSpec params, >>> SecureRandom random) throws >>> InvalidAlgorithmParameterException { >>> if (params instanceof TlsPrfParameterSpec == false) { >>> --- >>> old/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java >>> >>> 2014-12-04 15:39:08.672335057 -0800 >>> +++ >>> new/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java >>> >>> 2014-12-04 15:39:08.480431048 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -57,6 +57,7 @@ >>> // mechanism id >>> private long mechanism; >>> >>> + @SuppressWarnings("deprecation") >>> private TlsRsaPremasterSecretParameterSpec spec; >>> >>> P11TlsRsaPremasterSecretGenerator(Token token, String algorithm, >>> long mechanism) >>> @@ -71,6 +72,7 @@ >>> throw new InvalidParameterException(MSG); >>> } >>> >>> + @SuppressWarnings("deprecation") >>> protected void engineInit(AlgorithmParameterSpec params, >>> SecureRandom random) throws >>> InvalidAlgorithmParameterException { >>> if (!(params instanceof TlsRsaPremasterSecretParameterSpec)) { >>> From valerie.peng at oracle.com Fri Dec 5 23:37:54 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 05 Dec 2014 15:37:54 -0800 Subject: Please review CR8048819 Implement reliability test for DH algorithm In-Reply-To: <543B1CD5.8060706@oracle.com> References: <543B1CD5.8060706@oracle.com> Message-ID: <548241D2.5080305@oracle.com> Amanda, Since the test is under the path for SunJCE provider, can you please add the "SunJCE" provider name when calling getInstance()? This would means that you need to update the test to handle NoSuchProviderException, etc. But should be minor changes. Thanks, Valerie On 10/12/2014 5:29 PM, Amanda Jiang wrote: > Hello, > > Please help to review the changeset below, the new test stressful > verifies the assertion of "The secret keys generated by all involved > parties should be the same" for javax.crypto.KeyAgreement. > > Bug - https://bugs.openjdk.java.net/browse/JDK-8048819 > Webrev - http://cr.openjdk.java.net/~tyan/amandaj/8048819/webrev.00/ > > Thanks, > Amanda From zaiyao.liu at oracle.com Mon Dec 8 01:44:07 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Mon, 08 Dec 2014 09:44:07 +0800 Subject: RFR JDK-8049432: Need new tests for testing TLS property jdk.tls.client.protocols with various protocols and values In-Reply-To: <54804187.3090700@oracle.com> References: <540FB78D.2070101@oracle.com> <547EAA93.6040308@oracle.com> <547ECEC2.5000109@oracle.com> <547FF75F.3080501@oracle.com> <54800A4E.1060004@oracle.com> <54801DBC.3070500@oracle.com> <54804187.3090700@oracle.com> Message-ID: <54850267.5060604@oracle.com> Hi Xuelei, Please check the update: http://cr.openjdk.java.net/~rhalade/8049432/webrev.02/ Please help to push it if OK. Full comments: 8049432: Need new tests for testing TLS property jdk.tls.client.protocols with various protocols and values Reviewed-by: xuelei Contributed-by: Zaiyao Liu Thanks and Regards. Kevin ? 2014/12/4 19:12, Xuelei Fan ??: > On 12/4/2014 4:39 PM, zaiyao liu wrote: >> Hi Xuelei, >> >> From the document: >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider >> > Please refer to: > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext > >> The |SunJSSE| provider supports the following |protocol| parameters: >> >> Protocol Enabled by Default for Client Enabled by Default for Server >> SSLv3 Yes Yes >> TLSv1 Yes Yes >> TLSv1.1 Yes Yes >> TLSv1.2 Yes Yes >> SSLv2Hello Footnote 1 >> >> No Yes >> >> >> Also I got following error when set contextProtocol as SSL and TLS: >> Caused by: java.lang.IllegalArgumentException: jdk.tls.client.protocols: >> TLS is not a standard SSL protocol name >> at >> sun.security.ssl.SSLContextImpl$CustomizedSSLContext.(SSLContextImpl.java:615) >> >> What's your suggestion for test the "SSL" and "TLS"? >> > SSLContext protocol name is not SSL/TLS protocol name. Maybe confusing, > but they are two concepts. "SSL" and "TLS" are not SSL/TLS protocols, > they are default SSLContext algorithms. One cannot specify SSLContext > protocol to SSL/TLS protocol. SSLContext.getInstance("SSL") should > work. But "jdk.tls.client.protocols=SSL" will not work. > > Xuelei > > >> Thanks >> >> Kevin >> >> ? 2014/12/4 15:16, Xuelei Fan ??: >>> On 12/4/2014 1:55 PM, zaiyao liu wrote: >>>> Hi Xuelei, >>>> >>>> Thanks for careful review. please check the update: >>>> http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8049432/webrev/ >>>> >>> Looks fine to me. >>> >>>> I am not very clear about "4. Do you want to test the "SSL" and "TLS" >>>> protocol of SSLContext ()?", Can you explain it? >>>> >>> "SSL" and "TLS" are two protocol algorithm for SSLContext. >>> SSLContext.getInstance("SSL"); >>> SSLContext.getInstance("TLS"); >>> >>> Xuelei >>> >>>> Thanks again. >>>> >>>> Kevin >>>> ? 2014/12/3 16:50, Xuelei Fan ??: >>>>> Looks fine to me. Only a few minor comments: >>>>> >>>>> 1. >>>>> 201 String[] expecteSupported_protos = new String[] { >>>>> 202 "SSLv2Hello", "SSLv3", "TLSv1", "TLSv1.1", >>>>> "TLSv1.2" >>>>> 203 }; >>>>> >>>>> This variable can be define as a static class variable: >>>>> public class TLSClientPropertyTest { >>>>> private String[] expecteSupportedProtos = new String[] { >>>>> "SSLv2Hello", "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" >>>>> }; >>>>> } >>>>> >>>>> Per Java coding conversions, better to use "theVariableName" style, >>>>> rather than link with "-" or "_" (expecteSupported_protos vs >>>>> expecteSupportedProtos). >>>>> >>>>> 2. >>>>> 60 String protocol; >>>>> >>>>> I think, in the test, this is used as SSLContext protocol. It would be >>>>> nice if the variable name is instinctive. I may suggest to use >>>>> "contextProtocol". >>>>> >>>>> The same for the "expectedProto" parameter name. >>>>> >>>>> 3. >>>>> 67 expectedDefaultProtos = new String[] { >>>>> 68 "TLSv1.1", "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" >>>>> 69 }; >>>>> >>>>> Is it intend to have duplicated "TLSv1.1"? It's OK to me, but better to >>>>> add a comment about why duplicated protocols are listed here. >>>>> >>>>> 4. >>>>> Do you want to test the "SSL" and "TLS" protocol of SSLContext ()? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 12/3/2014 2:15 PM, zaiyao liu wrote: >>>>>> Hi Xuelei, >>>>>> >>>>>> Can you help to review this code change? >>>>>> >>>>>> Thanks and Regards. >>>>>> >>>>>> Kevin >>>>>> ? 2014/9/10 10:29, zaiyao liu ??: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review the code change,the purpose of this fix is to address >>>>>>> following: >>>>>>> -Sets the property jdk.tls.client.protocols to one of this >>>>>>> protocols:SSLv3,TLSv1,TLSv1,TLSv1.1,TLSv1.2 and TLSV(invalid) or >>>>>>> removes this >>>>>>> property (if any),then validates the default, supported and current >>>>>>> protocols in the SSLContext. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8049432/webrev01/ >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049432 >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Kevin From amanda.jiang at oracle.com Tue Dec 9 23:02:02 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 09 Dec 2014 15:02:02 -0800 Subject: Please review CR8048819 Implement reliability test for DH algorithm In-Reply-To: <548241D2.5080305@oracle.com> References: <543B1CD5.8060706@oracle.com> <548241D2.5080305@oracle.com> Message-ID: <54877F6A.2080206@oracle.com> Hi Valerie, Thanks for your comments, the test case is updated by your suggestions, please check below webrev: http://cr.openjdk.java.net/~tyan/amandaj/8048819/webrev.01/ Thanks, Amanda On 12/5/14 3:37 PM, Valerie Peng wrote: > Amanda, > > Since the test is under the path for SunJCE provider, can you please > add the "SunJCE" provider name when calling getInstance()? This would > means that you need to update the test to handle > NoSuchProviderException, etc. But should be minor changes. > > Thanks, > Valerie > > On 10/12/2014 5:29 PM, Amanda Jiang wrote: >> Hello, >> >> Please help to review the changeset below, the new test stressful >> verifies the assertion of "The secret keys generated by all involved >> parties should be the same" for javax.crypto.KeyAgreement. >> >> Bug - https://bugs.openjdk.java.net/browse/JDK-8048819 >> Webrev - http://cr.openjdk.java.net/~tyan/amandaj/8048819/webrev.00/ >> >> Thanks, >> Amanda From valerie.peng at oracle.com Wed Dec 10 00:41:09 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 09 Dec 2014 16:41:09 -0800 Subject: Please review CR8048819 Implement reliability test for DH algorithm In-Reply-To: <54877F6A.2080206@oracle.com> References: <543B1CD5.8060706@oracle.com> <548241D2.5080305@oracle.com> <54877F6A.2080206@oracle.com> Message-ID: <548796A5.3020600@oracle.com> Looks fine. Thanks, Valerie On 12/9/2014 3:02 PM, Amanda Jiang wrote: > Hi Valerie, > > Thanks for your comments, the test case is updated by your > suggestions, please check below webrev: > http://cr.openjdk.java.net/~tyan/amandaj/8048819/webrev.01/ > > Thanks, > Amanda > > On 12/5/14 3:37 PM, Valerie Peng wrote: >> Amanda, >> >> Since the test is under the path for SunJCE provider, can you please >> add the "SunJCE" provider name when calling getInstance()? This would >> means that you need to update the test to handle >> NoSuchProviderException, etc. But should be minor changes. >> >> Thanks, >> Valerie >> >> On 10/12/2014 5:29 PM, Amanda Jiang wrote: >>> Hello, >>> >>> Please help to review the changeset below, the new test >>> stressful verifies the assertion of "The secret keys generated by >>> all involved parties should be the same" for javax.crypto.KeyAgreement. >>> >>> Bug - https://bugs.openjdk.java.net/browse/JDK-8048819 >>> Webrev - >>> http://cr.openjdk.java.net/~tyan/amandaj/8048819/webrev.00/ >>> >>> Thanks, >>> Amanda > From valerie.peng at oracle.com Thu Dec 11 02:53:53 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Dec 2014 18:53:53 -0800 Subject: [9] RFR 8062170: java.security.ProviderException: Error parsing configuration with space Message-ID: <54890741.2020208@oracle.com> Can someone help reviewing this regression (by 7196009 when adding support for parenthesis in library path in PKCS11 provider config file)? The fix is to change the library path parsing back to using the parseLine() method and then relax the impl inside parseLine() to allow quoted strings. Bug: https://bugs.openjdk.java.net/browse/JDK-8062170 Webrev: http://cr.openjdk.java.net/~valeriep/8062170/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Thu Dec 11 03:20:52 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Dec 2014 19:20:52 -0800 Subject: [9] RFR 8049312: AES/CICO test failed with on several modes In-Reply-To: <53F7AD0D.8050601@oracle.com> References: <53C9A9D8.1060109@oracle.com> <53F7AD0D.8050601@oracle.com> Message-ID: <54890D94.8090003@oracle.com> Still looking for a reviewer for this fix... Thanks, Valerie On 8/22/2014 1:50 PM, Valerie Peng wrote: > Ping again. Anyone has time to review? > > The webrev has been updated in place for > 1) to reflect the new modular path > 2) update of test/ProblemList.txt given the integration of the failed > test (done in a separate bug fix which adds bunch of new tests). > > The main changes are in CipherCore.java to pass the correct data size > when calling cipher.encrypt/decrypt(...). > Also, updated the various modes implementation so that an Exception is > thrown if data with incorrect length are passed. This is to make the > code more robust. > > Thanks, > Valerie > > On 7/18/2014 4:12 PM, Valerie Peng wrote: >> >> Can someone please help reviewing this following fix? >> https://bugs.openjdk.java.net/browse/JDK-8049312 >> Webrev: http://cr.openjdk.java.net/~valeriep/8049312/webrev.00/ >> >> The must-fix change is in || >> src/share/classes/com/sun/crypto/provider/CipherCore.java which is to >> correct the data size calculation based on "unitBytes". For example, >> for CFB24, our current impl assumes the given data will be multiples >> of 3 bytes. When the given data isn't multiples of 3, it will >> continue but then the result is incorrect. >> >> To make the code more robust, I think we should explicitly check and >> error out when the given data doesn't have the correct size. Thus, I >> have added the input-length check to the various mode >> implementations. Along the way, I also fixed javadoc typos, removed >> redundancies, etc. >> >> Thanks, >> Valerie >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Thu Dec 11 10:17:20 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 11 Dec 2014 13:17:20 +0300 Subject: RFR: 8048603: Additional tests for MAC algorithms In-Reply-To: <545C99D6.2090200@oracle.com> References: <545C99D6.2090200@oracle.com> Message-ID: <54896F30.6050802@oracle.com> I have addressed a couple of comments from Valerie: - updated tests in test/com/sun/crypto/provider/Mac not to test SunPKCS11 provider - added the following tests for PKCS11 providers test/sun/security/pkcs11/Mac/MacKAT.java test/sun/security/pkcs11/Mac/MacSameTest.java - removed a check that CloneNotSupportedException is thrown on Solaris Please take a look. http://cr.openjdk.java.net/~asmotrak/8048603/webrev.01/ Artem On 11/07/2014 01:07 PM, Artem Smotrakov wrote: > Please review a couple of new test cases for MAC algorithms. > > https://bugs.openjdk.java.net/browse/JDK-8048603 > http://cr.openjdk.java.net/~asmotrak/8048603/webrev.00/ > > Artem From vincent.x.ryan at oracle.com Thu Dec 11 13:47:36 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 11 Dec 2014 13:47:36 +0000 Subject: [9] RFR 8062170: java.security.ProviderException: Error parsing configuration with space In-Reply-To: <54890741.2020208@oracle.com> References: <54890741.2020208@oracle.com> Message-ID: <8EC18BBF-8772-4433-B6B3-78E129B8C32A@oracle.com> Your fix looks good to me. Thanks. On 11 Dec 2014, at 02:53, Valerie Peng wrote: > > Can someone help reviewing this regression (by 7196009 when adding support for parenthesis in library path in PKCS11 provider config file)? > > The fix is to change the library path parsing back to using the parseLine() method and then relax the impl inside parseLine() to allow quoted strings. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062170 > Webrev: http://cr.openjdk.java.net/~valeriep/8062170/webrev.00/ > > Thanks, > Valerie > From weijun.wang at oracle.com Fri Dec 12 04:02:01 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 12 Dec 2014 12:02:01 +0800 Subject: Detecting whether an algorithm is supported without creating one? Message-ID: <548A68B9.6030309@oracle.com> I'd like to check if "SHA-256" is supported without calling MessageDigest.getInstance("SHA-256"). Does such a method exist? My case is a multi-thread digestor like this: class Digestor { Digestor(String alg) throws NSAE; @ThreadSafe byte[] digest(byte[]) throws Nothing; } So a Digestor is created and multiple threads can call the digest() method. I would be glad if the constructor can throw an NSAE but not creating a MessageDigest object because I don't know how to safely use it inside digest(). Thanks Max From bradford.wetmore at oracle.com Fri Dec 12 04:12:08 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 11 Dec 2014 20:12:08 -0800 Subject: Detecting whether an algorithm is supported without creating one? In-Reply-To: <548A68B9.6030309@oracle.com> References: <548A68B9.6030309@oracle.com> Message-ID: <548A6B18.6000504@oracle.com> On 12/11/2014 8:02 PM, Weijun Wang wrote: > I'd like to check if "SHA-256" is supported without calling > MessageDigest.getInstance("SHA-256"). Does such a method exist? Not that I'm aware of. Brad > My case is a multi-thread digestor like this: > > class Digestor { > Digestor(String alg) throws NSAE; > @ThreadSafe byte[] digest(byte[]) throws Nothing; > } > > So a Digestor is created and multiple threads can call the digest() > method. I would be glad if the constructor can throw an NSAE but not > creating a MessageDigest object because I don't know how to safely use > it inside digest(). > > Thanks > Max From ecki at zusammenkunft.net Fri Dec 12 05:04:30 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 12 Dec 2014 06:04:30 +0100 Subject: Detecting whether an algorithm is supported without creating one? In-Reply-To: <548A68B9.6030309@oracle.com> References: <548A68B9.6030309@oracle.com> Message-ID: <2083F961-20EF-4E57-AB12-AE1D27B81BE7@zusammenkunft.net> Just get it and throw it away, it is easier than iterating the algorithms of the providers. > Am 12.12.2014 um 05:02 schrieb Weijun Wang : > > I'd like to check if "SHA-256" is supported without calling MessageDigest.getInstance("SHA-256"). Does such a method exist? > > My case is a multi-thread digestor like this: > > class Digestor { > Digestor(String alg) throws NSAE; > @ThreadSafe byte[] digest(byte[]) throws Nothing; > } > > So a Digestor is created and multiple threads can call the digest() method. I would be glad if the constructor can throw an NSAE but not creating a MessageDigest object because I don't know how to safely use it inside digest(). > > Thanks > Max From sean.mullan at oracle.com Fri Dec 12 13:20:47 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Dec 2014 08:20:47 -0500 Subject: Detecting whether an algorithm is supported without creating one? In-Reply-To: <2083F961-20EF-4E57-AB12-AE1D27B81BE7@zusammenkunft.net> References: <548A68B9.6030309@oracle.com> <2083F961-20EF-4E57-AB12-AE1D27B81BE7@zusammenkunft.net> Message-ID: <548AEBAF.7030609@oracle.com> On 12/12/2014 12:04 AM, Bernd Eckenfels wrote: > Just get it and throw it away, it is easier than iterating the algorithms of the providers. Yes, probably. But as you note, the other way is to iterate over the Providers returned by Security.getProviders(), and call p.getService("MessageDigest", "SHA-256") on each ... --Sean > > >> Am 12.12.2014 um 05:02 schrieb Weijun Wang : >> >> I'd like to check if "SHA-256" is supported without calling MessageDigest.getInstance("SHA-256"). Does such a method exist? >> >> My case is a multi-thread digestor like this: >> >> class Digestor { >> Digestor(String alg) throws NSAE; >> @ThreadSafe byte[] digest(byte[]) throws Nothing; >> } >> >> So a Digestor is created and multiple threads can call the digest() method. I would be glad if the constructor can throw an NSAE but not creating a MessageDigest object because I don't know how to safely use it inside digest(). >> >> Thanks >> Max From vincent.x.ryan at oracle.com Fri Dec 12 14:59:07 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 12 Dec 2014 14:59:07 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <547DD669.7010808@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> Message-ID: Thanks for those comments Sean. I?ve addressed most of them in the webrev below. Other notable changes since the previous webrev include: - modified the two getInstance(File,?) methods to also load the keystore entries - PKCS12 keystore support now available in both SUN and SunJSSE providers - test fixes http://cr.openjdk.java.net/~vinnie/8044445/webrev.02/ On 2 Dec 2014, at 15:10, Sean Mullan wrote: > Comments: > > * JceKeyStore > > [906] add @Override to engineProbe method > > * KeyStore > > [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. > > You need to define what happens if the File does not exist. You could either throw a KeyStoreException, or you could instantiate a KeyStore using the default keystore type. Each have their pros/cons. The latter seems a little better as this method could then be used to open existing keystores or for creating new keystores. > > [1638] This is a provider configuration error, but there still may be other KeyStoreSpis that can parse the file. I would probably just log this and continue to check other providers. > > [1654] Same here. I would log this and continue to check other providers. Method currently say it throws KeyStoreExc only if no Provider supports the file, but we have not necessarily checked all providers yet. > > * KeyStoreSpi > > [606] s/@exception/@throws/. Should probably also add an @throws NullPointerException if stream is null. > > You need to define that the method returns false by default. > > * PKCS12KeyStore > > [2340] @Override > [2342-51] indentation should be 4 spaces > [2353,2364] these should be static fields > > * JavaKeyStore > > [54] why did you make this public? Because its JKS subclass is now called from the sun.security.pkcs12 package > [816] @Override > > * keytool/Main > > [814, 1919] I'm not sure if it is correct to ignore the storetype. I think getInstance(File) should only be called if the storetype is not specified. I wanted to take advantage of the new keystore probing mechanism. Maybe we should honour the storetype if it?s neither JKS nor PKCS12, otherwise probe? > > * KeyStoreDelegator > > overridden methods should have @Override tag > > Can you make this class final with a private ctor, and instead have a static method to return instances? Then I have to duplicate each of the KeyStoreSpi methods in both PKCS12KeyStore.DualFormatPKCS12 and JavaKeyStore.DualFormatJKS. > > The engine methods throw NPE if the keystore has not been loaded. This is not consistent with the current JKS Keystore and PKCS12 Keystore impls and looks like it is not compliant with the KeyStoreSpi spec. I think you need to modify the methods to return null, etc instead if the keystore has not been loaded yet. The KeyStore methods handle the test for an uninitialised keystore (before the KeyStoreSpi methods are called). > > --Sean > > On 12/02/2014 06:23 AM, Vincent Ryan wrote: >> >> Please review the following enhancement to improve keystore security by creating PKCS12 keystores by default. >> Previously, JKS keystores were created by default. PKCS12 has the advantage of supporting stronger crypto >> and hashing algorithms. It is also an open, extensible format and supports associating arbitrary attributes with >> keystore entries. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8044445/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8044445 >> >> >> To assist with compatibility across JDK releases, both JKS and PKCS12 keystore implementations have been >> extended to support both file formats. Applications that access keystores created by earlier releases should >> require no code changes. >> >> This changeset also includes a new convenience method for instantiating a file-based keystore: KeyStore.getInstance >> - it takes a File argument. The specified file is probed by each supported keystore implementation to determine its >> keystore type. KeyStoreSpi has been enhanced with a boolean engineProbe method to perform the actual probing. >> >> Finally, to improve performance, the PKCS12 keystore implementation has been moved from the SunJSSE provider >> to the SUN provider (as it appears earlier in the default list of installed JCE providers). >> From peter.levart at gmail.com Sat Dec 13 21:12:37 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 13 Dec 2014 22:12:37 +0100 Subject: Detecting whether an algorithm is supported without creating one? In-Reply-To: <548AEBAF.7030609@oracle.com> References: <548A68B9.6030309@oracle.com> <2083F961-20EF-4E57-AB12-AE1D27B81BE7@zusammenkunft.net> <548AEBAF.7030609@oracle.com> Message-ID: <548CABC5.40308@gmail.com> On 12/12/2014 02:20 PM, Sean Mullan wrote: > On 12/12/2014 12:04 AM, Bernd Eckenfels wrote: >> Just get it and throw it away, it is easier than iterating the >> algorithms of the providers. > > Yes, probably. But as you note, the other way is to iterate over the > Providers returned by Security.getProviders(), and call > p.getService("MessageDigest", "SHA-256") on each ... > Even simpler: java.security.Security.getAlgorithms("MessageDigest").contains("SHA-256") Regards, Peter > --Sean > >> >> >>> Am 12.12.2014 um 05:02 schrieb Weijun Wang : >>> >>> I'd like to check if "SHA-256" is supported without calling >>> MessageDigest.getInstance("SHA-256"). Does such a method exist? >>> >>> My case is a multi-thread digestor like this: >>> >>> class Digestor { >>> Digestor(String alg) throws NSAE; >>> @ThreadSafe byte[] digest(byte[]) throws Nothing; >>> } >>> >>> So a Digestor is created and multiple threads can call the digest() >>> method. I would be glad if the constructor can throw an NSAE but not >>> creating a MessageDigest object because I don't know how to safely >>> use it inside digest(). >>> >>> Thanks >>> Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sun Dec 14 09:13:57 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 14 Dec 2014 17:13:57 +0800 Subject: Detecting whether an algorithm is supported without creating one? In-Reply-To: <548CABC5.40308@gmail.com> References: <548A68B9.6030309@oracle.com> <2083F961-20EF-4E57-AB12-AE1D27B81BE7@zusammenkunft.net> <548AEBAF.7030609@oracle.com> <548CABC5.40308@gmail.com> Message-ID: Unfortunately it does not contain the aliases, say, there is "SHA" but no "SHA-1". --Max > On Dec 14, 2014, at 05:12, Peter Levart wrote: > > Even simpler: > > java.security.Security.getAlgorithms("MessageDigest").contains("SHA-256") > > Regards, Peter > From rich.midwinter at gmail.com Sun Dec 14 20:24:29 2014 From: rich.midwinter at gmail.com (Rich Midwinter) Date: Sun, 14 Dec 2014 20:24:29 +0000 Subject: New switch suggestion for keytool Message-ID: Hi I'd like to see a new switch added to keytool to initialise an empty keystore, for which I've attached a first shot at a patch. Could someone point me in the right direction (a sponsor?) to see if this can be included. Thanks Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java @@ -204,6 +204,7 @@ SRCALIAS, DESTALIAS, SRCKEYPASS, DESTKEYPASS, NOPROMPT, PROVIDERCLASS, PROVIDERARG, PROVIDERPATH, V), + INIT("Creates.an.initial.empty.keystore", KEYSTORE, STOREPASS), KEYPASSWD("Changes.the.key.password.of.an.entry", ALIAS, KEYPASS, NEW, KEYSTORE, STOREPASS, STORETYPE, PROVIDERNAME, PROVIDERCLASS, PROVIDERARG, @@ -784,6 +785,7 @@ command != IMPORTCERT && command != IMPORTPASS && command != IMPORTKEYSTORE && + command != INIT && command != PRINTCRL) { throw new Exception(rb.getString ("Keystore.file.does.not.exist.") + ksfname); @@ -1067,6 +1069,8 @@ } else if (command == IMPORTKEYSTORE) { doImportKeyStore(); kssave = true; + } else if (command == INIT) { + kssave = true; } else if (command == KEYCLONE) { keyPassNew = newPass; diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java @@ -78,6 +78,8 @@ "Imports a password"}, //-importpass {"Imports.one.or.all.entries.from.another.keystore", "Imports one or all entries from another keystore"}, //-importkeystore + {"Creates.an.initial.empty.keystore", + "Creates an initial empty keystore"}, //-init {"Clones.a.key.entry", "Clones a key entry"}, //-keyclone {"Changes.the.key.password.of.an.entry", From weijun.wang at oracle.com Mon Dec 15 01:54:53 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 15 Dec 2014 09:54:53 +0800 Subject: New switch suggestion for keytool In-Reply-To: References: Message-ID: <89A7EF74-03C8-4E37-BA55-DD2F9EB2EBBC@oracle.com> How is this useful? On the other hand, you can always import a cert and remove it to get an empty keystore. --Max > On Dec 15, 2014, at 04:24, Rich Midwinter wrote: > > Hi > > I'd like to see a new switch added to keytool to initialise an empty keystore, for which I've attached a first shot at a patch. > > Could someone point me in the right direction (a sponsor?) to see if this can be included. > > Thanks > Rich > > From fengzm at sg.ibm.com Mon Dec 15 02:08:18 2014 From: fengzm at sg.ibm.com (Zhemin Feng) Date: Mon, 15 Dec 2014 10:08:18 +0800 Subject: AUTO: Zhemin Feng is out of the office (returning 12/19/2014) Message-ID: I am out of the office until 12/19/2014. I will take leave from 15th Dec, and will be back on 19th Dec. Please contact Ke Pi/Singapore/IBM for Java Security L3 work. Best regards, Feng Zhemin Note: This is an automated response to your message "security-dev Digest, Vol 90, Issue 7" sent on 12/15/2014 4:24:55. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Mon Dec 15 14:43:24 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 15 Dec 2014 14:43:24 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> Message-ID: <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> One further update: introduced a new security property to explicitly disable compatibility mode for JKS and PKCS12 keystores. By default, compatibility mode is enabled for JKS and PKCS12 to aid applications that expect the previous default keystore type (JKS). http://cr.openjdk.java.net/~vinnie/8044445/webrev.03/ On 12 Dec 2014, at 14:59, Vincent Ryan wrote: > Thanks for those comments Sean. I?ve addressed most of them in the webrev below. > > Other notable changes since the previous webrev include: > > - modified the two getInstance(File,?) methods to also load the keystore entries > - PKCS12 keystore support now available in both SUN and SunJSSE providers > - test fixes > > http://cr.openjdk.java.net/~vinnie/8044445/webrev.02/ > > > On 2 Dec 2014, at 15:10, Sean Mullan wrote: > >> Comments: >> >> * JceKeyStore >> >> [906] add @Override to engineProbe method > >> >> * KeyStore >> >> [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. >> >> You need to define what happens if the File does not exist. You could either throw a KeyStoreException, or you could instantiate a KeyStore using the default keystore type. Each have their pros/cons. The latter seems a little better as this method could then be used to open existing keystores or for creating new keystores. >> >> [1638] This is a provider configuration error, but there still may be other KeyStoreSpis that can parse the file. I would probably just log this and continue to check other providers. >> >> [1654] Same here. I would log this and continue to check other providers. Method currently say it throws KeyStoreExc only if no Provider supports the file, but we have not necessarily checked all providers yet. >> >> * KeyStoreSpi >> >> [606] s/@exception/@throws/. Should probably also add an @throws NullPointerException if stream is null. >> >> You need to define that the method returns false by default. >> >> * PKCS12KeyStore >> >> [2340] @Override >> [2342-51] indentation should be 4 spaces >> [2353,2364] these should be static fields >> >> * JavaKeyStore >> >> [54] why did you make this public? > > Because its JKS subclass is now called from the sun.security.pkcs12 package > > >> [816] @Override >> >> * keytool/Main >> >> [814, 1919] I'm not sure if it is correct to ignore the storetype. I think getInstance(File) should only be called if the storetype is not specified. > > I wanted to take advantage of the new keystore probing mechanism. > Maybe we should honour the storetype if it?s neither JKS nor PKCS12, otherwise probe? > > >> >> * KeyStoreDelegator >> >> overridden methods should have @Override tag >> >> Can you make this class final with a private ctor, and instead have a static method to return instances? > > Then I have to duplicate each of the KeyStoreSpi methods in both PKCS12KeyStore.DualFormatPKCS12 > and JavaKeyStore.DualFormatJKS. > > >> >> The engine methods throw NPE if the keystore has not been loaded. This is not consistent with the current JKS Keystore and PKCS12 Keystore impls and looks like it is not compliant with the KeyStoreSpi spec. I think you need to modify the methods to return null, etc instead if the keystore has not been loaded yet. > > The KeyStore methods handle the test for an uninitialised keystore (before the KeyStoreSpi methods are called). > > >> >> --Sean >> >> On 12/02/2014 06:23 AM, Vincent Ryan wrote: >>> >>> Please review the following enhancement to improve keystore security by creating PKCS12 keystores by default. >>> Previously, JKS keystores were created by default. PKCS12 has the advantage of supporting stronger crypto >>> and hashing algorithms. It is also an open, extensible format and supports associating arbitrary attributes with >>> keystore entries. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8044445/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044445 >>> >>> >>> To assist with compatibility across JDK releases, both JKS and PKCS12 keystore implementations have been >>> extended to support both file formats. Applications that access keystores created by earlier releases should >>> require no code changes. >>> >>> This changeset also includes a new convenience method for instantiating a file-based keystore: KeyStore.getInstance >>> - it takes a File argument. The specified file is probed by each supported keystore implementation to determine its >>> keystore type. KeyStoreSpi has been enhanced with a boolean engineProbe method to perform the actual probing. >>> >>> Finally, to improve performance, the PKCS12 keystore implementation has been moved from the SunJSSE provider >>> to the SUN provider (as it appears earlier in the default list of installed JCE providers). >>> > From mhall at mhcomputing.net Mon Dec 15 20:19:31 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Mon, 15 Dec 2014 12:19:31 -0800 Subject: New switch suggestion for keytool In-Reply-To: <89A7EF74-03C8-4E37-BA55-DD2F9EB2EBBC@oracle.com> References: <89A7EF74-03C8-4E37-BA55-DD2F9EB2EBBC@oracle.com> Message-ID: <20141215201931.GA806@mhcomputing.net> It's really useful for things like bootstrapping keystores for symmetric keys. Many StackOverflows exist of people doing it manually to "work around" this limitation. I've done it myself especially when working on an identity management appliance. Matthew. On Mon, Dec 15, 2014 at 09:54:53AM +0800, Wang Weijun wrote: > How is this useful? > > On the other hand, you can always import a cert and remove it to get an empty keystore. > > --Max > > > On Dec 15, 2014, at 04:24, Rich Midwinter wrote: > > > > Hi > > > > I'd like to see a new switch added to keytool to initialise an empty keystore, for which I've attached a first shot at a patch. > > > > Could someone point me in the right direction (a sponsor?) to see if this can be included. > > > > Thanks > > Rich > > > > > From valerie.peng at oracle.com Mon Dec 15 22:38:26 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Dec 2014 14:38:26 -0800 Subject: RFR: 8048603: Additional tests for MAC algorithms In-Reply-To: <54896F30.6050802@oracle.com> References: <545C99D6.2090200@oracle.com> <54896F30.6050802@oracle.com> Message-ID: <548F62E2.7020803@oracle.com> Artem, Here are my comments: 1) Three tests under com/sun/crypto/provider directory do not specify a provider when calling Mac.getInstance(). Since they are under the regression tests directory for SunJCE, perhaps we should specify SunJCE provider to be used. 2) 'ALGORITHMS' seems redundant for sun/security/pkcs11/Mac/MacSameTest.java Thanks, Valerie On 12/11/2014 2:17 AM, Artem Smotrakov wrote: > I have addressed a couple of comments from Valerie: > - updated tests in test/com/sun/crypto/provider/Mac not to test > SunPKCS11 provider > - added the following tests for PKCS11 providers > test/sun/security/pkcs11/Mac/MacKAT.java > test/sun/security/pkcs11/Mac/MacSameTest.java > - removed a check that CloneNotSupportedException is thrown on Solaris > > Please take a look. > > http://cr.openjdk.java.net/~asmotrak/8048603/webrev.01/ > > Artem > > On 11/07/2014 01:07 PM, Artem Smotrakov wrote: >> Please review a couple of new test cases for MAC algorithms. >> >> https://bugs.openjdk.java.net/browse/JDK-8048603 >> http://cr.openjdk.java.net/~asmotrak/8048603/webrev.00/ >> >> Artem > From weijun.wang at oracle.com Tue Dec 16 00:50:24 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 16 Dec 2014 08:50:24 +0800 Subject: New switch suggestion for keytool In-Reply-To: <20141215201931.GA806@mhcomputing.net> References: <89A7EF74-03C8-4E37-BA55-DD2F9EB2EBBC@oracle.com> <20141215201931.GA806@mhcomputing.net> Message-ID: > On Dec 16, 2014, at 04:19, Matthew Hall wrote: > > It's really useful for things like bootstrapping keystores for symmetric keys. For a program? It's super easy for a program to create an empty keystore. > > Many StackOverflows exist of people doing it manually to "work around" this > limitation. In fact, I searched for "create empty keystore" on stackoverflow and didn't notice such a requirement. --Max > > I've done it myself especially when working on an identity management > appliance. > > Matthew. > > On Mon, Dec 15, 2014 at 09:54:53AM +0800, Wang Weijun wrote: >> How is this useful? >> >> On the other hand, you can always import a cert and remove it to get an empty keystore. >> >> --Max >> >>> On Dec 15, 2014, at 04:24, Rich Midwinter wrote: >>> >>> Hi >>> >>> I'd like to see a new switch added to keytool to initialise an empty keystore, for which I've attached a first shot at a patch. >>> >>> Could someone point me in the right direction (a sponsor?) to see if this can be included. >>> >>> Thanks >>> Rich >>> >>> >> From joe.darcy at oracle.com Tue Dec 16 18:25:22 2014 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 16 Dec 2014 10:25:22 -0800 Subject: JDK 9 RFR of JDK-8067091: Fix Windows-specific deprecation warnings in the jdk.crypto.mscapi module Message-ID: <54907912.2060106@oracle.com> Hello, Please review the simple changes to address JDK-8067091: Fix Windows-specific deprecation warnings in the jdk.crypto.mscapi module http://cr.openjdk.java.net/~darcy/8067091.0/ Patch below. Thanks, -Joe diff -r e934242d0c1f src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSACipher.java --- a/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSACipher.java Tue Dec 16 09:51:17 2014 -0800 +++ b/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSACipher.java Tue Dec 16 10:22:37 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -159,6 +159,7 @@ } // see JCE spec + @SuppressWarnings("deprecation") protected void engineInit(int opmode, Key key, AlgorithmParameterSpec params, SecureRandom random) throws InvalidKeyException, InvalidAlgorithmParameterException { @@ -369,6 +370,7 @@ } // see JCE spec + @SuppressWarnings("deprecation") protected java.security.Key engineUnwrap(byte[] wrappedKey, String algorithm, int type) throws InvalidKeyException, NoSuchAlgorithmException { From vincent.x.ryan at oracle.com Tue Dec 16 18:26:30 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 16 Dec 2014 18:26:30 +0000 Subject: JDK 9 RFR of JDK-8067091: Fix Windows-specific deprecation warnings in the jdk.crypto.mscapi module In-Reply-To: <54907912.2060106@oracle.com> References: <54907912.2060106@oracle.com> Message-ID: <929F3BFC-76A1-439B-8E25-C77A6023A411@oracle.com> Fix looks good to me. On 16 Dec 2014, at 18:25, joe darcy wrote: > Hello, > > Please review the simple changes to address > > JDK-8067091: Fix Windows-specific deprecation warnings in the jdk.crypto.mscapi module > http://cr.openjdk.java.net/~darcy/8067091.0/ > > Patch below. > > Thanks, > > -Joe > > diff -r e934242d0c1f src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSACipher.java > --- a/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSACipher.java Tue Dec 16 09:51:17 2014 -0800 > +++ b/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/RSACipher.java Tue Dec 16 10:22:37 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -159,6 +159,7 @@ > } > > // see JCE spec > + @SuppressWarnings("deprecation") > protected void engineInit(int opmode, Key key, > AlgorithmParameterSpec params, SecureRandom random) > throws InvalidKeyException, InvalidAlgorithmParameterException { > @@ -369,6 +370,7 @@ > } > > // see JCE spec > + @SuppressWarnings("deprecation") > protected java.security.Key engineUnwrap(byte[] wrappedKey, > String algorithm, > int type) throws InvalidKeyException, NoSuchAlgorithmException { > From joe.darcy at oracle.com Tue Dec 16 19:17:25 2014 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 16 Dec 2014 11:17:25 -0800 Subject: JDK 9 RFR of 8067088: Suppress solaris-specific deprecation warnings in the jdk.crypto.ucrypto module Message-ID: <54908545.9070307@oracle.com> Hello, Please review this small change to address 8067088: Suppress solaris-specific deprecation warnings in the jdk.crypto.ucrypto module http://cr.openjdk.java.net/~darcy/8067088.0/ Patch below. Thanks, -Joe diff -r 5b63e9c1e8a0 src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeRSACipher.java --- a/src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeRSACipher.java Tue Dec 16 11:05:12 2014 -0800 +++ b/src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeRSACipher.java Tue Dec 16 11:15:09 2014 -0800 @@ -178,6 +178,7 @@ // see JCE spec @Override + @SuppressWarnings("deprecation") protected synchronized void engineInit(int opmode, Key newKey, AlgorithmParameterSpec params, SecureRandom random) throws InvalidKeyException, InvalidAlgorithmParameterException { @@ -331,6 +332,7 @@ // see JCE spec @Override + @SuppressWarnings("deprecation") protected synchronized Key engineUnwrap(byte[] wrappedKey, String wrappedKeyAlgorithm, int wrappedKeyType) throws InvalidKeyException, NoSuchAlgorithmException { From valerie.peng at oracle.com Tue Dec 16 19:27:42 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 16 Dec 2014 11:27:42 -0800 Subject: JDK 9 RFR of 8067088: Suppress solaris-specific deprecation warnings in the jdk.crypto.ucrypto module In-Reply-To: <54908545.9070307@oracle.com> References: <54908545.9070307@oracle.com> Message-ID: <549087AE.9070803@oracle.com> Fix looks good. Thanks, Valerie On 12/16/2014 11:17 AM, joe darcy wrote: > Hello, > > Please review this small change to address > > 8067088: Suppress solaris-specific deprecation warnings in the > jdk.crypto.ucrypto module > http://cr.openjdk.java.net/~darcy/8067088.0/ > > Patch below. > > Thanks, > > -Joe > > diff -r 5b63e9c1e8a0 > src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeRSACipher.java > --- > a/src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeRSACipher.java > Tue Dec 16 11:05:12 2014 -0800 > +++ > b/src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeRSACipher.java > Tue Dec 16 11:15:09 2014 -0800 > @@ -178,6 +178,7 @@ > > // see JCE spec > @Override > + @SuppressWarnings("deprecation") > protected synchronized void engineInit(int opmode, Key newKey, > AlgorithmParameterSpec params, SecureRandom random) > throws InvalidKeyException, > InvalidAlgorithmParameterException { > @@ -331,6 +332,7 @@ > > // see JCE spec > @Override > + @SuppressWarnings("deprecation") > protected synchronized Key engineUnwrap(byte[] wrappedKey, > String wrappedKeyAlgorithm, int wrappedKeyType) > throws InvalidKeyException, NoSuchAlgorithmException { > From jason.uh at oracle.com Tue Dec 16 19:44:45 2014 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 16 Dec 2014 11:44:45 -0800 Subject: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled Message-ID: <54908BAD.3010700@oracle.com> Please review this fix, which allows XML Signature ECKeyValue elements to be marshalled and unmarshalled. Dependence on internal sun.security.* classes has been removed, so that the (un)marshalling can happen without reflection. webrev: http://cr.openjdk.java.net/~juh/8046724/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8046724 A corresponding test will be added to the closed repository. Thanks, Jason From sean.mullan at oracle.com Tue Dec 16 21:11:16 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Dec 2014 16:11:16 -0500 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> Message-ID: <54909FF4.9020404@oracle.com> Here are my comments on the latest webrev: * General - for the engineProbe methods, if a DataInputStream is not specified, I think you should wrap the stream in a DataInputStream, rather than returning false. * KeyStore - The class summary should be modified to include an example using the new getInstance methods. * keytool/Main - can you explain more about why the provider is ignored on lines 812-817, 1919-1925? This doesn't seem like it is compliant with keytool -- if a provider is specified, it should be used. * ReadP12Test - can you fix the typo: s/IN_KETYSTORE_TYPE/IN_KEYSTORE_TYPE/ * KeyToolTest - you have some comments labeled with VR that look like they should be removed --Sean On 12/15/2014 09:43 AM, Vincent Ryan wrote: > > One further update: introduced a new security property to explicitly disable compatibility mode > for JKS and PKCS12 keystores. By default, compatibility mode is enabled for JKS and PKCS12 > to aid applications that expect the previous default keystore type (JKS). > > http://cr.openjdk.java.net/~vinnie/8044445/webrev.03/ > > > > On 12 Dec 2014, at 14:59, Vincent Ryan wrote: > >> Thanks for those comments Sean. I?ve addressed most of them in the webrev below. >> >> Other notable changes since the previous webrev include: >> >> - modified the two getInstance(File,?) methods to also load the keystore entries >> - PKCS12 keystore support now available in both SUN and SunJSSE providers >> - test fixes >> >> http://cr.openjdk.java.net/~vinnie/8044445/webrev.02/ >> >> >> On 2 Dec 2014, at 15:10, Sean Mullan wrote: >> >>> Comments: >>> >>> * JceKeyStore >>> >>> [906] add @Override to engineProbe method >> >>> >>> * KeyStore >>> >>> [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. >>> >>> You need to define what happens if the File does not exist. You could either throw a KeyStoreException, or you could instantiate a KeyStore using the default keystore type. Each have their pros/cons. The latter seems a little better as this method could then be used to open existing keystores or for creating new keystores. >>> >>> [1638] This is a provider configuration error, but there still may be other KeyStoreSpis that can parse the file. I would probably just log this and continue to check other providers. >>> >>> [1654] Same here. I would log this and continue to check other providers. Method currently say it throws KeyStoreExc only if no Provider supports the file, but we have not necessarily checked all providers yet. >>> >>> * KeyStoreSpi >>> >>> [606] s/@exception/@throws/. Should probably also add an @throws NullPointerException if stream is null. >>> >>> You need to define that the method returns false by default. >>> >>> * PKCS12KeyStore >>> >>> [2340] @Override >>> [2342-51] indentation should be 4 spaces >>> [2353,2364] these should be static fields >>> >>> * JavaKeyStore >>> >>> [54] why did you make this public? >> >> Because its JKS subclass is now called from the sun.security.pkcs12 package >> >> >>> [816] @Override >>> >>> * keytool/Main >>> >>> [814, 1919] I'm not sure if it is correct to ignore the storetype. I think getInstance(File) should only be called if the storetype is not specified. >> >> I wanted to take advantage of the new keystore probing mechanism. >> Maybe we should honour the storetype if it?s neither JKS nor PKCS12, otherwise probe? >> >> >>> >>> * KeyStoreDelegator >>> >>> overridden methods should have @Override tag >>> >>> Can you make this class final with a private ctor, and instead have a static method to return instances? >> >> Then I have to duplicate each of the KeyStoreSpi methods in both PKCS12KeyStore.DualFormatPKCS12 >> and JavaKeyStore.DualFormatJKS. >> >> >>> >>> The engine methods throw NPE if the keystore has not been loaded. This is not consistent with the current JKS Keystore and PKCS12 Keystore impls and looks like it is not compliant with the KeyStoreSpi spec. I think you need to modify the methods to return null, etc instead if the keystore has not been loaded yet. >> >> The KeyStore methods handle the test for an uninitialised keystore (before the KeyStoreSpi methods are called). >> >> >>> >>> --Sean >>> >>> On 12/02/2014 06:23 AM, Vincent Ryan wrote: >>>> >>>> Please review the following enhancement to improve keystore security by creating PKCS12 keystores by default. >>>> Previously, JKS keystores were created by default. PKCS12 has the advantage of supporting stronger crypto >>>> and hashing algorithms. It is also an open, extensible format and supports associating arbitrary attributes with >>>> keystore entries. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8044445/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044445 >>>> >>>> >>>> To assist with compatibility across JDK releases, both JKS and PKCS12 keystore implementations have been >>>> extended to support both file formats. Applications that access keystores created by earlier releases should >>>> require no code changes. >>>> >>>> This changeset also includes a new convenience method for instantiating a file-based keystore: KeyStore.getInstance >>>> - it takes a File argument. The specified file is probed by each supported keystore implementation to determine its >>>> keystore type. KeyStoreSpi has been enhanced with a boolean engineProbe method to perform the actual probing. >>>> >>>> Finally, to improve performance, the PKCS12 keystore implementation has been moved from the SunJSSE provider >>>> to the SUN provider (as it appears earlier in the default list of installed JCE providers). >>>> >> > From mhall at mhcomputing.net Tue Dec 16 23:32:45 2014 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 16 Dec 2014 15:32:45 -0800 Subject: New switch suggestion for keytool In-Reply-To: References: <89A7EF74-03C8-4E37-BA55-DD2F9EB2EBBC@oracle.com> <20141215201931.GA806@mhcomputing.net> Message-ID: <20141216233245.GA21860@mhcomputing.net> On Tue, Dec 16, 2014 at 08:50:24AM +0800, Wang Weijun wrote: > For a program? It's super easy for a program to create an empty keystore. Why have to do it separately, when it could be added to keytool for all? > > Many StackOverflows exist of people doing it manually to "work around" this > > limitation. > > In fact, I searched for "create empty keystore" on stackoverflow and didn't > notice such a requirement. The ones I ran across were for PKCS#11 using the NSS C-code tools because I had to be FIPS compliant. But it'd be nice if Java's tools supported it too. Matthew. From vincent.x.ryan at oracle.com Wed Dec 17 00:12:20 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 17 Dec 2014 00:12:20 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <54909FF4.9020404@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> Message-ID: I?ve generated a new webrev to address your comments below: http://cr.openjdk.java.net/~vinnie/8044445/webrev.04/ Thanks. On 16 Dec 2014, at 21:11, Sean Mullan wrote: > Here are my comments on the latest webrev: > > * General > > - for the engineProbe methods, if a DataInputStream is not specified, I think you should wrap the stream in a DataInputStream, rather than returning false. KeyStore.getInstance(File,?) always supplies a DataInputStream to KeyStoreSpi.engineProbe so it is not necessary to wrap. > > * KeyStore > > - The class summary should be modified to include an example using the new getInstance methods. Fixed. > > * keytool/Main > > - can you explain more about why the provider is ignored on lines 812-817, 1919-1925? This doesn't seem like it is compliant with keytool -- if a provider is specified, it should be used. The probing mechanism is better equipped to determine the exact keystore type. For example, if an application specifies no -storetype option then it implicitly gets the default keystore type which now differs between JDK 9 and earlier releases. The new compatibility mode can handle this scenario so that the application doesn?t break. However, in compatibility mode the instantiated keystore type might not match the keystore format. Whereas when probing is employed the instantiated keystore type always matches the keystore format. > > * ReadP12Test > > - can you fix the typo: s/IN_KETYSTORE_TYPE/IN_KEYSTORE_TYPE/ Fixed. > > * KeyToolTest > > - you have some comments labeled with VR that look like they should be removed Fixed. > > --Sean > > > On 12/15/2014 09:43 AM, Vincent Ryan wrote: >> >> One further update: introduced a new security property to explicitly disable compatibility mode >> for JKS and PKCS12 keystores. By default, compatibility mode is enabled for JKS and PKCS12 >> to aid applications that expect the previous default keystore type (JKS). >> >> http://cr.openjdk.java.net/~vinnie/8044445/webrev.03/ >> >> >> >> On 12 Dec 2014, at 14:59, Vincent Ryan wrote: >> >>> Thanks for those comments Sean. I?ve addressed most of them in the webrev below. >>> >>> Other notable changes since the previous webrev include: >>> >>> - modified the two getInstance(File,?) methods to also load the keystore entries >>> - PKCS12 keystore support now available in both SUN and SunJSSE providers >>> - test fixes >>> >>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.02/ >>> >>> >>> On 2 Dec 2014, at 15:10, Sean Mullan wrote: >>> >>>> Comments: >>>> >>>> * JceKeyStore >>>> >>>> [906] add @Override to engineProbe method >>> >>>> >>>> * KeyStore >>>> >>>> [1615] use @throws instead of @exception. Should probably also add an @throws NullPointerException if keystore is null. >>>> >>>> You need to define what happens if the File does not exist. You could either throw a KeyStoreException, or you could instantiate a KeyStore using the default keystore type. Each have their pros/cons. The latter seems a little better as this method could then be used to open existing keystores or for creating new keystores. >>>> >>>> [1638] This is a provider configuration error, but there still may be other KeyStoreSpis that can parse the file. I would probably just log this and continue to check other providers. >>>> >>>> [1654] Same here. I would log this and continue to check other providers. Method currently say it throws KeyStoreExc only if no Provider supports the file, but we have not necessarily checked all providers yet. >>>> >>>> * KeyStoreSpi >>>> >>>> [606] s/@exception/@throws/. Should probably also add an @throws NullPointerException if stream is null. >>>> >>>> You need to define that the method returns false by default. >>>> >>>> * PKCS12KeyStore >>>> >>>> [2340] @Override >>>> [2342-51] indentation should be 4 spaces >>>> [2353,2364] these should be static fields >>>> >>>> * JavaKeyStore >>>> >>>> [54] why did you make this public? >>> >>> Because its JKS subclass is now called from the sun.security.pkcs12 package >>> >>> >>>> [816] @Override >>>> >>>> * keytool/Main >>>> >>>> [814, 1919] I'm not sure if it is correct to ignore the storetype. I think getInstance(File) should only be called if the storetype is not specified. >>> >>> I wanted to take advantage of the new keystore probing mechanism. >>> Maybe we should honour the storetype if it?s neither JKS nor PKCS12, otherwise probe? >>> >>> >>>> >>>> * KeyStoreDelegator >>>> >>>> overridden methods should have @Override tag >>>> >>>> Can you make this class final with a private ctor, and instead have a static method to return instances? >>> >>> Then I have to duplicate each of the KeyStoreSpi methods in both PKCS12KeyStore.DualFormatPKCS12 >>> and JavaKeyStore.DualFormatJKS. >>> >>> >>>> >>>> The engine methods throw NPE if the keystore has not been loaded. This is not consistent with the current JKS Keystore and PKCS12 Keystore impls and looks like it is not compliant with the KeyStoreSpi spec. I think you need to modify the methods to return null, etc instead if the keystore has not been loaded yet. >>> >>> The KeyStore methods handle the test for an uninitialised keystore (before the KeyStoreSpi methods are called). >>> >>> >>>> >>>> --Sean >>>> >>>> On 12/02/2014 06:23 AM, Vincent Ryan wrote: >>>>> >>>>> Please review the following enhancement to improve keystore security by creating PKCS12 keystores by default. >>>>> Previously, JKS keystores were created by default. PKCS12 has the advantage of supporting stronger crypto >>>>> and hashing algorithms. It is also an open, extensible format and supports associating arbitrary attributes with >>>>> keystore entries. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8044445/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044445 >>>>> >>>>> >>>>> To assist with compatibility across JDK releases, both JKS and PKCS12 keystore implementations have been >>>>> extended to support both file formats. Applications that access keystores created by earlier releases should >>>>> require no code changes. >>>>> >>>>> This changeset also includes a new convenience method for instantiating a file-based keystore: KeyStore.getInstance >>>>> - it takes a File argument. The specified file is probed by each supported keystore implementation to determine its >>>>> keystore type. KeyStoreSpi has been enhanced with a boolean engineProbe method to perform the actual probing. >>>>> >>>>> Finally, to improve performance, the PKCS12 keystore implementation has been moved from the SunJSSE provider >>>>> to the SUN provider (as it appears earlier in the default list of installed JCE providers). >>>>> >>> >> From sean.mullan at oracle.com Wed Dec 17 18:59:54 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Dec 2014 13:59:54 -0500 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> Message-ID: <5491D2AA.3000403@oracle.com> On 12/16/2014 07:12 PM, Vincent Ryan wrote: > I?ve generated a new webrev to address your comments below: > http://cr.openjdk.java.net/~vinnie/8044445/webrev.04/ > > Thanks. > > > On 16 Dec 2014, at 21:11, Sean Mullan wrote: > >> Here are my comments on the latest webrev: >> >> * General >> >> - for the engineProbe methods, if a DataInputStream is not specified, I think you should wrap the stream in a DataInputStream, rather than returning false. > > KeyStore.getInstance(File,?) always supplies a DataInputStream to KeyStoreSpi.engineProbe > so it is not necessary to wrap. That's an implementation detail though. Another vendor's implementation of the new KeyStore.getInstance methods may not do that. If you want to guarantee that, you should change the InputStream parameter of the engineProbe method to a DataInputStream. Unless you think engineProbe may be called/used in other circumstances where a DataInputStream is not appropriate, which in that case you change the subclasses to do an instanceof and wrap it. >> * keytool/Main >> >> - can you explain more about why the provider is ignored on lines 812-817, 1919-1925? This doesn't seem like it is compliant with keytool -- if a provider is specified, it should be used. > > The probing mechanism is better equipped to determine the exact keystore type. > > For example, if an application specifies no -storetype option then it implicitly gets the > default keystore type which now differs between JDK 9 and earlier releases. > The new compatibility mode can handle this scenario so that the application doesn?t > break. However, in compatibility mode the instantiated keystore type might not match > the keystore format. > > Whereas when probing is employed the instantiated keystore type always matches > the keystore format. Ok, but I think you should do that only if both a provider and storetype are not specified. If the -providerName option is specified, you need to honor that. It looks like the code is not doing that right now. --Sean From vincent.x.ryan at oracle.com Wed Dec 17 20:08:45 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 17 Dec 2014 20:08:45 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <5491D2AA.3000403@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> Message-ID: On 17 Dec 2014, at 18:59, Sean Mullan wrote: > On 12/16/2014 07:12 PM, Vincent Ryan wrote: >> I?ve generated a new webrev to address your comments below: >> http://cr.openjdk.java.net/~vinnie/8044445/webrev.04/ >> >> Thanks. >> >> >> On 16 Dec 2014, at 21:11, Sean Mullan wrote: >> >>> Here are my comments on the latest webrev: >>> >>> * General >>> >>> - for the engineProbe methods, if a DataInputStream is not specified, I think you should wrap the stream in a DataInputStream, rather than returning false. >> >> KeyStore.getInstance(File,?) always supplies a DataInputStream to KeyStoreSpi.engineProbe >> so it is not necessary to wrap. > > That's an implementation detail though. Another vendor's implementation of the new KeyStore.getInstance methods may not do that. If you want to guarantee that, you should change the InputStream parameter of the engineProbe method to a DataInputStream. Unless you think engineProbe may be called/used in other circumstances where a DataInputStream is not appropriate, which in that case you change the subclasses to do an instanceof and wrap it. OK that makes sense. I?ll wrap it. > >>> * keytool/Main >>> >>> - can you explain more about why the provider is ignored on lines 812-817, 1919-1925? This doesn't seem like it is compliant with keytool -- if a provider is specified, it should be used. >> >> The probing mechanism is better equipped to determine the exact keystore type. >> >> For example, if an application specifies no -storetype option then it implicitly gets the >> default keystore type which now differs between JDK 9 and earlier releases. >> The new compatibility mode can handle this scenario so that the application doesn?t >> break. However, in compatibility mode the instantiated keystore type might not match >> the keystore format. >> >> Whereas when probing is employed the instantiated keystore type always matches >> the keystore format. > > Ok, but I think you should do that only if both a provider and storetype are not specified. If the -providerName option is specified, you need to honor that. It looks like the code is not doing that right now. Sorry, I misread your previous comment. I thought you were asking why the storetype is ignored. I hadn?t considered the impact of the -providerName option. I?ll make that change. > > --Sean From valerie.peng at oracle.com Wed Dec 17 23:18:01 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 17 Dec 2014 15:18:01 -0800 Subject: [9] RFR 8043349: Consider adding aliases for Ucrypto algorithm-only Cipher transformations. Message-ID: <54920F29.8060604@oracle.com> Hi, Brad, Can you please review this straightforward Ucrypto fix? This is about adding aliases to the AES and RSA ciphers of OracleUcrypto provider. Webrev: http://cr.openjdk.java.net/~valeriep/8043349/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8043349 Thanks, Valerie From bradford.wetmore at oracle.com Wed Dec 17 23:36:07 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 17 Dec 2014 15:36:07 -0800 Subject: [9] RFR 8043349: Consider adding aliases for Ucrypto algorithm-only Cipher transformations. In-Reply-To: <54920F29.8060604@oracle.com> References: <54920F29.8060604@oracle.com> Message-ID: <54921367.1010109@oracle.com> I think this is ok. I have a recollection our Cipher.getInstance() provider selection mechanism (getTransforms()) allows for missing options: "AES//NoPadding" "AES/ECB/" But it's been a while since I've looked at this. These ucrypto values look like they must be completely specified. Is that something to look into for down the road? One other point, is there a reason why we're not including the Supported* values in ucrypto? Brad On 12/17/2014 3:18 PM, Valerie Peng wrote: > Hi, Brad, > > Can you please review this straightforward Ucrypto fix? This is about > adding aliases to the AES and RSA ciphers of OracleUcrypto provider. > > Webrev: http://cr.openjdk.java.net/~valeriep/8043349/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8043349 > > Thanks, > Valerie From vincent.x.ryan at oracle.com Wed Dec 17 23:58:09 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 17 Dec 2014 23:58:09 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> Message-ID: <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> FYI I?ve updated the webrev to include the changes below: http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ On 17 Dec 2014, at 20:08, Vincent Ryan wrote: > On 17 Dec 2014, at 18:59, Sean Mullan wrote: > >> On 12/16/2014 07:12 PM, Vincent Ryan wrote: >>> I?ve generated a new webrev to address your comments below: >>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.04/ >>> >>> Thanks. >>> >>> >>> On 16 Dec 2014, at 21:11, Sean Mullan wrote: >>> >>>> Here are my comments on the latest webrev: >>>> >>>> * General >>>> >>>> - for the engineProbe methods, if a DataInputStream is not specified, I think you should wrap the stream in a DataInputStream, rather than returning false. >>> >>> KeyStore.getInstance(File,?) always supplies a DataInputStream to KeyStoreSpi.engineProbe >>> so it is not necessary to wrap. >> >> That's an implementation detail though. Another vendor's implementation of the new KeyStore.getInstance methods may not do that. If you want to guarantee that, you should change the InputStream parameter of the engineProbe method to a DataInputStream. Unless you think engineProbe may be called/used in other circumstances where a DataInputStream is not appropriate, which in that case you change the subclasses to do an instanceof and wrap it. > > OK that makes sense. I?ll wrap it. > > >> >>>> * keytool/Main >>>> >>>> - can you explain more about why the provider is ignored on lines 812-817, 1919-1925? This doesn't seem like it is compliant with keytool -- if a provider is specified, it should be used. >>> >>> The probing mechanism is better equipped to determine the exact keystore type. >>> >>> For example, if an application specifies no -storetype option then it implicitly gets the >>> default keystore type which now differs between JDK 9 and earlier releases. >>> The new compatibility mode can handle this scenario so that the application doesn?t >>> break. However, in compatibility mode the instantiated keystore type might not match >>> the keystore format. >>> >>> Whereas when probing is employed the instantiated keystore type always matches >>> the keystore format. >> >> Ok, but I think you should do that only if both a provider and storetype are not specified. If the -providerName option is specified, you need to honor that. It looks like the code is not doing that right now. > > Sorry, I misread your previous comment. I thought you were asking why the storetype is ignored. > I hadn?t considered the impact of the -providerName option. I?ll make that change. > > >> >> --Sean > From valerie.peng at oracle.com Wed Dec 17 23:58:11 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 17 Dec 2014 15:58:11 -0800 Subject: [9] RFR 8043349: Consider adding aliases for Ucrypto algorithm-only Cipher transformations. In-Reply-To: <54921367.1010109@oracle.com> References: <54920F29.8060604@oracle.com> <54921367.1010109@oracle.com> Message-ID: <54921893.4010602@oracle.com> Thanks for the review~ Well, as for allowing the missing options, I am not sure how useful or how frequently people use them. As for me, I find them a bit too ambiguous to my liking. I think there are other more useful bugs to fix than spending time on this. So far, no bug report regarding support for missing options, thus, no plan for looking into this (yet). As for not including the Supported* values, it's mostly due to priorities and effort trade-offs. For example, updating the Ucrypto provider w/ latest list of supported Solaris algos would happen before adding them... Thanks, Valerie On 12/17/2014 3:36 PM, Bradford Wetmore wrote: > I think this is ok. > > I have a recollection our Cipher.getInstance() provider selection > mechanism (getTransforms()) allows for missing options: > "AES//NoPadding" "AES/ECB/" But it's been a while since I've looked > at this. These ucrypto values look like they must be completely > specified. Is that something to look into for down the road? > > One other point, is there a reason why we're not including the > Supported* values in ucrypto? > > Brad > > > > On 12/17/2014 3:18 PM, Valerie Peng wrote: >> Hi, Brad, >> >> Can you please review this straightforward Ucrypto fix? This is about >> adding aliases to the AES and RSA ciphers of OracleUcrypto provider. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8043349/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043349 >> >> Thanks, >> Valerie From weijun.wang at oracle.com Thu Dec 18 01:52:54 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 18 Dec 2014 09:52:54 +0800 Subject: New switch suggestion for keytool In-Reply-To: <20141216233245.GA21860@mhcomputing.net> References: <89A7EF74-03C8-4E37-BA55-DD2F9EB2EBBC@oracle.com> <20141215201931.GA806@mhcomputing.net> <20141216233245.GA21860@mhcomputing.net> Message-ID: <7D75C160-0C6F-4F23-B345-14BA4A4AD867@oracle.com> > On Dec 17, 2014, at 07:32, Matthew Hall wrote: > >>> Many StackOverflows exist of people doing it manually to "work around" this >>> limitation. >> >> In fact, I searched for "create empty keystore" on stackoverflow and didn't >> notice such a requirement. > > The ones I ran across were for PKCS#11 using the NSS C-code tools because I > had to be FIPS compliant. But it'd be nice if Java's tools supported it too. Can you show me some? Thanks Max From xuelei.fan at oracle.com Thu Dec 18 02:38:47 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 18 Dec 2014 10:38:47 +0800 Subject: [9] RFR 8049312: AES/CICO test failed with on several modes In-Reply-To: <54890D94.8090003@oracle.com> References: <53C9A9D8.1060109@oracle.com> <53F7AD0D.8050601@oracle.com> <54890D94.8090003@oracle.com> Message-ID: <54923E37.6020206@oracle.com> Looks fine to me. Sorry for the delay of the code review. Xuelei On 12/11/2014 11:20 AM, Valerie Peng wrote: > > Still looking for a reviewer for this fix... > > Thanks, > Valerie > > On 8/22/2014 1:50 PM, Valerie Peng wrote: >> Ping again. Anyone has time to review? >> >> The webrev has been updated in place for >> 1) to reflect the new modular path >> 2) update of test/ProblemList.txt given the integration of the failed >> test (done in a separate bug fix which adds bunch of new tests). >> >> The main changes are in CipherCore.java to pass the correct data size >> when calling cipher.encrypt/decrypt(...). >> Also, updated the various modes implementation so that an Exception is >> thrown if data with incorrect length are passed. This is to make the >> code more robust. >> >> Thanks, >> Valerie >> >> On 7/18/2014 4:12 PM, Valerie Peng wrote: >>> >>> Can someone please help reviewing this following fix? >>> https://bugs.openjdk.java.net/browse/JDK-8049312 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8049312/webrev.00/ >>> >>> The must-fix change is in || >>> src/share/classes/com/sun/crypto/provider/CipherCore.java which is to >>> correct the data size calculation based on "unitBytes". For example, >>> for CFB24, our current impl assumes the given data will be multiples >>> of 3 bytes. When the given data isn't multiples of 3, it will >>> continue but then the result is incorrect. >>> >>> To make the code more robust, I think we should explicitly check and >>> error out when the given data doesn't have the correct size. Thus, I >>> have added the input-length check to the various mode >>> implementations. Along the way, I also fixed javadoc typos, removed >>> redundancies, etc. >>> >>> Thanks, >>> Valerie >>> From weijun.wang at oracle.com Thu Dec 18 06:52:38 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 18 Dec 2014 14:52:38 +0800 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> Message-ID: <3D7BA13E-2419-43A7-A5ED-FB5378338877@oracle.com> > On Dec 18, 2014, at 07:58, Vincent Ryan wrote: > > FYI I?ve updated the webrev to include the changes below: > http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ PKCS12KeyStore.PKCS12_HEADER_PATTERNS. Is there a possibility for this? 30 82 -- -- 02 01 03 30 81 -- 06 09 2A 86 48 86 F7 0D 01 07 01 A0 -- 04 That is to say, the length of ContentInfo is only slight smaller than 128. My understanding this is more likely than existing pattern #5 and #6. KeyStore.getInstance(file,pass,param,hasP): It seems if one engineProbe() returns true but loading fails you will try the next storetype. Right? If so, dataStream.reset() should be called. Thanks Max From peter.levart at gmail.com Thu Dec 18 13:23:35 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 18 Dec 2014 14:23:35 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors Message-ID: <5492D557.2000807@gmail.com> Hi, I propose a patch for the following issue: https://bugs.openjdk.java.net/browse/JDK-8047769 Here's the webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/ The patch uses a package-private FileInputStreamPool class that caches open FileInputStream(s) so that at most one file descriptor is open for a particular file. Reading from shared unbuffered FileInputStream in multiple threads should be safe, right? If not, some synchronization on Java side will be necessary. This should not impact concurrent performance much since we are using the streams to read from /dev/random or /dev/urandom which are secure random generators with shared state and must therefore have their own internal synchronization. 52 jtreg tests in sun/security/provider pass with or without this patch, 3 tests that fail are: sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java: Make sure that when no system policy and user policy files exist, the built-in default policy will be used, which - amongst other things - grants standard extensions the AllPermission. sun/security/provider/PolicyParser/ExtDirsChange.java: standard extensions path is hard-coded in default system policy file sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser incorrectly ignores a principal if the principal name expands to nothing. ...they are unrelated to this patch - seems to be caused by recent layout changes for modular runtime images. Regards, Peter From vincent.x.ryan at oracle.com Thu Dec 18 14:12:47 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 18 Dec 2014 14:12:47 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <3D7BA13E-2419-43A7-A5ED-FB5378338877@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <3D7BA13E-2419-43A7-A5ED-FB5378338877@oracle.com> Message-ID: <54096504-2018-45BA-AA47-053DE69C71E5@oracle.com> Thanks for reviewing, Max. On 18 Dec 2014, at 06:52, Wang Weijun wrote: > >> On Dec 18, 2014, at 07:58, Vincent Ryan wrote: >> >> FYI I?ve updated the webrev to include the changes below: >> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ > > PKCS12KeyStore.PKCS12_HEADER_PATTERNS. > > Is there a possibility for this? > > 30 82 -- -- 02 01 03 30 81 -- 06 09 2A 86 48 86 F7 0D 01 07 01 A0 -- 04 > > That is to say, the length of ContentInfo is only slight smaller than 128. My understanding this is more likely than existing pattern #5 and #6. In theory it may be possible but the smallest non-empty content that I could generate was about 200 bytes. Do you have an example? > > > KeyStore.getInstance(file,pass,param,hasP): > > It seems if one engineProbe() returns true but loading fails you will try the next storetype. Right? If so, dataStream.reset() should be called. No. If loading fails then an exception is thrown - no further storetypes are checked. > > Thanks > Max > From weijun.wang at oracle.com Thu Dec 18 14:59:43 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 18 Dec 2014 22:59:43 +0800 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <54096504-2018-45BA-AA47-053DE69C71E5@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <3D7BA13E-2419-43A7-A5ED-FB5378338877@oracle.com> <54096504-2018-45BA-AA47-053DE69C71E5@oracle.com> Message-ID: > On Dec 18, 2014, at 22:12, Vincent Ryan wrote: > > Thanks for reviewing, Max. > > > On 18 Dec 2014, at 06:52, Wang Weijun wrote: > >> >>> On Dec 18, 2014, at 07:58, Vincent Ryan wrote: >>> >>> FYI I?ve updated the webrev to include the changes below: >>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ >> >> PKCS12KeyStore.PKCS12_HEADER_PATTERNS. >> >> Is there a possibility for this? >> >> 30 82 -- -- 02 01 03 30 81 -- 06 09 2A 86 48 86 F7 0D 01 07 01 A0 -- 04 >> >> That is to say, the length of ContentInfo is only slight smaller than 128. My understanding this is more likely than existing pattern #5 and #6. > > In theory it may be possible but the smallest non-empty content that I could generate was about 200 bytes. Oh, so #2 is reserved for an empty keystore. :-) > Do you have an example? No. I tried to store a DES key there but see "NoSuchAlgorithmException: unrecognized algorithm name: DES". Maybe DES is obsolete? What would be the size if another tool creates a DES key? Will it be small enough? I use keytool to -genseckey an AES key, ContentInfo has size D0. A little bigger. > KeyStore.getInstance(file,pass,param,hasP): >> >> It seems if one engineProbe() returns true but loading fails you will try the next storetype. Right? If so, dataStream.reset() should be called. > > No. If loading fails then an exception is thrown - no further storetypes are checked. I see. I thought new KeyStore(impl, (Provider)objs[1], type) could throw some exception. That's where I called "loading". --Max > > >> >> Thanks >> Max >> > From sean.mullan at oracle.com Thu Dec 18 15:02:03 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Dec 2014 10:02:03 -0500 Subject: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled In-Reply-To: <54908BAD.3010700@oracle.com> References: <54908BAD.3010700@oracle.com> Message-ID: <5492EC6B.10000@oracle.com> Just a few comments: - some of the methods (encodePoint, trimZeroes, ...) can be made private static. 451: if getCurveOid returns null, you should throw MarshalException instead of outputting a null Oid 486: if getECParameterSpec returns null, you should throw MarshalException (otherwise an NPE would be thrown on line 498) 520,524: these methods should be private --Sean On 12/16/2014 02:44 PM, Jason Uh wrote: > Please review this fix, which allows XML Signature ECKeyValue elements > to be marshalled and unmarshalled. > > Dependence on internal sun.security.* classes has been removed, so that > the (un)marshalling can happen without reflection. > > webrev: http://cr.openjdk.java.net/~juh/8046724/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8046724 > > A corresponding test will be added to the closed repository. > > Thanks, > Jason From vincent.x.ryan at oracle.com Thu Dec 18 15:09:32 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 18 Dec 2014 15:09:32 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <3D7BA13E-2419-43A7-A5ED-FB5378338877@oracle.com> <54096504-2018-45BA-AA47-053DE69C71E5@oracle.com> Message-ID: The smallest content I could generate using keytool was 200 bytes: a 1-byte password. 0000000 3082011b 02010330 81d60609 2a864886 0000020 f70d0107 01a081c8 0481c530 81c23081 0000040 bf06092a 864886f7 0d010701 a081b104 0000060 81ae3081 ab3081a8 060b2a86 4886f70d 0000100 010c0a01 05a05930 57060b2a 864886f7 0000120 0d010c0a 0102a048 04463044 3028060a 0000140 2a864886 f70d010c 0103301a 04147856 0000160 a3689d4b e55469af fbfa2a41 d5d3ce1d 0000200 81360202 04000418 7867f3fc a91b9a1b 0000220 7b863cc5 7e89e11e db14739a e623462c 0000240 313e3019 06092a86 4886f70d 01091431 0000260 0c1e0a00 6d007900 6b006500 79302106 0000300 092a8648 86f70d01 09153114 04125469 0000320 6d652031 34313839 30383339 32363333 0000340 303d3021 30090605 2b0e0302 1a050004 0000360 144a9a2f f169cbdc 65e31b6e fd5d25a8 0000400 a7096207 55041433 c18e4ee1 0ee7fc7f 0000420 4e0177a3 f7248ac0 9484bd02 02040000 0000437 On 18 Dec 2014, at 14:59, Wang Weijun wrote: > >> On Dec 18, 2014, at 22:12, Vincent Ryan wrote: >> >> Thanks for reviewing, Max. >> >> >> On 18 Dec 2014, at 06:52, Wang Weijun wrote: >> >>> >>>> On Dec 18, 2014, at 07:58, Vincent Ryan wrote: >>>> >>>> FYI I?ve updated the webrev to include the changes below: >>>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ >>> >>> PKCS12KeyStore.PKCS12_HEADER_PATTERNS. >>> >>> Is there a possibility for this? >>> >>> 30 82 -- -- 02 01 03 30 81 -- 06 09 2A 86 48 86 F7 0D 01 07 01 A0 -- 04 >>> >>> That is to say, the length of ContentInfo is only slight smaller than 128. My understanding this is more likely than existing pattern #5 and #6. >> >> In theory it may be possible but the smallest non-empty content that I could generate was about 200 bytes. > > Oh, so #2 is reserved for an empty keystore. :-) > >> Do you have an example? > > No. I tried to store a DES key there but see "NoSuchAlgorithmException: unrecognized algorithm name: DES". Maybe DES is obsolete? What would be the size if another tool creates a DES key? Will it be small enough? > > I use keytool to -genseckey an AES key, ContentInfo has size D0. A little bigger. > >> KeyStore.getInstance(file,pass,param,hasP): >>> >>> It seems if one engineProbe() returns true but loading fails you will try the next storetype. Right? If so, dataStream.reset() should be called. >> >> No. If loading fails then an exception is thrown - no further storetypes are checked. > > I see. I thought new KeyStore(impl, (Provider)objs[1], type) could throw some exception. That's where I called "loading". > > --Max > >> >> >>> >>> Thanks >>> Max >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Thu Dec 18 16:01:52 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 18 Dec 2014 16:01:52 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <3D7BA13E-2419-43A7-A5ED-FB5378338877@oracle.com> <54096504-2018-45BA-AA47-053DE69C71E5@oracle.com> Message-ID: <85B32D01-FAA2-4D99-9091-1BF5236755F1@oracle.com> On 18 Dec 2014, at 14:59, Wang Weijun wrote: > >> On Dec 18, 2014, at 22:12, Vincent Ryan wrote: >> >> Thanks for reviewing, Max. >> >> >> On 18 Dec 2014, at 06:52, Wang Weijun wrote: >> >>> >>>> On Dec 18, 2014, at 07:58, Vincent Ryan wrote: >>>> >>>> FYI I?ve updated the webrev to include the changes below: >>>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ >>> >>> PKCS12KeyStore.PKCS12_HEADER_PATTERNS. >>> >>> Is there a possibility for this? >>> >>> 30 82 -- -- 02 01 03 30 81 -- 06 09 2A 86 48 86 F7 0D 01 07 01 A0 -- 04 >>> >>> That is to say, the length of ContentInfo is only slight smaller than 128. My understanding this is more likely than existing pattern #5 and #6. >> >> In theory it may be possible but the smallest non-empty content that I could generate was about 200 bytes. > > Oh, so #2 is reserved for an empty keystore. :-) > >> Do you have an example? > > No. I tried to store a DES key there but see "NoSuchAlgorithmException: unrecognized algorithm name: DES". Maybe DES is obsolete? What would be the size if another tool creates a DES key? Will it be small enough? > > I use keytool to -genseckey an AES key, ContentInfo has size D0. A little bigger. > >> KeyStore.getInstance(file,pass,param,hasP): >>> >>> It seems if one engineProbe() returns true but loading fails you will try the next storetype. Right? If so, dataStream.reset() should be called. >> >> No. If loading fails then an exception is thrown - no further storetypes are checked. > > I see. I thought new KeyStore(impl, (Provider)objs[1], type) could throw some exception. That's where I called "loading?. I thought you were referring to keystore.load, which is called later. However, you are right, it would be safer to move the reset call out of the try block and beyond the 2 catch blocks so that probing can continue if the keystore cannot be instantiated. > > --Max > >> >> >>> >>> Thanks >>> Max >>> >> > From sean.mullan at oracle.com Thu Dec 18 18:18:40 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Dec 2014 13:18:40 -0500 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> Message-ID: <54931A80.4040906@oracle.com> On 12/17/2014 06:58 PM, Vincent Ryan wrote: > FYI I?ve updated the webrev to include the changes below: > http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ > The updated webrev looks good. --Sean From bradford.wetmore at oracle.com Thu Dec 18 22:03:07 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 18 Dec 2014 14:03:07 -0800 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <5492D557.2000807@gmail.com> References: <5492D557.2000807@gmail.com> Message-ID: <54934F1B.6060900@oracle.com> Peter, Thanks for looking into this. I'll in the middle of reviewing your change (and TLR/SplittableRandom reply), but have several appointments over the next few days. But did want to respond to: > sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java: > Make sure that when no system policy and user policy files exist, the > built-in default policy will be used, which - amongst other things - > grants standard extensions the AllPermission. > sun/security/provider/PolicyParser/ExtDirsChange.java: standard > extensions path is hard-coded in default system policy file > sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser > incorrectly ignores a principal if the principal name expands to nothing. > > ...they are unrelated to this patch - seems to be caused by recent > layout changes for modular runtime images. They've been failing for a while: https://bugs.openjdk.java.net/browse/JDK-8039280 These tests are all "/manual" so they don't show up in our regular runs of JPRT/jtreg, which include -a. -a | -automatic | -automagic Any test with /manual will not be run Thanks, Brad From vincent.x.ryan at oracle.com Fri Dec 19 13:01:41 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 19 Dec 2014 13:01:41 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <54931A80.4040906@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <54931A80.4040906@oracle.com> Message-ID: Thanks Sean. I have a testcase that I?d like to add to the changeset. I?ll send that out later today. On 18 Dec 2014, at 18:18, Sean Mullan wrote: > On 12/17/2014 06:58 PM, Vincent Ryan wrote: >> FYI I?ve updated the webrev to include the changes below: >> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ >> > > The updated webrev looks good. > > --Sean From vincent.x.ryan at oracle.com Fri Dec 19 16:43:45 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 19 Dec 2014 16:43:45 +0000 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <54931A80.4040906@oracle.com> Message-ID: <17800439-65AD-4CB7-B1CA-2A086B5BAD8A@oracle.com> Here?s the (hopefully) final webrev, it includes a testcase to exercise the new KeyStore methods: http://cr.openjdk.java.net/~vinnie/8044445/webrev.06/ On 19 Dec 2014, at 13:01, Vincent Ryan wrote: > Thanks Sean. I have a testcase that I?d like to add to the changeset. I?ll send that out later today. > > > On 18 Dec 2014, at 18:18, Sean Mullan wrote: > >> On 12/17/2014 06:58 PM, Vincent Ryan wrote: >>> FYI I?ve updated the webrev to include the changes below: >>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ >>> >> >> The updated webrev looks good. >> >> --Sean > From sean.mullan at oracle.com Fri Dec 19 19:54:26 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 19 Dec 2014 14:54:26 -0500 Subject: [9] request for review 8044445: Create PKCS12 Keystores by Default In-Reply-To: <17800439-65AD-4CB7-B1CA-2A086B5BAD8A@oracle.com> References: <6AAFFE99-9F9E-4156-8F62-E3EF70B29A9B@oracle.com> <547DD669.7010808@oracle.com> <7C4D0493-20C2-4D6E-A4D4-A0C7C25EEF47@oracle.com> <54909FF4.9020404@oracle.com> <5491D2AA.3000403@oracle.com> <1D492B68-969C-4C6F-9033-15B3031BD81C@oracle.com> <54931A80.4040906@oracle.com> <17800439-65AD-4CB7-B1CA-2A086B5BAD8A@oracle.com> Message-ID: <54948272.7030703@oracle.com> On 12/19/2014 11:43 AM, Vincent Ryan wrote: > Here?s the (hopefully) final webrev, it includes a testcase to exercise the new KeyStore methods: > http://cr.openjdk.java.net/~vinnie/8044445/webrev.06/ The new test looks fine to me. --Sean > > > On 19 Dec 2014, at 13:01, Vincent Ryan wrote: > >> Thanks Sean. I have a testcase that I?d like to add to the changeset. I?ll send that out later today. >> >> >> On 18 Dec 2014, at 18:18, Sean Mullan wrote: >> >>> On 12/17/2014 06:58 PM, Vincent Ryan wrote: >>>> FYI I?ve updated the webrev to include the changes below: >>>> http://cr.openjdk.java.net/~vinnie/8044445/webrev.05/ >>>> >>> >>> The updated webrev looks good. >>> >>> --Sean >> > From jeffrey.nisewanger at oracle.com Sat Dec 20 00:47:36 2014 From: jeffrey.nisewanger at oracle.com (Jeff Nisewanger) Date: Fri, 19 Dec 2014 16:47:36 -0800 Subject: Further Defenses for the Security Manager In-Reply-To: <5450ED3A.6050801@andrew.cmu.edu> References: <5450ED3A.6050801@andrew.cmu.edu> Message-ID: <5D4ABD71-AAA1-4EFE-A154-A5B0EC9B8FA9@oracle.com> Thank you for contacting us and sharing the initial results of your research. You raised two basic topics. First, you discussed the possibility of adding additional restrictions on the ability to change the system Security Manager multiple times during application execution. This is normally already subject to a security check but there might be malicious exploits that bypass the existing check. It turns out that we are already independently investigating this topic. We agree that such a restriction likely requires additional assistance from the JVM implementation for several reasons. As you mentioned, an important aspect to such a change is to minimize backwards compatibility problems. Your research on the use of security managers by existing Java applications is interesting and useful. You also suggested the general idea that whenever a new class is loaded we should check the granted permissions of the classes containing the methods on the thread call stack. You propose to ensure that each such class on the call stack has already itself been granted a superset of the permissions that would be granted to the newly loaded class. However, you would not enforce this general rule for common cases such as classes loaded by the bootstrap loader or classes within the list of restricted package names. Does your proposal take into account any calls to AccessController.doPrivileged() on the thread call stack? Could a thread shortcut this proposed check by causing it's action to take place on another thread (create a new thread to initiate the class loading)? The Java Virtual Machine specification allows for class loading to be initiated in a flexible manner that may have only a tangential relationship to the members of a thread's call stack. Examples include: 1. When a class is being loaded the JVM resolves the names of the superclass or super interfaces 2. Constant pool resolution during the execution of a bytecode instruction in a class that refers symbolically to a named class type. 3. Bytecode verification of another class which is in the process of being loaded. To ensure type-safety, the verifier may sometimes load other classes recursively that are symbolically referenced by a bytecode instruction (before any of the code in the class being verified is ever executed normally). 4. Direct calls to Class.forName(), ClassLoader.loadClass() or perhaps somehow maliciously to ClassLoader.defineClass(). Also, according to the specification, the JVM is free to spontaneously "pre-load" classes whenever it feels like it even if those classes have no apparent relationship with the thread chosen to load them. For this reason, Java class loading is generally independent of thread context except for the immediate class in which a constant pool resolution is being performed which is subject, for example, to the language-level access controls (public, protected, etc.) of the class it is referencing. Thanks, Jeff > On Oct 29, 2014, at 6:35 AM, Michael Maass wrote: > > Hello All, > > I've spent the last 6 months working with some colleagues on a project that aimed to stop an exploitation avenue that has been popular with recent Java exploits: disabling the security manager. We think that what ended up with may be worthy of a JEP and/or a prototype implementation in the JVM; we're looking for feedback from the experts, you folks. > > We initially set out to determine how benign applications interact with the security manager and to determine how those interactions differ from malicious ones. The idea was that an investigation aimed at making these determinations could show us ways to constrain operations on the manager that are backwards compatible with benign applications while blocking exploits. > > After investigating the open source Java landscape we learned to distinguish between (1) "self-protecting" and "defenseless" security managers and (2) the operations that may be performed in the presence of each. A defenseless manager enforces a policy that uses at least one permission in a set of permissions we identified that allow anyone to change the manager itself or the policy it enforces (a self-protecting manager is the opposite of a defenseless manager). Given this definition, we found that enforcing the following rules stopped known exploits without impeding (aside from overhead) the execution of benign applications: > > 1. If a self-protecting manager is set, a class may not load or cause the loading of a class more privileged than itself unless the loaded class is in a protected package (listed in the package.access property in java.security.Security). > > 2. If a self-protecting manager is set, an application may not change the security manager or the enforced policy in any way. > > We built a JVMTI agent to enforce these rules (available here: https://github.com/SecurityManagerCodeBase/JavaSandboxFortifier). Unfortunately, to use the JVMTI events that allow us to enforce rule 2, the JIT must be off, which drastically slows down the execution of applets in the presence of our agent. Rule 1 adds about 1-2% overhead. We believe overhead would drop enough for adoption if the JVM were to natively enforce these rules instead of using an agent, but we do not have the resources or the expertise to try this ourselves. > > Any thoughts on whether or not this type of change is worth pursing in the form of a JEP and/or prototype in the JVM? If so, is anyone willing and able to help? > > Thanks, > > Michael Maass, PhD Candidate > Software Engineering > Institute for Software Research > School of Computer Science > Carnegie Mellon University From zaiyao.liu at oracle.com Mon Dec 22 03:11:38 2014 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Mon, 22 Dec 2014 11:11:38 +0800 Subject: Review request for CR 8044193 Need to add known answer tests for AES cipher In-Reply-To: <53E129B4.3070200@oracle.com> References: <53D607D2.7040809@oracle.com> <53D724DF.6060404@oracle.com> <53E129B4.3070200@oracle.com> Message-ID: <54978BEA.1050702@oracle.com> Hi Valeries, Thanks for review, please check the update: http://cr.openjdk.java.net/~rhalade/8044193/webrev.02/ Regards. Kevin ? 2014/8/6 3:00, Valerie Peng ??: > > The tests look fine. > However, can you please update the test policy files with fine-grained > permissions for SunJCE provider? > Please refer to the current /lib/security/java.policy. > > Thanks, > Valerie > > On 7/28/2014 9:36 PM, zaiyao liu wrote: >> Hello, >> Please help to review the tests for AES cipher. >> This tests test AES ciphers with different modes and padding >> schemes when provider change,are part of tests for bug 8044193(Open >> part) >> Bug - https://bugs.openjdk.java.net/browse/JDK-8044193 >> webrev- http://cr.openjdk.java.net/~rhalade/8044193/webrev.00/ >> >> Thanks >> >> Kevin Liu From artem.smotrakov at oracle.com Mon Dec 22 11:29:49 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 22 Dec 2014 14:29:49 +0300 Subject: RFR: 8048603: Additional tests for MAC algorithms In-Reply-To: <548F62E2.7020803@oracle.com> References: <545C99D6.2090200@oracle.com> <54896F30.6050802@oracle.com> <548F62E2.7020803@oracle.com> Message-ID: <549800AD.4050303@oracle.com> Hi Valerie, I have updated the webrev, please take a look. http://cr.openjdk.java.net/~asmotrak/8048603/webrev.02/ Artem On 12/16/2014 01:38 AM, Valerie Peng wrote: > Artem, > > Here are my comments: > 1) Three tests under com/sun/crypto/provider directory do not specify > a provider when calling Mac.getInstance(). Since they are under the > regression tests directory for SunJCE, perhaps we should specify > SunJCE provider to be used. > 2) 'ALGORITHMS' seems redundant for > sun/security/pkcs11/Mac/MacSameTest.java > > Thanks, > Valerie > > On 12/11/2014 2:17 AM, Artem Smotrakov wrote: >> I have addressed a couple of comments from Valerie: >> - updated tests in test/com/sun/crypto/provider/Mac not to test >> SunPKCS11 provider >> - added the following tests for PKCS11 providers >> test/sun/security/pkcs11/Mac/MacKAT.java >> test/sun/security/pkcs11/Mac/MacSameTest.java >> - removed a check that CloneNotSupportedException is thrown on Solaris >> >> Please take a look. >> >> http://cr.openjdk.java.net/~asmotrak/8048603/webrev.01/ >> >> Artem >> >> On 11/07/2014 01:07 PM, Artem Smotrakov wrote: >>> Please review a couple of new test cases for MAC algorithms. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8048603 >>> http://cr.openjdk.java.net/~asmotrak/8048603/webrev.00/ >>> >>> Artem >> From valerie.peng at oracle.com Mon Dec 22 23:53:00 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 22 Dec 2014 15:53:00 -0800 Subject: RFR: 8048603: Additional tests for MAC algorithms In-Reply-To: <549800AD.4050303@oracle.com> References: <545C99D6.2090200@oracle.com> <54896F30.6050802@oracle.com> <548F62E2.7020803@oracle.com> <549800AD.4050303@oracle.com> Message-ID: <5498AEDC.9020505@oracle.com> Updated webrev looks good. Thanks, Valerie On 12/22/2014 3:29 AM, Artem Smotrakov wrote: > Hi Valerie, > > I have updated the webrev, please take a look. > > http://cr.openjdk.java.net/~asmotrak/8048603/webrev.02/ > > Artem > > On 12/16/2014 01:38 AM, Valerie Peng wrote: >> Artem, >> >> Here are my comments: >> 1) Three tests under com/sun/crypto/provider directory do not specify >> a provider when calling Mac.getInstance(). Since they are under the >> regression tests directory for SunJCE, perhaps we should specify >> SunJCE provider to be used. >> 2) 'ALGORITHMS' seems redundant for >> sun/security/pkcs11/Mac/MacSameTest.java >> >> Thanks, >> Valerie >> >> On 12/11/2014 2:17 AM, Artem Smotrakov wrote: >>> I have addressed a couple of comments from Valerie: >>> - updated tests in test/com/sun/crypto/provider/Mac not to test >>> SunPKCS11 provider >>> - added the following tests for PKCS11 providers >>> test/sun/security/pkcs11/Mac/MacKAT.java >>> test/sun/security/pkcs11/Mac/MacSameTest.java >>> - removed a check that CloneNotSupportedException is thrown on Solaris >>> >>> Please take a look. >>> >>> http://cr.openjdk.java.net/~asmotrak/8048603/webrev.01/ >>> >>> Artem >>> >>> On 11/07/2014 01:07 PM, Artem Smotrakov wrote: >>>> Please review a couple of new test cases for MAC algorithms. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8048603 >>>> http://cr.openjdk.java.net/~asmotrak/8048603/webrev.00/ >>>> >>>> Artem >>> > From bradford.wetmore at oracle.com Tue Dec 23 01:30:08 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 22 Dec 2014 17:30:08 -0800 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <5492D557.2000807@gmail.com> References: <5492D557.2000807@gmail.com> Message-ID: <5498C5A0.50104@oracle.com> Hi Peter, Looks like you have a committer status, will you be pushing this? On 12/18/2014 5:23 AM, Peter Levart wrote: > Hi, > > I propose a patch for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8047769 > > Here's the webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/ Looks good. A few minor comments. In a couple places, there are a few lines > 80 chars. (It's a pet peeve of mine, this makes side-by-side reviews difficult without a wide monitor. I realize not everyone shares this view, but they're probably not working on a laptop screen regularly.) Do you need to close the InputStream when last holder is GC'd, or do we just let the FileInputStream's finalizer take care of that? Both of these current calls are contained within a AccessContrller.doPriviledged, the checkRead() seems redundant. In your test case, if assertions are not enabled, the tests at 46/50/51 are noops, e.g. when run by hand. Generally should directly throw Exceptions. > The patch uses a package-private FileInputStreamPool class that caches > open FileInputStream(s) so that at most one file descriptor is open for > a particular file. Reading from shared unbuffered FileInputStream in > multiple threads should be safe, right? I would think (hope?) so, but I am not 100% sure. I tracked it down into libjava native code: io_util.c ========= fd = GET_FD(this, fid); if (fd == -1) { JNU_ThrowIOException(env, "Stream Closed"); nread = -1; } else { nread = IO_Read(fd, buf, len); which is then defined to handleRead, which calls something called RESTARTABLE in io_util_md.c. Assuming I'm looking at the right code. Core-libs folks? > sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java: > Make sure that when no system policy and user policy files exist, the > built-in default policy will be used, which - amongst other things - > grants standard extensions the AllPermission. > sun/security/provider/PolicyParser/ExtDirsChange.java: standard > extensions path is hard-coded in default system policy file > sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser > incorrectly ignores a principal if the principal name expands to nothing. > > ...they are unrelated to this patch - seems to be caused by recent > layout changes for modular runtime images. Hopefully you saw my previous response. Repeating: ---begin--- They've been failing for a while: https://bugs.openjdk.java.net/browse/JDK-8039280 These tests are all "/manual" so they don't show up in our regular runs of JPRT/jtreg, which include -a. -a | -automatic | -automagic Any test with /manual will not be run ---end--- Thanks, Brad From mala.bankal at oracle.com Tue Dec 23 13:21:59 2014 From: mala.bankal at oracle.com (mala bankal) Date: Tue, 23 Dec 2014 18:51:59 +0530 Subject: Request for review : 7196009-SunPkcs11 provider fails to parse config path containing parenthesis Message-ID: <54996C77.1080408@oracle.com> HI Valerie, All, Request your review for backport of bug 7196009 to 7u-dev. https://bugs.openjdk.java.net/browse/JDK-7196009 webrev: http://cr.openjdk.java.net/~mbankal/7196009/webrev.00/ rgds mala From mala.bankal at oracle.com Tue Dec 23 14:16:35 2014 From: mala.bankal at oracle.com (mala bankal) Date: Tue, 23 Dec 2014 19:46:35 +0530 Subject: Request for review : 8032573 - CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input Message-ID: <54997943.6020706@oracle.com> HI Jamil, All, Request your review for backport of bug# 8032573 to 7u-dev. https://bugs.openjdk.java.net/browse/JDK-8032573 webrev: http://cr.openjdk.java.net/~mbankal/8032573/webrev.00/ rgds mala From gnu.andrew at redhat.com Tue Dec 23 16:13:24 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 23 Dec 2014 11:13:24 -0500 (EST) Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <542D1374.8030608@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> Message-ID: <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Valerie Peng (original author) is probably best suited to reviewing this > but I think she's out of the office the moment and back next week. Let's > hope we can get an update/review then. > Hi, Any movement on this? It's been three months. Thanks. > regards, > Sean. > > On 01/10/2014 16:11, Andrew Hughes wrote: > > ----- Original Message ----- > >> > >> ----- Original Message ----- > >>> Code changes generally require two approvals: codereview, performed by a > >>> reviewer, (in this case from security-dev) and push approval, performed > >>> by a gatekeeper. Given your email template matches the push approval > >>> template I understood that you intended the latter. Generally speaking > >>> codereview requests would say "Request for review" as opposed to > >>> "Request for approval" so a reviewer could overlook your mail if you > >>> intended the former. > >>> > >>> -Rob > >>> > >>> On 18/09/14 00:21, Andrew Hughes wrote: > >>>> ----- Original Message ----- > >>>>> Hi Andrew, > >>>>> > >>>>> Sorry to be a pest, but given the scope of the change I'd feel more > >>>>> comfortable with an explicit codereview for the backport. > >>>>> > >>>>> -Rob > >>>>> > >>>>> On 17/09/14 18:32, Andrew Hughes wrote: > >>>>>> This is the first of three backports to 7u designed to retain SSL > >>>>>> compatibility with servers implemented in other languages switching > >>>>>> to larger key sizes (notably DH >=2048 in Apache 2.4.7 [0]). > >>>>>> > >>>>>> This patch is a per-requisite of the patch which brings NSA Suite B > >>>>>> support to 7. It applies largely unchanged, bar the following: > >>>>>> > >>>>>> * Copyright header adjustment > >>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec to avoid > >>>>>> introducing a new public variable. The SHA-224 variant is constructed > >>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. > >>>>>> * A change to OAEPParameters is dropped as it was already incorporated > >>>>>> in the backport of 7180907 & 8049480 (addition of SHA-224 to > >>>>>> convertToStandardName) > >>>>>> > >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 > >>>>>> Webrev: http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ > >>>>>> > >>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html > >>>>>> > >>>>>> Ok to push? > >>>>>> > >>>>>> Thanks, > >>>> Which is what I asked for, no? > >>>> > >>>> If I wasn't waiting on a review first, I'd have pushed the change. > >>> > >> This was the only applicable template on: > >> > >> http://openjdk.java.net/projects/jdk7u/ > >> > >> Anyway, now including security-dev for review. > >> -- > >> Andrew :) > >> > >> Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >> > >> > > Ping. Any movement on this? > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dalibor.topic at oracle.com Tue Dec 23 16:52:19 2014 From: dalibor.topic at oracle.com (dalibor.topic at oracle.com) Date: Tue, 23 Dec 2014 17:52:19 +0100 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> Message-ID: <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> Considering that the issue was a P3 RFE rather than a high priority bug fix, it's not clear to me why it would be necessary to backport it into 7u80, at the end point in the release cycle. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile:+491737185961 Oracle Java Platform Group 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 Gesch?ftsf?hrer: J?rgen Kunz 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, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment > On 23.12.2014, at 17:13, Andrew Hughes wrote: > > ----- Original Message ----- >> Valerie Peng (original author) is probably best suited to reviewing this >> but I think she's out of the office the moment and back next week. Let's >> hope we can get an update/review then. > > Hi, > > Any movement on this? It's been three months. > > Thanks. > >> regards, >> Sean. >> >>> On 01/10/2014 16:11, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> >>>> ----- Original Message ----- >>>>> Code changes generally require two approvals: codereview, performed by a >>>>> reviewer, (in this case from security-dev) and push approval, performed >>>>> by a gatekeeper. Given your email template matches the push approval >>>>> template I understood that you intended the latter. Generally speaking >>>>> codereview requests would say "Request for review" as opposed to >>>>> "Request for approval" so a reviewer could overlook your mail if you >>>>> intended the former. >>>>> >>>>> -Rob >>>>> >>>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>> ----- Original Message ----- >>>>>>> Hi Andrew, >>>>>>> >>>>>>> Sorry to be a pest, but given the scope of the change I'd feel more >>>>>>> comfortable with an explicit codereview for the backport. >>>>>>> >>>>>>> -Rob >>>>>>> >>>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>> This is the first of three backports to 7u designed to retain SSL >>>>>>>> compatibility with servers implemented in other languages switching >>>>>>>> to larger key sizes (notably DH >=2048 in Apache 2.4.7 [0]). >>>>>>>> >>>>>>>> This patch is a per-requisite of the patch which brings NSA Suite B >>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>> >>>>>>>> * Copyright header adjustment >>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec to avoid >>>>>>>> introducing a new public variable. The SHA-224 variant is constructed >>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>> * A change to OAEPParameters is dropped as it was already incorporated >>>>>>>> in the backport of 7180907 & 8049480 (addition of SHA-224 to >>>>>>>> convertToStandardName) >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>> Webrev: http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>> >>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>> >>>>>>>> Ok to push? >>>>>>>> >>>>>>>> Thanks, >>>>>> Which is what I asked for, no? >>>>>> >>>>>> If I wasn't waiting on a review first, I'd have pushed the change. >>>> This was the only applicable template on: >>>> >>>> http://openjdk.java.net/projects/jdk7u/ >>>> >>>> Anyway, now including security-dev for review. >>>> -- >>>> Andrew :) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> Ping. Any movement on this? > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Tue Dec 23 16:56:48 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 23 Dec 2014 16:56:48 +0000 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> Message-ID: <54999ED0.5090300@oracle.com> Actually, another kink: this requires ccc approval for a backport to 7. -Rob On 23/12/14 16:52, dalibor.topic at oracle.com wrote: > Considering that the issue was a P3 RFE rather than a high priority bug fix, it's not clear to me why it would be necessary to backport it into 7u80, at the end point in the release cycle. > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile:+491737185961 > Oracle Java Platform Group > > 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 > Gesch?ftsf?hrer: J?rgen Kunz > > 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, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed to developing practices and products that help protect the environment > >> On 23.12.2014, at 17:13, Andrew Hughes wrote: >> >> ----- Original Message ----- >>> Valerie Peng (original author) is probably best suited to reviewing this >>> but I think she's out of the office the moment and back next week. Let's >>> hope we can get an update/review then. >> Hi, >> >> Any movement on this? It's been three months. >> >> Thanks. >> >>> regards, >>> Sean. >>> >>>> On 01/10/2014 16:11, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> ----- Original Message ----- >>>>>> Code changes generally require two approvals: codereview, performed by a >>>>>> reviewer, (in this case from security-dev) and push approval, performed >>>>>> by a gatekeeper. Given your email template matches the push approval >>>>>> template I understood that you intended the latter. Generally speaking >>>>>> codereview requests would say "Request for review" as opposed to >>>>>> "Request for approval" so a reviewer could overlook your mail if you >>>>>> intended the former. >>>>>> >>>>>> -Rob >>>>>> >>>>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>>> ----- Original Message ----- >>>>>>>> Hi Andrew, >>>>>>>> >>>>>>>> Sorry to be a pest, but given the scope of the change I'd feel more >>>>>>>> comfortable with an explicit codereview for the backport. >>>>>>>> >>>>>>>> -Rob >>>>>>>> >>>>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>>> This is the first of three backports to 7u designed to retain SSL >>>>>>>>> compatibility with servers implemented in other languages switching >>>>>>>>> to larger key sizes (notably DH >=2048 in Apache 2.4.7 [0]). >>>>>>>>> >>>>>>>>> This patch is a per-requisite of the patch which brings NSA Suite B >>>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>>> >>>>>>>>> * Copyright header adjustment >>>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec to avoid >>>>>>>>> introducing a new public variable. The SHA-224 variant is constructed >>>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>>> * A change to OAEPParameters is dropped as it was already incorporated >>>>>>>>> in the backport of 7180907 & 8049480 (addition of SHA-224 to >>>>>>>>> convertToStandardName) >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>>> >>>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>>> >>>>>>>>> Ok to push? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>> Which is what I asked for, no? >>>>>>> >>>>>>> If I wasn't waiting on a review first, I'd have pushed the change. >>>>> This was the only applicable template on: >>>>> >>>>> http://openjdk.java.net/projects/jdk7u/ >>>>> >>>>> Anyway, now including security-dev for review. >>>>> -- >>>>> Andrew :) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>> Ping. Any movement on this? >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> From rob.mckenna at oracle.com Tue Dec 23 16:57:50 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 23 Dec 2014 16:57:50 +0000 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <54999ED0.5090300@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> <54999ED0.5090300@oracle.com> Message-ID: <54999F0E.1090708@oracle.com> Gah, apologies, forgot about your note: Removal of change to java.security.spec.MGF1ParameterSpec to avoid introducing a new public variable. No CCC needed. -Rob On 23/12/14 16:56, Rob McKenna wrote: > Actually, another kink: this requires ccc approval for a backport to 7. > > -Rob > > On 23/12/14 16:52, dalibor.topic at oracle.com wrote: >> Considering that the issue was a P3 RFE rather than a high priority >> bug fix, it's not clear to me why it would be necessary to backport >> it into 7u80, at the end point in the release cycle. >> >> -- >> Oracle >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | >> Mobile:+491737185961 >> Oracle Java Platform Group >> >> 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 >> Gesch?ftsf?hrer: J?rgen Kunz >> >> 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, Astrid Kepper, Val Maher >> >> Green Oracle Oracle is committed >> to developing practices and products that help protect the environment >> >>> On 23.12.2014, at 17:13, Andrew Hughes wrote: >>> >>> ----- Original Message ----- >>>> Valerie Peng (original author) is probably best suited to reviewing >>>> this >>>> but I think she's out of the office the moment and back next week. >>>> Let's >>>> hope we can get an update/review then. >>> Hi, >>> >>> Any movement on this? It's been three months. >>> >>> Thanks. >>> >>>> regards, >>>> Sean. >>>> >>>>> On 01/10/2014 16:11, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> ----- Original Message ----- >>>>>>> Code changes generally require two approvals: codereview, >>>>>>> performed by a >>>>>>> reviewer, (in this case from security-dev) and push approval, >>>>>>> performed >>>>>>> by a gatekeeper. Given your email template matches the push >>>>>>> approval >>>>>>> template I understood that you intended the latter. Generally >>>>>>> speaking >>>>>>> codereview requests would say "Request for review" as opposed to >>>>>>> "Request for approval" so a reviewer could overlook your mail if >>>>>>> you >>>>>>> intended the former. >>>>>>> >>>>>>> -Rob >>>>>>> >>>>>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>>>> ----- Original Message ----- >>>>>>>>> Hi Andrew, >>>>>>>>> >>>>>>>>> Sorry to be a pest, but given the scope of the change I'd feel >>>>>>>>> more >>>>>>>>> comfortable with an explicit codereview for the backport. >>>>>>>>> >>>>>>>>> -Rob >>>>>>>>> >>>>>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>>>> This is the first of three backports to 7u designed to retain >>>>>>>>>> SSL >>>>>>>>>> compatibility with servers implemented in other languages >>>>>>>>>> switching >>>>>>>>>> to larger key sizes (notably DH >=2048 in Apache 2.4.7 [0]). >>>>>>>>>> >>>>>>>>>> This patch is a per-requisite of the patch which brings NSA >>>>>>>>>> Suite B >>>>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>>>> >>>>>>>>>> * Copyright header adjustment >>>>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec >>>>>>>>>> to avoid >>>>>>>>>> introducing a new public variable. The SHA-224 variant is >>>>>>>>>> constructed >>>>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>>>> * A change to OAEPParameters is dropped as it was already >>>>>>>>>> incorporated >>>>>>>>>> in the backport of 7180907 & 8049480 (addition of SHA-224 to >>>>>>>>>> convertToStandardName) >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>>>> >>>>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>>>> >>>>>>>>>> Ok to push? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>> Which is what I asked for, no? >>>>>>>> >>>>>>>> If I wasn't waiting on a review first, I'd have pushed the change. >>>>>> This was the only applicable template on: >>>>>> >>>>>> http://openjdk.java.net/projects/jdk7u/ >>>>>> >>>>>> Anyway, now including security-dev for review. >>>>>> -- >>>>>> Andrew :) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>>> Ping. Any movement on this? >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> > From peter.levart at gmail.com Wed Dec 24 11:37:23 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 24 Dec 2014 12:37:23 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <5498C5A0.50104@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> Message-ID: <549AA573.2060801@gmail.com> Hi Brad, Thanks for looking into this. Here's updated webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/ ...and answers are inline... On 12/23/2014 02:30 AM, Bradford Wetmore wrote: > > Hi Peter, > > Looks like you have a committer status, will you be pushing this? I can, yes. As soon as we clear-out the remaining questions, right? > > On 12/18/2014 5:23 AM, Peter Levart wrote: >> Hi, >> >> I propose a patch for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8047769 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/ >> > > Looks good. A few minor comments. > > In a couple places, there are a few lines > 80 chars. (It's a pet > peeve of mine, this makes side-by-side reviews difficult without a > wide monitor. I realize not everyone shares this view, but they're > probably not working on a laptop screen regularly.) I have wrapped the lines to contain them inside the 80 column margin. > > Do you need to close the InputStream when last holder is GC'd, or do > we just let the FileInputStream's finalizer take care of that? WeakReference is enqueued when it is cleared, so at that time we have no access to the referent (UncloseableInputStream) any more. We could, in addition, "strongly" reference the underlying FileInputStream in the WeakReference subclass itself, but that would just prolong the life of FileInputStream (possibly forever if no further calls to FileInputStreamPool are made that expunge the references from the queue). So yes, we rely on FileInputStream's finalizer, but I don't see any other way that would be better than that. NativePRNG and URLSeedGenerator don't have a means of closing underlying resources either, so this is not making things any worse. > > Both of these current calls are contained within a > AccessContrller.doPriviledged, the checkRead() seems redundant. That's right, but from encapsulation, uniformity, security and future maintainability standpoint, I would keep this logic in. It doesn't hurt. Another possibility is to move doPriviliged call to FileInputStreamPool itself and declare it's API exposing security capability (of reading any file). > > In your test case, if assertions are not enabled, the tests at > 46/50/51 are noops, e.g. when run by hand. Generally should directly > throw Exceptions. I modified the test to use jdk.testlibrary.Asserts class. Is this ok from "run by hand" perspective or should the test be self-contained? > >> The patch uses a package-private FileInputStreamPool class that caches >> open FileInputStream(s) so that at most one file descriptor is open for >> a particular file. Reading from shared unbuffered FileInputStream in >> multiple threads should be safe, right? > > I would think (hope?) so, but I am not 100% sure. I tracked it down > into libjava native code: > > io_util.c > ========= > fd = GET_FD(this, fid); > if (fd == -1) { > JNU_ThrowIOException(env, "Stream Closed"); > nread = -1; > } else { > nread = IO_Read(fd, buf, len); > > which is then defined to handleRead, which calls something called > RESTARTABLE in io_util_md.c. Assuming I'm looking at the right code. > > Core-libs folks? The documentation doesn't mention threads anywhere in InputStream or FileInputStream except in this piece of javadoc for available() method: * Returns an estimate of the number of remaining bytes that can be read (or * skipped over) from this input stream without blocking by the next * invocation of a method for this input stream. Returns 0 when the file * position is beyond EOF. The next invocation might be the same *thread* * or another *thread*. A single read or skip of this many bytes will not * block, but may read or skip fewer bytes. ...which indicates that multiple threads may be used to read from FileInputStream(s)... Anyway it works correctly and not redundantly synchronizing in Java seems to increase the mutithreaded throughput a bit (or more acurately, does not decrease it compared to single-threaded case). For example, the following JMH benchmark: @State(Scope.Thread) public class DevUrandomTest { private static final Object sharedLock = new Object(); private static final InputStream sharedRndStream; static { try { sharedRndStream = new FileInputStream("/dev/urandom"); } catch (FileNotFoundException e) { throw new RuntimeException(e); } } // per-thread instance private final byte[] buff = new byte[32]; @Benchmark @BenchmarkMode(Mode.Throughput) @Fork(value = 1, warmups = 0) @Warmup(iterations = 5) @Measurement(iterations = 10) public byte testReadUnsynchronized() { try { sharedRndStream.read(buff); } catch (IOException e) { throw new RuntimeException(e); } return buff[0]; } @Benchmark @BenchmarkMode(Mode.Throughput) @Fork(value = 1, warmups = 0) @Warmup(iterations = 5) @Measurement(iterations = 10) public byte testReadSynchronized() { try { synchronized (sharedLock) { sharedRndStream.read(buff); } } catch (IOException e) { throw new RuntimeException(e); } return buff[0]; } } when run on: 1 thread: Benchmark Mode Samples Score Error Units j.t.DevUrandomTest.testReadSynchronized thrpt 10 553331.718 ? 309.350 ops/s j.t.DevUrandomTest.testReadUnsynchronized thrpt 10 556654.281 ? 1703.320 ops/s 2 threads: Benchmark Mode Samples Score Error Units j.t.DevUrandomTest.testReadSynchronized thrpt 10 346127.591 ? 73537.596 ops/s j.t.DevUrandomTest.testReadUnsynchronized thrpt 10 570414.143 ? 25134.664 ops/s 4 threads: Benchmark Mode Samples Score Error Units j.t.DevUrandomTest.testReadSynchronized thrpt 10 392531.196 ? 67848.064 ops/s j.t.DevUrandomTest.testReadUnsynchronized thrpt 10 500111.743 ? 62730.048 ops/s > >> sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java: >> Make sure that when no system policy and user policy files exist, the >> built-in default policy will be used, which - amongst other things - >> grants standard extensions the AllPermission. >> sun/security/provider/PolicyParser/ExtDirsChange.java: standard >> extensions path is hard-coded in default system policy file >> sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser >> incorrectly ignores a principal if the principal name expands to >> nothing. >> >> ...they are unrelated to this patch - seems to be caused by recent >> layout changes for modular runtime images. > > Hopefully you saw my previous response. Repeating: > > ---begin--- > They've been failing for a while: > > https://bugs.openjdk.java.net/browse/JDK-8039280 > > These tests are all "/manual" so they don't show up in our regular > runs of JPRT/jtreg, which include -a. > > -a | -automatic | -automagic > Any test with /manual will not be run > ---end--- > > Thanks, > > Brad Yes, I saw that. Thanks. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Dec 24 16:09:22 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 24 Dec 2014 11:09:22 -0500 (EST) Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> Message-ID: <1176100146.1009924.1419437362122.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Considering that the issue was a P3 RFE rather than a high priority bug fix, > it's not clear to me why it would be necessary to backport it into 7u80, at > the end point in the release cycle. > I don't have anything to do with the assignment of such priorities. >From our side, as already explained, backporting this and a couple of other patches yet to come that depend on it is important for retaining the compatibility of OpenJDK web servers with Apache web servers, which have switched to requiring a higher DH key size by default. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From jamil.j.nimeh at oracle.com Wed Dec 24 19:18:23 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 24 Dec 2014 11:18:23 -0800 Subject: Request for review : 8032573 - CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input In-Reply-To: <54997943.6020706@oracle.com> References: <54997943.6020706@oracle.com> Message-ID: <549B117F.9050504@oracle.com> Hi Mala, the backport looks good to me. Only one nit: I think the comment "no crls provided" in X509Factory.java:461 should be removed since you have the corrected comment in there. For what it's worth I'm not an approved reviewer on the census yet so you might need someone else to give the official OK. Cheers! --Jamil On 12/23/2014 6:16 AM, mala bankal wrote: > HI Jamil, All, > > Request your review for backport of bug# 8032573 to 7u-dev. > > https://bugs.openjdk.java.net/browse/JDK-8032573 > > webrev: > http://cr.openjdk.java.net/~mbankal/8032573/webrev.00/ > > rgds > mala From dalibor.topic at oracle.com Wed Dec 24 19:21:07 2014 From: dalibor.topic at oracle.com (dalibor.topic at oracle.com) Date: Wed, 24 Dec 2014 20:21:07 +0100 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <1176100146.1009924.1419437362122.JavaMail.zimbra@redhat.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> <1176100146.1009924.1419437362122.JavaMail.zimbra@redhat.com> Message-ID: <4353739B-3220-4AF9-9FB5-ECA1EEE0C85C@oracle.com> Can you elaborate on 'this and a couple of other patches' - is that supposed to be all of the corresponding JEP 130? Some part of it? Considering that the JEP 130 has legal and docs implications that imply more work having to be done than just back porting a couple of change sets, I think you need to try to make a stronger case for the proposed change. Is there a specific issue in JBS (or some other bug tracker) this change is trying to address? -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile:+491737185961 Oracle Java Platform Group 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 Gesch?ftsf?hrer: J?rgen Kunz 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, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment > On 24.12.2014, at 17:09, Andrew Hughes wrote: > > ----- Original Message ----- >> Considering that the issue was a P3 RFE rather than a high priority bug fix, >> it's not clear to me why it would be necessary to backport it into 7u80, at >> the end point in the release cycle. >> > > I don't have anything to do with the assignment of such priorities. > > From our side, as already explained, backporting this and a couple of other patches > yet to come that depend on it is important for retaining the compatibility of OpenJDK > web servers with Apache web servers, which have switched to requiring a higher DH key > size by default. > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Dec 26 23:47:16 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 26 Dec 2014 15:47:16 -0800 Subject: Request for review : 7196009-SunPkcs11 provider fails to parse config path containing parenthesis In-Reply-To: <54996C77.1080408@oracle.com> References: <54996C77.1080408@oracle.com> Message-ID: <549DF384.4030806@oracle.com> Mala, The backport looks fine... I recently fixed a regression which is related to 7196009 (tracked under 8062170) Webrev: http://cr.openjdk.java.net/~valeriep/8062170/webrev.00/ Any chance that you can backport this as well? It's better to combine these two. Thanks, Valerie On 12/23/2014 5:21 AM, mala bankal wrote: > HI Valerie, All, > > Request your review for backport of bug 7196009 to 7u-dev. > > https://bugs.openjdk.java.net/browse/JDK-7196009 > > webrev: > http://cr.openjdk.java.net/~mbankal/7196009/webrev.00/ > > rgds > mala From Alan.Bateman at oracle.com Mon Dec 29 09:08:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Dec 2014 09:08:15 +0000 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <549AA573.2060801@gmail.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> Message-ID: <54A119FF.4060103@oracle.com> On 24/12/2014 11:37, Peter Levart wrote: > Hi Brad, > > Thanks for looking into this. Here's updated webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/ > > This mostly looks good to me too, except the permission checking. As I read it, getInputStream uses getCanonicalFile and thus the permission check will be happen early and so it makes me wonder if checkRead is needed. Additionally, both of the uses are in privileged blocks so it looks like checkRead will always be called with a stack that has AllPermission anyway. -Alan. From peter.levart at gmail.com Mon Dec 29 09:45:14 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 29 Dec 2014 10:45:14 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A119FF.4060103@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com> Message-ID: <54A122AA.3010004@gmail.com> On 12/29/2014 10:08 AM, Alan Bateman wrote: > On 24/12/2014 11:37, Peter Levart wrote: >> Hi Brad, >> >> Thanks for looking into this. Here's updated webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/ >> >> > This mostly looks good to me too, except the permission checking. As I > read it, getInputStream uses getCanonicalFile and thus the permission > check will be happen early and so it makes me wonder if checkRead is > needed. Additionally, both of the uses are in privileged blocks so it > looks like checkRead will always be called with a stack that has > AllPermission anyway. > > -Alan. Thanks for looking at this, Alan. You're right about File.getCanonicalFile(). It already checks read permission for a file. The additional explicit check is superfluous. I have removed it. With explicit check I wanted the API to behave uniformly regardless of whether the returned stream is opened by getInputStream() call or an already opened stream is just returned. getCannonicalFile() already takes care of it. Here's the updated webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ Regards, Peter From Alan.Bateman at oracle.com Mon Dec 29 15:51:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Dec 2014 15:51:53 +0000 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A122AA.3010004@gmail.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com> <54A122AA.3010004@gmail.com> Message-ID: <54A17899.4060304@oracle.com> On 29/12/2014 09:45, Peter Levart wrote: > > Thanks for looking at this, Alan. > > You're right about File.getCanonicalFile(). It already checks read > permission for a file. The additional explicit check is superfluous. I > have removed it. > > With explicit check I wanted the API to behave uniformly regardless of > whether the returned stream is opened by getInputStream() call or an > already opened stream is just returned. getCannonicalFile() already > takes care of it. Here's the updated webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ > Updated patch looks good to me. -Alan. From valerie.peng at oracle.com Mon Dec 29 21:51:53 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 29 Dec 2014 13:51:53 -0800 Subject: Please review CR 8049021 Add smartcardio tests with APDU buffer In-Reply-To: <540FA0EB.2090105@oracle.com> References: <540FA0EB.2090105@oracle.com> Message-ID: <54A1CCF9.90309@oracle.com> Hi, Amanda, Your changes look fine. Thanks, Valerie On 9/9/2014 5:52 PM, Amanda Jiang wrote: > Hello, > > Please help to review the changeset below, new tests are added > for javax.smartcardio.CommandAPDU, javax.smartcardio.ResponseAPDU > and javax.smartcardio.TerminalFactorySpi. > > Bug - https://bugs.openjdk.java.net/browse/JDK-8049021 > Webrev - http://cr.openjdk.java.net/~tyan/amandaj/8049021/webrev00/ > > Thanks, > Amanda From amanda.jiang at oracle.com Mon Dec 29 22:59:58 2014 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 29 Dec 2014 14:59:58 -0800 Subject: Please review CR 8049021 Add smartcardio tests with APDU buffer In-Reply-To: <54A1CCF9.90309@oracle.com> References: <540FA0EB.2090105@oracle.com> <54A1CCF9.90309@oracle.com> Message-ID: <54A1DCEE.1030305@oracle.com> Hi Valerie, Thanks for reviewing this changeset, could you please sponsor this? Regards, Amanda On 12/29/14 1:51 PM, Valerie Peng wrote: > Hi, Amanda, > > Your changes look fine. > > Thanks, > Valerie > > On 9/9/2014 5:52 PM, Amanda Jiang wrote: >> Hello, >> >> Please help to review the changeset below, new tests are added >> for javax.smartcardio.CommandAPDU, javax.smartcardio.ResponseAPDU >> and javax.smartcardio.TerminalFactorySpi. >> >> Bug - https://bugs.openjdk.java.net/browse/JDK-8049021 >> Webrev - http://cr.openjdk.java.net/~tyan/amandaj/8049021/webrev00/ >> >> Thanks, >> Amanda From valerie.peng at oracle.com Tue Dec 30 00:07:04 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 29 Dec 2014 16:07:04 -0800 Subject: Please review CR 8049021 Add smartcardio tests with APDU buffer In-Reply-To: <54A1DCEE.1030305@oracle.com> References: <540FA0EB.2090105@oracle.com> <54A1CCF9.90309@oracle.com> <54A1DCEE.1030305@oracle.com> Message-ID: <54A1ECA8.10105@oracle.com> Ok, will put it back tomorrow. Regards, Valerie On 12/29/2014 2:59 PM, Amanda Jiang wrote: > Hi Valerie, > > Thanks for reviewing this changeset, could you please sponsor this? > > Regards, > Amanda > > On 12/29/14 1:51 PM, Valerie Peng wrote: >> Hi, Amanda, >> >> Your changes look fine. >> >> Thanks, >> Valerie >> >> On 9/9/2014 5:52 PM, Amanda Jiang wrote: >>> Hello, >>> >>> Please help to review the changeset below, new tests are added >>> for javax.smartcardio.CommandAPDU, javax.smartcardio.ResponseAPDU >>> and javax.smartcardio.TerminalFactorySpi. >>> >>> Bug - https://bugs.openjdk.java.net/browse/JDK-8049021 >>> Webrev - http://cr.openjdk.java.net/~tyan/amandaj/8049021/webrev00/ >>> >>> Thanks, >>> Amanda > From valerie.peng at oracle.com Tue Dec 30 00:40:50 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 29 Dec 2014 16:40:50 -0800 Subject: [9] RFR 8039921: SHA1WithDSA with key > 1024 bits not working Message-ID: <54A1F492.5020905@oracle.com> Can someone please help review this change? The fix is straightforward - remove the key length check inside the code for DSA related signatures. Bug: https://bugs.openjdk.java.net/browse/JDK-8039921 Webrev: http://cr.openjdk.java.net/~valeriep/8039921/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Tue Dec 30 01:29:11 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 30 Dec 2014 09:29:11 +0800 Subject: [9] RFR 8039921: SHA1WithDSA with key > 1024 bits not working In-Reply-To: <54A1F492.5020905@oracle.com> References: <54A1F492.5020905@oracle.com> Message-ID: <0A0ABD8C-DE17-4FCC-980C-DF1BF1486BE1@oracle.com> Looks fine. Thanks Max > On Dec 30, 2014, at 08:40, Valerie Peng wrote: > > > Can someone please help review this change? The fix is straightforward - remove the key length check inside the code for DSA related signatures. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039921 > Webrev: http://cr.openjdk.java.net/~valeriep/8039921/webrev.00/ > > Thanks, > Valerie From bradford.wetmore at oracle.com Tue Dec 30 01:48:37 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 29 Dec 2014 17:48:37 -0800 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <549AA573.2060801@gmail.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> Message-ID: <54A20475.3040206@oracle.com> I'm looking at this version of the webrev. http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ I just assigned 8047769 to you. My username is wetmore, Alan is alanb. On 12/24/2014 3:37 AM, Peter Levart wrote: >> Looks like you have a committer status, will you be pushing this? > > I can, yes. As soon as we clear-out the remaining questions, right? Yes. The comments below are minor and shouldn't need another review cycle. I have started a JPRT job for you, I'll run it through "core" target which will give us: jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. Anything else? I'm off tomorrow, I should have full results Wed. Here are the preliminary results for the jobs that have finished. jdk.testlibrary.Asserts is causing compilation errors, additional comments below: /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33: error: package jdk.testlibrary does not exist import static jdk.testlibrary.Asserts.*; ^ /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52: error: cannot find symbol assertEquals(bytes.length, nread, "short read"); ^ symbol: method assertEquals(int,int,String) location: class FileInputStreamPoolTest /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53: error: cannot find symbol assertTrue(Arrays.equals(readBytes, bytes), ^ symbol: method assertTrue(boolean,String) location: class FileInputStreamPoolTest 3 errors TEST RESULT: Failed. Compilation failed: Compilation failed I'm also getting failures in the following test. I unfortunately have to leave now, so don't have time to look at this. But it did mention "seed" so I'm mentioning it here. TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the same "-Dseed=" option as in the log file! REASON: User specified action: run main/othervm LFGarbageCollectedTest TIME: 213.406 seconds messages: command: main LFGarbageCollectedTest reason: User specified action: run main/othervm LFGarbageCollectedTest elapsed time (seconds): 213.406 STDOUT: -Dseed=6102311124531075592 -DtestLimit=2000 Number of iterations according to -DtestLimit is 153 (1989 cases) Code cache size is 251658240 bytes Non-profiled code cache size is 123058253 bytes Number of iterations limited by code cache size is 84 (1092 cases) Number of iterations limited by non-profiled code cache size is 41 (533 cases) Number of iterations is set to 41 (533 cases) Not enough time to continue execution. Interrupted. STDERR: Iteration 0: Tested LF caching feature with MethodHandles.foldArguments method. java.lang.AssertionError: Error: Lambda form is not garbage collected at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81) at LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139) at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source) at jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71) at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201) at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> In a couple places, there are a few lines > 80 chars. (It's a pet >> peeve of mine, this makes side-by-side reviews difficult without a >> wide monitor. I realize not everyone shares this view, but they're >> probably not working on a laptop screen regularly.) > > I have wrapped the lines to contain them inside the 80 column margin. I and my scrubber/slider thank you. :) Two minor nits? SeedGenerator.java: Lines 507/518 >> Do you need to close the InputStream when last holder is GC'd, or do >> we just let the FileInputStream's finalizer take care of that? > > WeakReference is enqueued when it is cleared, so > at that time we have no access to the referent (UncloseableInputStream) > any more. We could, in addition, "strongly" reference the underlying > FileInputStream in the WeakReference subclass itself, but that would > just prolong the life of FileInputStream (possibly forever if no further > calls to FileInputStreamPool are made that expunge the references from > the queue). So yes, we rely on FileInputStream's finalizer, but I don't > see any other way that would be better than that. Makes sense, thanks. > NativePRNG and > URLSeedGenerator don't have a means of closing underlying resources > either, so this is not making things any worse. Yes. >> Both of these current calls are contained within a >> AccessContrller.doPriviledged, the checkRead() seems redundant. > > That's right, but from encapsulation, uniformity, security and future > maintainability standpoint, I would keep this logic in. It doesn't hurt. > Another possibility is to move doPriviliged call to FileInputStreamPool > itself and declare it's API exposing security capability (of reading any > file). I see this was addressed later via Alan's review. >> In your test case, if assertions are not enabled, the tests at >> 46/50/51 are noops, e.g. when run by hand. Generally should directly >> throw Exceptions. > > I modified the test to use jdk.testlibrary.Asserts class. Is this ok > from "run by hand" perspective or should the test be self-contained? I've not used this Asserts library yet. Is this part of TestNG, or something new in jtreg or jprt? If Core-libs is ok with this style of doing it, I'm ok. I'm kind of old-school and tests should be mostly self-contained and can be tested via: % javac Clazz.java % java Clazz without extra classpaths needed. I understand this model doesn't work with @library and such, so I'm not strongly tied to it. I can be taught new tricks. >> Core-libs folks? > > The documentation doesn't mention threads anywhere in InputStream or > FileInputStream except in this piece of javadoc for available() method: ...snip... Ok. A few minor nits below: FileInputStreamPool.java ======================== * This method opens an underlying {@link java.io.FileInputStream} for -> * This method opens an underlying {@link java.io.FileInputStream} for a * among multiple readers of same {@code file} and ignores -> * among multiple readers of the same {@code file} and ignores FileInputStreamPoolTest.java ============================ Generally JTREG labels are immediately following the copyright and before the imports. While what you have is allowed by the JTREG syntax, @test is usually by itself, or followed by old SCCS or filename info. @summary is usually the bug description. Suggest: @summary SecureRandom should be more frugal with file descriptors 48: This is still using assert. Maybe issue multiple reads to exercise in1 and in2? e.g. 2 bytes of in1, 4 bytes of in2, then 2 bytes of in1? IIRC, when I ran this under NetBeans last week, the second testCaching didn't clear the WeakReference. Thanks, Brad From ymnk at jcraft.com Wed Dec 31 15:54:27 2014 From: ymnk at jcraft.com (Atsuhiko Yamanaka) Date: Thu, 1 Jan 2015 00:54:27 +0900 Subject: JDK-8039921: SHA1WithDSA with key > 1024 bits not working In-Reply-To: <54371765.60500@oracle.com> References: <541B732A.2080804@oracle.com> <54371765.60500@oracle.com> Message-ID: Hi, On Fri, Oct 10, 2014 at 8:16 AM, Valerie Peng wrote: > Thanks for the reply. I have just returned from vacation and am looking > through the specs that you provided. > Should have an update some time next week. It seems the problem will disappear in Java9[1]. I greatly appreciate this change, and say thank you as one of developers and users, who are developing and using the ssh system in Java. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/edd7a67585a5 I wish you a happy new year!! -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 Skypecallto://jcraft/ Twitter:http://twitter.com/ymnk Facebook:http://facebook.com/aymnk From plin at dynamath.tw Sat Dec 20 01:52:50 2014 From: plin at dynamath.tw (plin) Date: Sat, 20 Dec 2014 01:52:50 -0000 Subject: JDK-8056130 Message-ID: <1419039731580-211036.post@n7.nabble.com> I have the similiar problem as what was described on https://bugs.openjdk.java.net/browse/JDK-8056130. In my case, the problem is actually caused by the use of xxx.class.getResource( "yyyy.gif") method in a JPanel used in the applet. It seems to be compiled well in JDK8.0_05 but failed with newer versions. Is getResource from the jar itself prohibited by the new version? Pao-Ping Lin http://mathboard.org -- View this message in context: http://openjdk.5641.n7.nabble.com/JDK-8056130-tp211036.html Sent from the OpenJDK Security Development mailing list archive at Nabble.com.