From Alan.Bateman at oracle.com Sat Jan 2 07:40:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 2 Jan 2016 07:40:44 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <56853BED.2070007@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> Message-ID: <56877EFC.2000505@oracle.com> On 31/12/2015 14:30, Mark Sheppard wrote: > Hi > please oblige and review the current version of the fix for > https://bugs.openjdk.java.net/browse/JDK-8134577 > > at > http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ > > which is based on feedback from the second review. I looked through the latest webrev and I think this is starting to look good. Having the hosts file be the same format (albeit a subset) as /etc/hosts is a big improvement on previous iterations. InetAddress.nameServices is still a List but the List will always have one element, should this be changed to InetAddress.nameService (singular)? I think it would be cleaner if NameService were changed to an interface with two implementations, say PlatformNameService and HostsFileNameService. That way you could eliminate the useLocalHostsFileLookup and hostsFileName fields from InetAddress and HostsFileNameService could encapsulate the parsing of the hosts file rather than NameService trying to support both ways. The property name jdk.net.hosts.file is good but if set to a file that doesn't exist then the current patch falls back to use the platform name service. I assume this is not the original intention. The Scanner is created without specifying a charset, is this deliberate because the platform /etc/hosts is in platform encoding? For tests then it might be better to use UTF-8 because these hosts file will be used on several different platforms. Is there any reason to use legacy StringTokenizer in createAddressByteArray? In other areas of the patch then it using Scanner or String.split so it seems inconsistent to see legacy StringTokenizer in use too. You mentioned in the mail about # supported as a comment when the first character. It doesn't seem to be much effort to just drop everything after the # so that it is more consistent with the platform hosts file. UHE is thrown in a few places without any exception message. For the hosts file then it would be useful to include some message to make configuration issues easier to diagnose. The comment in NameService has a historical reference to the JNDI DNS provider, I assume that is not needed. I also looked through the test changes. Several tests set test.src and not clear that this is needed. I assume that what you really want is: String testSrc = System.getProperty("test.src", "."); addMappingToHostsFile is added to a number of tests. It would be good if this could use try-with-resources to avoid leaving a file open then the write fails (say a test machine with a full file system). sun/security/x509/URICertStore/ExtensionsWithLDAP.java has been added to the exclude list with JDK-8134577 as the issue number. Is there is a different issue number for this? Are all of the tests in test/sun/net/InetAddress/nameservice still needed? Some of these tests, as least in the 'dns' directory, are tests for the JNDI DNS provider and maybe they should be deleted. The update to KDC means that any test using this library will need to run in othervm mode. That may be true already but we should check. Related to this is that setting the system property in the main method might be fragile in that it's possible for code to execute before the main method that triggers the initialization of InetAddress. Something to keep in mind as we might have to re-visit these tests again. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Jan 2 09:41:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 2 Jan 2016 17:41:09 +0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>

<565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com> Message-ID: <8C0A593F-C56B-4790-8483-E9DF7F9442E3@oracle.com> Looks better. One question: the bug description mentions *signed* JARs. Will it be covered? Thanks Max > On Dec 22, 2015, at 2:17 PM, Sibabrata Sahoo wrote: > > Hi Max/Mandy, > > Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.05/ > > I tried to address all the comments bellow. The major change includes abstracting the common behavior to ModularTest.java and extend the rest by each specific test. i.e. SecurityProviderModularTest and JaasModularClientTest. > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Monday, December 21, 2015 7:20 AM > To: Sibabrata Sahoo > Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > Tests are good. Several comments: > > 1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this. > > 2. It's not a good practice extending a class just to use its static fields/methods. Instead, make the util class final. > > public class JaasModularClientTest extends SecurityUtils > public class SecurityProviderModularTest extends SecurityUtils > > In fact, if you do find similarities between SecurityProviderModularTest and JaasModularClientTest, try abstract them into a ModularTest class. > > 3. Please add enough comments to SecurityUtils since it will be reused. For example, move the descriptions of EXPLICIT, AUTO and UNNAMED from test @summary to definition of enum MODULE_TYPE. > > Thanks > Max > > >> On Dec 20, 2015, at 2:10 PM, Sibabrata Sahoo wrote: >> >> Hi Mandy/Max, >> >> Here is the updated webrev with very minor change over previous: >> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/ >> >> Thanks >> Siba >> >> -----Original Message----- >> From: Sibabrata Sahoo >> Sent: Sunday, December 20, 2015 1:34 AM >> To: Mandy Chung; Weijun Wang >> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; >> security-dev at openjdk.java.net >> Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Hi Mandy/Max, >> >> Please review the updated webrev: >> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/ >> >> "3rd party security providers" Test change includes: >> - Test are converted to use TestNG framework. >> - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository. >> - Common reusable operations moved to "SecurityUtils.java" >> - All the following comments associated. >> >> >> Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes: >> - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed. >> - Test converted to use TestNG framework. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Mandy Chung >> Sent: Wednesday, December 09, 2015 11:55 PM >> To: Sibabrata Sahoo >> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; >> security-dev at openjdk.java.net >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Some high-level comment: >> 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. >> 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. >> >> Some comments on JigsawSecurityUtils.java: >> 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); >> >> this can be replaced with >> Arrays.stream(options).collect(Collectors.joining(SPACE)); >> >> 111 System.out.println(String.format( >> >> You can do: System.out.format(?.) instead; >> >> Mandy >> [1] >> http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/ >> jigsaw/reflect/Proxy/ProxyTest.java >> >>> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: >>> >>> Hi Valerie, >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~ntv/siba/webrev.00/ >>> >>> Changes applied as per previous comments. >>> - File names are modified and do not include the term JCE. >>> - Source folder structure is flat now and all belongs to "java/security/Provider" folder. >>> - Sign jar functionality removed. >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Wednesday, December 09, 2015 5:37 AM >>> To: Sibabrata Sahoo >>> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan >>> Bateman >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> Hi Siba, >>> >>> Here are some nits: >>> >>> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. >>> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). >>> You can remove a lot of code as a result. >>> Also, your directory seems a bit deep, e.g. >>> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. >>> >>> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? >>> >>> Thanks, >>> Valerie >>> >>> On 12/8/2015 2:04 PM, Valerie Peng wrote: >>>> Right, that'd be my expectation as well. Sounds like everything works. >>>> I will change to look at your latest webrev. >>>> Valerie >>>> >>>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>>>> Hi Valerie, >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>>>> >>>>> Now the modular behavior for the test works as per expectation >>>>> through JAKE build with the following condition. >>>>> If the provider jar is available under ModulePath then the >>>>> "java.security" file should have the provider configuration entry >>>>> as ProviderName while in case of ClassPath the entry should hold >>>>> the full class name. >>>>> >>>>> Thanks, >>>>> Siba >>>>> >>>>> -----Original Message----- >>>>> From: Valerie Peng >>>>> Sent: Tuesday, December 08, 2015 4:46 AM >>>>> To: Sibabrata Sahoo >>>>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>>>> jigsaw-dev at openjdk.java.net >>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>>> security providers if they are in signed/unsigned modular JARs >>>>> >>>>> Siba, >>>>> >>>>> I have just started to review this webrev and not done yet. >>>>> As for your question, the java.security file in OpenJDK9 still uses >>>>> the provider class names instead of provider names. Are you talking >>>>> about the java.security file in Jigsaw? Which build (OpenJDK or >>>>> Jigsaw) have you tested against. I am pretty sure that I tested the >>>>> 3rd party provider on classpath setting when I worked on the >>>>> 7191662 changes. >>>>> >>>>> Supposedly, if the jar files are available on class path, then you >>>>> should specify its full *class name* in the java.security file for >>>>> it to be instantiated. Otherwise, how would it find the class? Only >>>>> the classes discovered by ServiceLoader can be identified using the >>>>> provider name (which is different from the class name referred >>>>> above). So, in your scenario, that would be >>>>> "provider.TestJCEProvider" instead of "TEST". >>>>> >>>>> If you still run into problems, try enable the java security debug >>>>> flag and u should get a good idea why it isn't loaded. Let me know >>>>> if you still have questions. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>>>> I would like to know more about this. As far, I can see the >>>>>> "java.security" provider configuration available with JDK9, it >>>>>> holds provider names instead of provider class names. In that case >>>>>> how it resolve the fall back? >>>>>> >>>>>> Thanks, >>>>>> Siba >>>>>> >>>>>> -----Original Message----- >>>>>> From: Alan Bateman >>>>>> Sent: Monday, November 30, 2015 4:54 PM >>>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>>>> jigsaw-dev at openjdk.java.net >>>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>>>> security providers if they are in signed/unsigned modular JARs >>>>>> >>>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>>>> >>>>>>> I have one question: >>>>>>> What should be the behavior when the older version of 3rd party >>>>>>> JCE provider jar file(without service descriptor >>>>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>>>> "java.security" file, will be place in CLASS_PATH, running >>>>>>> through >>>>>>> JDK9 and the client is using Security.getProvider() to look for >>>>>>> the provider? >>>>>>> >>>>>>> Currently the scenario fails to find the JCE provider. Is this >>>>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>>>> find the security provider provided through older jar files from >>>>>>> CLASS_PATH. >>>>>>> >>>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>>>> point by falling back and attempting to load the class name >>>>>> specified via the security.provider. properties in the >>>>>> java.security file. I'm sure Valerie can say more about this. >>>>>> >>>>>> -Alan >> > From sibabrata.sahoo at oracle.com Sun Jan 3 06:30:06 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Sat, 2 Jan 2016 22:30:06 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <8C0A593F-C56B-4790-8483-E9DF7F9442E3@oracle.com> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>

<565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com> <8C0A593F-C56B-4790-8483-E9DF7F9442E3@oracle.com> Message-ID: <08c99338-0244-4492-a599-f298636c51f1@default> Hi Max, The test is for verifying 3rd party security provider in classpath/modulepath. I am using an empty provider to check, if the provider can be found during runtime when the bundle provided through classpath/modulepath with different modular type combination. As the provider is empty, I think this is unnecessary to sign the bundle. Even the same comment[1] was also provided by "Valerie" few days ago and the comment was addressed with this webrev, [1] I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Saturday, January 02, 2016 3:11 PM To: Sibabrata Sahoo Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; OpenJDK Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Looks better. One question: the bug description mentions *signed* JARs. Will it be covered? Thanks Max > On Dec 22, 2015, at 2:17 PM, Sibabrata Sahoo wrote: > > Hi Max/Mandy, > > Here is the updated webrev: > http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.05/ > > I tried to address all the comments bellow. The major change includes abstracting the common behavior to ModularTest.java and extend the rest by each specific test. i.e. SecurityProviderModularTest and JaasModularClientTest. > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Monday, December 21, 2015 7:20 AM > To: Sibabrata Sahoo > Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; > security-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security > providers if they are in signed/unsigned modular JARs > > Tests are good. Several comments: > > 1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this. > > 2. It's not a good practice extending a class just to use its static fields/methods. Instead, make the util class final. > > public class JaasModularClientTest extends SecurityUtils > public class SecurityProviderModularTest extends SecurityUtils > > In fact, if you do find similarities between SecurityProviderModularTest and JaasModularClientTest, try abstract them into a ModularTest class. > > 3. Please add enough comments to SecurityUtils since it will be reused. For example, move the descriptions of EXPLICIT, AUTO and UNNAMED from test @summary to definition of enum MODULE_TYPE. > > Thanks > Max > > >> On Dec 20, 2015, at 2:10 PM, Sibabrata Sahoo wrote: >> >> Hi Mandy/Max, >> >> Here is the updated webrev with very minor change over previous: >> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/ >> >> Thanks >> Siba >> >> -----Original Message----- >> From: Sibabrata Sahoo >> Sent: Sunday, December 20, 2015 1:34 AM >> To: Mandy Chung; Weijun Wang >> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; >> security-dev at openjdk.java.net >> Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Hi Mandy/Max, >> >> Please review the updated webrev: >> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/ >> >> "3rd party security providers" Test change includes: >> - Test are converted to use TestNG framework. >> - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository. >> - Common reusable operations moved to "SecurityUtils.java" >> - All the following comments associated. >> >> >> Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes: >> - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed. >> - Test converted to use TestNG framework. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Mandy Chung >> Sent: Wednesday, December 09, 2015 11:55 PM >> To: Sibabrata Sahoo >> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; >> security-dev at openjdk.java.net >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Some high-level comment: >> 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. >> 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. >> >> Some comments on JigsawSecurityUtils.java: >> 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); >> >> this can be replaced with >> Arrays.stream(options).collect(Collectors.joining(SPACE)); >> >> 111 System.out.println(String.format( >> >> You can do: System.out.format(?.) instead; >> >> Mandy >> [1] >> http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk >> / >> jigsaw/reflect/Proxy/ProxyTest.java >> >>> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: >>> >>> Hi Valerie, >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~ntv/siba/webrev.00/ >>> >>> Changes applied as per previous comments. >>> - File names are modified and do not include the term JCE. >>> - Source folder structure is flat now and all belongs to "java/security/Provider" folder. >>> - Sign jar functionality removed. >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Wednesday, December 09, 2015 5:37 AM >>> To: Sibabrata Sahoo >>> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan >>> Bateman >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> Hi Siba, >>> >>> Here are some nits: >>> >>> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. >>> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). >>> You can remove a lot of code as a result. >>> Also, your directory seems a bit deep, e.g. >>> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. >>> >>> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? >>> >>> Thanks, >>> Valerie >>> >>> On 12/8/2015 2:04 PM, Valerie Peng wrote: >>>> Right, that'd be my expectation as well. Sounds like everything works. >>>> I will change to look at your latest webrev. >>>> Valerie >>>> >>>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>>>> Hi Valerie, >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>>>> >>>>> Now the modular behavior for the test works as per expectation >>>>> through JAKE build with the following condition. >>>>> If the provider jar is available under ModulePath then the >>>>> "java.security" file should have the provider configuration entry >>>>> as ProviderName while in case of ClassPath the entry should hold >>>>> the full class name. >>>>> >>>>> Thanks, >>>>> Siba >>>>> >>>>> -----Original Message----- >>>>> From: Valerie Peng >>>>> Sent: Tuesday, December 08, 2015 4:46 AM >>>>> To: Sibabrata Sahoo >>>>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>>>> jigsaw-dev at openjdk.java.net >>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>>> security providers if they are in signed/unsigned modular JARs >>>>> >>>>> Siba, >>>>> >>>>> I have just started to review this webrev and not done yet. >>>>> As for your question, the java.security file in OpenJDK9 still >>>>> uses the provider class names instead of provider names. Are you >>>>> talking about the java.security file in Jigsaw? Which build >>>>> (OpenJDK or >>>>> Jigsaw) have you tested against. I am pretty sure that I tested >>>>> the 3rd party provider on classpath setting when I worked on the >>>>> 7191662 changes. >>>>> >>>>> Supposedly, if the jar files are available on class path, then you >>>>> should specify its full *class name* in the java.security file for >>>>> it to be instantiated. Otherwise, how would it find the class? >>>>> Only the classes discovered by ServiceLoader can be identified >>>>> using the provider name (which is different from the class name >>>>> referred above). So, in your scenario, that would be >>>>> "provider.TestJCEProvider" instead of "TEST". >>>>> >>>>> If you still run into problems, try enable the java security debug >>>>> flag and u should get a good idea why it isn't loaded. Let me >>>>> know if you still have questions. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>>>> I would like to know more about this. As far, I can see the >>>>>> "java.security" provider configuration available with JDK9, it >>>>>> holds provider names instead of provider class names. In that >>>>>> case how it resolve the fall back? >>>>>> >>>>>> Thanks, >>>>>> Siba >>>>>> >>>>>> -----Original Message----- >>>>>> From: Alan Bateman >>>>>> Sent: Monday, November 30, 2015 4:54 PM >>>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>>>> jigsaw-dev at openjdk.java.net >>>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>>>> security providers if they are in signed/unsigned modular JARs >>>>>> >>>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>>>> >>>>>>> I have one question: >>>>>>> What should be the behavior when the older version of 3rd party >>>>>>> JCE provider jar file(without service descriptor >>>>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>>>> "java.security" file, will be place in CLASS_PATH, running >>>>>>> through >>>>>>> JDK9 and the client is using Security.getProvider() to look for >>>>>>> the provider? >>>>>>> >>>>>>> Currently the scenario fails to find the JCE provider. Is this >>>>>>> right behavior? If it is, then jdk9 is not backward compatible >>>>>>> to find the security provider provided through older jar files >>>>>>> from CLASS_PATH. >>>>>>> >>>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>>>> point by falling back and attempting to load the class name >>>>>> specified via the security.provider. properties in the >>>>>> java.security file. I'm sure Valerie can say more about this. >>>>>> >>>>>> -Alan >> > From weijun.wang at oracle.com Sun Jan 3 07:32:17 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 3 Jan 2016 15:32:17 +0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <08c99338-0244-4492-a599-f298636c51f1@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>

<565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com> <8C0A593F-C56B-4790-8483-E9DF7F9442E3@oracle.com> <08c99338-0244-4492-a599-f298636c51f1@default> <0A2B94FD-7468-4169-A676-E55AF20CF5BB@oracle.com> <63548002-8f1e-4c64-a9c5-55df5d27fc7b@default> <43E8BD33-AB62-4A5E-9049-D80193B80DB2@oracle.com> Message-ID: <7effb779-2f60-4058-a312-a17d1d8929d4@default> Hi Valerie, If everything looks fine in the current version of webrev then can you please help me push the changes to JAKE repo. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Monday, January 04, 2016 2:36 PM To: Sibabrata Sahoo Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; OpenJDK Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs I have no more comment. --Max > On Jan 3, 2016, at 3:48 PM, Sibabrata Sahoo wrote: > > Updated the bug title and description. > > Thanks, > Siba > > -----Original Message----- > From: Wang Weijun > Sent: Sunday, January 03, 2016 1:02 PM > To: Sibabrata Sahoo > Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; OpenJDK > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > Then you don't need to include the "signed/unsigned" words in the bug description. > > --Max > >> On Jan 3, 2016, at 2:30 PM, Sibabrata Sahoo wrote: >> >> Hi Max, >> >> The test is for verifying 3rd party security provider in classpath/modulepath. I am using an empty provider to check, if the provider can be found during runtime when the bundle provided through classpath/modulepath with different modular type combination. As the provider is empty, I think this is unnecessary to sign the bundle. >> >> Even the same comment[1] was also provided by "Valerie" few days ago and the comment was addressed with this webrev, >> >> [1] I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). >> >> Thanks, >> Siba > From chris.hegarty at oracle.com Mon Jan 4 14:02:34 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Jan 2016 14:02:34 +0000 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc Message-ID: <568A7B7A.5060001@oracle.com> sun.misc.VM provides a low-level interface for a small number of specific operations with the VM. In preparation for JEP 260, this class should be moved out of sun.misc and located in a non-exported package [. http://cr.openjdk.java.net/~chegar/8145544/00/ Note: as in other areas some tests that require access to internal APIs have been updated to use types from a more stable package, sun.security.x509. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8145544 From sean.mullan at oracle.com Mon Jan 4 14:12:16 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 4 Jan 2016 09:12:16 -0500 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7B7A.5060001@oracle.com> References: <568A7B7A.5060001@oracle.com> Message-ID: <568A7DC0.6090604@oracle.com> On 01/04/2016 09:02 AM, Chris Hegarty wrote: > sun.misc.VM provides a low-level interface for a small number > of specific operations with the VM. In preparation for JEP 260, > this class should be moved out of sun.misc and located in a > non-exported package [. > > http://cr.openjdk.java.net/~chegar/8145544/00/ The security-libs changes look fine to me. > > Note: as in other areas some tests that require access to > internal APIs have been updated to use types from a more > stable package, sun.security.x509. Not sure what you mean - which tests do you mean and why is sun.security.x509 related to this issue? --Sean > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8145544 From weijun.wang at oracle.com Mon Jan 4 14:13:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 4 Jan 2016 22:13:30 +0800 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7B7A.5060001@oracle.com> References: <568A7B7A.5060001@oracle.com> Message-ID: I am OK with the change for krb5 in both src and test. Thanks Max > On Jan 4, 2016, at 10:02 PM, Chris Hegarty wrote: > > sun.misc.VM provides a low-level interface for a small number > of specific operations with the VM. In preparation for JEP 260, > this class should be moved out of sun.misc and located in a > non-exported package [. > > http://cr.openjdk.java.net/~chegar/8145544/00/ > > Note: as in other areas some tests that require access to > internal APIs have been updated to use types from a more > stable package, sun.security.x509. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8145544 From chris.hegarty at oracle.com Mon Jan 4 14:14:12 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Jan 2016 14:14:12 +0000 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7DC0.6090604@oracle.com> References: <568A7B7A.5060001@oracle.com> <568A7DC0.6090604@oracle.com> Message-ID: <568A7E34.8060703@oracle.com> On 04/01/16 14:12, Sean Mullan wrote: > On 01/04/2016 09:02 AM, Chris Hegarty wrote: >> sun.misc.VM provides a low-level interface for a small number >> of specific operations with the VM. In preparation for JEP 260, >> this class should be moved out of sun.misc and located in a >> non-exported package [. >> >> http://cr.openjdk.java.net/~chegar/8145544/00/ > > The security-libs changes look fine to me. Thanks Sean. >> Note: as in other areas some tests that require access to >> internal APIs have been updated to use types from a more >> stable package, sun.security.x509. > > Not sure what you mean - which tests do you mean and why is > sun.security.x509 related to this issue? Not an issue for security, there are a couple of langtools tests that verify that the compiler issues an appropriate warning when internal types are used. These tests used to use sun.misc.VM, I changed them to use types from sun.security.x509. We have done this in a few other placed too. -Chris. > --Sean > >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8145544 From Alan.Bateman at oracle.com Mon Jan 4 14:16:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Jan 2016 14:16:20 +0000 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7B7A.5060001@oracle.com> References: <568A7B7A.5060001@oracle.com> Message-ID: <568A7EB4.4080308@oracle.com> On 04/01/2016 14:02, Chris Hegarty wrote: > sun.misc.VM provides a low-level interface for a small number > of specific operations with the VM. In preparation for JEP 260, > this class should be moved out of sun.misc and located in a > non-exported package [. > > http://cr.openjdk.java.net/~chegar/8145544/00/ > > Note: as in other areas some tests that require access to > internal APIs have been updated to use types from a more > stable package, sun.security.x509. This looks okay to me. There's a few places where importing jdk.internal.misc.VM might be nicer to avoid repeating the fully qualified name - java.lang.Class and java.lang.System are two examples. In passing then I wonder if it's time to drop OSEnvironment, I don't think it has been needed for a long time (the win32 error mode stuff is legacy). -Alan. From sean.mullan at oracle.com Mon Jan 4 14:19:48 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 4 Jan 2016 09:19:48 -0500 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7E34.8060703@oracle.com> References: <568A7B7A.5060001@oracle.com> <568A7DC0.6090604@oracle.com> <568A7E34.8060703@oracle.com> Message-ID: <568A7F84.4060707@oracle.com> On 01/04/2016 09:14 AM, Chris Hegarty wrote: >>> Note: as in other areas some tests that require access to >>> internal APIs have been updated to use types from a more >>> stable package, sun.security.x509. >> >> Not sure what you mean - which tests do you mean and why is >> sun.security.x509 related to this issue? > > > Not an issue for security, there are a couple of langtools tests > that verify that the compiler issues an appropriate warning when > internal types are used. These tests used to use sun.misc.VM, I > changed them to use types from sun.security.x509. We have done > this in a few other placed too. Ah, ok. --Sean From chris.hegarty at oracle.com Mon Jan 4 14:37:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Jan 2016 14:37:54 +0000 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7EB4.4080308@oracle.com> References: <568A7B7A.5060001@oracle.com> <568A7EB4.4080308@oracle.com> Message-ID: <568A83C2.2090807@oracle.com> On 04/01/16 14:16, Alan Bateman wrote: > On 04/01/2016 14:02, Chris Hegarty wrote: >> sun.misc.VM provides a low-level interface for a small number >> of specific operations with the VM. In preparation for JEP 260, >> this class should be moved out of sun.misc and located in a >> non-exported package [. >> >> http://cr.openjdk.java.net/~chegar/8145544/00/ >> >> Note: as in other areas some tests that require access to >> internal APIs have been updated to use types from a more >> stable package, sun.security.x509. > This looks okay to me. Thanks Alan. > There's a few places where importing > jdk.internal.misc.VM might be nicer to avoid repeating the fully > qualified name - java.lang.Class and java.lang.System are two examples. I see these. Integer and few others too. I fixed them and updated the webrev in-place. > In passing then I wonder if it's time to drop OSEnvironment, I don't > think it has been needed for a long time (the win32 error mode stuff is > legacy). Right. If it is ok, I'll file another bug and do the cleanup as a follow up. -Chris. From sean.mullan at oracle.com Mon Jan 4 17:28:58 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 4 Jan 2016 12:28:58 -0500 Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 In-Reply-To: <95db8a25-2e09-4290-9cb5-7212627d53f8@default> References: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default> <56746A84.60106@oracle.com> <95db8a25-2e09-4290-9cb5-7212627d53f8@default> Message-ID: <568AABDA.6070409@oracle.com> On 12/20/2015 11:42 PM, Bhanu Gopularam wrote: > Hi Sean, > > The present fix solves the test issue which is happening in newer Solaris version viz., 11.3/12 which has FIPS guidelines as a prerequisite. > With your permission I shall leave the JDK-8074580 (test stabilization issue) in current state, and would like to continue with fix for public exponent issue as reported in JDK-8129560. > Please let me know. Sure, that is fine. --Sean > > Thank you, > Bhanu > > -----Original Message----- > From: Anthony Scarpino > Sent: Saturday, December 19, 2015 3:34 AM > To: Sean Mullan > Cc: Bhanu Gopularam; security-dev at openjdk.java.net > Subject: Re: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 > > The problems are different. The PKCS11 error means everything in this case. > > Tony > >> On Dec 18, 2015, at 12:20 PM, Sean Mullan wrote: >> >> The fix looks good, although this test is already on the ProblemList due to JDK-8074580. Do you know if that bug is caused by the same issue? The underlying PKCS11 error is different (maybe due to a different Solaris version?), but it looks like an identical stack trace. It would be good to also remove it from the ProblemList and close the other bug if it is a duplicate issue. >> >> --Sean >> >>> On 12/18/2015 12:41 AM, Bhanu Gopularam wrote: >>> Hi all, >>> >>> Please review a fix for following bug: >>> >>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560 >>> >>> Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is >>> failing because RSAKeyGenParameterSpec >>> >>> public exponent is not accordance with FIPS 186-4 guidance >>> >>> Solution ? Used proper value for exponent based on reference from >>> FIPS 186-4, section B-2. >>> >>> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/ >>> >>> Thanks, >>> >>> Bhanu >>> From valerie.peng at oracle.com Mon Jan 4 18:53:54 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 04 Jan 2016 10:53:54 -0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <7effb779-2f60-4058-a312-a17d1d8929d4@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>

<566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> Message-ID: <568AF944.10904@oracle.com> Here are some more comments on the API: * EntropyInput: 29 * An interface of a source of entropy input. "interface" is implied, so you can just say "A source of entropy input." Also, I think this interface should be called "EntropySource". To me, "Input" means the byte array that is already populated, whereas "Source" produces those bytes. A sentence or two with more details in the description would also be helpful. Do we want to allow the generated entropy input to be longer than the size requested (see section 7.1 of sp800-90Ar1)? Perhaps, a method such as: byte[] getFullEntropy(int length) might be more suitable, and specify that a byte array longer than the specified length may be returned. * EntropyNotAvailableException: 37 * Creates one Incomplete sentence. In the class description, add an @see link to EntropyInput.getFullEntropy. * SecureRandomParameters: It seems a little odd to have a class with one parameter that can be optional, and then accepting null as a value in the ctor, which typically will only needed by subclasses. I think it would be nicer to avoid exposing that in the API. Have you considered defining this as an interface, with a static method that returns an instance with an EntropyInput, ex: public interface SecureRandomParameters { EntropyInput getEntropyInput(); static SecureRandomParameters of(EntropyInput); } --Sean On 12/16/2015 02:20 AM, Wang Weijun wrote: > Webrev updated: > > http://cr.openjdk.java.net/~weijun/8051408/webrev.02/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html > > Changes: > > 1. DrbgParameters has a Builder now > > 2. No more default implementation for reseed() > > 3. Synchronization is now inside implementation, on engineXXX() methods > > 4. engineConfigure() now throws InvalidAlgorithmParameterException instead of IllegalArgumentException > > 5. CtrDRBG uses up all input in engineSetSeed() > > Thanks > Max From mark.sheppard at oracle.com Tue Jan 5 00:54:24 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 5 Jan 2016 00:54:24 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <56877EFC.2000505@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> Message-ID: <568B1440.6040404@oracle.com> Hi, as per feedback below webrev has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.06/ change summary: * List nameServices replaced with Nameservice nameService * references to nameServices removed * private interface NameService added, with two implementation PlatformNameService and HostsFileNameService * Scanner created with UTF-8 charset * removed StringTokenizer, replaced with String.split() * comment handling extended, handling comments on line with mapping entry * try with resources added to addMappingToHostsFile method in tests regards Mark On 02/01/2016 07:40, Alan Bateman wrote: > On 31/12/2015 14:30, Mark Sheppard wrote: >> Hi >> please oblige and review the current version of the fix for >> https://bugs.openjdk.java.net/browse/JDK-8134577 >> >> at >> http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ >> >> which is based on feedback from the second review. > I looked through the latest webrev and I think this is starting to > look good. Having the hosts file be the same format (albeit a subset) > as /etc/hosts is a big improvement on previous iterations. > > InetAddress.nameServices is still a List but the List > will always have one element, should this be changed to > InetAddress.nameService (singular)? > > I think it would be cleaner if NameService were changed to an > interface with two implementations, say PlatformNameService and > HostsFileNameService. That way you could eliminate the > useLocalHostsFileLookup and hostsFileName fields from InetAddress and > HostsFileNameService could encapsulate the parsing of the hosts file > rather than NameService trying to support both ways. > > The property name jdk.net.hosts.file is good but if set to a file that > doesn't exist then the current patch falls back to use the platform > name service. I assume this is not the original intention. > > The Scanner is created without specifying a charset, is this > deliberate because the platform /etc/hosts is in platform encoding? > For tests then it might be better to use UTF-8 because these hosts > file will be used on several different platforms. > > Is there any reason to use legacy StringTokenizer in > createAddressByteArray? In other areas of the patch then it using > Scanner or String.split so it seems inconsistent to see legacy > StringTokenizer in use too. > > You mentioned in the mail about # supported as a comment when the > first character. It doesn't seem to be much effort to just drop > everything after the # so that it is more consistent with the platform > hosts file. > > UHE is thrown in a few places without any exception message. For the > hosts file then it would be useful to include some message to make > configuration issues easier to diagnose. > > The comment in NameService has a historical reference to the JNDI DNS > provider, I assume that is not needed. > > I also looked through the test changes. Several tests set test.src and > not clear that this is needed. I assume that what you really want is: > String testSrc = System.getProperty("test.src", "."); > > addMappingToHostsFile is added to a number of tests. It would be good > if this could use try-with-resources to avoid leaving a file open then > the write fails (say a test machine with a full file system). > > sun/security/x509/URICertStore/ExtensionsWithLDAP.java has been added > to the exclude list with JDK-8134577 as the issue number. Is there is > a different issue number for this? > > Are all of the tests in test/sun/net/InetAddress/nameservice still > needed? Some of these tests, as least in the 'dns' directory, are > tests for the JNDI DNS provider and maybe they should be deleted. > > The update to KDC means that any test using this library will need to > run in othervm mode. That may be true already but we should check. > Related to this is that setting the system property in the main method > might be fragile in that it's possible for code to execute before the > main method that triggers the initialization of InetAddress. Something > to keep in mind as we might have to re-visit these tests again. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jan 5 01:17:43 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Jan 2016 09:17:43 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <568AF944.10904@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>

<566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> <568AF944.10904@oracle.com> Message-ID: <2EB14CF3-76B8-4237-A0BE-309A444581E5@oracle.com> > On Jan 5, 2016, at 6:59 AM, Sean Mullan wrote: > > Here are some more comments on the API: > > * EntropyInput: > > 29 * An interface of a source of entropy input. > > "interface" is implied, so you can just say "A source of entropy input." Also, I think this interface should be called "EntropySource". To me, "Input" means the byte array that is already populated, whereas "Source" produces those bytes. A sentence or two with more details in the description would also be helpful. Well, as defined in Section 4 of SP 800-90Ar1, "Entropy Source" means real random source based on a physical device. What we need here is the "Randomness Source" or "Source of entropy input" (section 2 of 800-90B). Shall we call it RandomnessSource? > > Do we want to allow the generated entropy input to be longer than the size requested (see section 7.1 of sp800-90Ar1)? Perhaps, a method such as: > > byte[] getFullEntropy(int length) > > might be more suitable, and specify that a byte array longer than the specified length may be returned. This should be named getEntropy(), because full means every bit of the output contains one bit of entropy. Such a method is OK for most cases, but except for one, CtrDRBG with no derivation function, where the entropy input must be full. Therefore a getFullEntropy() is needed anyway so I just use it everywhere. I also thought that every random source should have a conditioning module to convert non-full entropy bytes to full ones. If this is not true, 2 methods are needed: byte[] getEntropy(int length); void getFullEntropy(byte[] entropy); Detailed descriptions will be added on when and which is used. And I don't think we need to provide any conditioning codes. > > * EntropyNotAvailableException: > > 37 * Creates one > > Incomplete sentence. Will fix it. > > In the class description, add an @see link to EntropyInput.getFullEntropy. > > * SecureRandomParameters: > > It seems a little odd to have a class with one parameter that can be optional, and then accepting null as a value in the ctor, which typically will only needed by subclasses. I think it would be nicer to avoid exposing that in the API. Have you considered defining this as an interface, with a static method that returns an instance with an EntropyInput, ex: > > public interface SecureRandomParameters { > > EntropyInput getEntropyInput(); > > static SecureRandomParameters of(EntropyInput); > } OK. Thanks Max > > --Sean > > On 12/16/2015 02:20 AM, Wang Weijun wrote: >> Webrev updated: >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.02/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html >> >> Changes: >> >> 1. DrbgParameters has a Builder now >> >> 2. No more default implementation for reseed() >> >> 3. Synchronization is now inside implementation, on engineXXX() methods >> >> 4. engineConfigure() now throws InvalidAlgorithmParameterException instead of IllegalArgumentException >> >> 5. CtrDRBG uses up all input in engineSetSeed() >> >> Thanks >> Max From yasuenag at gmail.com Tue Jan 5 13:19:13 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 5 Jan 2016 22:19:13 +0900 Subject: Negative parameter in c'tor of EllipticCurve Message-ID: <568BC2D1.8000506@gmail.com> Hi all, I encountered IllegalArgumentException when I generate EC key pair as below. reproducer: ----------------- import java.math.*; import java.security.*; import java.security.spec.*; import java.security.interfaces.*; public class ECKeyGen{ public static BigInteger P = new BigInteger("900812823637587646514106462588455890498729007071"); public static BigInteger A = new BigInteger("-3"); public static BigInteger B = new BigInteger("366394034647231750324370400222002566844354703832"); public static BigInteger Gx = new BigInteger("264865613959729647018113670854605162895977008838"); public static BigInteger Gy = new BigInteger("51841075954883162510413392745168936296187808697"); public static BigInteger R = new BigInteger("900812823637587646514106555566573588779770753047"); public static void main(String[] args) throws Exception{ EllipticCurve curve = new EllipticCurve(new ECFieldFp(P), A, B); ECParameterSpec spec = new ECParameterSpec(curve, new ECPoint(Gx, Gy), R, 1); KeyPairGenerator keygen = KeyPairGenerator.getInstance("EC"); KeyPair keypair = keygen.generateKeyPair(); ECPrivateKey privateKey = (ECPrivateKey)keypair.getPrivate(); ECPoint publicKey = ((ECPublicKey)keypair.getPublic()).getW(); System.out.println("Private Key: " + privateKey.getS().toString(16)); System.out.println("Public Key:"); System.out.println(" x: " + publicKey.getAffineX().toString(16)); System.out.println(" y: " + publicKey.getAffineY().toString(16)); } } ----------------- console: ----------------- $ /usr/local/jdk1.8.0_66/bin/java ECKeyGen Exception in thread "main" java.lang.IllegalArgumentException: first coefficient is negative at java.security.spec.EllipticCurve.checkValidity(EllipticCurve.java:59) at java.security.spec.EllipticCurve.(EllipticCurve.java:112) at java.security.spec.EllipticCurve.(EllipticCurve.java:83) at ECKeyGen.main(ECKeyGen.java:27) ----------------- I checked this exception with both 8u66 and 9. Cause of this is the "a" parameter is negative value. However, these parameters are based on [1] . I'm not sure about the EC. However, [1] shows negative parameter, and C code which uses OpenSSL does not occur error with same parameters. If JDK implementation is incorrect, I will file it to JBS and create a webrev to avoid the check for negative value. Could you help? Thanks, Yasumasa [1] Advanced Access Content System (AACS) Introduction and Common Cryptographic Elements Table 2-1 - ECC Parameters http://www.aacsla.com/specifications/AACS_Spec_Common_Final_0953.pdf From sean.mullan at oracle.com Tue Jan 5 16:01:02 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Jan 2016 11:01:02 -0500 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <2EB14CF3-76B8-4237-A0BE-309A444581E5@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>

<566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> <568AF944.10904@oracle.com> <2EB14CF3-76B8-4237-A0BE-309A444581E5@oracle.com> Message-ID: <568BE8BE.8010508@oracle.com> On 01/04/2016 08:17 PM, Wang Weijun wrote: > >> On Jan 5, 2016, at 6:59 AM, Sean Mullan >> wrote: >> >> Here are some more comments on the API: >> >> * EntropyInput: >> >> 29 * An interface of a source of entropy input. >> >> "interface" is implied, so you can just say "A source of entropy >> input." Also, I think this interface should be called >> "EntropySource". To me, "Input" means the byte array that is >> already populated, whereas "Source" produces those bytes. A >> sentence or two with more details in the description would also be >> helpful. > > Well, as defined in Section 4 of SP 800-90Ar1, "Entropy Source" means > real random source based on a physical device. What we need here is > the "Randomness Source" or "Source of entropy input" (section 2 of > 800-90B). Ok, but in what cases would you really want someone to use a source that is not based on a physical device? In the default implementation, isn't the only case if the securerandom.source property is not set or is not correct, and then the SHA1PRNG non-device algorithm is used? Perhaps we could have an option which throws an exception and refuses to fall back on that for the DRBG mechanisms. Also, whether it is an approved DRBG implementation seems like a separate testing or compliance issue to me. > Shall we call it RandomnessSource? EntropySource still seems like the best name to me. EntropySource implementations produce entropy :) RandomnessSource may lead to more confusion as to what is the difference between that and SecureRandom. >> Do we want to allow the generated entropy input to be longer than >> the size requested (see section 7.1 of sp800-90Ar1)? Perhaps, a >> method such as: >> >> byte[] getFullEntropy(int length) >> >> might be more suitable, and specify that a byte array longer than >> the specified length may be returned. > > This should be named getEntropy(), because full means every bit of > the output contains one bit of entropy. > > Such a method is OK for most cases, but except for one, CtrDRBG with > no derivation function, where the entropy input must be full. > Therefore a getFullEntropy() is needed anyway so I just use it > everywhere. I also thought that every random source should have a > conditioning module to convert non-full entropy bytes to full ones. > > If this is not true, 2 methods are needed: > > byte[] getEntropy(int length); void getFullEntropy(byte[] entropy); > > Detailed descriptions will be added on when and which is used. > > And I don't think we need to provide any conditioning codes. If you think getFullEntropy is sufficient, then let's just keep the one method. --Sean From mstjohns at comcast.net Tue Jan 5 16:28:04 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 5 Jan 2016 11:28:04 -0500 Subject: Negative parameter in c'tor of EllipticCurve In-Reply-To: <568BC2D1.8000506@gmail.com> References: <568BC2D1.8000506@gmail.com> Message-ID: <568BEF14.9000202@comcast.net> I believe you need to take "a mod p" to get the correct value. If you google for one of the other values in the table, you can find implementations that pre-reduce this and have a value for a that is 3 less than p. BTW - this is generally not the place to ask non-JDK questions. Mike On 1/5/2016 8:19 AM, Yasumasa Suenaga wrote: > Hi all, > > I encountered IllegalArgumentException when I generate EC key pair as below. > > reproducer: > ----------------- > import java.math.*; > import java.security.*; > import java.security.spec.*; > import java.security.interfaces.*; > > > public class ECKeyGen{ > > public static BigInteger P = > new BigInteger("900812823637587646514106462588455890498729007071"); > > public static BigInteger A = new BigInteger("-3"); > > public static BigInteger B = > new BigInteger("366394034647231750324370400222002566844354703832"); > > public static BigInteger Gx = > new BigInteger("264865613959729647018113670854605162895977008838"); > > public static BigInteger Gy = > new BigInteger("51841075954883162510413392745168936296187808697"); > > public static BigInteger R = > new BigInteger("900812823637587646514106555566573588779770753047"); > > public static void main(String[] args) throws Exception{ > EllipticCurve curve = new EllipticCurve(new ECFieldFp(P), A, B); > ECParameterSpec spec = > new ECParameterSpec(curve, new ECPoint(Gx, Gy), R, 1); > > KeyPairGenerator keygen = KeyPairGenerator.getInstance("EC"); > KeyPair keypair = keygen.generateKeyPair(); > > ECPrivateKey privateKey = (ECPrivateKey)keypair.getPrivate(); > ECPoint publicKey = ((ECPublicKey)keypair.getPublic()).getW(); > System.out.println("Private Key: " + privateKey.getS().toString(16)); > System.out.println("Public Key:"); > System.out.println(" x: " + publicKey.getAffineX().toString(16)); > System.out.println(" y: " + publicKey.getAffineY().toString(16)); > } > > } > > ----------------- > > console: > ----------------- > $ /usr/local/jdk1.8.0_66/bin/java ECKeyGen > Exception in thread "main" java.lang.IllegalArgumentException: first coefficient is negative > at java.security.spec.EllipticCurve.checkValidity(EllipticCurve.java:59) > at java.security.spec.EllipticCurve.(EllipticCurve.java:112) > at java.security.spec.EllipticCurve.(EllipticCurve.java:83) > at ECKeyGen.main(ECKeyGen.java:27) > ----------------- > > I checked this exception with both 8u66 and 9. > Cause of this is the "a" parameter is negative value. > However, these parameters are based on [1] . > > I'm not sure about the EC. > However, [1] shows negative parameter, and C code which uses OpenSSL > does not occur error with same parameters. > > If JDK implementation is incorrect, I will file it to JBS and create > a webrev to avoid the check for negative value. > > Could you help? > > > Thanks, > > Yasumasa > > > [1] Advanced Access Content System (AACS) > Introduction and Common Cryptographic Elements > Table 2-1 - ECC Parameters > http://www.aacsla.com/specifications/AACS_Spec_Common_Final_0953.pdf > > From sean.mullan at oracle.com Tue Jan 5 17:21:29 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Jan 2016 12:21:29 -0500 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>

<566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> Message-ID: <568BFB99.8040900@oracle.com> Here are some more comments on the API. I will send some comments on the impl next. * DrbgParameters 38 * A DRBG mechanism should extend this class. Is this sentence necessary? None of the builtin DRBG mechs extend this class. 175 * If this method is not called, the implementation will select 176 * a default {@code EntropyInput}. I think you need to be more specific about what you mean by "the implementation" (and in other methods of this class). It is not the implementation of this class, it is the DRBG SecureRandom implementations. 236 * Requests that a derivation function to be used by the DRBG mechanism. s/to be used/is to be used/ 280 * @return teh newly built {@code DrbgParameters} object s/teh/the/ The get methods should state whether they can return null or not. Some of the methods should be more specific about whether they return or make copies of mutable parameters. * SecureRandomSpi 67 protected SecureRandomSpi() { This seems like an incompatible change to me. The previous version had a default public constructor. I think this needs to be public. 75 * This argument can be {@code null}. Why can't we call the SecureRandomSpi ctor that takes no args when the parameter is null? It seems it would be cleaner to do that, but there is probably a good reason. 109 * @param bytes output. Too terse. How about "the array to be filled in with random bytes" 110 * @param additionalInput additional input. {@code null} if none. I think you should throw NPE if this is null because callers should call engineNextBytes(byte[]) in that case. 110, 134: both of these methods need an @throws UnsupportedOperationException 134 * @param additionalInput additional string, {@code null} if none. I think it would be better to add 2 engineReseed methods, one which takes no arguments and one with an additionalInput arg that throws NPE if it is null. This would also be consistent with the corresponding methods on SecureRandom. * SecureRandom 68 * {@link SecureRandomParameters} parameter. For example, a DRBG 69 * can be initialized with a {@link DrbgParameters} object. s/a DRBG/a DRBG implementation/ 87 *

Except for the one created by {@link #SecureRandom(byte[])}, a newly s/one/instance/ 88 * instantiated SecureRandom object is not seeded. Call one of {@code reseed} 89 * or {@code setSeed} methods to seed it. If none is called, the first call s/Call one of/Call the/ s/methods/method/ s/If none/If neither method/ 92 * at instantiate time through a {@code SecureRandomParameters} object. s/instantiate/instantiation/ (or creation) 94 * This self-seeding will not occur if one of {@code reseed} or {@code setSeed} 95 * methods was previously called. s/one of/the/ s/methods/method/ 97 *

A SecureRandom can be reseeded at any time by calling one of the s/one of the/the/ s/methods/method/ 883 * {@code additionalInput} may contain entropy but its main usage is to 884 * provide diversity. s/entropy but/entropy, its/ --Sean On 12/16/2015 02:20 AM, Wang Weijun wrote: > Webrev updated: > > http://cr.openjdk.java.net/~weijun/8051408/webrev.02/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html > > Changes: > > 1. DrbgParameters has a Builder now > > 2. No more default implementation for reseed() > > 3. Synchronization is now inside implementation, on engineXXX() methods > > 4. engineConfigure() now throws InvalidAlgorithmParameterException instead of IllegalArgumentException > > 5. CtrDRBG uses up all input in engineSetSeed() > > Thanks > Max From usha.seshadri at lmco.com Tue Jan 5 17:28:44 2016 From: usha.seshadri at lmco.com (Seshadri, Usha) Date: Tue, 5 Jan 2016 17:28:44 +0000 Subject: Java security configuration to look at CRL for revocation checking Message-ID: <0F6322F01158F94EBDA664939D5EA15504F4663D@HVXDSP25.us.lmco.com> Hi, I am using Java 8, and am trying to configure JVM to go to CRL for revocation checking. I didn't see any parameter in java.security to enable CRL revocation checking, although there are parameters to configure OCSP. I tried setting these two parameters as JVM options with -D, but doesn't seem to take any effect. deployment.security.validation.crl= true deployment.security.validation.crl.url=file:///root/xyz/crls/ --> points to the CRL directory What configurable property controls the CRL revocation checking? Any answer will be greatly appreciated! Thanks, Usha Seshadri Lockheed Martin, IS&GS 301-240-7496 [LM-logo] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 3520 bytes Desc: image004.jpg URL: From richardl at ufp.com Tue Jan 5 17:35:54 2016 From: richardl at ufp.com (Richard Levenberg) Date: Tue, 5 Jan 2016 09:35:54 -0800 Subject: CallbackHandler updates? Message-ID: <568BFEFA.9040005@ufp.com> Is there any work planned for the javax.security.auth.callback.* package and the provided com.sun.security.auth.callback.TextCallbackHandler? Specifically it would be nice if the readLine method were protected rather than private, and some thought went in to how to extend the class, perhaps unrolling the loop through the array of Callback's. r From sean.mullan at oracle.com Tue Jan 5 18:38:12 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Jan 2016 13:38:12 -0500 Subject: Java security configuration to look at CRL for revocation checking In-Reply-To: <0F6322F01158F94EBDA664939D5EA15504F4663D@HVXDSP25.us.lmco.com> References: <0F6322F01158F94EBDA664939D5EA15504F4663D@HVXDSP25.us.lmco.com> Message-ID: <568C0D94.7050505@oracle.com> On 01/05/2016 12:28 PM, Seshadri, Usha wrote: > Hi, > > I am using Java 8, and am trying to configure JVM to go to CRL for > revocation checking.I didn?t see any parameter in java.security to > enable CRL revocation checking, although there are parameters to > configure OCSP. > > I tried setting these two parameters as JVM options with -D, but doesn?t > seem to take any effect. > > deployment.security.validation.crl= true > > deployment.security.validation.crl.url=file:///root/xyz/crls/ ?points to > the CRL directory These properties are not general JDK system properties. They are specifically used for revocation checking of certificates used when running signed applets via Java Plugin or WebStart. > What configurable property controls the CRL revocation checking? Any > answer will be greatly appreciated! It would be helpful to know what security APIs your application is using, as the JVM itself doesn't perform revocation checking. For example, if you are using JSSE, then setting the following system properties may help address your issue: com.sun.net.ssl.checkRevocation=true com.sun.security.enableCRLDP=true You can find more information and examples in the JSSE reference guide: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html Note that this list is not intended to be a general alias for questions about Java Security, so this question is somewhat off topic. There are various forums/websites that are probably more appropriate. Thanks, Sean > > Thanks, > > Usha Seshadri > > Lockheed Martin, IS&GS > > 301-240-7496 > > LM-logo > From weijun.wang at oracle.com Wed Jan 6 03:37:31 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 6 Jan 2016 11:37:31 +0800 Subject: CallbackHandler updates? In-Reply-To: <568BFEFA.9040005@ufp.com> References: <568BFEFA.9040005@ufp.com> Message-ID: <6F751418-777E-4A8E-90BB-E92742F86019@oracle.com> > On Jan 6, 2016, at 1:35 AM, Richard Levenberg wrote: > > Is there any work planned for the javax.security.auth.callback.* package > and the provided com.sun.security.auth.callback.TextCallbackHandler? No. > > Specifically it would be nice if the readLine method were protected > rather than private, and some thought went in to how to extend the > class, perhaps unrolling the loop through the array of Callback's. You are welcome to contribute any enhancement in this area. Please read the jdk9 change on this class first. Thanks Max > > r From david.holmes at oracle.com Wed Jan 6 04:20:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 14:20:05 +1000 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568A7B7A.5060001@oracle.com> References: <568A7B7A.5060001@oracle.com> Message-ID: <568C95F5.4040101@oracle.com> Hi Chris, Hotspot comment change looks okay.:) I see a lot of hotspot tests that include @modules java.base/sun.misc but I don't understand why it is present in the few cases I looked at eg: hotspot/test/gc/g1/TestShrinkAuxiliaryData15.java so not sure when it needs to be converted to jdk.internal.misc Thanks, David On 5/01/2016 12:02 AM, Chris Hegarty wrote: > sun.misc.VM provides a low-level interface for a small number > of specific operations with the VM. In preparation for JEP 260, > this class should be moved out of sun.misc and located in a > non-exported package [. > > http://cr.openjdk.java.net/~chegar/8145544/00/ > > Note: as in other areas some tests that require access to > internal APIs have been updated to use types from a more > stable package, sun.security.x509. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8145544 From weijun.wang at oracle.com Wed Jan 6 05:05:03 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 6 Jan 2016 13:05:03 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <568BFB99.8040900@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> <566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> <568BFB99.8040900@oracle.com> Message-ID: > On Jan 6, 2016, at 1:21 AM, Sean Mullan wrote: > > Here are some more comments on the API. I will send some comments on the impl next. > > * DrbgParameters > > 38 * A DRBG mechanism should extend this class. > > Is this sentence necessary? None of the builtin DRBG mechs extend this class. I was wrong. > > 175 * If this method is not called, the implementation will select > 176 * a default {@code EntropyInput}. > > I think you need to be more specific about what you mean by "the implementation" (and in other methods of this class). It is not the implementation of this class, it is the DRBG SecureRandom implementations. OK. > > 236 * Requests that a derivation function to be used by the DRBG mechanism. > > s/to be used/is to be used/ > > 280 * @return teh newly built {@code DrbgParameters} object > > s/teh/the/ > > The get methods should state whether they can return null or not. Some of the methods should be more specific about whether they return or make copies of mutable parameters. OK. > > * SecureRandomSpi > > 67 protected SecureRandomSpi() { > > This seems like an incompatible change to me. The previous version had a default public constructor. I think this needs to be public. OK. > > 75 * This argument can be {@code null}. > > Why can't we call the SecureRandomSpi ctor that takes no args when the parameter is null? It seems it would be cleaner to do that, but there is probably a good reason. SecureRandom.getInstance("HashDRBG") will call new HashDrbg(null), which calls a series of super(null) until SecureRandomSpi. The @implSpec of the class has more details. I can revisit the change in Provider.java. Maybe the following will work: if (param == null) { findCtorWithNoArg().newInstance(); } else { findCtorWithArg(argClazz).newInstance(param); } > > 109 * @param bytes output. > > Too terse. How about "the array to be filled in with random bytes" OK. > > 110 * @param additionalInput additional input. {@code null} if none. > > I think you should throw NPE if this is null because callers should call engineNextBytes(byte[]) in that case. OK. I'll need to implement engineNextBytes(1,2) and engineNextBytes(1) in all implementations and probably let them call something like nextBytesInternal(). > > 110, 134: both of these methods need an @throws UnsupportedOperationException OK. > > 134 * @param additionalInput additional string, {@code null} if none. > > I think it would be better to add 2 engineReseed methods, one which takes no arguments and one with an additionalInput arg that throws NPE if it is null. This would also be consistent with the corresponding methods on SecureRandom. OK. > > * SecureRandom > > 68 * {@link SecureRandomParameters} parameter. For example, a DRBG > 69 * can be initialized with a {@link DrbgParameters} object. > > s/a DRBG/a DRBG implementation/ > > 87 *

Except for the one created by {@link #SecureRandom(byte[])}, a newly > > s/one/instance/ > > 88 * instantiated SecureRandom object is not seeded. Call one of {@code reseed} > 89 * or {@code setSeed} methods to seed it. If none is called, the first call > > s/Call one of/Call the/ > s/methods/method/ > s/If none/If neither method/ > > 92 * at instantiate time through a {@code SecureRandomParameters} object. > > s/instantiate/instantiation/ (or creation) > > 94 * This self-seeding will not occur if one of {@code reseed} or {@code setSeed} > 95 * methods was previously called. > > s/one of/the/ > s/methods/method/ > > 97 *

A SecureRandom can be reseeded at any time by calling one of the > > s/one of the/the/ > s/methods/method/ > > 883 * {@code additionalInput} may contain entropy but its main usage is to > 884 * provide diversity. > > s/entropy but/entropy, its/ OK. Thanks Max > > --Sean > > On 12/16/2015 02:20 AM, Wang Weijun wrote: >> Webrev updated: >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.02/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html >> >> Changes: >> >> 1. DrbgParameters has a Builder now >> >> 2. No more default implementation for reseed() >> >> 3. Synchronization is now inside implementation, on engineXXX() methods >> >> 4. engineConfigure() now throws InvalidAlgorithmParameterException instead of IllegalArgumentException >> >> 5. CtrDRBG uses up all input in engineSetSeed() >> >> Thanks >> Max From weijun.wang at oracle.com Wed Jan 6 05:08:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 6 Jan 2016 13:08:09 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <568BE8BE.8010508@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> <566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> <568AF944.10904@oracle.com> <2EB14CF3-76B8-4237-A0BE-309A444581E5@oracle.com> <568BE8BE.8010508@oracle.com> Message-ID: > On Jan 6, 2016, at 12:01 AM, Sean Mullan wrote: > > If you think getFullEntropy is sufficient, then let's just keep the one method. I thought about this more and we can actually do /** * An interface of a source of entropy input. *

* This interface has 2 methods returning byte arrays containing entropy. * The result of {@link #getFullEntropy} contains full entropy and that of * {@link #getEntropy} contains the request amount of entropy but might not * be full. The default implementation of the methods inside this interface * are dependent on each other. An implementation must implement at least * one of them to be useful. * * @since 1.9 */ public interface EntropyInput { /** * Fills a byte array with full entropy. *

* This method might block and/or fail. * * @implSpec The default implementation calls {@link #getEntropy} * to return a byte array which might not have full entropy, and then * calls the hashdf conditioning function defined in NIST SP 800-90Ar1 * 10.3.1 to condense it into an array with full entropy. * * @param entropy the byte array with filled entropy. * @throws EntropyNotAvailableException if not enough entropy is available. */ default void getFullEntropy(byte[] entropy) { byte[] raw = getEntropy(entropy.length); if (raw.length != entropy.length) { try { MessageDigest md = MessageDigest.getInstance("SHA-256", "SUN"); raw = HashDrbg.hashDf(md, md.getDigestLength(), entropy.length, raw); } catch (Exception e) { throw new InternalError(e); } } System.arraycopy(raw, 0, entropy, 0, raw.length); } /** * Returns a byte array with at least length*8 bits of entropy. *

* This method might block and/or fail. * * @implSpec The default implementation calls {@link #getFullEntropy} * to return a byte array which has full entropy. * * @param length the minimum size of entropy requested in bytes * @return a byte array containing entropy * @throws EntropyNotAvailableException if not enough entropy is available. */ default byte[] getEntropy(int length) { byte[] result = new byte[length]; getFullEntropy(result); return result; } } From chris.hegarty at oracle.com Wed Jan 6 06:10:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Jan 2016 06:10:39 +0000 Subject: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc In-Reply-To: <568C95F5.4040101@oracle.com> References: <568A7B7A.5060001@oracle.com> <568C95F5.4040101@oracle.com> Message-ID: <42EE23DC-1CD2-4816-949A-0EC4875909F5@oracle.com> On 6 Jan 2016, at 04:20, David Holmes wrote: > Hi Chris, > > Hotspot comment change looks okay.:) Thanks David. > I see a lot of hotspot tests that include > > @modules java.base/sun.misc > > but I don't understand why it is present in the few cases I looked at eg: > > hotspot/test/gc/g1/TestShrinkAuxiliaryData15.java The dependency on sun.misc is coming from the test library, specifically jdk.test.lib.Utils. Quite a few tests in the hotspot repo use the test library, so have this dependency ( on sun.misc.Unsafe ). > so not sure when it needs to be converted to jdk.internal.misc It is on my list to update these tests, see 8140608 [1]. I punted doing this with the Unsafe move, as I was unhappy with the test coverage of sun.misc.Unsafe. Paul has since added some additional tests [2] that have variants that cover both jdk.internal.misc.Unsafe and sun.misc.Unsafe, so I think the hotspot tests can now be updated to only use jdk.internal.misc. I?ll move 8140608 forward over the next few weeks. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8140608 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d84bd22ab531 > Thanks, > David > > On 5/01/2016 12:02 AM, Chris Hegarty wrote: >> sun.misc.VM provides a low-level interface for a small number >> of specific operations with the VM. In preparation for JEP 260, >> this class should be moved out of sun.misc and located in a >> non-exported package [. >> >> http://cr.openjdk.java.net/~chegar/8145544/00/ >> >> Note: as in other areas some tests that require access to >> internal APIs have been updated to use types from a more >> stable package, sun.security.x509. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8145544 From ecki at zusammenkunft.net Wed Jan 6 07:31:37 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Wed, 6 Jan 2016 08:31:37 +0100 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> <566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> <568AF944.10904@oracle.com> <2EB14CF3-76B8-4237-A0BE-309A444581E5@oracle.com> <568BE8BE.8010508@oracle.com> Message-ID: Hello, is the Intention of the default implementation of getFullEntropy to expand a too short array with the DF as well (which is a dangerous thing to do IMHO) or is the conditional conditioning only to condense (aka shorten)? In that case you should maybe add an assert and make the if compare against bigger length only? (On the other hand I wonder why not simly discarding the bytes would be fine, too. I dont see an implementation providing excessive bytes anyway. Why not have a int fillEntropy (byte [] out, boolean partial (, int pos, int len)) methods instead? (This also avoids the need to exlain "full" as well as "get". When partial is false the method is guranteed to throw if not enough entropy is available and by not creating arrays it cannot create exceeding bytes. The default impl for the pos/len is to call fillEntropy(out, partial, 0, out.length). It might not be needed hoewever. Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Wang Weijun To: Sean Mullan Cc: OpenJDK Dev list Sent: Mi., 06 Jan. 2016 6:19 Subject: Re: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations > On Jan 6, 2016, at 12:01 AM, Sean Mullan wrote: > > If you think getFullEntropy is sufficient, then let's just keep the one method. I thought about this more and we can actually do /** * An interface of a source of entropy input. *

> * This interface has 2 methods returning byte arrays containing entropy. > * The result of {@link #getFullEntropy} contains full entropy and that of > * {@link #getEntropy} contains the request amount of entropy but might not > * be full. The default implementation of the methods inside this interface > * are dependent on each other. An implementation must implement at least > * one of them to be useful. > * > * @since 1.9 > */ > public interface EntropyInput { > /** > * Fills a byte array with full entropy. > *

> * This method might block and/or fail. > * > * @implSpec The default implementation calls {@link #getEntropy} > * to return a byte array which might not have full entropy, and then > * calls the hashdf conditioning function defined in NIST SP 800-90Ar1 > * 10.3.1 to condense it into an array with full entropy. > * > * @param entropy the byte array with filled entropy. > * @throws EntropyNotAvailableException if not enough entropy is available. > */ > default void getFullEntropy(byte[] entropy) { > byte[] raw = getEntropy(entropy.length); > if (raw.length != entropy.length) { > try { > MessageDigest md = MessageDigest.getInstance("SHA-256", "SUN"); > raw = HashDrbg.hashDf(md, md.getDigestLength(), > entropy.length, raw); > } catch (Exception e) { > throw new InternalError(e); > } > } > System.arraycopy(raw, 0, entropy, 0, raw.length); > } > > /** > * Returns a byte array with at least length*8 bits of entropy. > *