From valerie.peng at oracle.com Fri Jul 1 00:20:50 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 30 Jun 2016 17:20:50 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> Message-ID: <5775B762.3090000@oracle.com> Max, Please find comments in line. On 6/29/2016 8:18 PM, Wang Weijun wrote: >> On Jun 30, 2016, at 9:39 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Changes look fine. Just some comments/questions as below. >> >> >> - line 46, fix this {0} as well? > I don't see {0} in keytool/Resources.java. > > There is one in jarsigner/Resources.java: > > 46 {"signerClass.is.not.a.signing.mechanism", "{0} is not a signing mechanism"}, > > You mean it's useless now? Right, it's under the jarsigner directory. My eyes were crossed. ;) Is this used still? I didn't find reference to this one. >> >> - line 53, better to use -providerClass? > Both should work. > > -addprovider works because SUN is already a loaded provider. > -providerclass works because sun.security.provider.Sun is a public class in the same module. > > I prefer -addprovider because -providerclass is only for legacy providers loaded with reflection. > > In fact, I noticed that SUN is also not in ServiceLoader.load(Provider.class), which means it is not a service. Is that why you suggest the test load it with -providerclass? I only saw -provider not -addprovider? Correct, SUN provider is not exported as a provider for ServiceLoader. I don't have preference to use -providerClass over -addprovider. Whatever is the expected usage is fine with me. Thanks, Valerie > Thanks > Max > >> Thanks, >> Valerie >> >> On 6/28/2016 6:09 PM, Wang Weijun wrote: >>> Ping again to security-dev. Anyone can approve it? >>> >>> The latest webrev is at >>> >>> http://cr.openjdk.java.net/~weijun/8130302/webrev.06 >>> >>> Change from webrev.05 [1] is tiny. >>> >>> Thanks >>> Max >>> >>> [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html >>> >>>> On Jun 16, 2016, at 9:33 AM, Wang Weijun wrote: >>>> >>>> >>>>> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: >>>>> >>>>> No big difference to me. >>>> Good, I'll remove the cast. >>>> >>>> @security-dev, can someone approve the whole webrev.05? >>>> >>>> http://cr.openjdk.java.net/~weijun/8130302/webrev.05 >>>> >>>> Thanks >>>> Max >>>> >>>>> Valerie >>>>> >>>>> On 6/15/2016 8:40 AM, Wang Weijun wrote: >>>>>>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>>>>>> >>>>>>>>> 241 throw (InvalidParameterException) >>>>>>>>> >>>>>>>>> This cast should not be needed? >>>>>>>>> >>>>>>>> } catch (UcryptoException ue) { >>>>>>>> throw (InvalidParameterException) >>>>>>>> new InvalidParameterException("Error using " + configArg). >>>>>>>> initCause(ue.getCause()); >>>>>>>> } >>>>>>>> >>>>>>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>>>>>> >>>>>>> Perhaps have a local variable for InvalidParameterException exception. >>>>>> Valerie, are you OK with this? >>>>>> >>>>>> --Max >>>>>> >>>>>>> Mandy From weijun.wang at oracle.com Fri Jul 1 00:40:37 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jul 2016 08:40:37 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <5775B762.3090000@oracle.com> References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> <5775B7! 62.3090000@oracle.com> Message-ID: <6759706E-1408-49E0-8FA0-4CD85E1770CA@oracle.com> > On Jul 1, 2016, at 8:20 AM, Valerie Peng wrote: > > Max, > > Please find comments in line. > > On 6/29/2016 8:18 PM, Wang Weijun wrote: >>> On Jun 30, 2016, at 9:39 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> Changes look fine. Just some comments/questions as below. >>> >>> >>> - line 46, fix this {0} as well? >> I don't see {0} in keytool/Resources.java. >> >> There is one in jarsigner/Resources.java: >> >> 46 {"signerClass.is.not.a.signing.mechanism", "{0} is not a signing mechanism"}, >> >> You mean it's useless now? > Right, it's under the jarsigner directory. My eyes were crossed. ;) > Is this used still? I didn't find reference to this one. It is useless after the jdk.security.jarsigner.JarSigner API. I'll remove it. >>> >>> - line 53, better to use -providerClass? >> Both should work. >> >> -addprovider works because SUN is already a loaded provider. >> -providerclass works because sun.security.provider.Sun is a public class in the same module. >> >> I prefer -addprovider because -providerclass is only for legacy providers loaded with reflection. >> >> In fact, I noticed that SUN is also not in ServiceLoader.load(Provider.class), which means it is not a service. Is that why you suggest the test load it with -providerclass? > I only saw -provider not -addprovider? Confused. http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.html has 53
  • keytool -list -storepass password -addprovider SUN > Correct, SUN provider is not exported as a provider for ServiceLoader. I don't have preference to use -providerClass over -addprovider. Whatever is the expected usage is fine with me. OK. Thanks Max From valerie.peng at oracle.com Fri Jul 1 01:12:35 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 30 Jun 2016 18:12:35 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <745DFC74-5E81-4E57-B4D8-C1AD018CDA62@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> <576DC75C.9060503@oracle.com> <745DFC74-5E81-4E57-B4D8-C1AD018CDA62@oracle.com> Message-ID: <5775C383.1040600@oracle.com> Webrev updated with your suggestion: http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/ Thanks, Valerie On 6/24/2016 5:05 PM, Wang Weijun wrote: >> On Jun 25, 2016, at 7:50 AM, Valerie Peng wrote: >> >> I thought about it, but as Provider object is serializable, if the field is of new type Runtime.Version class, the (de-)serialization against older releases may break. > I see. > >> What exactly is the version style that you have in mind then? I think the major.minor thing is quite reasonable. >> 1.9d does not really look like a version to me. Do you want to special handling this just because the earlier version is a double? > Since you mentioned "major" and "minor" in the spec, we have to define it. Either referring to the Version class, or define one inside Provider. My preference is later, with a regex /(^\d+(\.\d+)?)/, which is a superset of Version. > > --Max > >> Valerie >> >> On 6/23/2016 6:59 PM, Wang Weijun wrote: >>> If you mandate the use of Verona version style, can we just use the Version class in the constructor? >>> >>>> On Jun 24, 2016, at 9:56 AM, Valerie Peng wrote: >>>> >>>> >>>> Well, we have to define something for the version syntax and how it converts to the legacy double version. >>>> I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. >>>> >>>> Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? >>>> Valerie From valerie.peng at oracle.com Fri Jul 1 01:16:29 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 30 Jun 2016 18:16:29 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <6759706E-1408-49E0-8FA0-4CD85E1770CA@oracle.com> References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> <5775B762.3090000@oracle.com> <6759706E-1408-49E0-8FA0-4CD85E1770CA@oracle.com> Message-ID: <5775C46D.6050408@oracle.com> Weird, I still see -provider on the link below. http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.sdiff.html If you saw differently, I need to book an urgent doc appt for my eyes... Valerie On 6/30/2016 5:40 PM, Wang Weijun wrote: > Confused. > http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.html > has 53
  • keytool -list -storepass password -addprovider SUN >> Correct, SUN provider is not exported as a provider for ServiceLoader. I don't have preference to use -providerClass over -addprovider. Whatever is the expected usage is fine with me. > OK. > > Thanks > Max > From weijun.wang at oracle.com Fri Jul 1 02:00:57 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jul 2016 10:00:57 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <5775C46D.6050408@oracle.com> References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> <5775B762.3090000@oracle.com> <6759706E-1408-49E0-8FA0-4CD85E1770CA@oracle.com> <5775C46D.6050408@oracle.com> Message-ID: <2A2E353B-E09E-4C56-96DE-E5D5158756A5@oracle.com> > On Jul 1, 2016, at 9:16 AM, Valerie Peng wrote: > > Weird, I still see -provider on the link below. > http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.sdiff.html This is sdiff, you need to scroll to far right to see the new line. I should probably make the lines shorter one day. --Max > > If you saw differently, I need to book an urgent doc appt for my eyes... > Valerie > > On 6/30/2016 5:40 PM, Wang Weijun wrote: >> Confused. http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.html has 53
  • keytool -list -storepass password -addprovider SUN >>> Correct, SUN provider is not exported as a provider for ServiceLoader. I don't have preference to use -providerClass over -addprovider. Whatever is the expected usage is fine with me. >> OK. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Fri Jul 1 02:18:31 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jul 2016 10:18:31 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <5775C383.1040600@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> <576DC75C.9060503@oracle.com> <745DFC74-5E81-4E57-B4D8-C1AD018CDA62@oracle.com> <5775C383.1040600@oracle.com> Message-ID: One tiny thing, in Provider.java: 244 *{@code getVersion()}, by filtering out the trailing optional information There should be a space between * and {. I am not sure if this is worth a clarification, that when version string is "1.2.3", we would like "1.2" being the version number and "3" being other information. Do you think your @implNote also allows "1" being interpreted as version number and "2.3" as other information? A regex is greedy but the @implNote does not imply it. --Max > On Jul 1, 2016, at 9:12 AM, Valerie Peng wrote: > > > Webrev updated with your suggestion: http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/ > Thanks, > Valerie > > > On 6/24/2016 5:05 PM, Wang Weijun wrote: >>> On Jun 25, 2016, at 7:50 AM, Valerie Peng wrote: >>> >>> I thought about it, but as Provider object is serializable, if the field is of new type Runtime.Version class, the (de-)serialization against older releases may break. >> I see. >> >>> What exactly is the version style that you have in mind then? I think the major.minor thing is quite reasonable. >>> 1.9d does not really look like a version to me. Do you want to special handling this just because the earlier version is a double? >> Since you mentioned "major" and "minor" in the spec, we have to define it. Either referring to the Version class, or define one inside Provider. My preference is later, with a regex /(^\d+(\.\d+)?)/, which is a superset of Version. >> >> --Max >> >>> Valerie >>> >>> On 6/23/2016 6:59 PM, Wang Weijun wrote: >>>> If you mandate the use of Verona version style, can we just use the Version class in the constructor? >>>> >>>>> On Jun 24, 2016, at 9:56 AM, Valerie Peng wrote: >>>>> >>>>> >>>>> Well, we have to define something for the version syntax and how it converts to the legacy double version. >>>>> I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. >>>>> >>>>> Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? >>>>> Valerie > From amy.lu at oracle.com Fri Jul 1 03:43:27 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 1 Jul 2016 11:43:27 +0800 Subject: JDK 9 RFR of JDK-8160658: sun/security/tools/keytool/standard.sh fails on all platforms after JDK-8160415 Message-ID: <5775E6DF.5010801@oracle.com> Please review this simple and urgent fix for the regression introduced by JDK-8160415. In this patch, an empty line added after the @key line (that introduced in JDK-8160415) and before the comment lines to avoid comments to be read as "key" values. bug: https://bugs.openjdk.java.net/browse/JDK-8160658 webrev: http://cr.openjdk.java.net/~amlu/8160658/webrev.00/ Thanks, Amy --- old/test/sun/security/tools/keytool/standard.sh 2016-07-01 11:31:42.000000000 +0800 +++ new/test/sun/security/tools/keytool/standard.sh 2016-07-01 11:31:42.000000000 +0800 @@ -26,7 +26,7 @@ # @author Weijun Wang # @run shell/timeout=600 standard.sh # @key intermittent -# + # This test is always excecuted. # # set a few environment variables so that the shell-script can run stand-alone -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Jul 1 04:44:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jul 2016 12:44:40 +0800 Subject: JDK 9 RFR of JDK-8160658: sun/security/tools/keytool/standard.sh fails on all platforms after JDK-8160415 In-Reply-To: <5775E6DF.5010801@oracle.com> References: <5775E6DF.5010801@oracle.com> Message-ID: <7BF2FB11-A697-4742-87B8-C2741D8ECD61@oracle.com> Change looks fine. Thanks Max > On Jul 1, 2016, at 11:43 AM, Amy Lu wrote: > > Please review this simple and urgent fix for the regression introduced by JDK-8160415. > > In this patch, an empty line added after the @key line (that introduced in JDK-8160415) and before the comment lines to avoid comments to be read as "key" values. > > bug: https://bugs.openjdk.java.net/browse/JDK-8160658 > webrev: http://cr.openjdk.java.net/~amlu/8160658/webrev.00/ > > Thanks, > Amy > > --- old/test/sun/security/tools/keytool/standard.sh 2016-07-01 11:31:42.000000000 +0800 > +++ new/test/sun/security/tools/keytool/standard.sh 2016-07-01 11:31:42.000000000 +0800 > @@ -26,7 +26,7 @@ > # @author Weijun Wang > # @run shell/timeout=600 standard.sh > # @key intermittent > -# > + > # This test is always excecuted. > # > # set a few environment variables so that the shell-script can run stand-alone > > > From sean.mullan at oracle.com Fri Jul 1 12:08:26 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 Jul 2016 08:08:26 -0400 Subject: RFR: 8157707: Deprecate the java.security.Certificate API with forRemoval=true Message-ID: <57765D3A.7090905@oracle.com> Please review the changes for this RFE to mark the java.security.Certificate API with forRemoval=true. The intention is to remove this API in JDK 10. The java.security.Certificate API has been deprecated since 1.2 and has been superseded by java.security.cert.Certificate and related classes since 1.2. It is no longer necessary to retain this class. --- a/src/java.base/share/classes/java/security/Certificate.java Wed Jun 15 14:21:24 2016 +0200 +++ b/src/java.base/share/classes/java/security/Certificate.java Fri Jul 01 08:07:25 2016 -0400 @@ -60,9 +60,10 @@ * This Certificate interface is entirely deprecated and * is here to allow for a smooth transition to the new * package. + * This class is subject to removal in a future version of Java SE. * @see java.security.cert.Certificate */ - at Deprecated + at Deprecated(since="1.2", forRemoval=true) public interface Certificate { --Sean From Xuelei.Fan at Oracle.Com Fri Jul 1 12:20:10 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 1 Jul 2016 20:20:10 +0800 Subject: RFR: 8157707: Deprecate the java.security.Certificate API with forRemoval=true In-Reply-To: <57765D3A.7090905@oracle.com> References: <57765D3A.7090905@oracle.com> Message-ID: <2594420C-3071-4C32-A601-25ED0047D149@Oracle.Com> looks fine to me. Xuelei > On Jul 1, 2016, at 8:08 PM, Sean Mullan wrote: > > Please review the changes for this RFE to mark the java.security.Certificate API with forRemoval=true. The intention is to remove this API in JDK 10. > > The java.security.Certificate API has been deprecated since 1.2 and has been superseded by java.security.cert.Certificate and related classes since 1.2. It is no longer necessary to retain this class. > > --- a/src/java.base/share/classes/java/security/Certificate.java Wed Jun 15 14:21:24 2016 +0200 > +++ b/src/java.base/share/classes/java/security/Certificate.java Fri Jul 01 08:07:25 2016 -0400 > @@ -60,9 +60,10 @@ > * This Certificate interface is entirely deprecated and > * is here to allow for a smooth transition to the new > * package. > + * This class is subject to removal in a future version of Java SE. > * @see java.security.cert.Certificate > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public interface Certificate { > > --Sean From sean.mullan at oracle.com Fri Jul 1 12:31:05 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 Jul 2016 08:31:05 -0400 Subject: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true Message-ID: <57766289.9060601@oracle.com> Please review the changes for this RFE to mark the java.security.acl API with forRemoval=true. The intention is to remove this API in JDK 10. The APIs in java.security.acl were deprecated in 1.9 but have had the following warning in the package description for many releases: "The classes and interfaces in this package have been superseded by classes in the java.security package. See that package and, for example, java.security.Permission for details." Since there have been suitable replacements since 1.2, there is no reason to retain this package and it should be removed. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8157847/webrev.00/ --Sean From weijun.wang at oracle.com Fri Jul 1 13:30:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jul 2016 21:30:27 +0800 Subject: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true In-Reply-To: <57766289.9060601@oracle.com> References: <57766289.9060601@oracle.com> Message-ID: Change looks fine. Thanks Max > On Jul 1, 2016, at 8:31 PM, Sean Mullan wrote: > > Please review the changes for this RFE to mark the java.security.acl API with forRemoval=true. The intention is to remove this API in JDK 10. > > The APIs in java.security.acl were deprecated in 1.9 but have had the following warning in the package description for many releases: > > "The classes and interfaces in this package have been superseded by classes in the java.security package. See that package and, for example, java.security.Permission for details." > > Since there have been suitable replacements since 1.2, there is no reason to retain this package and it should be removed. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8157847/webrev.00/ > > --Sean From sha.jiang at oracle.com Fri Jul 1 13:38:06 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 1 Jul 2016 21:38:06 +0800 Subject: [9] RFR 8157667: sun/security/x509/URICertStore/ExtensionsWithLDAP.java has to be updated due to JDK-8134577 In-Reply-To: <8a63a9eb-1788-ca91-8ae9-627649426bb8@oracle.com> References: <5717b5e1-605f-2c46-2cfd-d0dff631dd5c@oracle.com> <8a63a9eb-1788-ca91-8ae9-627649426bb8@oracle.com> Message-ID: <5422fb64-ecac-1014-13b5-90c3546fd8d5@oracle.com> Ping again ;-) John Jiang On 2016/6/28 6:42, John Jiang wrote: > Please review this patch. > Thanks! > > John Jiang > > > On 2016/6/24 16:55, John Jiang wrote: >> Hi, >> Due to JDK-8134577, the test >> sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve >> hosts from a local name service provider. >> This fix creates a simple Socks4 proxy, and use it to resolve hosts >> from Socket. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8157667 >> Webrev: http://cr.openjdk.java.net/~jjiang/8157667/webrev.01 >> >> Please note that, this fix provides two separated local hosts files. >> Each of them contains only one host entry. >> And the test is executed twice in deed. Each time, the test focus >> only one specific host, and uses one hosts file accordingly. >> If one hosts file includes two entries, like the below, >> 127.0.0.1 ldap.host.for.crldp >> 127.0.0.1 ldap.host.for.aia >> then, only the first host, ldap.host.for.crldp, is resolved by the >> proxy. >> If I misunderstand something, or you have better solution, please let >> me know. >> >> Thanks! >> >> John Jiang >> >> > > From mandy.chung at oracle.com Fri Jul 1 16:41:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 1 Jul 2016 09:41:37 -0700 Subject: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true In-Reply-To: <57766289.9060601@oracle.com> References: <57766289.9060601@oracle.com> Message-ID: > On Jul 1, 2016, at 5:31 AM, Sean Mullan wrote: > > Please review the changes for this RFE to mark the java.security.acl API with forRemoval=true. The intention is to remove this API in JDK 10. > > The APIs in java.security.acl were deprecated in 1.9 but have had the following warning in the package description for many releases: > > "The classes and interfaces in this package have been superseded by classes in the java.security package. See that package and, for example, java.security.Permission for details." > > Since there have been suitable replacements since 1.2, there is no reason to retain this package and it should be removed. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8157847/webrev.00/ Should be @since=?9? rather than ?1.9?. Otherwise, looks okay. Mandy From sean.mullan at oracle.com Fri Jul 1 18:13:53 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 Jul 2016 14:13:53 -0400 Subject: RFR: 8157847: Deprecate the java.security.acl API with forRemoval=true In-Reply-To: References: <57766289.9060601@oracle.com> Message-ID: <5776B2E1.4000909@oracle.com> On 07/01/2016 12:41 PM, Mandy Chung wrote: > >> On Jul 1, 2016, at 5:31 AM, Sean Mullan wrote: >> >> Please review the changes for this RFE to mark the java.security.acl API with forRemoval=true. The intention is to remove this API in JDK 10. >> >> The APIs in java.security.acl were deprecated in 1.9 but have had the following warning in the package description for many releases: >> >> "The classes and interfaces in this package have been superseded by classes in the java.security package. See that package and, for example, java.security.Permission for details." >> >> Since there have been suitable replacements since 1.2, there is no reason to retain this package and it should be removed. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8157847/webrev.00/ > > Should be @since=?9? rather than ?1.9?. Otherwise, looks okay. Good catch. Thanks, Sean From sean.mullan at oracle.com Fri Jul 1 19:39:49 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 Jul 2016 15:39:49 -0400 Subject: RFR: 8154015 Apply algorithm constraints to timestamped code In-Reply-To: <57758FC9.9040507@oracle.com> References: <5772E956.4010305@oracle.com> <57756C4B.3030701@oracle.com> <57758FC9.9040507@oracle.com> Message-ID: <5776C705.9070709@oracle.com> Looks good, just one comment below ... On 06/30/2016 05:31 PM, Anthony Scarpino wrote: > Unless otherwise specified below, it was accepted.. > > http://cr.openjdk.java.net/~ascarpino/8154015/webrev.02/ > > Tony >> >> PKIX.java: >> >> 107 this.params = ((PKIXTimestampParameters) >> params).getPKIXBuilderParameters(); >> >> Shouldn't this be: >> >> this.params = (PKIXBuilderParameters) params; > > The passed in params doesn't itself contain the original > PKIXBuilderParamters data. It's the wrapper with an internal > PKIXBuilderParameter object it holds the data. > getPKIXBuilderParameters() passes the orignal PKIXBuilderParameters object. > > Without it being setup this way I don't see how I can get and set the > timestamp. Right, you still need to get the timestamp, but all the other methods in params are overidden and just call through to the wrapped object, so it seems like you can still do this: if (params instanceof PKIXTimestampParameters) { timestamp = ((PKIXTimestampParameters) params).getTimestamp(); this.params = (PKIXBuilderParameters) params; } and then you don't need the getPKIXBuilderParameters() method. --Sean From anthony.scarpino at oracle.com Fri Jul 1 20:32:47 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 1 Jul 2016 13:32:47 -0700 Subject: RFR: 8154015 Apply algorithm constraints to timestamped code In-Reply-To: <5776C705.9070709@oracle.com> References: <5772E956.4010305@oracle.com> <57756C4B.3030701@oracle.com> <57758FC9.9040507@oracle.com> <5776C705.9070709@oracle.com> Message-ID: <5776D36F.1080802@oracle.com> On 07/01/2016 12:39 PM, Sean Mullan wrote: > Looks good, just one comment below ... > > On 06/30/2016 05:31 PM, Anthony Scarpino wrote: >> Unless otherwise specified below, it was accepted.. >> >> http://cr.openjdk.java.net/~ascarpino/8154015/webrev.02/ >> >> Tony > >>> >>> PKIX.java: >>> >>> 107 this.params = ((PKIXTimestampParameters) >>> params).getPKIXBuilderParameters(); >>> >>> Shouldn't this be: >>> >>> this.params = (PKIXBuilderParameters) params; >> >> The passed in params doesn't itself contain the original >> PKIXBuilderParamters data. It's the wrapper with an internal >> PKIXBuilderParameter object it holds the data. >> getPKIXBuilderParameters() passes the orignal PKIXBuilderParameters >> object. >> >> Without it being setup this way I don't see how I can get and set the >> timestamp. > > Right, you still need to get the timestamp, but all the other methods in > params are overidden and just call through to the wrapped object, so it > seems like you can still do this: > > if (params instanceof PKIXTimestampParameters) { > timestamp = ((PKIXTimestampParameters) params).getTimestamp(); > this.params = (PKIXBuilderParameters) params; > } > > and then you don't need the getPKIXBuilderParameters() method. > > --Sean I see what you're saying now... Additionally, I don't need to typecast params. I can remove the 'else' and just have 'this.params = params;' thanks Tony From anthony.scarpino at oracle.com Fri Jul 1 20:38:51 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 1 Jul 2016 13:38:51 -0700 Subject: RFR: 8159180 Remove default setting for jdk.security.provider.preferred In-Reply-To: References: <5774188A.7090400@oracle.com> Message-ID: <5776D4DB.3020506@oracle.com> Thanks Tony On 06/29/2016 05:16 PM, Xuelei Fan wrote: > Looks fine to me. > > Thanks, > Xuelei > > On 6/30/2016 2:50 AM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this simple change to to undo the default settings >> for the jdk.security.provider.preferred. The only code changes are test >> related. The test now sets the property to test the previous default >> functionality. >> >> http://cr.openjdk.java.net/~ascarpino/8159180/webrev/ >> >> thanks >> >> Tony > From valerie.peng at oracle.com Fri Jul 1 21:24:02 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 1 Jul 2016 14:24:02 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <2A2E353B-E09E-4C56-96DE-E5D5158756A5@oracle.com> References: <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> <5775B762.3090000@oracle.com> <6759706E-1408-49E0-8FA0-4CD85E1770CA@oracle.com> <5775C46D.6050408@oracle.com> <2A2E353B-E09E-4C56-96DE-E5D5158756A5@oracle.com> Message-ID: <5776DF72.2050908@oracle.com> Mystery solved. Didn't notice that. :P Valerie On 6/30/2016 7:00 PM, Wang Weijun wrote: >> On Jul 1, 2016, at 9:16 AM, Valerie Peng wrote: >> >> Weird, I still see -provider on the link below. >> http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.sdiff.html > This is sdiff, you need to scroll to far right to see the new line. > > I should probably make the lines shorter one day. > > --Max > >> If you saw differently, I need to book an urgent doc appt for my eyes... >> Valerie >> >> On 6/30/2016 5:40 PM, Wang Weijun wrote: >>> Confused. http://cr.openjdk.java.net/~weijun/8130302/webrev.06/test/sun/security/tools/keytool/i18n.html.html has 53
  • keytool -list -storepass password -addprovider SUN >>>> Correct, SUN provider is not exported as a provider for ServiceLoader. I don't have preference to use -providerClass over -addprovider. Whatever is the expected usage is fine with me. >>> OK. >>> >>> Thanks >>> Max >>> From valerie.peng at oracle.com Fri Jul 1 21:32:20 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 1 Jul 2016 14:32:20 -0700 Subject: [9] RFR 8136459: MessageDigest.isEqual is not a "simple byte compare" Message-ID: <5776E163.7090000@oracle.com> Sean, Do you have one minute to spare for this trivial javadoc update? Can you please take a look at the CCC too? I plan to fast track it once you reviewed it. Bug: https://bugs.openjdk.java.net/browse/JDK-8136459 Webrev: http://cr.openjdk.java.net/~valeriep/8136459/webrev.00/ Thanks, Valerie From sean.mullan at oracle.com Fri Jul 1 21:34:40 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 Jul 2016 17:34:40 -0400 Subject: [9] RFR 8136459: MessageDigest.isEqual is not a "simple byte compare" In-Reply-To: <5776E163.7090000@oracle.com> References: <5776E163.7090000@oracle.com> Message-ID: <5776E1F0.60702@oracle.com> Looks fine. --Sean On 07/01/2016 05:32 PM, Valerie Peng wrote: > Sean, > > Do you have one minute to spare for this trivial javadoc update? Can you > please take a look at the CCC too? > I plan to fast track it once you reviewed it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136459 > Webrev: http://cr.openjdk.java.net/~valeriep/8136459/webrev.00/ > > Thanks, > Valerie From vincent.x.ryan at oracle.com Fri Jul 1 21:52:35 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 1 Jul 2016 22:52:35 +0100 Subject: [9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail Message-ID: Please review this change to correct two failing JCK tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8068290 Webrev: http://cr.openjdk.java.net/~vinnie/8068290/webrev.00/ PKCS12 is the default keystore type in JDK 9 and its implementation stores only X.509 certificates although the KeyStore API allows any Certificate object to be stored. This fix checks that the supplied certificate is an X509Certificate object before storing it. Thanks. From weijun.wang at oracle.com Sat Jul 2 01:04:43 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 2 Jul 2016 09:04:43 +0800 Subject: [9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail In-Reply-To: References: Message-ID: <4BB03A27-1370-4811-AC5A-D651999C97EB@oracle.com> Should engineSetKeyEntry make the same check? --Max > On Jul 2, 2016, at 5:52 AM, Vincent Ryan wrote: > > Please review this change to correct two failing JCK tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068290 > Webrev: http://cr.openjdk.java.net/~vinnie/8068290/webrev.00/ > > PKCS12 is the default keystore type in JDK 9 and its implementation stores only X.509 certificates > although the KeyStore API allows any Certificate object to be stored. > This fix checks that the supplied certificate is an X509Certificate object before storing it. > > Thanks. > From jonathan.gibbons at oracle.com Sat Jul 2 01:44:11 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 01 Jul 2016 18:44:11 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <0C8CD227-06A1-4964-861B-857992B700F1@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <0C8CD227-06A1-4964-861B-857992B700F1@oracle.com> Message-ID: <57771C6B.1020004@oracle.com> The test can also report which providers it is testing and/or skipping, so that anyone checking the .jtr file can verify the behavior. Maybe it fails if expected modules or providers are not found. -- Jon On 06/29/2016 10:50 AM, Mandy Chung wrote: > Valerie?s suggestion is a good one. The test will require a minimum image with cross-platform security providers to run the test while it can still verify other platform-specific providers. > > Mandy > >> On Jun 29, 2016, at 10:41 AM, Valerie Peng wrote: >> >> >> It's not like the test silently passes as the test still covers the cross-platform modules. >> The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. >> >> Just my .02, >> Valerie >> >> On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >>>> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >>>> >>>> >>>> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >>>> >>>> The original test already detects the OS and will skip certain providers accordingly. >>>> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? >>> ModuleFinder.ofSystem().find(String). >>> >>> We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. >>> >>> So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. >>> >>> This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. >>> >>> Mandy? >>> >>> Shura >>> >>>> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >>>> >>>> If we can't query what modules are available, then we may have to think of something else. >>>> Valerie >>>> >>>> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>>>> I?m including security-dev which would be a better list to review this test fix. >>>>> >>>>> Valerie, >>>>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>>>> >>>>> See my comments below. >>>>> >>>>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>>>> >>>>>> Hi. >>>>>> >>>>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>>>> >>>>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>>>> >>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>>>> The copyright header start year of the new tests should be 2016. >>>>> >>>>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>>>> - drop @requires >>>>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>>>> >>>>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>>>> >>>>> Mandy >>>>> From mandy.chung at oracle.com Sat Jul 2 22:26:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 2 Jul 2016 15:26:35 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> Message-ID: <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> > On Jul 1, 2016, at 6:20 PM, Alexandre (Shura) Iline wrote: > > Please review the new version of the fix. > http://cr.openjdk.java.net/~shurailine/8158670/webrev.01/ This looks much better. Small comment: you can use Layer::findModule and also Optional::ifPresent, like this: boot.findModule("jdk.crypto.ucrypto?) .ifPresent(m -> expected.add("com.oracle.security.ucrypto.UcryptoProvider?)); Mandy From sean.coffey at oracle.com Sun Jul 3 12:37:56 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sun, 3 Jul 2016 13:37:56 +0100 Subject: RFR: 8153948: sun/security/mscapi/ShortRSAKey1024.sh fails with "Field length overflow" In-Reply-To: References: Message-ID: <13a3de0a-c011-9622-7899-46f77d2b372a@oracle.com> Looks like a good test fix to me Ivan. Regards, Sean. On 29/06/2016 16:20, Ivan Gerasimov wrote: > Hello! > > The mentioned test was seen failing on a machine, where the keystore > contains a lot of certificates because they overflowed the maximum > allowed list of authorities in the CertificateRequest TLS message. > To make the test more robust, it is proposed to create a custom > TrustManager, which will filter out all the certificates except the > one really used in the test. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153948 > WEBREV: http://cr.openjdk.java.net/~igerasim/8153948/01/webrev/ > > Would you please help review this fix? > > With kind regard, > Ivan > From xuelei.fan at oracle.com Sun Jul 3 12:43:55 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 3 Jul 2016 20:43:55 +0800 Subject: RFR: 8153948: sun/security/mscapi/ShortRSAKey1024.sh fails with "Field length overflow" In-Reply-To: <13a3de0a-c011-9622-7899-46f77d2b372a@oracle.com> References: <13a3de0a-c011-9622-7899-46f77d2b372a@oracle.com> Message-ID: On 7/3/2016 8:37 PM, Se?n Coffey wrote: > Looks like a good test fix to me Ivan. > +1. Xuelei > Regards, > Sean. > > On 29/06/2016 16:20, Ivan Gerasimov wrote: >> Hello! >> >> The mentioned test was seen failing on a machine, where the keystore >> contains a lot of certificates because they overflowed the maximum >> allowed list of authorities in the CertificateRequest TLS message. >> To make the test more robust, it is proposed to create a custom >> TrustManager, which will filter out all the certificates except the >> one really used in the test. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153948 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8153948/01/webrev/ >> >> Would you please help review this fix? >> >> With kind regard, >> Ivan >> > From ivan.gerasimov at oracle.com Sun Jul 3 14:47:52 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 3 Jul 2016 17:47:52 +0300 Subject: RFR: 8153948: sun/security/mscapi/ShortRSAKey1024.sh fails with "Field length overflow" In-Reply-To: References: <13a3de0a-c011-9622-7899-46f77d2b372a@oracle.com> Message-ID: <07d4e35f-90b7-3a03-50dd-807207b4f11e@oracle.com> Thank you Se?n and Xuelei for your reviews! With kind regards, Ivan On 03.07.2016 15:43, Xuelei Fan wrote: > On 7/3/2016 8:37 PM, Se?n Coffey wrote: >> Looks like a good test fix to me Ivan. >> > +1. > > Xuelei > >> Regards, >> Sean. >> >> On 29/06/2016 16:20, Ivan Gerasimov wrote: >>> Hello! >>> >>> The mentioned test was seen failing on a machine, where the keystore >>> contains a lot of certificates because they overflowed the maximum >>> allowed list of authorities in the CertificateRequest TLS message. >>> To make the test more robust, it is proposed to create a custom >>> TrustManager, which will filter out all the certificates except the >>> one really used in the test. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153948 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8153948/01/webrev/ >>> >>> Would you please help review this fix? >>> >>> With kind regard, >>> Ivan >>> > From weijun.wang at oracle.com Mon Jul 4 06:03:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 4 Jul 2016 14:03:14 +0800 Subject: Questions on deprivileging a module Message-ID: I am working on JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth https://bugs.openjdk.java.net/browse/JDK-8159528 Several questions: 1. How does updating /make/common/Modules.gmk affect an exploded build? 2. I am using Unsafe in two places, once to rewrite a final filed in clone() [1], and another to call unsafe.ensureClassInitialized(KeyTab.class) so that I can call a non-public method there [2], but it seems a platform module cannot use Unsafe. Is there new ways to do these? What I can do now is 1) make it non-final 2) call a method in KeyTab to get it initialized. 3. I thought I can add something like grant codeBase "file://${java.home}/modules/java.security.jgss" { permission java.security.AllPermission; }; into java.policy so I can test with an exploded build. However, I see exceptions on ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util") not granted. The exception is not thrown when I am testing with an image build. Is there any way I can avoid it? Thanks Max [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/98f89fe2b722/src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java#l182 [2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/98f89fe2b722/src/java.security.jgss/share/classes/sun/security/krb5/KerberosSecrets.java From vincent.x.ryan at oracle.com Mon Jul 4 09:25:08 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 4 Jul 2016 10:25:08 +0100 Subject: [9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail In-Reply-To: <4BB03A27-1370-4811-AC5A-D651999C97EB@oracle.com> References: <4BB03A27-1370-4811-AC5A-D651999C97EB@oracle.com> Message-ID: <53F77963-1B80-409B-B62E-9D41D16F0A84@oracle.com> Good catch Max. I?ll add the check there too. > On 2 Jul 2016, at 02:04, Wang Weijun wrote: > > Should engineSetKeyEntry make the same check? > > --Max > >> On Jul 2, 2016, at 5:52 AM, Vincent Ryan wrote: >> >> Please review this change to correct two failing JCK tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8068290 >> Webrev: http://cr.openjdk.java.net/~vinnie/8068290/webrev.00/ >> >> PKCS12 is the default keystore type in JDK 9 and its implementation stores only X.509 certificates >> although the KeyStore API allows any Certificate object to be stored. >> This fix checks that the supplied certificate is an X509Certificate object before storing it. >> >> Thanks. >> > From ivan.gerasimov at oracle.com Mon Jul 4 13:37:19 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 4 Jul 2016 16:37:19 +0300 Subject: RFR: 8160267: Ucrypto config file cannot be read when -Dfile.encoding=UTF-16 is set Message-ID: Hello! When backporting JDK-8158633 to jdk8u, it was noticed that OracleUcrypto provider may experience difficulties reading its config file in UTF-16 environment. The fix is to explicitly specify the expected encoding of the config file. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160267 WEBREV: http://cr.openjdk.java.net/~igerasim/8160267/00/webrev/ With kind regards, Ivan From ivan.gerasimov at oracle.com Mon Jul 4 17:03:39 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 4 Jul 2016 20:03:39 +0300 Subject: RFR: 8160518: Semicolon is not recognized as comment starting character (Kerberos) Message-ID: Hello! We've got a complain that a semicolon character cannot be used to start a comment in the kerberos config file. In the documentation [1] I don't see mentioning comments at all, but it is said that the config file is in style of Windows INI file, and the later does allow semicolons to be used. This blog entry [2] also mentions the semicolon as an alternative to the hash sign '#'. Would you please review the trivial change? Comments, suggestions are very welcome. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160518 WEBREV: http://cr.openjdk.java.net/~igerasim/8160518/00/webrev/ [1] http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html [2] https://blogs.oracle.com/wangwj/entry/krb5_conf With kind regards, Ivan From sibabrata.sahoo at oracle.com Mon Jul 4 17:24:36 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 4 Jul 2016 10:24:36 -0700 (PDT) Subject: [9] RFR: 8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout Message-ID: Hi, Please review this patch for "8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout" JBS: https://bugs.openjdk.java.net/browse/JDK-8159861 Webrev: http://cr.openjdk.java.net/~ssahoo/8159861/webrev.00/ Description: The test generates several set of keypair among which few keypair takes time when keysize is large. Particularly for "DSA - 3072". It need to have a larger timeout value to be set to avoid timeout in certain machine with certain platform. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Mon Jul 4 17:41:47 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 4 Jul 2016 10:41:47 -0700 (PDT) Subject: [9] RFR: 8160341: Remove intermittent key from TestDSAGenParameterSpec.java Message-ID: Hi, Please review this patch for "8160341: Remove intermittent key from TestDSAGenParameterSpec.java" JBS: https://bugs.openjdk.java.net/browse/JDK-8160341 Webrev: http://cr.openjdk.java.net/~ssahoo/8160341/webrev.00/ Description: Removing intermittent keyword from the test. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Mon Jul 4 17:56:00 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 4 Jul 2016 10:56:00 -0700 (PDT) Subject: [9] RFR: 8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" Message-ID: <5157ff41-4751-4189-afc9-b6b5401224a2@default> Hi, Please review this patch for "8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" JBS: https://bugs.openjdk.java.net/browse/JDK-8160624 Webrev: http://cr.openjdk.java.net/~ssahoo/8160624/webrev.00/ Description: The test is for "keytool should be able to import certificates from remote SSL server". The failure was due to the serversocket which get pre-closed during communication. This patch simplify the test by another approach of implementation and fix such issues to not appear in future. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Mon Jul 4 18:07:15 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 4 Jul 2016 11:07:15 -0700 (PDT) Subject: [9] RFR: 8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout Message-ID: <221b3881-fe80-4509-b96a-cd6669338943@default> Hi, Please review this patch for "8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout" JBS: https://bugs.openjdk.java.net/browse/JDK-8158116 Webrev: http://cr.openjdk.java.net/~ssahoo/8158116/webrev.00/ Description: This JBS bug does not have enough information about the keysize causing the timeout issue. But I have observed the longer keysize take longer time to generate keys. That is the reason I thought to increase the timeout to avoid such issue. Please validate and let me know your suggestion. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jul 4 23:42:19 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 Jul 2016 07:42:19 +0800 Subject: [9] RFR: 8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout In-Reply-To: References: Message-ID: <0342b9a7-b708-c2e0-a9ac-d1202d54e9d9@oracle.com> Looks fine to me. Xuelei On 7/5/2016 1:24 AM, Sibabrata Sahoo wrote: > Hi, > > > > Please review this patch for ?8159861: > sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8159861 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8159861/webrev.00/ > > > > Description: > > The test generates several set of keypair among which few keypair takes > time when keysize is large. Particularly for ?DSA - 3072?. It need to > have a larger timeout value to be set to avoid timeout in certain > machine with certain platform. > > > > Thanks, > > Siba > > > From xuelei.fan at oracle.com Mon Jul 4 23:45:06 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 Jul 2016 07:45:06 +0800 Subject: [9] RFR: 8160341: Remove intermittent key from TestDSAGenParameterSpec.java In-Reply-To: References: Message-ID: Looks fine to me. Thanks, Xuelei On 7/5/2016 1:41 AM, Sibabrata Sahoo wrote: > Hi, > > > > Please review this patch for ?8160341: Remove intermittent key from > TestDSAGenParameterSpec.java? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160341 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8160341/webrev.00/ > > > > Description: > > Removing intermittent keyword from the test. > > > > Thanks, > > Siba > > > From xuelei.fan at oracle.com Mon Jul 4 23:45:59 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 Jul 2016 07:45:59 +0800 Subject: [9] RFR: 8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout In-Reply-To: <221b3881-fe80-4509-b96a-cd6669338943@default> References: <221b3881-fe80-4509-b96a-cd6669338943@default> Message-ID: Looks fine to me. Thanks, Xuelei On 7/5/2016 2:07 AM, Sibabrata Sahoo wrote: > Hi, > > > > Please review this patch for ?8158116: > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed > with timeout? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158116 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8158116/webrev.00/ > > > > Description: > > This JBS bug does not have enough information about the keysize causing > the timeout issue. But I have observed the longer keysize take longer > time to generate keys. That is the reason I thought to increase the > timeout to avoid such issue. Please validate and let me know your > suggestion. > > > > Thanks, > > Siba > > > From weijun.wang at oracle.com Tue Jul 5 01:15:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Jul 2016 09:15:32 +0800 Subject: [9] RFR: 8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" In-Reply-To: <5157ff41-4751-4189-afc9-b6b5401224a2@default> References: <5157ff41-4751-4189-afc9-b6b5401224a2@default> Message-ID: The change looks great. Thank you for removing another shell test. --Max > On Jul 5, 2016, at 1:56 AM, Sibabrata Sahoo wrote: > > Hi, > > Please review this patch for ?8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160624 > Webrev: http://cr.openjdk.java.net/~ssahoo/8160624/webrev.00/ > > Description: > The test is for ?keytool should be able to import certificates from remote SSL server?. The failure was due to the serversocket which get pre-closed during communication. This patch simplify the test by another approach of implementation and fix such issues to not appear in future. > > Thanks, > Siba From weijun.wang at oracle.com Tue Jul 5 03:53:22 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Jul 2016 11:53:22 +0800 Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> This test fails: import java.security.Permission; import java.sql.SQLPermission; public class SSL extends SecurityManager { @Override public void checkPermission(Permission perm, Object context) { checkPermission(perm); } public void checkPermission(Permission perm) { if (!(perm instanceof SQLPermission)) { return; } } public static void main(String[] args) throws Exception { System.setSecurityManager(new SSL()); X.go(); } static class X { static void go() { System.out.println(12); } } } The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class, or change SQLPermission to something defined in one of BOOT_MODULES. Note: the test is a simplified form of test/sun/security/krb5/auto/SSL.java (hence the name) and it fails when I am trying to deprivilege java.security.jgss. More observations: 1. If I directly run the test (not with jtreg), error is "java.lang.NoClassDefFoundError: SSL$X". 2. If I directly run the test but with javatest.jar in CLASSPATH, the failure is the same with jtreg run. Anyway, this test runs fine on jdk8u. Or, must I break the test into 2 parts and grant the SecurityManager part AllPermission? (I haven't tried it though). Thanks Max ------ Exception: java.lang.IllegalStateException thrown from the UncaughtExceptionHandler in thread "MainThread" STATUS:Failed.`main' threw exception: java.lang.IllegalStateException: Recursive update Exception in thread "main" java.lang.IllegalStateException: Recursive update at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(java.base at 9-internal/ConcurrentHashMap.java:1767) at jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(java.base at 9-internal/BuiltinClassLoader.java:727) at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base at 9-internal/BuiltinClassLoader.java:484) at jdk.internal.loader.BuiltinClassLoader.lambda$findClassInModuleOrNull$2(java.base at 9-internal/BuiltinClassLoader.java:449) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(java.base at 9-internal/BuiltinClassLoader.java:450) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 9-internal/BuiltinClassLoader.java:390) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 9-internal/BuiltinClassLoader.java:425) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 9-internal/BuiltinClassLoader.java:394) at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:364) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:185) at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) at SSL.checkPermission(SSL.java:42) at java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1285) at java.lang.System.getProperty(java.base at 9-internal/System.java:762) at sun.security.action.GetPropertyAction.run(java.base at 9-internal/GetPropertyAction.java:87) at sun.security.action.GetPropertyAction.run(java.base at 9-internal/GetPropertyAction.java:53) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at sun.security.action.GetPropertyAction.privilegedGetProperty(java.base at 9-internal/GetPropertyAction.java:107) at sun.net.www.protocol.jrt.JavaRuntimeURLConnection.getPermission(java.base at 9-internal/JavaRuntimeURLConnection.java:164) at java.lang.module.SystemModuleFinder$ImageModuleReader.checkPermissionToConnect(java.base at 9-internal/SystemModuleFinder.java:258) at java.lang.module.SystemModuleFinder$ImageModuleReader.(java.base at 9-internal/SystemModuleFinder.java:266) at java.lang.module.SystemModuleFinder$1.get(java.base at 9-internal/SystemModuleFinder.java:174) at java.lang.module.SystemModuleFinder$1.get(java.base at 9-internal/SystemModuleFinder.java:171) at java.lang.module.ModuleReference.open(java.base at 9-internal/ModuleReference.java:163) at jdk.internal.loader.BuiltinClassLoader.createModuleReader(java.base at 9-internal/BuiltinClassLoader.java:735) at jdk.internal.loader.BuiltinClassLoader.lambda$moduleReaderFor$3(java.base at 9-internal/BuiltinClassLoader.java:727) at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(java.base at 9-internal/ConcurrentHashMap.java:1716) at jdk.internal.loader.BuiltinClassLoader.moduleReaderFor(java.base at 9-internal/BuiltinClassLoader.java:727) at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base at 9-internal/BuiltinClassLoader.java:484) at jdk.internal.loader.BuiltinClassLoader.lambda$findClassInModuleOrNull$2(java.base at 9-internal/BuiltinClassLoader.java:449) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(java.base at 9-internal/BuiltinClassLoader.java:450) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 9-internal/BuiltinClassLoader.java:390) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 9-internal/BuiltinClassLoader.java:425) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 9-internal/BuiltinClassLoader.java:394) at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:364) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:185) at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) at SSL.checkPermission(SSL.java:42) at java.lang.SecurityManager.checkExit(java.base at 9-internal/SecurityManager.java:753) at java.lang.Runtime.exit(java.base at 9-internal/Runtime.java:120) at java.lang.System.exit(java.base at 9-internal/System.java:1666) at com.sun.javatest.Status.exit(Status.java:293) at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:81) From tiantian.du at oracle.com Tue Jul 5 06:45:51 2016 From: tiantian.du at oracle.com (Tim Du) Date: Tue, 5 Jul 2016 14:45:51 +0800 Subject: [9] RFR:8160333:Remove intermittent key from javax/net/ssl/TLSv12/ShortRSAKey512.java Message-ID: <577B579F.1050103@oracle.com> Hi, Please help to review the path for javax/net/ssl/TLSv12/ShortRSAKey512.java , JDK-8159501 has been fixed, and no bug is tracking issue on this test, @key intermittent can be removed.Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8160333 webrev: http://cr.openjdk.java.net/~tidu/8160333/webrev.00/ Regards Tim From Alan.Bateman at oracle.com Tue Jul 5 06:52:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 07:52:24 +0100 Subject: Questions on deprivileging a module In-Reply-To: References: Message-ID: On 04/07/2016 07:03, Wang Weijun wrote: > I am working on > > JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth > https://bugs.openjdk.java.net/browse/JDK-8159528 > > Several questions: > > 1. How does updating /make/common/Modules.gmk affect an exploded build? The mappings are used for both exploded and images build so the configuration in this make file is for both. > > 2. I am using Unsafe in two places, once to rewrite a final filed in clone() [1], and another to call unsafe.ensureClassInitialized(KeyTab.class) so that I can call a non-public method there [2], but it seems a platform module cannot use Unsafe. Is there new ways to do these? What I can do now is 1) make it non-final 2) call a method in KeyTab to get it initialized. Can you say any more on this? When you say "a platform module cannot use Unsafe" then do you mean a compilation error? Are you attempting to use sun.misc.Unsafe without a dependency on jdk.unsupported? > > 3. I thought I can add something like > > grant codeBase "file://${java.home}/modules/java.security.jgss" { > permission java.security.AllPermission; > }; > > into java.policy so I can test with an exploded build. However, I see exceptions on ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util") not granted. The exception is not thrown when I am testing with an image build. Is there any way I can avoid it? > Can you provide the stack trace or better, the output when running with -Djava.security.debug=failure,access. -Alan From weijun.wang at oracle.com Tue Jul 5 07:15:41 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Jul 2016 15:15:41 +0800 Subject: Questions on deprivileging a module In-Reply-To: References: Message-ID: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> > On Jul 5, 2016, at 2:52 PM, Alan Bateman wrote: > > On 04/07/2016 07:03, Wang Weijun wrote: > >> I am working on >> >> JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth >> https://bugs.openjdk.java.net/browse/JDK-8159528 >> >> Several questions: >> >> 1. How does updating /make/common/Modules.gmk affect an exploded build? > The mappings are used for both exploded and images build so the configuration in this make file is for both. I see. BTW, which file contain the mappings? > >> >> 2. I am using Unsafe in two places, once to rewrite a final filed in clone() [1], and another to call unsafe.ensureClassInitialized(KeyTab.class) so that I can call a non-public method there [2], but it seems a platform module cannot use Unsafe. Is there new ways to do these? What I can do now is 1) make it non-final 2) call a method in KeyTab to get it initialized. > Can you say any more on this? When you say "a platform module cannot use Unsafe" then do you mean a compilation error? Are you attempting to use sun.misc.Unsafe without a dependency on jdk.unsupported? I am using Unsafe in jdk.internal.misc, at least that's what the code is using now. It's a runtime error. @CallerSensitive public static Unsafe getUnsafe() { Class caller = Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(caller.getClassLoader())) throw new SecurityException("Unsafe"); <<<<<< The exception thrown return theUnsafe; } Just tried the one in jdk.unsupported, same error. > >> >> 3. I thought I can add something like >> >> grant codeBase "file://${java.home}/modules/java.security.jgss" { >> permission java.security.AllPermission; >> }; >> >> into java.policy so I can test with an exploded build. However, I see exceptions on ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util") not granted. The exception is not thrown when I am testing with an image build. Is there any way I can avoid it? >> > Can you provide the stack trace or better, the output when running with -Djava.security.debug=failure,access. Sorry but I cannot reproduce the failure now. Test is passing. No idea why. I did several make images since yesterday. Thanks Max > > -Alan From Alan.Bateman at oracle.com Tue Jul 5 07:56:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 08:56:35 +0100 Subject: Questions on deprivileging a module In-Reply-To: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> References: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> Message-ID: <8a592695-7b14-3dca-668d-eba2c038a7be@oracle.com> On 05/07/2016 08:15, Wang Weijun wrote: > : > It's a runtime error. > > @CallerSensitive > public static Unsafe getUnsafe() { > Class caller = Reflection.getCallerClass(); > if (!VM.isSystemDomainLoader(caller.getClassLoader())) > throw new SecurityException("Unsafe"); <<<<<< The exception thrown > return theUnsafe; > } > > Just tried the one in jdk.unsupported, same error. > Okay, maybe this restriction in jdk.internal.misc.Unsafe needs to relaxed. For now then I assume you can read Unsafe.theUnsafe which is how user code typically gets it. -Alan. From Alan.Bateman at oracle.com Tue Jul 5 08:07:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 09:07:44 +0100 Subject: Questions on deprivileging a module In-Reply-To: <1258116078.732449.1467705835515.JavaMail.zimbra@u-pem.fr> References: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> <8a592695-7b14-3dca-668d-eba2c038a7be@oracle.com> <1258116078.732449.1467705835515.JavaMail.zimbra@u-pem.fr> Message-ID: <6cf4ffb7-369e-92ed-f7d8-cb4f69a1407f@oracle.com> On 05/07/2016 09:03, Remi Forax wrote: > The other solution is to use a VarHandle instead of Unsafe for setting the final field, > i don't think that letting unprivileged module to access to Unsafe is a good idea. > Very true, I wasn't paying attending to why it is using Unsafe in the first place. That said, the context seems to be a standard (=platform) module rather than a user module. -Alan From weijun.wang at oracle.com Tue Jul 5 08:22:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Jul 2016 16:22:30 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> Message-ID: <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> > On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: > > The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class Update: any call that triggers a permission check will do. For example: import java.security.Permission; import java.sql.SQLPermission; public class SSL extends SecurityManager { @Override public void checkPermission(Permission perm, Object context) { checkPermission(perm); } public void checkPermission(Permission perm) { if (!(perm instanceof SQLPermission)) { return; } } public static void main(String[] args) throws Exception { System.setSecurityManager(new SSL()); System.getProperty("os.name"); } } From Xuelei.Fan at Oracle.Com Tue Jul 5 08:46:43 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 5 Jul 2016 16:46:43 +0800 Subject: [9] RFR:8160333:Remove intermittent key from javax/net/ssl/TLSv12/ShortRSAKey512.java In-Reply-To: <577B579F.1050103@oracle.com> References: <577B579F.1050103@oracle.com> Message-ID: <758BCF65-8E51-47AF-8FD5-14F270D56AC0@Oracle.Com> looks fine to me. Xuelei > On Jul 5, 2016, at 2:45 PM, Tim Du wrote: > > Hi, > > Please help to review the path for javax/net/ssl/TLSv12/ShortRSAKey512.java , JDK-8159501 has been fixed, and no bug is tracking issue on this test, @key intermittent can be removed.Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160333 > webrev: http://cr.openjdk.java.net/~tidu/8160333/webrev.00/ > > Regards > Tim From sibabrata.sahoo at oracle.com Tue Jul 5 11:20:10 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 5 Jul 2016 04:20:10 -0700 (PDT) Subject: [9] RFR: 8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly" Message-ID: <6fe26a08-8bf7-4def-84e2-e28e31bd845a@default> Hi, Please review the patch for "8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly"" JBS: https://bugs.openjdk.java.net/browse/JDK-8160210 Webrev: http://cr.openjdk.java.net/~ssahoo/8160210/webrev.00/ Description: This is a rare failure occurred in Mac OS X 10.10.5 (x86_64) and has not been seen as frequent failure. From the test point of view it does not look anything wrong. It is a very rare failure and the failure log does not leave much clue about the failure. I am just adding few debug statements such as "-Djavax.net.debug=ssl,handshake", so that if it will fail in future it will have some meaningful information to debug. NOTE: The code has been formatted with NetBeans IDE and that is the reason it appears to have change almost in all line numbers. Please suggest if any possible fix can be made for this bug. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiantian.du at oracle.com Tue Jul 5 12:11:28 2016 From: tiantian.du at oracle.com (Tim Du) Date: Tue, 5 Jul 2016 20:11:28 +0800 Subject: [9] RFR: JDK-7052815 Finish checking of 7052537 Message-ID: <577BA3F0.6060109@oracle.com> Hi , Please help to review the path for "JDK-7052815 :Finish checking of 7052537" . A few test are using removedProvider() to removed the security provider,like JDK-7052537, If the tests not in othervm,it will affect other tests. Checking tests which are using removedProvider() for security area and update them run in othervm mode to avoid the same issue. JBS: https://bugs.openjdk.java.net/browse/JDK-7052815 webrev: http://cr.openjdk.java.net/~tidu/7052815/webrev.00/ Regards Tim From xuelei.fan at oracle.com Tue Jul 5 12:32:31 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 Jul 2016 20:32:31 +0800 Subject: [9] RFR: 8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly" In-Reply-To: <6fe26a08-8bf7-4def-84e2-e28e31bd845a@default> References: <6fe26a08-8bf7-4def-84e2-e28e31bd845a@default> Message-ID: <0b27f884-e458-09e0-b40c-9dbb6bcf1693@oracle.com> You may also want to dump the SSL record so that we can analysis the record directly. -Djavax.net.debug=ssl,handshake,record This update does not actually address the potential problem. Please file a new bug for this update, and keep this bug open so that the issue can be tracked. Thanks, Xuelei On 7/5/2016 7:20 PM, Sibabrata Sahoo wrote: > Hi, > > > > Please review the patch for ?8160210: > javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut > down incorrectly"? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160210 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8160210/webrev.00/ > > > > Description: > > This is a rare failure occurred in Mac OS X 10.10.5 (x86_64) and has not > been seen as frequent failure. From the test point of view it does not > look anything wrong. > > It is a very rare failure and the failure log does not leave much clue > about the failure. I am just adding few debug statements such as > ?-Djavax.net.debug=ssl,handshake?, so that if it will fail in future it > will have some meaningful information to debug. > > NOTE: The code has been formatted with NetBeans IDE and that is the > reason it appears to have change almost in all line numbers. Please > suggest if any possible fix can be made for this bug. > > > > Thanks, > > Siba > > > From sibabrata.sahoo at oracle.com Tue Jul 5 12:41:15 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 5 Jul 2016 05:41:15 -0700 (PDT) Subject: [9] RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" Message-ID: Hi, Please review the patch for "8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]"" JBS: https://bugs.openjdk.java.net/browse/JDK-8079441 Webrev: http://cr.openjdk.java.net/~ssahoo/8079441/webrev.00/ Description: This is a rare failure. It looks to be the test failed due to unexpected exit of JVM in a Windows machine. Why JVM possibly exit for this test unexpectedly is unknown. But I thought to provide the fix using recent thread APIs and that might cause this test to work without such failure in future. The reason is, 1) This failure is not intended for the test and is not raised from Security library. 2) There are no such test failed in security component in past with same error which are implemented using new Thread API. 3) It makes sense to remove using older API and upgrade with new and retaining the same behavior. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Jul 5 15:00:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Jul 2016 08:00:30 -0700 Subject: Questions on deprivileging a module In-Reply-To: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> References: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> Message-ID: <0FDF4215-3920-4E80-A26A-0F9D8B706E36@oracle.com> > On Jul 5, 2016, at 12:15 AM, Wang Weijun wrote: > >>> 1. How does updating /make/common/Modules.gmk affect an exploded build? >> The mappings are used for both exploded and images build so the configuration in this make file is for both. > > I see. BTW, which file contain the mappings? It?s generated at the build time: $BUILD_OUTPUTDIR/support/gensrc/java.base/jdk/internal/module/ModuleLoaderMap.java Mandy From Alan.Bateman at oracle.com Tue Jul 5 15:11:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 16:11:11 +0100 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> Message-ID: On 05/07/2016 09:22, Wang Weijun wrote: >> On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: >> >> The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class > Update: any call that triggers a permission check will do. For example: > > Yes, tricky issue because checkPermission is triggering class loading and permission checks. It worked previously because the java.sql module was defined to the boot loader. -Alan From mandy.chung at oracle.com Tue Jul 5 15:50:58 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Jul 2016 08:50:58 -0700 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> Message-ID: > On Jul 5, 2016, at 8:11 AM, Alan Bateman wrote: > > On 05/07/2016 09:22, Wang Weijun wrote: > >>> On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: >>> >>> The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class >> Update: any call that triggers a permission check will do. For example: >> >> > Yes, tricky issue because checkPermission is triggering class loading and permission checks. It worked previously because the java.sql module was defined to the boot loader. Max - are you running the test with exploded image (see JDK-8155858 [1])? The java.policy grants permission to modules in the jimage. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8155858 From sean.mullan at oracle.com Tue Jul 5 16:40:43 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Jul 2016 12:40:43 -0400 Subject: RFR 8158589: Possible integer overflow issues for DRBG In-Reply-To: <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> References: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> Message-ID: <577BE30B.4030803@oracle.com> Looks fine, just a couple of typos: - HashDrbg.java 84 * Note: In each current calle, requested is seedLen, therefore small, s/calle/call/ - CtrDrbg.java 399 "entropy plus additonal input is too long"); s/additonal/additional/ --Sean On 06/16/2016 10:00 PM, Wang Weijun wrote: > Ping again. > >> On Jun 7, 2016, at 11:52 AM, Wang Weijun wrote: >> >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8158589/webrev.00/ >> >> For the reseedCounter case, the default reseedInterval is Integer.MAX_VALUE and there is no integer bigger than it, therefore a new check reseedCounter < 0 is added. I had thought about making it long but can a long field be a safe volatile? I am not sure. >> >> I added a label noreg-cleanup, or maybe noreg-hard is better? >> >> Thanks >> Max >> > From vincent.x.ryan at oracle.com Tue Jul 5 18:44:33 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 5 Jul 2016 19:44:33 +0100 Subject: [9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail In-Reply-To: <53F77963-1B80-409B-B62E-9D41D16F0A84@oracle.com> References: <4BB03A27-1370-4811-AC5A-D651999C97EB@oracle.com> <53F77963-1B80-409B-B62E-9D41D16F0A84@oracle.com> Message-ID: <98AC897F-BACE-4E51-B5FB-3C22C52015F6@oracle.com> I?ve updated the webrev to also check for X509Certificate in both engineSetKeyEntry methods and in engineSetEntry: http://cr.openjdk.java.net/~vinnie/8068290/webrev.01/ > On 4 Jul 2016, at 10:25, Vincent Ryan wrote: > > Good catch Max. I?ll add the check there too. > > >> On 2 Jul 2016, at 02:04, Wang Weijun wrote: >> >> Should engineSetKeyEntry make the same check? >> >> --Max >> >>> On Jul 2, 2016, at 5:52 AM, Vincent Ryan wrote: >>> >>> Please review this change to correct two failing JCK tests. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8068290 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8068290/webrev.00/ >>> >>> PKCS12 is the default keystore type in JDK 9 and its implementation stores only X.509 certificates >>> although the KeyStore API allows any Certificate object to be stored. >>> This fix checks that the supplied certificate is an X509Certificate object before storing it. >>> >>> Thanks. >>> >> > From artem.kosarev at oracle.com Tue Jul 5 19:28:44 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Tue, 5 Jul 2016 22:28:44 +0300 Subject: [9] RFR 8135114: sun/security/krb5/auto tests failed for tr locale. Message-ID: <9a3ec106-1f6d-4e8e-c2b8-3b788ad2accf@oracle.com> Could you please review the proposed fix for regression tests BUGURL: https://bugs.openjdk.java.net/browse/JDK-8135114 WEBREV: http://cr.openjdk.java.net/~akosarev/8135114/webrev.00 DESCRIPTION: **toLowerCase & toUpperCase methods were used without Locale specification. This resulted in incorrect conversion for some of the Locales (i.e. tr_TR.UTF-8). Changes were successfully tested with JPRT. Best regards, Artem Kosarev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Jul 5 20:36:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Jul 2016 13:36:42 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> Message-ID: > On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline wrote: > > This made sense, than you, Mandy. > > Please review new version: > http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ You can use Layer::findModule instead of Configuration::findModule. You can also use List::equals. Mandy From forax at univ-mlv.fr Tue Jul 5 08:03:55 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 Jul 2016 10:03:55 +0200 (CEST) Subject: Questions on deprivileging a module In-Reply-To: <8a592695-7b14-3dca-668d-eba2c038a7be@oracle.com> References: <9350E8C6-AFC2-4190-A4C4-A3A1ED8705D6@oracle.com> <8a592695-7b14-3dca-668d-eba2c038a7be@oracle.com> Message-ID: <1258116078.732449.1467705835515.JavaMail.zimbra@u-pem.fr> The other solution is to use a VarHandle instead of Unsafe for setting the final field, i don't think that letting unprivileged module to access to Unsafe is a good idea. cheers, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Wang Weijun" > Cc: "jigsaw-dev" , "OpenJDK" > Envoy?: Mardi 5 Juillet 2016 09:56:35 > Objet: Re: Questions on deprivileging a module > > On 05/07/2016 08:15, Wang Weijun wrote: > > > : > > It's a runtime error. > > > > @CallerSensitive > > public static Unsafe getUnsafe() { > > Class caller = Reflection.getCallerClass(); > > if (!VM.isSystemDomainLoader(caller.getClassLoader())) > > throw new SecurityException("Unsafe"); <<<<<< The exception thrown > > return theUnsafe; > > } > > > > Just tried the one in jdk.unsupported, same error. > > > Okay, maybe this restriction in jdk.internal.misc.Unsafe needs to > relaxed. For now then I assume you can read Unsafe.theUnsafe which is > how user code typically gets it. > > -Alan. > From alexandre.iline at oracle.com Sat Jul 2 01:20:38 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 1 Jul 2016 18:20:38 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> Message-ID: <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> Pleas review the new version of the fix. http://cr.openjdk.java.net/~shurailine/8158670/webrev.01/ I have executed the changed test successfully on linux, windows, mac os x and solaris. Shura > On Jun 29, 2016, at 10:43 AM, Alexandre (Shura) Iline wrote: > > >> On Jun 29, 2016, at 10:41 AM, Valerie Peng wrote: >> >> >> It's not like the test silently passes as the test still covers the cross-platform modules. >> The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. > > Oh ? that makes more sense. I mis-understood it originally. > > Let me fix it like this. > > Shura > >> >> Just my .02, >> Valerie >> >> On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >>>> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >>>> >>>> >>>> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >>>> >>>> The original test already detects the OS and will skip certain providers accordingly. >>>> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? >>> ModuleFinder.ofSystem().find(String). >>> >>> We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. >>> >>> So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. >>> >>> This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. >>> >>> Mandy? >>> >>> Shura >>> >>>> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >>>> >>>> If we can't query what modules are available, then we may have to think of something else. >>>> Valerie >>>> >>>> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>>>> I?m including security-dev which would be a better list to review this test fix. >>>>> >>>>> Valerie, >>>>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>>>> >>>>> See my comments below. >>>>> >>>>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>>>> >>>>>> Hi. >>>>>> >>>>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>>>> >>>>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>>>> >>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>>>> The copyright header start year of the new tests should be 2016. >>>>> >>>>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>>>> - drop @requires >>>>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>>>> >>>>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>>>> >>>>> Mandy >>>>> >> > From alexandre.iline at oracle.com Sat Jul 2 01:22:11 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 1 Jul 2016 18:22:11 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> Message-ID: <8066BF38-5AE6-4E00-B74E-1223F088F952@oracle.com> > On Jul 1, 2016, at 6:20 PM, Alexandre (Shura) Iline wrote: > > Pleas review the new version of the fix. > http://cr.openjdk.java.net/~shurailine/8158670/webrev.01/ > > I have executed the changed test successfully on linux, windows, mac os x and solaris. I have also executed it manually on my laptop with most relevant values for -limitmods. Shura > > Shura > >> On Jun 29, 2016, at 10:43 AM, Alexandre (Shura) Iline wrote: >> >> >>> On Jun 29, 2016, at 10:41 AM, Valerie Peng wrote: >>> >>> >>> It's not like the test silently passes as the test still covers the cross-platform modules. >>> The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. >> >> Oh ? that makes more sense. I mis-understood it originally. >> >> Let me fix it like this. >> >> Shura >> >>> >>> Just my .02, >>> Valerie >>> >>> On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >>>>> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >>>>> >>>>> >>>>> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >>>>> >>>>> The original test already detects the OS and will skip certain providers accordingly. >>>>> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? >>>> ModuleFinder.ofSystem().find(String). >>>> >>>> We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. >>>> >>>> So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. >>>> >>>> This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. >>>> >>>> Mandy? >>>> >>>> Shura >>>> >>>>> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >>>>> >>>>> If we can't query what modules are available, then we may have to think of something else. >>>>> Valerie >>>>> >>>>> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>>>>> I?m including security-dev which would be a better list to review this test fix. >>>>>> >>>>>> Valerie, >>>>>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>>>>> >>>>>> See my comments below. >>>>>> >>>>>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>>>>> >>>>>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>>>>> >>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>>>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>>>>> The copyright header start year of the new tests should be 2016. >>>>>> >>>>>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>>>>> - drop @requires >>>>>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>>>>> >>>>>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>>>>> >>>>>> Mandy >>>>>> >>> >> > From alexandre.iline at oracle.com Tue Jul 5 19:42:08 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 5 Jul 2016 12:42:08 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> Message-ID: <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> This made sense, than you, Mandy. Please review new version: http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ Shura > On Jul 2, 2016, at 3:26 PM, Mandy Chung wrote: > > >> On Jul 1, 2016, at 6:20 PM, Alexandre (Shura) Iline wrote: >> >> Please review the new version of the fix. >> http://cr.openjdk.java.net/~shurailine/8158670/webrev.01/ > > This looks much better. Small comment: you can use Layer::findModule and also Optional::ifPresent, like this: > > boot.findModule("jdk.crypto.ucrypto?) > .ifPresent(m -> expected.add("com.oracle.security.ucrypto.UcryptoProvider?)); > > Mandy > From alexandre.iline at oracle.com Tue Jul 5 19:44:37 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 5 Jul 2016 12:44:37 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <57771C6B.1020004@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <0C8CD227-06A1-4964-861B-857992B700F1@oracle.com> <57771C6B.1020004@oracle.com> Message-ID: <7873228D-58EC-4C72-9D7D-91454EE2EE6A@oracle.com> Jon, > On Jul 1, 2016, at 6:44 PM, Jonathan Gibbons wrote: > > The test can also report which providers it is testing and/or skipping, so that anyone checking the .jtr file can verify the behavior. I have added some debug output, pls take a look. http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ > > Maybe it fails if expected modules or providers are not found. In the current state the test would work with any module availabilities - it simply checks that order and presence of security providers is consistent with the module availabilities. Shura > > -- Jon > > > On 06/29/2016 10:50 AM, Mandy Chung wrote: >> Valerie?s suggestion is a good one. The test will require a minimum image with cross-platform security providers to run the test while it can still verify other platform-specific providers. >> >> Mandy >> >>> On Jun 29, 2016, at 10:41 AM, Valerie Peng wrote: >>> >>> >>> It's not like the test silently passes as the test still covers the cross-platform modules. >>> The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. >>> >>> Just my .02, >>> Valerie >>> >>> On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >>>>> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >>>>> >>>>> >>>>> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >>>>> >>>>> The original test already detects the OS and will skip certain providers accordingly. >>>>> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? >>>> ModuleFinder.ofSystem().find(String). >>>> >>>> We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. >>>> >>>> So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. >>>> >>>> This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. >>>> >>>> Mandy? >>>> >>>> Shura >>>> >>>>> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >>>>> >>>>> If we can't query what modules are available, then we may have to think of something else. >>>>> Valerie >>>>> >>>>> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>>>>> I?m including security-dev which would be a better list to review this test fix. >>>>>> >>>>>> Valerie, >>>>>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>>>>> >>>>>> See my comments below. >>>>>> >>>>>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>>>>> >>>>>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>>>>> >>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>>>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>>>>> The copyright header start year of the new tests should be 2016. >>>>>> >>>>>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>>>>> - drop @requires >>>>>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>>>>> >>>>>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>>>>> >>>>>> Mandy >>>>>> > From alexandre.iline at oracle.com Tue Jul 5 20:53:25 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 5 Jul 2016 13:53:25 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> Message-ID: > On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: > > >> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline wrote: >> >> This made sense, than you, Mandy. >> >> Please review new version: >> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ > > You can use Layer::findModule instead of Configuration::findModule. That is correct. Changed in place. > > You can also use List::equals. I am assuming you are suggesting to use List::equals in the bottom part of the test where the expected result is compared with the actual list of providers. The whole reason I redid that section to provide more information in the jtr file, both for a case of a failure and to find out what providers were actually expected for given configuration. I do not see how List:equals help me with that. Information on size mismatch is useful, and also the information on unexpected provider name. Shura > > Mandy From mandy.chung at oracle.com Tue Jul 5 21:31:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Jul 2016 14:31:09 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> Message-ID: > On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline wrote: > > >> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: >> >> >>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline wrote: >>> >>> This made sense, than you, Mandy. >>> >>> Please review new version: >>> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ >> >> You can use Layer::findModule instead of Configuration::findModule. > > That is correct. Changed in place. > >> >> You can also use List::equals. > > I am assuming you are suggesting to use List::equals in the bottom part of the test where the expected result is compared with the actual list of providers. The whole reason I redid that section to provide more information in the jtr file, both for a case of a failure and to find out what providers were actually expected for given configuration. I do not see how List:equals help me with that. Information on size mismatch is useful, and also the information on unexpected provider name. What you have is fine. The information is useful to help diagnosis. The alternative I was thinking is to check List::equals and if not equals, do line-108-117. It?s a minor thing and up to you. Mandy From xuelei.fan at oracle.com Wed Jul 6 01:31:48 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Jul 2016 09:31:48 +0800 Subject: [9] RFR 8135114: sun/security/krb5/auto tests failed for tr locale. In-Reply-To: <9a3ec106-1f6d-4e8e-c2b8-3b788ad2accf@oracle.com> References: <9a3ec106-1f6d-4e8e-c2b8-3b788ad2accf@oracle.com> Message-ID: <4b0ada22-b863-4ad4-6b25-6fcfee6c6d33@oracle.com> Looks like safe update to me. Thanks, Xuelei On 7/6/2016 3:28 AM, Artem Kosarev wrote: > Could you please review the proposed fix for regression tests > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8135114 > WEBREV: > http://cr.openjdk.java.net/~akosarev/8135114/webrev.00 > > DESCRIPTION: > * *toLowerCase & toUpperCase methods were used without Locale > specification. > This resulted in incorrect conversion for some of the Locales (i.e. > tr_TR.UTF-8). > > Changes were successfully tested with JPRT. > > Best regards, > Artem Kosarev. > > > From weijun.wang at oracle.com Wed Jul 6 04:32:03 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Jul 2016 12:32:03 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> Message-ID: On 7/5/2016 23:50, Mandy Chung wrote: > Max - are you running the test with exploded image (see JDK-8155858 [1])? No. The test also fails with recent promoted builds (ever since java.sql is de-priveleged). --Max From weijun.wang at oracle.com Wed Jul 6 06:28:53 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 6 Jul 2016 14:28:53 +0800 Subject: [9] RFR 8068290: JCK: 2 api/java_security/cert/ tests fail In-Reply-To: <98AC897F-BACE-4E51-B5FB-3C22C52015F6@oracle.com> References: <4BB03A27-1370-4811-AC5A-D651999C97EB@oracle.com> <53F77963-1B80-409B-B62E-9D41D16F0A84@oracle.com> <98AC897F-BACE-4E51-B5FB-3C22C52015F6@oracle.com> Message-ID: <0984E1F7-6A2C-4EB2-96E6-1AB220C34EF5@oracle.com> How about letting validateChain() throw a KeyStoreException directly? --Max > On Jul 6, 2016, at 2:44 AM, Vincent Ryan wrote: > > I?ve updated the webrev to also check for X509Certificate in both engineSetKeyEntry methods and in engineSetEntry: > http://cr.openjdk.java.net/~vinnie/8068290/webrev.01/ From tiantian.du at oracle.com Wed Jul 6 07:36:02 2016 From: tiantian.du at oracle.com (Tim Du) Date: Wed, 6 Jul 2016 15:36:02 +0800 Subject: [9] RFR:8160339 Remove intermittent key from javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java Message-ID: <577CB4E2.4000101@oracle.com> Hi, Please help to review the path for "8160339:Remove intermittent key from javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java ", JDK-8049314 has been fixed, and no bug is tracking issue on this test, @key intermittent can be removed.Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8160339 webrev: http://cr.openjdk.java.net/~tidu/8160339/webrev.00/ Regards Tim From Xuelei.Fan at Oracle.Com Wed Jul 6 07:56:46 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 6 Jul 2016 15:56:46 +0800 Subject: [9] RFR:8160339 Remove intermittent key from javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java In-Reply-To: <577CB4E2.4000101@oracle.com> References: <577CB4E2.4000101@oracle.com> Message-ID: <5F8EAE24-2C40-44D7-B2F7-53A059ACA12E@Oracle.Com> looks fine to me. Xuelei > On Jul 6, 2016, at 3:36 PM, Tim Du wrote: > > Hi, > > Please help to review the path for "8160339:Remove intermittent key from javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java ", JDK-8049314 has been fixed, and no bug is tracking issue on this test, @key intermittent can be removed.Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160339 > webrev: http://cr.openjdk.java.net/~tidu/8160339/webrev.00/ > > Regards > Tim From tiantian.du at oracle.com Wed Jul 6 08:04:39 2016 From: tiantian.du at oracle.com (Tim Du) Date: Wed, 6 Jul 2016 16:04:39 +0800 Subject: [9] RFR:8160337 Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java Message-ID: <577CBB97.7040806@oracle.com> Hi All, Would you help to review the path for "8160337:Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java"? JDK-8074580 has been fixed, @key intermittent can be removed.Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8160337 webrev: http://cr.openjdk.java.net/~tidu/8160337/webrev.00/ Regards Tim From Alan.Bateman at oracle.com Wed Jul 6 08:51:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Jul 2016 09:51:27 +0100 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> Message-ID: <13314581-a60d-9426-3b79-d2fc9f943758@oracle.com> On 06/07/2016 05:32, Weijun Wang wrote: > > On 7/5/2016 23:50, Mandy Chung wrote: >> Max - are you running the test with exploded image (see JDK-8155858 >> [1])? > > No. The test also fails with recent promoted builds (ever since > java.sql is de-priveleged). I assume this is a general issue with security manager implementations where the checkPermission implementation triggers permission checks and so leads to stack overflow (and depending on the area can surface with different errors or exceptions). Do we have older issues on this? -Alan From sean.mullan at oracle.com Wed Jul 6 14:40:07 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 6 Jul 2016 10:40:07 -0400 Subject: [9] RFR 8157667: sun/security/x509/URICertStore/ExtensionsWithLDAP.java has to be updated due to JDK-8134577 In-Reply-To: <5422fb64-ecac-1014-13b5-90c3546fd8d5@oracle.com> References: <5717b5e1-605f-2c46-2cfd-d0dff631dd5c@oracle.com> <8a63a9eb-1788-ca91-8ae9-627649426bb8@oracle.com> <5422fb64-ecac-1014-13b5-90c3546fd8d5@oracle.com> Message-ID: <577D1847.9090209@oracle.com> On 07/01/2016 09:38 AM, John Jiang wrote: > Ping again ;-) Looks good. My only comment is that SocksProxy.java might be generally useful for other tests, so it may make sense later on to move it to jdk/test/java/security/testlibrary, but no action is needed right now. --Sean > > John Jiang > > > On 2016/6/28 6:42, John Jiang wrote: >> Please review this patch. >> Thanks! >> >> John Jiang >> >> >> On 2016/6/24 16:55, John Jiang wrote: >>> Hi, >>> Due to JDK-8134577, the test >>> sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve >>> hosts from a local name service provider. >>> This fix creates a simple Socks4 proxy, and use it to resolve hosts >>> from Socket. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8157667 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8157667/webrev.01 >>> >>> Please note that, this fix provides two separated local hosts files. >>> Each of them contains only one host entry. >>> And the test is executed twice in deed. Each time, the test focus >>> only one specific host, and uses one hosts file accordingly. >>> If one hosts file includes two entries, like the below, >>> 127.0.0.1 ldap.host.for.crldp >>> 127.0.0.1 ldap.host.for.aia >>> then, only the first host, ldap.host.for.crldp, is resolved by the >>> proxy. >>> If I misunderstand something, or you have better solution, please let >>> me know. >>> >>> Thanks! >>> >>> John Jiang >>> >>> >> >> > From sean.mullan at oracle.com Wed Jul 6 15:05:40 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 6 Jul 2016 11:05:40 -0400 Subject: [9] RFR: JDK-7052815 Finish checking of 7052537 In-Reply-To: <577BA3F0.6060109@oracle.com> References: <577BA3F0.6060109@oracle.com> Message-ID: <577D1E44.7030201@oracle.com> Could you add a more descriptive title for this bug report than "Finish checking of 7052537"? How about "Change tests that remove providers to run in othervm mode". Also, have you also checked if there are tests that just add their own provider but don't remove it? This could also potentially cause strange behavior if another test run in parallel accidentally uses that provider (perhaps if it was inserted as the first provider and implemented an algorithm that the test was testing). Typo in RemoveProviders.java: 28 * @run main/othrevm RemoveProviders s/othrevm/othervm/ --Sean On 07/05/2016 08:11 AM, Tim Du wrote: > Hi , > > Please help to review the path for "JDK-7052815 :Finish checking of > 7052537" . > > A few test are using removedProvider() to removed the security > provider,like JDK-7052537, If the tests not in othervm,it will affect > other tests. Checking tests which are using removedProvider() for > security area and update them run in othervm mode to avoid the same issue. > > JBS: https://bugs.openjdk.java.net/browse/JDK-7052815 > webrev: http://cr.openjdk.java.net/~tidu/7052815/webrev.00/ > > Regards > Tim From jamil.j.nimeh at oracle.com Wed Jul 6 16:54:18 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 6 Jul 2016 09:54:18 -0700 Subject: RFR: JDK-8129972 (Clarify the javadoc for CodeSource) Message-ID: <577D37BA.4030506@oracle.com> Hello all, This is a quick webrev to clarify the behavior in the javadoc for a null URL input in the CodeSource constructors. There are a few other minor javadoc nit fixes too. Bug: https://bugs.openjdk.java.net/browse/JDK-8129972 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8129972/webrev.01 --Jamil From valerie.peng at oracle.com Wed Jul 6 17:08:06 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 Jul 2016 10:08:06 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> Message-ID: <577D3AF6.3020700@oracle.com> Changes look fine to me. Thanks, Valerie On 7/5/2016 2:31 PM, Mandy Chung wrote: >> On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline wrote: >> >> >>> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: >>> >>> >>>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline wrote: >>>> >>>> This made sense, than you, Mandy. >>>> >>>> Please review new version: >>>> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ >>> You can use Layer::findModule instead of Configuration::findModule. >> That is correct. Changed in place. >> >>> You can also use List::equals. >> I am assuming you are suggesting to use List::equals in the bottom part of the test where the expected result is compared with the actual list of providers. The whole reason I redid that section to provide more information in the jtr file, both for a case of a failure and to find out what providers were actually expected for given configuration. I do not see how List:equals help me with that. Information on size mismatch is useful, and also the information on unexpected provider name. > What you have is fine. The information is useful to help diagnosis. The alternative I was thinking is to check List::equals and if not equals, do line-108-117. It?s a minor thing and up to you. > > Mandy From rajan.halade at oracle.com Wed Jul 6 17:22:22 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 6 Jul 2016 10:22:22 -0700 Subject: [9] RFR:8160337 Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java In-Reply-To: <577CBB97.7040806@oracle.com> References: <577CBB97.7040806@oracle.com> Message-ID: Hi Tim, Thanks for taking care of this one. Since the test is still using random data key "randomness" should be retained. Thanks, Rajan On 7/6/16 1:04 AM, Tim Du wrote: > Hi All, > > Would you help to review the path for "8160337:Remove intermittent key > from sun/security/pkcs11/rsa/TestKeyPairGenerator.java"? JDK-8074580 > has been fixed, @key intermittent can be removed.Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160337 > webrev: http://cr.openjdk.java.net/~tidu/8160337/webrev.00/ > > Regards > Tim From alexandre.iline at oracle.com Wed Jul 6 18:31:44 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 6 Jul 2016 11:31:44 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <577D3AF6.3020700@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> <577D3AF6.3020700@oracle.com> Message-ID: <69DB9F31-F1D3-484C-8575-AA2A22515E0D@oracle.com> Valerie, could you sponsor the patch for me? Shura > On Jul 6, 2016, at 10:08 AM, Valerie Peng wrote: > > > Changes look fine to me. > Thanks, > Valerie > > On 7/5/2016 2:31 PM, Mandy Chung wrote: >>> On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline wrote: >>> >>> >>>> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: >>>> >>>> >>>>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline wrote: >>>>> >>>>> This made sense, than you, Mandy. >>>>> >>>>> Please review new version: >>>>> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ >>>> You can use Layer::findModule instead of Configuration::findModule. >>> That is correct. Changed in place. >>> >>>> You can also use List::equals. >>> I am assuming you are suggesting to use List::equals in the bottom part of the test where the expected result is compared with the actual list of providers. The whole reason I redid that section to provide more information in the jtr file, both for a case of a failure and to find out what providers were actually expected for given configuration. I do not see how List:equals help me with that. Information on size mismatch is useful, and also the information on unexpected provider name. >> What you have is fine. The information is useful to help diagnosis. The alternative I was thinking is to check List::equals and if not equals, do line-108-117. It?s a minor thing and up to you. >> >> Mandy > From sean.mullan at oracle.com Wed Jul 6 19:03:26 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 6 Jul 2016 15:03:26 -0400 Subject: RFR: JDK-8129972 (Clarify the javadoc for CodeSource) In-Reply-To: <577D37BA.4030506@oracle.com> References: <577D37BA.4030506@oracle.com> Message-ID: <577D55FE.2050406@oracle.com> Looks good. Add a noreg-doc label to the bug. --Sean On 07/06/2016 12:54 PM, Jamil Nimeh wrote: > Hello all, > > This is a quick webrev to clarify the behavior in the javadoc for a null > URL input in the CodeSource constructors. There are a few other minor > javadoc nit fixes too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129972 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8129972/webrev.01 > > --Jamil From sean.mullan at oracle.com Wed Jul 6 21:04:41 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 6 Jul 2016 17:04:41 -0400 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <13314581-a60d-9426-3b79-d2fc9f943758@oracle.com> References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> <13314581-a60d-9426-3b79-d2fc9f943758@oracle.com> Message-ID: <577D7269.8060400@oracle.com> On 07/06/2016 04:51 AM, Alan Bateman wrote: > On 06/07/2016 05:32, Weijun Wang wrote: > >> >> On 7/5/2016 23:50, Mandy Chung wrote: >>> Max - are you running the test with exploded image (see JDK-8155858 >>> [1])? >> >> No. The test also fails with recent promoted builds (ever since >> java.sql is de-priveleged). > I assume this is a general issue with security manager implementations > where the checkPermission implementation triggers permission checks and > so leads to stack overflow (and depending on the area can surface with > different errors or exceptions). Do we have older issues on this? Yes. Typically you can avoid these by either putting the custom SM on the bootclasspath or granting it AllPermission, or implementing a policy provider that checks if the caller's ProtectionDomain is the same as the custom SM. This one is a little different though. I will need to look into it some more. Does your SSL code match up with the stack trace? The test only has 27 lines, but the stack trace says it was called from line 42. --Sean From weijun.wang at oracle.com Wed Jul 6 23:47:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 07:47:09 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <577D7269.8060400@oracle.com> References: <34D2305D-6B2B-46F4-951A-7A22062977B6@oracle.com> <92587C03-1A69-4981-B58D-C676E781B33B@oracle.com> <13314581-a60d-9426-3b79-d2fc9f943758@oracle.com> <577D7269.8060400@oracle.com> Message-ID: <462A5A40-6065-42F9-9FFA-1CCB11FEB815@oracle.com> > On Jul 7, 2016, at 5:04 AM, Sean Mullan wrote: > > Does your SSL code match up with the stack trace? The test only has 27 lines, but the stack trace says it was called from line 42. My local SSL.java still contains the GPL comments and I didn't paste them here. Line 42 is if (!(perm instanceof SQLPermission)) { BTW, I also tried putting the SecurityManager impl into a different codePath with AllPermission granted, and load it on the command line with -Djava.security.manager=X, the test still failed with the same exception. --Max From weijun.wang at oracle.com Thu Jul 7 01:08:58 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 09:08:58 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: References: Message-ID: > On Jul 7, 2016, at 8:19 AM, Peter Firmstone wrote: > > Perhaps the policy provider hasn't been refreshed when the new security manager is in force? Try doing a Policy.refresh() in the SecurityManager constructor. You mean Policy.getPolicy().refresh()? No difference. And I don't think this simple SecurityManager makes use of Policy at all. Thanks Max > > Regards, > > Peter. > > Sent from my Samsung device. > > ---- Original message ---- > From: Wang Weijun > Sent: 07/07/2016 09:47:09 am > To: Sean Mullan > Cc: jigsaw-dev ; OpenJDK > Subject: Re: Strange test failure when referencing a class in a deprivileged module > > > > On Jul 7, 2016, at 5:04 AM, Sean Mullan wrote: > > > > Does your SSL code match up with the stack trace? The test only has 27 lines, but the stack trace says it was called from line 42. > > My local SSL.java still contains the GPL comments and I didn't paste them here. Line 42 is > > if (!(perm instanceof SQLPermission)) { > > BTW, I also tried putting the SecurityManager impl into a different codePath with AllPermission granted, and load it on the command line with -Djava.security.manager=X, the test still failed with the same exception. > > --Max > > From weijun.wang at oracle.com Thu Jul 7 03:45:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 11:45:08 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <22385eff216e6b905bb30aca8b526ce0@org.tizen.email> References: <22385eff216e6b905bb30aca8b526ce0@org.tizen.email> Message-ID: I run the program directly (not from jtreg) and the result is different: Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception at SSL.checkPermission(SSL.java:21) at java.lang.SecurityManager.checkPropertyAccess(java.base at 9-ea/SecurityManager.java:1285) at java.lang.System.getProperty(java.base at 9-ea/System.java:762) at SSL.main(SSL.java:28) Then I add -Djava.security.debug=all, and the exact old exception is back! The debug output [1] has nothing special, in fact there is no difference if I substitute SQLPermission to AllPermission, except that with AllPermission the program runs fine. Thanks Max [1] https://gist.github.com/wangweij/b7d031dea470000c456b169f1e733eac > On Jul 7, 2016, at 11:02 AM, Peter Firmstone wrote: > > Have you tried setting the jvm in security debug mode to see else might be occurring? If so can you send the output? > > Regards, > > Peter. > > Sent from my Samsung device. From sibabrata.sahoo at oracle.com Thu Jul 7 07:33:38 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 7 Jul 2016 07:33:38 +0000 (UTC) Subject: [9] RFR: 8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 In-Reply-To: <0b27f884-e458-09e0-b40c-9dbb6bcf1693@oracle.com> References: <6fe26a08-8bf7-4def-84e2-e28e31bd845a@default> <0b27f884-e458-09e0-b40c-9dbb6bcf1693@oracle.com> Message-ID: <59097746-c190-42ba-a1f9-889cc216c2f6@default> Hi Xuelei, As suggested I have created a new bug to enable debug log for the failure raised for JDK-8160210. Now the original bug JDK-8160210 will be under observation until the failure found again in future. Because the fix is for a new bug, so the original subject line changed for this email thread. JBS: https://bugs.openjdk.java.net/browse/JDK-8160940 Webrev: http://cr.openjdk.java.net/~ssahoo/8160940/webrev.00/ Change over previous: This change set has no change over previous except adding "record" to JVM param "-Djavax.net.debug ". Thanks, Siba -----Original Message----- From: Xuelei Fan Sent: Tuesday, July 05, 2016 6:03 PM To: Sibabrata Sahoo; security-dev at openjdk.java.net Subject: Re: [9] RFR: 8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly" You may also want to dump the SSL record so that we can analysis the record directly. -Djavax.net.debug=ssl,handshake,record This update does not actually address the potential problem. Please file a new bug for this update, and keep this bug open so that the issue can be tracked. Thanks, Xuelei On 7/5/2016 7:20 PM, Sibabrata Sahoo wrote: > Hi, > > > > Please review the patch for "8160210: > javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer > shut down incorrectly"" > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160210 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8160210/webrev.00/ > > > > Description: > > This is a rare failure occurred in Mac OS X 10.10.5 (x86_64) and has > not been seen as frequent failure. From the test point of view it does > not look anything wrong. > > It is a very rare failure and the failure log does not leave much clue > about the failure. I am just adding few debug statements such as > "-Djavax.net.debug=ssl,handshake", so that if it will fail in future > it will have some meaningful information to debug. > > NOTE: The code has been formatted with NetBeans IDE and that is the > reason it appears to have change almost in all line numbers. Please > suggest if any possible fix can be made for this bug. > > > > Thanks, > > Siba > > > From Xuelei.Fan at Oracle.Com Thu Jul 7 08:25:35 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 7 Jul 2016 16:25:35 +0800 Subject: [9] RFR: 8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 In-Reply-To: <59097746-c190-42ba-a1f9-889cc216c2f6@default> References: <6fe26a08-8bf7-4def-84e2-e28e31bd845a@default> <0b27f884-e458-09e0-b40c-9dbb6bcf1693@oracle.com> <59097746-c190-42ba-a1f9-889cc216c2f6@default> Message-ID: <2960C4AB-5B6D-4A94-83A9-2346BBA6D1A3@Oracle.Com> looks fine to me. Thanks, Xuelei > On Jul 7, 2016, at 3:33 PM, Sibabrata Sahoo wrote: > > Hi Xuelei, > > As suggested I have created a new bug to enable debug log for the failure raised for JDK-8160210. Now the original bug JDK-8160210 will be under observation until the failure found again in future. > > Because the fix is for a new bug, so the original subject line changed for this email thread. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160940 > Webrev: http://cr.openjdk.java.net/~ssahoo/8160940/webrev.00/ > > Change over previous: > This change set has no change over previous except adding "record" to JVM param "-Djavax.net.debug ". > > Thanks, > Siba > > -----Original Message----- > From: Xuelei Fan > Sent: Tuesday, July 05, 2016 6:03 PM > To: Sibabrata Sahoo; security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8160210: javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer shut down incorrectly" > > You may also want to dump the SSL record so that we can analysis the record directly. > > -Djavax.net.debug=ssl,handshake,record > > This update does not actually address the potential problem. Please file a new bug for this update, and keep this bug open so that the issue can be tracked. > > Thanks, > Xuelei > >> On 7/5/2016 7:20 PM, Sibabrata Sahoo wrote: >> Hi, >> >> >> >> Please review the patch for "8160210: >> javax/net/ssl/HttpsURLConnection/Equals.java failed with "SSL peer >> shut down incorrectly"" >> >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160210 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8160210/webrev.00/ >> >> >> >> Description: >> >> This is a rare failure occurred in Mac OS X 10.10.5 (x86_64) and has >> not been seen as frequent failure. From the test point of view it does >> not look anything wrong. >> >> It is a very rare failure and the failure log does not leave much clue >> about the failure. I am just adding few debug statements such as >> "-Djavax.net.debug=ssl,handshake", so that if it will fail in future >> it will have some meaningful information to debug. >> >> NOTE: The code has been formatted with NetBeans IDE and that is the >> reason it appears to have change almost in all line numbers. Please >> suggest if any possible fix can be made for this bug. >> >> >> >> Thanks, >> >> Siba > From weijun.wang at oracle.com Thu Jul 7 08:27:43 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 16:27:43 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <9029076ca5f8fcd39076007dda00ba0a@org.tizen.email> References: <9029076ca5f8fcd39076007dda00ba0a@org.tizen.email> Message-ID: <29624496-A4FE-4112-B1ED-B77EE09842A8@oracle.com> Like this? https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 The horizontal line is printed on line 706 of the gist. --Max > On Jul 7, 2016, at 12:57 PM, Peter Firmstone wrote: > > Can you change the test to call checkPermission prior to setting SSL as the system security manager? > > This will just ensure that all necessary classes are loaded prior to SSL becoming the security manager. > > Regards, > > Peter. From Alan.Bateman at oracle.com Thu Jul 7 08:37:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jul 2016 09:37:49 +0100 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <29624496-A4FE-4112-B1ED-B77EE09842A8@oracle.com> References: <9029076ca5f8fcd39076007dda00ba0a@org.tizen.email> <29624496-A4FE-4112-B1ED-B77EE09842A8@oracle.com> Message-ID: <69104e7c-5f12-67f9-cdfe-150f6b21bafd@oracle.com> On 07/07/2016 09:27, Wang Weijun wrote: > Like this? > > https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 > > The horizontal line is printed on line 706 of the gist. > I assume the suggestion was to reference SQLPermission before setting the security manager. As regards module loading then we can re-wording this specific case but fundamentally then anything in the checkPermission implementation that triggers a permission check is going to lead to a recursive call to checkPermission. -Alan From weijun.wang at oracle.com Thu Jul 7 08:44:24 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 16:44:24 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <69104e7c-5f12-67f9-cdfe-150f6b21bafd@oracle.com> References: <9029076ca5f8fcd39076007dda00ba0a@org.tizen.email> <29624496-A4FE-4112-B1ED-B77EE09842A8@oracle.com> <69104e7c-5f12-67f9-cdfe-150f6b21bafd@oracle.com> Message-ID: <6164807E-DCDB-4E80-8F1B-9D0160E3B979@oracle.com> > On Jul 7, 2016, at 4:37 PM, Alan Bateman wrote: > > On 07/07/2016 09:27, Wang Weijun wrote: > >> Like this? >> >> https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 >> >> The horizontal line is printed on line 706 of the gist. >> > I assume the suggestion was to reference SQLPermission before setting the security manager. As regards module loading then we can re-wording this specific case but fundamentally then anything in the checkPermission implementation that triggers a permission check is going to lead to a recursive call to checkPermission. If I add a "new SQLPermission("setLog");" at the beginning, then there will be no exception thrown. The stack trace does show the issue arise from resolving SQLPermission. Peter says "all necessary classes are loaded", and I thought it's about the access control things. --Max > > -Alan From weijun.wang at oracle.com Thu Jul 7 08:55:26 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 16:55:26 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <7a8ae05c9c14d48871de99fc89141b62@org.tizen.email> References: <7a8ae05c9c14d48871de99fc89141b62@org.tizen.email> Message-ID: > On Jul 7, 2016, at 4:47 PM, Peter Firmstone wrote: > > Sorry, I wasn't clear, I meant, create a new instance of SSL, call its checkPermission method, then make that instance your system security manager. That would cure the test too, since it references SQLPermission when checkPermission is called. In another reply to Alan, I said a single "new SQLPermission("setLog");" is enough. --Max > > Although the check permission call will be repeated in the test, it will have run while the standard SecurityManager is in force, so the jvm won't lazy load any classes that require permission checks, during the test permission check as that will happen during the first permission check call. > > Cheers, > > Peter. > > Sent from my Samsung device. > > ---- Original message ---- > From: Wang Weijun > Sent: 07/07/2016 06:27:43 pm > To: Peter Firmstone > Cc: SeanMullan ; jigsaw-dev ; OpenJDK > Subject: Re: Strange test failure when referencing a class in a deprivileged module > > Like this? > > https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 > > The horizontal line is printed on line 706 of the gist. > > --Max > > > On Jul 7, 2016, at 12:57 PM, Peter Firmstone wrote: > > > > Can you change the test to call checkPermission prior to setting SSL as the system security manager? > > > > This will just ensure that all necessary classes are loaded prior to SSL becoming the security manager. > > > > Regards, > > > > Peter. > > From weijun.wang at oracle.com Thu Jul 7 08:56:36 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Jul 2016 16:56:36 +0800 Subject: [9] RFR: 8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]" In-Reply-To: References: Message-ID: <8A1E799E-FD31-4994-B4BE-2D2B066128CB@oracle.com> Hi Siba I don't think we need to fix it this way. While the Thread APIs are old they are not obsolete or deprecated. Also, I don't understand how this rewrite using new APIs could be any useful for the bug. I see another bug JDK-8160596 in the hotspot category was closed as a dup, and I believe your fix won't be able to cover that failure. Since a lot of people believes this is VM or OS related, I'd rather reopen that bug and close yours as a duplicate. Or, you change the category to hotspot. --Max > On Jul 5, 2016, at 8:41 PM, Sibabrata Sahoo wrote: > > Hi, > > Please review the patch for ?8079441: Intermittent failures on Windows with "Unexpected exit from test [exit code: 1080890248]"? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8079441 > Webrev: http://cr.openjdk.java.net/~ssahoo/8079441/webrev.00/ > > Description: > This is a rare failure. It looks to be the test failed due to unexpected exit of JVM in a Windows machine. Why JVM possibly exit for this test unexpectedly is unknown. But I thought to provide the fix using recent thread APIs and that might cause this test to work without such failure in future. The reason is, > 1) This failure is not intended for the test and is not raised from Security library. > 2) There are no such test failed in security component in past with same error which are implemented using new Thread API. > 3) It makes sense to remove using older API and upgrade with new and retaining the same behavior. > > Thanks, > Siba From tiantian.du at oracle.com Thu Jul 7 09:11:41 2016 From: tiantian.du at oracle.com (Tim Du) Date: Thu, 7 Jul 2016 17:11:41 +0800 Subject: [9] RFR: JDK-7052815 Change tests that remove or add providers to run in othervm mode In-Reply-To: <577D1E44.7030201@oracle.com> References: <577BA3F0.6060109@oracle.com> <577D1E44.7030201@oracle.com> Message-ID: <577E1CCD.5060405@oracle.com> Hi Sean: Thank you for reviewing the codes. I updated the title for this bug and added othervm for the tests that add but not remove their own provider. Also corrected the typo. New webrev is available here: http://cr.openjdk.java.net/~tidu/7052815/webrev.01/ . Please help to review it again.Thanks. Regards Tim On 2016/7/6 23:05, Sean Mullan wrote: > Could you add a more descriptive title for this bug report than > "Finish checking of 7052537"? How about "Change tests that remove > providers to run in othervm mode". > > Also, have you also checked if there are tests that just add their own > provider but don't remove it? This could also potentially cause > strange behavior if another test run in parallel accidentally uses > that provider (perhaps if it was inserted as the first provider and > implemented an algorithm that the test was testing). > > Typo in RemoveProviders.java: > > 28 * @run main/othrevm RemoveProviders > > s/othrevm/othervm/ > > --Sean > > On 07/05/2016 08:11 AM, Tim Du wrote: >> Hi , >> >> Please help to review the path for "JDK-7052815 :Finish checking of >> 7052537" . >> >> A few test are using removedProvider() to removed the security >> provider,like JDK-7052537, If the tests not in othervm,it will affect >> other tests. Checking tests which are using removedProvider() for >> security area and update them run in othervm mode to avoid the same >> issue. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-7052815 >> webrev: http://cr.openjdk.java.net/~tidu/7052815/webrev.00/ >> >> Regards >> Tim From rajan.halade at oracle.com Thu Jul 7 17:30:46 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 7 Jul 2016 10:30:46 -0700 Subject: [9] RFR: JDK-7052815 Change tests that remove or add providers to run in othervm mode In-Reply-To: <577E1CCD.5060405@oracle.com> References: <577BA3F0.6060109@oracle.com> <577D1E44.7030201@oracle.com> <577E1CCD.5060405@oracle.com> Message-ID: Hi Tim, Please also update the copyright year to 2016 wherever applicable. Thanks, Rajan On 7/7/16 2:11 AM, Tim Du wrote: > Hi Sean: > > Thank you for reviewing the codes. > I updated the title for this bug and added othervm for the tests that > add but not remove their own provider. Also corrected the typo. New > webrev is available here: > http://cr.openjdk.java.net/~tidu/7052815/webrev.01/ . > Please help to review it again.Thanks. > > Regards > Tim > On 2016/7/6 23:05, Sean Mullan wrote: >> Could you add a more descriptive title for this bug report than >> "Finish checking of 7052537"? How about "Change tests that remove >> providers to run in othervm mode". >> >> Also, have you also checked if there are tests that just add their >> own provider but don't remove it? This could also potentially cause >> strange behavior if another test run in parallel accidentally uses >> that provider (perhaps if it was inserted as the first provider and >> implemented an algorithm that the test was testing). >> >> Typo in RemoveProviders.java: >> >> 28 * @run main/othrevm RemoveProviders >> >> s/othrevm/othervm/ >> >> --Sean >> >> On 07/05/2016 08:11 AM, Tim Du wrote: >>> Hi , >>> >>> Please help to review the path for "JDK-7052815 :Finish checking of >>> 7052537" . >>> >>> A few test are using removedProvider() to removed the security >>> provider,like JDK-7052537, If the tests not in othervm,it will affect >>> other tests. Checking tests which are using removedProvider() for >>> security area and update them run in othervm mode to avoid the same >>> issue. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-7052815 >>> webrev: http://cr.openjdk.java.net/~tidu/7052815/webrev.00/ >>> >>> Regards >>> Tim > From sean.mullan at oracle.com Thu Jul 7 17:33:49 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 7 Jul 2016 13:33:49 -0400 Subject: RFR: 8160267: Ucrypto config file cannot be read when -Dfile.encoding=UTF-16 is set In-Reply-To: References: Message-ID: <577E927D.7040006@oracle.com> Looks fine to me. --Sean On 07/04/2016 09:37 AM, Ivan Gerasimov wrote: > Hello! > > When backporting JDK-8158633 to jdk8u, it was noticed that OracleUcrypto > provider may experience difficulties reading its config file in UTF-16 > environment. > > The fix is to explicitly specify the expected encoding of the config file. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160267 > WEBREV: http://cr.openjdk.java.net/~igerasim/8160267/00/webrev/ > > With kind regards, > Ivan > From svetlana.nikandrova at oracle.com Thu Jul 7 18:29:12 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 07 Jul 2016 21:29:12 +0300 Subject: RFR 8054537: sun.security.x509.SerialNumber constructor should not accept negative numbers Message-ID: <577E9F78.3090303@oracle.com> Hello, could you please review this simple fix. Issue: https://bugs.openjdk.java.net/browse/JDK-8054537 Webrev: http://cr.openjdk.java.net/~snikandrova/8054537/webrev.00/ Description: Added check if SerialNumber constructor's parameter is negative. Thank you, Svetlana From peter.firmstone at zeus.net.au Thu Jul 7 00:19:17 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Jul 2016 10:19:17 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: Perhaps the policy provider hasn't been refreshed when the new security manager is in force? ?Try doing a Policy.refresh() in the SecurityManager constructor. Regards, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Wang Weijun Sent: 07/07/2016 09:47:09 am To: Sean Mullan Cc: jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module >?On?Jul?7,?2016,?at?5:04?AM,?Sean?Mullan??wrote: >? >?Does?your?SSL?code?match?up?with?the?stack?trace??The?test?only?has?27?lines,?but?the?stack?trace?says?it?was?called?from?line?42. My?local?SSL.java?still?contains?the?GPL?comments?and?I?didn't?paste?them?here.?Line?42?is ?????????????????if?(!(perm?instanceof?SQLPermission))?{ BTW,?I?also?tried?putting?the?SecurityManager?impl?into?a?different?codePath?with?AllPermission?granted,?and?load?it?on?the?command?line?with?-Djava.security.manager=X,?the?test?still?failed?with?the?same?exception. --Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Jul 7 03:02:19 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Jul 2016 13:02:19 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <22385eff216e6b905bb30aca8b526ce0@org.tizen.email> Have you tried setting the jvm in security debug mode to see else might be occurring? ?If so can you send the output? Regards, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Wang Weijun Sent: 07/07/2016 11:08:58 am To: Peter Firmstone Cc: SeanMullan ; jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module >?On?Jul?7,?2016,?at?8:19?AM,?Peter?Firmstone??wrote: >? >?Perhaps?the?policy?provider?hasn't?been?refreshed?when?the?new?security?manager?is?in?force???Try?doing?a?Policy.refresh()?in?the?SecurityManager?constructor. You?mean?Policy.getPolicy().refresh()??No?difference And?I?don't?think?this?simple?SecurityManager?makes?use?of?Policy?at?all. Thanks Max >? >?Regards, >? >?Peter. >? >?Sent?from?my?Samsung?device. >?? >?----?Original?message?---- >?From:?Wang?Weijun? >?Sent:?07/07/2016?09:47:09?am >?To:?Sean?Mullan? >?Cc:?jigsaw-dev?;?OpenJDK? >?Subject:?Re:?Strange?test?failure?when?referencing?a?class?in?a?deprivileged?module >? >? >?>?On?Jul?7,?2016,?at?5:04?AM,?Sean?Mullan??wrote:? >?>?? >?>?Does?your?SSL?code?match?up?with?the?stack?trace??The?test?only?has?27?lines,?but?the?stack?trace?says?it?was?called?from?line?42.? >? >?My?local?SSL.java?still?contains?the?GPL?comments?and?I?didn't?paste?them?here.?Line?42?is? >? >??????????????????if?(!(perm?instanceof?SQLPermission))?{? >? >?BTW,?I?also?tried?putting?the?SecurityManager?impl?into?a?different?codePath?with?AllPermission?granted,?and?load?it?on?the?command?line?with?-Djava.security.manager=X,?the?test?still?failed?with?the?same?exception.? >? >?--Max? >? >? -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Jul 7 04:57:53 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Jul 2016 14:57:53 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <9029076ca5f8fcd39076007dda00ba0a@org.tizen.email> Can you change the test to call checkPermission prior to setting SSL as the system security manager? This will just ensure that all necessary classes are loaded prior to SSL becoming the security manager.? Regards, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Wang Weijun Sent: 07/07/2016 01:45:08 pm To: Peter Firmstone Cc: SeanMullan ; jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module I?run?the?program?directly?(not?from?jtreg)?and?the?result?is?different: Exception?in?thread?"main"?java.lang.BootstrapMethodError:?call?site?initialization?exception ????at?SSL.checkPermission(SSL.java:21) ????at?java.lang.SecurityManager.checkPropertyAccess(java.base at 9-ea/SecurityManager.java:1285) ????at?java.lang.System.getProperty(java.base at 9-ea/System.java:762) ????at?SSL.main(SSL.java:28) Then?I?add?-Djava.security.debug=all,?and?the?exact?old?exception?is?back!?The?debug?output?[1]?has?nothing?special,?in?fact?there?is?no?difference?if?I?substitute?SQLPermission?to?AllPermission,?except?that?with?AllPermission?the?program?runs?fine. Thanks Max [1]?https://gist.github.com/wangweij/b7d031dea470000c456b169f1e733eac >?On?Jul?7,?2016,?at?11:02?AM,?Peter?Firmstone??wrote: >? >?Have?you?tried?setting?the?jvm?in?security?debug?mode?to?see?else?might?be?occurring???If?so?can?you?send?the?output? >? >?Regards, >? >?Peter. >? >?Sent?from?my?Samsung?device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Jul 7 08:47:00 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Jul 2016 18:47:00 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <7a8ae05c9c14d48871de99fc89141b62@org.tizen.email> Sorry, I wasn't clear, I meant, create a new instance of SSL, call its checkPermission method, then make that instance your system security manager. Although the check permission call will be repeated in the test, it will have run while the standard SecurityManager is in force, so the jvm won't lazy load any classes that require permission checks, during the test permission check as that will happen during the first permission check call. Cheers, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Wang Weijun Sent: 07/07/2016 06:27:43 pm To: Peter Firmstone Cc: SeanMullan ; jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module Like?this? https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 The?horizontal?line?is?printed?on?line?706?of?the?gist. --Max >?On?Jul?7,?2016,?at?12:57?PM,?Peter?Firmstone??wrote: >? >?Can?you?change?the?test?to?call?checkPermission?prior?to?setting?SSL?as?the?system?security?manager? >? >?This?will?just?ensure?that?all?necessary?classes?are?loaded?prior?to?SSL?becoming?the?security?manager.? >? >?Regards, >????? >?Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Jul 7 08:51:14 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Jul 2016 18:51:14 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: Yes, that's correct. ;) Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Alan Bateman Sent: 07/07/2016 06:37:49 pm To: Wang Weijun Cc: jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module On?07/07/2016?09:27,?Wang?Weijun?wrote: >?Like?this? > >?https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 > >?The?horizontal?line?is?printed?on?line?706?of?the?gist. > I?assume?the?suggestion?was?to?reference?SQLPermission?before?setting? the?security?manager.?As?regards?module?loading?then?we?can?re-wording? this?specific?case?but?fundamentally?then?anything?in?the? checkPermission?implementation?that?triggers?a?permission?check?is?going? to?lead?to?a?recursive?call?to?checkPermission. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Jul 7 09:00:04 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Jul 2016 19:00:04 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <06f28075c1401d14f47bfdc891bad700@org.tizen.email> Problem solved, even though it didn't occur on Java 8, the potential for it to occur still exists there, ?it's simply that Java 9 seems to have hit this execution path, it was a latent bug. Cheers, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Wang Weijun Sent: 07/07/2016 06:55:26 pm To: Peter Firmstone Cc: SeanMullan ; jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module >?On?Jul?7,?2016,?at?4:47?PM,?Peter?Firmstone??wrote: >? >?Sorry,?I?wasn't?clear,?I?meant,?create?a?new?instance?of?SSL,?call?its?checkPermission?method,?then?make?that?instance?your?system?security?manager. That?would?cure?the?test?too,?since?it?references?SQLPermission?when?checkPermission?is?called. In?another?reply?to?Alan,?I?said?a?single?"new?SQLPermission("setLog");"?is?enough. --Max >? >?Although?the?check?permission?call?will?be?repeated?in?the?test,?it?will?have?run?while?the?standard?SecurityManager?is?in?force,?so?the?jvm?won't?lazy?load?any?classes?that?require?permission?checks,?during?the?test?permission?check?as?that?will?happen?during?the?first?permission?check?call. >? >?Cheers, >? >?Peter. >? >?Sent?from?my?Samsung?device. >?? >?----?Original?message?---- >?From:?Wang?Weijun? >?Sent:?07/07/2016?06:27:43?pm >?To:?Peter?Firmstone? >?Cc:?SeanMullan?;?jigsaw-dev?;?OpenJDK? >?Subject:?Re:?Strange?test?failure?when?referencing?a?class?in?a?deprivileged?module >? >?Like?this?? >? >?https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6? >? >?The?horizontal?line?is?printed?on?line?706?of?the?gist.? >? >?--Max? >? >?>?On?Jul?7,?2016,?at?12:57?PM,?Peter?Firmstone??wrote:? >?>?? >?>?Can?you?change?the?test?to?call?checkPermission?prior?to?setting?SSL?as?the?system?security?manager?? >?>?? >?>?This?will?just?ensure?that?all?necessary?classes?are?loaded?prior?to?SSL?becoming?the?security?manager.?? >?>?? >?>?Regards,? >?>?????? >?>?Peter.? >? >? -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jul 7 21:02:41 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 7 Jul 2016 14:02:41 -0700 Subject: JDK 9 RFR mark java/security/SignedObject/Chain.java as failing intermittently Message-ID: <0513958c-5340-be60-e127-23446c283687@oracle.com> Hello, The test java/security/SignedObject/Chain.java has been seen to fail intermittently (JDK-8136842). I'd like to mark the test accordingly; please review the test below which does this. Thanks, -Joe --- a/test/java/security/SignedObject/Chain.java Thu Jul 07 10:16:47 2016 -0700 +++ b/test/java/security/SignedObject/Chain.java Thu Jul 07 13:59:49 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, 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 @@ -33,6 +33,7 @@ /* * @test * @bug 8050374 + * @key intermittent * @summary Verify a chain of signed objects */ public class Chain { From rajan.halade at oracle.com Thu Jul 7 22:43:10 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 7 Jul 2016 15:43:10 -0700 Subject: RFR: 9: 8144559: sun/security/mscapi/SignUsingNONEwithRSA.sh failed intermittently Message-ID: <5faf9c97-72a8-8225-6bb8-f6edd926d95c@oracle.com> May I request you to review this small patch. I am not able to reproduce the failure so I enhance the test itself to get rid of shell script. Since temporary key generation is now moved to java source, if it fails, exception will be raised and test will not fail with "Cannot load keys....". I also removed "intermittent" key from this test as it has never failed since this one instance back in 2015 and there are no other open bugs affecting this test. Bug: https://bugs.openjdk.java.net/browse/JDK-8144559 Webrev: http://cr.openjdk.java.net/~rhalade/8144559/webrev.00/ Thanks, Rajan From valerie.peng at oracle.com Thu Jul 7 22:48:31 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Jul 2016 15:48:31 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <69DB9F31-F1D3-484C-8575-AA2A22515E0D@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> <5693D67E-96E0-433D-B16C-6EB26FD3741F@oracle.com> <93FBB1D1-3F99-4C3A-9C17-3C356066741B@oracle.com> <57BA79DB-C1C7-4C34-A41C-BE22DB80EB2B@oracle.com> <577D3AF6.3020700@oracle.com> <69DB9F31-F1D3-484C-8575-AA2A22515E0D@oracle.com> Message-ID: <577EDC3F.3020306@oracle.com> Ok, please send me your putback comment. Otherwise, I will just use my own wording. ;) Should get it done either later today or tomorrow... Thanks, Valerie On 7/6/2016 11:31 AM, Alexandre (Shura) Iline wrote: > Valerie, could you sponsor the patch for me? > > Shura > >> On Jul 6, 2016, at 10:08 AM, Valerie Peng wrote: >> >> >> Changes look fine to me. >> Thanks, >> Valerie >> >> On 7/5/2016 2:31 PM, Mandy Chung wrote: >>>> On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline wrote: >>>> >>>> >>>>> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline wrote: >>>>>> >>>>>> This made sense, than you, Mandy. >>>>>> >>>>>> Please review new version: >>>>>> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ >>>>> You can use Layer::findModule instead of Configuration::findModule. >>>> That is correct. Changed in place. >>>> >>>>> You can also use List::equals. >>>> I am assuming you are suggesting to use List::equals in the bottom part of the test where the expected result is compared with the actual list of providers. The whole reason I redid that section to provide more information in the jtr file, both for a case of a failure and to find out what providers were actually expected for given configuration. I do not see how List:equals help me with that. Information on size mismatch is useful, and also the information on unexpected provider name. >>> What you have is fine. The information is useful to help diagnosis. The alternative I was thinking is to check List::equals and if not equals, do line-108-117. It?s a minor thing and up to you. >>> >>> Mandy From weijun.wang at oracle.com Fri Jul 8 00:41:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 8 Jul 2016 08:41:45 +0800 Subject: RFR: 8160518: Semicolon is not recognized as comment starting character (Kerberos) In-Reply-To: References: Message-ID: Change looks fine. Only one thing: why is the following @modules tag needed? java.security.jgss/sun.security.krb5.internal.crypto Thanks Max > On Jul 5, 2016, at 1:03 AM, Ivan Gerasimov wrote: > > Hello! > > We've got a complain that a semicolon character cannot be used to start a comment in the kerberos config file. > In the documentation [1] I don't see mentioning comments at all, but it is said that the config file is in style of Windows INI file, and the later does allow semicolons to be used. > This blog entry [2] also mentions the semicolon as an alternative to the hash sign '#'. > > Would you please review the trivial change? > Comments, suggestions are very welcome. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160518 > WEBREV: http://cr.openjdk.java.net/~igerasim/8160518/00/webrev/ > > [1] http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html > [2] https://blogs.oracle.com/wangwj/entry/krb5_conf > > With kind regards, > Ivan > > From weijun.wang at oracle.com Fri Jul 8 00:55:44 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 8 Jul 2016 08:55:44 +0800 Subject: RFR 8054537: sun.security.x509.SerialNumber constructor should not accept negative numbers In-Reply-To: <577E9F78.3090303@oracle.com> References: <577E9F78.3090303@oracle.com> Message-ID: Hi Svetlana According to http://tools.ietf.org/html/rfc5280#section-4.1.2.2: Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero. Certificate users SHOULD be prepared to gracefully handle such certificates. This means although a modern library/tool MUST NOT create negative serial numbers, it is required to support an existing certificate with a negative serial number. At least in jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java: 257 CertId cid = new CertId(chain[1], 258 new SerialNumber(chain[0].getSerialNumber())); It is reading an existing serial number. JDK is mainly about parsing certificates and if I remember correctly the only place it creates one is in keytool, and the tool has already made sure serial numbers be non-negative. I would close this bug as not-an-issue. Other suggestions are welcome. Thanks Max > On Jul 8, 2016, at 2:29 AM, Svetlana Nikandrova wrote: > > Hello, > > could you please review this simple fix. > Issue: > https://bugs.openjdk.java.net/browse/JDK-8054537 > Webrev: > http://cr.openjdk.java.net/~snikandrova/8054537/webrev.00/ > > Description: > Added check if SerialNumber constructor's parameter is negative. > > Thank you, > Svetlana > > From weijun.wang at oracle.com Fri Jul 8 00:57:06 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 8 Jul 2016 08:57:06 +0800 Subject: JDK 9 RFR mark java/security/SignedObject/Chain.java as failing intermittently In-Reply-To: <0513958c-5340-be60-e127-23446c283687@oracle.com> References: <0513958c-5340-be60-e127-23446c283687@oracle.com> Message-ID: <22E23652-DEF6-49D6-AE3D-E6F0909E734F@oracle.com> Looks fine to me. 8136842 has a long comment history. Thanks Max > On Jul 8, 2016, at 5:02 AM, joe darcy wrote: > > Hello, > > The test > > java/security/SignedObject/Chain.java > > has been seen to fail intermittently (JDK-8136842). I'd like to mark the test accordingly; please review the test below which does this. > > Thanks, > > -Joe > > > --- a/test/java/security/SignedObject/Chain.java Thu Jul 07 10:16:47 2016 -0700 > +++ b/test/java/security/SignedObject/Chain.java Thu Jul 07 13:59:49 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2016, 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 > @@ -33,6 +33,7 @@ > /* > * @test > * @bug 8050374 > + * @key intermittent > * @summary Verify a chain of signed objects > */ > public class Chain { > From tiantian.du at oracle.com Fri Jul 8 01:37:58 2016 From: tiantian.du at oracle.com (Tim Du) Date: Fri, 8 Jul 2016 09:37:58 +0800 Subject: [9] RFR: JDK-7052815 Change tests that remove or add providers to run in othervm mode In-Reply-To: References: <577BA3F0.6060109@oracle.com> <577D1E44.7030201@oracle.com> <577E1CCD.5060405@oracle.com> Message-ID: <577F03F6.9030509@oracle.com> Updated copyright , new webrev here: http://cr.openjdk.java.net/~tidu/7052815/webrev.02/ Please help to review them ,Thanks. Regards Tim On 2016/7/8 1:30, Rajan Halade wrote: > Hi Tim, > > Please also update the copyright year to 2016 wherever applicable. > > Thanks, > Rajan > > On 7/7/16 2:11 AM, Tim Du wrote: >> Hi Sean: >> >> Thank you for reviewing the codes. >> I updated the title for this bug and added othervm for the tests that >> add but not remove their own provider. Also corrected the typo. New >> webrev is available here: >> http://cr.openjdk.java.net/~tidu/7052815/webrev.01/ . >> Please help to review it again.Thanks. >> >> Regards >> Tim >> On 2016/7/6 23:05, Sean Mullan wrote: >>> Could you add a more descriptive title for this bug report than >>> "Finish checking of 7052537"? How about "Change tests that remove >>> providers to run in othervm mode". >>> >>> Also, have you also checked if there are tests that just add their >>> own provider but don't remove it? This could also potentially cause >>> strange behavior if another test run in parallel accidentally uses >>> that provider (perhaps if it was inserted as the first provider and >>> implemented an algorithm that the test was testing). >>> >>> Typo in RemoveProviders.java: >>> >>> 28 * @run main/othrevm RemoveProviders >>> >>> s/othrevm/othervm/ >>> >>> --Sean >>> >>> On 07/05/2016 08:11 AM, Tim Du wrote: >>>> Hi , >>>> >>>> Please help to review the path for "JDK-7052815 :Finish checking of >>>> 7052537" . >>>> >>>> A few test are using removedProvider() to removed the security >>>> provider,like JDK-7052537, If the tests not in othervm,it will affect >>>> other tests. Checking tests which are using removedProvider() for >>>> security area and update them run in othervm mode to avoid the same >>>> issue. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-7052815 >>>> webrev: http://cr.openjdk.java.net/~tidu/7052815/webrev.00/ >>>> >>>> Regards >>>> Tim >> > From valerie.peng at oracle.com Fri Jul 8 02:24:03 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Jul 2016 19:24:03 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> <576DC75C.9060503@oracle.com> <745DFC74-5E81-4E57-B4D8-C1AD018CDA62@oracle.com> <5775C383.1040600@oracle.com> Message-ID: <577F0EC3.1090105@oracle.com> Hmm, as I re-read it, I think it's too ambiguous to include '.' as a separator as it's possible to interpret the info as optional trailing info instead of version number as your earlier comment mentioned. I updated the @implNote and removed the '.' as the separator for the other info. I think this one should be clearer... Webrev is updated in place with only Provider.java, i.e. see line 233-248 of http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/src/java.base/share/classes/java/security/Provider.java.sdiff.html (Will update CCC after webrev is finalized) Thanks, Valerie On 6/30/2016 7:18 PM, Wang Weijun wrote: > One tiny thing, in Provider.java: > > 244 *{@code getVersion()}, by filtering out the trailing optional information > > There should be a space between * and {. > > I am not sure if this is worth a clarification, that when version string is "1.2.3", we would like "1.2" being the version number and "3" being other information. Do you think your @implNote also allows "1" being interpreted as version number and "2.3" as other information? A regex is greedy but the @implNote does not imply it. > > --Max > >> On Jul 1, 2016, at 9:12 AM, Valerie Peng wrote: >> >> >> Webrev updated with your suggestion: http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/ >> Thanks, >> Valerie >> >> >> On 6/24/2016 5:05 PM, Wang Weijun wrote: >>>> On Jun 25, 2016, at 7:50 AM, Valerie Peng wrote: >>>> >>>> I thought about it, but as Provider object is serializable, if the field is of new type Runtime.Version class, the (de-)serialization against older releases may break. >>> I see. >>> >>>> What exactly is the version style that you have in mind then? I think the major.minor thing is quite reasonable. >>>> 1.9d does not really look like a version to me. Do you want to special handling this just because the earlier version is a double? >>> Since you mentioned "major" and "minor" in the spec, we have to define it. Either referring to the Version class, or define one inside Provider. My preference is later, with a regex /(^\d+(\.\d+)?)/, which is a superset of Version. >>> >>> --Max >>> >>>> Valerie >>>> >>>> On 6/23/2016 6:59 PM, Wang Weijun wrote: >>>>> If you mandate the use of Verona version style, can we just use the Version class in the constructor? >>>>> >>>>>> On Jun 24, 2016, at 9:56 AM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>> Well, we have to define something for the version syntax and how it converts to the legacy double version. >>>>>> I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. >>>>>> >>>>>> Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? >>>>>> Valerie From weijun.wang at oracle.com Fri Jul 8 02:29:28 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Jul 2016 10:29:28 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <577F0EC3.1090105@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> <576DC75C.9060503@oracle.com> <745DFC74-5E81-4E57-B4D8-C1AD018CDA62@oracle.com> <5775C383.1040600@oracle.com> <577F0EC3.1090105@oracle.com> Message-ID: <7a9e1e7c-c2bd-9f4a-7ad8-bbf37d706d07@oracle.com> Yes, this is precise. I have no other comment. Thanks Max On 7/8/2016 10:24, Valerie Peng wrote: > > Hmm, as I re-read it, I think it's too ambiguous to include '.' as a > separator as it's possible to interpret the info as optional trailing > info instead of version number as your earlier comment mentioned. > I updated the @implNote and removed the '.' as the separator for the > other info. I think this one should be clearer... > Webrev is updated in place with only Provider.java, i.e. see line > 233-248 of > http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/src/java.base/share/classes/java/security/Provider.java.sdiff.html > > > (Will update CCC after webrev is finalized) > Thanks, > Valerie > > On 6/30/2016 7:18 PM, Wang Weijun wrote: >> One tiny thing, in Provider.java: >> >> 244 *{@code getVersion()}, by filtering out the trailing >> optional information >> >> There should be a space between * and {. >> >> I am not sure if this is worth a clarification, that when version >> string is "1.2.3", we would like "1.2" being the version number and >> "3" being other information. Do you think your @implNote also allows >> "1" being interpreted as version number and "2.3" as other >> information? A regex is greedy but the @implNote does not imply it. >> >> --Max >> >>> On Jul 1, 2016, at 9:12 AM, Valerie Peng >>> wrote: >>> >>> >>> Webrev updated with your suggestion: >>> http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/ >>> Thanks, >>> Valerie >>> >>> >>> On 6/24/2016 5:05 PM, Wang Weijun wrote: >>>>> On Jun 25, 2016, at 7:50 AM, Valerie Peng >>>>> wrote: >>>>> >>>>> I thought about it, but as Provider object is serializable, if the >>>>> field is of new type Runtime.Version class, the (de-)serialization >>>>> against older releases may break. >>>> I see. >>>> >>>>> What exactly is the version style that you have in mind then? I >>>>> think the major.minor thing is quite reasonable. >>>>> 1.9d does not really look like a version to me. Do you want to >>>>> special handling this just because the earlier version is a double? >>>> Since you mentioned "major" and "minor" in the spec, we have to >>>> define it. Either referring to the Version class, or define one >>>> inside Provider. My preference is later, with a regex >>>> /(^\d+(\.\d+)?)/, which is a superset of Version. >>>> >>>> --Max >>>> >>>>> Valerie >>>>> >>>>> On 6/23/2016 6:59 PM, Wang Weijun wrote: >>>>>> If you mandate the use of Verona version style, can we just use >>>>>> the Version class in the constructor? >>>>>> >>>>>>> On Jun 24, 2016, at 9:56 AM, Valerie Peng >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Well, we have to define something for the version syntax and how >>>>>>> it converts to the legacy double version. >>>>>>> I think it makes sense to follow the Verona JEP as that's the JDK >>>>>>> version syntax which seems to fit the normal convention of >>>>>>> release numbering. >>>>>>> >>>>>>> Maybe we can clarify major and minor by referring to >>>>>>> java.lang.Runtime.Version class? >>>>>>> Valerie > From weijun.wang at oracle.com Fri Jul 8 03:18:56 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Jul 2016 11:18:56 +0800 Subject: Strange test failure when referencing a class in a deprivileged module In-Reply-To: <06f28075c1401d14f47bfdc891bad700@org.tizen.email> References: <06f28075c1401d14f47bfdc891bad700@org.tizen.email> Message-ID: Mystery solved or problem solved? Have you fixed it somewhere else? Thanks Max On 7/7/2016 17:00, Peter Firmstone wrote: > Problem solved, even though it didn't occur on Java 8, the potential for > it to occur still exists there, it's simply that Java 9 seems to have > hit this execution path, it was a latent bug. > > Cheers, > > Peter. From weijun.wang at oracle.com Fri Jul 8 03:28:11 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Jul 2016 11:28:11 +0800 Subject: @run main/policy ignores system default java.policy Message-ID: I know that a "@run main/policy=p" tag will be translated to -Djava.security.policy==p and the system default java.home/conf/security/java.policy will be ignored, and sometimes it's necessary to copy some lines from there to the test's own policy file. However, with more modules being de-privileged, the system default java.policy is becoming much longer, this means it's more likely to duplicate lines there into a test policy file. Sometimes this is not obvious. Is there a plan to allow the system default java.policy also be loaded? Maybe a new option name like "addpolicy"? Thanks Max From sha.jiang at oracle.com Fri Jul 8 06:35:38 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 8 Jul 2016 14:35:38 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() Message-ID: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> Hi, Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests? In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue. If I miss something, please let me know. Issue: https://bugs.openjdk.java.net/browse/JDK-8160029 Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 Thanks! John Jiang From weijun.wang at oracle.com Fri Jul 8 08:19:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 8 Jul 2016 16:19:42 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() In-Reply-To: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> References: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> Message-ID: <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> The reason a loop is needed here is that both the TCT and UDP servers must listen on the same port number. With your fix, the TCP server finds a free port, but I doubt if it's free for the UDP server. --Max > On Jul 8, 2016, at 2:35 PM, John Jiang wrote: > > Hi, > Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests? > In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue. > If I miss something, please let me know. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8160029 > Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 > > Thanks! > > John Jiang > > From vincent.x.ryan at oracle.com Fri Jul 8 10:31:42 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 8 Jul 2016 11:31:42 +0100 Subject: RFR: 9: 8144559: sun/security/mscapi/SignUsingNONEwithRSA.sh failed intermittently In-Reply-To: <5faf9c97-72a8-8225-6bb8-f6edd926d95c@oracle.com> References: <5faf9c97-72a8-8225-6bb8-f6edd926d95c@oracle.com> Message-ID: Your change looks fine to me - and another shell script zapped. Thanks. > On 7 Jul 2016, at 23:43, Rajan Halade wrote: > > May I request you to review this small patch. I am not able to reproduce the failure so I enhance the test itself to get rid of shell script. Since temporary key generation is now moved to java source, if it fails, exception will be raised and test will not fail with "Cannot load keys....". I also removed "intermittent" key from this test as it has never failed since this one instance back in 2015 and there are no other open bugs affecting this test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144559 > Webrev: http://cr.openjdk.java.net/~rhalade/8144559/webrev.00/ > > Thanks, > Rajan > From sean.mullan at oracle.com Fri Jul 8 11:34:27 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 8 Jul 2016 07:34:27 -0400 Subject: @run main/policy ignores system default java.policy In-Reply-To: References: Message-ID: <577F8FC3.4040003@oracle.com> On 07/07/2016 11:28 PM, Weijun Wang wrote: > I know that a "@run main/policy=p" tag will be translated to > -Djava.security.policy==p and the system default > java.home/conf/security/java.policy will be ignored, and sometimes it's > necessary to copy some lines from there to the test's own policy file. > > However, with more modules being de-privileged, the system default > java.policy is becoming much longer, this means it's more likely to > duplicate lines there into a test policy file. Sometimes this is not > obvious. > > Is there a plan to allow the system default java.policy also be loaded? > Maybe a new option name like "addpolicy"? Use the new jtreg "java.security.policy=p" option. This will concatentate the specified policy with the configured system policy files. --Sean From sean.mullan at oracle.com Fri Jul 8 14:06:53 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 8 Jul 2016 10:06:53 -0400 Subject: [9] RFR: JDK-7052815 Change tests that remove or add providers to run in othervm mode In-Reply-To: <577E1CCD.5060405@oracle.com> References: <577BA3F0.6060109@oracle.com> <577D1E44.7030201@oracle.com> <577E1CCD.5060405@oracle.com> Message-ID: <577FB37D.3030904@oracle.com> Looks fine. --Sean On 07/07/2016 05:11 AM, Tim Du wrote: > Hi Sean: > > Thank you for reviewing the codes. > I updated the title for this bug and added othervm for the tests that > add but not remove their own provider. Also corrected the typo. New > webrev is available here: > http://cr.openjdk.java.net/~tidu/7052815/webrev.01/ . > Please help to review it again.Thanks. > > Regards > Tim > On 2016/7/6 23:05, Sean Mullan wrote: >> Could you add a more descriptive title for this bug report than >> "Finish checking of 7052537"? How about "Change tests that remove >> providers to run in othervm mode". >> >> Also, have you also checked if there are tests that just add their own >> provider but don't remove it? This could also potentially cause >> strange behavior if another test run in parallel accidentally uses >> that provider (perhaps if it was inserted as the first provider and >> implemented an algorithm that the test was testing). >> >> Typo in RemoveProviders.java: >> >> 28 * @run main/othrevm RemoveProviders >> >> s/othrevm/othervm/ >> >> --Sean >> >> On 07/05/2016 08:11 AM, Tim Du wrote: >>> Hi , >>> >>> Please help to review the path for "JDK-7052815 :Finish checking of >>> 7052537" . >>> >>> A few test are using removedProvider() to removed the security >>> provider,like JDK-7052537, If the tests not in othervm,it will affect >>> other tests. Checking tests which are using removedProvider() for >>> security area and update them run in othervm mode to avoid the same >>> issue. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-7052815 >>> webrev: http://cr.openjdk.java.net/~tidu/7052815/webrev.00/ >>> >>> Regards >>> Tim > From svetlana.nikandrova at oracle.com Fri Jul 8 14:34:18 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 08 Jul 2016 17:34:18 +0300 Subject: RFR 8054537: sun.security.x509.SerialNumber constructor should not accept negative numbers In-Reply-To: References: <577E9F78.3090303@oracle.com> Message-ID: <577FB9EA.2030007@oracle.com> Hi Max, thank you for pointing this out. Sure, if this change will break existing certificates handling we shouldn't add this restriction. If you don't mind I'll wait a little bit if anyone else wants to share his/her opinion on that topic and if not close it as "Not an issue" as you suggested. Thank you, Svetlana On 08.07.2016 3:55, Wang Weijun wrote: > Hi Svetlana > > According to http://tools.ietf.org/html/rfc5280#section-4.1.2.2: > > Note: Non-conforming CAs may issue certificates with serial numbers > that are negative or zero. Certificate users SHOULD be prepared to > gracefully handle such certificates. > > This means although a modern library/tool MUST NOT create negative serial numbers, it is required to support an existing certificate with a negative serial number. > > At least in jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java: > > 257 CertId cid = new CertId(chain[1], > 258 new SerialNumber(chain[0].getSerialNumber())); > > It is reading an existing serial number. > > JDK is mainly about parsing certificates and if I remember correctly the only place it creates one is in keytool, and the tool has already made sure serial numbers be non-negative. > > I would close this bug as not-an-issue. > > Other suggestions are welcome. > > Thanks > Max > > >> On Jul 8, 2016, at 2:29 AM, Svetlana Nikandrova wrote: >> >> Hello, >> >> could you please review this simple fix. >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8054537 >> Webrev: >> http://cr.openjdk.java.net/~snikandrova/8054537/webrev.00/ >> >> Description: >> Added check if SerialNumber constructor's parameter is negative. >> >> Thank you, >> Svetlana >> >> From weijun.wang at oracle.com Fri Jul 8 15:23:37 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 8 Jul 2016 23:23:37 +0800 Subject: [9] RFR: JDK-7052815 Change tests that remove or add providers to run in othervm mode In-Reply-To: <577F03F6.9030509@oracle.com> References: <577BA3F0.6060109@oracle.com> <577D1E44.7030201@oracle.com> <577E1CCD.5060405@oracle.com> <577F03F6.9030509@oracle.com> Message-ID: Hi Tim Are we seeing new failures in these tests? I am asking this question because once upon a time (4 years ago) I was involved in several RFEs [1][2][3] to do some similar the same cleanup. Some tests were put into othervm mode, but for most others, we tried our best to make them runnable in samevm/agentvm mode for performance benefits. For example, in test/java/security/Provider/RemoveProvider.java, the main method has 39 ProvidersSnapshot snapshot = ProvidersSnapshot.create(); 40 try { 41 main0(args); 42 } finally { 43 snapshot.restore(); 44 } The ProvidersSnapshot class is meant to be able to restore the provider list after the test completes, and thus not necessary to run in othervm. Also, I think there is no need to care about multiple tests running at the same time, because both samevm and agentvm modes make sure each VM is used in batch mode so no two tests can run simultaneously in the same VM. The agentvm mode does support concurrency but it's about multiple VMs running in parallel and each one will only serve one test at one time. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-7054918 [2] https://bugs.openjdk.java.net/browse/JDK-7055362 [3] https://bugs.openjdk.java.net/browse/JDK-7055363 [4] http://cr.openjdk.java.net/~tidu/7052815/webrev.00/test/java/security/Provider/RemoveProvider.java.html > On Jul 8, 2016, at 9:37 AM, Tim Du wrote: > > Updated copyright , new webrev here: http://cr.openjdk.java.net/~tidu/7052815/webrev.02/ > Please help to review them ,Thanks. > > Regards > Tim From sean.mullan at oracle.com Fri Jul 8 15:34:04 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 8 Jul 2016 11:34:04 -0400 Subject: [9] RFR: JDK-7052815 Change tests that remove or add providers to run in othervm mode In-Reply-To: References: <577BA3F0.6060109@oracle.com> <577D1E44.7030201@oracle.com> <577E1CCD.5060405@oracle.com> <577F03F6.9030509@oracle.com> Message-ID: <577FC7EC.4090206@oracle.com> On 07/08/2016 11:23 AM, Wang Weijun wrote: > Hi Tim > > Are we seeing new failures in these tests? > > I am asking this question because once upon a time (4 years ago) I > was involved in several RFEs [1][2][3] to do some similar the same > cleanup. Some tests were put into othervm mode, but for most others, > we tried our best to make them runnable in samevm/agentvm mode for > performance benefits. For example, in > test/java/security/Provider/RemoveProvider.java, the main method has > > 39 ProvidersSnapshot snapshot = ProvidersSnapshot.create(); > 40 try { 41 main0(args); 42 } finally { > 43 snapshot.restore(); 44 } > > The ProvidersSnapshot class is meant to be able to restore the > provider list after the test completes, and thus not necessary to run > in othervm. > > Also, I think there is no need to care about multiple tests running > at the same time, because both samevm and agentvm modes make sure > each VM is used in batch mode so no two tests can run simultaneously > in the same VM. The agentvm mode does support concurrency but it's > about multiple VMs running in parallel and each one will only serve > one test at one time. Good points. I think we should take a step back and decide if these changes are really necessary. The bug itself was filed in 2011, so maybe it is no longer an issue after Max' work which came after that. --Sean > > Thanks Max > > [1] https://bugs.openjdk.java.net/browse/JDK-7054918 [2] > https://bugs.openjdk.java.net/browse/JDK-7055362 [3] > https://bugs.openjdk.java.net/browse/JDK-7055363 [4] > http://cr.openjdk.java.net/~tidu/7052815/webrev.00/test/java/security/Provider/RemoveProvider.java.html > > >> On Jul 8, 2016, at 9:37 AM, Tim Du wrote: >> >> Updated copyright , new webrev here: >> http://cr.openjdk.java.net/~tidu/7052815/webrev.02/ Please help to >> review them ,Thanks. >> >> Regards Tim > From ivan.gerasimov at oracle.com Fri Jul 8 16:35:39 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 8 Jul 2016 19:35:39 +0300 Subject: RFR: 8160518: Semicolon is not recognized as comment starting character (Kerberos) In-Reply-To: References: Message-ID: Thank you Max for reviewing! On 08.07.2016 3:41, Wang Weijun wrote: > Change looks fine. > > Only one thing: why is the following @modules tag needed? > > java.security.jgss/sun.security.krb5.internal.crypto It's a copy\paste error, I'll remove it before pushing. With kind regards, Ivan > Thanks > Max > >> On Jul 5, 2016, at 1:03 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> We've got a complain that a semicolon character cannot be used to start a comment in the kerberos config file. >> In the documentation [1] I don't see mentioning comments at all, but it is said that the config file is in style of Windows INI file, and the later does allow semicolons to be used. >> This blog entry [2] also mentions the semicolon as an alternative to the hash sign '#'. >> >> Would you please review the trivial change? >> Comments, suggestions are very welcome. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160518 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8160518/00/webrev/ >> >> [1] http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html >> [2] https://blogs.oracle.com/wangwj/entry/krb5_conf >> >> With kind regards, >> Ivan >> >> > From ivan.gerasimov at oracle.com Fri Jul 8 17:04:49 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 8 Jul 2016 20:04:49 +0300 Subject: [8u-dev] Request for Review and Approval to backport: 8160518: Semicolon is not recognized as comment starting character (Kerberos) Message-ID: <980944ed-f763-9208-e6bb-a2345899f842@oracle.com> Hello! I'd like to backport this fix into jdk8u-dev. The fix is essentially the same as in jdk9, but could not be used verbatim because of the code derivation. Bug: https://bugs.openjdk.java.net/browse/JDK-8160518 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d5c6e8bad2d Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-July/014377.html Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8160518/01/webrev/ Would you please help review it and approve the backport? With kind regards, Ivan From xuelei.fan at oracle.com Sat Jul 9 02:22:13 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 9 Jul 2016 10:22:13 +0800 Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.finalize() implementation Message-ID: Hi, Please review this simple code cleanup: http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/ The javax.crypto.ExemptionMechanism.finalize() is implemented as: /** * Ensures that the key stored away by this ExemptionMechanism * object will be wiped out when there are no more references to it. */ protected void finalize() { keyStored = null; // Are there anything else we could do? } Plan to remove this finalize() method as it really does nothing more than the default finalizer but hurt the performance. Thanks, Xuelei From weijun.wang at oracle.com Sat Jul 9 02:45:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 9 Jul 2016 10:45:42 +0800 Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.finalize() implementation In-Reply-To: References: Message-ID: Change looks fine to me. Thanks Max > ? 2016?7?9??10:22?Xuelei Fan ??? > > Hi, > > Please review this simple code cleanup: > > http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/ > > The javax.crypto.ExemptionMechanism.finalize() is implemented as: > > /** > * Ensures that the key stored away by this ExemptionMechanism > * object will be wiped out when there are no more references to it. > */ > protected void finalize() { > keyStored = null; > // Are there anything else we could do? > } > > Plan to remove this finalize() method as it really does nothing more > than the default finalizer but hurt the performance. > > Thanks, > Xuelei From sha.jiang at oracle.com Sat Jul 9 07:18:14 2016 From: sha.jiang at oracle.com (John Jiang) Date: Sat, 9 Jul 2016 15:18:14 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() In-Reply-To: <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> References: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> Message-ID: Hi Max, On 2016/7/8 16:19, Wang Weijun wrote: > The reason a loop is needed here is that both the TCT and UDP servers must listen on the same port number. With your fix, the TCP server finds a free port, but I doubt if it's free for the UDP server. Yes, it's possible that the port still be occupied by another DatagramSocket. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.01 Best regards, John Jiang > > --Max > > >> On Jul 8, 2016, at 2:35 PM, John Jiang wrote: >> >> Hi, >> Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests? >> In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue. >> If I miss something, please let me know. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8160029 >> Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 >> >> Thanks! >> >> John Jiang >> >> > From weijun.wang at oracle.com Sat Jul 9 10:04:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 9 Jul 2016 18:04:30 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() In-Reply-To: References: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> Message-ID: <6C71C399-9776-470C-AFA5-81C387BA7B6A@oracle.com> I am not sure. If in the first round a free port is chosen for UDP but it's not available for TCP, how can we avoid the same port being chosen again in the 2nd round? The DatagramSocket object is closed in the catch block and the port number is reclaimed by the OS. Will the OS reuse it immediately in the 2nd round? --Max > On Jul 9, 2016, at 3:18 PM, John Jiang wrote: > > Hi Max, > > On 2016/7/8 16:19, Wang Weijun wrote: >> The reason a loop is needed here is that both the TCT and UDP servers must listen on the same port number. With your fix, the TCP server finds a free port, but I doubt if it's free for the UDP server. > Yes, it's possible that the port still be occupied by another DatagramSocket. > Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.01 > > Best regards, > John Jiang > >> >> --Max >> >> >>> On Jul 8, 2016, at 2:35 PM, John Jiang wrote: >>> >>> Hi, >>> Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests? >>> In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue. >>> If I miss something, please let me know. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160029 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 >>> >>> Thanks! >>> >>> John Jiang >>> >>> >> > From christos at zoulas.com Sat Jul 9 14:43:22 2016 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 9 Jul 2016 10:43:22 -0400 Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.finalize() implementation In-Reply-To: from Xuelei Fan (Jul 9, 10:22am) Message-ID: <20160709144322.526E717FDAB@rebar.astron.com> On Jul 9, 10:22am, xuelei.fan at oracle.com (Xuelei Fan) wrote: -- Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.fina | Hi, | | Please review this simple code cleanup: | | http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/ | | The javax.crypto.ExemptionMechanism.finalize() is implemented as: | | /** | * Ensures that the key stored away by this ExemptionMechanism | * object will be wiped out when there are no more references to it. | */ | protected void finalize() { | keyStored = null; | // Are there anything else we could do? | } | | Plan to remove this finalize() method as it really does nothing more | than the default finalizer but hurt the performance. Ok fine, but can't we do better than saying "hurt the performance", by actually providing how we measured this and what is it actually saving? This does not look like a hot code path to me... christos From xuelei.fan at oracle.com Sat Jul 9 15:47:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 9 Jul 2016 23:47:18 +0800 Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.finalize() implementation In-Reply-To: <20160709144322.526E717FDAB@rebar.astron.com> References: <20160709144322.526E717FDAB@rebar.astron.com> Message-ID: <097ade22-9b20-4ff1-f380-c890907bec96@oracle.com> On 7/9/2016 10:43 PM, christos at zoulas.com wrote: > On Jul 9, 10:22am, xuelei.fan at oracle.com (Xuelei Fan) wrote: > -- Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.fina > > | Hi, > | > | Please review this simple code cleanup: > | > | http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/ > | > | The javax.crypto.ExemptionMechanism.finalize() is implemented as: > | > | /** > | * Ensures that the key stored away by this ExemptionMechanism > | * object will be wiped out when there are no more references to it. > | */ > | protected void finalize() { > | keyStored = null; > | // Are there anything else we could do? > | } > | > | Plan to remove this finalize() method as it really does nothing more > | than the default finalizer but hurt the performance. > > Ok fine, but can't we do better than saying "hurt the performance" For the detailed description, please refer to Item 7, Effective Java. Xuelei > , by > actually providing how we measured this and what is it actually saving? > This does not look like a hot code path to me... > > christos > From sean.coffey at oracle.com Sat Jul 9 18:52:32 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Sat, 9 Jul 2016 19:52:32 +0100 Subject: [8u-dev] Request for Review and Approval to backport: 8160518: Semicolon is not recognized as comment starting character (Kerberos) In-Reply-To: <980944ed-f763-9208-e6bb-a2345899f842@oracle.com> References: <980944ed-f763-9208-e6bb-a2345899f842@oracle.com> Message-ID: <578147F0.3000802@oracle.com> Looks fine. Approved for jdk8u-dev. regards, Sean. On 08/07/2016 18:04, Ivan Gerasimov wrote: > Hello! > > I'd like to backport this fix into jdk8u-dev. > The fix is essentially the same as in jdk9, but could not be used > verbatim because of the code derivation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160518 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d5c6e8bad2d > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2016-July/014377.html > Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8160518/01/webrev/ > > Would you please help review it and approve the backport? > > With kind regards, > Ivan > From weijun.wang at oracle.com Mon Jul 11 01:14:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 11 Jul 2016 09:14:42 +0800 Subject: RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module) Message-ID: <54636D41-7AD7-417E-9EED-70EA51E7A770@oracle.com> Hi All I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at http://cr.openjdk.java.net/~weijun/8161102/webrev.00/ Whoever is able to fix JDK-8161101 later can liberate the test from problem list. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8161101 [2] http://mail.openjdk.java.net/pipermail/security-dev/2016-July/014313.html [3] https://bugs.openjdk.java.net/browse/JDK-8161102 From xuelei.fan at oracle.com Mon Jul 11 03:44:09 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jul 2016 11:44:09 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template Message-ID: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> Hi, Please review this enhancement of SSLSocket test template: http://cr.openjdk.java.net/~xuelei/8161106/webrev.00/ There are some known issues with the current SSLSocket test template (test/javax/net/ssl/templates/SSLSocketTemplate.java) in the automation testing environment: 1. the client or server can be blocked if the peer run into problems, as may result in intermittent timeout failure. 2. the server accepted connection may be not linked to the expected client. For example, some other test case may try to use and connect to a free server socket port, unfortunately this port can be actually opened by the server of SSLSocketTemplate because there is no synchronization about the free socket port between test cases. It's OK to run the test singly, but may result in weird intermittent failure in the automation testing environment. The new test template in this update considers the noises above. Thanks, Xuelei From xuelei.fan at oracle.com Mon Jul 11 03:56:38 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jul 2016 11:56:38 +0800 Subject: RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module) In-Reply-To: <54636D41-7AD7-417E-9EED-70EA51E7A770@oracle.com> References: <54636D41-7AD7-417E-9EED-70EA51E7A770@oracle.com> Message-ID: I have not followed the discussion of the problem. But this test looks simple and fine to me. The test may be helpful to replay the issue. Better to add more comments in the test about what's the problem the test case cares about. Thanks, Xuelei On 7/11/2016 9:14 AM, Wang Weijun wrote: > Hi All > > I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at > > http://cr.openjdk.java.net/~weijun/8161102/webrev.00/ > > Whoever is able to fix JDK-8161101 later can liberate the test from problem list. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8161101 > [2] http://mail.openjdk.java.net/pipermail/security-dev/2016-July/014313.html > [3] https://bugs.openjdk.java.net/browse/JDK-8161102 > From sha.jiang at oracle.com Mon Jul 11 04:28:04 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 11 Jul 2016 12:28:04 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() In-Reply-To: <6C71C399-9776-470C-AFA5-81C387BA7B6A@oracle.com> References: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> <6C71C399-9776-470C-AFA5-81C387BA7B6A@oracle.com> Message-ID: <59d0a5c6-a4d9-9ff3-5a4c-2442e72fcce0@oracle.com> Hi Max, On 2016/7/9 18:04, Wang Weijun wrote: > I am not sure. If in the first round a free port is chosen for UDP but it's not available for TCP, how can we avoid the same port being chosen again in the 2nd round? The DatagramSocket object is closed in the catch block and the port number is reclaimed by the OS. Will the OS reuse it immediately in the 2nd round? I tested the case with the below codes on Windows and Linux, for (int i = 0; i < 100; i++) { try (ServerSocket ss = new ServerSocket(0)) { int port = ss.getLocalPort(); System.out.println(port); try (DatagramSocket us = new DatagramSocket(port, InetAddress.getByName("127.0.0.1"))) { } } Thread.sleep(500); } The outputs like the followings: Windows 7: 57632 57633 57634 57635 57636 57637 57638 57639 57640 57641 57642 57643 57644 57645 57646 57647 57648 57649 57650 57651 ... Ubuntu 15.10: 45916 44807 33578 40244 46033 38966 34431 46026 40069 39013 39496 37745 36749 43594 45667 46410 36762 38565 35074 34843 ... With the results, the previous port is not reused by the subsequent round immediately. Best regards, John Jiang > --Max > >> On Jul 9, 2016, at 3:18 PM, John Jiang wrote: >> >> Hi Max, >> >> On 2016/7/8 16:19, Wang Weijun wrote: >>> The reason a loop is needed here is that both the TCT and UDP servers must listen on the same port number. With your fix, the TCP server finds a free port, but I doubt if it's free for the UDP server. >> Yes, it's possible that the port still be occupied by another DatagramSocket. >> Please review the updated webrev:http://cr.openjdk.java.net/~jjiang/8160029/webrev.01 >> >> Best regards, >> John Jiang >> >>> --Max >>> >>> >>>> On Jul 8, 2016, at 2:35 PM, John Jiang wrote: >>>> >>>> Hi, >>>> Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests? >>>> In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue. >>>> If I miss something, please let me know. >>>> >>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8160029 >>>> Webrev:http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 >>>> >>>> Thanks! >>>> >>>> John Jiang >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jul 11 05:16:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Jul 2016 13:16:37 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> Message-ID: <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> There is a nice catch of the timeout miss-match during the handling of serverIsReady in doClientSide(). Here is the updated webrev: http://cr.openjdk.java.net/~xuelei/8161106/webrev.01/ Thanks, Xuelei On 7/11/2016 11:44 AM, Xuelei Fan wrote: > Hi, > > Please review this enhancement of SSLSocket test template: > http://cr.openjdk.java.net/~xuelei/8161106/webrev.00/ > > There are some known issues with the current SSLSocket test template > (test/javax/net/ssl/templates/SSLSocketTemplate.java) in the automation > testing environment: > 1. the client or server can be blocked if the peer run into problems, as > may result in intermittent timeout failure. > 2. the server accepted connection may be not linked to the expected > client. For example, some other test case may try to use and connect to > a free server socket port, unfortunately this port can be actually > opened by the server of SSLSocketTemplate because there is no > synchronization about the free socket port between test cases. It's OK > to run the test singly, but may result in weird intermittent failure in > the automation testing environment. > > The new test template in this update considers the noises above. > > Thanks, > Xuelei > From Alan.Bateman at oracle.com Mon Jul 11 06:15:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Jul 2016 07:15:18 +0100 Subject: RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module) In-Reply-To: <54636D41-7AD7-417E-9EED-70EA51E7A770@oracle.com> References: <54636D41-7AD7-417E-9EED-70EA51E7A770@oracle.com> Message-ID: <9a2cd38c-8aa1-2cd6-8691-558c46453e0d@oracle.com> On 11/07/2016 02:14, Wang Weijun wrote: > Hi All > > I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at > > http://cr.openjdk.java.net/~weijun/8161102/webrev.00/ > > Whoever is able to fix JDK-8161101 later can liberate the test from problem list. > Checking in a failing (albeit excluded) test is a big strange. It might be less confusing to just attach the test case to the bug. -Alan From weijun.wang at oracle.com Mon Jul 11 06:16:17 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Jul 2016 14:16:17 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() In-Reply-To: <59d0a5c6-a4d9-9ff3-5a4c-2442e72fcce0@oracle.com> References: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> <6C71C399-9776-470C-AFA5-81C387BA7B6A@oracle.com> <59d0a5c6-a4d9-9ff3-5a4c-2442e72fcce0@oracle.com> Message-ID: OK, so neither Windows not Linux is reusing the port number immediately. But I don't want to rely on this observation. The Windows behavior is especially suspicious because it is a simple increment. If the current free port for UDP is n and for TCP is m and n < m, then after we get the free UDP port n in the first round, we will have to loop from n to m until we find a free TCP port. The Linux behavior looks like choosing a random port. This is good but is it documented clearly? How about other platforms? IMHO controlling the randomness inside the test looks more reliable to me. Also, the updated code still contains a loop and I don't think it's a big enhancement comparing to the existing loop. The bug description is worried about "test stabilization issues". Have we seen intermittent failures on port already used in this case? If no, then I don't think it's necessary to make a change here. Thanks Max On 7/11/2016 12:28, John Jiang wrote: > Hi Max, > > On 2016/7/9 18:04, Wang Weijun wrote: >> I am not sure. If in the first round a free port is chosen for UDP but it's not available for TCP, how can we avoid the same port being chosen again in the 2nd round? The DatagramSocket object is closed in the catch block and the port number is reclaimed by the OS. Will the OS reuse it immediately in the 2nd round? > I tested the case with the below codes on Windows and Linux, > > for (int i = 0; i < 100; i++) { > try (ServerSocket ss = new ServerSocket(0)) { > int port = ss.getLocalPort(); > System.out.println(port); > try (DatagramSocket us = new DatagramSocket(port, > InetAddress.getByName("127.0.0.1"))) { > } > } > > Thread.sleep(500); > } > > The outputs like the followings: > Windows 7: > 57632 > 57633 > 57634 > 57635 > 57636 > 57637 > 57638 > 57639 > 57640 > 57641 > 57642 > 57643 > 57644 > 57645 > 57646 > 57647 > 57648 > 57649 > 57650 > 57651 > ... > > Ubuntu 15.10: > 45916 > 44807 > 33578 > 40244 > 46033 > 38966 > 34431 > 46026 > 40069 > 39013 > 39496 > 37745 > 36749 > 43594 > 45667 > 46410 > 36762 > 38565 > 35074 > 34843 > ... > > With the results, the previous port is not reused by the subsequent > round immediately. > > Best regards, > John Jiang >> --Max >> >>> On Jul 9, 2016, at 3:18 PM, John Jiang wrote: >>> >>> Hi Max, >>> >>> On 2016/7/8 16:19, Wang Weijun wrote: >>>> The reason a loop is needed here is that both the TCT and UDP servers must listen on the same port number. With your fix, the TCP server finds a free port, but I doubt if it's free for the UDP server. >>> Yes, it's possible that the port still be occupied by another DatagramSocket. >>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.01 >>> >>> Best regards, >>> John Jiang >>> >>>> --Max >>>> >>>> >>>>> On Jul 8, 2016, at 2:35 PM, John Jiang wrote: >>>>> >>>>> Hi, >>>>> Would you like to review this patch for removing unnecessary usages on jdk.testlibrary.Utils.getFreePort() from security-libs tests? >>>>> In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be modified for this issue. >>>>> If I miss something, please let me know. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160029 >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 >>>>> >>>>> Thanks! >>>>> >>>>> John Jiang >>>>> >>>>> > From weijun.wang at oracle.com Mon Jul 11 06:31:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 11 Jul 2016 14:31:45 +0800 Subject: RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module) In-Reply-To: <9a2cd38c-8aa1-2cd6-8691-558c46453e0d@oracle.com> References: <54636D41-7AD7-417E-9EED-70EA51E7A770@oracle.com> <9a2cd38c-8aa1-2cd6-8691-558c46453e0d@oracle.com> Message-ID: Ok, that's simpler. Code and error added as a comment to JDK-8161101. I also changed the synopsis a little because error is different when run standalone. Thanks Max > On Jul 11, 2016, at 2:15 PM, Alan Bateman wrote: > > On 11/07/2016 02:14, Wang Weijun wrote: > >> Hi All >> >> I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8161102/webrev.00/ >> >> Whoever is able to fix JDK-8161101 later can liberate the test from problem list. >> > Checking in a failing (albeit excluded) test is a big strange. It might be less confusing to just attach the test case to the bug. > > -Alan From sha.jiang at oracle.com Mon Jul 11 07:38:11 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 11 Jul 2016 15:38:11 +0800 Subject: [9]RFR JDK-8160029: Security-libs tests need to avoid using jdk.testlibrary.Utils.getFreePort() In-Reply-To: References: <0a786952-2c23-ab69-3cf5-aa91aa745ce4@oracle.com> <07E09A42-3AC3-47D2-AFA7-7B2113662BD2@oracle.com> <6C71C399-9776-470C-AFA5-81C387BA7B6A@oracle.com> <59d0a5c6-a4d9-9ff3-5a4c-2442e72fcce0@oracle.com> Message-ID: Hi Max, On 2016/7/11 14:16, Weijun Wang wrote: > OK, so neither Windows not Linux is reusing the port number immediately. > > But I don't want to rely on this observation. The Windows behavior is > especially suspicious because it is a simple increment. If the current > free port for UDP is n and for TCP is m and n < m, then after we get > the free UDP port n in the first round, we will have to loop from n to > m until we find a free TCP port. The Linux behavior looks like > choosing a random port. This is good but is it documented clearly? How > about other platforms? > > IMHO controlling the randomness inside the test looks more reliable to > me. Also, the updated code still contains a loop and I don't think > it's a big enhancement comparing to the existing loop. > > The bug description is worried about "test stabilization issues". Have > we seen intermittent failures on port already used in this case? If > no, then I don't think it's necessary to make a change here. OK. I won't change this test for this issue. Thanks for your comments. Best regards, John Jiang > > Thanks > Max > > On 7/11/2016 12:28, John Jiang wrote: >> Hi Max, >> >> On 2016/7/9 18:04, Wang Weijun wrote: >>> I am not sure. If in the first round a free port is chosen for UDP >>> but it's not available for TCP, how can we avoid the same port being >>> chosen again in the 2nd round? The DatagramSocket object is closed >>> in the catch block and the port number is reclaimed by the OS. Will >>> the OS reuse it immediately in the 2nd round? >> I tested the case with the below codes on Windows and Linux, >> >> for (int i = 0; i < 100; i++) { >> try (ServerSocket ss = new ServerSocket(0)) { >> int port = ss.getLocalPort(); >> System.out.println(port); >> try (DatagramSocket us = new DatagramSocket(port, >> InetAddress.getByName("127.0.0.1"))) { >> } >> } >> >> Thread.sleep(500); >> } >> >> The outputs like the followings: >> Windows 7: >> 57632 >> 57633 >> 57634 >> 57635 >> 57636 >> 57637 >> 57638 >> 57639 >> 57640 >> 57641 >> 57642 >> 57643 >> 57644 >> 57645 >> 57646 >> 57647 >> 57648 >> 57649 >> 57650 >> 57651 >> ... >> >> Ubuntu 15.10: >> 45916 >> 44807 >> 33578 >> 40244 >> 46033 >> 38966 >> 34431 >> 46026 >> 40069 >> 39013 >> 39496 >> 37745 >> 36749 >> 43594 >> 45667 >> 46410 >> 36762 >> 38565 >> 35074 >> 34843 >> ... >> >> With the results, the previous port is not reused by the subsequent >> round immediately. >> >> Best regards, >> John Jiang >>> --Max >>> >>>> On Jul 9, 2016, at 3:18 PM, John Jiang wrote: >>>> >>>> Hi Max, >>>> >>>> On 2016/7/8 16:19, Wang Weijun wrote: >>>>> The reason a loop is needed here is that both the TCT and UDP >>>>> servers must listen on the same port number. With your fix, the >>>>> TCP server finds a free port, but I doubt if it's free for the UDP >>>>> server. >>>> Yes, it's possible that the port still be occupied by another >>>> DatagramSocket. >>>> Please review the updated webrev: >>>> http://cr.openjdk.java.net/~jjiang/8160029/webrev.01 >>>> >>>> Best regards, >>>> John Jiang >>>> >>>>> --Max >>>>> >>>>> >>>>>> On Jul 8, 2016, at 2:35 PM, John Jiang wrote: >>>>>> >>>>>> Hi, >>>>>> Would you like to review this patch for removing unnecessary >>>>>> usages on jdk.testlibrary.Utils.getFreePort() from security-libs >>>>>> tests? >>>>>> In OpenJDK, I find only sun/security/krb5/auto/KDC.java should be >>>>>> modified for this issue. >>>>>> If I miss something, please let me know. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160029 >>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00 >>>>>> >>>>>> Thanks! >>>>>> >>>>>> John Jiang >>>>>> >>>>>> >> > From weijun.wang at oracle.com Mon Jul 11 08:15:48 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Jul 2016 16:15:48 +0800 Subject: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth Message-ID: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> Hi All Please review the code change at dev: http://cr.openjdk.java.net/~weijun/8159528/dev/webrev.00 dev/jdk: http://cr.openjdk.java.net/~weijun/8159528/jdk/webrev.00 Some notes on the jdk changes: 1. java.policy: I just append the new grants to the end of the file (before the common block). There seems to be no special order. Also, new RFEs will be filed to refine the permissions granted. 2. KerberosSecrets.java and PrincipalName.java cannot get Unsafe as before. I copied this hack from Nashorn. 3. The SSL.java test fails because of another bug [1]. Workaround added. 4. Other tests use the new java.security.policy @run option because the system default java.policy must also be included. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8161101 From mandy.chung at oracle.com Mon Jul 11 08:50:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 Jul 2016 16:50:48 +0800 Subject: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth In-Reply-To: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> References: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> Message-ID: <7B5AE7E4-9DB0-40B0-B68C-9D429F8D052F@oracle.com> > On Jul 11, 2016, at 4:15 PM, Weijun Wang wrote: > > Hi All > > Please review the code change at > > dev: http://cr.openjdk.java.net/~weijun/8159528/dev/webrev.00 Good to keep the PLATFORM_MODULE list in alphabetical order. So java.security.jgss should be moved up. > dev/jdk: http://cr.openjdk.java.net/~weijun/8159528/jdk/webrev.00 > Two comments related to the use of unsafe here. You use reflection to get access to Unsafe instance to bypass the caller?s class loader check. I think Unsafe::getUnsafe should be relaxed for null or ClassLoader::getPlatformLoader to access. On the other hand, we should also examine the use of Unsafe and see if they can be converted to VarHandle or other means. Maybe you can file a JBS issue for Unsafe::getUnsafe to allow the platform class loader to access it and another one to examine the use of unsafe in java.security.jgss module. I file a JBS issue to track this (JDK-8161121) to audit the callers of VM::isSystemDomainLoader and make appropriate adjustment. Mandy From weijun.wang at oracle.com Mon Jul 11 13:38:47 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Jul 2016 21:38:47 +0800 Subject: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth In-Reply-To: <7B5AE7E4-9DB0-40B0-B68C-9D429F8D052F@oracle.com> References: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> <7B5AE7E4-9DB0-40B0-B68C-9D429F8D052F@oracle.com> Message-ID: <5d2ecef9-23b3-944e-ea2f-3ba267238fa0@oracle.com> On 7/11/2016 16:50, Mandy Chung wrote: > >> On Jul 11, 2016, at 4:15 PM, Weijun Wang wrote: >> >> Hi All >> >> Please review the code change at >> >> dev: http://cr.openjdk.java.net/~weijun/8159528/dev/webrev.00 > > Good to keep the PLATFORM_MODULE list in alphabetical order. So java.security.jgss should be moved up. The existing list in not in alphabetical order: jdk.jsobject \ jdk.xml.dom \ jdk.localedata \ jdk.naming.dns \ jdk.scripting.nashorn \ jdk.zipfs \ Shall I reorder them? > >> dev/jdk: http://cr.openjdk.java.net/~weijun/8159528/jdk/webrev.00 >> > > Two comments related to the use of unsafe here. > > You use reflection to get access to Unsafe instance to bypass the caller?s class loader check. I think Unsafe::getUnsafe should be relaxed for null or ClassLoader::getPlatformLoader to access. On the other hand, we should also examine the use of Unsafe and see if they can be converted to VarHandle or other means. Maybe you can file a JBS issue for Unsafe::getUnsafe to allow the platform class loader to access it and another one to examine the use of unsafe in java.security.jgss module. JDK-8161129 filed. I didn't file a specific bug for java.security.jgss. I will be alerted once JDK-8161129 is resolved and I can file a bug then. > > I file a JBS issue to track this (JDK-8161121) to audit the callers of VM::isSystemDomainLoader and make appropriate adjustment. Thanks Max > > Mandy > From mandy.chung at oracle.com Mon Jul 11 15:14:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 11 Jul 2016 23:14:03 +0800 Subject: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth In-Reply-To: <5d2ecef9-23b3-944e-ea2f-3ba267238fa0@oracle.com> References: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> <7B5AE7E4-9DB0-40B0-B68C-9D429F8D052F@oracle.com> <5d2ecef9-23b3-944e-ea2f-3ba267238fa0@oracle.com> Message-ID: > On Jul 11, 2016, at 9:38 PM, Weijun Wang wrote: > > > > On 7/11/2016 16:50, Mandy Chung wrote: >> >>> On Jul 11, 2016, at 4:15 PM, Weijun Wang wrote: >>> >>> Hi All >>> >>> Please review the code change at >>> >>> dev: http://cr.openjdk.java.net/~weijun/8159528/dev/webrev.00 >> >> Good to keep the PLATFORM_MODULE list in alphabetical order. So java.security.jgss should be moved up. > > The existing list in not in alphabetical order: > > jdk.jsobject \ > jdk.xml.dom \ > jdk.localedata \ > jdk.naming.dns \ > jdk.scripting.nashorn \ > jdk.zipfs \ > > Shall I reorder them? yes please if you don?t mind. Mandy From sean.mullan at oracle.com Tue Jul 12 14:31:23 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Jul 2016 10:31:23 -0400 Subject: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth In-Reply-To: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> References: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> Message-ID: <5784FF3B.9060804@oracle.com> Did you try to grant less than AllPermission to these modules? In PrincipalName.java, you can use diamond on line 206: return AccessController.doPrivileged(new PrivilegedAction<>() { Looks ok otherwise. --Sean On 07/11/2016 04:15 AM, Weijun Wang wrote: > Hi All > > Please review the code change at > > dev: http://cr.openjdk.java.net/~weijun/8159528/dev/webrev.00 > dev/jdk: http://cr.openjdk.java.net/~weijun/8159528/jdk/webrev.00 > > Some notes on the jdk changes: > > 1. java.policy: I just append the new grants to the end of the file > (before the common block). There seems to be no special order. Also, new > RFEs will be filed to refine the permissions granted. > > 2. KerberosSecrets.java and PrincipalName.java cannot get Unsafe as > before. I copied this hack from Nashorn. > > 3. The SSL.java test fails because of another bug [1]. Workaround added. > > 4. Other tests use the new java.security.policy @run option because the > system default java.policy must also be included. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8161101 From artem.smotrakov at oracle.com Tue Jul 12 17:03:02 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 12 Jul 2016 10:03:02 -0700 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> Message-ID: <578522C6.8040402@oracle.com> Hi Xuelei, I am not an official reviewer, but I have a couple of comments. 1. line 149: would it be better to check this condition in a loop? 2. Using try-with-resources blocks might simplify doServerSide() a little bit (no need to call close() on sockets, and a couple of "try" blocks might be probably removed) 3. Minor: it might be better to define timeout values as constants with meaningful names. 4. Minor: lines 268-273 seem to work, but I am wondering if it would be better to use File.separator instead of "/" (someone may run the test on Windows, but without Cygwin). 5. SSLSocketSample() constructor, startServer() and startClient() methods: Recently we've had a couple of test issue where no exception was printed on client/server sides. It happened because exceptions were caught and stored, but then tests waited infinitely for another thread to finish. Then, jtreg just killed the tests. As a result, no exception was printed out. It might be better to simplify this code to print out an exception right after it's caught, and then throw a runtime exception if serverException or clientException are not null. Probably there is a side effect that logs may be a little messy sometimes because of lack of synchronization, but maybe something like synchronized(System.out) may help. 6. Minor: it might be better to make class constants uppercase http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367 Artem On 07/10/2016 10:16 PM, Xuelei Fan wrote: > There is a nice catch of the timeout miss-match during the handling of > serverIsReady in doClientSide(). Here is the updated webrev: > > http://cr.openjdk.java.net/~xuelei/8161106/webrev.01/ > > Thanks, > Xuelei > > On 7/11/2016 11:44 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this enhancement of SSLSocket test template: >> http://cr.openjdk.java.net/~xuelei/8161106/webrev.00/ >> >> There are some known issues with the current SSLSocket test template >> (test/javax/net/ssl/templates/SSLSocketTemplate.java) in the automation >> testing environment: >> 1. the client or server can be blocked if the peer run into problems, as >> may result in intermittent timeout failure. >> 2. the server accepted connection may be not linked to the expected >> client. For example, some other test case may try to use and connect to >> a free server socket port, unfortunately this port can be actually >> opened by the server of SSLSocketTemplate because there is no >> synchronization about the free socket port between test cases. It's OK >> to run the test singly, but may result in weird intermittent failure in >> the automation testing environment. >> >> The new test template in this update considers the noises above. >> >> Thanks, >> Xuelei >> From omajid at redhat.com Tue Jul 12 19:58:28 2016 From: omajid at redhat.com (Omair Majid) Date: Tue, 12 Jul 2016 15:58:28 -0400 Subject: Handling SNI alerts in OpenJDK In-Reply-To: <565C157B.8060207@oracle.com> References: <20151116182428.GC3979@redhat.com> <565C157B.8060207@oracle.com> Message-ID: <20160712195828.GE5150@redhat.com> * Xuelei Fan [2015-11-30 04:23]: > Can I get the full exception stacks? The original issue was experienced by others and they asked me to reach out to the OpenJDK developers. I went back to them and they no longer have the stack traces or a reproducer. Sorry about wasting your time. Regards, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From rajan.halade at oracle.com Tue Jul 12 21:31:11 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 12 Jul 2016 14:31:11 -0700 Subject: RFR: 9: 8161233: ProblemList sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java on macOS Message-ID: <96897498-120f-1fb7-3bd1-23633181b875@oracle.com> Please review following patch. Test is failing consistently on macOS due toJDK-8161232 . Until this issue is fixed, test should be in ProblemList. diff -r fa9e1202a3cd test/ProblemList.txt --- a/test/ProblemList.txt Tue Jul 12 10:58:58 2016 -0300 +++ b/test/ProblemList.txt Tue Jul 12 14:29:01 2016 -0700 @@ -284,6 +284,7 @@ sun/security/krb5/auto/HttpNegotiateServer.java 8038079 generic-all sun/security/tools/keytool/autotest.sh 8130302 generic-all +sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all ############################################################################ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Jul 12 21:36:14 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 12 Jul 2016 14:36:14 -0700 Subject: RFR: 9: 8161233: ProblemList sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java on macOS In-Reply-To: <96897498-120f-1fb7-3bd1-23633181b875@oracle.com> References: <96897498-120f-1fb7-3bd1-23633181b875@oracle.com> Message-ID: <578562CE.1070806@oracle.com> looks good. Tony On 07/12/2016 02:31 PM, Rajan Halade wrote: > Please review following patch. Test is failing consistently on macOS due > toJDK-8161232 . Until > this issue is fixed, test should be in ProblemList. > > diff -r fa9e1202a3cd test/ProblemList.txt > --- a/test/ProblemList.txt Tue Jul 12 10:58:58 2016 -0300 > +++ b/test/ProblemList.txt Tue Jul 12 14:29:01 2016 -0700 > @@ -284,6 +284,7 @@ > sun/security/krb5/auto/HttpNegotiateServer.java 8038079 generic-all > > sun/security/tools/keytool/autotest.sh 8130302 generic-all > +sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all > > ############################################################################ > > Thanks, > Rajan From weijun.wang at oracle.com Wed Jul 13 02:01:15 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 Jul 2016 10:01:15 +0800 Subject: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth In-Reply-To: <5784FF3B.9060804@oracle.com> References: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> <5784FF3B.9060804@oracle.com> Message-ID: <92abed6c-d7b6-6a98-55dc-407ae3fa340c@oracle.com> On 7/12/2016 22:31, Sean Mullan wrote: > Did you try to grant less than AllPermission to these modules? Ah yes, below is the exact permissions needed to run the sun/security/krb5/auto/BasicProc.java test. Some of them will need to be applied to the application also. The SocketPermission, FilePermission, DelegationPermission and ServicePermission will need to change the name to "*". The permissions are surely not enough. For example, if server-side rcache is enabled, FilePermission on "write" will be needed. If SPNEGO is used, at least the spnego debug flag should be read. There are other kind of LoginModules that would need other permissions. grant codeBase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.action"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.ssl"; permission java.util.PropertyPermission "sun.security.krb5.debug", "read"; permission java.util.PropertyPermission "java.security.krb5.kdc", "read"; permission java.util.PropertyPermission "java.security.krb5.realm", "read"; permission java.util.PropertyPermission "java.security.krb5.conf", "read"; permission java.util.PropertyPermission "sun.security.jgss.mechanism", "read"; permission java.util.PropertyPermission "sun.security.krb5.msinterop.kstring", "read"; permission java.util.PropertyPermission "sun.security.jgss.debug", "read"; permission java.util.PropertyPermission "javax.security.auth.useSubjectCredsOnly", "read"; permission java.util.PropertyPermission "sun.security.krb5.rcache", "read"; permission java.util.PropertyPermission "sun.security.krb5.acceptor.subkey", "read"; // Config#loadConfigFile permission java.util.PropertyPermission "user.dir", "read"; // Connecting to KDC (could be UDP) permission java.net.SocketPermission "127.0.0.1:14234", "accept,connect,resolve"; permission java.io.FilePermission "krb5.conf", "read"; permission java.security.SecurityPermission "getProperty.krb5.kdc.bad.policy"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission java.util.PropertyPermission "sun.security.krb5.autodeducerealm", "read"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "clearProviderProperties.SunJGSS"; permission java.security.SecurityPermission "removeProviderProperty.SunJGSS"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KeyTab * \"*\"", "read"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KerberosTicket * \"*\"", "read"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KerberosKey * \"*\"", "read"; permission javax.security.auth.kerberos.ServicePermission "server/localhost at REALM", "accept"; permission javax.security.auth.kerberos.ServicePermission "backend/localhost at REALM", "accept"; permission javax.security.auth.kerberos.ServicePermission "krbtgt/REALM at REALM", "initiate"; permission javax.security.auth.kerberos.ServicePermission "server/localhost at REALM", "initiate"; permission javax.security.auth.kerberos.DelegationPermission "\"server/localhost at REALM\" \"krbtgt/REALM at REALM\""; permission java.io.FilePermission "C:\\cygwin\\home\\ww155710\\tmp\\RR1\\W\\scratch\\ktab", "read"; permission javax.security.auth.kerberos.ServicePermission "backend/localhost at REALM", "accept"; permission javax.security.auth.kerberos.ServicePermission "backend/localhost at REALM", "initiate"; }; grant codeBase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jgss"; permission com.sun.security.jgss.InquireSecContextPermission "*"; }; grant codeBase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission java.util.PropertyPermission "sun.security.krb5.principal", "read"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jgss.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5.internal.ktab"; // resource bundle permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getClassLoader"; }; Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jul 13 02:41:49 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 Jul 2016 10:41:49 +0800 Subject: ServiceLoader loading services from platform modules (was Re: RFR 8159528: Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth) In-Reply-To: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> References: <5b34d332-ffd1-50b1-4db9-649301f0701f@oracle.com> Message-ID: I wasn't running all tests before and today I noticed a new failure of java/net/httpclient/security/Security.java. I think it's because Krb5KeyExchangeService in java.security.jgss provides ClientKeyExchangeService, and when ServiceLoader is iterating through all its providers and touching Krb5KeyExchangeService it needs to access its parent class ClientKeyExchangeService. Change "@run main/policy=0.policy" to"@run main/java.security.policy=0.policy" will succeed again, but I wonder why we must do this? The test has nothing to do with JGSS. Should ServiceLoader ignore any such exception? Thanks Max ---------------------------- The exception thrown by the test: java.lang.ExceptionInInitializerError at sun.security.ssl.ClientKeyExchangeService.find(java.base at 9-internal/ClientKeyExchangeService.java:72) at sun.security.ssl.JsseJce.(java.base at 9-internal/JsseJce.java:63) at sun.security.ssl.CipherSuite$BulkCipher.(java.base at 9-internal/CipherSuite.java:513) at sun.security.ssl.CipherSuite.(java.base at 9-internal/CipherSuite.java:1072) at sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(java.base at 9-internal/SSLContextImpl.java:352) at sun.security.ssl.SSLContextImpl.access$100(java.base at 9-internal/SSLContextImpl.java:41) at sun.security.ssl.SSLContextImpl$AbstractTLSContext.(java.base at 9-internal/SSLContextImpl.java:484) at java.lang.Class.forName0(java.base at 9-internal/Native Method) at java.lang.Class.forName(java.base at 9-internal/Class.java:294) at java.security.Provider$Service.getImplClass(java.base at 9-internal/Provider.java:1744) at java.security.Provider$Service.newInstance(java.base at 9-internal/Provider.java:1720) at sun.security.jca.GetInstance.getInstance(java.base at 9-internal/GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(java.base at 9-internal/GetInstance.java:164) at javax.net.ssl.SSLContext.getInstance(java.base at 9-internal/SSLContext.java:166) at javax.net.ssl.SSLContext.getDefault(java.base at 9-internal/SSLContext.java:98) at java.net.http.HttpClientImpl.(java.httpclient at 9-internal/HttpClientImpl.java:89) at java.net.http.HttpClientImpl.create(java.httpclient at 9-internal/HttpClientImpl.java:81) at java.net.http.HttpClientBuilderImpl.build(java.httpclient at 9-internal/HttpClientBuilderImpl.java:131) at Security.main(Security.java:378) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:533) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.ssl") at java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:468) at java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894) at java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:541) at java.lang.SecurityManager.checkPackageAccess(java.base at 9-internal/SecurityManager.java:1500) at java.lang.ClassLoader$1.run(java.base at 9-internal/ClassLoader.java:632) at java.lang.ClassLoader$1.run(java.base at 9-internal/ClassLoader.java:630) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at java.lang.ClassLoader.checkPackageAccess(java.base at 9-internal/ClassLoader.java:630) at java.lang.ClassLoader.defineClass2(java.base at 9-internal/Native Method) at java.lang.ClassLoader.defineClass(java.base at 9-internal/ClassLoader.java:1032) at java.security.SecureClassLoader.defineClass(java.base at 9-internal/SecureClassLoader.java:182) at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base at 9-internal/BuiltinClassLoader.java:512) at jdk.internal.loader.BuiltinClassLoader.lambda$findClassInModuleOrNull$2(java.base at 9-internal/BuiltinClassLoader.java:449) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(java.base at 9-internal/BuiltinClassLoader.java:450) at jdk.internal.loader.BuiltinClassLoader.findClass(java.base at 9-internal/BuiltinClassLoader.java:354) at java.lang.ClassLoader.loadLocalClass(java.base at 9-internal/ClassLoader.java:531) at java.lang.Class.forName(java.base at 9-internal/Class.java:450) at java.util.ServiceLoader.lambda$loadClassInModule$0(java.base at 9-internal/ServiceLoader.java:502) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at java.util.ServiceLoader.loadClassInModule(java.base at 9-internal/ServiceLoader.java:503) at java.util.ServiceLoader.access$500(java.base at 9-internal/ServiceLoader.java:218) at java.util.ServiceLoader$ModuleServicesIterator.nextService(java.base at 9-internal/ServiceLoader.java:724) at java.util.ServiceLoader$RestrictedIterator$2.run(java.base at 9-internal/ServiceLoader.java:541) at java.security.AccessController.doPrivileged(java.base at 9-internal/Native Method) at java.util.ServiceLoader$RestrictedIterator.next(java.base at 9-internal/ServiceLoader.java:543) at java.util.ServiceLoader$2.next(java.base at 9-internal/ServiceLoader.java:921) at sun.security.ssl.ClientKeyExchangeService$Loader.(java.base at 9-internal/ClientKeyExchangeService.java:62) ... 25 more From sha.jiang at oracle.com Wed Jul 13 03:17:23 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 13 Jul 2016 11:17:23 +0800 Subject: [9] RFR 8154821: Update issue number for sun/security/pkcs11/ec/TestKeyFactory.java in ProblemList Message-ID: Hi, Please review this small update for ProblemList. sun/security/pkcs11/ec/TestKeyFactory.java should be associated to JDK-8026976 rather than JDK-7157786. diff -r bbf0170e96b2 test/ProblemList.txt --- a/test/ProblemList.txt Wed Jul 13 10:26:11 2016 +0800 +++ b/test/ProblemList.txt Wed Jul 13 04:05:35 2016 +0100 @@ -213,7 +213,7 @@ # jdk_security -sun/security/pkcs11/ec/TestKeyFactory.java 7157786 generic-all +sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac Best regards, John Jiang From xuelei.fan at oracle.com Wed Jul 13 03:22:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Jul 2016 11:22:18 +0800 Subject: [9] RFR 8154821: Update issue number for sun/security/pkcs11/ec/TestKeyFactory.java in ProblemList In-Reply-To: References: Message-ID: On 7/13/2016 11:17 AM, John Jiang wrote: > Hi, > Please review this small update for ProblemList. > sun/security/pkcs11/ec/TestKeyFactory.java should be associated to > JDK-8026976 rather than JDK-7157786. > Can you give more information about this point? Thanks, Xuelei > diff -r bbf0170e96b2 test/ProblemList.txt > --- a/test/ProblemList.txt Wed Jul 13 10:26:11 2016 +0800 > +++ b/test/ProblemList.txt Wed Jul 13 04:05:35 2016 +0100 > @@ -213,7 +213,7 @@ > > # jdk_security > > -sun/security/pkcs11/ec/TestKeyFactory.java 7157786 generic-all > +sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all > > sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no > PortUnreachableException on Mac > > > Best regards, > John Jiang > From sha.jiang at oracle.com Wed Jul 13 03:37:38 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 13 Jul 2016 11:37:38 +0800 Subject: [9] RFR 8154821: Update issue number for sun/security/pkcs11/ec/TestKeyFactory.java in ProblemList In-Reply-To: References: Message-ID: <6a7e282a-ad1e-1b99-10a5-618ba7f28fc1@oracle.com> Hi Xuelei, Thanks for your review. On 2016/7/13 11:22, Xuelei Fan wrote: > On 7/13/2016 11:17 AM, John Jiang wrote: >> Hi, >> Please review this small update for ProblemList. >> sun/security/pkcs11/ec/TestKeyFactory.java should be associated to >> JDK-8026976 rather than JDK-7157786. >> > Can you give more information about this point? Currently, in ProblemList, sun/security/pkcs11/ec/TestKeyFactory.java is tracked by JDK-7157786. But this issue had been resolved. And now, the root cause of this test failure is tracked by another open issue JDK-8026976. For more details, please take a look at https://bugs.openjdk.java.net/browse/JDK-8154821 Best regards, John Jiang > > Thanks, > Xuelei > >> diff -r bbf0170e96b2 test/ProblemList.txt >> --- a/test/ProblemList.txt Wed Jul 13 10:26:11 2016 +0800 >> +++ b/test/ProblemList.txt Wed Jul 13 04:05:35 2016 +0100 >> @@ -213,7 +213,7 @@ >> >> # jdk_security >> >> -sun/security/pkcs11/ec/TestKeyFactory.java 7157786 generic-all >> +sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all >> >> sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no >> PortUnreachableException on Mac >> >> >> Best regards, >> John Jiang >> > From xuelei.fan at oracle.com Wed Jul 13 03:52:44 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Jul 2016 11:52:44 +0800 Subject: [9] RFR 8154821: Update issue number for sun/security/pkcs11/ec/TestKeyFactory.java in ProblemList In-Reply-To: <6a7e282a-ad1e-1b99-10a5-618ba7f28fc1@oracle.com> References: <6a7e282a-ad1e-1b99-10a5-618ba7f28fc1@oracle.com> Message-ID: Ok, go ahead. Thanks! Xuelei On 7/13/2016 11:37 AM, John Jiang wrote: > Hi Xuelei, > Thanks for your review. > > On 2016/7/13 11:22, Xuelei Fan wrote: >> On 7/13/2016 11:17 AM, John Jiang wrote: >>> Hi, >>> Please review this small update for ProblemList. >>> sun/security/pkcs11/ec/TestKeyFactory.java should be associated to >>> JDK-8026976 rather than JDK-7157786. >>> >> Can you give more information about this point? > Currently, in ProblemList, sun/security/pkcs11/ec/TestKeyFactory.java is > tracked by JDK-7157786. But this issue had been resolved. > And now, the root cause of this test failure is tracked by another open > issue JDK-8026976. > For more details, please take a look at > https://bugs.openjdk.java.net/browse/JDK-8154821 > > Best regards, > John Jiang >> >> Thanks, >> Xuelei >> >>> diff -r bbf0170e96b2 test/ProblemList.txt >>> --- a/test/ProblemList.txt Wed Jul 13 10:26:11 2016 +0800 >>> +++ b/test/ProblemList.txt Wed Jul 13 04:05:35 2016 +0100 >>> @@ -213,7 +213,7 @@ >>> >>> # jdk_security >>> >>> -sun/security/pkcs11/ec/TestKeyFactory.java 7157786 generic-all >>> +sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all >>> >>> sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no >>> PortUnreachableException on Mac >>> >>> >>> Best regards, >>> John Jiang >>> >> > From xuelei.fan at oracle.com Wed Jul 13 05:36:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Jul 2016 13:36:37 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <578522C6.8040402@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> Message-ID: Thanks for the feedback, Artem. Here is the updated webrev per your suggestions: http://cr.openjdk.java.net/~xuelei/8161106/webrev.02/ On 7/13/2016 1:03 AM, Artem Smotrakov wrote: > Hi Xuelei, > > I am not an official reviewer, but I have a couple of comments. > > 1. line 149: would it be better to check this condition in a loop? > clientCondition.await() will wait for 30 seconds. Need no loop any more. If adding a loop, it may become a potential deadloop and cause timeout issue. > 2. Using try-with-resources blocks might simplify doServerSide() a > little bit (no need to call close() on sockets, and a couple of "try" > blocks might be probably removed) > I considered to use try-with-resources. But as the lock is introduced. and we want to support socket accept timeout, it more convenient to me to use the traditional try-finally clauses. > 3. Minor: it might be better to define timeout values as constants with > meaningful names. > Maybe. Normally, if a number is used only once, I may not define a field for it. > 4. Minor: lines 268-273 seem to work, but I am wondering if it would be > better to use File.separator instead of "/" (someone may run the test on > Windows, but without Cygwin). > I think JDK file I/O would take care of this file separator interoperability. It's good to use File.separator, but as the path may contains a few separator in test case following this template, for example: pathToStores = "../../../../../javax/net/ssl"; Using File.separator would not make nice line. > 5. SSLSocketSample() constructor, startServer() and startClient() methods: > > Recently we've had a couple of test issue where no exception was printed > on client/server sides. It happened because exceptions were caught and > stored, but then tests waited infinitely for another thread to finish. > Then, jtreg just killed the tests. As a result, no exception was printed > out. It might be better to simplify this code to print out an exception > right after it's caught, and then throw a runtime exception if > serverException or clientException are not null. Probably there is a > side effect that logs may be a little messy sometimes because of lack of > synchronization, but maybe something like synchronized(System.out) may > help. > This update should be able to avoid the infinitely waiting. Updated to print the exception message right after it is caught. > 6. Minor: it might be better to make class constants uppercase > > http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367 > Good to use uppercase. I plan to modify this template to a overridable one so that test case can extend this template. By then, those fields will not be declared as constants any more. Let's use the current names for a while. Thanks, Xuelei > > Artem > > On 07/10/2016 10:16 PM, Xuelei Fan wrote: >> There is a nice catch of the timeout miss-match during the handling of >> serverIsReady in doClientSide(). Here is the updated webrev: >> >> http://cr.openjdk.java.net/~xuelei/8161106/webrev.01/ >> >> Thanks, >> Xuelei >> >> On 7/11/2016 11:44 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review this enhancement of SSLSocket test template: >>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.00/ >>> >>> There are some known issues with the current SSLSocket test template >>> (test/javax/net/ssl/templates/SSLSocketTemplate.java) in the automation >>> testing environment: >>> 1. the client or server can be blocked if the peer run into problems, as >>> may result in intermittent timeout failure. >>> 2. the server accepted connection may be not linked to the expected >>> client. For example, some other test case may try to use and connect to >>> a free server socket port, unfortunately this port can be actually >>> opened by the server of SSLSocketTemplate because there is no >>> synchronization about the free socket port between test cases. It's OK >>> to run the test singly, but may result in weird intermittent failure in >>> the automation testing environment. >>> >>> The new test template in this update considers the noises above. >>> >>> Thanks, >>> Xuelei >>> > From weijun.wang at oracle.com Wed Jul 13 07:23:35 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 Jul 2016 15:23:35 +0800 Subject: @run main/policy ignores system default java.policy In-Reply-To: <577F8FC3.4040003@oracle.com> References: <577F8FC3.4040003@oracle.com> Message-ID: On 7/8/2016 19:34, Sean Mullan wrote: > > Use the new jtreg "java.security.policy=p" option. This will > concatentate the specified policy with the configured system policy files. I've used this new option. However, it also picks up ~/.java.policy, which I believe will bring in some noise. Maybe jtreg can be enhanced to ignore ~/.java.policy? Thanks Max From mandy.chung at oracle.com Wed Jul 13 07:59:52 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Jul 2016 15:59:52 +0800 Subject: @run main/policy ignores system default java.policy In-Reply-To: References: <577F8FC3.4040003@oracle.com> Message-ID: <67525DA0-1423-439F-9B1B-6D950408A58B@oracle.com> > On Jul 13, 2016, at 3:23 PM, Weijun Wang wrote: > > > > On 7/8/2016 19:34, Sean Mullan wrote: >> >> Use the new jtreg "java.security.policy=p" option. This will >> concatentate the specified policy with the configured system policy files. > > I've used this new option. > > However, it also picks up ~/.java.policy, which I believe will bring in some noise. Maybe jtreg can be enhanced to ignore ~/.java.policy? IMO it?s a configuration issue. We should make sure ${java.home}/.java.policy is not present when running the regression tests. In addition, to ignore ${java.home}/.java.policy, it?s a change in the policy file I believe (not in jtreg). Mandy From sean.mullan at oracle.com Wed Jul 13 11:54:36 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 Jul 2016 07:54:36 -0400 Subject: @run main/policy ignores system default java.policy In-Reply-To: <67525DA0-1423-439F-9B1B-6D950408A58B@oracle.com> References: <577F8FC3.4040003@oracle.com> <67525DA0-1423-439F-9B1B-6D950408A58B@oracle.com> Message-ID: <57862BFC.2060408@oracle.com> Also, I am working on a change where the java.security.policy== option will include the permissions granted to de-privileged modules [1]. So once that is in, you will be able to use the '==' option instead. --Sean [1] https://bugs.openjdk.java.net/browse/JDK-8159752 On 07/13/2016 03:59 AM, Mandy Chung wrote: > >> On Jul 13, 2016, at 3:23 PM, Weijun Wang wrote: >> >> >> >> On 7/8/2016 19:34, Sean Mullan wrote: >>> >>> Use the new jtreg "java.security.policy=p" option. This will >>> concatentate the specified policy with the configured system policy files. >> >> I've used this new option. >> >> However, it also picks up ~/.java.policy, which I believe will bring in some noise. Maybe jtreg can be enhanced to ignore ~/.java.policy? > > IMO it?s a configuration issue. We should make sure ${java.home}/.java.policy is not present when running the regression tests. > > In addition, to ignore ${java.home}/.java.policy, it?s a change in the policy file I believe (not in jtreg). > > Mandy > From artem.smotrakov at oracle.com Wed Jul 13 17:44:44 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 13 Jul 2016 10:44:44 -0700 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> Message-ID: <57867E0C.7000705@oracle.com> Hi Xuelei, The webrev looks good to me. Please see inline. On 07/12/2016 10:36 PM, Xuelei Fan wrote: > Thanks for the feedback, Artem. Here is the updated webrev per your > suggestions: > > http://cr.openjdk.java.net/~xuelei/8161106/webrev.02/ > > On 7/13/2016 1:03 AM, Artem Smotrakov wrote: >> Hi Xuelei, >> >> I am not an official reviewer, but I have a couple of comments. >> >> 1. line 149: would it be better to check this condition in a loop? >> > clientCondition.await() will wait for 30 seconds. Need no loop any > more. If adding a loop, it may become a potential deadloop and cause > timeout issue. Right, I didn't get it when I read it first time. >> 2. Using try-with-resources blocks might simplify doServerSide() a >> little bit (no need to call close() on sockets, and a couple of "try" >> blocks might be probably removed) >> > I considered to use try-with-resources. But as the lock is introduced. > and we want to support socket accept timeout, it more convenient to me > to use the traditional try-finally clauses. Agree. Using try-with resources would remove one try-finally block, but probably it would introduce nested "try" blocks. >> 3. Minor: it might be better to define timeout values as constants with >> meaningful names. >> > Maybe. Normally, if a number is used only once, I may not define a > field for it. Sure. > >> 4. Minor: lines 268-273 seem to work, but I am wondering if it would be >> better to use File.separator instead of "/" (someone may run the test on >> Windows, but without Cygwin). >> > I think JDK file I/O would take care of this file separator > interoperability. It's good to use File.separator, but as the path may > contains a few separator in test case following this template, for example: > > pathToStores = "../../../../../javax/net/ssl"; > > Using File.separator would not make nice line. Okay. I am not an expert in Java I/O, so I am not sure. Agree, File.separator wouldn't make it nicer. >> 5. SSLSocketSample() constructor, startServer() and startClient() methods: >> >> Recently we've had a couple of test issue where no exception was printed >> on client/server sides. It happened because exceptions were caught and >> stored, but then tests waited infinitely for another thread to finish. >> Then, jtreg just killed the tests. As a result, no exception was printed >> out. It might be better to simplify this code to print out an exception >> right after it's caught, and then throw a runtime exception if >> serverException or clientException are not null. Probably there is a >> side effect that logs may be a little messy sometimes because of lack of >> synchronization, but maybe something like synchronized(System.out) may >> help. >> > This update should be able to avoid the infinitely waiting. Updated to > print the exception message right after it is caught. Thanks. It might be better to print whole stack trace in srartServer/startClient >> 6. Minor: it might be better to make class constants uppercase >> >> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367 >> > Good to use uppercase. I plan to modify this template to a overridable > one so that test case can extend this template. By then, those fields > will not be declared as constants any more. Let's use the current names > for a while. Sure. Artem > > Thanks, > Xuelei > >> Artem >> >> On 07/10/2016 10:16 PM, Xuelei Fan wrote: >>> There is a nice catch of the timeout miss-match during the handling of >>> serverIsReady in doClientSide(). Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.01/ >>> >>> Thanks, >>> Xuelei >>> >>> On 7/11/2016 11:44 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review this enhancement of SSLSocket test template: >>>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.00/ >>>> >>>> There are some known issues with the current SSLSocket test template >>>> (test/javax/net/ssl/templates/SSLSocketTemplate.java) in the automation >>>> testing environment: >>>> 1. the client or server can be blocked if the peer run into problems, as >>>> may result in intermittent timeout failure. >>>> 2. the server accepted connection may be not linked to the expected >>>> client. For example, some other test case may try to use and connect to >>>> a free server socket port, unfortunately this port can be actually >>>> opened by the server of SSLSocketTemplate because there is no >>>> synchronization about the free socket port between test cases. It's OK >>>> to run the test singly, but may result in weird intermittent failure in >>>> the automation testing environment. >>>> >>>> The new test template in this update considers the noises above. >>>> >>>> Thanks, >>>> Xuelei >>>> From valerie.peng at oracle.com Thu Jul 14 00:10:08 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 13 Jul 2016 17:10:08 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" Message-ID: <5786D860.3080304@oracle.com> Sean, Can you please review the following two webrevs? Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ While making changes for 8159488, I noticed a problem with my earlier putback of 8154191 - the top level Modules.gmk was not integrated. So, I filed 8161171: Missed the make/common/Modules.gmk file when integrating JDK-8154191. Can you also review this? It's essentially the same change as the one reviewed. Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Thu Jul 14 01:57:33 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Jul 2016 09:57:33 +0800 Subject: RFR 8161341: Garbage in ProblemList.txt Message-ID: <6ee1c98e-97e3-7876-dbcc-84c50f14e83f@oracle.com> Some useless text were left on an exclude line, should be removed. The patch is: diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -215,7 +215,7 @@ sun/security/pkcs11/ec/TestKeyFactory.java 7157786 generic-all -sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac +sun/security/krb5/auto/Unreachable.java 7164518 macosx-all sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all Sorry for the "rich text format". The old line is too long. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jul 14 02:05:48 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 14 Jul 2016 10:05:48 +0800 Subject: RFR 8161341: Garbage in ProblemList.txt In-Reply-To: <6ee1c98e-97e3-7876-dbcc-84c50f14e83f@oracle.com> References: <6ee1c98e-97e3-7876-dbcc-84c50f14e83f@oracle.com> Message-ID: Looks fine to me. Xuelei On 7/14/2016 9:57 AM, Weijun Wang wrote: > Some useless text were left on an exclude line, should be removed. > > The patch is: > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -215,7 +215,7 @@ > > sun/security/pkcs11/ec/TestKeyFactory.java 7157786 > generic-all > > -sun/security/krb5/auto/Unreachable.java 7164518 > macosx-all no PortUnreachableException on Mac > +sun/security/krb5/auto/Unreachable.java 7164518 > macosx-all > > sun/security/tools/keytool/ListKeychainStore.sh 8156889 > macosx-all > > Sorry for the "rich text format". The old line is too long. > > Thanks > Max > From mandy.chung at oracle.com Thu Jul 14 07:59:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Jul 2016 15:59:53 +0800 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <5786D860.3080304@oracle.com> References: <5786D860.3080304@oracle.com> Message-ID: <78BABEE1-50A1-4A46-868E-37FC4BA78388@oracle.com> > On Jul 14, 2016, at 8:10 AM, Valerie Peng wrote: > > Sean, > > Can you please review the following two webrevs? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 > Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ > Update to Modules.gmk looks good. > While making changes for 8159488, I noticed a problem with my earlier putback of 8154191 - the top level Modules.gmk was not integrated. > So, I filed 8161171: Missed the make/common/Modules.gmk file when integrating JDK-8154191. > Can you also review this? It's essentially the same change as the one reviewed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 > Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ +1 You can go ahead and push the fix for JDK-8161171. Mandy From weijun.wang at oracle.com Thu Jul 14 08:30:25 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Jul 2016 16:30:25 +0800 Subject: RFR 8161354: policytool fails if it needs to show an error dialog before the main window appears Message-ID: <821ceb9c-b590-00c3-d776-f8e52e5e412c@oracle.com> Please review the patch below: diff --git a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java --- a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java +++ b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java @@ -1376,10 +1376,6 @@ ToolDialog ed = new ToolDialog (PolicyTool.getMessage("Error"), tool, this, true); - // find where the PolicyTool gui is - Point location = ((w == null) ? - getLocationOnScreen() : w.getLocationOnScreen()); - //ed.setBounds(location.x + 50, location.y + 50, 600, 100); ed.setLayout(new GridBagLayout()); JLabel label = new JLabel(error); location is already useless before this fix. I am trying to use policytool to load an illegal policy file and the tool wants to display an error dialog before the main windows shows up, and the getLocationOnScreen() method above fails. Noreg-trivial && noreg-cleanup. Thanks Max From sean.mullan at oracle.com Thu Jul 14 11:22:43 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 Jul 2016 07:22:43 -0400 Subject: RFR 8161354: policytool fails if it needs to show an error dialog before the main window appears In-Reply-To: <821ceb9c-b590-00c3-d776-f8e52e5e412c@oracle.com> References: <821ceb9c-b590-00c3-d776-f8e52e5e412c@oracle.com> Message-ID: <57877603.7070908@oracle.com> Looks ok to me. Make sure you add a noreg label to the bug. --Sean On 07/14/2016 04:30 AM, Weijun Wang wrote: > Please review the patch below: > > diff --git > a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > > --- > a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > > +++ > b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > > @@ -1376,10 +1376,6 @@ > ToolDialog ed = new ToolDialog > (PolicyTool.getMessage("Error"), tool, this, true); > > - // find where the PolicyTool gui is > - Point location = ((w == null) ? > - getLocationOnScreen() : w.getLocationOnScreen()); > - //ed.setBounds(location.x + 50, location.y + 50, 600, 100); > ed.setLayout(new GridBagLayout()); > > JLabel label = new JLabel(error); > > location is already useless before this fix. > > I am trying to use policytool to load an illegal policy file and the > tool wants to display an error dialog before the main windows shows up, > and the getLocationOnScreen() method above fails. > > Noreg-trivial && noreg-cleanup. > > Thanks > Max From svetlana.nikandrova at oracle.com Thu Jul 14 15:19:04 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 14 Jul 2016 18:19:04 +0300 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method Message-ID: <5787AD68.5030107@oracle.com> Hello, please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8054536 Webrev: http://cr.openjdk.java.net/~snikandrova/8054536/webrev.00/ Description: Equals and hasCode methods of Extension use extensionId without prior check for "null" (+ 1 mistype in equals javadoc). Thank you, Svetlana From artem.smotrakov at oracle.com Thu Jul 14 16:35:19 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 14 Jul 2016 09:35:19 -0700 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: <5787AD68.5030107@oracle.com> References: <5787AD68.5030107@oracle.com> Message-ID: <5787BF47.8060702@oracle.com> Hi Svetlana, I'll leave the main review to an official reviewer, but I have a couple of comments. There are a couple of other places in Extension.java where NPE may occur: - line 255: I see that "extensionId" is checked for null in other methods, but not in getId() - line 200: I see that "extensionValue" is checked for null in other methids, but not in getValue() Minor: try-catch is not really necessary. I am not sure, but "iff" might mean "if and only if", so it may be not a typo. You may want to add @Override to a couple of methods since you update Extension.java Artem On 07/14/2016 08:19 AM, Svetlana Nikandrova wrote: > Hello, > > please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8054536 > Webrev: > http://cr.openjdk.java.net/~snikandrova/8054536/webrev.00/ > > > Description: > Equals and hasCode methods of Extension use extensionId without prior > check for "null" (+ 1 mistype in equals javadoc). > > Thank you, > Svetlana From sibabrata.sahoo at oracle.com Thu Jul 14 17:01:23 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 14 Jul 2016 10:01:23 -0700 (PDT) Subject: [9] RFR: 8151654: Additional modular test for "auth.login.defaultCallbackHandler" property In-Reply-To: References: Message-ID: <9ea8bcba-cb54-4f3f-a953-d782523b6e87@default> Hi, Please review the following patch for "Additional modular test for "auth.login.defaultCallbackHandler" property". JBS: https://bugs.openjdk.java.net/browse/JDK-8151654 Webrev: http://cr.openjdk.java.net/~ssahoo/8151654/webrev.00/ Description: A custom callback handler for JAAS can be provided through "auth.login.defaultCallbackHandler" security property. This patch provides test the behavior when the callback handler available in module/class path as modular/regular jar file. There are few minor changes over few existing test files due to missing "-addmods" during runtime for automated module dependency. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jul 14 20:05:45 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 Jul 2016 16:05:45 -0400 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option Message-ID: <5787F099.2020606@oracle.com> Please review this change to the default Policy provider implementation to grant de-privileged module permissions by default even when the java.security.policy override option is specified or when the Policy.getInstance API is used: http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ A new system-wide policy file located in ${java.home}/lib/security/default.policy has been created. It contains grant statements containing the permissions that need to be granted to de-privileged modules. These grant statements were previously located in the ${java.home}/conf/security/java.policy file and have been relocated to the default.policy file. The default.policy file is now always loaded by the default Policy provider implementation (sun/security/provider/PolicyFile). It is loaded if the java.security.policy '=' or '==' option is specified, and also if the application uses the Policy.getInstance methods and specifies the "JavaPolicy" type. If the default.policy file cannot be loaded, an InternalError is thrown, on the basis that the runtime cannot operate correctly unless these permissions are granted. The rationale for making this change is that the runtime should be responsible for granting the permissions it needs to operate correctly. We should not expect users to have to determine or copy and paste these permissions into their own policy files. Thanks, Sean From chris.hegarty at oracle.com Thu Jul 14 20:38:35 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Jul 2016 21:38:35 +0100 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5787F099.2020606@oracle.com> References: <5787F099.2020606@oracle.com> Message-ID: <498E47BC-344A-4275-968C-AE82820AD1F1@oracle.com> > On 14 Jul 2016, at 21:05, Sean Mullan wrote: > > Please review this change to the default Policy provider implementation to grant de-privileged module permissions by default even when the java.security.policy override option is specified or when the Policy.getInstance API is used: > > http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ This makes sense. A quick skim shows nothing untoward. > A new system-wide policy file located in ${java.home}/lib/security/default.policy has been created. It contains grant statements containing the permissions that need to be granted to de-privileged modules. These grant statements were previously located in the ${java.home}/conf/security/java.policy file and have been relocated to the default.policy file. > > The default.policy file is now always loaded by the default Policy provider implementation (sun/security/provider/PolicyFile). It is loaded if the java.security.policy '=' or '==' option is specified, and also if the application uses the Policy.getInstance methods and specifies the "JavaPolicy" type. If the default.policy file cannot be loaded, an InternalError is thrown, on the basis that the runtime cannot operate correctly unless these permissions are granted. I think this is ok, but of course it is unnecessary for a minimal image with just java.base. Probably not worth complicating things, but you could conditionally add include the permissions per module based on its presence. > The rationale for making this change is that the runtime should be responsible for granting the permissions it needs to operate correctly. We should not expect users to have to determine or copy and paste these permissions into their own policy files. Sounds reasonable. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jul 14 20:43:57 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 Jul 2016 16:43:57 -0400 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <498E47BC-344A-4275-968C-AE82820AD1F1@oracle.com> References: <5787F099.2020606@oracle.com> <498E47BC-344A-4275-968C-AE82820AD1F1@oracle.com> Message-ID: <5787F98D.6010200@oracle.com> On 07/14/2016 04:38 PM, Chris Hegarty wrote: >> The default.policy file is now always loaded by the default Policy >> provider implementation (sun/security/provider/PolicyFile). It is >> loaded if the java.security.policy '=' or '==' option is specified, >> and also if the application uses the Policy.getInstance methods and >> specifies the "JavaPolicy" type. If the default.policy file cannot be >> loaded, an InternalError is thrown, on the basis that the runtime >> cannot operate correctly unless these permissions are granted. > > I think this is ok, but of course it is unnecessary for a minimal image > with just java.base. Probably not worth complicating things, but you > could conditionally add include the permissions per module based on its > presence. Yes, excellent point and there is already an RFE open for this: https://bugs.openjdk.java.net/browse/JDK-8080294 This should establish the groundwork for making that happen more easily but was not considered as critical as this piece to have in place right now. --Sean From valerie.peng at oracle.com Fri Jul 15 00:15:17 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 14 Jul 2016 17:15:17 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <78BABEE1-50A1-4A46-868E-37FC4BA78388@oracle.com> References: <5786D860.3080304@oracle.com> <78BABEE1-50A1-4A46-868E-37FC4BA78388@oracle.com> Message-ID: <57882B15.30403@oracle.com> Thanks, I will proceed integrating JDK-8161171 then. Valerie On 7/14/2016 12:59 AM, Mandy Chung wrote: >> On Jul 14, 2016, at 8:10 AM, Valerie Peng wrote: >> >> Sean, >> >> Can you please review the following two webrevs? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >> > Update to Modules.gmk looks good. > >> While making changes for 8159488, I noticed a problem with my earlier putback of 8154191 - the top level Modules.gmk was not integrated. >> So, I filed 8161171: Missed the make/common/Modules.gmk file when integrating JDK-8154191. >> Can you also review this? It's essentially the same change as the one reviewed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ > > +1 > > You can go ahead and push the fix for JDK-8161171. > > Mandy From mandy.chung at oracle.com Fri Jul 15 08:37:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Jul 2016 16:37:48 +0800 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5787F099.2020606@oracle.com> References: <5787F099.2020606@oracle.com> Message-ID: > On Jul 15, 2016, at 4:05 AM, Sean Mullan wrote: > > Please review this change to the default Policy provider implementation to grant de-privileged module permissions by default even when the java.security.policy override option is specified or when the Policy.getInstance API is used: > > http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ > Thanks for addressing the `==` overriding issue. As you replied in another mail, this patch prepares the future work to modularize java.policy for modules. I skimmed on the patch. The build change and java.policy and default.policy files look okay. I will leave the detailed review to the security team. Nit: line 312-314 - an alternative is to use: Paths.get(System.getProperty("java.home?), ?lib?, ?security?, ?default.policy?); Mandy From sean.mullan at oracle.com Fri Jul 15 11:51:49 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 Jul 2016 07:51:49 -0400 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5787F099.2020606@oracle.com> References: <5787F099.2020606@oracle.com> Message-ID: <5788CE55.60606@oracle.com> Adding build-dev for review since there is one change to a Makefile in the webrev below. Thanks, Sean On 07/14/2016 04:05 PM, Sean Mullan wrote: > Please review this change to the default Policy provider implementation > to grant de-privileged module permissions by default even when the > java.security.policy override option is specified or when the > Policy.getInstance API is used: > > http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ > > A new system-wide policy file located in > ${java.home}/lib/security/default.policy has been created. It contains > grant statements containing the permissions that need to be granted to > de-privileged modules. These grant statements were previously located in > the ${java.home}/conf/security/java.policy file and have been relocated > to the default.policy file. > > The default.policy file is now always loaded by the default Policy > provider implementation (sun/security/provider/PolicyFile). It is loaded > if the java.security.policy '=' or '==' option is specified, and also if > the application uses the Policy.getInstance methods and specifies the > "JavaPolicy" type. If the default.policy file cannot be loaded, an > InternalError is thrown, on the basis that the runtime cannot operate > correctly unless these permissions are granted. > > The rationale for making this change is that the runtime should be > responsible for granting the permissions it needs to operate correctly. > We should not expect users to have to determine or copy and paste these > permissions into their own policy files. > > Thanks, > Sean From tim.bell at oracle.com Fri Jul 15 14:14:53 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 15 Jul 2016 07:14:53 -0700 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5788CE55.60606@oracle.com> References: <5787F099.2020606@oracle.com> <5788CE55.60606@oracle.com> Message-ID: <5788EFDD.2050109@oracle.com> The Makefile changes look fine. Tim On 07/15/16 04:51, Sean Mullan wrote: > Adding build-dev for review since there is one change to a Makefile in > the webrev below. > > Thanks, > Sean > > On 07/14/2016 04:05 PM, Sean Mullan wrote: >> Please review this change to the default Policy provider implementation >> to grant de-privileged module permissions by default even when the >> java.security.policy override option is specified or when the >> Policy.getInstance API is used: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ >> >> A new system-wide policy file located in >> ${java.home}/lib/security/default.policy has been created. It contains >> grant statements containing the permissions that need to be granted to >> de-privileged modules. These grant statements were previously located in >> the ${java.home}/conf/security/java.policy file and have been relocated >> to the default.policy file. >> >> The default.policy file is now always loaded by the default Policy >> provider implementation (sun/security/provider/PolicyFile). It is loaded >> if the java.security.policy '=' or '==' option is specified, and also if >> the application uses the Policy.getInstance methods and specifies the >> "JavaPolicy" type. If the default.policy file cannot be loaded, an >> InternalError is thrown, on the basis that the runtime cannot operate >> correctly unless these permissions are granted. >> >> The rationale for making this change is that the runtime should be >> responsible for granting the permissions it needs to operate correctly. >> We should not expect users to have to determine or copy and paste these >> permissions into their own policy files. >> >> Thanks, >> Sean From weijun.wang at oracle.com Fri Jul 15 14:50:48 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 15 Jul 2016 22:50:48 +0800 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <5787F099.2020606@oracle.com> References: <5787F099.2020606@oracle.com> Message-ID: <2de7ed8a-68b6-f49c-69fd-4a6c538d4439@oracle.com> Changes looks fine to me. One nit: Shall we put jdk.crypto.ucrypto into src/java.base/solaris/lib/security/default.policy? --Max On 7/15/2016 4:05, Sean Mullan wrote: > Please review this change to the default Policy provider implementation > to grant de-privileged module permissions by default even when the > java.security.policy override option is specified or when the > Policy.getInstance API is used: > > http://cr.openjdk.java.net/~mullan/webrevs/8159752/webrev.00/ > > A new system-wide policy file located in > ${java.home}/lib/security/default.policy has been created. It contains > grant statements containing the permissions that need to be granted to > de-privileged modules. These grant statements were previously located in > the ${java.home}/conf/security/java.policy file and have been relocated > to the default.policy file. > > The default.policy file is now always loaded by the default Policy > provider implementation (sun/security/provider/PolicyFile). It is loaded > if the java.security.policy '=' or '==' option is specified, and also if > the application uses the Policy.getInstance methods and specifies the > "JavaPolicy" type. If the default.policy file cannot be loaded, an > InternalError is thrown, on the basis that the runtime cannot operate > correctly unless these permissions are granted. > > The rationale for making this change is that the runtime should be > responsible for granting the permissions it needs to operate correctly. > We should not expect users to have to determine or copy and paste these > permissions into their own policy files. > > Thanks, > Sean From sean.mullan at oracle.com Fri Jul 15 18:00:25 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 Jul 2016 14:00:25 -0400 Subject: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option In-Reply-To: <2de7ed8a-68b6-f49c-69fd-4a6c538d4439@oracle.com> References: <5787F099.2020606@oracle.com> <2de7ed8a-68b6-f49c-69fd-4a6c538d4439@oracle.com> Message-ID: <578924B9.2020104@oracle.com> On 07/15/2016 10:50 AM, Weijun Wang wrote: > Changes looks fine to me. > > One nit: Shall we put jdk.crypto.ucrypto into > src/java.base/solaris/lib/security/default.policy? Yes, might as well fix that as part of this. Thanks, Sean From svetlana.nikandrova at oracle.com Fri Jul 15 18:12:17 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 15 Jul 2016 21:12:17 +0300 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: <5787BF47.8060702@oracle.com> References: <5787AD68.5030107@oracle.com> <5787BF47.8060702@oracle.com> Message-ID: <57892781.3080302@oracle.com> Hi Artem, ok, lets get rid of possible NPE in other methods too: http://cr.openjdk.java.net/~snikandrova/8054536/webrev.01/ As for unnecessary try-catch in test I'd prefer to have it to emphasis that we are checking for NPE. I'm not sure about "iff" but let it be, it seems like a right place to use it. Thank you, Svetlana On 14.07.2016 19:35, Artem Smotrakov wrote: > Hi Svetlana, > > I'll leave the main review to an official reviewer, but I have a > couple of comments. > > There are a couple of other places in Extension.java where NPE may occur: > - line 255: I see that "extensionId" is checked for null in other > methods, but not in getId() > - line 200: I see that "extensionValue" is checked for null in other > methids, but not in getValue() > > Minor: try-catch is not really necessary. > > I am not sure, but "iff" might mean "if and only if", so it may be not > a typo. > > You may want to add @Override to a couple of methods since you update > Extension.java > > Artem > > On 07/14/2016 08:19 AM, Svetlana Nikandrova wrote: >> Hello, >> >> please review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8054536 >> Webrev: >> http://cr.openjdk.java.net/~snikandrova/8054536/webrev.00/ >> >> >> Description: >> Equals and hasCode methods of Extension use extensionId without prior >> check for "null" (+ 1 mistype in equals javadoc). >> >> Thank you, >> Svetlana > From peter.firmstone at zeus.net.au Fri Jul 8 07:53:47 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 8 Jul 2016 17:53:47 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <3d6b1f2d7d5212ea75370848a5181720@org.tizen.email> Yes, I've come across this before, it will occur if you write a custom security manager or policy provider and either are in force before all their required classes have been loaded. SM implementors also need to be careful of Permission checks that require another permission check, as these create recursive calls that can become infinite, but this won't occur in your simple test case. Regards, Peter. Sent from my Samsung device. ?? ??Include original message ---- Original message ---- From: Weijun Wang Sent: 08/07/2016 01:18:56 pm To: Peter Firmstone Cc: SeanMullan ; jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module Mystery?solved?or?problem?solved??Have?you?fixed?it?somewhere?else? Thanks Max On?7/7/2016?17:00,?Peter?Firmstone?wrote: >?Problem?solved,?even?though?it?didn't?occur?on?Java?8,?the?potential?for >?it?to?occur?still?exists?there,??it's?simply?that?Java?9?seems?to?have >?hit?this?execution?path,?it?was?a?latent?bug. > >?Cheers, > >?Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Fri Jul 8 09:31:12 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 8 Jul 2016 19:31:12 +1000 (AEST) Subject: Strange test failure when referencing a class in a deprivileged module Message-ID: <99f174b069f3171039225b6abf3a9cc0@org.tizen.email> I discovered these bugs after writing a non blocking caching security manager and a couple of high scaling policy providers that combine immutability, atomic policy refresh and local variable confined mutibility. ?The policy provider avoids unnecessary DNS calls by replacing URL with an rfc3986 compliant uri, which uses bitshift case conversion during normalisation. ?I could donate parts of it that I've written under GPL, but would need to determine and contact all other authors to donate the entire works. Needless to say Java's AccessController or AccessControlContext, are often incorrectly criticised for performance issues that originate in the policy provider. The rfc3986 compliant Uri class has an api identical to java's URI, although it isn't Serializable, it could be used to test the impact of rfc3986 on java platform libraries. Cheers, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Peter Firmstone Sent: 08/07/2016 05:53:47 pm To: WeijunWang Cc: jigsaw-dev ; OpenJDK Subject: Re: Strange test failure when referencing a class in a deprivileged module Yes,?I've?come?across?this?before,?it?will?occur?if?you?write?a?custom?security?manager?or?policy?provider?and?either?are?in?force?before?all?their?required?classes?have?been?loaded. SM?implementors?also?need?to?be?careful?of?Permission?checks?that?require?another?permission?check,?as?these?create?recursive?calls?that?can?become?infinite,?but?this?won't?occur?in?your?simple?test?case. Regards, Peter. Sent?from?my?Samsung?device. ?? ??Include?original?message ----?Original?message?---- From:?Weijun?Wang? Sent:?08/07/2016?01:18:56?pm To:?Peter?Firmstone? Cc:?SeanMullan?;?jigsaw-dev?;?OpenJDK? Subject:?Re:?Strange?test?failure?when?referencing?a?class?in?a?deprivileged?module Mystery?solved?or?problem?solved??Have?you?fixed?it?somewhere?else?? Thanks? Max? On?7/7/2016?17:00,?Peter?Firmstone?wrote:? >?Problem?solved,?even?though?it?didn't?occur?on?Java?8,?the?potential?for? >?it?to?occur?still?exists?there,??it's?simply?that?Java?9?seems?to?have? >?hit?this?execution?path,?it?was?a?latent?bug.? >? >?Cheers,? >? >?Peter.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From neomorcon at yahoo.com Wed Jul 13 22:57:39 2016 From: neomorcon at yahoo.com (sheon banks) Date: Wed, 13 Jul 2016 22:57:39 +0000 (UTC) Subject: JDK-8152524 References: <1467657865.2758173.1468450659825.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1467657865.2758173.1468450659825.JavaMail.yahoo@mail.yahoo.com> Hi All, This message is actually for Sean Coffey in relation to the JDK-8152524.? I saw the incident on the Web.? I am having a similar issue.? In the post, it is stated that this is being tracked elsewhere.? Can you tell me where?? I would like to know if it is being treated as an MS or McAfee issue. Sheon Banks -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Fri Jul 15 18:32:34 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 15 Jul 2016 11:32:34 -0700 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: <57892781.3080302@oracle.com> References: <5787AD68.5030107@oracle.com> <5787BF47.8060702@oracle.com> <57892781.3080302@oracle.com> Message-ID: <57892C42.4030506@oracle.com> Hi Svetlana, The webrev looks fine to me. Please see one more comment inline. On 07/15/2016 11:12 AM, Svetlana Nikandrova wrote: > Hi Artem, > > ok, lets get rid of possible NPE in other methods too: > http://cr.openjdk.java.net/~snikandrova/8054536/webrev.01/ > I also noticed that encode(DerOutputStream) checks extensionId and extensionValue for null, but encode(OutputStream) doesn't. encode(OutputStream) might just call encode(DerOutputStream), so that it always checks those fields for null. It also would remove some duplicate code. > > As for unnecessary try-catch in test I'd prefer to have it to emphasis > that we are checking for NPE. Okay. > I'm not sure about "iff" but let it be, it seems like a right place to > use it. Sure. Artem > > Thank you, > Svetlana > > On 14.07.2016 19:35, Artem Smotrakov wrote: >> Hi Svetlana, >> >> I'll leave the main review to an official reviewer, but I have a >> couple of comments. >> >> There are a couple of other places in Extension.java where NPE may >> occur: >> - line 255: I see that "extensionId" is checked for null in other >> methods, but not in getId() >> - line 200: I see that "extensionValue" is checked for null in other >> methids, but not in getValue() >> >> Minor: try-catch is not really necessary. >> >> I am not sure, but "iff" might mean "if and only if", so it may be >> not a typo. >> >> You may want to add @Override to a couple of methods since you update >> Extension.java >> >> Artem >> >> On 07/14/2016 08:19 AM, Svetlana Nikandrova wrote: >>> Hello, >>> >>> please review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8054536 >>> Webrev: >>> http://cr.openjdk.java.net/~snikandrova/8054536/webrev.00/ >>> >>> >>> Description: >>> Equals and hasCode methods of Extension use extensionId without >>> prior check for "null" (+ 1 mistype in equals javadoc). >>> >>> Thank you, >>> Svetlana >> > From weijun.wang at oracle.com Sun Jul 17 07:41:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 17 Jul 2016 15:41:30 +0800 Subject: [9] RFR: 8151654: Additional modular test for "auth.login.defaultCallbackHandler" property In-Reply-To: <9ea8bcba-cb54-4f3f-a953-d782523b6e87@default> References: <9ea8bcba-cb54-4f3f-a953-d782523b6e87@default> Message-ID: Why change C_BUILD_DIR to C_BLD_DIR everywhere? Can you add the "-addmods m" option into the vmArgs parameter of the getJavaCommand() method? In fact, why must vmArgs be a map instead of a List? Are you worried about the same system property be assigned twice? There is no need to generate lists and convert it to array in getTestOutput(), just return what you need, like this: return new Object[][] { {1,2,3}, {4,5,6}, }; BTW, what's the main reason you rewrite existing tests? Thanks Max > On Jul 15, 2016, at 1:01 AM, Sibabrata Sahoo wrote: > > Hi, > > Please review the following patch for ?Additional modular test for "auth.login.defaultCallbackHandler" property?. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8151654 > Webrev: http://cr.openjdk.java.net/~ssahoo/8151654/webrev.00/ > > Description: > A custom callback handler for JAAS can be provided through "auth.login.defaultCallbackHandler" security property. This patch provides test the behavior when the callback handler available in module/class path as modular/regular jar file. > There are few minor changes over few existing test files due to missing ?-addmods? during runtime for automated module dependency. > > Thanks, > Siba From svetlana.nikandrova at oracle.com Mon Jul 18 15:40:33 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Mon, 18 Jul 2016 18:40:33 +0300 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: <57892C42.4030506@oracle.com> References: <5787AD68.5030107@oracle.com> <5787BF47.8060702@oracle.com> <57892781.3080302@oracle.com> <57892C42.4030506@oracle.com> Message-ID: <578CF871.4040009@oracle.com> Artem, please see updated review: http://cr.openjdk.java.net/~snikandrova/8054536/webrev.02/ Thanks, Svetlana On 15.07.2016 21:32, Artem Smotrakov wrote: > Hi Svetlana, > > The webrev looks fine to me. Please see one more comment inline. > > On 07/15/2016 11:12 AM, Svetlana Nikandrova wrote: >> Hi Artem, >> >> ok, lets get rid of possible NPE in other methods too: >> http://cr.openjdk.java.net/~snikandrova/8054536/webrev.01/ >> > I also noticed that encode(DerOutputStream) checks extensionId and > extensionValue for null, but encode(OutputStream) doesn't. > > encode(OutputStream) might just call encode(DerOutputStream), so that > it always checks those fields for null. It also would remove some > duplicate code. >> >> As for unnecessary try-catch in test I'd prefer to have it to >> emphasis that we are checking for NPE. > Okay. >> I'm not sure about "iff" but let it be, it seems like a right place >> to use it. > Sure. > > Artem >> >> Thank you, >> Svetlana >> >> On 14.07.2016 19:35, Artem Smotrakov wrote: >>> Hi Svetlana, >>> >>> I'll leave the main review to an official reviewer, but I have a >>> couple of comments. >>> >>> There are a couple of other places in Extension.java where NPE may >>> occur: >>> - line 255: I see that "extensionId" is checked for null in other >>> methods, but not in getId() >>> - line 200: I see that "extensionValue" is checked for null in other >>> methids, but not in getValue() >>> >>> Minor: try-catch is not really necessary. >>> >>> I am not sure, but "iff" might mean "if and only if", so it may be >>> not a typo. >>> >>> You may want to add @Override to a couple of methods since you >>> update Extension.java >>> >>> Artem >>> >>> On 07/14/2016 08:19 AM, Svetlana Nikandrova wrote: >>>> Hello, >>>> >>>> please review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8054536 >>>> Webrev: >>>> http://cr.openjdk.java.net/~snikandrova/8054536/webrev.00/ >>>> >>>> >>>> Description: >>>> Equals and hasCode methods of Extension use extensionId without >>>> prior check for "null" (+ 1 mistype in equals javadoc). >>>> >>>> Thank you, >>>> Svetlana >>> >> > From weijun.wang at oracle.com Mon Jul 18 16:09:43 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Jul 2016 00:09:43 +0800 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: <578CF871.4040009@oracle.com> References: <5787AD68.5030107@oracle.com> <5787BF47.8060702@oracle.com> <57892781.3080302@oracle.com> <57892C42.4030506@oracle.com> <578CF871.4040009@oracle.com> Message-ID: If the constructor is only meant to be called by a child class, can we just change it to protected? Also, if extensionId and extensionValue should never be null, we should focus on not to create an Extension that has one of 2 fields as null. Inside this class, we can add Objects::requireNonNull checks in the 3-arg constructor and the static newExtension method. In case we cannot guarantee them to be non-null (For example, a child class has not fill in these 2 fields), I'd rather fail loudly instead of returning null or "null". In my humble opinion, throwing NPE in hashCode and equals is not really a bad thing. Thanks Max > On Jul 18, 2016, at 11:40 PM, Svetlana Nikandrova wrote: > > Artem, > > please see updated review: > http://cr.openjdk.java.net/~snikandrova/8054536/webrev.02/ > > Thanks, > Svetlana From sean.mullan at oracle.com Mon Jul 18 19:48:51 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 Jul 2016 15:48:51 -0400 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <5786D860.3080304@oracle.com> References: <5786D860.3080304@oracle.com> Message-ID: <578D32A3.8020307@oracle.com> On 07/13/2016 08:10 PM, Valerie Peng wrote: > Sean, > > Can you please review the following two webrevs? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 > Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ Looks good except for this one: 127 // needed for reading Certs 128 permission java.io.FilePermission "<>","read"; Why is that needed? > > While making changes for 8159488, I noticed a problem with my earlier > putback of 8154191 - the top level Modules.gmk was not integrated. > So, I filed 8161171: Missed the make/common/Modules.gmk file when > integrating JDK-8154191. > Can you also review this? It's essentially the same change as the one > reviewed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 > Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ I'll skip this since Mandy already reviewed that one. --Sean From anthony.scarpino at oracle.com Mon Jul 18 20:24:41 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 18 Jul 2016 13:24:41 -0700 Subject: RFR: 8060224 Enable SHA-1 CertPath Restrictions Message-ID: <578D3B09.1090000@oracle.com> Please review the configuration change for the java.security file. http://cr.openjdk.java.net/~ascarpino/8060224/webrev/ Tony From valerie.peng at oracle.com Mon Jul 18 21:38:23 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 18 Jul 2016 14:38:23 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <578D32A3.8020307@oracle.com> References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> Message-ID: <578D4C4F.6000101@oracle.com> Hi Sean, I found these two classes in java.xml.crypto module reading local files: src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java If you think the File reading permission is not needed for java.xml.crypto module, I will remove the corresponding permission entry. Thanks, Valerie On 7/18/2016 12:48 PM, Sean Mullan wrote: > On 07/13/2016 08:10 PM, Valerie Peng wrote: >> Sean, >> >> Can you please review the following two webrevs? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ > > Looks good except for this one: > > 127 // needed for reading Certs > 128 permission java.io.FilePermission "<>","read"; > > Why is that needed? > >> >> While making changes for 8159488, I noticed a problem with my earlier >> putback of 8154191 - the top level Modules.gmk was not integrated. >> So, I filed 8161171: Missed the make/common/Modules.gmk file when >> integrating JDK-8154191. >> Can you also review this? It's essentially the same change as the one >> reviewed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ > > I'll skip this since Mandy already reviewed that one. > > --Sean From sean.mullan at oracle.com Mon Jul 18 22:28:18 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 Jul 2016 18:28:18 -0400 Subject: RFR: 8060224 Enable SHA-1 CertPath Restrictions In-Reply-To: <578D3B09.1090000@oracle.com> References: <578D3B09.1090000@oracle.com> Message-ID: <578D5802.7020401@oracle.com> Looks good. --Sean On 7/18/2016 4:24 PM, Anthony Scarpino wrote: > Please review the configuration change for the java.security file. > > http://cr.openjdk.java.net/~ascarpino/8060224/webrev/ > > Tony > From sean.mullan at oracle.com Tue Jul 19 18:57:22 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 19 Jul 2016 14:57:22 -0400 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <578D4C4F.6000101@oracle.com> References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> Message-ID: <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> On 07/18/2016 05:38 PM, Valerie Peng wrote: > Hi Sean, > > I found these two classes in java.xml.crypto module reading local files: > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java > > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java I think we should leave it out. The methods that need that permission are in non-exported packages and are essentially unused. Also, you may have noticed, but I just filed https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would allow us to remove this permission: permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca.*"; I'm not sure if you have the time to tackle that as part of this issue, but I think it would be acceptable to fix them together as part of this issue if so. --Sean > > > > If you think the File reading permission is not needed for > java.xml.crypto module, I will remove the corresponding permission entry. > Thanks, > Valerie > > On 7/18/2016 12:48 PM, Sean Mullan wrote: >> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>> Sean, >>> >>> Can you please review the following two webrevs? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >> >> Looks good except for this one: >> >> 127 // needed for reading Certs >> 128 permission java.io.FilePermission "<>","read"; >> >> Why is that needed? >> >>> >>> While making changes for 8159488, I noticed a problem with my earlier >>> putback of 8154191 - the top level Modules.gmk was not integrated. >>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>> integrating JDK-8154191. >>> Can you also review this? It's essentially the same change as the one >>> reviewed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >> >> I'll skip this since Mandy already reviewed that one. >> >> --Sean > From vincent.x.ryan at oracle.com Tue Jul 19 19:10:27 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 19 Jul 2016 20:10:27 +0100 Subject: [9] RFR 8161571: Verifying ECDSA signatures permits trailing bytes Message-ID: <9BF0A4C5-85CF-44B3-A59F-113A6BCF4808@oracle.com> Please review this fix to apply stricter length checks when verifying public key signatures. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8161571 Webrev: http://cr.openjdk.java.net/~vinnie/8161571/webrev.00/ From valerie.peng at oracle.com Wed Jul 20 23:57:25 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 Jul 2016 16:57:25 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> Message-ID: Sean, I have updated webrev to rid the dependency on sun.security.jca packages. Also, I found one additional SecurityPermission is needed. Please find the updated webrev at: http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/ So, we should close JDK-8161710 as a duplicate of JDK-8159488 then? Thanks, Valerie On 7/19/2016 11:57 AM, Sean Mullan wrote: > On 07/18/2016 05:38 PM, Valerie Peng wrote: >> Hi Sean, >> >> I found these two classes in java.xml.crypto module reading local files: >> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java >> >> >> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java >> > > I think we should leave it out. The methods that need that permission > are in non-exported packages and are essentially unused. > > Also, you may have noticed, but I just filed > https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would > allow us to remove this permission: > > permission java.lang.RuntimePermission > "accessClassInPackage.sun.security.jca.*"; > > I'm not sure if you have the time to tackle that as part of this > issue, but I think it would be acceptable to fix them together as part > of this issue if so. > > --Sean > >> >> >> >> If you think the File reading permission is not needed for >> java.xml.crypto module, I will remove the corresponding permission >> entry. >> Thanks, >> Valerie >> >> On 7/18/2016 12:48 PM, Sean Mullan wrote: >>> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Can you please review the following two webrevs? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >>> >>> Looks good except for this one: >>> >>> 127 // needed for reading Certs >>> 128 permission java.io.FilePermission "<>","read"; >>> >>> Why is that needed? >>> >>>> >>>> While making changes for 8159488, I noticed a problem with my earlier >>>> putback of 8154191 - the top level Modules.gmk was not integrated. >>>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>>> integrating JDK-8154191. >>>> Can you also review this? It's essentially the same change as the one >>>> reviewed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >>> >>> I'll skip this since Mandy already reviewed that one. >>> >>> --Sean >> From xuelei.fan at oracle.com Thu Jul 21 02:32:02 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Jul 2016 10:32:02 +0800 Subject: Code Review Request JDK-8161898 Mark the use of deprecated javax.security.cert APIs with forRemoval=true Message-ID: Hi, javax.security.cert was deprecated and marked with forRemoval=true in JDK 9. The use of javax.security.cert APIs should be marked with forRemoval=true too. Please review the update: http://cr.openjdk.java.net/~xuelei/8161898/webrev.00/ Thanks, Xuelei From vincent.x.ryan at oracle.com Thu Jul 21 07:56:50 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 21 Jul 2016 08:56:50 +0100 Subject: Code Review Request JDK-8161898 Mark the use of deprecated javax.security.cert APIs with forRemoval=true In-Reply-To: References: Message-ID: <7C423C75-8884-422B-BF86-AD1BD9F028AD@oracle.com> Looks fine to me. Thanks. > On 21 Jul 2016, at 03:32, Xuelei Fan wrote: > > Hi, > > javax.security.cert was deprecated and marked with forRemoval=true in > JDK 9. The use of javax.security.cert APIs should be marked with > forRemoval=true too. > > Please review the update: > > http://cr.openjdk.java.net/~xuelei/8161898/webrev.00/ > > Thanks, > Xuelei From goondaba at gmail.com Thu Jul 21 12:48:58 2016 From: goondaba at gmail.com (Carlos Gunners) Date: Thu, 21 Jul 2016 13:48:58 +0100 Subject: Kerberos Authentication Issue Message-ID: Hello, I have a situation here where we run an ldap service with round-robin dns .. so, we advertise a cname that resolves to multiple actual servers. Also, this cnam is not setup as a service principal in kerberos. When I try to connect a java app (tomcat8 container, openjdk-7-jre v 7u101, debian jessie) to this ldap service via GSSAPI/kerberos using a keytab for auth, it repeatedly fails .. initially failing to find the service principal in kerberos via its non-canonical hostname (meaning that the java app totally ignores rdns setting, and thus does no reverse dns check before trying to obtain a ticket). When I define a JAVA_OPTION '-Dsun.security.jgss.native=true' to tomcat8, then the failure changes completely to enctype mismatch type of errors like below : > LDAPException(resultCode=82 (local error), errorMessage='An error occurred while > attempting to initialize the JAAS login context for GSSAPI authentication: > javax.security.auth.login.LoginException: Integrity check on decrypted field failed (31) - > PREAUTH_FAILED caused by KrbException: Integrity check on decrypted field failed (31) - > PREAUTH_FAILED caused by KrbException: Identifier doesn't match expected value (906)') The logs reveal the correct entypes are being used .. ktlog confirms that the keytab has the correct entypes .. It's worth noting that we have the same application setup and working exactly like this with openjdk-6-jre v 6b36 on debian squeeze .. I have spent so many days trouble-shooting this without success .. My questions are: -- how do I force java to respect rdns settings in krb5.conf, and avoid all these issues ? -- what's the best practice way to configure for a service designed in this way? Or I must define the service principal in kerberos even for a round-robin presented service? -- are there any obvious issues I am overlooking ? Thanks in advance for suggestions, advice .. best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jul 21 14:46:17 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Jul 2016 22:46:17 +0800 Subject: [9] RFR 8161571: Verifying ECDSA signatures permits trailing bytes In-Reply-To: <9BF0A4C5-85CF-44B3-A59F-113A6BCF4808@oracle.com> References: <9BF0A4C5-85CF-44B3-A59F-113A6BCF4808@oracle.com> Message-ID: <941e1a8c-2668-4c9a-0496-a80d953f8155@oracle.com> Looks fine to me. Just two minor comments. The run tag in the test may be not necessary. Like EC algorithm, maybe the PKCS11 implementation of RSA and DSA algorithms can also be checked on some platform if not using provider option. + main0("RSA", 2048, "SHA256withRSA", null); + main0("DSA", 2048, "SHA256withDSA", null); Xuelei On 7/20/2016 3:10 AM, Vincent Ryan wrote: > Please review this fix to apply stricter length checks when verifying public key signatures. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161571 > Webrev: http://cr.openjdk.java.net/~vinnie/8161571/webrev.00/ > From sean.mullan at oracle.com Thu Jul 21 19:08:40 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 Jul 2016 15:08:40 -0400 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> Message-ID: On 07/20/2016 07:57 PM, Valerie Peng wrote: > Sean, > > I have updated webrev to rid the dependency on sun.security.jca > packages. Also, I found one additional SecurityPermission is needed. > > Please find the updated webrev at: > http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/ > > > So, we should close JDK-8161710 as a duplicate of JDK-8159488 then? Yes. The fix looks good. Could you write a simple test which calls the getInstance methods with good/bogus algs and providers just to make sure they all work as expected? There don't seem to be any regression tests for that. Thanks, Sean > > Thanks, > Valerie > > On 7/19/2016 11:57 AM, Sean Mullan wrote: >> On 07/18/2016 05:38 PM, Valerie Peng wrote: >>> Hi Sean, >>> >>> I found these two classes in java.xml.crypto module reading local files: >>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java >>> >>> >>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java >>> >> >> I think we should leave it out. The methods that need that permission >> are in non-exported packages and are essentially unused. >> >> Also, you may have noticed, but I just filed >> https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would >> allow us to remove this permission: >> >> permission java.lang.RuntimePermission >> "accessClassInPackage.sun.security.jca.*"; >> >> I'm not sure if you have the time to tackle that as part of this >> issue, but I think it would be acceptable to fix them together as part >> of this issue if so. >> >> --Sean >> >>> >>> >>> >>> If you think the File reading permission is not needed for >>> java.xml.crypto module, I will remove the corresponding permission >>> entry. >>> Thanks, >>> Valerie >>> >>> On 7/18/2016 12:48 PM, Sean Mullan wrote: >>>> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> Can you please review the following two webrevs? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >>>> >>>> Looks good except for this one: >>>> >>>> 127 // needed for reading Certs >>>> 128 permission java.io.FilePermission "<>","read"; >>>> >>>> Why is that needed? >>>> >>>>> >>>>> While making changes for 8159488, I noticed a problem with my earlier >>>>> putback of 8154191 - the top level Modules.gmk was not integrated. >>>>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>>>> integrating JDK-8154191. >>>>> Can you also review this? It's essentially the same change as the one >>>>> reviewed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >>>> >>>> I'll skip this since Mandy already reviewed that one. >>>> >>>> --Sean >>> > From valerie.peng at oracle.com Thu Jul 21 19:55:47 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 21 Jul 2016 12:55:47 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> Message-ID: <453e4a0d-e21b-23ec-92b2-3df6ed5ec8ae@oracle.com> Existing regression tests for the java.xml.crypto do test the getInstance() methods as I observed during my own testing. Maybe not all of them are covered though. I will double check and add test if necessary... Thanks, Valerie On 7/21/2016 12:08 PM, Sean Mullan wrote: > On 07/20/2016 07:57 PM, Valerie Peng wrote: >> Sean, >> >> I have updated webrev to rid the dependency on sun.security.jca >> packages. Also, I found one additional SecurityPermission is needed. >> >> Please find the updated webrev at: >> http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/ >> >> >> So, we should close JDK-8161710 as a duplicate of JDK-8159488 then? > > Yes. The fix looks good. Could you write a simple test which calls the > getInstance methods with good/bogus algs and providers just to make > sure they all work as expected? There don't seem to be any regression > tests for that. > > Thanks, > Sean > >> >> Thanks, >> Valerie >> >> On 7/19/2016 11:57 AM, Sean Mullan wrote: >>> On 07/18/2016 05:38 PM, Valerie Peng wrote: >>>> Hi Sean, >>>> >>>> I found these two classes in java.xml.crypto module reading local >>>> files: >>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java >>>> >>>> >>>> >>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java >>>> >>>> >>> >>> I think we should leave it out. The methods that need that permission >>> are in non-exported packages and are essentially unused. >>> >>> Also, you may have noticed, but I just filed >>> https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would >>> allow us to remove this permission: >>> >>> permission java.lang.RuntimePermission >>> "accessClassInPackage.sun.security.jca.*"; >>> >>> I'm not sure if you have the time to tackle that as part of this >>> issue, but I think it would be acceptable to fix them together as part >>> of this issue if so. >>> >>> --Sean >>> >>>> >>>> >>>> >>>> If you think the File reading permission is not needed for >>>> java.xml.crypto module, I will remove the corresponding permission >>>> entry. >>>> Thanks, >>>> Valerie >>>> >>>> On 7/18/2016 12:48 PM, Sean Mullan wrote: >>>>> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>>>>> Sean, >>>>>> >>>>>> Can you please review the following two webrevs? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >>>>> >>>>> Looks good except for this one: >>>>> >>>>> 127 // needed for reading Certs >>>>> 128 permission java.io.FilePermission "<>>>> FILES>>","read"; >>>>> >>>>> Why is that needed? >>>>> >>>>>> >>>>>> While making changes for 8159488, I noticed a problem with my >>>>>> earlier >>>>>> putback of 8154191 - the top level Modules.gmk was not integrated. >>>>>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>>>>> integrating JDK-8154191. >>>>>> Can you also review this? It's essentially the same change as the >>>>>> one >>>>>> reviewed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >>>>> >>>>> I'll skip this since Mandy already reviewed that one. >>>>> >>>>> --Sean >>>> >> From vincent.x.ryan at oracle.com Thu Jul 21 22:08:12 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 21 Jul 2016 23:08:12 +0100 Subject: [9] RFR 8161571: Verifying ECDSA signatures permits trailing bytes In-Reply-To: <941e1a8c-2668-4c9a-0496-a80d953f8155@oracle.com> References: <9BF0A4C5-85CF-44B3-A59F-113A6BCF4808@oracle.com> <941e1a8c-2668-4c9a-0496-a80d953f8155@oracle.com> Message-ID: Thanks for the review. The PKCS11 implementation is a little peculiar in that it is configured out-of-the-box only for Solaris and that implementation doesn?t support DSA. So I?ve added only the first of your additional lines below. (NOTE the update to the Ucrypto provider) Updated webrev at: http://cr.openjdk.java.net/~vinnie/8161571/webrev.01/ > On 21 Jul 2016, at 15:46, Xuelei Fan wrote: > > Looks fine to me. > > Just two minor comments. The run tag in the test may be not necessary. > Like EC algorithm, maybe the PKCS11 implementation of RSA and DSA > algorithms can also be checked on some platform if not using provider > option. > > + main0("RSA", 2048, "SHA256withRSA", null); > + main0("DSA", 2048, "SHA256withDSA", null); > > Xuelei > > On 7/20/2016 3:10 AM, Vincent Ryan wrote: >> Please review this fix to apply stricter length checks when verifying public key signatures. >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161571 >> Webrev: http://cr.openjdk.java.net/~vinnie/8161571/webrev.00/ >> > From xuelei.fan at oracle.com Thu Jul 21 22:58:58 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Jul 2016 06:58:58 +0800 Subject: [9] RFR 8161571: Verifying ECDSA signatures permits trailing bytes In-Reply-To: References: <9BF0A4C5-85CF-44B3-A59F-113A6BCF4808@oracle.com> <941e1a8c-2668-4c9a-0496-a80d953f8155@oracle.com> Message-ID: Looks fine to me. Thanks! Xuelei On 7/22/2016 6:08 AM, Vincent Ryan wrote: > Thanks for the review. > > The PKCS11 implementation is a little peculiar in that it is configured out-of-the-box only for Solaris > and that implementation doesn?t support DSA. So I?ve added only the first of your additional lines below. > > (NOTE the update to the Ucrypto provider) > > Updated webrev at: > http://cr.openjdk.java.net/~vinnie/8161571/webrev.01/ > > > > >> On 21 Jul 2016, at 15:46, Xuelei Fan wrote: >> >> Looks fine to me. >> >> Just two minor comments. The run tag in the test may be not necessary. >> Like EC algorithm, maybe the PKCS11 implementation of RSA and DSA >> algorithms can also be checked on some platform if not using provider >> option. >> >> + main0("RSA", 2048, "SHA256withRSA", null); >> + main0("DSA", 2048, "SHA256withDSA", null); >> >> Xuelei >> >> On 7/20/2016 3:10 AM, Vincent Ryan wrote: >>> Please review this fix to apply stricter length checks when verifying public key signatures. >>> Thanks. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161571 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8161571/webrev.00/ >>> >> > From tiantian.du at oracle.com Fri Jul 22 06:48:38 2016 From: tiantian.du at oracle.com (Tim Du) Date: Fri, 22 Jul 2016 14:48:38 +0800 Subject: [9] RFR:8160337 Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java In-Reply-To: References: <577CBB97.7040806@oracle.com> Message-ID: <5791C1C6.6010505@oracle.com> Thanks Rajan's comments, Updated the code here: http://cr.openjdk.java.net/~tidu/8160337/webrev.01/ ,Please help to review it again.Thanks. Regards Tim On 2016/7/7 1:22, Rajan Halade wrote: > Hi Tim, > > Thanks for taking care of this one. Since the test is still using > random data key "randomness" should be retained. > > Thanks, > Rajan > > On 7/6/16 1:04 AM, Tim Du wrote: >> Hi All, >> >> Would you help to review the path for "8160337:Remove intermittent >> key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java"? >> JDK-8074580 has been fixed, @key intermittent can be removed.Thanks. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160337 >> webrev: http://cr.openjdk.java.net/~tidu/8160337/webrev.00/ >> >> Regards >> Tim > From sibabrata.sahoo at oracle.com Fri Jul 22 09:12:49 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 22 Jul 2016 02:12:49 -0700 (PDT) Subject: [9] RFR: 8151654: Additional modular test for "auth.login.defaultCallbackHandler" property In-Reply-To: References: <9ea8bcba-cb54-4f3f-a953-d782523b6e87@default> Message-ID: Hi Max, Please find the update webrev: http://cr.openjdk.java.net/~ssahoo/8151654/webrev.01/ Here is the change as per comment, - I renamed C_BUILD_DIR to C_BLD_DIR just make few line to put within 80 character space. I think it should be fine here. - As suggested, "-addmods m" option added to vmArgs parameter of the getJavaCommand() method. Making vmArgs be a map makes more sense for holding JVM parameters(name, value) as well as makes sure the properties are not defined twice. - I understand that getTestInput() can directly return an array of Object[][]. But still I used List with intension. The reason is, I found it make the test input look more cleaner and it makes the line easily readable than an array. It got additional code but I think we still can have it from the point where it make more readable. After all it does not have any reasonable performance impact. - I did few change to existing Test to add "-addmods". It is useful for the case where a transitive dependency need to be added to root module explicitly. This is not required for the case where the modular graph is much clearly defined through module descriptor. This might require in certain cases where the module need to be linked to the root module in explicit way. Regarding the change to existing test, I feel still it is optional but good to have. The reason is, either we add a module explicitly or not, still it is a valid test case. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Sunday, July 17, 2016 1:12 PM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net; Mandy Chung; Valerie Peng Subject: Re: [9] RFR: 8151654: Additional modular test for "auth.login.defaultCallbackHandler" property Why change C_BUILD_DIR to C_BLD_DIR everywhere? Can you add the "-addmods m" option into the vmArgs parameter of the getJavaCommand() method? In fact, why must vmArgs be a map instead of a List? Are you worried about the same system property be assigned twice? There is no need to generate lists and convert it to array in getTestOutput(), just return what you need, like this: return new Object[][] { {1,2,3}, {4,5,6}, }; BTW, what's the main reason you rewrite existing tests? Thanks Max > On Jul 15, 2016, at 1:01 AM, Sibabrata Sahoo wrote: > > Hi, > > Please review the following patch for ?Additional modular test for "auth.login.defaultCallbackHandler" property?. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8151654 > Webrev: http://cr.openjdk.java.net/~ssahoo/8151654/webrev.00/ > > Description: > A custom callback handler for JAAS can be provided through "auth.login.defaultCallbackHandler" security property. This patch provides test the behavior when the callback handler available in module/class path as modular/regular jar file. > There are few minor changes over few existing test files due to missing ?-addmods? during runtime for automated module dependency. > > Thanks, > Siba From weijun.wang at oracle.com Fri Jul 22 15:13:36 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 Jul 2016 23:13:36 +0800 Subject: [9] RFR: 8151654: Additional modular test for "auth.login.defaultCallbackHandler" property In-Reply-To: References: <9ea8bcba-cb54-4f3f-a953-d782523b6e87@default> Message-ID: <680b411b-ea8d-9542-ddaf-81fd0ecb3c92@oracle.com> On 7/22/2016 17:12, Sibabrata Sahoo wrote: > Hi Max, > > Please find the update webrev: http://cr.openjdk.java.net/~ssahoo/8151654/webrev.01/ > > Here is the change as per comment, > - I renamed C_BUILD_DIR to C_BLD_DIR just make few line to put within 80 character space. I think it should be fine here. Well, you have S_BUILD_DIR and BUILD_DIR and then suddently C_BLD_DIR. Just looks strange. > - As suggested, "-addmods m" option added to vmArgs parameter of the getJavaCommand() method. Making vmArgs be a map makes more sense for holding JVM parameters(name, value) as well as makes sure the properties are not defined twice. No need to worry about this. I believe if a system property is defined multiple times, the last one wins out. > - I understand that getTestInput() can directly return an array of Object[][]. But still I used List with intension. The reason is, I found it make the test input look more cleaner and it makes the line easily readable than an array. It got additional code but I think we still can have it from the point where it make more readable. After all it does not have any reasonable performance impact. The arguments are all in a comma-separated-list, why is List better looking? > - I did few change to existing Test to add "-addmods". It is useful for the case where a transitive dependency need to be added to root module explicitly. This is not required for the case where the modular graph is much clearly defined through module descriptor. This might require in certain cases where the module need to be linked to the root module in explicit way. Regarding the change to existing test, I feel still it is optional but good to have. The reason is, either we add a module explicitly or not, still it is a valid test case. Sounds reasonable. Anyway, all my comments are about styles and not correctness. Feel free to ignore them. Thanks Max > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Sunday, July 17, 2016 1:12 PM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net; Mandy Chung; Valerie Peng > Subject: Re: [9] RFR: 8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > > Why change C_BUILD_DIR to C_BLD_DIR everywhere? > > Can you add the "-addmods m" option into the vmArgs parameter of the getJavaCommand() method? In fact, why must vmArgs be a map instead of a List? Are you worried about the same system property be assigned twice? > > There is no need to generate lists and convert it to array in getTestOutput(), just return what you need, like this: > > return new Object[][] { > {1,2,3}, > {4,5,6}, > }; > > BTW, what's the main reason you rewrite existing tests? > > Thanks > Max > > >> On Jul 15, 2016, at 1:01 AM, Sibabrata Sahoo wrote: >> >> Hi, >> >> Please review the following patch for ?Additional modular test for "auth.login.defaultCallbackHandler" property?. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8151654 >> Webrev: http://cr.openjdk.java.net/~ssahoo/8151654/webrev.00/ >> >> Description: >> A custom callback handler for JAAS can be provided through "auth.login.defaultCallbackHandler" security property. This patch provides test the behavior when the callback handler available in module/class path as modular/regular jar file. >> There are few minor changes over few existing test files due to missing ?-addmods? during runtime for automated module dependency. >> >> Thanks, >> Siba > From rajan.halade at oracle.com Fri Jul 22 17:30:20 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 22 Jul 2016 10:30:20 -0700 Subject: [9] RFR:8160337 Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java In-Reply-To: <5791C1C6.6010505@oracle.com> References: <577CBB97.7040806@oracle.com> <5791C1C6.6010505@oracle.com> Message-ID: <9b604b05-da2f-1b4b-d339-69d658db0f55@oracle.com> Looks good, thanks! Note, I am not OpenJDK reviewer. Thanks, Rajan On 7/21/16 11:48 PM, Tim Du wrote: > Thanks Rajan's comments, > Updated the code here: > http://cr.openjdk.java.net/~tidu/8160337/webrev.01/ ,Please help to > review it again.Thanks. > > Regards > Tim > On 2016/7/7 1:22, Rajan Halade wrote: >> Hi Tim, >> >> Thanks for taking care of this one. Since the test is still using >> random data key "randomness" should be retained. >> >> Thanks, >> Rajan >> >> On 7/6/16 1:04 AM, Tim Du wrote: >>> Hi All, >>> >>> Would you help to review the path for "8160337:Remove intermittent >>> key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java"? >>> JDK-8074580 has been fixed, @key intermittent can be removed.Thanks. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8160337 >>> webrev: http://cr.openjdk.java.net/~tidu/8160337/webrev.00/ >>> >>> Regards >>> Tim >> > From fw at deneb.enyo.de Fri Jul 22 21:22:24 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 22 Jul 2016 23:22:24 +0200 Subject: Kerberos Authentication Issue In-Reply-To: (Carlos Gunners's message of "Thu, 21 Jul 2016 13:48:58 +0100") References: Message-ID: <877fcdwepb.fsf@mid.deneb.enyo.de> * Carlos Gunners: > When I try to connect a java app (tomcat8 container, openjdk-7-jre v 7u101, > debian jessie) to this ldap service via GSSAPI/kerberos using a keytab for > auth, it repeatedly fails .. initially failing to find the service > principal in kerberos via its non-canonical hostname (meaning that the java > app totally ignores rdns setting, and thus does no reverse dns check before > trying to obtain a ticket). Would be a service principal selection based on reverse DNS even secure? From valerie.peng at oracle.com Fri Jul 22 22:19:38 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 22 Jul 2016 15:19:38 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <453e4a0d-e21b-23ec-92b2-3df6ed5ec8ae@oracle.com> References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> <453e4a0d-e21b-23ec-92b2-3df6ed5ec8ae@oracle.com> Message-ID: I added a new test covering the basics of getInstance() methods. Webrev updated: http://cr.openjdk.java.net/~valeriep/8159488/webrev.02 If you have a particular scenario that you want me to cover, please let me know. Thanks, Valerie On 7/21/2016 12:55 PM, Valerie Peng wrote: > > Existing regression tests for the java.xml.crypto do test the > getInstance() methods as I observed during my own testing. > > Maybe not all of them are covered though. I will double check and add > test if necessary... > > Thanks, > > Valerie > > > On 7/21/2016 12:08 PM, Sean Mullan wrote: >> On 07/20/2016 07:57 PM, Valerie Peng wrote: >>> Sean, >>> >>> I have updated webrev to rid the dependency on sun.security.jca >>> packages. Also, I found one additional SecurityPermission is needed. >>> >>> Please find the updated webrev at: >>> http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/ >>> >>> >>> So, we should close JDK-8161710 as a duplicate of JDK-8159488 then? >> >> Yes. The fix looks good. Could you write a simple test which calls >> the getInstance methods with good/bogus algs and providers just to >> make sure they all work as expected? There don't seem to be any >> regression tests for that. >> >> Thanks, >> Sean >> >>> >>> Thanks, >>> Valerie >>> >>> On 7/19/2016 11:57 AM, Sean Mullan wrote: >>>> On 07/18/2016 05:38 PM, Valerie Peng wrote: >>>>> Hi Sean, >>>>> >>>>> I found these two classes in java.xml.crypto module reading local >>>>> files: >>>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java >>>>> >>>>> >>>>> >>>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java >>>>> >>>>> >>>> >>>> I think we should leave it out. The methods that need that permission >>>> are in non-exported packages and are essentially unused. >>>> >>>> Also, you may have noticed, but I just filed >>>> https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would >>>> allow us to remove this permission: >>>> >>>> permission java.lang.RuntimePermission >>>> "accessClassInPackage.sun.security.jca.*"; >>>> >>>> I'm not sure if you have the time to tackle that as part of this >>>> issue, but I think it would be acceptable to fix them together as part >>>> of this issue if so. >>>> >>>> --Sean >>>> >>>>> >>>>> >>>>> >>>>> If you think the File reading permission is not needed for >>>>> java.xml.crypto module, I will remove the corresponding permission >>>>> entry. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 7/18/2016 12:48 PM, Sean Mullan wrote: >>>>>> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>>>>>> Sean, >>>>>>> >>>>>>> Can you please review the following two webrevs? >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >>>>>> >>>>>> Looks good except for this one: >>>>>> >>>>>> 127 // needed for reading Certs >>>>>> 128 permission java.io.FilePermission "<>>>>> FILES>>","read"; >>>>>> >>>>>> Why is that needed? >>>>>> >>>>>>> >>>>>>> While making changes for 8159488, I noticed a problem with my >>>>>>> earlier >>>>>>> putback of 8154191 - the top level Modules.gmk was not integrated. >>>>>>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>>>>>> integrating JDK-8154191. >>>>>>> Can you also review this? It's essentially the same change as >>>>>>> the one >>>>>>> reviewed. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >>>>>> >>>>>> I'll skip this since Mandy already reviewed that one. >>>>>> >>>>>> --Sean >>>>> >>> > From xuelei.fan at oracle.com Mon Jul 25 03:38:40 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Jul 2016 11:38:40 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <57867E0C.7000705@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> Message-ID: <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> Hi Weijun, Please review this update. Per you suggestion, I updated to use CountDownLatch for the synchronization between client and server. CountDownLatch is more simple than ReentrantLock in the context. http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ Thanks, Xuelei On 7/14/2016 1:44 AM, Artem Smotrakov wrote: > Hi Xuelei, > > The webrev looks good to me. Please see inline. > > On 07/12/2016 10:36 PM, Xuelei Fan wrote: >> Thanks for the feedback, Artem. Here is the updated webrev per your >> suggestions: >> >> http://cr.openjdk.java.net/~xuelei/8161106/webrev.02/ >> >> On 7/13/2016 1:03 AM, Artem Smotrakov wrote: >>> Hi Xuelei, >>> >>> I am not an official reviewer, but I have a couple of comments. >>> >>> 1. line 149: would it be better to check this condition in a loop? >>> >> clientCondition.await() will wait for 30 seconds. Need no loop any >> more. If adding a loop, it may become a potential deadloop and cause >> timeout issue. > Right, I didn't get it when I read it first time. >>> 2. Using try-with-resources blocks might simplify doServerSide() a >>> little bit (no need to call close() on sockets, and a couple of "try" >>> blocks might be probably removed) >>> >> I considered to use try-with-resources. But as the lock is introduced. >> and we want to support socket accept timeout, it more convenient to me >> to use the traditional try-finally clauses. > Agree. Using try-with resources would remove one try-finally block, but > probably it would introduce nested "try" blocks. >>> 3. Minor: it might be better to define timeout values as constants with >>> meaningful names. >>> >> Maybe. Normally, if a number is used only once, I may not define a >> field for it. > Sure. >> >>> 4. Minor: lines 268-273 seem to work, but I am wondering if it would be >>> better to use File.separator instead of "/" (someone may run the test on >>> Windows, but without Cygwin). >>> >> I think JDK file I/O would take care of this file separator >> interoperability. It's good to use File.separator, but as the path may >> contains a few separator in test case following this template, for >> example: >> >> pathToStores = "../../../../../javax/net/ssl"; >> >> Using File.separator would not make nice line. > Okay. I am not an expert in Java I/O, so I am not sure. Agree, > File.separator wouldn't make it nicer. >>> 5. SSLSocketSample() constructor, startServer() and startClient() >>> methods: >>> >>> Recently we've had a couple of test issue where no exception was printed >>> on client/server sides. It happened because exceptions were caught and >>> stored, but then tests waited infinitely for another thread to finish. >>> Then, jtreg just killed the tests. As a result, no exception was printed >>> out. It might be better to simplify this code to print out an exception >>> right after it's caught, and then throw a runtime exception if >>> serverException or clientException are not null. Probably there is a >>> side effect that logs may be a little messy sometimes because of lack of >>> synchronization, but maybe something like synchronized(System.out) may >>> help. >>> >> This update should be able to avoid the infinitely waiting. Updated to >> print the exception message right after it is caught. > Thanks. It might be better to print whole stack trace in > srartServer/startClient >>> 6. Minor: it might be better to make class constants uppercase >>> >>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367 >>> >>> >> Good to use uppercase. I plan to modify this template to a overridable >> one so that test case can extend this template. By then, those fields >> will not be declared as constants any more. Let's use the current names >> for a while. > Sure. > > Artem >> >> Thanks, >> Xuelei >> >>> Artem >>> >>> On 07/10/2016 10:16 PM, Xuelei Fan wrote: >>>> There is a nice catch of the timeout miss-match during the handling of >>>> serverIsReady in doClientSide(). Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.01/ >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 7/11/2016 11:44 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review this enhancement of SSLSocket test template: >>>>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.00/ >>>>> >>>>> There are some known issues with the current SSLSocket test template >>>>> (test/javax/net/ssl/templates/SSLSocketTemplate.java) in the >>>>> automation >>>>> testing environment: >>>>> 1. the client or server can be blocked if the peer run into >>>>> problems, as >>>>> may result in intermittent timeout failure. >>>>> 2. the server accepted connection may be not linked to the expected >>>>> client. For example, some other test case may try to use and >>>>> connect to >>>>> a free server socket port, unfortunately this port can be actually >>>>> opened by the server of SSLSocketTemplate because there is no >>>>> synchronization about the free socket port between test cases. >>>>> It's OK >>>>> to run the test singly, but may result in weird intermittent >>>>> failure in >>>>> the automation testing environment. >>>>> >>>>> The new test template in this update considers the noises above. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> > From weijun.wang at oracle.com Mon Jul 25 04:15:26 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Jul 2016 12:15:26 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> Message-ID: <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> Is it possible to use a single new CountDownLatch(2)? Also, I think comments on lines 145-149 and 199-203 are not really necessary, the println() lines after them are quite clear. --Max On 7/25/2016 11:38, Xuelei Fan wrote: > Hi Weijun, > > Please review this update. Per you suggestion, I updated to use > CountDownLatch for the synchronization between client and server. > CountDownLatch is more simple than ReentrantLock in the context. > > http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ > > Thanks, > Xuelei > From xuelei.fan at oracle.com Mon Jul 25 05:14:10 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 25 Jul 2016 13:14:10 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> Message-ID: On 7/25/2016 12:15 PM, Weijun Wang wrote: > Is it possible to use a single new CountDownLatch(2)? > Per the spec, the countDown() release all waiting threads if the count reaches zero, and the await() will not return until the latch has counted down to zero, or interrupted or timeout. It's difficult to use one instance of CountDownLatch(2) for two conditions. > Also, I think comments on lines 145-149 and 199-203 are not really > necessary, the println() lines after them are quite clear. > The comments make the logic easier to understand, I think. Let's keep the comments if it is not a big concern of yours. Thanks, Xuelei > --Max > > On 7/25/2016 11:38, Xuelei Fan wrote: >> Hi Weijun, >> >> Please review this update. Per you suggestion, I updated to use >> CountDownLatch for the synchronization between client and server. >> CountDownLatch is more simple than ReentrantLock in the context. >> >> http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ >> >> Thanks, >> Xuelei >> From weijun.wang at oracle.com Mon Jul 25 05:22:59 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Jul 2016 13:22:59 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> Message-ID: <051486bd-159d-ef4b-486b-f007a9ccb636@oracle.com> On 7/25/2016 13:14, Xuelei Fan wrote: > On 7/25/2016 12:15 PM, Weijun Wang wrote: >> Is it possible to use a single new CountDownLatch(2)? >> > Per the spec, the countDown() release all waiting threads if the count > reaches zero, and the await() will not return until the latch has > counted down to zero, or interrupted or timeout. It's difficult to use > one instance of CountDownLatch(2) for two conditions. Ah, yes. I forgot about that. > >> Also, I think comments on lines 145-149 and 199-203 are not really >> necessary, the println() lines after them are quite clear. >> > The comments make the logic easier to understand, I think. Let's keep > the comments if it is not a big concern of yours. Sure. So everything looks fine to me. Thanks Max > > Thanks, > Xuelei > >> --Max >> >> On 7/25/2016 11:38, Xuelei Fan wrote: >>> Hi Weijun, >>> >>> Please review this update. Per you suggestion, I updated to use >>> CountDownLatch for the synchronization between client and server. >>> CountDownLatch is more simple than ReentrantLock in the context. >>> >>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ >>> >>> Thanks, >>> Xuelei >>> > From weijun.wang at oracle.com Mon Jul 25 08:47:05 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Jul 2016 16:47:05 +0800 Subject: Kerberos Authentication Issue In-Reply-To: References: Message-ID: The JGSS/krb5 provider in jdk7 does not allow "insecure" hostname canonicalization for security reason. (A "secure" canonicalization means the result starts with the input. We still support this for compatibility). This is the reason why you see the service not found error. When -Dsun.security.jgss.native=true is set, the Java provider is not used, and whatever native GSS-API library installed in your system is used. In this case, you should not call JAAS (Krb5LoginModule) to launch JGSS. Instead, please call the JGSS-API directly. --Max On 7/21/2016 20:48, Carlos Gunners wrote: > Hello, > > I have a situation here where we run an ldap service with round-robin > dns .. so, we advertise a cname that resolves to multiple actual > servers. Also, this cnam is not setup as a service principal in kerberos. > > When I try to connect a java app (tomcat8 container, openjdk-7-jre v > 7u101, debian jessie) to this ldap service via GSSAPI/kerberos using a > keytab for auth, it repeatedly fails .. initially failing to find the > service principal in kerberos via its non-canonical hostname (meaning > that the java app totally ignores rdns setting, and thus does no reverse > dns check before trying to obtain a ticket). > > > When I define a JAVA_OPTION '-Dsun.security.jgss.native=true' to > tomcat8, then the failure changes completely to enctype mismatch type of > errors like below : > >> LDAPException(resultCode=82 (local error), errorMessage='An error > occurred while >> attempting to initialize the JAAS login context for GSSAPI > authentication: >> javax.security.auth.login.LoginException: Integrity check on decrypted > field failed (31) - >> PREAUTH_FAILED caused by KrbException: Integrity check on decrypted > field failed (31) - >> PREAUTH_FAILED caused by KrbException: Identifier doesn't match > expected value (906)') > > The logs reveal the correct entypes are being used .. ktlog confirms > that the keytab has the correct entypes .. > > It's worth noting that we have the same application setup and working > exactly like this with openjdk-6-jre v 6b36 on debian squeeze .. > > I have spent so many days trouble-shooting this without success .. > > My questions are: > -- how do I force java to respect rdns settings in krb5.conf, and avoid > all these issues ? > -- what's the best practice way to configure for a service designed in > this way? Or I must define the service principal in kerberos even for a > round-robin presented service? > -- are there any obvious issues I am overlooking ? > > Thanks in advance for suggestions, advice .. > > best regards From svetlana.nikandrova at oracle.com Mon Jul 25 14:59:01 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Mon, 25 Jul 2016 17:59:01 +0300 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: References: <5787AD68.5030107@oracle.com> <5787BF47.8060702@oracle.com> <57892781.3080302@oracle.com> <57892C42.4030506@oracle.com> <578CF871.4040009@oracle.com> Message-ID: <57962935.1000405@oracle.com> Hi Max, yes, comment states that this constructor is only for sub-classes so I've made it protected. Compilation didn't broke (at least in jdk and tests). AFAIK extensionId should never be null, as for extensionValue there are extensions without value (e.g. OCSPNocheck) but in that case value is set to empty byte array. I've reverted checks in equal and hashCode to let NPE be thrown: http://cr.openjdk.java.net/~snikandrova/8054536/webrev.03/ BTW, should I rename bug and review? Current title seems to be irrelevant. Thank you, Svetlana On 18.07.2016 19:09, Wang Weijun wrote: > If the constructor is only meant to be called by a child class, can we just change it to protected? > > Also, if extensionId and extensionValue should never be null, we should focus on not to create an Extension that has one of 2 fields as null. Inside this class, we can add Objects::requireNonNull checks in the 3-arg constructor and the static newExtension method. > > In case we cannot guarantee them to be non-null (For example, a child class has not fill in these 2 fields), I'd rather fail loudly instead of returning null or "null". In my humble opinion, throwing NPE in hashCode and equals is not really a bad thing. > > Thanks > Max > >> On Jul 18, 2016, at 11:40 PM, Svetlana Nikandrova wrote: >> >> Artem, >> >> please see updated review: >> http://cr.openjdk.java.net/~snikandrova/8054536/webrev.02/ >> >> Thanks, >> Svetlana From weijun.wang at oracle.com Mon Jul 25 15:17:58 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 25 Jul 2016 23:17:58 +0800 Subject: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method In-Reply-To: <57962935.1000405@oracle.com> References: <5787AD68.5030107@oracle.com> <5787BF47.8060702@oracle.com> <57892781.3080302@oracle.com> <57892C42.4030506@oracle.com> <578CF871.4040009@oracle.com> <57962935.1000405@oracle.com> Message-ID: <56B9E14B-F226-4853-A291-73A3C6599A3B@oracle.com> Hi Svetlana > http://cr.openjdk.java.net/~snikandrova/8054536/webrev.03/ Change looks fine. One nit: we usually combine the null check and the assignment into a single line. For example, this.x = Objects.requireNonNull(x). > > BTW, should I rename bug and review? Current title seems to be irrelevant. Yes, it's better. Thanks Max > > Thank you, > Svetlana > From sean.mullan at oracle.com Mon Jul 25 15:34:05 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 25 Jul 2016 11:34:05 -0400 Subject: Code Review Request JDK-8161898 Mark the use of deprecated javax.security.cert APIs with forRemoval=true In-Reply-To: References: Message-ID: <24dff81f-6cb9-0d55-08ac-e8123c48a15b@oracle.com> Looks fine to me. --Sean On 07/20/2016 10:32 PM, Xuelei Fan wrote: > Hi, > > javax.security.cert was deprecated and marked with forRemoval=true in > JDK 9. The use of javax.security.cert APIs should be marked with > forRemoval=true too. > > Please review the update: > > http://cr.openjdk.java.net/~xuelei/8161898/webrev.00/ > > Thanks, > Xuelei > From sean.mullan at oracle.com Mon Jul 25 15:49:26 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 25 Jul 2016 11:49:26 -0400 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> <453e4a0d-e21b-23ec-92b2-3df6ed5ec8ae@oracle.com> Message-ID: <23402548-37e9-0a3f-14bb-29ae1a4f9abc@oracle.com> Does the test need to run in othervm? It doesn't seem like it adds or changes the order of providers. Otherwise looks good. --Sean On 07/22/2016 06:19 PM, Valerie Peng wrote: > > I added a new test covering the basics of getInstance() methods. > > Webrev updated: http://cr.openjdk.java.net/~valeriep/8159488/webrev.02 > > If you have a particular scenario that you want me to cover, please let > me know. > Thanks, > Valerie > > On 7/21/2016 12:55 PM, Valerie Peng wrote: >> >> Existing regression tests for the java.xml.crypto do test the >> getInstance() methods as I observed during my own testing. >> >> Maybe not all of them are covered though. I will double check and add >> test if necessary... >> >> Thanks, >> >> Valerie >> >> >> On 7/21/2016 12:08 PM, Sean Mullan wrote: >>> On 07/20/2016 07:57 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> I have updated webrev to rid the dependency on sun.security.jca >>>> packages. Also, I found one additional SecurityPermission is needed. >>>> >>>> Please find the updated webrev at: >>>> http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/ >>>> >>>> >>>> So, we should close JDK-8161710 as a duplicate of JDK-8159488 then? >>> >>> Yes. The fix looks good. Could you write a simple test which calls >>> the getInstance methods with good/bogus algs and providers just to >>> make sure they all work as expected? There don't seem to be any >>> regression tests for that. >>> >>> Thanks, >>> Sean >>> >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 7/19/2016 11:57 AM, Sean Mullan wrote: >>>>> On 07/18/2016 05:38 PM, Valerie Peng wrote: >>>>>> Hi Sean, >>>>>> >>>>>> I found these two classes in java.xml.crypto module reading local >>>>>> files: >>>>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java >>>>>> >>>>>> >>>>>> >>>>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java >>>>>> >>>>>> >>>>> >>>>> I think we should leave it out. The methods that need that permission >>>>> are in non-exported packages and are essentially unused. >>>>> >>>>> Also, you may have noticed, but I just filed >>>>> https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would >>>>> allow us to remove this permission: >>>>> >>>>> permission java.lang.RuntimePermission >>>>> "accessClassInPackage.sun.security.jca.*"; >>>>> >>>>> I'm not sure if you have the time to tackle that as part of this >>>>> issue, but I think it would be acceptable to fix them together as part >>>>> of this issue if so. >>>>> >>>>> --Sean >>>>> >>>>>> >>>>>> >>>>>> >>>>>> If you think the File reading permission is not needed for >>>>>> java.xml.crypto module, I will remove the corresponding permission >>>>>> entry. >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 7/18/2016 12:48 PM, Sean Mullan wrote: >>>>>>> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>>>>>>> Sean, >>>>>>>> >>>>>>>> Can you please review the following two webrevs? >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >>>>>>> >>>>>>> Looks good except for this one: >>>>>>> >>>>>>> 127 // needed for reading Certs >>>>>>> 128 permission java.io.FilePermission "<>>>>>> FILES>>","read"; >>>>>>> >>>>>>> Why is that needed? >>>>>>> >>>>>>>> >>>>>>>> While making changes for 8159488, I noticed a problem with my >>>>>>>> earlier >>>>>>>> putback of 8154191 - the top level Modules.gmk was not integrated. >>>>>>>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>>>>>>> integrating JDK-8154191. >>>>>>>> Can you also review this? It's essentially the same change as >>>>>>>> the one >>>>>>>> reviewed. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >>>>>>> >>>>>>> I'll skip this since Mandy already reviewed that one. >>>>>>> >>>>>>> --Sean >>>>>> >>>> >> > From valerie.peng at oracle.com Tue Jul 26 00:36:23 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 25 Jul 2016 17:36:23 -0700 Subject: [9] RFR 8159488 "Deprivilege java.xml.crypto" and 8161171 "Missed the make/common/Modules.gmk file when integrating JDK-8154191" In-Reply-To: <23402548-37e9-0a3f-14bb-29ae1a4f9abc@oracle.com> References: <5786D860.3080304@oracle.com> <578D32A3.8020307@oracle.com> <578D4C4F.6000101@oracle.com> <0d3d8101-f791-9257-66be-8c97a7eab1af@oracle.com> <453e4a0d-e21b-23ec-92b2-3df6ed5ec8ae@oracle.com> <23402548-37e9-0a3f-14bb-29ae1a4f9abc@oracle.com> Message-ID: <4fe906ff-49aa-e415-87e5-7e8b1a5e2316@oracle.com> Right, it doesn't. I will update it. Thanks, Valerie On 7/25/2016 8:49 AM, Sean Mullan wrote: > Does the test need to run in othervm? It doesn't seem like it adds or > changes the order of providers. > > Otherwise looks good. > > --Sean > > On 07/22/2016 06:19 PM, Valerie Peng wrote: >> >> I added a new test covering the basics of getInstance() methods. >> >> Webrev updated: http://cr.openjdk.java.net/~valeriep/8159488/webrev.02 >> >> If you have a particular scenario that you want me to cover, please let >> me know. >> Thanks, >> Valerie >> >> On 7/21/2016 12:55 PM, Valerie Peng wrote: >>> >>> Existing regression tests for the java.xml.crypto do test the >>> getInstance() methods as I observed during my own testing. >>> >>> Maybe not all of them are covered though. I will double check and add >>> test if necessary... >>> >>> Thanks, >>> >>> Valerie >>> >>> >>> On 7/21/2016 12:08 PM, Sean Mullan wrote: >>>> On 07/20/2016 07:57 PM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> I have updated webrev to rid the dependency on sun.security.jca >>>>> packages. Also, I found one additional SecurityPermission is needed. >>>>> >>>>> Please find the updated webrev at: >>>>> http://cr.openjdk.java.net/~valeriep/8159488/webrev.01/ >>>>> >>>>> >>>>> So, we should close JDK-8161710 as a duplicate of JDK-8159488 then? >>>> >>>> Yes. The fix looks good. Could you write a simple test which calls >>>> the getInstance methods with good/bogus algs and providers just to >>>> make sure they all work as expected? There don't seem to be any >>>> regression tests for that. >>>> >>>> Thanks, >>>> Sean >>>> >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 7/19/2016 11:57 AM, Sean Mullan wrote: >>>>>> On 07/18/2016 05:38 PM, Valerie Peng wrote: >>>>>>> Hi Sean, >>>>>>> >>>>>>> I found these two classes in java.xml.crypto module reading local >>>>>>> files: >>>>>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I think we should leave it out. The methods that need that >>>>>> permission >>>>>> are in non-exported packages and are essentially unused. >>>>>> >>>>>> Also, you may have noticed, but I just filed >>>>>> https://bugs.openjdk.java.net/browse/JDK-8161710. Fixing this would >>>>>> allow us to remove this permission: >>>>>> >>>>>> permission java.lang.RuntimePermission >>>>>> "accessClassInPackage.sun.security.jca.*"; >>>>>> >>>>>> I'm not sure if you have the time to tackle that as part of this >>>>>> issue, but I think it would be acceptable to fix them together as >>>>>> part >>>>>> of this issue if so. >>>>>> >>>>>> --Sean >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> If you think the File reading permission is not needed for >>>>>>> java.xml.crypto module, I will remove the corresponding permission >>>>>>> entry. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 7/18/2016 12:48 PM, Sean Mullan wrote: >>>>>>>> On 07/13/2016 08:10 PM, Valerie Peng wrote: >>>>>>>>> Sean, >>>>>>>>> >>>>>>>>> Can you please review the following two webrevs? >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159488 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8159488/ >>>>>>>> >>>>>>>> Looks good except for this one: >>>>>>>> >>>>>>>> 127 // needed for reading Certs >>>>>>>> 128 permission java.io.FilePermission "<>>>>>>> FILES>>","read"; >>>>>>>> >>>>>>>> Why is that needed? >>>>>>>> >>>>>>>>> >>>>>>>>> While making changes for 8159488, I noticed a problem with my >>>>>>>>> earlier >>>>>>>>> putback of 8154191 - the top level Modules.gmk was not >>>>>>>>> integrated. >>>>>>>>> So, I filed 8161171: Missed the make/common/Modules.gmk file when >>>>>>>>> integrating JDK-8154191. >>>>>>>>> Can you also review this? It's essentially the same change as >>>>>>>>> the one >>>>>>>>> reviewed. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161171 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8161171/webrev.00/ >>>>>>>> >>>>>>>> I'll skip this since Mandy already reviewed that one. >>>>>>>> >>>>>>>> --Sean >>>>>>> >>>>> >>> >> From Xuelei.Fan at Oracle.Com Tue Jul 26 08:29:47 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 26 Jul 2016 16:29:47 +0800 Subject: [9] RFR:8160337 Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java In-Reply-To: <9b604b05-da2f-1b4b-d339-69d658db0f55@oracle.com> References: <577CBB97.7040806@oracle.com> <5791C1C6.6010505@oracle.com> <9b604b05-da2f-1b4b-d339-69d658db0f55@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei > On Jul 23, 2016, at 1:30 AM, Rajan Halade wrote: > > Looks good, thanks! > > Note, I am not OpenJDK reviewer. > > Thanks, > Rajan > >> On 7/21/16 11:48 PM, Tim Du wrote: >> Thanks Rajan's comments, >> Updated the code here: http://cr.openjdk.java.net/~tidu/8160337/webrev.01/ ,Please help to review it again.Thanks. >> >> Regards >> Tim >>> On 2016/7/7 1:22, Rajan Halade wrote: >>> Hi Tim, >>> >>> Thanks for taking care of this one. Since the test is still using random data key "randomness" should be retained. >>> >>> Thanks, >>> Rajan >>> >>>> On 7/6/16 1:04 AM, Tim Du wrote: >>>> Hi All, >>>> >>>> Would you help to review the path for "8160337:Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenerator.java"? JDK-8074580 has been fixed, @key intermittent can be removed.Thanks. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8160337 >>>> webrev: http://cr.openjdk.java.net/~tidu/8160337/webrev.00/ >>>> >>>> Regards >>>> Tim > From sean.mullan at oracle.com Wed Jul 27 13:02:26 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 Jul 2016 09:02:26 -0400 Subject: Code Review Request: JDK-8161506 : Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true Message-ID: Please review this change to mark the pre-1.2 deprecated SecurityManager methods (and 1 field) with forRemoval=true. These methods are no longer necessary and are known to be error-prone and have been deprecated since JDK 1.2. The intention is to remove them in a subsequent release of Java SE. http://cr.openjdk.java.net/~mullan/webrevs/8161506/webrev.00/ Thanks, Sean From xuelei.fan at oracle.com Wed Jul 27 13:53:04 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Jul 2016 21:53:04 +0800 Subject: Code Review Request: JDK-8161506 : Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true In-Reply-To: References: Message-ID: <7e6dd3a9-f96a-9310-0b39-d3f2451831dd@oracle.com> Looks fine to me. Xuelei On 7/27/2016 9:02 PM, Sean Mullan wrote: > Please review this change to mark the pre-1.2 deprecated SecurityManager > methods (and 1 field) with forRemoval=true. These methods are no longer > necessary and are known to be error-prone and have been deprecated since > JDK 1.2. The intention is to remove them in a subsequent release of Java > SE. > > http://cr.openjdk.java.net/~mullan/webrevs/8161506/webrev.00/ > > Thanks, > Sean From coleen.phillimore at oracle.com Wed Jul 27 16:45:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Jul 2016 12:45:21 -0400 Subject: Code Review Request: JDK-8161506 : Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true In-Reply-To: <7e6dd3a9-f96a-9310-0b39-d3f2451831dd@oracle.com> References: <7e6dd3a9-f96a-9310-0b39-d3f2451831dd@oracle.com> Message-ID: This looks great. Thank you! Should we have another bug to actually remove the code and hotspot code for jdk10 and make it blocked by https://bugs.openjdk.java.net/browse/JDK-8162416? thanks, Coleen On 7/27/16 9:53 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 7/27/2016 9:02 PM, Sean Mullan wrote: >> Please review this change to mark the pre-1.2 deprecated SecurityManager >> methods (and 1 field) with forRemoval=true. These methods are no longer >> necessary and are known to be error-prone and have been deprecated since >> JDK 1.2. The intention is to remove them in a subsequent release of Java >> SE. >> >> http://cr.openjdk.java.net/~mullan/webrevs/8161506/webrev.00/ >> >> Thanks, >> Sean From sean.mullan at oracle.com Wed Jul 27 16:52:57 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 Jul 2016 12:52:57 -0400 Subject: Code Review Request: JDK-8161506 : Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true In-Reply-To: References: <7e6dd3a9-f96a-9310-0b39-d3f2451831dd@oracle.com> Message-ID: On 07/27/2016 12:45 PM, Coleen Phillimore wrote: > This looks great. Thank you! > > Should we have another bug to actually remove the code and hotspot code > for jdk10 Yes we should. We need to also do that for all of the other APIs that we have added forRemoval=true to for 9, so I was thinking about creating a single umbrella bug for that, and then using subtasks for each one. --Sean From bradford.wetmore at oracle.com Thu Jul 28 00:39:16 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 27 Jul 2016 17:39:16 -0700 Subject: RFR: 8161527: NPE is thrown if exempt application is bundled with specific cryptoPerms Message-ID: This bug has been around since JDK 5 and likely before. :( If you bundle a specific length cryptoPerms, calls to Cipher with an illegal size key will NPE. The fix in CryptoPermissions is almost exactly the same as what is in java.security.Permissions. I took the liberty of doing a little syntactic cleanup in the file. The only change of note is in the implies() code. https://bugs.openjdk.java.net/browse/JDK-8161527 http://cr.openjdk.java.net/~wetmore/8161527/webrev.00/ Thanks, Brad From bradford.wetmore at oracle.com Thu Jul 28 00:39:22 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 27 Jul 2016 17:39:22 -0700 Subject: RFR: 8161303: Sample NIO Server README needs updating. Message-ID: <3c036333-7c2f-61e9-bb7b-de6f314cde87@oracle.com> A trivial update to the README to remove -source/-target 1.5 in the sample code. https://bugs.openjdk.java.net/browse/JDK-8161303 http://cr.openjdk.java.net/~wetmore/8161303/webrev.00 Thanks, Brad From xuelei.fan at oracle.com Thu Jul 28 01:17:20 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Jul 2016 09:17:20 +0800 Subject: RFR: 8161527: NPE is thrown if exempt application is bundled with specific cryptoPerms In-Reply-To: References: Message-ID: <5fda0258-55c1-847f-c017-b194dc44c811@oracle.com> Looks fine to me. I like the update to use braces. Thanks, Xuelei On 7/28/2016 8:39 AM, Bradford Wetmore wrote: > > This bug has been around since JDK 5 and likely before. :( > > If you bundle a specific length cryptoPerms, calls to Cipher with an > illegal size key will NPE. The fix in CryptoPermissions is almost > exactly the same as what is in java.security.Permissions. > > I took the liberty of doing a little syntactic cleanup in the file. The > only change of note is in the implies() code. > > https://bugs.openjdk.java.net/browse/JDK-8161527 > http://cr.openjdk.java.net/~wetmore/8161527/webrev.00/ > > Thanks, > > Brad > From xuelei.fan at oracle.com Thu Jul 28 01:28:36 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Jul 2016 09:28:36 +0800 Subject: RFR: 8161303: Sample NIO Server README needs updating. In-Reply-To: <3c036333-7c2f-61e9-bb7b-de6f314cde87@oracle.com> References: <3c036333-7c2f-61e9-bb7b-de6f314cde87@oracle.com> Message-ID: <62c70c7d-acde-194a-0105-e05761fa1073@oracle.com> Looks fine to me. Nice catch! Thanks, Xuelei On 7/28/2016 8:39 AM, Bradford Wetmore wrote: > > A trivial update to the README to remove -source/-target 1.5 in the > sample code. > > https://bugs.openjdk.java.net/browse/JDK-8161303 > http://cr.openjdk.java.net/~wetmore/8161303/webrev.00 > > Thanks, > > Brad > > From artem.smotrakov at oracle.com Thu Jul 28 23:36:11 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 28 Jul 2016 16:36:11 -0700 Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout In-Reply-To: <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> References: <5771CEF7.8060400@oracle.com> <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> Message-ID: <67fd1bb2-35d2-2c15-6c76-5133e084b461@oracle.com> Hi Xuelei, I updated CustomDatagramSocketImpl class to be able to drop some packets randomly or by specified numbers. While updating the test, I found https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the root cause of these intermittent failures. I added a couple of PacketLoss* tests to reproduce and verify 8161086. These tests drop different packets while handshaking. They use different cipher suites and modes, so that they take a while. I didn't notice they fail with timeout, but I suspect that may happen on slower machines. That's why I increased timeout value for them. I added the tests to the problem list since 8161086 is not fixed yet. There are a couple of other updates to DTLSOverDatagram.java: - Server tries to receive first application data when it finishes handshaking. Server re-sends final handshaking messages if timeout reached while waiting for application data from client. - Updated client and server to use simple threads instead of thread pools. This way, it's possible to specify meaningful names for threads which makes logs more readable if "-Djavax.net.debug=ssl" specified - Added more logging - Made some fields final At the moment, CustomDatagramSocketImplFactory doesn't drop packets by default because it may cause intermittent failures of tests which are based on DTLSOverDatagram class: ... static class CustomDatagramSocketImplFactory implements DatagramSocketImplFactory { ... // if true, it's going to drop some packets private static boolean dropPackets = false; ... When 8161086 is fixed, it may be set to true by default. Currently the packet loss rate is 5% which I think is much more than if we use UDP sockets on localhost, so that we test DTLS impl in worse conditions. Could you please take a look at updated webrev? http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/ Artem On 06/27/2016 06:25 PM, Xuelei Fan wrote: > On 6/28/2016 9:12 AM, Artem Smotrakov wrote: >> Hello, >> >> Please review this patch for javax/net/ssl/DTLS tests. >> >> A couple of DTLS tests fail intermittently on Mac with timeout or "Too >> many handshake loops ..." error. The tests use UDP to transfer DTLS >> records. It happens sometimes that server cannot receive UDP packets >> with DatagramSocket.receive() method even if client tries to re-send >> them multiple times. Please see logs in the bug. >> >> At the moment, it is not clear why UDP packets can't be delivered to >> server. If someone has seen something similar before, or has some ideas >> what might be the root cause, please let me know. >> > UDP is not reliable. It could happen that the packets get lost. > >> I think that the tests and DTLS implementation are fine here. Since the >> tests are for DTLS, we can workaround this issue by avoiding real UDP >> connections. To avoid changing test logic much, we can use a custom >> DatagramSocketImpl and DatagramSocketImplFactory implementations to >> replace system UDP implementation. >> >> The patch below updates the tests with the following: >> - added custom DatagramSocketImpl and DatagramSocketImplFactory >> implementations to avoid real UDP connections > Tests for real connections in practice are needed. If we update this > test this way, we need to add other tests to test real application > usage. I don't think this is the right direction to avoid real UDP > connections. > >> - added more test output, so that we can have more info it the tests >> fail again >> > I agree with this point. > > Xuelei > >> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac, >> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on >> all supported generic platforms, and they worked fine. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416 >> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/ >> >> Artem From weijun.wang at oracle.com Fri Jul 29 02:11:35 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 29 Jul 2016 10:11:35 +0800 Subject: RFR 8162752: keytool -importkeystore should probe srcstoretype if not specified Message-ID: Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8162752/webrev.00/ for 8162752: keytool -importkeystore should probe srcstoretype if not specified https://bugs.openjdk.java.net/browse/JDK-8162752 Keytool uses 1 flag to manage 2 options, 2 is better. Thanks Max From sean.mullan at oracle.com Fri Jul 29 11:27:16 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 29 Jul 2016 07:27:16 -0400 Subject: RFR 8162752: keytool -importkeystore should probe srcstoretype if not specified In-Reply-To: References: Message-ID: <24e636c2-fea8-12b2-84f1-e95e279c91c2@oracle.com> In the test: 37 // When there is no -srckeystore, it should be probed from the file did you mean to say "no -srcstoretype"? Looks fine otherwise. --Sean On 07/28/2016 10:11 PM, Weijun Wang wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8162752/webrev.00/ > > for > > 8162752: keytool -importkeystore should probe srcstoretype if not > specified > https://bugs.openjdk.java.net/browse/JDK-8162752 > > Keytool uses 1 flag to manage 2 options, 2 is better. > > Thanks > Max From weijun.wang at oracle.com Fri Jul 29 11:41:53 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 29 Jul 2016 19:41:53 +0800 Subject: RFR 8162752: keytool -importkeystore should probe srcstoretype if not specified In-Reply-To: <24e636c2-fea8-12b2-84f1-e95e279c91c2@oracle.com> References: <24e636c2-fea8-12b2-84f1-e95e279c91c2@oracle.com> Message-ID: <19c5bbe1-e086-79bb-a5d5-ae9147163c3e@oracle.com> On 7/29/2016 19:27, Sean Mullan wrote: > In the test: > > 37 // When there is no -srckeystore, it should be probed from > the file > > did you mean to say "no -srcstoretype"? Yes. > > Looks fine otherwise. Thanks Max > > --Sean > From xuelei.fan at oracle.com Fri Jul 29 15:23:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 29 Jul 2016 23:23:15 +0800 Subject: Code Review Request JDK-8162362, Cannot enable previously default enabled cipher suites Message-ID: Hi, Please review the fix for JDK-8162362: http://cr.openjdk.java.net/~xuelei/8162362/webrev.00/ If a cipher suite is getting weak or vulnerable, it is normally removed from the default enabled list in JDK. The compatibility impact of the removing is normally minimal as if there are other available cipher suites enabled. However, some applications may want to support the disabled cipher suites in JDK. If the source code is not accessible, there is not much workaround to have the cipher suite back to work if it is removed from the default enabled list in JDK. This fix introduces two new system properties, which can be used to customize the default enabled cipher suites. The system property "jdk.tls.client.cipherSuites" is used to customize the default enabled cipher suites for client side of SSL/TLS/DTLS connections. Similarly, the system property "jdk.tls.server.cipherSuites" is used for server side. The system property contains a comma-separated list of supported cipher suite names specifying the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite name specified in the property is ignored. Explicit setting of enabled cipher suites will override the system property. Thanks, Xuelei