From xuelei.fan at oracle.com Tue Nov 1 00:36:11 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 1 Nov 2016 08:36:11 +0800 Subject: RFR: 4985694: Incomplete spec for most of the getInstances In-Reply-To: <12091979-f821-1ace-829b-dcce2cd6133b@oracle.com> References: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> <6587c593-466f-d681-5880-6cb6ccd00584@oracle.com> <12091979-f821-1ace-829b-dcce2cd6133b@oracle.com> Message-ID: <6ee6dc6a-8bf9-65d0-1216-d98bf0ee80a7@oracle.com> Looks fine to me. Thanks, Xuelei On 11/1/2016 5:19 AM, Bradford Wetmore wrote: > Here's the latest, and have checked in: > > https://bugs.openjdk.java.net/browse/JDK-4985694 > http://cr.openjdk.java.net/~wetmore/4985694/webrev.01/ > >>> Egads, good catch. I completely missed this one. I will put in >>> Objects.requireNonNull throughout. >>> >>> Cipher.java is the one weird one, null or empty gets the same exception. > > Updated both Mac and Cipher to throw upon entrance. > > Thanks for the reviews. > > Brad > > > On 10/30/2016 10:56 AM, Sean Mullan wrote: >> Looks good to me. >> >> --Sean >> >> On 10/28/2016 08:17 PM, Bradford Wetmore wrote: >>> Egads, good catch. I completely missed this one. I will put in >>> Objects.requireNonNull throughout. >>> >>> Cipher.java is the one weird one, null or empty gets the same exception. >>> >>> Brad >>> >>> >>> >>> On 10/28/2016 5:13 PM, Xuelei Fan wrote: >>>> Looks fine to me. >>>> >>>> For the update in Mac.java, I may prefer to check the null parameter >>>> explicitly as earlier as possible instead of delegate to the further >>>> calls (GetInstance.getServices()). Similar comment to Cipher.java. >>>> Not >>>> an issue, just a preference. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 10/29/2016 3:06 AM, Bradford Wetmore wrote: >>>>> >>>>> Hi, >>>>> >>>>> I need a review for this P2 TCK-RED-9 bug. >>>>> >>>>> The original request (JDK-8166350) was for documenting null algorithm >>>>> names in the 3 new DRBG getInstances() in SecureRandom, but there is a >>>>> 12 year old bug for the same thing throughout the >>>>> JCA/JCE/JSSE/JGSS/JAAS. I've gone ahead and fixed. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-4985694 >>>>> http://cr.openjdk.java.net/~wetmore/4985694/webrev.00/ >>>>> >>>>> Other comments: >>>>> >>>>> . Instead of waiting for a NP to be generated by the code, added a >>>>> hardcoded NPE parameter sanity check: >>>>> >>>>> Objects.requireNonNull(algorithm, "null algorithm name"); >>>>> >>>>> . verified APIs to ensure proper exceptions are thrown for null/empty >>>>> algorithm/provider Strings and null Providers. >>>>> >>>>> . Added a full test suite for all getInstances to check for above, >>>>> including a reflection check for future getInstances. >>>>> >>>>> . Some minor javadoc cleanup/reorgs, mainly to the >>>>> @returns/@throws/@exceptions tags (e.g. {@code >>>>> ...}/alphabetizing/ending >>>>> "." on phrases} for consistency and to conform to current javadoc >>>>> standards. I've tried to be consistent throughout (@code's around >>>>> class >>>>> names}, but I know I have missed a couple things here/there (no >>>>> @code's >>>>> around parameter names). I do need to move onto other things. >>>>> >>>>> Thanks, >>>>> >>>>> Brad From sergei.kovalev at oracle.com Tue Nov 1 17:15:37 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 1 Nov 2016 20:15:37 +0300 Subject: RFR(s): 8169002: [TESTBUG] Several java/net/httpclient have undeclared dependency on java.logging module Message-ID: Hello all, Please review a small fix for tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8169002 WebRev: http://cr.openjdk.java.net/~skovalev/8169002/webrev.00/ Issue: Several tests from java/net/httpclient folder have undeclared dependency on java.logging module. This issue leads the test to fail in case module limitation. Solution: added module declaration into jtreg header and organized imports. -- With best regards, Sergei From artem.smotrakov at oracle.com Tue Nov 1 23:35:13 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 1 Nov 2016 16:35:13 -0700 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar Message-ID: Hello, Please review this small update for keytool. "keytool -printcert -jarfile" doesn't work with jars which were signed with algorithms listed in "jdk.jar.disabledAlgorithms" security property. The patch below resets "jdk.jar.disabledAlgorithms" security property before reading a jar file, and prints a warning. I also re-wrote readjar.sh test, and added SecurityTools class with a couple of re-usable methods for jarsigner and keytool (those methods are based on methods from TimestampCheck.java). Bug: https://bugs.openjdk.java.net/browse/JDK-8168882 Webrev: http://cr.openjdk.java.net/~asmotrak/8168882/webrev.00/ Artem From artem.smotrakov at oracle.com Wed Nov 2 00:54:50 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 1 Nov 2016 17:54:50 -0700 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate Message-ID: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> Hello, Please review the following patch which merges a couple of classes in javax/net/ssl/templates. SSLTest class contains re-usable parts of SSLSocketSample. SSLSocketTemplate class is buggy (tests which follows it may fail intermittently). I basically replaced SSLSocketTemplate with SSLTest, and removed SSLSocketSample. SSL/TLS tests should use SSLSocketTemplate class. I updated test which use SSLTest to use SSLSocketTemplate. Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ Artem From sha.jiang at oracle.com Wed Nov 2 06:48:36 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 2 Nov 2016 14:48:36 +0800 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> Message-ID: <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> Hi Artem, Thanks for making the template to be used easily. The tests in your patch extend class SSLSocketTemplate, but SSLSocketTemplate looks like an utility class, but not a parent class. For example, test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java 67 new SSLSocketTemplate() AnonCipherWithWantClientAuth still creates a SSLSocketTemplate instance, but not itself. In fact, if replacing "print()" with "SSLSocketTemplate.print()", AnonCipherWithWantClientAuth can work fine without extending SSLSocketTemplate. The original SSLSocketSample.java defines the core methods, such as doServerSide(), runServerApplication(), doClientSide() and runClientApplication(), as non-static. In my eyes, this style may be better. The child class can simply override the methods if necessary. In addition, some tests have to configure SSLServerSocket. Why not provide one more extension point in doServerSide()? Then, it unnecessary to re-write the whole doServerSide() (or, set a new server peer). The code talks more clearly. Please take a look at my example: http://cr.openjdk.java.net/~jjiang/8168969/example/ Best regards, John Jiang On 2016/11/2 8:54, Artem Smotrakov wrote: > Hello, > > Please review the following patch which merges a couple of classes in > javax/net/ssl/templates. > > SSLTest class contains re-usable parts of SSLSocketSample. > SSLSocketTemplate class is buggy (tests which follows it may fail > intermittently). I basically replaced SSLSocketTemplate with SSLTest, > and removed SSLSocketSample. > > SSL/TLS tests should use SSLSocketTemplate class. I updated test which > use SSLTest to use SSLSocketTemplate. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 > Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ > > Artem > From weijun.wang at oracle.com Wed Nov 2 06:59:31 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Nov 2016 14:59:31 +0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: References: Message-ID: Main.java: The warning (and the subsequent empty line) should be printed into System.err. Resources.java: "This tool accepts any algorithm" is a little confusing (sorry that I originally suggested it). Maybe "This tool does not attempt to verify a signed jar file, please run \"jarsigner -verify\" if you want to." Also, ever since the 1st time hard coded strings are changed into dot-connected resource keys, newly added keys do not necessarily use the exact same string. Make it simple so next time if the value needs to be updated you don't need to change the key. Test: - You can also add -Duser.language=en and -Duser.country=US to keytool. - With my recent update to JarUtils.createJar(), there is no need to create the "test" file. Everything else looks fine. Thanks Max > On Nov 2, 2016, at 7:35 AM, Artem Smotrakov wrote: > > Hello, > > Please review this small update for keytool. > > "keytool -printcert -jarfile" doesn't work with jars which were signed with algorithms listed in "jdk.jar.disabledAlgorithms" security property. > > The patch below resets "jdk.jar.disabledAlgorithms" security property before reading a jar file, and prints a warning. > > I also re-wrote readjar.sh test, and added SecurityTools class with a couple of re-usable methods for jarsigner and keytool (those methods are based on methods from TimestampCheck.java). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168882 > Webrev: http://cr.openjdk.java.net/~asmotrak/8168882/webrev.00/ > > Artem From weijun.wang at oracle.com Wed Nov 2 07:27:20 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Nov 2016 15:27:20 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: Ping again. There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. Thanks Max > On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: > > Please review the enhancement at > > http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ > > Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before. > > Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks. > > Thanks > Max From jamil.j.nimeh at oracle.com Wed Nov 2 07:30:23 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 2 Nov 2016 00:30:23 -0700 Subject: RFR 8133632: javax.net.ssl.SSLEngine does not properly handle received SSL fatal alerts Message-ID: <41c1ac45-1feb-0039-d143-b4b3f3a60eaa@oracle.com> Hello folks, This fixes an issue in SSLEngine that happens when an engine unwraps a TLS fatal alert record. The resulting engine state still leaves both input and output queues in an open state, and in NEED_UNWRAP. Unwrapping just causes the exception thrown as a result of processing the exception to be thrown again. This fix updates the resulting state of the engine in this particular case to have both I/O queues closed and updates the state of the engine to NOT_HANDSHAKING. Bug: https://bugs.openjdk.java.net/browse/JDK-8133632 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8133632/webrev.01/ Thanks, --Jamil From xuelei.fan at oracle.com Wed Nov 2 08:56:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 16:56:15 +0800 Subject: RFR 8133632: javax.net.ssl.SSLEngine does not properly handle received SSL fatal alerts In-Reply-To: <41c1ac45-1feb-0039-d143-b4b3f3a60eaa@oracle.com> References: <41c1ac45-1feb-0039-d143-b4b3f3a60eaa@oracle.com> Message-ID: <7c7c39e5-b732-321f-ab23-7c4dea5dffe1@oracle.com> Looks fine to me exception that you may also want to consider the case: 1850 if (description == -1) { // check for short message 1851 fatal(Alerts.alert_illegal_parameter, "Short alert message"); 1852 } If the level is not warning, please don't sent the alert any more at line 1851 (via fatal()). Xuelei On 11/2/2016 3:30 PM, Jamil Nimeh wrote: > Hello folks, > > This fixes an issue in SSLEngine that happens when an engine unwraps a > TLS fatal alert record. The resulting engine state still leaves both > input and output queues in an open state, and in NEED_UNWRAP. Unwrapping > just causes the exception thrown as a result of processing the exception > to be thrown again. > > This fix updates the resulting state of the engine in this particular > case to have both I/O queues closed and updates the state of the engine > to NOT_HANDSHAKING. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133632 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8133632/webrev.01/ > > Thanks, > --Jamil From xuelei.fan at oracle.com Wed Nov 2 09:34:53 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 17:34:53 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: 1. More specific "A SecureRandom service provider can advertise that it is thread-safe by setting the service provider attribute "ThreadSafe" to "true" when registering the provider." A service provider may contains many services implementations. May need to be more specific to set "ThreadSafe" for SecureRandom only, rather the full provider is thread safe. For example: map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); Otherwise, a service provider need to make sure all services are thread safe, or all services implementation are not thread safe. 2. "true" is the only true property value. "If this attribute is not set or is "false", this class will instead ..." If the attribute is set to "yes" or "hello, world!", I think it is the same as set to "false" per your current implementation. "Otherwise, this class will ... " May need to update the implementation accordingly if you accept the comments. Xuelei On 11/2/2016 3:27 PM, Wang Weijun wrote: > Ping again. > > There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. > > Thanks > Max > >> On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: >> >> Please review the enhancement at >> >> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >> >> Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before. >> >> Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks. >> >> Thanks >> Max > From xuelei.fan at oracle.com Wed Nov 2 10:57:20 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 18:57:20 +0800 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> Message-ID: <93642848-56fe-6362-85ed-0d3d7bdeefbb@oracle.com> Please use JDK 6 only features (no Lambda, try-with-resource, multi-catch, java.util.Objects, etc.) so as to expedite porting to previous releases. It would be nice if removing the part to declare the store files in each sub-classes. Xuelei On 11/2/2016 2:48 PM, John Jiang wrote: > Hi Artem, > Thanks for making the template to be used easily. > > The tests in your patch extend class SSLSocketTemplate, but > SSLSocketTemplate looks like an utility class, but not a parent class. > For example, > test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java > 67 new SSLSocketTemplate() > AnonCipherWithWantClientAuth still creates a SSLSocketTemplate instance, > but not itself. > In fact, if replacing "print()" with "SSLSocketTemplate.print()", > AnonCipherWithWantClientAuth can work fine without extending > SSLSocketTemplate. > > The original SSLSocketSample.java defines the core methods, such as > doServerSide(), runServerApplication(), doClientSide() and > runClientApplication(), as non-static. In my eyes, this style may be > better. The child class can simply override the methods if necessary. > > In addition, some tests have to configure SSLServerSocket. Why not > provide one more extension point in doServerSide()? Then, it unnecessary > to re-write the whole doServerSide() (or, set a new server peer). > The code talks more clearly. Please take a look at my example: > http://cr.openjdk.java.net/~jjiang/8168969/example/ > > Best regards, > John Jiang > > On 2016/11/2 8:54, Artem Smotrakov wrote: >> Hello, >> >> Please review the following patch which merges a couple of classes in >> javax/net/ssl/templates. >> >> SSLTest class contains re-usable parts of SSLSocketSample. >> SSLSocketTemplate class is buggy (tests which follows it may fail >> intermittently). I basically replaced SSLSocketTemplate with SSLTest, >> and removed SSLSocketSample. >> >> SSL/TLS tests should use SSLSocketTemplate class. I updated test which >> use SSLTest to use SSLSocketTemplate. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >> >> Artem >> > From weijun.wang at oracle.com Wed Nov 2 12:47:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Nov 2016 20:47:45 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> > On Nov 2, 2016, at 5:34 PM, Xuelei Fan wrote: > > 1. More specific > > "A SecureRandom service provider can advertise that it is > thread-safe by setting the service provider attribute > "ThreadSafe" to "true" when registering the provider." > > A service provider may contains many services implementations. May need to be more specific to set "ThreadSafe" for SecureRandom only, rather the full provider is thread safe. For example: > > map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); > > Otherwise, a service provider need to make sure all services are thread safe, or all services implementation are not thread safe. How about changing "A SecureRandom service provider" to "A SecureRandom implementation"? > > 2. "true" is the only true property value. > "If this attribute is not set or is "false", this class will > instead ..." > > If the attribute is set to "yes" or "hello, world!", I think it is the same as set to "false" per your current implementation. > > "Otherwise, this class will ... " OK. > > May need to update the implementation accordingly if you accept the comments. Why update the implementation? Thanks Max > > Xuelei > > > On 11/2/2016 3:27 PM, Wang Weijun wrote: >> Ping again. >> >> There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. >> >> Thanks >> Max >> >>> On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: >>> >>> Please review the enhancement at >>> >>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>> >>> Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before. >>> >>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks. >>> >>> Thanks >>> Max >> From xuelei.fan at oracle.com Wed Nov 2 13:18:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 21:18:18 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> References: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> Message-ID: On 11/2/2016 8:47 PM, Wang Weijun wrote: > >> On Nov 2, 2016, at 5:34 PM, Xuelei Fan wrote: >> >> 1. More specific >> >> "A SecureRandom service provider can advertise that it is >> thread-safe by setting the service provider attribute >> "ThreadSafe" to "true" when registering the provider." >> >> A service provider may contains many services implementations. May need to be more specific to set "ThreadSafe" for SecureRandom only, rather the full provider is thread safe. For example: >> >> map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); >> >> Otherwise, a service provider need to make sure all services are thread safe, or all services implementation are not thread safe. > > How about changing "A SecureRandom service provider" to "A SecureRandom implementation"? > I don't think it is sufficient. See bellow. >> >> 2. "true" is the only true property value. >> "If this attribute is not set or is "false", this class will >> instead ..." >> >> If the attribute is set to "yes" or "hello, world!", I think it is the same as set to "false" per your current implementation. >> >> "Otherwise, this class will ... " > > OK. > >> >> May need to update the implementation accordingly if you accept the comments. > > Why update the implementation? > If I'm reading correct, you are setting the "ThreadSafe" for provider, but not for SecureRandom implementation. I may use the property similar to: map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); That's why I don't think above update is not sufficient. Xuelei > Thanks > Max > >> >> Xuelei >> >> >> On 11/2/2016 3:27 PM, Wang Weijun wrote: >>> Ping again. >>> >>> There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. >>> >>> Thanks >>> Max >>> >>>> On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: >>>> >>>> Please review the enhancement at >>>> >>>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>>> >>>> Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before. >>>> >>>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks. >>>> >>>> Thanks >>>> Max >>> > From weijun.wang at oracle.com Wed Nov 2 13:33:54 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Nov 2016 21:33:54 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> Message-ID: <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> > On Nov 2, 2016, at 9:18 PM, Xuelei Fan wrote: > > On 11/2/2016 8:47 PM, Wang Weijun wrote: >> >>> On Nov 2, 2016, at 5:34 PM, Xuelei Fan wrote: >>> >>> 1. More specific >>> >>> "A SecureRandom service provider can advertise that it is >>> thread-safe by setting the service provider attribute >>> "ThreadSafe" to "true" when registering the provider." >>> >>> A service provider may contains many services implementations. May need to be more specific to set "ThreadSafe" for SecureRandom only, rather the full provider is thread safe. For example: >>> >>> map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); >>> >>> Otherwise, a service provider need to make sure all services are thread safe, or all services implementation are not thread safe. >> >> How about changing "A SecureRandom service provider" to "A SecureRandom implementation"? >> > I don't think it is sufficient. See bellow. > >>> >>> 2. "true" is the only true property value. >>> "If this attribute is not set or is "false", this class will >>> instead ..." >>> >>> If the attribute is set to "yes" or "hello, world!", I think it is the same as set to "false" per your current implementation. >>> >>> "Otherwise, this class will ... " >> >> OK. >> >>> >>> May need to update the implementation accordingly if you accept the comments. >> >> Why update the implementation? >> > If I'm reading correct, you are setting the "ThreadSafe" for provider, but not for SecureRandom implementation. Sorry but I don't understand what you mean. On read side, the threadSafe field is for each "SecureRandom." + algorithm, so it is for an implementation. On write side, every call looks like the line you write below. > I may use the property similar to: > > map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); > > That's why I don't think above update is not sufficient. Can you point out on exactly which line in webrev I'm doing wrong? Thanks Max > > Xuelei > >> Thanks >> Max >> >>> >>> Xuelei >>> >>> >>> On 11/2/2016 3:27 PM, Wang Weijun wrote: >>>> Ping again. >>>> >>>> There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: >>>>> >>>>> Please review the enhancement at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>>>> >>>>> Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before. >>>>> >>>>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks. >>>>> >>>>> Thanks >>>>> Max From xuelei.fan at oracle.com Wed Nov 2 13:45:07 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 21:45:07 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> References: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> Message-ID: <7ede2a5b-9fec-9769-4c4a-78252ac47a54@oracle.com> Oops, I was mis-reading with the following code. 990 super(token.provider, type, algorithm, className, toList(al), 991 type.equals(SR) ? Map.of("ThreadSafe", "true") : null); OK, it's fine. Xuelei On 11/2/2016 9:33 PM, Wang Weijun wrote: >> I may use the property similar to: >> >> map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); From xuelei.fan at oracle.com Wed Nov 2 13:50:44 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 21:50:44 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> References: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> Message-ID: On 11/2/2016 9:33 PM, Wang Weijun wrote: >> >>> >> >>> 1. More specific >> >>> >> >>> "A SecureRandom service provider can advertise that it is >> >>> thread-safe by setting the service provider attribute >> >>> "ThreadSafe" to "true" when registering the provider." >> >>> >> >>> A service provider may contains many services implementations. May need to be more specific to set "ThreadSafe" for SecureRandom only, rather the full provider is thread safe. For example: >> >>> >> >>> map.put("SecureRandom.SHA1PRNG ThreadSafe", "true"); >> >>> >> >>> Otherwise, a service provider need to make sure all services are thread safe, or all services implementation are not thread safe. >>> >>> How about changing "A SecureRandom service provider" to "A SecureRandom implementation"? I may change "the service provider attribute" to "the service attribute". A SecureRandom service provider can advertise that the implementation is thread-safe by setting the service attribute "ThreadSafe" to "true" when registering the provider. Xuelei From weijun.wang at oracle.com Wed Nov 2 13:58:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Nov 2016 21:58:45 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> Message-ID: > ? 2016?11?2??21:50?Xuelei Fan ??? > > I may change "the service provider attribute" to "the service attribute". I didn't invent that name, I remember it's named exactly like this in one of the security guides. Will check tomorrow, not near a big screen now. Thanks Max From xuelei.fan at oracle.com Wed Nov 2 14:00:04 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Nov 2016 22:00:04 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: <6191FA49-F575-457E-BDEF-8F6BDD36A001@oracle.com> <744E5628-CD11-4C1A-8B68-EEB118BE08FF@oracle.com> Message-ID: Not a big concern of mine. Please go ahead if you would like. Xuelei On 11/2/2016 9:58 PM, Wang Weijun wrote: > > >> ? 2016?11?2??21:50?Xuelei Fan ??? >> >> I may change "the service provider attribute" to "the service attribute". > > I didn't invent that name, I remember it's named exactly like this in one of the security guides. Will check tomorrow, not near a big screen now. > > Thanks > Max > > From artem.smotrakov at oracle.com Wed Nov 2 15:54:52 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 2 Nov 2016 08:54:52 -0700 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> Message-ID: <1bfb0c53-43ce-396d-3811-8c32b2d577fe@oracle.com> Hi John, Please see inline. On 11/01/2016 11:48 PM, John Jiang wrote: > Hi Artem, > Thanks for making the template to be used easily. > > The tests in your patch extend class SSLSocketTemplate, but > SSLSocketTemplate looks like an utility class, but not a parent class. > For example, > test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java > 67 new SSLSocketTemplate() > AnonCipherWithWantClientAuth still creates a SSLSocketTemplate > instance, but not itself. > In fact, if replacing "print()" with "SSLSocketTemplate.print()", > AnonCipherWithWantClientAuth can work fine without extending > SSLSocketTemplate. Correct, AnonCipherWithWantClientAuth can work fine without extending SSLSocketTemplate. I make those classes to extend SSLSocketTemplate to make lines shorter (we keep lines shorter than 80 symbols). > > The original SSLSocketSample.java defines the core methods, such as > doServerSide(), runServerApplication(), doClientSide() and > runClientApplication(), as non-static. In my eyes, this style may be > better. The child class can simply override the methods if necessary. I think it may be better to keep them static which also means stateless here. It would be easier to re-use in my opinion. > > In addition, some tests have to configure SSLServerSocket. Why not > provide one more extension point in doServerSide()? Then, it > unnecessary to re-write the whole doServerSide() (or, set a new server > peer). I see your point, and agree with that. I would prefer to add this extension when we update a test which really needs it. If you have such a bug, please feel free to do that. We have more than one hundred SSL/TLS tests, and they may need some other extensions. I am not sure that it's possible to provide a universal SSLSocketTemplate which fits all test's needs. Artem > The code talks more clearly. Please take a look at my example: > http://cr.openjdk.java.net/~jjiang/8168969/example/ > > Best regards, > John Jiang > > On 2016/11/2 8:54, Artem Smotrakov wrote: >> Hello, >> >> Please review the following patch which merges a couple of classes in >> javax/net/ssl/templates. >> >> SSLTest class contains re-usable parts of SSLSocketSample. >> SSLSocketTemplate class is buggy (tests which follows it may fail >> intermittently). I basically replaced SSLSocketTemplate with SSLTest, >> and removed SSLSocketSample. >> >> SSL/TLS tests should use SSLSocketTemplate class. I updated test >> which use SSLTest to use SSLSocketTemplate. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >> >> Artem >> > From artem.smotrakov at oracle.com Wed Nov 2 16:14:00 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 2 Nov 2016 09:14:00 -0700 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <93642848-56fe-6362-85ed-0d3d7bdeefbb@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> <93642848-56fe-6362-85ed-0d3d7bdeefbb@oracle.com> Message-ID: Hi Xuelei, This totally makes sense. But in my opinion we should use new features and APIs because: - they are here to make code readable (okay, not to much lambdas) - they help to avoid bugs (e.g., forgetting to close resources) - we implicitly provide test coverage for new APIs - we give examples how these features can be used - finally, we encourage people to move to new Java versions Not sure if I got correction what you mean by removing the part to declare the store files in each sub-classes. Do you mean getting rid of setting keystore/truststore in actual test files? If so, I would prefer to do it in a separate enhancement. Most of SSL/TLS tests use keystores from "etc" directory. The test use "test.src" system property (set by jtreg) to build a path to "etc", and it depends on actual directory where a test stays. Also if I recall correctly, some tests use their own keystore. This update may be quite big. Would you mind if we did it separately? 8168969 is about merging helper classes to remove possible confusions Brad mentioned recently. Artem On 11/02/2016 03:57 AM, Xuelei Fan wrote: > Please use JDK 6 only features (no Lambda, try-with-resource, > multi-catch, java.util.Objects, etc.) so as to expedite porting to > previous releases. > > It would be nice if removing the part to declare the store files in > each sub-classes. > > Xuelei > > On 11/2/2016 2:48 PM, John Jiang wrote: >> Hi Artem, >> Thanks for making the template to be used easily. >> >> The tests in your patch extend class SSLSocketTemplate, but >> SSLSocketTemplate looks like an utility class, but not a parent class. >> For example, >> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >> 67 new SSLSocketTemplate() >> AnonCipherWithWantClientAuth still creates a SSLSocketTemplate instance, >> but not itself. >> In fact, if replacing "print()" with "SSLSocketTemplate.print()", >> AnonCipherWithWantClientAuth can work fine without extending >> SSLSocketTemplate. >> >> The original SSLSocketSample.java defines the core methods, such as >> doServerSide(), runServerApplication(), doClientSide() and >> runClientApplication(), as non-static. In my eyes, this style may be >> better. The child class can simply override the methods if necessary. >> >> In addition, some tests have to configure SSLServerSocket. Why not >> provide one more extension point in doServerSide()? Then, it unnecessary >> to re-write the whole doServerSide() (or, set a new server peer). >> The code talks more clearly. Please take a look at my example: >> http://cr.openjdk.java.net/~jjiang/8168969/example/ >> >> Best regards, >> John Jiang >> >> On 2016/11/2 8:54, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review the following patch which merges a couple of classes in >>> javax/net/ssl/templates. >>> >>> SSLTest class contains re-usable parts of SSLSocketSample. >>> SSLSocketTemplate class is buggy (tests which follows it may fail >>> intermittently). I basically replaced SSLSocketTemplate with SSLTest, >>> and removed SSLSocketSample. >>> >>> SSL/TLS tests should use SSLSocketTemplate class. I updated test which >>> use SSLTest to use SSLSocketTemplate. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >>> >>> Artem >>> >> From jamil.j.nimeh at oracle.com Thu Nov 3 00:13:35 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 2 Nov 2016 17:13:35 -0700 Subject: RFR 8133632: javax.net.ssl.SSLEngine does not properly handle received SSL fatal alerts In-Reply-To: <7c7c39e5-b732-321f-ab23-7c4dea5dffe1@oracle.com> References: <41c1ac45-1feb-0039-d143-b4b3f3a60eaa@oracle.com> <7c7c39e5-b732-321f-ab23-7c4dea5dffe1@oracle.com> Message-ID: <1c5e73f2-77a3-92d0-7f8f-303262707b22@oracle.com> Good suggestion. Updated webrev below: http://cr.openjdk.java.net/~jnimeh/reviews/8133632/webrev.02/ On 11/2/2016 1:56 AM, Xuelei Fan wrote: > Looks fine to me exception that you may also want to consider the case: > > 1850 if (description == -1) { // check for short message > 1851 fatal(Alerts.alert_illegal_parameter, "Short alert message"); > 1852 } > > If the level is not warning, please don't sent the alert any more at > line 1851 (via fatal()). > > Xuelei > > On 11/2/2016 3:30 PM, Jamil Nimeh wrote: >> Hello folks, >> >> This fixes an issue in SSLEngine that happens when an engine unwraps a >> TLS fatal alert record. The resulting engine state still leaves both >> input and output queues in an open state, and in NEED_UNWRAP. Unwrapping >> just causes the exception thrown as a result of processing the exception >> to be thrown again. >> >> This fix updates the resulting state of the engine in this particular >> case to have both I/O queues closed and updates the state of the engine >> to NOT_HANDSHAKING. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133632 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8133632/webrev.01/ >> >> Thanks, >> --Jamil From artem.smotrakov at oracle.com Thu Nov 3 00:27:23 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 2 Nov 2016 17:27:23 -0700 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: References: Message-ID: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> Hi Max, Please see inline. On 11/01/2016 11:59 PM, Wang Weijun wrote: > Main.java: > > The warning (and the subsequent empty line) should be printed into System.err. > > Resources.java: > > "This tool accepts any algorithm" is a little confusing (sorry that I originally suggested it). Maybe "This tool does not attempt to verify a signed jar file, please run \"jarsigner -verify\" if you want to." Sure, I'll update the message. > > Also, ever since the 1st time hard coded strings are changed into dot-connected resource keys, newly added keys do not necessarily use the exact same string. Make it simple so next time if the value needs to be updated you don't need to change the key. Agree, I was thinking about shorter key, but then noticed that most of keys look like messages. I'll make the key shorter. > > Test: > > - You can also add -Duser.language=en and -Duser.country=US to keytool. Makes sense to me, will do. > > - With my recent update to JarUtils.createJar(), there is no need to create the "test" file. Right. I'll remove it, however creating a file would make it a bit clearer to me. Thank you for review Max, please take a look at updated webrev: http://cr.openjdk.java.net/~asmotrak/8168882/webrev.01/ By the way, I just noticed that we have another version of JarUtils.java which was added by Alan 7 month ago http://hg.openjdk.java.net/jdk9/dev/jdk/log/1396fb6d0279/test/lib/testlibrary/JarUtils.java Artem > > Everything else looks fine. > > Thanks > Max > > >> On Nov 2, 2016, at 7:35 AM, Artem Smotrakov wrote: >> >> Hello, >> >> Please review this small update for keytool. >> >> "keytool -printcert -jarfile" doesn't work with jars which were signed with algorithms listed in "jdk.jar.disabledAlgorithms" security property. >> >> The patch below resets "jdk.jar.disabledAlgorithms" security property before reading a jar file, and prints a warning. >> >> I also re-wrote readjar.sh test, and added SecurityTools class with a couple of re-usable methods for jarsigner and keytool (those methods are based on methods from TimestampCheck.java). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168882 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8168882/webrev.00/ >> >> Artem From xuelei.fan at oracle.com Thu Nov 3 00:35:07 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 3 Nov 2016 08:35:07 +0800 Subject: RFR 8133632: javax.net.ssl.SSLEngine does not properly handle received SSL fatal alerts In-Reply-To: <1c5e73f2-77a3-92d0-7f8f-303262707b22@oracle.com> References: <41c1ac45-1feb-0039-d143-b4b3f3a60eaa@oracle.com> <7c7c39e5-b732-321f-ab23-7c4dea5dffe1@oracle.com> <1c5e73f2-77a3-92d0-7f8f-303262707b22@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 11/3/2016 8:13 AM, Jamil Nimeh wrote: > Good suggestion. Updated webrev below: > > http://cr.openjdk.java.net/~jnimeh/reviews/8133632/webrev.02/ > > On 11/2/2016 1:56 AM, Xuelei Fan wrote: >> Looks fine to me exception that you may also want to consider the case: >> >> 1850 if (description == -1) { // check for short message >> 1851 fatal(Alerts.alert_illegal_parameter, "Short alert message"); >> 1852 } >> >> If the level is not warning, please don't sent the alert any more at >> line 1851 (via fatal()). >> >> Xuelei >> >> On 11/2/2016 3:30 PM, Jamil Nimeh wrote: >>> Hello folks, >>> >>> This fixes an issue in SSLEngine that happens when an engine unwraps a >>> TLS fatal alert record. The resulting engine state still leaves both >>> input and output queues in an open state, and in NEED_UNWRAP. Unwrapping >>> just causes the exception thrown as a result of processing the exception >>> to be thrown again. >>> >>> This fix updates the resulting state of the engine in this particular >>> case to have both I/O queues closed and updates the state of the engine >>> to NOT_HANDSHAKING. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133632 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8133632/webrev.01/ >>> >>> Thanks, >>> --Jamil > From sha.jiang at oracle.com Thu Nov 3 00:36:44 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 3 Nov 2016 08:36:44 +0800 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <1bfb0c53-43ce-396d-3811-8c32b2d577fe@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> <1bfb0c53-43ce-396d-3811-8c32b2d577fe@oracle.com> Message-ID: Hi Artem, On 2016/11/2 23:54, Artem Smotrakov wrote: > Hi John, > > Please see inline. > > > On 11/01/2016 11:48 PM, John Jiang wrote: >> Hi Artem, >> Thanks for making the template to be used easily. >> >> The tests in your patch extend class SSLSocketTemplate, but >> SSLSocketTemplate looks like an utility class, but not a parent class. >> For example, >> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >> 67 new SSLSocketTemplate() >> AnonCipherWithWantClientAuth still creates a SSLSocketTemplate >> instance, but not itself. >> In fact, if replacing "print()" with "SSLSocketTemplate.print()", >> AnonCipherWithWantClientAuth can work fine without extending >> SSLSocketTemplate. > Correct, AnonCipherWithWantClientAuth can work fine without extending > SSLSocketTemplate. > > I make those classes to extend SSLSocketTemplate to make lines shorter > (we keep lines shorter than 80 symbols). In practice, you could divide one line to two lines if the line length is greater than 80. >> >> The original SSLSocketSample.java defines the core methods, such as >> doServerSide(), runServerApplication(), doClientSide() and >> runClientApplication(), as non-static. In my eyes, this style may be >> better. The child class can simply override the methods if necessary. > I think it may be better to keep them static which also means > stateless here. It would be easier to re-use in my opinion. >> >> In addition, some tests have to configure SSLServerSocket. Why not >> provide one more extension point in doServerSide()? Then, it >> unnecessary to re-write the whole doServerSide() (or, set a new >> server peer). > I see your point, and agree with that. I would prefer to add this > extension when we update a test which really needs it. If you have > such a bug, please feel free to do that. The test AnonCipherWithWantClientAuth.java in your patch looks need this extension. > > We have more than one hundred SSL/TLS tests, and they may need some > other extensions. I am not sure that it's possible to provide a > universal SSLSocketTemplate which fits all test's needs. I see. It's unnecessary to design too much before getting more concrete requirements. Best regards, John Jiang > > Artem >> The code talks more clearly. Please take a look at my example: >> http://cr.openjdk.java.net/~jjiang/8168969/example/ >> >> Best regards, >> John Jiang >> >> On 2016/11/2 8:54, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review the following patch which merges a couple of classes >>> in javax/net/ssl/templates. >>> >>> SSLTest class contains re-usable parts of SSLSocketSample. >>> SSLSocketTemplate class is buggy (tests which follows it may fail >>> intermittently). I basically replaced SSLSocketTemplate with >>> SSLTest, and removed SSLSocketSample. >>> >>> SSL/TLS tests should use SSLSocketTemplate class. I updated test >>> which use SSLTest to use SSLSocketTemplate. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >>> >>> Artem >>> >> > > From artem.smotrakov at oracle.com Thu Nov 3 00:48:12 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 2 Nov 2016 17:48:12 -0700 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> <1bfb0c53-43ce-396d-3811-8c32b2d577fe@oracle.com> Message-ID: <160e4427-3a9f-c43c-e8ed-b555e4ff8efc@oracle.com> Hi John, On 11/02/2016 05:36 PM, John Jiang wrote: > Correct, AnonCipherWithWantClientAuth can work fine without extending > SSLSocketTemplate. >> >> I make those classes to extend SSLSocketTemplate to make lines >> shorter (we keep lines shorter than 80 symbols). > In practice, you could divide one line to two lines if the line length > is greater than 80. Correct. Extending SSLSocketTemplate allows not to mention class name when you call a static method which makes lines shorter. > >>> >>> The original SSLSocketSample.java defines the core methods, such as >>> doServerSide(), runServerApplication(), doClientSide() and >>> runClientApplication(), as non-static. In my eyes, this style may be >>> better. The child class can simply override the methods if necessary. >> I think it may be better to keep them static which also means >> stateless here. It would be easier to re-use in my opinion. >>> >>> In addition, some tests have to configure SSLServerSocket. Why not >>> provide one more extension point in doServerSide()? Then, it >>> unnecessary to re-write the whole doServerSide() (or, set a new >>> server peer). >> I see your point, and agree with that. I would prefer to add this >> extension when we update a test which really needs it. If you have >> such a bug, please feel free to do that. > The test AnonCipherWithWantClientAuth.java in your patch looks need > this extension. This update is about merging files in javax/net/ssl/template to avoid confusions Brad mentioned recently. I would prefer to implement other enhancements separately. This may also eliminate some confusions. > >> >> We have more than one hundred SSL/TLS tests, and they may need some >> other extensions. I am not sure that it's possible to provide a >> universal SSLSocketTemplate which fits all test's needs. > I see. It's unnecessary to design too much before getting more > concrete requirements. Agree. Please see above. Artem > > > Best regards, > John Jiang > >> >> Artem >>> The code talks more clearly. Please take a look at my example: >>> http://cr.openjdk.java.net/~jjiang/8168969/example/ >>> >>> Best regards, >>> John Jiang >>> >>> On 2016/11/2 8:54, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review the following patch which merges a couple of classes >>>> in javax/net/ssl/templates. >>>> >>>> SSLTest class contains re-usable parts of SSLSocketSample. >>>> SSLSocketTemplate class is buggy (tests which follows it may fail >>>> intermittently). I basically replaced SSLSocketTemplate with >>>> SSLTest, and removed SSLSocketSample. >>>> >>>> SSL/TLS tests should use SSLSocketTemplate class. I updated test >>>> which use SSLTest to use SSLSocketTemplate. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >>>> >>>> Artem >>>> >>> >> >> > From weijun.wang at oracle.com Thu Nov 3 01:30:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 3 Nov 2016 09:30:48 +0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> Message-ID: > On Nov 3, 2016, at 8:27 AM, Artem Smotrakov wrote: > > Hi Max, > > Please see inline. > > > On 11/01/2016 11:59 PM, Wang Weijun wrote: >> Main.java: >> >> The warning (and the subsequent empty line) should be printed into System.err. This one? > > Thank you for review Max, please take a look at updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8168882/webrev.01/ Fine except for the System.out one above. > > By the way, I just noticed that we have another version of JarUtils.java which was added by Alan 7 month ago > > http://hg.openjdk.java.net/jdk9/dev/jdk/log/1396fb6d0279/test/lib/testlibrary/JarUtils.java Looks like it's only used by himself, and has 2 lines of history. Also, my understanding is that we are switching to test utils in the root repo. A lot of same name utils in jdk/test were deprecated. Thanks Max > > Artem From artem.smotrakov at oracle.com Thu Nov 3 01:38:00 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 2 Nov 2016 18:38:00 -0700 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> Message-ID: <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> My bad, I missed that. http://cr.openjdk.java.net/~asmotrak/8168882/webrev.02/ Artem On 11/02/2016 06:30 PM, Wang Weijun wrote: >> On 11/01/2016 11:59 PM, Wang Weijun wrote: >>> >>Main.java: >>> >> >>> >>The warning (and the subsequent empty line) should be printed into System.err. > This one? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Nov 3 02:40:17 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 3 Nov 2016 10:40:17 +0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> Message-ID: Everything is fine now. Thanks Max On 11/3/2016 9:38 AM, Artem Smotrakov wrote: > My bad, I missed that. > > http://cr.openjdk.java.net/~asmotrak/8168882/webrev.02/ > > Artem > > > On 11/02/2016 06:30 PM, Wang Weijun wrote: >>> On 11/01/2016 11:59 PM, Wang Weijun wrote: >>>> >> Main.java: >>>> >> >>>> >> The warning (and the subsequent empty line) should be printed into System.err. >> This one? >> > From sergei.kovalev at oracle.com Thu Nov 3 10:26:20 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 3 Nov 2016 13:26:20 +0300 Subject: RFR(s): 8169002: [TESTBUG] Several java/net/httpclient have undeclared dependency on java.logging module In-Reply-To: References: Message-ID: <7cba0eaa-30fc-1803-659d-32b68864cf9f@oracle.com> Hi, Beside of listed in the review tests there are another tests in the folder. In case I'd update TEST.properties the not listed tests also will get unnecessary dependency from java.logging. -- With best regards, Sergei > On 1 Nov 2016, at 18:40, Roger Riggs > wrote: > >//>/Hi, />//>/Ok, leave the logging in. (There are currently 3 issues marked as > intermittent that refer to httpclient). />//>/Roger />//>/p.s. I'm also a fan of using the TEST.properties for test directives > that apply to multiple tests />/in a directory. In this case, "modules = java.logging?. / > If I understand correctly, the list of ?modules' in TEST.properties is only used > if the test does not explicitly have any @modules tags. So, if you want any > specific exports, or modules, then you need to specify them all. > > -Chris. > > >//>/On 11/1/2016 2:34 PM, Daniel Fuchs wrote: />>/Hi Roger, />>//>>/I think we agree :-) />>//>>/On 01/11/16 18:01, Roger Riggs wrote: />>>/Hi Daniel, />>>//>>>/It seemed useful to be able to run the test in as many environments as />>>/possible />>>/though realistically java.util.logging may be there too. />>>//>>>/I don't see that setting the logging levels is intrinsic to the tests />>>/and would be used />>>/for debugging so perhaps that function can be dropped or configured > via the />>>/java.util.logging.config.file system property if/when needed. />>//>>/For the java.util.logging.config.file system property to work then />>/you would need java.logging to be linked in - so if you do want />>/a test to spit out logging traces then you should require java.logging />>/in @modules - whether you use logging.properties or programmatic />>/interface to configure logging. />>//>>/So it all depends on how useful said traces are when investigating />>/a test failure. If a test is known to fail intermittently and />>/test failure would be very difficult to analyze without the logging />>/traces then the test should probably require and configure java.logging />>/upfront. />>//>>/Otherwise I agree you might want to remove the useless code, unless />>/you do want to validate that no NPE or else happen while logging... />>//>>/best regards, />>//>>/-- daniel />>//>>//>>>//>>>/$.02, Roger />>>//>>>//>>>//>>>/On 11/1/2016 1:53 PM, Daniel Fuchs wrote: />>>>/Hi Roger, />>>>//>>>>/On 01/11/16 17:21, Roger Riggs wrote: />>>>>/Hi Sergei, />>>>>//>>>>>/I think it would be preferable to convert the tests to use />>>>>/System.getLogger. />>>>>/Is that possible? />>>>//>>>>/Some of the tests want to configure the logging, rather />>>>/than simply produce traces - so they will need java.logging />>>>/to do that: />>>>//>>>>/670 Logger logger = Logger.getLogger("com.sun.net.httpserver"); />>>>/671 ConsoleHandler ch = new ConsoleHandler(); />>>>/672 logger.setLevel(Level.ALL); />>>>/673 ch.setLevel(Level.ALL); />>>>/674 logger.addHandler(ch); />>>>//>>>>/It's recommended to use System.Logger to log messages, />>>>/but you will have to use java.util.logging if you want to configure />>>>/the logging framework. Of course a library shouldn't do that, />>>>/but a test is well in its right to configure logging to make />>>>/sure the traces will appear in the log. />>>>/Unless you do want to run the test in a VM that does not have />>>>/java.logging linked in. />>>>//>>>>/cheers, />>>>//>>>>/-- daniel />>>>//>>>>//>>>>>//>>>>>/Thanks, Roger />>>>>//>>>>>//>>>>>/On 11/1/2016 1:15 PM, Sergei Kovalev wrote: />>>>>>/Hello all, />>>>>>//>>>>>>/Please review a small fix for tests. />>>>>>//>>>>>>/BugID: https://bugs.openjdk.java.net/browse/JDK-8169002 />>>>>>/WebRev: http://cr.openjdk.java.net/~skovalev/8169002/webrev.00/ > />>>>>>//>>>>>>/Issue: Several tests from java/net/httpclient folder have undeclared />>>>>>/dependency on java.logging module. This issue leads the test to fail />>>>>>/in case module limitation. />>>>>>/Solution: added module declaration into jtreg header and organized />>>>>>/imports. / -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Nov 3 14:00:36 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 3 Nov 2016 10:00:36 -0400 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> Message-ID: <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> You should only unset the jdk.jar.disabledAlgorithms property if a jarfile has been specified. Also, you are printing the warning message for all usages of the -printcert option, -ssl, etc, which is not correct. But I don't really think the warning message is necessary. The docs for the -printcert option are pretty clear that it simply extracts the certificate and prints it. If we are going to put a warning in for signed JARs, then arguably we should put in a more general, simple warning in for all usages of this option to say that the certificate, etc is not verified, ex: "WARNING: The -printcert option does not verify the certificate." But again, I don't think this is strictly necessary. Thanks, Sean On 11/2/16 10:40 PM, Wang Weijun wrote: > Everything is fine now. > > Thanks > Max > > On 11/3/2016 9:38 AM, Artem Smotrakov wrote: >> My bad, I missed that. >> >> http://cr.openjdk.java.net/~asmotrak/8168882/webrev.02/ >> >> Artem >> >> >> On 11/02/2016 06:30 PM, Wang Weijun wrote: >>>> On 11/01/2016 11:59 PM, Wang Weijun wrote: >>>>> >> Main.java: >>>>> >> >>>>> >> The warning (and the subsequent empty line) should be printed >>>>> into System.err. >>> This one? >>> >> From weijun.wang at oracle.com Thu Nov 3 14:27:53 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 3 Nov 2016 22:27:53 +0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> Message-ID: I agree with Sean. --Max > On Nov 3, 2016, at 10:00 PM, Sean Mullan wrote: > > You should only unset the jdk.jar.disabledAlgorithms property if a jarfile has been specified. > > Also, you are printing the warning message for all usages of the -printcert option, -ssl, etc, which is not correct. > > But I don't really think the warning message is necessary. The docs for the -printcert option are pretty clear that it simply extracts the certificate and prints it. If we are going to put a warning in for signed JARs, then arguably we should put in a more general, simple warning in for all usages of this option to say that the certificate, etc is not verified, ex: > > "WARNING: The -printcert option does not verify the certificate." > > But again, I don't think this is strictly necessary. > > Thanks, > Sean From artem.smotrakov at oracle.com Fri Nov 4 00:47:26 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 3 Nov 2016 17:47:26 -0700 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> Message-ID: <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> Thank you for review Sean. I'll remove the warning then. And I'll update it to reset the security property only if a jar file has been specified. Let me also check how "-printcert -file ..." and "-printcert -sslserver" work. Artem On 11/03/2016 07:27 AM, Wang Weijun wrote: > I agree with Sean. > > --Max > >> On Nov 3, 2016, at 10:00 PM, Sean Mullan wrote: >> >> You should only unset the jdk.jar.disabledAlgorithms property if a jarfile has been specified. >> >> Also, you are printing the warning message for all usages of the -printcert option, -ssl, etc, which is not correct. >> >> But I don't really think the warning message is necessary. The docs for the -printcert option are pretty clear that it simply extracts the certificate and prints it. If we are going to put a warning in for signed JARs, then arguably we should put in a more general, simple warning in for all usages of this option to say that the certificate, etc is not verified, ex: >> >> "WARNING: The -printcert option does not verify the certificate." >> >> But again, I don't think this is strictly necessary. >> >> Thanks, >> Sean From sean.coffey at oracle.com Fri Nov 4 13:42:16 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 4 Nov 2016 13:42:16 +0000 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates Message-ID: <581C9038.9060808@oracle.com> Looking to push this enhancement to jdk8u. The change introduces the new Security property which was brought into JDK 9 via JDK-8061842. The code differs in that jar files continue to be used and backwards compatibility is maintained. If the new security property is not defined and the policy jar files exist in the legacy locations, then those jar files will continue to be honoured. https://bugs.openjdk.java.net/browse/JDK-8157561 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ -- Regards, Sean. From erik.joelsson at oracle.com Fri Nov 4 14:16:41 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Nov 2016 15:16:41 +0100 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: <581C9038.9060808@oracle.com> References: <581C9038.9060808@oracle.com> Message-ID: <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> Build changes look ok to me. /Erik On 2016-11-04 14:42, Se?n Coffey wrote: > Looking to push this enhancement to jdk8u. The change introduces the > new Security property which was brought into JDK 9 via JDK-8061842. > > The code differs in that jar files continue to be used and backwards > compatibility is maintained. If the new security property is not > defined and the policy jar files exist in the legacy locations, then > those jar files will continue to be honoured. > > https://bugs.openjdk.java.net/browse/JDK-8157561 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ > From sean.mullan at oracle.com Fri Nov 4 14:54:01 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Nov 2016 10:54:01 -0400 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: * SecureRandom 131 * If this attribute is not set or is "false", this class will instead 132 * synchronize access to each of the methods of the {@code SecureRandomSpi} 133 * implementation. Not all of the methods are synchronized - engineGetParameters is not, for example. I think to avoid ambiguity, you should list the names of the methods that are synchronized. 810 * @throws IllegalArgumentException if {@code numBytes} is negative Since this is a new @throws, you really need to file a new CCC (or withdraw and amend the current one with this @throws). Please also file a docs bug with a description of the new attribute. * SecureRandomSpi lines 63-83, I think the wording could be improved/simplified, how about: See {@link SecureRandom} for additional details on thread safety. By default, a SecureRandomSpi implementation is considered to be not safe for use by multiple concurrent threads and SecureRandom will synchronize access to each of the applicable engine methods (see SecureRandom for the list of methods). However, if a SecureRandomSpi implementation is thread-safe, the service provider attribute "ThreadSafe" should be set to "true" during its registration, as follows: put("SecureRandom.AlgName ThreadSafe", "true"); or putService(new Service(this, "SecureRandom", "AlgName", className, null, Map.of("ThreadSafe", "true"))); {@code SecureRandom} will then call the applicable engine methods without any synchronization. --Sean On 11/2/16 3:27 AM, Wang Weijun wrote: > Ping again. > > There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. > > Thanks > Max > >> On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: >> >> Please review the enhancement at >> >> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >> >> Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before. >> >> Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks. >> >> Thanks >> Max > From claes.redestad at oracle.com Fri Nov 4 15:09:08 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Nov 2016 16:09:08 +0100 Subject: RFR: 8168911: Increased number of classes initialized during initialization of SignatureFileVerifier Message-ID: <8e3bba37-0c6f-50aa-e0ae-2c8aaefe7187@oracle.com> Hi, changes to SignatureFileVerifier in 9+142 has some startup implications, and a small cleanup to avoid some trivial regexes etc reduces number of classes initialized in affected startup tests by 61, undoing most of the observed regression. Webrev: http://cr.openjdk.java.net/~redestad/8168911/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8168911 Thanks! /Claes From bradford.wetmore at oracle.com Fri Nov 4 22:17:27 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 4 Nov 2016 15:17:27 -0700 Subject: RFR: 8169229: RSAClientKeyExchange debug info is incorrect Message-ID: https://bugs.openjdk.java.net/browse/JDK-8169229 http://cr.openjdk.java.net/~wetmore/8169229/webrev.00/ Please review this minor bug fix. Our RSAClientKeyExchange isn't properly outputing the RSA PreMasterSecret field. Thanks, Brad From bradford.wetmore at oracle.com Fri Nov 4 22:56:07 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 4 Nov 2016 15:56:07 -0700 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> References: <581C9038.9060808@oracle.com> <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> Message-ID: I didn't see anything majorly different in what I looked at earlier, I didn't check java.security or the test case. CryptoLevel.java ================ 49: Your usage mentions only unlimited|limited. Do you want to include a check for that? JceSecurity.java ================ 300: Indention problem. Looks ok otherwise. Thanks, Brad On 11/4/2016 7:16 AM, Erik Joelsson wrote: > Build changes look ok to me. > > /Erik > > > On 2016-11-04 14:42, Se?n Coffey wrote: >> Looking to push this enhancement to jdk8u. The change introduces the >> new Security property which was brought into JDK 9 via JDK-8061842. >> >> The code differs in that jar files continue to be used and backwards >> compatibility is maintained. If the new security property is not >> defined and the policy jar files exist in the legacy locations, then >> those jar files will continue to be honoured. >> >> https://bugs.openjdk.java.net/browse/JDK-8157561 >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ >> > From xuelei.fan at oracle.com Fri Nov 4 23:33:52 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 5 Nov 2016 07:33:52 +0800 Subject: RFR: 8169229: RSAClientKeyExchange debug info is incorrect In-Reply-To: References: Message-ID: <44ac8d11-f5fb-cd1c-319d-b2ff00174095@oracle.com> As there is a preMaster, may not need the debug-only debugProtocolVersion class field. It can be extracted from preMaster in the print() implementation. Xuelei On 11/5/2016 6:17 AM, Bradford Wetmore wrote: > > https://bugs.openjdk.java.net/browse/JDK-8169229 > http://cr.openjdk.java.net/~wetmore/8169229/webrev.00/ > > Please review this minor bug fix. Our RSAClientKeyExchange isn't > properly outputing the RSA PreMasterSecret field. > > Thanks, > > Brad From weijun.wang at oracle.com Sat Nov 5 14:28:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 5 Nov 2016 22:28:14 +0800 Subject: Windows LSA cache and Kerberos delegation In-Reply-To: References: Message-ID: <804C64BF-C6DC-463A-8105-CDF9B664C47A@oracle.com> > On Oct 13, 2016, at 3:38 AM, Venkat Iyer (veniyer) wrote: > > Do you know if the problem of obtaining TGT session key on Windows from LSA credential cache is resolved (see snippet below)? I am not sure. Sometimes you just cannot get the session key. One way to check this is to run Microsoft's own klist.exe tool. If "klist tgt" shows a non-zero session key, then Java can also get it. Otherwise, we don't have a good solution now. Hope this helps. --Weijun > Microsoft has not been able to provide any guidance on steps to make it work. These steps below haven?t helped: > ? Turn off UAC > ? Remove Service Account for application from local administrators group > ? Set the registry key ?allowtgtsessionkey? to true > We need delegation support through the application to underlying Kerberized systems. > > This reference was very useful to troubleshoot the issues. > http://cr.openjdk.java.net/~weijun/special/krb5winguide-2/raw_files/new/kwin > Known Issues > > If an AD account is also added into local administrator group on the > client PC, Microsoft restricts such client from getting the session key > for tickets (even if you set the allowtgtsessionkey registry key to 1). > The workaround is: Just forget you're a logged in user, call kinit.exe. > Do not depends on LSA credential cache. > > In a recent hotfix ([35]http://support.microsoft.com/kb/942219/en-us, > should be included in Vista SP1), this restriction is lifted for normal > service tickets. However, it still applies to TGT. Since Java uses TGT > to acquire tickets for other services (the standard Kerberos process), > this update provides no benefit to JGSS programming on Windows. > Furthermore, even if the implementation of Java is changed to read > service tickets from the LSA cache, it still cannot perform delegation, > since a TGT is always needed in that case. > > > Appreciate any help. > Thanks > Venkat From weijun.wang at oracle.com Mon Nov 7 09:59:04 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Nov 2016 17:59:04 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: <46f3fb61-fea2-ab7f-032c-9199d6aa0ec9@oracle.com> Accepted. Please review http://ccc.us.oracle.com/8169312. In fact, can we deprecate the getSeed() method? It's not unsafe so we don't need to give it a forRemoval value. Thanks Max On 11/4/2016 10:54 PM, Sean Mullan wrote: > * SecureRandom > > 131 * If this attribute is not set or is "false", this class will instead > 132 * synchronize access to each of the methods of the {@code > SecureRandomSpi} > 133 * implementation. > > Not all of the methods are synchronized - engineGetParameters is not, > for example. I think to avoid ambiguity, you should list the names of > the methods that are synchronized. > > 810 * @throws IllegalArgumentException if {@code numBytes} is negative > > Since this is a new @throws, you really need to file a new CCC (or > withdraw and amend the current one with this @throws). > > Please also file a docs bug with a description of the new attribute. > > * SecureRandomSpi > > lines 63-83, I think the wording could be improved/simplified, how about: > > See {@link SecureRandom} for additional details on thread safety. By > default, a SecureRandomSpi implementation is considered to be not safe > for use by multiple concurrent threads and SecureRandom will synchronize > access to each of the applicable engine methods (see SecureRandom for > the list of methods). However, if a SecureRandomSpi implementation is > thread-safe, the href="{@docRoot}/../technotes/guides/security/StandardNames.html#Service">service > provider attribute "ThreadSafe" should be set to "true" during its > registration, as follows: > > put("SecureRandom.AlgName ThreadSafe", "true"); > > or > > putService(new Service(this, "SecureRandom", "AlgName", className, > null, Map.of("ThreadSafe", "true"))); > > {@code SecureRandom} will then call the applicable engine methods > without any synchronization. > > --Sean > > On 11/2/16 3:27 AM, Wang Weijun wrote: >> Ping again. >> >> There is an updated version at >> http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only >> changes. >> >> Thanks >> Max >> >>> On Aug 25, 2016, at 10:00 AM, Weijun Wang >>> wrote: >>> >>> Please review the enhancement at >>> >>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>> >>> Basically, we want SecureRandom to be more efficient by removing all >>> synchronized keywords from its public methods and let an >>> implementation to take care of thread-safety (We already did some in >>> JDK-8098581). On the other hand, we need to make sure that existing >>> implementations that have not synchronized correctly to behave just >>> as good as before. >>> >>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you >>> think your implementation is already thread-safe, set it to "true" >>> and SecureRandom will be happy. Otherwise, don't set it and >>> SecureRandom will continuously call your SecureRandomSpi engine >>> methods in synchronized blocks. >>> >>> Thanks >>> Max >> From sean.coffey at oracle.com Mon Nov 7 11:34:00 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 7 Nov 2016 11:34:00 +0000 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: References: <581C9038.9060808@oracle.com> <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> Message-ID: <582066A8.502@oracle.com> Thanks for review Brad. I've included an extra check in CryptoLevel to check for "limited/unlimited" input. Addressed the JceSecurity indentation issue also. http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/ Regards, Sean. On 04/11/16 22:56, Bradford Wetmore wrote: > I didn't see anything majorly different in what I looked at earlier, I > didn't check java.security or the test case. > > > CryptoLevel.java > ================ > 49: Your usage mentions only unlimited|limited. Do you want to > include a check for that? > > JceSecurity.java > ================ > 300: Indention problem. > > Looks ok otherwise. > > Thanks, > > Brad > > > > > On 11/4/2016 7:16 AM, Erik Joelsson wrote: >> Build changes look ok to me. >> >> /Erik >> >> >> On 2016-11-04 14:42, Se?n Coffey wrote: >>> Looking to push this enhancement to jdk8u. The change introduces the >>> new Security property which was brought into JDK 9 via JDK-8061842. >>> >>> The code differs in that jar files continue to be used and backwards >>> compatibility is maintained. If the new security property is not >>> defined and the policy jar files exist in the legacy locations, then >>> those jar files will continue to be honoured. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157561 >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ >>> >> From xuelei.fan at oracle.com Mon Nov 7 12:00:14 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Nov 2016 20:00:14 +0800 Subject: Code Review Request, JDK-8169318, Dump the reproduced packet in DTLSOverDatagram.java Message-ID: <4e329574-5e29-c4f9-6271-77b9bf9a43cc@oracle.com> Hi, Please review this test update: http://cr.openjdk.java.net/~xuelei/8169318/webrev.00/ This update is related to JDK-8169086. From the debug log of JDK-8169086, it is hard to tell the failure is cause by anti-free-port issue or not. So I filed a new bug JDK-8169318, and want to expose more information for further evaluation. In the fix, retransmitted packet data will be dumped on timeout. Thanks, Xuelei From sean.mullan at oracle.com Mon Nov 7 15:51:46 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Nov 2016 10:51:46 -0500 Subject: Code Review Request, JDK-8169318, Dump the reproduced packet in DTLSOverDatagram.java In-Reply-To: <4e329574-5e29-c4f9-6271-77b9bf9a43cc@oracle.com> References: <4e329574-5e29-c4f9-6271-77b9bf9a43cc@oracle.com> Message-ID: <15821807-26e7-bcf5-1d3c-4180aef3dffa@oracle.com> Looks fine to me. --Sean On 11/7/16 7:00 AM, Xuelei Fan wrote: > Hi, > > Please review this test update: > > http://cr.openjdk.java.net/~xuelei/8169318/webrev.00/ > > This update is related to JDK-8169086. From the debug log of > JDK-8169086, it is hard to tell the failure is cause by anti-free-port > issue or not. So I filed a new bug JDK-8169318, and want to expose more > information for further evaluation. > > In the fix, retransmitted packet data will be dumped on timeout. > > Thanks, > Xuelei From bradford.wetmore at oracle.com Mon Nov 7 18:53:46 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 7 Nov 2016 10:53:46 -0800 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: <582066A8.502@oracle.com> References: <581C9038.9060808@oracle.com> <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> <582066A8.502@oracle.com> Message-ID: <52d9d607-4c41-1866-401c-1627b0b53230@oracle.com> Great, thanks. Looks good. Brad On 11/7/2016 3:34 AM, Se?n Coffey wrote: > Thanks for review Brad. I've included an extra check in CryptoLevel to > check for "limited/unlimited" input. Addressed the JceSecurity > indentation issue also. > > http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/ > > Regards, > Sean. > > On 04/11/16 22:56, Bradford Wetmore wrote: >> I didn't see anything majorly different in what I looked at earlier, I >> didn't check java.security or the test case. >> >> >> CryptoLevel.java >> ================ >> 49: Your usage mentions only unlimited|limited. Do you want to >> include a check for that? >> >> JceSecurity.java >> ================ >> 300: Indention problem. >> >> Looks ok otherwise. >> >> Thanks, >> >> Brad >> >> >> >> >> On 11/4/2016 7:16 AM, Erik Joelsson wrote: >>> Build changes look ok to me. >>> >>> /Erik >>> >>> >>> On 2016-11-04 14:42, Se?n Coffey wrote: >>>> Looking to push this enhancement to jdk8u. The change introduces the >>>> new Security property which was brought into JDK 9 via JDK-8061842. >>>> >>>> The code differs in that jar files continue to be used and backwards >>>> compatibility is maintained. If the new security property is not >>>> defined and the policy jar files exist in the legacy locations, then >>>> those jar files will continue to be honoured. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157561 >>>> webrev : >>>> http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ >>>> >>> > From sean.mullan at oracle.com Mon Nov 7 22:45:23 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Nov 2016 17:45:23 -0500 Subject: Updates to documentation for JEP 287 In-Reply-To: References: Message-ID: <50b1c090-41e4-ab55-4955-64915a8fa442@oracle.com> There's a bug open to update the Standard Names doc to include SHA-3: https://bugs.openjdk.java.net/browse/JDK-8004078 The security guides typically get updated a bit later. I don't have an estimate but it will be done before 9 is released. Thanks, Sean On 10/29/16 11:08 AM, Jurrian Fahner wrote: > Hi all, > > I discovered that for Java 9, the following page is not updated for the > new hashing algorithms: > http://download.java.net/java/jdk9/docs/technotes/guides/security/StandardNames.html > > I don't know whether it is on your to do list, if it is already an item > then just ignore this email. > If I can be of any assistance, please let me know. > > Kind regards, > > Jurrian Fahner From artem.smotrakov at oracle.com Tue Nov 8 01:59:19 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 7 Nov 2016 17:59:19 -0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> Message-ID: <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> Sean, Max, Please take a look at http://cr.openjdk.java.net/~asmotrak/8168882/webrev.03/ It doesn't print a warning anymore, and reset the security property only if -jarfile specified. I also updated a couple of tests to check if "-printcert" works fine. Artem On 11/03/2016 05:47 PM, Artem Smotrakov wrote: > Thank you for review Sean. > > I'll remove the warning then. And I'll update it to reset the security > property only if a jar file has been specified. > > Let me also check how "-printcert -file ..." and "-printcert > -sslserver" work. > > Artem > > > On 11/03/2016 07:27 AM, Wang Weijun wrote: >> I agree with Sean. >> >> --Max >> >>> On Nov 3, 2016, at 10:00 PM, Sean Mullan >>> wrote: >>> >>> You should only unset the jdk.jar.disabledAlgorithms property if a >>> jarfile has been specified. >>> >>> Also, you are printing the warning message for all usages of the >>> -printcert option, -ssl, etc, which is not correct. >>> >>> But I don't really think the warning message is necessary. The docs >>> for the -printcert option are pretty clear that it simply extracts >>> the certificate and prints it. If we are going to put a warning in >>> for signed JARs, then arguably we should put in a more general, >>> simple warning in for all usages of this option to say that the >>> certificate, etc is not verified, ex: >>> >>> "WARNING: The -printcert option does not verify the certificate." >>> >>> But again, I don't think this is strictly necessary. >>> >>> Thanks, >>> Sean > From weijun.wang at oracle.com Tue Nov 8 02:45:18 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Nov 2016 10:45:18 +0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> Message-ID: <75BDBEF3-C174-412D-8C25-B58AB627A300@oracle.com> Hi Artem Change looks fine, but you can add a comment in keytool/Main on why you want to set that security property. BTW, you mentioned keytool -printcert -sslserver the other time. Is there any strange thing happening if the SSL server is using weak cert/cipher? Thanks Max > On Nov 8, 2016, at 9:59 AM, Artem Smotrakov wrote: > > Sean, Max, > > Please take a look at http://cr.openjdk.java.net/~asmotrak/8168882/webrev.03/ > > It doesn't print a warning anymore, and reset the security property only if -jarfile specified. I also updated a couple of tests to check if "-printcert" works fine. > > Artem > > > On 11/03/2016 05:47 PM, Artem Smotrakov wrote: >> Thank you for review Sean. >> >> I'll remove the warning then. And I'll update it to reset the security property only if a jar file has been specified. >> >> Let me also check how "-printcert -file ..." and "-printcert -sslserver" work. >> >> Artem >> >> >> On 11/03/2016 07:27 AM, Wang Weijun wrote: >>> I agree with Sean. >>> >>> --Max >>> >>>> On Nov 3, 2016, at 10:00 PM, Sean Mullan wrote: >>>> >>>> You should only unset the jdk.jar.disabledAlgorithms property if a jarfile has been specified. >>>> >>>> Also, you are printing the warning message for all usages of the -printcert option, -ssl, etc, which is not correct. >>>> >>>> But I don't really think the warning message is necessary. The docs for the -printcert option are pretty clear that it simply extracts the certificate and prints it. If we are going to put a warning in for signed JARs, then arguably we should put in a more general, simple warning in for all usages of this option to say that the certificate, etc is not verified, ex: >>>> >>>> "WARNING: The -printcert option does not verify the certificate." >>>> >>>> But again, I don't think this is strictly necessary. >>>> >>>> Thanks, >>>> Sean >> > From artem.smotrakov at oracle.com Tue Nov 8 02:50:48 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 7 Nov 2016 18:50:48 -0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <75BDBEF3-C174-412D-8C25-B58AB627A300@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> <75BDBEF3-C174-412D-8C25-B58AB627A300@oracle.com> Message-ID: <4896c7d4-9d7d-94bb-488f-a2cb0e69f0c4@oracle.com> Hi Max, Sure, I'll add a comment which explains why keytool resets that security property. I didn't notice any strange thing happening if SSL server uses weak algorithms. Please see updated PrintSSL.java which now uses MD5withRSA. Artem On 11/07/2016 06:45 PM, Wang Weijun wrote: > Hi Artem > > Change looks fine, but you can add a comment in keytool/Main on why you want to set that security property. > > BTW, you mentioned keytool -printcert -sslserver the other time. Is there any strange thing happening if the SSL server is using weak cert/cipher? > > Thanks > Max > >> On Nov 8, 2016, at 9:59 AM, Artem Smotrakov wrote: >> >> Sean, Max, >> >> Please take a look at http://cr.openjdk.java.net/~asmotrak/8168882/webrev.03/ >> >> It doesn't print a warning anymore, and reset the security property only if -jarfile specified. I also updated a couple of tests to check if "-printcert" works fine. >> >> Artem >> >> >> On 11/03/2016 05:47 PM, Artem Smotrakov wrote: >>> Thank you for review Sean. >>> >>> I'll remove the warning then. And I'll update it to reset the security property only if a jar file has been specified. >>> >>> Let me also check how "-printcert -file ..." and "-printcert -sslserver" work. >>> >>> Artem >>> >>> >>> On 11/03/2016 07:27 AM, Wang Weijun wrote: >>>> I agree with Sean. >>>> >>>> --Max >>>> >>>>> On Nov 3, 2016, at 10:00 PM, Sean Mullan wrote: >>>>> >>>>> You should only unset the jdk.jar.disabledAlgorithms property if a jarfile has been specified. >>>>> >>>>> Also, you are printing the warning message for all usages of the -printcert option, -ssl, etc, which is not correct. >>>>> >>>>> But I don't really think the warning message is necessary. The docs for the -printcert option are pretty clear that it simply extracts the certificate and prints it. If we are going to put a warning in for signed JARs, then arguably we should put in a more general, simple warning in for all usages of this option to say that the certificate, etc is not verified, ex: >>>>> >>>>> "WARNING: The -printcert option does not verify the certificate." >>>>> >>>>> But again, I don't think this is strictly necessary. >>>>> >>>>> Thanks, >>>>> Sean From artem.smotrakov at oracle.com Tue Nov 8 03:09:08 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 7 Nov 2016 19:09:08 -0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <4896c7d4-9d7d-94bb-488f-a2cb0e69f0c4@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> <75BDBEF3-C174-412D-8C25-B58AB627A300@oracle.com> <4896c7d4-9d7d-94bb-488f-a2cb0e69f0c4@oracle.com> Message-ID: Here is final version (I hope) http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/ Artem On 11/07/2016 06:50 PM, Artem Smotrakov wrote: > Hi Max, > > Sure, I'll add a comment which explains why keytool resets that > security property. > > I didn't notice any strange thing happening if SSL server uses weak > algorithms. Please see updated PrintSSL.java which now uses MD5withRSA. > > Artem > > > On 11/07/2016 06:45 PM, Wang Weijun wrote: >> Hi Artem >> >> Change looks fine, but you can add a comment in keytool/Main on why >> you want to set that security property. >> >> BTW, you mentioned keytool -printcert -sslserver the other time. Is >> there any strange thing happening if the SSL server is using weak >> cert/cipher? >> >> Thanks >> Max >> >>> On Nov 8, 2016, at 9:59 AM, Artem Smotrakov >>> wrote: >>> >>> Sean, Max, >>> >>> Please take a look at >>> http://cr.openjdk.java.net/~asmotrak/8168882/webrev.03/ >>> >>> It doesn't print a warning anymore, and reset the security property >>> only if -jarfile specified. I also updated a couple of tests to >>> check if "-printcert" works fine. >>> >>> Artem >>> >>> >>> On 11/03/2016 05:47 PM, Artem Smotrakov wrote: >>>> Thank you for review Sean. >>>> >>>> I'll remove the warning then. And I'll update it to reset the >>>> security property only if a jar file has been specified. >>>> >>>> Let me also check how "-printcert -file ..." and "-printcert >>>> -sslserver" work. >>>> >>>> Artem >>>> >>>> >>>> On 11/03/2016 07:27 AM, Wang Weijun wrote: >>>>> I agree with Sean. >>>>> >>>>> --Max >>>>> >>>>>> On Nov 3, 2016, at 10:00 PM, Sean Mullan >>>>>> wrote: >>>>>> >>>>>> You should only unset the jdk.jar.disabledAlgorithms property if >>>>>> a jarfile has been specified. >>>>>> >>>>>> Also, you are printing the warning message for all usages of the >>>>>> -printcert option, -ssl, etc, which is not correct. >>>>>> >>>>>> But I don't really think the warning message is necessary. The >>>>>> docs for the -printcert option are pretty clear that it simply >>>>>> extracts the certificate and prints it. If we are going to put a >>>>>> warning in for signed JARs, then arguably we should put in a more >>>>>> general, simple warning in for all usages of this option to say >>>>>> that the certificate, etc is not verified, ex: >>>>>> >>>>>> "WARNING: The -printcert option does not verify the certificate." >>>>>> >>>>>> But again, I don't think this is strictly necessary. >>>>>> >>>>>> Thanks, >>>>>> Sean > From weijun.wang at oracle.com Tue Nov 8 03:10:59 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 8 Nov 2016 11:10:59 +0800 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> <75BDBEF3-C174-412D-8C25-B58AB627A300@oracle.com> <4896c7d4-9d7d-94bb-488f-a2cb0e69f0c4@oracle.com> Message-ID: <10B13637-FBCA-4603-A96C-DFB2704A8D24@oracle.com> Everything looks fine now. --Max > On Nov 8, 2016, at 11:09 AM, Artem Smotrakov wrote: > > Here is final version (I hope) > > http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/ > > Artem From anthony.scarpino at oracle.com Tue Nov 8 03:30:26 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 7 Nov 2016 19:30:26 -0800 Subject: RFR: 8168911: Increased number of classes initialized during initialization of SignatureFileVerifier In-Reply-To: <8e3bba37-0c6f-50aa-e0ae-2c8aaefe7187@oracle.com> References: <8e3bba37-0c6f-50aa-e0ae-2c8aaefe7187@oracle.com> Message-ID: <582146D2.1020405@oracle.com> On 11/04/2016 08:09 AM, Claes Redestad wrote: > Hi, > > changes to SignatureFileVerifier in 9+142 has some startup implications, > and a small > cleanup to avoid some trivial regexes etc reduces number of classes > initialized in affected > startup tests by 61, undoing most of the observed regression. > > Webrev: http://cr.openjdk.java.net/~redestad/8168911/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8168911 > > Thanks! > > /Claes The change looks fine.. thanks Tony From jurrian.fahner at gmail.com Tue Nov 8 17:34:37 2016 From: jurrian.fahner at gmail.com (Jurrian Fahner) Date: Tue, 08 Nov 2016 17:34:37 +0000 Subject: Updates to documentation for JEP 287 In-Reply-To: <50b1c090-41e4-ab55-4955-64915a8fa442@oracle.com> References: <50b1c090-41e4-ab55-4955-64915a8fa442@oracle.com> Message-ID: Thanks for the update. Kind regards, Jurrian Op ma 7 nov. 2016 23:45 schreef Sean Mullan : > There's a bug open to update the Standard Names doc to include SHA-3: > https://bugs.openjdk.java.net/browse/JDK-8004078 > > The security guides typically get updated a bit later. I don't have an > estimate but it will be done before 9 is released. > > Thanks, > Sean > > > On 10/29/16 11:08 AM, Jurrian Fahner wrote: > > Hi all, > > > > I discovered that for Java 9, the following page is not updated for the > > new hashing algorithms: > > > http://download.java.net/java/jdk9/docs/technotes/guides/security/StandardNames.html > > > > I don't know whether it is on your to do list, if it is already an item > > then just ignore this email. > > If I can be of any assistance, please let me know. > > > > Kind regards, > > > > Jurrian Fahner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Nov 8 21:06:40 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Nov 2016 16:06:40 -0500 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: <46f3fb61-fea2-ab7f-032c-9199d6aa0ec9@oracle.com> References: <46f3fb61-fea2-ab7f-032c-9199d6aa0ec9@oracle.com> Message-ID: <3f7db397-203e-428a-d77c-b9b5309384ca@oracle.com> On 11/7/16 4:59 AM, Wang Weijun wrote: > Accepted. > > Please review http://ccc.us.oracle.com/8169312. Reviewed. > In fact, can we > deprecate the getSeed() method? It's not unsafe so we don't need to give > it a forRemoval value. Sounds reasonable. I would file a bug, but I don't think it is critical for 9 - we can do it in 10. --Sean > > Thanks > Max > > On 11/4/2016 10:54 PM, Sean Mullan wrote: >> * SecureRandom >> >> 131 * If this attribute is not set or is "false", this class will >> instead >> 132 * synchronize access to each of the methods of the {@code >> SecureRandomSpi} >> 133 * implementation. >> >> Not all of the methods are synchronized - engineGetParameters is not, >> for example. I think to avoid ambiguity, you should list the names of >> the methods that are synchronized. >> >> 810 * @throws IllegalArgumentException if {@code numBytes} is >> negative >> >> Since this is a new @throws, you really need to file a new CCC (or >> withdraw and amend the current one with this @throws). >> >> Please also file a docs bug with a description of the new attribute. >> >> * SecureRandomSpi >> >> lines 63-83, I think the wording could be improved/simplified, how about: >> >> See {@link SecureRandom} for additional details on thread safety. By >> default, a SecureRandomSpi implementation is considered to be not safe >> for use by multiple concurrent threads and SecureRandom will synchronize >> access to each of the applicable engine methods (see SecureRandom for >> the list of methods). However, if a SecureRandomSpi implementation is >> thread-safe, the > href="{@docRoot}/../technotes/guides/security/StandardNames.html#Service">service >> >> provider attribute "ThreadSafe" should be set to "true" during its >> registration, as follows: >> >> put("SecureRandom.AlgName ThreadSafe", "true"); >> >> or >> >> putService(new Service(this, "SecureRandom", "AlgName", className, >> null, Map.of("ThreadSafe", "true"))); >> >> {@code SecureRandom} will then call the applicable engine methods >> without any synchronization. >> >> --Sean >> >> On 11/2/16 3:27 AM, Wang Weijun wrote: >>> Ping again. >>> >>> There is an updated version at >>> http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only >>> changes. >>> >>> Thanks >>> Max >>> >>>> On Aug 25, 2016, at 10:00 AM, Weijun Wang >>>> wrote: >>>> >>>> Please review the enhancement at >>>> >>>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>>> >>>> Basically, we want SecureRandom to be more efficient by removing all >>>> synchronized keywords from its public methods and let an >>>> implementation to take care of thread-safety (We already did some in >>>> JDK-8098581). On the other hand, we need to make sure that existing >>>> implementations that have not synchronized correctly to behave just >>>> as good as before. >>>> >>>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you >>>> think your implementation is already thread-safe, set it to "true" >>>> and SecureRandom will be happy. Otherwise, don't set it and >>>> SecureRandom will continuously call your SecureRandomSpi engine >>>> methods in synchronized blocks. >>>> >>>> Thanks >>>> Max >>> From sean.mullan at oracle.com Tue Nov 8 21:27:12 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Nov 2016 16:27:12 -0500 Subject: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar In-Reply-To: <10B13637-FBCA-4603-A96C-DFB2704A8D24@oracle.com> References: <285f5045-c363-6c9c-89a2-7cba6c786d0a@oracle.com> <8628cd54-817e-8606-b478-640203bbab0b@oracle.com> <099eb7de-ca6d-dd10-8d34-76ae5cf9e454@oracle.com> <68bdf4b8-8e49-3c19-e450-432c5ca70cf8@oracle.com> <6c608816-7e6b-55a5-0b6d-b3018a665c8b@oracle.com> <75BDBEF3-C174-412D-8C25-B58AB627A300@oracle.com> <4896c7d4-9d7d-94bb-488f-a2cb0e69f0c4@oracle.com> <10B13637-FBCA-4603-A96C-DFB2704A8D24@oracle.com> Message-ID: Looks fine to me. --Sean On 11/7/16 10:10 PM, Wang Weijun wrote: > Everything looks fine now. > > --Max > >> On Nov 8, 2016, at 11:09 AM, Artem Smotrakov wrote: >> >> Here is final version (I hope) >> >> http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/ >> >> Artem > From bradford.wetmore at oracle.com Tue Nov 8 23:09:46 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 8 Nov 2016 15:09:46 -0800 Subject: RFR: 8169229: RSAClientKeyExchange debug info is incorrect In-Reply-To: <44ac8d11-f5fb-cd1c-319d-b2ff00174095@oracle.com> References: <44ac8d11-f5fb-cd1c-319d-b2ff00174095@oracle.com> Message-ID: <674fb48c-9ce0-2083-082c-ef0c767663e6@oracle.com> Xuelei/I inadvertently left off security-dev in a later discussion, so cc'ing here on some main points. On 11/4/2016 4:33 PM, Xuelei Fan wrote: > As there is a preMaster, may not need the debug-only > debugProtocolVersion class field. It can be extracted from preMaster in > the print() implementation. On 11/6/2016 12:51 AM, Bradford Wetmore wrote: > What if it's not extractible? Xuelei wrote: > We know the version for the ClientKeyExchange message generation > (client side). For the receiving/server side, no idea about how to > get the version. Maybe, we can just dump "version is not > extractable"? For the client, the clientKeyExchange protocol version field for the message is actually set in the KeyGenerator, so RSAClientKeyExchange.protocolVersion may or may not be what is sent over the wire. That is: RSAClientKeyExchange.protocolVersion is only a guess, and may not be accurate and will confuse any debug analysis. For the server side, I would expect the same: if it's not extractable we could output some currentVersion, but again it's only a guess and would confuse things. So IMHO, we should not look at this.protocolVersion for debug if the preMaster is not extractable: void print(PrintStream s) throws IOException { + String version = "protocol version not available"; + + byte[] ba = preMaster.getEncoded(); + if (ba != null && ba.length >= 2) { + version = ProtocolVersion.valueOf(ba[0], ba[1]).name; + } + s.println("*** ClientKeyExchange, RSA PreMasterSecret, " + - protocolVersion); + version); Final update: https://bugs.openjdk.java.net/browse/JDK-8169229 http://cr.openjdk.java.net/~wetmore/8169229/webrev.01 I'll run it through JPRT, but I'll mark as noreg-trivial. Brad >>>>> On 11/5/2016 6:17 AM, Bradford Wetmore wrote: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8169229 >>>>>> http://cr.openjdk.java.net/~wetmore/8169229/webrev.00/ >>>>>> >>>>>> Please review this minor bug fix. Our RSAClientKeyExchange isn't >>>>>> properly outputing the RSA PreMasterSecret field. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Brad From weijun.wang at oracle.com Tue Nov 8 23:51:12 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 9 Nov 2016 07:51:12 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: <3f7db397-203e-428a-d77c-b9b5309384ca@oracle.com> References: <46f3fb61-fea2-ab7f-032c-9199d6aa0ec9@oracle.com> <3f7db397-203e-428a-d77c-b9b5309384ca@oracle.com> Message-ID: > On Nov 9, 2016, at 5:06 AM, Sean Mullan wrote: > >> In fact, can we >> deprecate the getSeed() method? It's not unsafe so we don't need to give >> it a forRemoval value. > > Sounds reasonable. I would file a bug, but I don't think it is critical for 9 - we can do it in 10. https://bugs.openjdk.java.net/browse/JDK-8169437 --Max From xuelei.fan at oracle.com Wed Nov 9 01:13:49 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 9 Nov 2016 09:13:49 +0800 Subject: RFR: 8169229: RSAClientKeyExchange debug info is incorrect In-Reply-To: <674fb48c-9ce0-2083-082c-ef0c767663e6@oracle.com> References: <44ac8d11-f5fb-cd1c-319d-b2ff00174095@oracle.com> <674fb48c-9ce0-2083-082c-ef0c767663e6@oracle.com> Message-ID: > http://cr.openjdk.java.net/~wetmore/8169229/webrev.01 Looks fine to me. Xuelei On 11/9/2016 7:09 AM, Bradford Wetmore wrote: > Xuelei/I inadvertently left off security-dev in a later discussion, so > cc'ing here on some main points. > > On 11/4/2016 4:33 PM, Xuelei Fan wrote: >> As there is a preMaster, may not need the debug-only >> debugProtocolVersion class field. It can be extracted from preMaster in >> the print() implementation. > > On 11/6/2016 12:51 AM, Bradford Wetmore wrote: >> What if it's not extractible? > > Xuelei wrote: > >> We know the version for the ClientKeyExchange message generation >> (client side). For the receiving/server side, no idea about how to >> get the version. Maybe, we can just dump "version is not >> extractable"? > > For the client, the clientKeyExchange protocol version field for the > message is actually set in the KeyGenerator, so > RSAClientKeyExchange.protocolVersion may or may not be what is sent over > the wire. That is: RSAClientKeyExchange.protocolVersion is only a > guess, and may not be accurate and will confuse any debug analysis. > > For the server side, I would expect the same: if it's not extractable we > could output some currentVersion, but again it's only a guess and would > confuse things. > > So IMHO, we should not look at this.protocolVersion for debug if the > preMaster is not extractable: > > void print(PrintStream s) throws IOException { > + String version = "protocol version not available"; > + > + byte[] ba = preMaster.getEncoded(); > + if (ba != null && ba.length >= 2) { > + version = ProtocolVersion.valueOf(ba[0], ba[1]).name; > + } > + > s.println("*** ClientKeyExchange, RSA PreMasterSecret, " + > - protocolVersion); > + version); > > Final update: > > https://bugs.openjdk.java.net/browse/JDK-8169229 > http://cr.openjdk.java.net/~wetmore/8169229/webrev.01 > > I'll run it through JPRT, but I'll mark as noreg-trivial. > > Brad > > >>>>>> On 11/5/2016 6:17 AM, Bradford Wetmore wrote: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8169229 >>>>>>> http://cr.openjdk.java.net/~wetmore/8169229/webrev.00/ >>>>>>> >>>>>>> Please review this minor bug fix. Our RSAClientKeyExchange isn't >>>>>>> properly outputing the RSA PreMasterSecret field. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Brad > > > From sean.coffey at oracle.com Wed Nov 9 11:26:17 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 9 Nov 2016 11:26:17 +0000 Subject: RFR : (XS) 8166432:Bad 8u112 merge of sun/security/tools/jarsigner/warnings/Test.java Message-ID: <582307D9.2070501@oracle.com> A bad test code merge occurred when 8u112 and CPU code was being merged a few weeks ago. Some extra functionality added to a helper test was lost. This fix restores it. 8u applicable only. diff --git a/test/sun/security/tools/jarsigner/warnings/Test.java b/test/sun/security/tools/jarsigner/warnings/Test.java --- a/test/sun/security/tools/jarsigner/warnings/Test.java +++ b/test/sun/security/tools/jarsigner/warnings/Test.java @@ -22,6 +22,11 @@ */ import jdk.testlibrary.OutputAnalyzer; +import jdk.testlibrary.ProcessTools; + +import java.util.ArrayList; +import java.util.Arrays; +import java.util.List; /** * Base class. @@ -175,4 +180,21 @@ } analyzer.shouldContain(JAR_SIGNED); } + + protected OutputAnalyzer keytool(String... cmd) throws Throwable { + return tool(KEYTOOL, cmd); } + + protected OutputAnalyzer jarsigner(String... cmd) throws Throwable { + return tool(JARSIGNER, cmd); + } + + private OutputAnalyzer tool(String tool, String... args) throws Throwable { + List cmd = new ArrayList<>(); + cmd.add(tool); + cmd.add("-J-Duser.language=en"); + cmd.add("-J-Duser.country=US"); + cmd.addAll(Arrays.asList(args)); + return ProcessTools.executeCommand(cmd.toArray(new String[cmd.size()])); + } +} -- Regards, Sean. From xuelei.fan at oracle.com Wed Nov 9 13:17:40 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 9 Nov 2016 21:17:40 +0800 Subject: Code Review Reqeust, JDK-8169362, Interop automated testing with Chrome Message-ID: Hi, Please review this test enhancement: http://cr.openjdk.java.net/~xuelei/8169362/webrev.00/ This update adds a interop new test case with Chrome ClientHello message. Thanks, Xuelei From vincent.x.ryan at oracle.com Wed Nov 9 13:39:32 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 9 Nov 2016 13:39:32 +0000 Subject: RFR : (XS) 8166432:Bad 8u112 merge of sun/security/tools/jarsigner/warnings/Test.java In-Reply-To: <582307D9.2070501@oracle.com> References: <582307D9.2070501@oracle.com> Message-ID: Looks fine to me. Thanks. > On 9 Nov 2016, at 11:26, Se?n Coffey wrote: > > A bad test code merge occurred when 8u112 and CPU code was being merged a few weeks ago. Some extra functionality added to a helper test was lost. This fix restores it. 8u applicable only. > > diff --git a/test/sun/security/tools/jarsigner/warnings/Test.java b/test/sun/security/tools/jarsigner/warnings/Test.java > --- a/test/sun/security/tools/jarsigner/warnings/Test.java > +++ b/test/sun/security/tools/jarsigner/warnings/Test.java > @@ -22,6 +22,11 @@ > */ > > import jdk.testlibrary.OutputAnalyzer; > +import jdk.testlibrary.ProcessTools; > + > +import java.util.ArrayList; > +import java.util.Arrays; > +import java.util.List; > > /** > * Base class. > @@ -175,4 +180,21 @@ > } > analyzer.shouldContain(JAR_SIGNED); > } > + > + protected OutputAnalyzer keytool(String... cmd) throws Throwable { > + return tool(KEYTOOL, cmd); > } > + > + protected OutputAnalyzer jarsigner(String... cmd) throws Throwable { > + return tool(JARSIGNER, cmd); > + } > + > + private OutputAnalyzer tool(String tool, String... args) throws Throwable { > + List cmd = new ArrayList<>(); > + cmd.add(tool); > + cmd.add("-J-Duser.language=en"); > + cmd.add("-J-Duser.country=US"); > + cmd.addAll(Arrays.asList(args)); > + return ProcessTools.executeCommand(cmd.toArray(new String[cmd.size()])); > + } > +} > > -- > Regards, > Sean. > From xuelei.fan at oracle.com Thu Nov 10 00:57:00 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Nov 2016 08:57:00 +0800 Subject: Code Review Reqeust, JDK-8169362, Interop automated testing with Chrome In-Reply-To: References: Message-ID: Upated webrev: http://cr.openjdk.java.net/~xuelei/8169362/webrev.01/ Comparing the webrev.00, the logging class field is removed. Xuelei On 11/9/2016 9:17 PM, Xuelei Fan wrote: > Hi, > > Please review this test enhancement: > > http://cr.openjdk.java.net/~xuelei/8169362/webrev.00/ > > This update adds a interop new test case with Chrome ClientHello message. > > Thanks, > Xuelei From bradford.wetmore at oracle.com Thu Nov 10 01:41:00 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 9 Nov 2016 17:41:00 -0800 Subject: Code Review Reqeust, JDK-8169362, Interop automated testing with Chrome In-Reply-To: References: Message-ID: <773caa25-6d45-e67d-01ea-e49efa912084@oracle.com> Hi Xuelei, Nothing major, mostly nits and some Netbeans suggestions. On 11/9/2016 5:17 AM, Xuelei Fan wrote: > Hi, > > Please review this test enhancement: > > http://cr.openjdk.java.net/~xuelei/8169362/webrev.00/ > > This update adds a interop new test case with Chrome ClientHello message. ClientHelloInterOp.java ======================= 34: import not needed. 43/92/138/178: could be final. 265: is value of null is never used. 290: Generally prefer () groupings if you can. 316: Nit, you could combine: Certificate[] chain = new Certificate [] { keyCert }; 200/211/285: jcheck problems. You could make a lot of these methods/fields private unless you plan to use them later. ClientHelloChromeInterOp.java ============================= 37: import not needed. 46: could be final. I didn't check the format of the ClientHello, assuming it does what you need. Do you need me to do a secondary check? Ok otherwise, Brad From xuelei.fan at oracle.com Thu Nov 10 03:02:21 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Nov 2016 11:02:21 +0800 Subject: Code Review Reqeust, JDK-8169362, Interop automated testing with Chrome In-Reply-To: <773caa25-6d45-e67d-01ea-e49efa912084@oracle.com> References: <773caa25-6d45-e67d-01ea-e49efa912084@oracle.com> Message-ID: <29c760d4-3cfd-4e7f-bbd2-fedd4ca73513@oracle.com> Thanks for review. I will go ahead and push the changeset. The latest update is: http://cr.openjdk.java.net/~xuelei/8169362/webrev.01/ Xuelei On 11/10/2016 9:41 AM, Bradford Wetmore wrote: > Hi Xuelei, > > Nothing major, mostly nits and some Netbeans suggestions. > > On 11/9/2016 5:17 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this test enhancement: >> >> http://cr.openjdk.java.net/~xuelei/8169362/webrev.00/ >> >> This update adds a interop new test case with Chrome ClientHello message. > > ClientHelloInterOp.java > ======================= > 34: import not needed. > > 43/92/138/178: could be final. > > 265: is value of null is never used. > > 290: Generally prefer () groupings if you can. > > 316: Nit, you could combine: > > Certificate[] chain = new Certificate [] { keyCert }; > > 200/211/285: jcheck problems. > > You could make a lot of these methods/fields private unless you plan to > use them later. > > > ClientHelloChromeInterOp.java > ============================= > 37: import not needed. > > 46: could be final. > > I didn't check the format of the ClientHello, assuming it does what you > need. Do you need me to do a secondary check? > > Ok otherwise, > > Brad > > From ecki at zusammenkunft.net Thu Nov 10 07:19:25 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 10 Nov 2016 07:19:25 +0000 (UTC) Subject: Code Review Reqeust, JDK-8169362, Interop automated testing with Chrome In-Reply-To: <29c760d4-3cfd-4e7f-bbd2-fedd4ca73513@oracle.com> References: <773caa25-6d45-e67d-01ea-e49efa912084@oracle.com> <29c760d4-3cfd-4e7f-bbd2-fedd4ca73513@oracle.com> Message-ID: <57A008FAA9E6E1E3.1E474A88-0393-4D69-AAEC-3A84DA326651@mail.outlook.com> Hello, just a Nit, but should this be clientNet/AppOutbound instead of Inbound (or maybe use Response instead?) in ClientHelloInterOp#run Is it Ok that there is no asserts? What cipher would be picked for example? ClientHelloInterOp? In 271+304 I would use try-with-resource or not close the in memory stream at all. Also while it is possible to use getBytes() I used to use StandardCharset.ASCII to make it explicit. Typo in 388 comment (delegated) Gruss Bernd -- http://bernd.eckenfels.net On Thu, Nov 10, 2016 at 4:13 AM +0100, "Xuelei Fan" wrote: Thanks for review. I will go ahead and push the changeset. The latest update is: http://cr.openjdk.java.net/~xuelei/8169362/webrev.01/ Xuelei On 11/10/2016 9:41 AM, Bradford Wetmore wrote: > Hi Xuelei, > > Nothing major, mostly nits and some Netbeans suggestions. > > On 11/9/2016 5:17 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this test enhancement: >> >> http://cr.openjdk.java.net/~xuelei/8169362/webrev.00/ >> >> This update adds a interop new test case with Chrome ClientHello message. > > ClientHelloInterOp.java > ======================= > 34: import not needed. > > 43/92/138/178: could be final. > > 265: is value of null is never used. > > 290: Generally prefer () groupings if you can. > > 316: Nit, you could combine: > > Certificate[] chain = new Certificate [] { keyCert }; > > 200/211/285: jcheck problems. > > You could make a lot of these methods/fields private unless you plan to > use them later. > > > ClientHelloChromeInterOp.java > ============================= > 37: import not needed. > > 46: could be final. > > I didn't check the format of the ClientHello, assuming it does what you > need. Do you need me to do a secondary check? > > Ok otherwise, > > Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Thu Nov 10 21:55:41 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 10 Nov 2016 13:55:41 -0800 Subject: RFR: 8168861 AnchorCertificates uses hardcoded password for cacerts keystore Message-ID: <5824ECDD.1020407@oracle.com> Hi, I need a one line review to null out the password field in the keystore load op.. http://cr.openjdk.java.net/~ascarpino/8168861/webrev/ thanks Tony From xuelei.fan at oracle.com Fri Nov 11 05:11:06 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Nov 2016 13:11:06 +0800 Subject: Code Review Request, JDK-8166103 Allow certs with unknown critical extension in SunX509 validator Message-ID: <22d5ef59-658c-b30e-c254-21f3d89f190f@oracle.com> Hi, Please review this bug fix: http://cr.openjdk.java.net/~xuelei/8166103/webrev.00/ The current validator implementations only allow white listed critical certificate extensions, and not all JDK supported extensions are known to the validator. As may result in some issues that the cert is valid, but cannot pass the validation because there is a critical extension that is not white listed in the validator implementation. This fix will only check the validity of the white listed critical certificate extensions, and ignore the critical certificate extensions if they can be parsed with X509Certificate. Thanks, Xuelei From vincent.x.ryan at oracle.com Fri Nov 11 17:46:38 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 11 Nov 2016 17:46:38 +0000 Subject: Code Review Request, JDK-8166103 Allow certs with unknown critical extension in SunX509 validator In-Reply-To: <22d5ef59-658c-b30e-c254-21f3d89f190f@oracle.com> References: <22d5ef59-658c-b30e-c254-21f3d89f190f@oracle.com> Message-ID: <7D3E2B82-F9B3-4E3D-8551-40296BF29A47@oracle.com> Your changes look fine to me. Just a minor language correction: ?to use? -> ?using? (2 instances) > On 11 Nov 2016, at 05:11, Xuelei Fan wrote: > > Hi, > > Please review this bug fix: > > http://cr.openjdk.java.net/~xuelei/8166103/webrev.00/ > > The current validator implementations only allow white listed critical certificate extensions, and not all JDK supported extensions are known to the validator. As may result in some issues that the cert is valid, but cannot pass the validation because there is a critical extension that is not white listed in the validator implementation. > > This fix will only check the validity of the white listed critical certificate extensions, and ignore the critical certificate extensions if they can be parsed with X509Certificate. > > Thanks, > Xuelei From vincent.x.ryan at oracle.com Fri Nov 11 18:07:49 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 11 Nov 2016 18:07:49 +0000 Subject: RFR: 8168861 AnchorCertificates uses hardcoded password for cacerts keystore In-Reply-To: <5824ECDD.1020407@oracle.com> References: <5824ECDD.1020407@oracle.com> Message-ID: <22EBE444-E059-49F2-8691-E64792E0C779@oracle.com> Your fix looks good to me Tony. Thanks. > On 10 Nov 2016, at 21:55, Anthony Scarpino wrote: > > Hi, > > I need a one line review to null out the password field in the keystore load op.. > > http://cr.openjdk.java.net/~ascarpino/8168861/webrev/ > > thanks > > Tony From bdhess at pobox.com Fri Nov 11 19:25:56 2016 From: bdhess at pobox.com (Bradley Hess) Date: Fri, 11 Nov 2016 19:25:56 +0000 Subject: Code Review Request, JDK-8166103 Allow certs with unknown critical extension in SunX509 validator In-Reply-To: <7D3E2B82-F9B3-4E3D-8551-40296BF29A47@oracle.com> References: <22d5ef59-658c-b30e-c254-21f3d89f190f@oracle.com> <7D3E2B82-F9B3-4E3D-8551-40296BF29A47@oracle.com> Message-ID: The test case fails for me against JDK 1.7.0_05 and 1.8.0_20 -- the SunX509 validator complains about the presence of the critical extension. Contrary to what the OP suggested in the bug report, it doesn't seem like this behavior is new. Plenty of implementations in the wild (e.g. Tomcat) either hardcode SunX509 or rely on getDefaultAlgorithm, which returns SunX509. I would imagine that in most cases, and especially in cases where the TrustManagerFactory is being instantiated by a web container using platform defaults, that there's no user code that does further checking. To me this change seems both breaking and inconsistent with RFC 5280. On Fri, Nov 11, 2016 at 12:47 PM Vincent Ryan wrote: > Your changes look fine to me. > Just a minor language correction: ?to use? -> ?using? (2 instances) > > > On 11 Nov 2016, at 05:11, Xuelei Fan wrote: > > > > Hi, > > > > Please review this bug fix: > > > > http://cr.openjdk.java.net/~xuelei/8166103/webrev.00/ > > > > The current validator implementations only allow white listed critical > certificate extensions, and not all JDK supported extensions are known to > the validator. As may result in some issues that the cert is valid, but > cannot pass the validation because there is a critical extension that is > not white listed in the validator implementation. > > > > This fix will only check the validity of the white listed critical > certificate extensions, and ignore the critical certificate extensions if > they can be parsed with X509Certificate. > > > > Thanks, > > Xuelei > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mallikarjuna.avaluri at oracle.com Mon Nov 14 05:02:36 2016 From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri) Date: Mon, 14 Nov 2016 10:32:36 +0530 Subject: RFR 8164881: Add more tests for JDK-8139565. Message-ID: Hi all, Please review the fix for following issue. JDK-8164881: Add more tests for JDK-8139565 https://bugs.openjdk.java.net/browse/JDK-8164881 *Summary:* Currently test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java checks only that DSA keys with size of 512 bits are disabled. But we also need to check that DSA keys with sizes 1024 & 2048 are working fine. *Fix: * Currently test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java checks only that DSA keys with size of 512 bits are disabled. Added new tests with DSA keys with size of 960 bits disabled, 1024, 2048, 3072 bits enabled. *Webrev: * http://cr.openjdk.java.net/~bgopularam/mavaluri/JDK-8164881/webrev.00/ Thanks, Mallikarjuna Avaluri -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Nov 14 13:22:37 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Nov 2016 08:22:37 -0500 Subject: RFR: 8168861 AnchorCertificates uses hardcoded password for cacerts keystore In-Reply-To: <5824ECDD.1020407@oracle.com> References: <5824ECDD.1020407@oracle.com> Message-ID: Looks good, please add an appropriate noreg label (probably noreg-trivial) to the bug. --Sean On 11/10/16 4:55 PM, Anthony Scarpino wrote: > Hi, > > I need a one line review to null out the password field in the keystore > load op.. > > http://cr.openjdk.java.net/~ascarpino/8168861/webrev/ > > thanks > > Tony From anthony.scarpino at oracle.com Mon Nov 14 18:45:36 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 14 Nov 2016 10:45:36 -0800 Subject: RFR 8168931: Few OCSP related test failed with "Response is unreliable: its validity interval is out-of-date" Message-ID: <582A0650.5050003@oracle.com> Hi, I need a review of a one liner to revert the PKIXParameter date argument back to null, aka current time. http://cr.openjdk.java.net/~ascarpino/8168931/webrev/ thanks Tony From sean.mullan at oracle.com Mon Nov 14 21:05:58 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Nov 2016 16:05:58 -0500 Subject: RFR 8168931: Few OCSP related test failed with "Response is unreliable: its validity interval is out-of-date" In-Reply-To: <582A0650.5050003@oracle.com> References: <582A0650.5050003@oracle.com> Message-ID: <0e658f0b-945d-e393-3b51-3a6a37a7f867@oracle.com> Looks good. --Sean On 11/14/16 1:45 PM, Anthony Scarpino wrote: > Hi, > > I need a review of a one liner to revert the PKIXParameter date argument > back to null, aka current time. > > http://cr.openjdk.java.net/~ascarpino/8168931/webrev/ > > thanks > > Tony From bradford.wetmore at oracle.com Tue Nov 15 19:31:03 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 15 Nov 2016 11:31:03 -0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist Message-ID: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> Simple codereview: http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 The "crypto.policy" Security property is normally defined/configured in the java.security file at build time. (e.g. "limited" or "unlimited") Rather than currently failing catastrophically if this value doesn't exist, there should be a sensible default if it is undeclared for whatever reason. We will use a sane fallback value of "limited". If the distribution has also removed the "limited" policy directory then the VM will still fail to initialize, but we have at least made an effort to recover. Thanks, Brad From artem.smotrakov at oracle.com Tue Nov 15 22:41:08 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 15 Nov 2016 14:41:08 -0800 Subject: RFR 8164881: Add more tests for JDK-8139565. In-Reply-To: References: Message-ID: Hi Mallikarjuna, I have a couple of comments. 1. I see you extract DSA key size from "jdk.certpath.disabledAlgorithms" security property. I think I would be better not to rely on it, but expect that keys less than 1024 bits are not allowed by default. You can pass a boolean parameter to the test which defines what should be expected. 2. We are trying not to use lines more than 80 symbols. Could you please fix it? 3. Minor: DSAKeys.java line 342, you don't need to specify types for HashMap 4. It is up to you, but it would be good to update the test to use SSTest.java (see examples in jdk/tests) because we've been seeing intermittent failures of JSSE tests like this one you are updating http://hg.openjdk.java.net/jdk9/dev/jdk/file/93fb16cbdf7f/test/javax/net/ssl/templates/SSLTest.java Artem On 11/13/2016 09:02 PM, Mallikarjuna Avaluri wrote: > > Hi all, > > Please review the fix for following issue. > > JDK-8164881: Add more tests for JDK-8139565 > https://bugs.openjdk.java.net/browse/JDK-8164881 > > *Summary:* Currently > test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java checks only that > DSA keys with size of 512 bits are disabled. > But we also need to check that DSA keys with sizes 1024 & 2048 are > working fine. > > > *Fix: * Currently test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java > checks only that DSA keys with size of 512 bits are disabled. > Added new tests with DSA keys with size of 960 bits disabled, 1024, > 2048, 3072 bits enabled. > > *Webrev: * > http://cr.openjdk.java.net/~bgopularam/mavaluri/JDK-8164881/webrev.00/ > > > > Thanks, > Mallikarjuna Avaluri -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Nov 16 00:12:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 08:12:48 +0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> Message-ID: <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> You create a debug field with a prefix string and then check both debug != null and Debug.isOn("policy") and then use System.out.println to print the message. Something must be useless. --Max > On Nov 16, 2016, at 3:31 AM, Bradford Wetmore wrote: > > Simple codereview: > > http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 > > The "crypto.policy" Security property is normally defined/configured in the java.security file at build time. (e.g. "limited" or "unlimited") Rather than currently failing catastrophically if this value doesn't exist, there should be a sensible default if it is undeclared for whatever reason. We will use a sane fallback value of "limited". > > If the distribution has also removed the "limited" policy directory then the VM will still fail to initialize, but we have at least made an effort to recover. > > Thanks, > > Brad > From jamil.j.nimeh at oracle.com Wed Nov 16 00:36:22 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 15 Nov 2016 16:36:22 -0800 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain Message-ID: <6d221522-44ce-755a-c916-e4c20da2862a@oracle.com> Hello all, This fixes an issue in ProtectionDomain, where Permission classes that take a loose interpretation of the getActions() method and return null cause an NPE to be thrown when a ProtectionDomain's toString method is called (during debugging for instance). Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ Thanks, --Jamil From bradford.wetmore at oracle.com Wed Nov 16 00:40:40 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 15 Nov 2016 16:40:40 -0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> Message-ID: Never noticed that before! We have NOT been consistent in whether we use: System.out.println() or debug.println() I knew SeanC wants to rework the JCA/JCE/Security debugging output in another project, so I will remove the prefix for now. Thanks for catching it. I will also add a simple regression Test before I push. In hindsight, it's not as trivial a change as I initially thought. If you want to review it, I can wait until you are back tomorrow. Brad On 11/15/2016 4:12 PM, Wang Weijun wrote: > You create a debug field with a prefix string and then check both debug != null and Debug.isOn("policy") and then use System.out.println to print the message. Something must be useless. > > --Max > >> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore wrote: >> >> Simple codereview: >> >> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >> >> The "crypto.policy" Security property is normally defined/configured in the java.security file at build time. (e.g. "limited" or "unlimited") Rather than currently failing catastrophically if this value doesn't exist, there should be a sensible default if it is undeclared for whatever reason. We will use a sane fallback value of "limited". >> >> If the distribution has also removed the "limited" policy directory then the VM will still fail to initialize, but we have at least made an effort to recover. >> >> Thanks, >> >> Brad >> > From weijun.wang at oracle.com Wed Nov 16 02:18:31 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 10:18:31 +0800 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain In-Reply-To: <6d221522-44ce-755a-c916-e4c20da2862a@oracle.com> References: <6d221522-44ce-755a-c916-e4c20da2862a@oracle.com> Message-ID: 41 System.setSecurityManager(new SecurityManager()); This is strange. I suppose you only want to trigger a permission check? If so, just change it to Policy.getPolicy(), and you can clean up the policy file a little. Thanks Max > On Nov 16, 2016, at 8:36 AM, Jamil Nimeh wrote: > > Hello all, > > This fixes an issue in ProtectionDomain, where Permission classes that take a loose interpretation of the getActions() method and return null cause an NPE to be thrown when a ProtectionDomain's toString method is called (during debugging for instance). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ > > Thanks, > --Jamil From weijun.wang at oracle.com Wed Nov 16 02:40:20 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 10:40:20 +0800 Subject: RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris Message-ID: <389F80CF-7EBA-46F3-8C39-F886F5A6619E@oracle.com> Please take a review at 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris Different service names are used in the 2 tests (rcache_usemd5.sh and ReplayCacheTestProc.java) now. Thanks Max From artem.smotrakov at oracle.com Wed Nov 16 02:44:01 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 15 Nov 2016 18:44:01 -0800 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> <93642848-56fe-6362-85ed-0d3d7bdeefbb@oracle.com> Message-ID: <23504943-9720-00a4-c643-986a6f20bb43@oracle.com> I don't like it, but no lambdas, no nothing in SSLSocketTemplate.java http://cr.openjdk.java.net/~asmotrak/8168969/webrev.01/ Xuelei, Could you please take a look? Artem On 11/02/2016 09:14 AM, Artem Smotrakov wrote: > Hi Xuelei, > > This totally makes sense. But in my opinion we should use new features > and APIs because: > - they are here to make code readable (okay, not to much lambdas) > - they help to avoid bugs (e.g., forgetting to close resources) > - we implicitly provide test coverage for new APIs > - we give examples how these features can be used > - finally, we encourage people to move to new Java versions > > Not sure if I got correction what you mean by removing the part to > declare the store files in each sub-classes. Do you mean getting rid > of setting keystore/truststore in actual test files? > > If so, I would prefer to do it in a separate enhancement. Most of > SSL/TLS tests use keystores from "etc" directory. The test use > "test.src" system property (set by jtreg) to build a path to "etc", > and it depends on actual directory where a test stays. Also if I > recall correctly, some tests use their own keystore. This update may > be quite big. Would you mind if we did it separately? > > 8168969 is about merging helper classes to remove possible confusions > Brad mentioned recently. > > Artem > > On 11/02/2016 03:57 AM, Xuelei Fan wrote: >> Please use JDK 6 only features (no Lambda, try-with-resource, >> multi-catch, java.util.Objects, etc.) so as to expedite porting to >> previous releases. >> >> It would be nice if removing the part to declare the store files in >> each sub-classes. >> >> Xuelei >> >> On 11/2/2016 2:48 PM, John Jiang wrote: >>> Hi Artem, >>> Thanks for making the template to be used easily. >>> >>> The tests in your patch extend class SSLSocketTemplate, but >>> SSLSocketTemplate looks like an utility class, but not a parent class. >>> For example, >>> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >>> >>> 67 new SSLSocketTemplate() >>> AnonCipherWithWantClientAuth still creates a SSLSocketTemplate >>> instance, >>> but not itself. >>> In fact, if replacing "print()" with "SSLSocketTemplate.print()", >>> AnonCipherWithWantClientAuth can work fine without extending >>> SSLSocketTemplate. >>> >>> The original SSLSocketSample.java defines the core methods, such as >>> doServerSide(), runServerApplication(), doClientSide() and >>> runClientApplication(), as non-static. In my eyes, this style may be >>> better. The child class can simply override the methods if necessary. >>> >>> In addition, some tests have to configure SSLServerSocket. Why not >>> provide one more extension point in doServerSide()? Then, it >>> unnecessary >>> to re-write the whole doServerSide() (or, set a new server peer). >>> The code talks more clearly. Please take a look at my example: >>> http://cr.openjdk.java.net/~jjiang/8168969/example/ >>> >>> Best regards, >>> John Jiang >>> >>> On 2016/11/2 8:54, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review the following patch which merges a couple of classes in >>>> javax/net/ssl/templates. >>>> >>>> SSLTest class contains re-usable parts of SSLSocketSample. >>>> SSLSocketTemplate class is buggy (tests which follows it may fail >>>> intermittently). I basically replaced SSLSocketTemplate with SSLTest, >>>> and removed SSLSocketSample. >>>> >>>> SSL/TLS tests should use SSLSocketTemplate class. I updated test which >>>> use SSLTest to use SSLSocketTemplate. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >>>> >>>> Artem >>>> >>> > From xuelei.fan at oracle.com Wed Nov 16 02:52:43 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Nov 2016 10:52:43 +0800 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <23504943-9720-00a4-c643-986a6f20bb43@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> <93642848-56fe-6362-85ed-0d3d7bdeefbb@oracle.com> <23504943-9720-00a4-c643-986a6f20bb43@oracle.com> Message-ID: <558ee9c3-dc31-8c45-a04e-86f17f1557bb@oracle.com> I don't like it, too. It is not necessary to make the merge in a hurry. Maybe, we can wait for a while so that we have time for a real and comfortable template. Thanks, Xuelei On 11/16/2016 10:44 AM, Artem Smotrakov wrote: > I don't like it, but no lambdas, no nothing in SSLSocketTemplate.java > > http://cr.openjdk.java.net/~asmotrak/8168969/webrev.01/ > > Xuelei, > > Could you please take a look? > > Artem > > > On 11/02/2016 09:14 AM, Artem Smotrakov wrote: >> Hi Xuelei, >> >> This totally makes sense. But in my opinion we should use new features >> and APIs because: >> - they are here to make code readable (okay, not to much lambdas) >> - they help to avoid bugs (e.g., forgetting to close resources) >> - we implicitly provide test coverage for new APIs >> - we give examples how these features can be used >> - finally, we encourage people to move to new Java versions >> >> Not sure if I got correction what you mean by removing the part to >> declare the store files in each sub-classes. Do you mean getting rid >> of setting keystore/truststore in actual test files? >> >> If so, I would prefer to do it in a separate enhancement. Most of >> SSL/TLS tests use keystores from "etc" directory. The test use >> "test.src" system property (set by jtreg) to build a path to "etc", >> and it depends on actual directory where a test stays. Also if I >> recall correctly, some tests use their own keystore. This update may >> be quite big. Would you mind if we did it separately? >> >> 8168969 is about merging helper classes to remove possible confusions >> Brad mentioned recently. >> >> Artem >> >> On 11/02/2016 03:57 AM, Xuelei Fan wrote: >>> Please use JDK 6 only features (no Lambda, try-with-resource, >>> multi-catch, java.util.Objects, etc.) so as to expedite porting to >>> previous releases. >>> >>> It would be nice if removing the part to declare the store files in >>> each sub-classes. >>> >>> Xuelei >>> >>> On 11/2/2016 2:48 PM, John Jiang wrote: >>>> Hi Artem, >>>> Thanks for making the template to be used easily. >>>> >>>> The tests in your patch extend class SSLSocketTemplate, but >>>> SSLSocketTemplate looks like an utility class, but not a parent class. >>>> For example, >>>> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >>>> >>>> 67 new SSLSocketTemplate() >>>> AnonCipherWithWantClientAuth still creates a SSLSocketTemplate >>>> instance, >>>> but not itself. >>>> In fact, if replacing "print()" with "SSLSocketTemplate.print()", >>>> AnonCipherWithWantClientAuth can work fine without extending >>>> SSLSocketTemplate. >>>> >>>> The original SSLSocketSample.java defines the core methods, such as >>>> doServerSide(), runServerApplication(), doClientSide() and >>>> runClientApplication(), as non-static. In my eyes, this style may be >>>> better. The child class can simply override the methods if necessary. >>>> >>>> In addition, some tests have to configure SSLServerSocket. Why not >>>> provide one more extension point in doServerSide()? Then, it >>>> unnecessary >>>> to re-write the whole doServerSide() (or, set a new server peer). >>>> The code talks more clearly. Please take a look at my example: >>>> http://cr.openjdk.java.net/~jjiang/8168969/example/ >>>> >>>> Best regards, >>>> John Jiang >>>> >>>> On 2016/11/2 8:54, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review the following patch which merges a couple of classes in >>>>> javax/net/ssl/templates. >>>>> >>>>> SSLTest class contains re-usable parts of SSLSocketSample. >>>>> SSLSocketTemplate class is buggy (tests which follows it may fail >>>>> intermittently). I basically replaced SSLSocketTemplate with SSLTest, >>>>> and removed SSLSocketSample. >>>>> >>>>> SSL/TLS tests should use SSLSocketTemplate class. I updated test which >>>>> use SSLTest to use SSLSocketTemplate. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >>>>> >>>>> Artem >>>>> >>>> >> > From weijun.wang at oracle.com Wed Nov 16 02:55:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 10:55:14 +0800 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: <9a14d653-358c-3d22-065f-079fd0cf2d4e@oracle.com> Please review the updated webrev at http://cr.openjdk.java.net/~weijun/7004967/webrev.02/ Only spec change [1]. This change also covers 8169312. Thanks Max [1] http://cr.openjdk.java.net/~weijun/7004967/webrev.02/interdiff.patch.html On 11/4/2016 10:54 PM, Sean Mullan wrote: > * SecureRandom > > 131 * If this attribute is not set or is "false", this class will instead > 132 * synchronize access to each of the methods of the {@code > SecureRandomSpi} > 133 * implementation. > > Not all of the methods are synchronized - engineGetParameters is not, > for example. I think to avoid ambiguity, you should list the names of > the methods that are synchronized. > > 810 * @throws IllegalArgumentException if {@code numBytes} is negative > > Since this is a new @throws, you really need to file a new bug. > > Please also file a docs bug with a description of the new attribute. > > * SecureRandomSpi > > lines 63-83, I think the wording could be improved/simplified, how about: > > See {@link SecureRandom} for additional details on thread safety. By > default, a SecureRandomSpi implementation is considered to be not safe > for use by multiple concurrent threads and SecureRandom will synchronize > access to each of the applicable engine methods (see SecureRandom for > the list of methods). However, if a SecureRandomSpi implementation is > thread-safe, the href="{@docRoot}/../technotes/guides/security/StandardNames.html#Service">service > provider attribute "ThreadSafe" should be set to "true" during its > registration, as follows: > > put("SecureRandom.AlgName ThreadSafe", "true"); > > or > > putService(new Service(this, "SecureRandom", "AlgName", className, > null, Map.of("ThreadSafe", "true"))); > > {@code SecureRandom} will then call the applicable engine methods > without any synchronization. > > --Sean > > On 11/2/16 3:27 AM, Wang Weijun wrote: >> Ping again. >> >> There is an updated version at >> http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only >> changes. >> >> Thanks >> Max >> >>> On Aug 25, 2016, at 10:00 AM, Weijun Wang >>> wrote: >>> >>> Please review the enhancement at >>> >>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>> >>> Basically, we want SecureRandom to be more efficient by removing all >>> synchronized keywords from its public methods and let an >>> implementation to take care of thread-safety (We already did some in >>> JDK-8098581). On the other hand, we need to make sure that existing >>> implementations that have not synchronized correctly to behave just >>> as good as before. >>> >>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you >>> think your implementation is already thread-safe, set it to "true" >>> and SecureRandom will be happy. Otherwise, don't set it and >>> SecureRandom will continuously call your SecureRandomSpi engine >>> methods in synchronized blocks. >>> >>> Thanks >>> Max >> From weijun.wang at oracle.com Wed Nov 16 03:23:57 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 11:23:57 +0800 Subject: RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris In-Reply-To: <389F80CF-7EBA-46F3-8C39-F886F5A6619E@oracle.com> References: <389F80CF-7EBA-46F3-8C39-F886F5A6619E@oracle.com> Message-ID: Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/ --Max > On Nov 16, 2016, at 10:40 AM, Wang Weijun wrote: > > Please take a review at > > 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris > > Different service names are used in the 2 tests (rcache_usemd5.sh and ReplayCacheTestProc.java) now. > > Thanks > Max > From xuelei.fan at oracle.com Wed Nov 16 03:30:48 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Nov 2016 11:30:48 +0800 Subject: RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris In-Reply-To: References: <389F80CF-7EBA-46F3-8C39-F886F5A6619E@oracle.com> Message-ID: Looks like a little bit hack, but fine to me. BTW, is it more convenient to have 2 run tags in ReplayCacheTestProc.java? Xuelei On 11/16/2016 11:23 AM, Wang Weijun wrote: > Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/ > > --Max > >> On Nov 16, 2016, at 10:40 AM, Wang Weijun wrote: >> >> Please take a review at >> >> 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris >> >> Different service names are used in the 2 tests (rcache_usemd5.sh and ReplayCacheTestProc.java) now. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Nov 16 03:32:36 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 11:32:36 +0800 Subject: RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris In-Reply-To: References: <389F80CF-7EBA-46F3-8C39-F886F5A6619E@oracle.com> Message-ID: <9505530B-208F-40DF-911D-E7B7386DB0F1@oracle.com> > On Nov 16, 2016, at 11:30 AM, Xuelei Fan wrote: > > Looks like a little bit hack, but fine to me. Thanks. > > BTW, is it more convenient to have 2 run tags in ReplayCacheTestProc.java? I'd like to run ReplayCacheTestProc.java manually (still using jtreg) with various test.* properties. Having 2 run tags double the time and not what I wanted. --Max > > Xuelei > > On 11/16/2016 11:23 AM, Wang Weijun wrote: >> Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/ >> >> --Max >> >>> On Nov 16, 2016, at 10:40 AM, Wang Weijun wrote: >>> >>> Please take a review at >>> >>> 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris >>> >>> Different service names are used in the 2 tests (rcache_usemd5.sh and ReplayCacheTestProc.java) now. >>> >>> Thanks >>> Max >>> >> From jamil.j.nimeh at oracle.com Wed Nov 16 03:45:45 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 15 Nov 2016 19:45:45 -0800 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain In-Reply-To: References: <6d221522-44ce-755a-c916-e4c20da2862a@oracle.com> Message-ID: <0eeedf47-a28a-38d7-5723-971e1ca9e019@oracle.com> Good suggestions, thanks. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02 --Jamil On 11/15/2016 06:18 PM, Wang Weijun wrote: > 41 System.setSecurityManager(new SecurityManager()); > > This is strange. I suppose you only want to trigger a permission check? > > If so, just change it to Policy.getPolicy(), and you can clean up the policy file a little. > > Thanks > Max > >> On Nov 16, 2016, at 8:36 AM, Jamil Nimeh wrote: >> >> Hello all, >> >> This fixes an issue in ProtectionDomain, where Permission classes that take a loose interpretation of the getActions() method and return null cause an NPE to be thrown when a ProtectionDomain's toString method is called (during debugging for instance). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ >> >> Thanks, >> --Jamil From weijun.wang at oracle.com Wed Nov 16 03:48:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 11:48:32 +0800 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain In-Reply-To: <0eeedf47-a28a-38d7-5723-971e1ca9e019@oracle.com> References: <6d221522-44ce-755a-c916-e4c20da2862a@oracle.com> <0eeedf47-a28a-38d7-5723-971e1ca9e019@oracle.com> Message-ID: Looks fine. Small nit: new test has copyright 2003, 2016. --Max > On Nov 16, 2016, at 11:45 AM, Jamil Nimeh wrote: > > Good suggestions, thanks. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02 > > --Jamil > > > On 11/15/2016 06:18 PM, Wang Weijun wrote: >> 41 System.setSecurityManager(new SecurityManager()); >> >> This is strange. I suppose you only want to trigger a permission check? >> >> If so, just change it to Policy.getPolicy(), and you can clean up the policy file a little. >> >> Thanks >> Max >> >>> On Nov 16, 2016, at 8:36 AM, Jamil Nimeh wrote: >>> >>> Hello all, >>> >>> This fixes an issue in ProtectionDomain, where Permission classes that take a loose interpretation of the getActions() method and return null cause an NPE to be thrown when a ProtectionDomain's toString method is called (during debugging for instance). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ >>> >>> Thanks, >>> --Jamil > From xuelei.fan at oracle.com Wed Nov 16 03:50:21 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Nov 2016 11:50:21 +0800 Subject: [9] RFR: 8168969: Merge SSLSocketSample and SSLSocketTemplate In-Reply-To: <558ee9c3-dc31-8c45-a04e-86f17f1557bb@oracle.com> References: <3fafdfa3-3ace-df9d-9635-560204dec739@oracle.com> <08ae545e-4a5b-ee35-94f9-a6fe492072c4@oracle.com> <93642848-56fe-6362-85ed-0d3d7bdeefbb@oracle.com> <23504943-9720-00a4-c643-986a6f20bb43@oracle.com> <558ee9c3-dc31-8c45-a04e-86f17f1557bb@oracle.com> Message-ID: I don't like it, but as the 1st stage of the improvement, it looks fine to me. Xuelei On 11/16/2016 10:52 AM, Xuelei Fan wrote: > I don't like it, too. It is not necessary to make the merge in a hurry. > Maybe, we can wait for a while so that we have time for a real and > comfortable template. > > Thanks, > Xuelei > > On 11/16/2016 10:44 AM, Artem Smotrakov wrote: >> I don't like it, but no lambdas, no nothing in SSLSocketTemplate.java >> >> http://cr.openjdk.java.net/~asmotrak/8168969/webrev.01/ >> >> Xuelei, >> >> Could you please take a look? >> >> Artem >> >> >> On 11/02/2016 09:14 AM, Artem Smotrakov wrote: >>> Hi Xuelei, >>> >>> This totally makes sense. But in my opinion we should use new features >>> and APIs because: >>> - they are here to make code readable (okay, not to much lambdas) >>> - they help to avoid bugs (e.g., forgetting to close resources) >>> - we implicitly provide test coverage for new APIs >>> - we give examples how these features can be used >>> - finally, we encourage people to move to new Java versions >>> >>> Not sure if I got correction what you mean by removing the part to >>> declare the store files in each sub-classes. Do you mean getting rid >>> of setting keystore/truststore in actual test files? >>> >>> If so, I would prefer to do it in a separate enhancement. Most of >>> SSL/TLS tests use keystores from "etc" directory. The test use >>> "test.src" system property (set by jtreg) to build a path to "etc", >>> and it depends on actual directory where a test stays. Also if I >>> recall correctly, some tests use their own keystore. This update may >>> be quite big. Would you mind if we did it separately? >>> >>> 8168969 is about merging helper classes to remove possible confusions >>> Brad mentioned recently. >>> >>> Artem >>> >>> On 11/02/2016 03:57 AM, Xuelei Fan wrote: >>>> Please use JDK 6 only features (no Lambda, try-with-resource, >>>> multi-catch, java.util.Objects, etc.) so as to expedite porting to >>>> previous releases. >>>> >>>> It would be nice if removing the part to declare the store files in >>>> each sub-classes. >>>> >>>> Xuelei >>>> >>>> On 11/2/2016 2:48 PM, John Jiang wrote: >>>>> Hi Artem, >>>>> Thanks for making the template to be used easily. >>>>> >>>>> The tests in your patch extend class SSLSocketTemplate, but >>>>> SSLSocketTemplate looks like an utility class, but not a parent class. >>>>> For example, >>>>> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >>>>> >>>>> >>>>> 67 new SSLSocketTemplate() >>>>> AnonCipherWithWantClientAuth still creates a SSLSocketTemplate >>>>> instance, >>>>> but not itself. >>>>> In fact, if replacing "print()" with "SSLSocketTemplate.print()", >>>>> AnonCipherWithWantClientAuth can work fine without extending >>>>> SSLSocketTemplate. >>>>> >>>>> The original SSLSocketSample.java defines the core methods, such as >>>>> doServerSide(), runServerApplication(), doClientSide() and >>>>> runClientApplication(), as non-static. In my eyes, this style may be >>>>> better. The child class can simply override the methods if necessary. >>>>> >>>>> In addition, some tests have to configure SSLServerSocket. Why not >>>>> provide one more extension point in doServerSide()? Then, it >>>>> unnecessary >>>>> to re-write the whole doServerSide() (or, set a new server peer). >>>>> The code talks more clearly. Please take a look at my example: >>>>> http://cr.openjdk.java.net/~jjiang/8168969/example/ >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>>> On 2016/11/2 8:54, Artem Smotrakov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following patch which merges a couple of classes in >>>>>> javax/net/ssl/templates. >>>>>> >>>>>> SSLTest class contains re-usable parts of SSLSocketSample. >>>>>> SSLSocketTemplate class is buggy (tests which follows it may fail >>>>>> intermittently). I basically replaced SSLSocketTemplate with SSLTest, >>>>>> and removed SSLSocketSample. >>>>>> >>>>>> SSL/TLS tests should use SSLSocketTemplate class. I updated test >>>>>> which >>>>>> use SSLTest to use SSLSocketTemplate. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168969 >>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8168969/webrev.00/ >>>>>> >>>>>> Artem >>>>>> >>>>> >>> >> From jamil.j.nimeh at oracle.com Wed Nov 16 04:40:42 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 15 Nov 2016 20:40:42 -0800 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain Message-ID: Oops, good catch. I'll fix that. ?I assume you don't need a third review for that? --Jamil -------- Original message --------From: Wang Weijun Date: 11/15/16 7:48 PM (GMT-08:00) To: Jamil Nimeh Cc: security-dev at openjdk.java.net Subject: Re: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain Looks fine. Small nit: new test has copyright 2003, 2016. --Max > On Nov 16, 2016, at 11:45 AM, Jamil Nimeh wrote: > > Good suggestions, thanks. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02 > > --Jamil > > > On 11/15/2016 06:18 PM, Wang Weijun wrote: >> 41???????? System.setSecurityManager(new SecurityManager()); >> >> This is strange. I suppose you only want to trigger a permission check? >> >> If so, just change it to Policy.getPolicy(), and you can clean up the policy file a little. >> >> Thanks >> Max >> >>> On Nov 16, 2016, at 8:36 AM, Jamil Nimeh wrote: >>> >>> Hello all, >>> >>> This fixes an issue in ProtectionDomain, where Permission classes that take a loose interpretation of the getActions() method and return null cause an NPE to be thrown when a ProtectionDomain's toString method is called (during debugging for instance). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ >>> >>> Thanks, >>> --Jamil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Nov 16 04:55:06 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Nov 2016 12:55:06 +0800 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain In-Reply-To: References: Message-ID: <10A05776-0FB3-4A64-8A88-986743039CAE@oracle.com> > On Nov 16, 2016, at 12:40 PM, Jamil Nimeh wrote: > > Oops, good catch. I'll fix that. I assume you don't need a third review for that? No. Just push your change. --Max > > > > --Jamil > > -------- Original message -------- > From: Wang Weijun > Date: 11/15/16 7:48 PM (GMT-08:00) > To: Jamil Nimeh > Cc: security-dev at openjdk.java.net > Subject: Re: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain > > Looks fine. > > Small nit: new test has copyright 2003, 2016. > > --Max > > > On Nov 16, 2016, at 11:45 AM, Jamil Nimeh wrote: > > > > Good suggestions, thanks. > > > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02 > > > > --Jamil > > > > > > On 11/15/2016 06:18 PM, Wang Weijun wrote: > >> 41 System.setSecurityManager(new SecurityManager()); > >> > >> This is strange. I suppose you only want to trigger a permission check? > >> > >> If so, just change it to Policy.getPolicy(), and you can clean up the policy file a little. > >> > >> Thanks > >> Max > >> > >>> On Nov 16, 2016, at 8:36 AM, Jamil Nimeh wrote: > >>> > >>> Hello all, > >>> > >>> This fixes an issue in ProtectionDomain, where Permission classes that take a loose interpretation of the getActions() method and return null cause an NPE to be thrown when a ProtectionDomain's toString method is called (during debugging for instance). > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 > >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ > >>> > >>> Thanks, > >>> --Jamil > > > From sean.coffey at oracle.com Wed Nov 16 14:21:52 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 16 Nov 2016 14:21:52 +0000 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> Message-ID: <582C6B80.4030408@oracle.com> In the recent jdk8u-dev edits of this file for 8157561, we introduced a debug field based on this key : Debug.getInstance("jca", "Cipher"); Can we continue to use 'jca' to be consistent for people upgrading ? for the testcase, I guess you can edit test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll have to launch with a customized java.security file which doesn't have crypto.policy set. (Security.setProperty doesn't allow null values) Regards, Sean. On 16/11/16 00:40, Bradford Wetmore wrote: > Never noticed that before! We have NOT been consistent in whether we > use: > > System.out.println() > or > debug.println() > > I knew SeanC wants to rework the JCA/JCE/Security debugging output in > another project, so I will remove the prefix for now. Thanks for > catching it. > > I will also add a simple regression Test before I push. In hindsight, > it's not as trivial a change as I initially thought. If you want to > review it, I can wait until you are back tomorrow. > > Brad > > > On 11/15/2016 4:12 PM, Wang Weijun wrote: >> You create a debug field with a prefix string and then check both >> debug != null and Debug.isOn("policy") and then use >> System.out.println to print the message. Something must be useless. >> >> --Max >> >>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>> wrote: >>> >>> Simple codereview: >>> >>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>> >>> The "crypto.policy" Security property is normally defined/configured >>> in the java.security file at build time. (e.g. "limited" or >>> "unlimited") Rather than currently failing catastrophically if this >>> value doesn't exist, there should be a sensible default if it is >>> undeclared for whatever reason. We will use a sane fallback value of >>> "limited". >>> >>> If the distribution has also removed the "limited" policy directory >>> then the VM will still fail to initialize, but we have at least made >>> an effort to recover. >>> >>> Thanks, >>> >>> Brad >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Nov 16 16:27:28 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 16 Nov 2016 11:27:28 -0500 Subject: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain In-Reply-To: <0eeedf47-a28a-38d7-5723-971e1ca9e019@oracle.com> References: <6d221522-44ce-755a-c916-e4c20da2862a@oracle.com> <0eeedf47-a28a-38d7-5723-971e1ca9e019@oracle.com> Message-ID: <1f1e720c-28b9-7297-88c7-092e09ac6c80@oracle.com> Looks fine. --Sean On 11/15/16 10:45 PM, Jamil Nimeh wrote: > Good suggestions, thanks. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.02 > > --Jamil > > > On 11/15/2016 06:18 PM, Wang Weijun wrote: >> 41 System.setSecurityManager(new SecurityManager()); >> >> This is strange. I suppose you only want to trigger a permission check? >> >> If so, just change it to Policy.getPolicy(), and you can clean up the >> policy file a little. >> >> Thanks >> Max >> >>> On Nov 16, 2016, at 8:36 AM, Jamil Nimeh >>> wrote: >>> >>> Hello all, >>> >>> This fixes an issue in ProtectionDomain, where Permission classes >>> that take a loose interpretation of the getActions() method and >>> return null cause an NPE to be thrown when a ProtectionDomain's >>> toString method is called (during debugging for instance). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043252 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8043252/webrev.01/ >>> >>> Thanks, >>> --Jamil > From bradford.wetmore at oracle.com Wed Nov 16 22:10:01 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Nov 2016 14:10:01 -0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <582C6B80.4030408@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> Message-ID: <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> Current iteration: http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 Changes: 1. Using Debug "jca" instead of "policy" 2. Using debug.println (System.err), as the other jca calls are also using it. 3. Added regression test. Strips out any crypto.policy entry to create a new file, then uses it. 4. Updated webrev with bugid/reviewers. Brad On 11/16/2016 6:21 AM, Se?n Coffey wrote: > In the recent jdk8u-dev edits of this file for 8157561, we introduced a > debug field based on this key : > > Debug.getInstance("jca", "Cipher"); > > Can we continue to use 'jca' to be consistent for people upgrading ? > > for the testcase, I guess you can edit > test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll have to > launch with a customized java.security file which doesn't have > crypto.policy set. (Security.setProperty doesn't allow null values) > > Regards, > Sean. > > On 16/11/16 00:40, Bradford Wetmore wrote: >> Never noticed that before! We have NOT been consistent in whether we >> use: >> >> System.out.println() >> or >> debug.println() >> >> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >> another project, so I will remove the prefix for now. Thanks for >> catching it. >> >> I will also add a simple regression Test before I push. In hindsight, >> it's not as trivial a change as I initially thought. If you want to >> review it, I can wait until you are back tomorrow. >> >> Brad >> >> >> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>> You create a debug field with a prefix string and then check both >>> debug != null and Debug.isOn("policy") and then use >>> System.out.println to print the message. Something must be useless. >>> >>> --Max >>> >>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>> wrote: >>>> >>>> Simple codereview: >>>> >>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>> >>>> The "crypto.policy" Security property is normally defined/configured >>>> in the java.security file at build time. (e.g. "limited" or >>>> "unlimited") Rather than currently failing catastrophically if this >>>> value doesn't exist, there should be a sensible default if it is >>>> undeclared for whatever reason. We will use a sane fallback value >>>> of "limited". >>>> >>>> If the distribution has also removed the "limited" policy directory >>>> then the VM will still fail to initialize, but we have at least made >>>> an effort to recover. >>>> >>>> Thanks, >>>> >>>> Brad >>>> >>> > From weijun.wang at oracle.com Thu Nov 17 00:14:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Nov 2016 08:14:08 +0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> Message-ID: <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> > On Nov 17, 2016, at 6:10 AM, Bradford Wetmore wrote: > > > Current iteration: > > http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 > > Changes: > > 1. Using Debug "jca" instead of "policy" > > 2. Using debug.println (System.err), as the other jca calls are also using it. Still have a question: Why must both (debug != null) and Debug.isOn("jca") be checked? If Debug.getInstance("jca") is not null, shouldn't Debug.isOn("jca") always be true? > > 3. Added regression test. Strips out any crypto.policy entry to create a new file, then uses it. Looks fine, but I heard you can use some cool jdk8 classes like for (in = Files.lines(input); out = new PrintWriter(output)) { in.filter(x -> !x.contains("crypto.policy")).forEach(out::println); } --Max > > 4. Updated webrev with bugid/reviewers. > > Brad > > > > > On 11/16/2016 6:21 AM, Se?n Coffey wrote: >> In the recent jdk8u-dev edits of this file for 8157561, we introduced a >> debug field based on this key : >> >> Debug.getInstance("jca", "Cipher"); >> >> Can we continue to use 'jca' to be consistent for people upgrading ? >> >> for the testcase, I guess you can edit >> test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll have to >> launch with a customized java.security file which doesn't have >> crypto.policy set. (Security.setProperty doesn't allow null values) >> >> Regards, >> Sean. >> >> On 16/11/16 00:40, Bradford Wetmore wrote: >>> Never noticed that before! We have NOT been consistent in whether we >>> use: >>> >>> System.out.println() >>> or >>> debug.println() >>> >>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >>> another project, so I will remove the prefix for now. Thanks for >>> catching it. >>> >>> I will also add a simple regression Test before I push. In hindsight, >>> it's not as trivial a change as I initially thought. If you want to >>> review it, I can wait until you are back tomorrow. >>> >>> Brad >>> >>> >>> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>>> You create a debug field with a prefix string and then check both >>>> debug != null and Debug.isOn("policy") and then use >>>> System.out.println to print the message. Something must be useless. >>>> >>>> --Max >>>> >>>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>>> wrote: >>>>> >>>>> Simple codereview: >>>>> >>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>>> >>>>> The "crypto.policy" Security property is normally defined/configured >>>>> in the java.security file at build time. (e.g. "limited" or >>>>> "unlimited") Rather than currently failing catastrophically if this >>>>> value doesn't exist, there should be a sensible default if it is >>>>> undeclared for whatever reason. We will use a sane fallback value >>>>> of "limited". >>>>> >>>>> If the distribution has also removed the "limited" policy directory >>>>> then the VM will still fail to initialize, but we have at least made >>>>> an effort to recover. >>>>> >>>>> Thanks, >>>>> >>>>> Brad >>>>> >>>> >> From bradford.wetmore at oracle.com Thu Nov 17 01:33:26 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Nov 2016 17:33:26 -0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> Message-ID: On 11/16/2016 4:14 PM, Wang Weijun wrote: > >> On Nov 17, 2016, at 6:10 AM, Bradford Wetmore wrote: >> >> >> Current iteration: >> >> http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 >> >> Changes: >> >> 1. Using Debug "jca" instead of "policy" >> >> 2. Using debug.println (System.err), as the other jca calls are also using it. > > Still have a question: > > Why must both (debug != null) and Debug.isOn("jca") be checked? If Debug.getInstance("jca") is not null, shouldn't Debug.isOn("jca") always be true? Ok, I think I've finally figured it out. For namespaces like JSSE and x509, there is a "main" namespace like "ssl" or "x509", and then subnames such as "plaintext" and "ava" which allow for more specific output selection criteria (e.g. ssl/trustmanager). For this case, I don't need to get more specific, so I can skip the isOn. (My first thought was that maybe older versions of the JDK would allow for dynamic changes of the variable, but never saw that kind of code anywhere.) >> >> 3. Added regression test. Strips out any crypto.policy entry to create a new file, then uses it. > > Looks fine, but I heard you can use some cool jdk8 classes like > > for (in = Files.lines(input); out = new PrintWriter(output)) { > in.filter(x -> !x.contains("crypto.policy")).forEach(out::println); > } Or: try (PrintWriter out = new PrintWriter(FILENAME)) { Files.lines(path) .filter(x -> !x.trim().startsWith("crypto.policy")) .forEach(out::println); } Latest at: http://cr.openjdk.java.net/~wetmore/8169335/webrev.02 Brad > --Max > > >> >> 4. Updated webrev with bugid/reviewers. >> >> Brad >> >> >> >> >> On 11/16/2016 6:21 AM, Se?n Coffey wrote: >>> In the recent jdk8u-dev edits of this file for 8157561, we introduced a >>> debug field based on this key : >>> >>> Debug.getInstance("jca", "Cipher"); >>> >>> Can we continue to use 'jca' to be consistent for people upgrading ? >>> >>> for the testcase, I guess you can edit >>> test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll have to >>> launch with a customized java.security file which doesn't have >>> crypto.policy set. (Security.setProperty doesn't allow null values) >>> >>> Regards, >>> Sean. >>> >>> On 16/11/16 00:40, Bradford Wetmore wrote: >>>> Never noticed that before! We have NOT been consistent in whether we >>>> use: >>>> >>>> System.out.println() >>>> or >>>> debug.println() >>>> >>>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >>>> another project, so I will remove the prefix for now. Thanks for >>>> catching it. >>>> >>>> I will also add a simple regression Test before I push. In hindsight, >>>> it's not as trivial a change as I initially thought. If you want to >>>> review it, I can wait until you are back tomorrow. >>>> >>>> Brad >>>> >>>> >>>> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>>>> You create a debug field with a prefix string and then check both >>>>> debug != null and Debug.isOn("policy") and then use >>>>> System.out.println to print the message. Something must be useless. >>>>> >>>>> --Max >>>>> >>>>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>>>> wrote: >>>>>> >>>>>> Simple codereview: >>>>>> >>>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>>>> >>>>>> The "crypto.policy" Security property is normally defined/configured >>>>>> in the java.security file at build time. (e.g. "limited" or >>>>>> "unlimited") Rather than currently failing catastrophically if this >>>>>> value doesn't exist, there should be a sensible default if it is >>>>>> undeclared for whatever reason. We will use a sane fallback value >>>>>> of "limited". >>>>>> >>>>>> If the distribution has also removed the "limited" policy directory >>>>>> then the VM will still fail to initialize, but we have at least made >>>>>> an effort to recover. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Brad >>>>>> >>>>> >>> > From xuelei.fan at oracle.com Thu Nov 17 01:42:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Nov 2016 09:42:23 +0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> Message-ID: > http://cr.openjdk.java.net/~wetmore/8169335/webrev.02 Looks fine to me. BTW, I was just wondering, do you want to allow empty security property (cryptoPolicyProperty.length() is 0) as well? Xuelei On 11/17/2016 9:33 AM, Bradford Wetmore wrote: > > > On 11/16/2016 4:14 PM, Wang Weijun wrote: >> >>> On Nov 17, 2016, at 6:10 AM, Bradford Wetmore >>> wrote: >>> >>> >>> Current iteration: >>> >>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 >>> >>> Changes: >>> >>> 1. Using Debug "jca" instead of "policy" >>> >>> 2. Using debug.println (System.err), as the other jca calls are also >>> using it. >> >> Still have a question: >> >> Why must both (debug != null) and Debug.isOn("jca") be checked? If >> Debug.getInstance("jca") is not null, shouldn't Debug.isOn("jca") >> always be true? > > Ok, I think I've finally figured it out. For namespaces like JSSE and > x509, there is a "main" namespace like "ssl" or "x509", and then > subnames such as "plaintext" and "ava" which allow for more specific > output selection criteria (e.g. ssl/trustmanager). For this case, I > don't need to get more specific, so I can skip the isOn. > > (My first thought was that maybe older versions of the JDK would allow > for dynamic changes of the variable, but never saw that kind of code > anywhere.) > >>> >>> 3. Added regression test. Strips out any crypto.policy entry to >>> create a new file, then uses it. >> >> Looks fine, but I heard you can use some cool jdk8 classes like >> >> for (in = Files.lines(input); out = new PrintWriter(output)) { >> in.filter(x -> !x.contains("crypto.policy")).forEach(out::println); >> } > > Or: > > try (PrintWriter out = new PrintWriter(FILENAME)) { > Files.lines(path) > .filter(x -> !x.trim().startsWith("crypto.policy")) > .forEach(out::println); > } > > > Latest at: > > http://cr.openjdk.java.net/~wetmore/8169335/webrev.02 > > Brad > > > >> --Max >> >> >>> >>> 4. Updated webrev with bugid/reviewers. >>> >>> Brad >>> >>> >>> >>> >>> On 11/16/2016 6:21 AM, Se?n Coffey wrote: >>>> In the recent jdk8u-dev edits of this file for 8157561, we introduced a >>>> debug field based on this key : >>>> >>>> Debug.getInstance("jca", "Cipher"); >>>> >>>> Can we continue to use 'jca' to be consistent for people upgrading ? >>>> >>>> for the testcase, I guess you can edit >>>> test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll >>>> have to >>>> launch with a customized java.security file which doesn't have >>>> crypto.policy set. (Security.setProperty doesn't allow null values) >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 16/11/16 00:40, Bradford Wetmore wrote: >>>>> Never noticed that before! We have NOT been consistent in whether we >>>>> use: >>>>> >>>>> System.out.println() >>>>> or >>>>> debug.println() >>>>> >>>>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >>>>> another project, so I will remove the prefix for now. Thanks for >>>>> catching it. >>>>> >>>>> I will also add a simple regression Test before I push. In hindsight, >>>>> it's not as trivial a change as I initially thought. If you want to >>>>> review it, I can wait until you are back tomorrow. >>>>> >>>>> Brad >>>>> >>>>> >>>>> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>>>>> You create a debug field with a prefix string and then check both >>>>>> debug != null and Debug.isOn("policy") and then use >>>>>> System.out.println to print the message. Something must be useless. >>>>>> >>>>>> --Max >>>>>> >>>>>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>>>>> wrote: >>>>>>> >>>>>>> Simple codereview: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>>>>> >>>>>>> The "crypto.policy" Security property is normally defined/configured >>>>>>> in the java.security file at build time. (e.g. "limited" or >>>>>>> "unlimited") Rather than currently failing catastrophically if this >>>>>>> value doesn't exist, there should be a sensible default if it is >>>>>>> undeclared for whatever reason. We will use a sane fallback value >>>>>>> of "limited". >>>>>>> >>>>>>> If the distribution has also removed the "limited" policy directory >>>>>>> then the VM will still fail to initialize, but we have at least made >>>>>>> an effort to recover. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Brad >>>>>>> >>>>>> >>>> >> From weijun.wang at oracle.com Thu Nov 17 02:49:47 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Nov 2016 10:49:47 +0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> Message-ID: <4B0C41A4-3B9E-4CA2-9ECF-FF25D8381237@oracle.com> > On Nov 17, 2016, at 9:33 AM, Bradford Wetmore wrote: > > try (PrintWriter out = new PrintWriter(FILENAME)) { > Files.lines(path) > .filter(x -> !x.trim().startsWith("crypto.policy")) > .forEach(out::println); > } Not very sure. Although IMHO a terminate method like forEach *should* close the stream, the spec has not said so: *

Streams have a {@link #close()} method and implement {@link AutoCloseable}. * Operating on a stream after it has been closed will throw {@link IllegalStateException}. * Most stream instances do not actually need to be closed after use, as they * are backed by collections, arrays, or generating functions, which require no * special resource management. Generally, only streams whose source is an IO channel, * such as those returned by {@link Files#lines(Path)}, will require closing. If a * stream does require closing, it must be opened as a resource within a try-with-resources * statement or similar control structure to ensure that it is closed promptly after its * operations have completed. I know you use Windows, so if you haven't seen any test failure, maybe it's safe. Thanks Max From sean.mullan at oracle.com Thu Nov 17 12:34:10 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Nov 2016 07:34:10 -0500 Subject: RFR 7004967: SecureRandom should be more explicit about threading In-Reply-To: <9a14d653-358c-3d22-065f-079fd0cf2d4e@oracle.com> References: <9a14d653-358c-3d22-065f-079fd0cf2d4e@oracle.com> Message-ID: Looks good. --Sean On 11/15/16 9:55 PM, Wang Weijun wrote: > Please review the updated webrev at > > http://cr.openjdk.java.net/~weijun/7004967/webrev.02/ > > Only spec change [1]. > > This change also covers 8169312. > > Thanks > Max > > [1] > http://cr.openjdk.java.net/~weijun/7004967/webrev.02/interdiff.patch.html > > On 11/4/2016 10:54 PM, Sean Mullan wrote: >> * SecureRandom >> >> 131 * If this attribute is not set or is "false", this class will >> instead >> 132 * synchronize access to each of the methods of the {@code >> SecureRandomSpi} >> 133 * implementation. >> >> Not all of the methods are synchronized - engineGetParameters is not, >> for example. I think to avoid ambiguity, you should list the names of >> the methods that are synchronized. >> >> 810 * @throws IllegalArgumentException if {@code numBytes} is >> negative >> >> Since this is a new @throws, you really need to file a new bug. >> >> Please also file a docs bug with a description of the new attribute. >> >> * SecureRandomSpi >> >> lines 63-83, I think the wording could be improved/simplified, how about: >> >> See {@link SecureRandom} for additional details on thread safety. By >> default, a SecureRandomSpi implementation is considered to be not safe >> for use by multiple concurrent threads and SecureRandom will synchronize >> access to each of the applicable engine methods (see SecureRandom for >> the list of methods). However, if a SecureRandomSpi implementation is >> thread-safe, the > href="{@docRoot}/../technotes/guides/security/StandardNames.html#Service">service >> >> provider attribute "ThreadSafe" should be set to "true" during its >> registration, as follows: >> >> put("SecureRandom.AlgName ThreadSafe", "true"); >> >> or >> >> putService(new Service(this, "SecureRandom", "AlgName", className, >> null, Map.of("ThreadSafe", "true"))); >> >> {@code SecureRandom} will then call the applicable engine methods >> without any synchronization. >> >> --Sean >> >> On 11/2/16 3:27 AM, Wang Weijun wrote: >>> Ping again. >>> >>> There is an updated version at >>> http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only >>> changes. >>> >>> Thanks >>> Max >>> >>>> On Aug 25, 2016, at 10:00 AM, Weijun Wang >>>> wrote: >>>> >>>> Please review the enhancement at >>>> >>>> http://cr.openjdk.java.net/~weijun/7004967/webrev.00/ >>>> >>>> Basically, we want SecureRandom to be more efficient by removing all >>>> synchronized keywords from its public methods and let an >>>> implementation to take care of thread-safety (We already did some in >>>> JDK-8098581). On the other hand, we need to make sure that existing >>>> implementations that have not synchronized correctly to behave just >>>> as good as before. >>>> >>>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you >>>> think your implementation is already thread-safe, set it to "true" >>>> and SecureRandom will be happy. Otherwise, don't set it and >>>> SecureRandom will continuously call your SecureRandomSpi engine >>>> methods in synchronized blocks. >>>> >>>> Thanks >>>> Max >>> From sergei.kovalev at oracle.com Thu Nov 17 12:43:56 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 17 Nov 2016 15:43:56 +0300 Subject: RFR(s): JDK-8169866: [TESTBUG] com/sun/security/ tests have undeclared modules dependencies Message-ID: <900e3a01-72ae-415b-e768-675ff228e4cc@oracle.com> Hello team, Please review a small fix for security tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8169866 Web review: http://cr.openjdk.java.net/~skovalev/8169866/webrev.00/ Issue: Tests from package com/sun/security failing in case of usage "--limit-modules java.base" command line options due to undeclared dependencies. Solution: add declaration of required modules. -- With best regards, Sergei From sean.coffey at oracle.com Thu Nov 17 15:19:02 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 17 Nov 2016 15:19:02 +0000 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> Message-ID: Looks good to me. I didn't know you could pass a plain file 'name' to java.security.properties. The docs indicate that a URL is required but the jdk code suggests your approach will work. The /policy= jtreg tag was also another possible solution. regards, Sean. On 17/11/2016 01:33, Bradford Wetmore wrote: > > > On 11/16/2016 4:14 PM, Wang Weijun wrote: >> >>> On Nov 17, 2016, at 6:10 AM, Bradford Wetmore >>> wrote: >>> >>> >>> Current iteration: >>> >>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 >>> >>> Changes: >>> >>> 1. Using Debug "jca" instead of "policy" >>> >>> 2. Using debug.println (System.err), as the other jca calls are >>> also using it. >> >> Still have a question: >> >> Why must both (debug != null) and Debug.isOn("jca") be checked? If >> Debug.getInstance("jca") is not null, shouldn't Debug.isOn("jca") >> always be true? > > Ok, I think I've finally figured it out. For namespaces like JSSE and > x509, there is a "main" namespace like "ssl" or "x509", and then > subnames such as "plaintext" and "ava" which allow for more specific > output selection criteria (e.g. ssl/trustmanager). For this case, I > don't need to get more specific, so I can skip the isOn. > > (My first thought was that maybe older versions of the JDK would allow > for dynamic changes of the variable, but never saw that kind of code > anywhere.) > >>> >>> 3. Added regression test. Strips out any crypto.policy entry to >>> create a new file, then uses it. >> >> Looks fine, but I heard you can use some cool jdk8 classes like >> >> for (in = Files.lines(input); out = new PrintWriter(output)) { >> in.filter(x -> >> !x.contains("crypto.policy")).forEach(out::println); >> } > > Or: > > try (PrintWriter out = new PrintWriter(FILENAME)) { > Files.lines(path) > .filter(x -> !x.trim().startsWith("crypto.policy")) > .forEach(out::println); > } > > > Latest at: > > http://cr.openjdk.java.net/~wetmore/8169335/webrev.02 > > Brad > > > >> --Max >> >> >>> >>> 4. Updated webrev with bugid/reviewers. >>> >>> Brad >>> >>> >>> >>> >>> On 11/16/2016 6:21 AM, Se?n Coffey wrote: >>>> In the recent jdk8u-dev edits of this file for 8157561, we >>>> introduced a >>>> debug field based on this key : >>>> >>>> Debug.getInstance("jca", "Cipher"); >>>> >>>> Can we continue to use 'jca' to be consistent for people upgrading ? >>>> >>>> for the testcase, I guess you can edit >>>> test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll >>>> have to >>>> launch with a customized java.security file which doesn't have >>>> crypto.policy set. (Security.setProperty doesn't allow null values) >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 16/11/16 00:40, Bradford Wetmore wrote: >>>>> Never noticed that before! We have NOT been consistent in whether we >>>>> use: >>>>> >>>>> System.out.println() >>>>> or >>>>> debug.println() >>>>> >>>>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >>>>> another project, so I will remove the prefix for now. Thanks for >>>>> catching it. >>>>> >>>>> I will also add a simple regression Test before I push. In hindsight, >>>>> it's not as trivial a change as I initially thought. If you want to >>>>> review it, I can wait until you are back tomorrow. >>>>> >>>>> Brad >>>>> >>>>> >>>>> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>>>>> You create a debug field with a prefix string and then check both >>>>>> debug != null and Debug.isOn("policy") and then use >>>>>> System.out.println to print the message. Something must be useless. >>>>>> >>>>>> --Max >>>>>> >>>>>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>>>>> wrote: >>>>>>> >>>>>>> Simple codereview: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>>>>> >>>>>>> The "crypto.policy" Security property is normally >>>>>>> defined/configured >>>>>>> in the java.security file at build time. (e.g. "limited" or >>>>>>> "unlimited") Rather than currently failing catastrophically if this >>>>>>> value doesn't exist, there should be a sensible default if it is >>>>>>> undeclared for whatever reason. We will use a sane fallback value >>>>>>> of "limited". >>>>>>> >>>>>>> If the distribution has also removed the "limited" policy directory >>>>>>> then the VM will still fail to initialize, but we have at least >>>>>>> made >>>>>>> an effort to recover. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Brad >>>>>>> >>>>>> >>>> >> From bradford.wetmore at oracle.com Thu Nov 17 17:46:45 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 17 Nov 2016 09:46:45 -0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> Message-ID: <71690c51-a5e1-26b5-7474-f1e576c170f2@oracle.com> On 11/17/2016 7:19 AM, Se?n Coffey wrote: > The /policy= jtreg tag was also another possible solution. That's a policy file, not a java.security file. SeanM pointed out that we could do a: @main -Djava.security.properties=xxx but that would require storing a snapshot of java.security. I think I prefer it being dynamically generated. Brad > regards, > Sean. > > > On 17/11/2016 01:33, Bradford Wetmore wrote: >> >> >> On 11/16/2016 4:14 PM, Wang Weijun wrote: >>> >>>> On Nov 17, 2016, at 6:10 AM, Bradford Wetmore >>>> wrote: >>>> >>>> >>>> Current iteration: >>>> >>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 >>>> >>>> Changes: >>>> >>>> 1. Using Debug "jca" instead of "policy" >>>> >>>> 2. Using debug.println (System.err), as the other jca calls are >>>> also using it. >>> >>> Still have a question: >>> >>> Why must both (debug != null) and Debug.isOn("jca") be checked? If >>> Debug.getInstance("jca") is not null, shouldn't Debug.isOn("jca") >>> always be true? >> >> Ok, I think I've finally figured it out. For namespaces like JSSE and >> x509, there is a "main" namespace like "ssl" or "x509", and then >> subnames such as "plaintext" and "ava" which allow for more specific >> output selection criteria (e.g. ssl/trustmanager). For this case, I >> don't need to get more specific, so I can skip the isOn. >> >> (My first thought was that maybe older versions of the JDK would allow >> for dynamic changes of the variable, but never saw that kind of code >> anywhere.) >> >>>> >>>> 3. Added regression test. Strips out any crypto.policy entry to >>>> create a new file, then uses it. >>> >>> Looks fine, but I heard you can use some cool jdk8 classes like >>> >>> for (in = Files.lines(input); out = new PrintWriter(output)) { >>> in.filter(x -> >>> !x.contains("crypto.policy")).forEach(out::println); >>> } >> >> Or: >> >> try (PrintWriter out = new PrintWriter(FILENAME)) { >> Files.lines(path) >> .filter(x -> !x.trim().startsWith("crypto.policy")) >> .forEach(out::println); >> } >> >> >> Latest at: >> >> http://cr.openjdk.java.net/~wetmore/8169335/webrev.02 >> >> Brad >> >> >> >>> --Max >>> >>> >>>> >>>> 4. Updated webrev with bugid/reviewers. >>>> >>>> Brad >>>> >>>> >>>> >>>> >>>> On 11/16/2016 6:21 AM, Se?n Coffey wrote: >>>>> In the recent jdk8u-dev edits of this file for 8157561, we >>>>> introduced a >>>>> debug field based on this key : >>>>> >>>>> Debug.getInstance("jca", "Cipher"); >>>>> >>>>> Can we continue to use 'jca' to be consistent for people upgrading ? >>>>> >>>>> for the testcase, I guess you can edit >>>>> test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll >>>>> have to >>>>> launch with a customized java.security file which doesn't have >>>>> crypto.policy set. (Security.setProperty doesn't allow null values) >>>>> >>>>> Regards, >>>>> Sean. >>>>> >>>>> On 16/11/16 00:40, Bradford Wetmore wrote: >>>>>> Never noticed that before! We have NOT been consistent in whether we >>>>>> use: >>>>>> >>>>>> System.out.println() >>>>>> or >>>>>> debug.println() >>>>>> >>>>>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >>>>>> another project, so I will remove the prefix for now. Thanks for >>>>>> catching it. >>>>>> >>>>>> I will also add a simple regression Test before I push. In hindsight, >>>>>> it's not as trivial a change as I initially thought. If you want to >>>>>> review it, I can wait until you are back tomorrow. >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>>>>>> You create a debug field with a prefix string and then check both >>>>>>> debug != null and Debug.isOn("policy") and then use >>>>>>> System.out.println to print the message. Something must be useless. >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>>>>>> wrote: >>>>>>>> >>>>>>>> Simple codereview: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>>>>>> >>>>>>>> The "crypto.policy" Security property is normally >>>>>>>> defined/configured >>>>>>>> in the java.security file at build time. (e.g. "limited" or >>>>>>>> "unlimited") Rather than currently failing catastrophically if this >>>>>>>> value doesn't exist, there should be a sensible default if it is >>>>>>>> undeclared for whatever reason. We will use a sane fallback value >>>>>>>> of "limited". >>>>>>>> >>>>>>>> If the distribution has also removed the "limited" policy directory >>>>>>>> then the VM will still fail to initialize, but we have at least >>>>>>>> made >>>>>>>> an effort to recover. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Brad >>>>>>>> >>>>>>> >>>>> >>> > From sean.coffey at oracle.com Thu Nov 17 17:51:37 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 17 Nov 2016 17:51:37 +0000 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <71690c51-a5e1-26b5-7474-f1e576c170f2@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> <71690c51-a5e1-26b5-7474-f1e576c170f2@oracle.com> Message-ID: On 17/11/2016 17:46, Bradford Wetmore wrote: > > > On 11/17/2016 7:19 AM, Se?n Coffey wrote: >> The /policy= jtreg tag was also another possible solution. > > That's a policy file, not a java.security file. Ah, of course. Wasn't thinking right. regards, Sean. > > SeanM pointed out that we could do a: > > @main -Djava.security.properties=xxx > > but that would require storing a snapshot of java.security. I think I > prefer it being dynamically generated. > > Brad > > >> regards, >> Sean. >> >> >> On 17/11/2016 01:33, Bradford Wetmore wrote: >>> >>> >>> On 11/16/2016 4:14 PM, Wang Weijun wrote: >>>> >>>>> On Nov 17, 2016, at 6:10 AM, Bradford Wetmore >>>>> wrote: >>>>> >>>>> >>>>> Current iteration: >>>>> >>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.01 >>>>> >>>>> Changes: >>>>> >>>>> 1. Using Debug "jca" instead of "policy" >>>>> >>>>> 2. Using debug.println (System.err), as the other jca calls are >>>>> also using it. >>>> >>>> Still have a question: >>>> >>>> Why must both (debug != null) and Debug.isOn("jca") be checked? If >>>> Debug.getInstance("jca") is not null, shouldn't Debug.isOn("jca") >>>> always be true? >>> >>> Ok, I think I've finally figured it out. For namespaces like JSSE and >>> x509, there is a "main" namespace like "ssl" or "x509", and then >>> subnames such as "plaintext" and "ava" which allow for more specific >>> output selection criteria (e.g. ssl/trustmanager). For this case, I >>> don't need to get more specific, so I can skip the isOn. >>> >>> (My first thought was that maybe older versions of the JDK would allow >>> for dynamic changes of the variable, but never saw that kind of code >>> anywhere.) >>> >>>>> >>>>> 3. Added regression test. Strips out any crypto.policy entry to >>>>> create a new file, then uses it. >>>> >>>> Looks fine, but I heard you can use some cool jdk8 classes like >>>> >>>> for (in = Files.lines(input); out = new PrintWriter(output)) { >>>> in.filter(x -> >>>> !x.contains("crypto.policy")).forEach(out::println); >>>> } >>> >>> Or: >>> >>> try (PrintWriter out = new PrintWriter(FILENAME)) { >>> Files.lines(path) >>> .filter(x -> !x.trim().startsWith("crypto.policy")) >>> .forEach(out::println); >>> } >>> >>> >>> Latest at: >>> >>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.02 >>> >>> Brad >>> >>> >>> >>>> --Max >>>> >>>> >>>>> >>>>> 4. Updated webrev with bugid/reviewers. >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> >>>>> On 11/16/2016 6:21 AM, Se?n Coffey wrote: >>>>>> In the recent jdk8u-dev edits of this file for 8157561, we >>>>>> introduced a >>>>>> debug field based on this key : >>>>>> >>>>>> Debug.getInstance("jca", "Cipher"); >>>>>> >>>>>> Can we continue to use 'jca' to be consistent for people upgrading ? >>>>>> >>>>>> for the testcase, I guess you can edit >>>>>> test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll >>>>>> have to >>>>>> launch with a customized java.security file which doesn't have >>>>>> crypto.policy set. (Security.setProperty doesn't allow null values) >>>>>> >>>>>> Regards, >>>>>> Sean. >>>>>> >>>>>> On 16/11/16 00:40, Bradford Wetmore wrote: >>>>>>> Never noticed that before! We have NOT been consistent in >>>>>>> whether we >>>>>>> use: >>>>>>> >>>>>>> System.out.println() >>>>>>> or >>>>>>> debug.println() >>>>>>> >>>>>>> I knew SeanC wants to rework the JCA/JCE/Security debugging >>>>>>> output in >>>>>>> another project, so I will remove the prefix for now. Thanks for >>>>>>> catching it. >>>>>>> >>>>>>> I will also add a simple regression Test before I push. In >>>>>>> hindsight, >>>>>>> it's not as trivial a change as I initially thought. If you want to >>>>>>> review it, I can wait until you are back tomorrow. >>>>>>> >>>>>>> Brad >>>>>>> >>>>>>> >>>>>>> On 11/15/2016 4:12 PM, Wang Weijun wrote: >>>>>>>> You create a debug field with a prefix string and then check both >>>>>>>> debug != null and Debug.isOn("policy") and then use >>>>>>>> System.out.println to print the message. Something must be >>>>>>>> useless. >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>>> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Simple codereview: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~wetmore/8169335/webrev.00 >>>>>>>>> >>>>>>>>> The "crypto.policy" Security property is normally >>>>>>>>> defined/configured >>>>>>>>> in the java.security file at build time. (e.g. "limited" or >>>>>>>>> "unlimited") Rather than currently failing catastrophically if >>>>>>>>> this >>>>>>>>> value doesn't exist, there should be a sensible default if it is >>>>>>>>> undeclared for whatever reason. We will use a sane fallback >>>>>>>>> value >>>>>>>>> of "limited". >>>>>>>>> >>>>>>>>> If the distribution has also removed the "limited" policy >>>>>>>>> directory >>>>>>>>> then the VM will still fail to initialize, but we have at least >>>>>>>>> made >>>>>>>>> an effort to recover. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Brad >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From amanda.jiang at oracle.com Sat Nov 19 00:38:17 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 18 Nov 2016 16:38:17 -0800 Subject: RFR 8169911: Enhanced tests for jarsigner -verbose -verify after JDK-8163304 Message-ID: HI All, Please help to review following code change: webrev: http://cr.openjdk.java.net/~amjiang/8169911/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8169911 This change enhances test case for JDK-8163304 by covering following cases: - Multiple signers (signed by jarsigner twice using different aliases) - Combinations of weak/strong -digestalg, -tsadigestalg and -sigalg - Signing with DSA keys Thanks, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Nov 19 07:37:26 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 19 Nov 2016 15:37:26 +0800 Subject: RFR 8169911: Enhanced tests for jarsigner -verbose -verify after JDK-8163304 In-Reply-To: References: Message-ID: Hi Amanda - There are many duplicates in signWithAlias() and sign(). I think it's better to make one based on the other. Maybe signWithAliasAndTsa() and sign(). - checkWeak2() is about combinations of weak/strong algs in a single signer. I'd rather it be an individual test case, and not as a step in multiple signers. The name is not meaningful enough. Maybe checkHalfWeak()? - About multiple signers: On lines 356 and 364, I suggest using different names for signed jar and original jar. This makes debugging easier when there is a failure. IMO it's not worth writing different checkComb() and checkComb2(). As long as the output contains "weak" we know the weak algorithm is also printed out. What we need to cover are: 1) it's treated as verified if at least one is strong (you already covered it) 2) it has only 1 verified signer, this should be shown with both -verbose and -certs. You can see there is only one certificate shown. Or you can use JarFile API to open the jar file and check the length of JarEntry::getCodeSigner(). 3) the history shows 2 signers, this can be provide by 2 "Signed by" lines. I'd suggest checkComb() be renamed to checkMultiple(). Thanks Max > On Nov 19, 2016, at 8:38 AM, Amanda Jiang wrote: > > HI All, > Please help to review following code change: > webrev: http://cr.openjdk.java.net/~amjiang/8169911/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8169911 > > This change enhances test case for JDK-8163304 by covering following cases: > - Multiple signers (signed by jarsigner twice using different aliases) > - Combinations of weak/strong -digestalg, -tsadigestalg and -sigalg > - Signing with DSA keys > > Thanks, > Amanda From sha.jiang at oracle.com Sat Nov 19 11:38:47 2016 From: sha.jiang at oracle.com (John Jiang) Date: Sat, 19 Nov 2016 19:38:47 +0800 Subject: RFR[9] JDK-8164595: javax/net/ssl/FixingJavadocs/SSLSessionNulls.java fails intermittently with javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake In-Reply-To: <9514b33b-e256-d17a-8ed7-e31dbffe8166@oracle.com> References: <9514b33b-e256-d17a-8ed7-e31dbffe8166@oracle.com> Message-ID: After push for JDK-8168969, this fix has to use updated SSLSocketTemplate.java. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8164595/webrev.01 Best regards, John Jiang On 2016/10/27 12:36, John Jiang wrote: > Hi, > Please review this patch for test > javax/net/ssl/FixingJavadocs/SSLSessionNulls.java. > It takes advantage of javax/net/ssl/templates/SSLTest.java to fix the > intermittent SSLHandshakeException issue. > > Webrev: http://cr.openjdk.java.net/~jjiang/8164595/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8164595 > > Best regards, > John Jiang From ecki at zusammenkunft.net Sun Nov 20 19:57:39 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 20 Nov 2016 20:57:39 +0100 Subject: JDK 9 and JCE code signing (where and sha1WithDSA 1024?) Message-ID: <20161120205739.00002b09.ecki@zusammenkunft.net> Hello, how will the JCE Provider signing in Java 9 work? Are the jmod files signed (I dont see a signature in them in the Windows EA builds)? On the BouncyCastle Crypto mailing list there has been a discussion that currently JCE code signing (of Jars) is done with a SHA1 chained 1024 bit DSA signature. https://www.bouncycastle.org/devmailarchive/msg14905.html Will that change to actually allow SHA-1 to be turned off? Does the JAR-path checking security attribute also apply to any (possible) JMOD signatures? Oracle's planned changes do not include as far as I can see any changes here. I dont mind much that JCE policy is enforced by an older algorithm, but it makes it impossible to globally turn off SHA1 and DSA (1024). Gruss Bernd From sean.mullan at oracle.com Mon Nov 21 12:48:10 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Nov 2016 07:48:10 -0500 Subject: JDK 9 and JCE code signing (where and sha1WithDSA 1024?) In-Reply-To: <20161120205739.00002b09.ecki@zusammenkunft.net> References: <20161120205739.00002b09.ecki@zusammenkunft.net> Message-ID: <9f9907f7-9877-b5c9-70dd-bb25556d7df8@oracle.com> On 11/20/16 2:57 PM, Bernd Eckenfels wrote: > Hello, > > how will the JCE Provider signing in Java 9 work? Are the jmod files > signed (I dont see a signature in them in the Windows EA builds)? Third party JCE providers still need to be signed as a JAR file. > On the BouncyCastle Crypto mailing list there has been a discussion > that currently JCE code signing (of Jars) is done with a SHA1 chained > 1024 bit DSA signature. > > https://www.bouncycastle.org/devmailarchive/msg14905.html > > Will that change to actually allow SHA-1 to be > turned off? Does the JAR-path checking security attribute also apply to > any (possible) JMOD signatures? > > Oracle's planned changes do not include as far as I can see any changes > here. I dont mind much that JCE policy is enforced by an older > algorithm, but it makes it impossible to globally turn off SHA1 and DSA > (1024). This information below is specific to Oracle's JDK, so it is best discussed in a different forum. In short though, here is some information you may find useful: We have recently upgraded Oracle's JCE CA to use stronger algorithms (SHA-256 and 2048-bit keys). It was released in JDK 8u111, 7u121, 6u131. More information is here (see "New JCE Code Signing Root CA": http://www.oracle.com/technetwork/java/javase/8u111-relnotes-3124969.html You can now request a new JCE code signing certificate that uses stronger algorithms. However, this certificate will only work on releases on or after the above releases. Thus, we recommend that if you do need to support older releases, you keep the signature on the existing JAR and re-sign it with the new certificate/key -- which means the resulting signed JAR will have 2 signatures. --Sean From sean.mullan at oracle.com Mon Nov 21 21:09:19 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 21 Nov 2016 16:09:19 -0500 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property Message-ID: Please review this fix for a bug where certificates were not being blocked if the algorithm is only listed in the jdk.tls.disabledAlgorithms property and not the jdk.certpath.disabledAlgorithms property. I have modified an existing regression test to test this functionality as there was no previous test for this feature. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8170131 --Sean From anthony.scarpino at oracle.com Mon Nov 21 22:43:32 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 21 Nov 2016 14:43:32 -0800 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property In-Reply-To: References: Message-ID: <58337894.4020600@oracle.com> On 11/21/2016 01:09 PM, Sean Mullan wrote: > Please review this fix for a bug where certificates were not being > blocked if the algorithm is only listed in the > jdk.tls.disabledAlgorithms property and not the > jdk.certpath.disabledAlgorithms property. > > I have modified an existing regression test to test this functionality > as there was no previous test for this feature. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170131 > > --Sean Is the reason the if() is needed is constraints.permit(CerttConstraintParameters) is not in the SSLAlgorithmConstraints class and the method exception is suppressed? Tony From bradford.wetmore at oracle.com Mon Nov 21 23:02:01 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 21 Nov 2016 15:02:01 -0800 Subject: JDK 9 and JCE code signing (where and sha1WithDSA 1024?) In-Reply-To: <9f9907f7-9877-b5c9-70dd-bb25556d7df8@oracle.com> References: <20161120205739.00002b09.ecki@zusammenkunft.net> <9f9907f7-9877-b5c9-70dd-bb25556d7df8@oracle.com> Message-ID: On 11/21/2016 4:48 AM, Sean Mullan wrote: > On 11/20/16 2:57 PM, Bernd Eckenfels wrote: >> Hello, >> >> how will the JCE Provider signing in Java 9 work? Are the jmod files >> signed (I dont see a signature in them in the Windows EA builds)? > > Third party JCE providers still need to be signed as a JAR file. To expand a bit. There are the usual JCE 3rd party signed code checks, so code must be signed by one of the certs mentioned by Sean in his previous post. JCE providers must still be packaged as signed jars. Depending on the jar contents and how they are loaded (via classpath/modulepath), they will be treated as either unnamed modules (classpath) or modular jars (module-info.class: automatic/named modules). The new Module System (JEP 261) rules apply. There is no signed modules (jmod) support in JDK 9. Attempts to use jlink to pull in signed jars will fail by default. If you force jlink to build an image (JDK-8159393: --ignore-signing-information), the code will be treated as unsigned (i.e. no JCE third party code), and provider verification will later fail. Thanks, Brad P.S. Of course, if you simply add module information to an existing signed jar, it will need to be resigned. >> On the BouncyCastle Crypto mailing list there has been a discussion >> that currently JCE code signing (of Jars) is done with a SHA1 chained >> 1024 bit DSA signature. >> >> https://www.bouncycastle.org/devmailarchive/msg14905.html >> >> Will that change to actually allow SHA-1 to be >> turned off? Does the JAR-path checking security attribute also apply to >> any (possible) JMOD signatures? >> >> Oracle's planned changes do not include as far as I can see any changes >> here. I dont mind much that JCE policy is enforced by an older >> algorithm, but it makes it impossible to globally turn off SHA1 and DSA >> (1024). > > This information below is specific to Oracle's JDK, so it is best > discussed in a different forum. In short though, here is some > information you may find useful: > > We have recently upgraded Oracle's JCE CA to use stronger algorithms > (SHA-256 and 2048-bit keys). It was released in JDK 8u111, 7u121, 6u131. > More information is here (see "New JCE Code Signing Root CA": > http://www.oracle.com/technetwork/java/javase/8u111-relnotes-3124969.html > > You can now request a new JCE code signing certificate that uses > stronger algorithms. However, this certificate will only work on > releases on or after the above releases. Thus, we recommend that if you > do need to support older releases, you keep the signature on the > existing JAR and re-sign it with the new certificate/key -- which means > the resulting signed JAR will have 2 signatures. > > --Sean From amanda.jiang at oracle.com Tue Nov 22 05:48:32 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 21 Nov 2016 21:48:32 -0800 Subject: RFR 8169911: Enhanced tests for jarsigner -verbose -verify after JDK-8163304 In-Reply-To: References: Message-ID: Hi Max, Thanks for your comments, the webrev below addressed all the issues you mentioned, please check and let me know if there are any problem. http://cr.openjdk.java.net/~amjiang/8169911/webrev.02/ Thanks, Amanda On 11/18/16 11:37 PM, Wang Weijun wrote: > Hi Amanda > > - There are many duplicates in signWithAlias() and sign(). I think it's better to make one based on the other. Maybe signWithAliasAndTsa() and sign(). > > - checkWeak2() is about combinations of weak/strong algs in a single signer. I'd rather it be an individual test case, and not as a step in multiple signers. The name is not meaningful enough. Maybe checkHalfWeak()? > > - About multiple signers: > > On lines 356 and 364, I suggest using different names for signed jar and original jar. This makes debugging easier when there is a failure. > > IMO it's not worth writing different checkComb() and checkComb2(). As long as the output contains "weak" we know the weak algorithm is also printed out. What we need to cover are: > > 1) it's treated as verified if at least one is strong (you already covered it) > > 2) it has only 1 verified signer, this should be shown with both -verbose and -certs. You can see there is only one certificate shown. Or you can use JarFile API to open the jar file and check the length of JarEntry::getCodeSigner(). > > 3) the history shows 2 signers, this can be provide by 2 "Signed by" lines. > > I'd suggest checkComb() be renamed to checkMultiple(). > > Thanks > Max > >> On Nov 19, 2016, at 8:38 AM, Amanda Jiang wrote: >> >> HI All, >> Please help to review following code change: >> webrev: http://cr.openjdk.java.net/~amjiang/8169911/webrev.01/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8169911 >> >> This change enhances test case for JDK-8163304 by covering following cases: >> - Multiple signers (signed by jarsigner twice using different aliases) >> - Combinations of weak/strong -digestalg, -tsadigestalg and -sigalg >> - Signing with DSA keys >> >> Thanks, >> Amanda From weijun.wang at oracle.com Tue Nov 22 05:50:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 22 Nov 2016 13:50:45 +0800 Subject: RFR 8169911: Enhanced tests for jarsigner -verbose -verify after JDK-8163304 In-Reply-To: References: Message-ID: Hi Amanda Everything looks fine. Thanks Max > On Nov 22, 2016, at 1:48 PM, Amanda Jiang wrote: > > Hi Max, > > Thanks for your comments, the webrev below addressed all the issues you mentioned, please check and let me know if there are any problem. > > http://cr.openjdk.java.net/~amjiang/8169911/webrev.02/ > > Thanks, > Amanda > > > On 11/18/16 11:37 PM, Wang Weijun wrote: > >> Hi Amanda >> >> - There are many duplicates in signWithAlias() and sign(). I think it's better to make one based on the other. Maybe signWithAliasAndTsa() and sign(). >> >> - checkWeak2() is about combinations of weak/strong algs in a single signer. I'd rather it be an individual test case, and not as a step in multiple signers. The name is not meaningful enough. Maybe checkHalfWeak()? >> >> - About multiple signers: >> >> On lines 356 and 364, I suggest using different names for signed jar and original jar. This makes debugging easier when there is a failure. >> >> IMO it's not worth writing different checkComb() and checkComb2(). As long as the output contains "weak" we know the weak algorithm is also printed out. What we need to cover are: >> >> 1) it's treated as verified if at least one is strong (you already covered it) >> >> 2) it has only 1 verified signer, this should be shown with both -verbose and -certs. You can see there is only one certificate shown. Or you can use JarFile API to open the jar file and check the length of JarEntry::getCodeSigner(). >> >> 3) the history shows 2 signers, this can be provide by 2 "Signed by" lines. >> >> I'd suggest checkComb() be renamed to checkMultiple(). >> >> Thanks >> Max >> >>> On Nov 19, 2016, at 8:38 AM, Amanda Jiang wrote: >>> >>> HI All, >>> Please help to review following code change: >>> webrev: http://cr.openjdk.java.net/~amjiang/8169911/webrev.01/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169911 >>> >>> This change enhances test case for JDK-8163304 by covering following cases: >>> - Multiple signers (signed by jarsigner twice using different aliases) >>> - Combinations of weak/strong -digestalg, -tsadigestalg and -sigalg >>> - Signing with DSA keys >>> >>> Thanks, >>> Amanda > From sean.mullan at oracle.com Tue Nov 22 13:19:45 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Nov 2016 08:19:45 -0500 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property In-Reply-To: <58337894.4020600@oracle.com> References: <58337894.4020600@oracle.com> Message-ID: On 11/21/16 5:43 PM, Anthony Scarpino wrote: > On 11/21/2016 01:09 PM, Sean Mullan wrote: >> Please review this fix for a bug where certificates were not being >> blocked if the algorithm is only listed in the >> jdk.tls.disabledAlgorithms property and not the >> jdk.certpath.disabledAlgorithms property. >> >> I have modified an existing regression test to test this functionality >> as there was no previous test for this feature. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8170131 >> >> --Sean > > Is the reason the if() is needed is > constraints.permit(CerttConstraintParameters) is not in the > SSLAlgorithmConstraints class and the method exception is suppressed? SSLAlgorithmConstraints is not an instanceof DisabledAlgorithmConstraints. When AlgorithmChecker.check is called, the previous code (on line 329) would call certPathDefaultConstraints.permits. This would pass, because the test has configured jdk.certpath.disabledAlgorithms property to be empty. The first time through, prevPubKey would also be null, so it would return on line 335. It would never call SSLAlgorithmConstraints.permits. Does that make sense? --Sean From anthony.scarpino at oracle.com Tue Nov 22 16:00:28 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 22 Nov 2016 08:00:28 -0800 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property In-Reply-To: References: <58337894.4020600@oracle.com> Message-ID: <58346B9C.7040102@oracle.com> On 11/22/2016 05:19 AM, Sean Mullan wrote: > On 11/21/16 5:43 PM, Anthony Scarpino wrote: >> On 11/21/2016 01:09 PM, Sean Mullan wrote: >>> Please review this fix for a bug where certificates were not being >>> blocked if the algorithm is only listed in the >>> jdk.tls.disabledAlgorithms property and not the >>> jdk.certpath.disabledAlgorithms property. >>> >>> I have modified an existing regression test to test this functionality >>> as there was no previous test for this feature. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8170131 >>> >>> --Sean >> >> Is the reason the if() is needed is >> constraints.permit(CerttConstraintParameters) is not in the >> SSLAlgorithmConstraints class and the method exception is suppressed? > > SSLAlgorithmConstraints is not an instanceof > DisabledAlgorithmConstraints. When AlgorithmChecker.check is called, the > previous code (on line 329) would call > certPathDefaultConstraints.permits. This would pass, because the test > has configured jdk.certpath.disabledAlgorithms property to be empty. The > first time through, prevPubKey would also be null, so it would return on > line 335. It would never call SSLAlgorithmConstraints.permits. > > Does that make sense? > > --Sean Ok.. I see what's going on more.. I'm ok with this.. Tony From jamil.j.nimeh at oracle.com Tue Nov 22 18:45:27 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 22 Nov 2016 10:45:27 -0800 Subject: RFR 8170035: When determining the ciphersuite lists, there is no debug output for disabled suites Message-ID: Hello all, This is a short webrev that adds extra debug output that will show users which ciphers are not in the enabled list due to being disabled by things like jdk.tls.disabledAlgorithms, etc. Bug: https://bugs.openjdk.java.net/browse/JDK-8170035 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8170035/webrev.01 Thanks, --Jamil From vincent.x.ryan at oracle.com Tue Nov 22 18:50:06 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Nov 2016 18:50:06 +0000 Subject: RFR 8170035: When determining the ciphersuite lists, there is no debug output for disabled suites In-Reply-To: References: Message-ID: <16796E0D-9F12-4273-87EA-5B4FEE597D6E@oracle.com> Looks fine to me. Thanks. > On 22 Nov 2016, at 18:45, Jamil Nimeh wrote: > > Hello all, > > This is a short webrev that adds extra debug output that will show users which ciphers are not in the enabled list due to being disabled by things like jdk.tls.disabledAlgorithms, etc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170035 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8170035/webrev.01 > > Thanks, > --Jamil From bradford.wetmore at oracle.com Tue Nov 22 19:36:13 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 22 Nov 2016 11:36:13 -0800 Subject: RFR 8170035: When determining the ciphersuite lists, there is no debug output for disabled suites In-Reply-To: <16796E0D-9F12-4273-87EA-5B4FEE597D6E@oracle.com> References: <16796E0D-9F12-4273-87EA-5B4FEE597D6E@oracle.com> Message-ID: Ditto. Does this need a regression test? Not really critical, but might be worth thinking up one. Brad On 11/22/2016 10:50 AM, Vincent Ryan wrote: > Looks fine to me. > Thanks. > > >> On 22 Nov 2016, at 18:45, Jamil Nimeh wrote: >> >> Hello all, >> >> This is a short webrev that adds extra debug output that will show users which ciphers are not in the enabled list due to being disabled by things like jdk.tls.disabledAlgorithms, etc. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170035 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8170035/webrev.01 >> >> Thanks, >> --Jamil > From jamil.j.nimeh at oracle.com Tue Nov 22 19:48:27 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 22 Nov 2016 11:48:27 -0800 Subject: RFR 8170035: When determining the ciphersuite lists, there is no debug output for disabled suites In-Reply-To: References: <16796E0D-9F12-4273-87EA-5B4FEE597D6E@oracle.com> Message-ID: <4c9cad5e-f62e-05b2-abdd-3bfbafa23e10@oracle.com> A regression test for debug output? Is that something that we've done in the past with other debug fixes? --Jamil On 11/22/2016 11:36 AM, Bradford Wetmore wrote: > Ditto. > > Does this need a regression test? Not really critical, but might be > worth thinking up one. > > Brad > > > > On 11/22/2016 10:50 AM, Vincent Ryan wrote: >> Looks fine to me. >> Thanks. >> >> >>> On 22 Nov 2016, at 18:45, Jamil Nimeh wrote: >>> >>> Hello all, >>> >>> This is a short webrev that adds extra debug output that will show >>> users which ciphers are not in the enabled list due to being >>> disabled by things like jdk.tls.disabledAlgorithms, etc. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170035 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8170035/webrev.01 >>> >>> Thanks, >>> --Jamil >> From bradford.wetmore at oracle.com Tue Nov 22 20:14:01 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 22 Nov 2016 12:14:01 -0800 Subject: RFR 8170035: When determining the ciphersuite lists, there is no debug output for disabled suites In-Reply-To: <4c9cad5e-f62e-05b2-abdd-3bfbafa23e10@oracle.com> References: <16796E0D-9F12-4273-87EA-5B4FEE597D6E@oracle.com> <4c9cad5e-f62e-05b2-abdd-3bfbafa23e10@oracle.com> Message-ID: <649c7477-71d6-86e7-8cdb-10e61d1821f8@oracle.com> On 11/22/2016 11:48 AM, Jamil Nimeh wrote: > A regression test for debug output? Is that something that we've done > in the past with other debug fixes? I thought we had some at one point, but can't find it now. Maybe not worth worrying about. IIRC, we had a shell script that ran with javax.net.debug=true, then we grep'd the output. Or you could use the test test/lib/testlibrary/jdk/testlibrary/ProcessTools library. output = ProcessTools.executeTestJava( getJavaCommand(cmBasePath, cPath, mName, MAIN, getVMArgs(sModuletype, getModuleName(sModuletype, sJarPath, P_PKG), args), args)) .outputTo(... Brad From Roger.Riggs at Oracle.com Tue Nov 22 21:41:54 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 22 Nov 2016 16:41:54 -0500 Subject: RFR 9: 8169416: SSLSessionImpl finalize overhead In-Reply-To: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> References: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> Message-ID: <5e1e84bf-4f10-1f23-5d36-55d441c1dad1@Oracle.com> Adding security-dev... Please review this change to remove an ineffective finalizer for SSLSessions. The finalizer removes bindings from the SSLSession of a table that is also freed when the SSLSession is being freed. There is no point in removing them explicitly. It only delays freeing memory and increases the overhead due to the tracking of finalizable objects. Details are in the issue. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-ssl-finalize-8169416 Issue: https://bugs.openjdk.java.net/browse/JDK-8169416 Thanks, Roger > From Xuelei.Fan at Oracle.Com Wed Nov 23 00:21:32 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 23 Nov 2016 08:21:32 +0800 Subject: RFR 9: 8169416: SSLSessionImpl finalize overhead In-Reply-To: <5e1e84bf-4f10-1f23-5d36-55d441c1dad1@Oracle.com> References: <5711d4dc-cfe8-c901-1623-0866163e0824@oracle.com> <5e1e84bf-4f10-1f23-5d36-55d441c1dad1@Oracle.com> Message-ID: <414AD697-091E-4F82-B17F-9B101D39858B@Oracle.Com> Looks fine to me. Thanks, Xuelei > On 23 Nov 2016, at 5:41 AM, Roger Riggs wrote: > > Adding security-dev... > > Please review this change to remove an ineffective finalizer for SSLSessions. > The finalizer removes bindings from the SSLSession of a table that is also > freed when the SSLSession is being freed. There is no point in removing them explicitly. > It only delays freeing memory and increases the overhead due to the tracking > of finalizable objects. Details are in the issue. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-ssl-finalize-8169416 > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8169416 > > Thanks, Roger >> > From sha.jiang at oracle.com Wed Nov 23 05:38:11 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 23 Nov 2016 13:38:11 +0800 Subject: RFR[9] JDK-8164595: javax/net/ssl/FixingJavadocs/SSLSessionNulls.java fails intermittently with javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake In-Reply-To: References: <9514b33b-e256-d17a-8ed7-e31dbffe8166@oracle.com> Message-ID: <8af75ff0-70ee-f8d7-3050-accb4c049923@oracle.com> Please review this patch. Thanks! John Jiang On 2016/11/19 19:38, John Jiang wrote: > After push for JDK-8168969, this fix has to use updated > SSLSocketTemplate.java. > Please review the updated webrev: > http://cr.openjdk.java.net/~jjiang/8164595/webrev.01 > > Best regards, > John Jiang > > On 2016/10/27 12:36, John Jiang wrote: >> Hi, >> Please review this patch for test >> javax/net/ssl/FixingJavadocs/SSLSessionNulls.java. >> It takes advantage of javax/net/ssl/templates/SSLTest.java to fix the >> intermittent SSLHandshakeException issue. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8164595/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8164595 >> >> Best regards, >> John Jiang > > From weijun.wang at oracle.com Wed Nov 23 10:29:35 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 23 Nov 2016 18:29:35 +0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <71690c51-a5e1-26b5-7474-f1e576c170f2@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> <71690c51-a5e1-26b5-7474-f1e576c170f2@oracle.com> Message-ID: <6baf8cb3-89a8-f512-121e-1eafd40f88bf@oracle.com> Hi Brad I think I found a problem with the test. Before you set your local java.security file, the system java.security file was already read (in jtreg initialization) and limited was picked up. In fact, I modified the java.security file of my own JDK to unlimited and the test fails. This seems to show that we have to set the system property on the command line. Either we provide a modified java.security with the test like SeanM suggested, or we create it dynamically and manually launch a new java process. I prefer the latter. Thanks Max On 11/18/2016 1:46 AM, Bradford Wetmore wrote: > SeanM pointed out that we could do a: > > @main -Djava.security.properties=xxx > > but that would require storing a snapshot of java.security. I think I > prefer it being dynamically generated. From weijun.wang at oracle.com Sat Nov 26 08:54:50 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 26 Nov 2016 16:54:50 +0800 Subject: RFR 8170364: FilePermission path modified during merge Message-ID: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8170364/webrev.00/ The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now. This fix creates a new non-public method to create this "merged" FilePermission. I checked other places and seems the name is not used to create a new FilePermission. Thanks Max From xuelei.fan at oracle.com Sun Nov 27 00:46:36 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 27 Nov 2016 08:46:36 +0800 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore Message-ID: Hi, Please review the performance enhancement update: http://cr.openjdk.java.net/~xuelei/8129988/webrev.00/ In SunJSSE provider, there are two ways to use the default trust store (lib/security/cacerts), using the default SSLContext instance or using the default trust manager. The default SSLContext holds a strong reference to a collection of trusted certificates in cacerts in static mode. The default trust manager reads the cacerts file and creates a KeyStore and parses the certificates each time. With the growth of cacerts, the loading and cache of trusted certificate is not performance friendly. In this fix, I'm trying to find a balance between CPU and memory: reuse the loaded trusted certificates if possible and release the unused trusted certificates if necessary. Thanks, Xuelei From xuelei.fan at oracle.com Sun Nov 27 01:35:38 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 27 Nov 2016 09:35:38 +0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template Message-ID: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> Hi, Please review this test update: http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ The new template (SSLSocketTemplate.java) could be used to avoid the anti-free-port issues. By using sub-classes of it, the new one can simplify the general SSLSocket test code significantly. Thanks, Xuelei From weijun.wang at oracle.com Sun Nov 27 10:04:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 27 Nov 2016 18:04:46 +0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> Message-ID: This is not only a test update. > On Nov 27, 2016, at 9:35 AM, Xuelei Fan wrote: > > Hi, > > Please review this test update: > > http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ > > The new template (SSLSocketTemplate.java) could be used to avoid the anti-free-port issues. By using sub-classes of it, the new one can simplify the general SSLSocket test code significantly. > > Thanks, > Xuelei From Alan.Bateman at oracle.com Sun Nov 27 10:12:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Nov 2016 10:12:30 +0000 Subject: RFR 8170364: FilePermission path modified during merge In-Reply-To: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> Message-ID: On 26/11/2016 08:54, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8170364/webrev.00/ > > The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now. > > This fix creates a new non-public method to create this "merged" FilePermission. > > I checked other places and seems the name is not used to create a new FilePermission. > Ideally FilePermission (and all permissions) would have final fields, I hope that can be fixed some day. In the mean-time then having withNewActions create a new FilePermission and then mutate it looks a bit ugly, can't you just introduce a new non-public constructor to create it with the effective mask? In passing then maybe the comment at L1063-1065 can be re-examined and it looks to be stale (the specific bootstrapping issue mentioned was fixed in 2015). The test is one specific scenario and I wonder if you've considered beefing this up to other scenarios and other targets so that it's more broadly testing the merging scenarios. -Alan From weijun.wang at oracle.com Sun Nov 27 11:13:52 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 27 Nov 2016 19:13:52 +0800 Subject: RFR 8170364: FilePermission path modified during merge In-Reply-To: References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> Message-ID: <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com> > On Nov 27, 2016, at 6:12 PM, Alan Bateman wrote: > > On 26/11/2016 08:54, Wang Weijun wrote: > >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8170364/webrev.00/ >> >> The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now. >> >> This fix creates a new non-public method to create this "merged" FilePermission. >> >> I checked other places and seems the name is not used to create a new FilePermission. >> > Ideally FilePermission (and all permissions) would have final fields, I hope that can be fixed some day. Me too, but we have that huge init() method now. > In the mean-time then having withNewActions create a new FilePermission and then mutate it looks a bit ugly, can't you just introduce a new non-public constructor to create it with the effective mask? The private "clone" constructor is now used in 3 places, all with a mutation right after (lines 267, 280, 993). I've taken care that only newly created objects are mutated this way. Creating 3 new constructors looks like too many duplicated codes. > > In passing then maybe the comment at L1063-1065 can be re-examined and it looks to be stale (the specific bootstrapping issue mentioned was fixed in 2015). I can try. > > The test is one specific scenario and I wonder if you've considered beefing this up to other scenarios and other targets so that it's more broadly testing the merging scenarios. I can add 2 more lines on checking the absolute path, and maybe with delete, execute and readlink (1+1+1+1, 2+2, 3+1 etc). The merge is only about the name and any name is the same, so it seems unnecessary to try other names. Thanks Max > > -Alan > > From xuelei.fan at oracle.com Sun Nov 27 12:43:21 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 27 Nov 2016 20:43:21 +0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> Message-ID: <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> On 11/27/2016 6:04 PM, Wang Weijun wrote: > This is not only a test update. > No, I happened to find an implementation issue with the new test, so fix it altogether. The issue is that the simple validator (SimpleValidator.java) does not support SKID/AKID during cert path build. If two trusted certs has the same subject, the simple validator may not be able to find the right one. Thanks, Xuelei >> On Nov 27, 2016, at 9:35 AM, Xuelei Fan wrote: >> >> Hi, >> >> Please review this test update: >> >> http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ >> >> The new template (SSLSocketTemplate.java) could be used to avoid the anti-free-port issues. By using sub-classes of it, the new one can simplify the general SSLSocket test code significantly. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Mon Nov 28 00:01:07 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 28 Nov 2016 08:01:07 +0800 Subject: RFR 8170364: FilePermission path modified during merge In-Reply-To: <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com> References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com> Message-ID: <99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com> > On Nov 27, 2016, at 7:13 PM, Wang Weijun wrote: > >> >> On Nov 27, 2016, at 6:12 PM, Alan Bateman wrote: >> >> On 26/11/2016 08:54, Wang Weijun wrote: >> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8170364/webrev.00/ >>> >>> The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2 inside. When this field is set, the permission's name is modified a little (JDK-8168127) so that when adding to a FilePermissionCollection, it is not confused with one without the field. Unfortunately, this modified name is reused in the merge to create a new "merged" FilePermission which contains a malformed path now. >>> >>> This fix creates a new non-public method to create this "merged" FilePermission. >>> >>> I checked other places and seems the name is not used to create a new FilePermission. >>> >> Ideally FilePermission (and all permissions) would have final fields, I hope that can be fixed some day. > > Me too, but we have that huge init() method now. > >> In the mean-time then having withNewActions create a new FilePermission and then mutate it looks a bit ugly, can't you just introduce a new non-public constructor to create it with the effective mask? > > The private "clone" constructor is now used in 3 places, all with a mutation right after (lines 267, 280, 993). I've taken care that only newly created objects are mutated this way. Creating 3 new constructors looks like too many duplicated codes. Do you still have a strong opinion? > >> >> In passing then maybe the comment at L1063-1065 can be re-examined and it looks to be stale (the specific bootstrapping issue mentioned was fixed in 2015). > > I can try. Changed to lambda. Tests on -testset core most pass. java/lang/invoke/lambda/LogGeneratedClassesTest.java still fails but it already failed before my change. > >> >> The test is one specific scenario and I wonder if you've considered beefing this up to other scenarios and other targets so that it's more broadly testing the merging scenarios. > > I can add 2 more lines on checking the absolute path, and maybe with delete, execute and readlink (1+1+1+1, 2+2, 3+1 etc). The merge is only about the name and any name is the same, so it seems unnecessary to try other names. Test enhanced. Permissions are granted in "read", "write", "delete", "execute", or "read,write", "delete,execute", or "read,write,delete", "execute", or "read,write,delete,execute", and 2^4-1 combinations of actions for both "x" and "/abs/x" checked. If you are OK with the above, I'll post an updated webrev. Thanks Max > > Thanks > Max > > >> >> -Alan From mallikarjuna.avaluri at oracle.com Mon Nov 28 06:54:27 2016 From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri) Date: Mon, 28 Nov 2016 12:24:27 +0530 Subject: RFR 8164881: Add more tests for JDK-8139565. In-Reply-To: References: Message-ID: <0a35e6b6-1fb5-9e43-95f3-40f7aef3e08e@oracle.com> Hi Artem Smotrakov, I have included the changes mentioned, please review the same. *Webrev: *http://cr.openjdk.java.net/~bgopularam/mavaluri/JDK-8164881/webrev.01/ * * Regards, Mallikarjuna Avaluri On 11/16/2016 4:11 AM, Artem Smotrakov wrote: > > Hi Mallikarjuna, > > I have a couple of comments. > > 1. I see you extract DSA key size from > "jdk.certpath.disabledAlgorithms" security property. I think I would > be better not to rely on it, but expect that keys less than 1024 bits > are not allowed by default. You can pass a boolean parameter to the > test which defines what should be expected. > > 2. We are trying not to use lines more than 80 symbols. Could you > please fix it? > > 3. Minor: DSAKeys.java line 342, you don't need to specify types for > HashMap > > 4. It is up to you, but it would be good to update the test to use > SSTest.java (see examples in jdk/tests) because we've been seeing > intermittent failures of JSSE tests like this one you are updating > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/93fb16cbdf7f/test/javax/net/ssl/templates/SSLTest.java > > Artem > > On 11/13/2016 09:02 PM, Mallikarjuna Avaluri wrote: >> >> Hi all, >> >> Please review the fix for following issue. >> >> JDK-8164881: Add more tests for JDK-8139565 >> https://bugs.openjdk.java.net/browse/JDK-8164881 >> >> *Summary:* Currently >> test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java checks only that >> DSA keys with size of 512 bits are disabled. >> But we also need to check that DSA keys with sizes 1024 & 2048 are >> working fine. >> >> >> *Fix: * Currently test/javax/net/ssl/TLSv12/DisabledShortDSAKeys.java >> checks only that DSA keys with size of 512 bits are disabled. >> Added new tests with DSA keys with size of 960 bits disabled, 1024, >> 2048, 3072 bits enabled. >> >> *Webrev: * >> http://cr.openjdk.java.net/~bgopularam/mavaluri/JDK-8164881/webrev.00/ >> >> >> >> Thanks, >> Mallikarjuna Avaluri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Nov 28 08:40:04 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 28 Nov 2016 16:40:04 +0800 Subject: RFR 8170364: FilePermission path modified during merge In-Reply-To: <99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com> References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com> <99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com> Message-ID: <075F53F1-ED08-4AB4-9B1D-D82A5358A01D@oracle.com> Hi Alan Updated webrev at http://cr.openjdk.java.net/~weijun/8170364/webrev.01 Changes since webrev.00: - a private constructor that can clones 4 fields and modifies 5 others - using lambda - test enhancement Thanks Max From sergei.kovalev at oracle.com Mon Nov 28 13:17:05 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 28 Nov 2016 16:17:05 +0300 Subject: RFR(s): JDK-8169866: [TESTBUG] com/sun/security/ tests have undeclared modules dependencies In-Reply-To: <900e3a01-72ae-415b-e768-675ff228e4cc@oracle.com> References: <900e3a01-72ae-415b-e768-675ff228e4cc@oracle.com> Message-ID: <0c42295c-2d61-971f-9f55-dd30b805604b@oracle.com> R-sending request for review 17.11.16 15:43, Sergei Kovalev wrote: > Hello team, > > Please review a small fix for security tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8169866 > Web review: http://cr.openjdk.java.net/~skovalev/8169866/webrev.00/ > > Issue: Tests from package com/sun/security failing in case of usage > "--limit-modules java.base" command line options due to undeclared > dependencies. > Solution: add declaration of required modules. > -- With best regards, Sergei From weijun.wang at oracle.com Mon Nov 28 13:22:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 28 Nov 2016 21:22:28 +0800 Subject: RFR(s): JDK-8169866: [TESTBUG] com/sun/security/ tests have undeclared modules dependencies In-Reply-To: <0c42295c-2d61-971f-9f55-dd30b805604b@oracle.com> References: <900e3a01-72ae-415b-e768-675ff228e4cc@oracle.com> <0c42295c-2d61-971f-9f55-dd30b805604b@oracle.com> Message-ID: Hi Sergei Looks good to me. Thanks Max On 11/28/2016 9:17 PM, Sergei Kovalev wrote: > R-sending request for review > > > 17.11.16 15:43, Sergei Kovalev wrote: >> Hello team, >> >> Please review a small fix for security tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8169866 >> Web review: http://cr.openjdk.java.net/~skovalev/8169866/webrev.00/ >> >> Issue: Tests from package com/sun/security failing in case of usage >> "--limit-modules java.base" command line options due to undeclared >> dependencies. >> Solution: add declaration of required modules. >> > From Alan.Bateman at oracle.com Mon Nov 28 14:17:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Nov 2016 14:17:05 +0000 Subject: RFR 8170364: FilePermission path modified during merge In-Reply-To: <075F53F1-ED08-4AB4-9B1D-D82A5358A01D@oracle.com> References: <2D9EFE53-ECE6-49E2-9D83-17055360EAA4@oracle.com> <6CF04250-1585-4FD4-81F7-E630121DEB84@oracle.com> <99F23B3A-AF21-4604-B9C2-B335279FF983@oracle.com> <075F53F1-ED08-4AB4-9B1D-D82A5358A01D@oracle.com> Message-ID: <2a8a0922-a967-68b4-6e8d-166ccabcc628@oracle.com> On 28/11/2016 08:40, Wang Weijun wrote: > Hi Alan > > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8170364/webrev.01 > > Changes since webrev.00: > > - a private constructor that can clones 4 fields and modifies 5 others > > - using lambda > > - test enhancement > This looks much better. A minor nit but the for readability purposes then it would be easy to read if the parameters to the constructor were all aligned rather than groups of two. -Alan From ivan.gerasimov at oracle.com Tue Nov 29 09:08:08 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 29 Nov 2016 12:08:08 +0300 Subject: [8u-dev] RFR 8170278 : ticket renewal won't happen with debugging turned on Message-ID: <9cc990e9-d4a0-7ade-8f5b-215ad92f95cf@oracle.com> Hello! It was reported that there's broken behavior exposed when the debug mode is turned on, which is due to KerberosTicket.toString() throwing an exception, if the ticket was already destroyed. The proposed fix is in fact the backport of a tiny portion of JDK-8043071. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170278 WEBREV: http://cr.openjdk.java.net/~igerasim/8170278/00/webrev/ Would you please help review? With kind regards, Ivan From sean.coffey at oracle.com Tue Nov 29 09:16:35 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 29 Nov 2016 09:16:35 +0000 Subject: [8u-dev] RFR 8170278 : ticket renewal won't happen with debugging turned on In-Reply-To: <9cc990e9-d4a0-7ade-8f5b-215ad92f95cf@oracle.com> References: <9cc990e9-d4a0-7ade-8f5b-215ad92f95cf@oracle.com> Message-ID: <9abcd965-f01a-5074-62f3-cc4878ba4537@oracle.com> Looks good. regards, Sean. On 29/11/2016 09:08, Ivan Gerasimov wrote: > Hello! > > It was reported that there's broken behavior exposed when the debug > mode is turned on, which is due to KerberosTicket.toString() throwing > an exception, if the ticket was already destroyed. > > The proposed fix is in fact the backport of a tiny portion of > JDK-8043071. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170278 > WEBREV: http://cr.openjdk.java.net/~igerasim/8170278/00/webrev/ > > Would you please help review? > > With kind regards, > Ivan From weijun.wang at oracle.com Tue Nov 29 10:59:01 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 29 Nov 2016 18:59:01 +0800 Subject: [8u-dev] RFR 8170278 : ticket renewal won't happen with debugging turned on In-Reply-To: <9abcd965-f01a-5074-62f3-cc4878ba4537@oracle.com> References: <9cc990e9-d4a0-7ade-8f5b-215ad92f95cf@oracle.com> <9abcd965-f01a-5074-62f3-cc4878ba4537@oracle.com> Message-ID: <713B2D5A-C9C4-4FBC-A990-5F59CD1266A1@oracle.com> +1 --Max > On Nov 29, 2016, at 5:16 PM, Se?n Coffey wrote: > > Looks good. > > regards, > Sean. > > > On 29/11/2016 09:08, Ivan Gerasimov wrote: >> Hello! >> >> It was reported that there's broken behavior exposed when the debug mode is turned on, which is due to KerberosTicket.toString() throwing an exception, if the ticket was already destroyed. >> >> The proposed fix is in fact the backport of a tiny portion of JDK-8043071. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170278 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8170278/00/webrev/ >> >> Would you please help review? >> >> With kind regards, >> Ivan > From sean.mullan at oracle.com Tue Nov 29 13:22:49 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Nov 2016 08:22:49 -0500 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> Message-ID: <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> On 11/27/16 7:43 AM, Xuelei Fan wrote: > On 11/27/2016 6:04 PM, Wang Weijun wrote: >> This is not only a test update. >> > No, I happened to find an implementation issue with the new test, so fix > it altogether. The issue is that the simple validator > (SimpleValidator.java) does not support SKID/AKID during cert path > build. If two trusted certs has the same subject, the simple validator > may not be able to find the right one. We have had issues in the PKIX CertPathBuilder with matching on AKID/SKID when building certpaths, so we want to be careful not to introduce a similar issue. See this bug for more information: https://bugs.openjdk.java.net/browse/JDK-8072463 I have not reviewed the fix enough to know if this issue applies here but please double-check it. --Sean > > Thanks, > Xuelei > >>> On Nov 27, 2016, at 9:35 AM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Please review this test update: >>> >>> http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ >>> >>> The new template (SSLSocketTemplate.java) could be used to avoid the >>> anti-free-port issues. By using sub-classes of it, the new one can >>> simplify the general SSLSocket test code significantly. >>> >>> Thanks, >>> Xuelei >> From valerie.peng at oracle.com Wed Nov 30 00:58:22 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 29 Nov 2016 16:58:22 -0800 Subject: [9] RFR: JDK-8170245 [TEST_BUG] Cipher tests fail when running with unlimited policy Message-ID: <904f38dc-f9bd-c392-7a9e-00b8d0b19ef8@oracle.com> Anyone has cycles to review this fix? Some cipher tests fail when running against unlimited crypto policy due to hardcoded checks and values. Changes are straight-forward. However, given the dependency between the tests (as they are ported from SQE tests in the previous co-location effort), I mostly just made the minimum changes needed for the test to work when unlimited crypto policy is in use. Webrev: http://cr.openjdk.java.net/~valeriep/8170245/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8170245 Thanks, Valerie From sibabrata.sahoo at oracle.com Wed Nov 30 09:27:39 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 30 Nov 2016 01:27:39 -0800 (PST) Subject: [9] RFR 8170247: java/security/SecureRandom/ApiTest fails when run with unlimited policy. Message-ID: <2bc5b654-dd65-42a4-b5f0-cc48b4b417fd@default> Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8170247 Webrev: http://cr.openjdk.java.net/~ssahoo/8170247/webrev.00/ Description: The Test was failing to handle the expected failure for invalid parameters, when the SecureRandom parameter size is > algorithm running with unlimited policy. I have modified the condition to handle the expected failures correctly. The change is only applicable to the "if" condition(Line:200). The other 2 lines are minor changes related to statement performance and renaming a variable. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Nov 30 09:37:13 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 30 Nov 2016 17:37:13 +0800 Subject: [9] RFR 8170247: java/security/SecureRandom/ApiTest fails when run with unlimited policy. In-Reply-To: <2bc5b654-dd65-42a4-b5f0-cc48b4b417fd@default> References: <2bc5b654-dd65-42a4-b5f0-cc48b4b417fd@default> Message-ID: <0f01a8f8-94a4-28b0-3600-e935e34ab9f8@oracle.com> Change looks fine. One nit: the extra space at the beginning of line 24 looks strange. Thanks Max On 11/30/2016 5:27 PM, Sibabrata Sahoo wrote: > Hi, > > > > Please review the patch for, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8170247 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8170247/webrev.00/ > > > > Description: > > The Test was failing to handle the expected failure for invalid > parameters, when the SecureRandom parameter size is > algorithm running > with unlimited policy. I have modified the condition to handle the > expected failures correctly. The change is only applicable to the ?if? > condition(Line:200). The other 2 lines are minor changes related to > statement performance and renaming a variable. > > > > Thanks, > > Siba > > > From goetz.lindenmaier at sap.com Wed Nov 30 13:12:13 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 30 Nov 2016 13:12:13 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding Message-ID: Hi, I'd like to propose a row of smaller fixes where code is noted down a bit questionable. SAP's quality process requires that we fix these in our internal delivery, and I Would like to share my fixes with openJdk. Some of these fixes are of more theoretical nature as how I understand the code paths never allow the problematic situation, but fixing it nevertheless assures that nothing is overseen if the code changes. Most changes are in libawt_xawt, some are in libsunec. I'd appreciate a review: http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ Changes in detail: awt_InputMethod.c: One might overrun the 100 byte fixed-size string statusWindow->status by copying text->string.multi_byte without checking the length. gtk3_interface.c: This less-than-zero comparison of an unsigned value is never true. Using uninitialized value color. Field color.alpha is uninitialized. E.g. used at gtk3_interface.c:2287. XToolkit.c Using uninitialized value ret_timeout. E.g. in XToolkit.c:6809. XWindow.c Argument is incompatible with corresponding format string conversion. splashscreen_sys.c Overflowed or truncated value (or a value computed from an overflowed or truncated value) (gdk_scale > 0) ? native_scale * (double)gdk_scale : native_scale used as return value. ec.c Using uninitialized value k.dp when calling mp_clear. ecdecode.c You might overrun the 291 byte fixed-size string genenc by copying curveParams->geny without checking the length. Added sanity check before doing the string concatenation. ecl_mult.c Using uninitialized value kt.flag when calling *group->point_mul. (The function pointer resolves to ec_GF2m_pt_mul_mont.) mpi.c Using uninitialized value s. Field s.flag is uninitialized when calling s_mp_exch. Using uninitialized value tmp. Field tmp.flag is uninitialized when calling s_mp_exch Using uninitialized value t.dp when calling mp_clear. p11_mutex.c Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is uninitialized when calling memcpy. DataBufferNative.c Using uninitialized value lockInfo.rasBase when calling BN_GetPixelPointer. fontpath.c You might overrun the 512 byte fixed-size string fontDirPath by copying DirP->name[index] without checking the length. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Wed Nov 30 13:52:30 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 30 Nov 2016 13:52:30 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: References: Message-ID: Hello Goetz, Please modify the bug summary to reference ECC too. Your ECC changes look fine but the ?Last Modified Date? line in the 4 source code headers will need to be updated/added. BTW p11_mutex.c is listed below but appears to be missing from the webrev. Thanks. > On 30 Nov 2016, at 13:12, Lindenmaier, Goetz wrote: > > Hi, > > I?d like to propose a row of smaller fixes where code is noted down a bit questionable. > SAP?s quality process requires that we fix these in our internal delivery, and I > Would like to share my fixes with openJdk. Some of these fixes are of more > theoretical nature as how I understand the code paths never allow the > problematic situation, but fixing it nevertheless assures that nothing is > overseen if the code changes. Most changes are in libawt_xawt, some > are in libsunec. > > I?d appreciate a review: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > Changes in detail: > > awt_InputMethod.c: > > One might overrun the 100 byte fixed-size string statusWindow->status by copying text->string.multi_byte without checking the length. > > gtk3_interface.c: > > This less-than-zero comparison of an unsigned value is never true. > > Using uninitialized value color. Field color.alpha is uninitialized. > E.g. used at gtk3_interface.c:2287. > > XToolkit.c > > Using uninitialized value ret_timeout. > E.g. in XToolkit.c:6809. > > XWindow.c > > Argument is incompatible with corresponding format string conversion. > > splashscreen_sys.c > > Overflowed or truncated value (or a value computed from an overflowed or truncated value) (gdk_scale > 0) ? native_scale * (double)gdk_scale : native_scale used as return value. > > ec.c > > Using uninitialized value k.dp when calling mp_clear. > > ecdecode.c > > You might overrun the 291 byte fixed-size string genenc by copying curveParams->geny without checking the length. > Added sanity check before doing the string concatenation. > > ecl_mult.c > > Using uninitialized value kt.flag when calling *group->point_mul. (The function pointer resolves to ec_GF2m_pt_mul_mont.) > > mpi.c > > Using uninitialized value s. Field s.flag is uninitialized when calling s_mp_exch. > Using uninitialized value tmp. Field tmp.flag is uninitialized when calling s_mp_exch > Using uninitialized value t.dp when calling mp_clear. > > p11_mutex.c > > Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is uninitialized when calling memcpy. > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling BN_GetPixelPointer. > > fontpath.c > > You might overrun the 512 byte fixed-size string fontDirPath by copying DirP->name[index] without checking the length. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Nov 30 15:41:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 30 Nov 2016 15:41:15 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: References: Message-ID: Hi Vincent, thanks for the quit review! Good catch that I lost the change to p11_mutex.c ... I had to change it and it fell out of my patches. I edited the Last Modified Date, and also updated the copyright messages. New webrev: http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ Best regards, Goetz. (Am I correct that your openJdk name is Vinnie?) > -----Original Message----- > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > Sent: Mittwoch, 30. November 2016 14:53 > To: Lindenmaier, Goetz > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > > Hello Goetz, > > Please modify the bug summary to reference ECC too. > Your ECC changes look fine but the ?Last Modified Date? line in the 4 source > code headers will need to be updated/added. > > BTW p11_mutex.c is listed below but appears to be missing from the webrev. > > Thanks. > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > > wrote: > > Hi, > > I?d like to propose a row of smaller fixes where code is noted down a > bit questionable. > SAP?s quality process requires that we fix these in our internal delivery, > and I > Would like to share my fixes with openJdk. Some of these fixes are of > more > theoretical nature as how I understand the code paths never allow the > problematic situation, but fixing it nevertheless assures that nothing is > overseen if the code changes. Most changes are in libawt_xawt, some > are in libsunec. > > I?d appreciate a review: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > Changes in detail: > > awt_InputMethod.c: > > One might overrun the 100 byte fixed-size string statusWindow->status > by copying text->string.multi_byte without checking the length. > > gtk3_interface.c: > > This less-than-zero comparison of an unsigned value is never true. > > Using uninitialized value color. Field color.alpha is uninitialized. > E.g. used at gtk3_interface.c:2287. > > XToolkit.c > > Using uninitialized value ret_timeout. > E.g. in XToolkit.c:6809. > > XWindow.c > > Argument is incompatible with corresponding format string conversion. > > splashscreen_sys.c > > Overflowed or truncated value (or a value computed from an > overflowed or truncated value) (gdk_scale > 0) ? native_scale * > (double)gdk_scale : native_scale used as return value. > > ec.c > > Using uninitialized value k.dp when calling mp_clear. > > ecdecode.c > > You might overrun the 291 byte fixed-size string genenc by copying > curveParams->geny without checking the length. > Added sanity check before doing the string concatenation. > > ecl_mult.c > > Using uninitialized value kt.flag when calling *group->point_mul. (The > function pointer resolves to ec_GF2m_pt_mul_mont.) > > mpi.c > > Using uninitialized value s. Field s.flag is uninitialized when calling > s_mp_exch. > Using uninitialized value tmp. Field tmp.flag is uninitialized when > calling s_mp_exch > Using uninitialized value t.dp when calling mp_clear. > > p11_mutex.c > > Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > uninitialized when calling memcpy. > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling > BN_GetPixelPointer. > > fontpath.c > > You might overrun the 512 byte fixed-size string fontDirPath by copying > DirP->name[index] without checking the length. > From vincent.x.ryan at oracle.com Wed Nov 30 16:09:56 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 30 Nov 2016 16:09:56 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: References: Message-ID: <1D1BCEF7-AD74-4358-8DE3-1073649A55DF@oracle.com> Note that I have reviewed only the ECC/PKCS11 changes. You?ll need a JDK 9 reviewer from awt-dev for your remaining changes. There is a minor typo in the commit message: s/ece/ECC Also please change the Bug Summary in JBS to indicate that ECC and PKCS11 changes are also present. > On 30 Nov 2016, at 15:41, Lindenmaier, Goetz wrote: > > Hi Vincent, > > thanks for the quit review! > Good catch that I lost the change to p11_mutex.c ... I had to change > it and it fell out of my patches. That looks fine. > I edited the Last Modified Date, and also updated the copyright messages. Thanks. > New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > > Best regards, > Goetz. > > (Am I correct that your openJdk name is Vinnie?) Yes. > >> -----Original Message----- >> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >> Sent: Mittwoch, 30. November 2016 14:53 >> To: Lindenmaier, Goetz >> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >> >> Hello Goetz, >> >> Please modify the bug summary to reference ECC too. >> Your ECC changes look fine but the ?Last Modified Date? line in the 4 source >> code headers will need to be updated/added. >> >> BTW p11_mutex.c is listed below but appears to be missing from the webrev. >> >> Thanks. >> >> >> >> >> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >> > wrote: >> >> Hi, >> >> I?d like to propose a row of smaller fixes where code is noted down a >> bit questionable. >> SAP?s quality process requires that we fix these in our internal delivery, >> and I >> Would like to share my fixes with openJdk. Some of these fixes are of >> more >> theoretical nature as how I understand the code paths never allow the >> problematic situation, but fixing it nevertheless assures that nothing is >> overseen if the code changes. Most changes are in libawt_xawt, some >> are in libsunec. >> >> I?d appreciate a review: >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >> >> Changes in detail: >> >> awt_InputMethod.c: >> >> One might overrun the 100 byte fixed-size string statusWindow->status >> by copying text->string.multi_byte without checking the length. >> >> gtk3_interface.c: >> >> This less-than-zero comparison of an unsigned value is never true. >> >> Using uninitialized value color. Field color.alpha is uninitialized. >> E.g. used at gtk3_interface.c:2287. >> >> XToolkit.c >> >> Using uninitialized value ret_timeout. >> E.g. in XToolkit.c:6809. >> >> XWindow.c >> >> Argument is incompatible with corresponding format string conversion. >> >> splashscreen_sys.c >> >> Overflowed or truncated value (or a value computed from an >> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >> (double)gdk_scale : native_scale used as return value. >> >> ec.c >> >> Using uninitialized value k.dp when calling mp_clear. >> >> ecdecode.c >> >> You might overrun the 291 byte fixed-size string genenc by copying >> curveParams->geny without checking the length. >> Added sanity check before doing the string concatenation. >> >> ecl_mult.c >> >> Using uninitialized value kt.flag when calling *group->point_mul. (The >> function pointer resolves to ec_GF2m_pt_mul_mont.) >> >> mpi.c >> >> Using uninitialized value s. Field s.flag is uninitialized when calling >> s_mp_exch. >> Using uninitialized value tmp. Field tmp.flag is uninitialized when >> calling s_mp_exch >> Using uninitialized value t.dp when calling mp_clear. >> >> p11_mutex.c >> >> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is >> uninitialized when calling memcpy. >> >> >> DataBufferNative.c >> >> Using uninitialized value lockInfo.rasBase when calling >> BN_GetPixelPointer. >> >> fontpath.c >> >> You might overrun the 512 byte fixed-size string fontDirPath by copying >> DirP->name[index] without checking the length. >> > From Sergey.Bylokhov at oracle.com Wed Nov 30 18:00:22 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 30 Nov 2016 21:00:22 +0300 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: References: Message-ID: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> cc 2d-dev. On 30.11.16 18:41, Lindenmaier, Goetz wrote: > Hi Vincent, > > thanks for the quit review! > Good catch that I lost the change to p11_mutex.c ... I had to change > it and it fell out of my patches. > I edited the Last Modified Date, and also updated the copyright messages. > New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > > Best regards, > Goetz. > > (Am I correct that your openJdk name is Vinnie?) > >> -----Original Message----- >> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >> Sent: Mittwoch, 30. November 2016 14:53 >> To: Lindenmaier, Goetz >> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >> >> Hello Goetz, >> >> Please modify the bug summary to reference ECC too. >> Your ECC changes look fine but the ?Last Modified Date? line in the 4 source >> code headers will need to be updated/added. >> >> BTW p11_mutex.c is listed below but appears to be missing from the webrev. >> >> Thanks. >> >> >> >> >> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >> > wrote: >> >> Hi, >> >> I?d like to propose a row of smaller fixes where code is noted down a >> bit questionable. >> SAP?s quality process requires that we fix these in our internal delivery, >> and I >> Would like to share my fixes with openJdk. Some of these fixes are of >> more >> theoretical nature as how I understand the code paths never allow the >> problematic situation, but fixing it nevertheless assures that nothing is >> overseen if the code changes. Most changes are in libawt_xawt, some >> are in libsunec. >> >> I?d appreciate a review: >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >> >> Changes in detail: >> >> awt_InputMethod.c: >> >> One might overrun the 100 byte fixed-size string statusWindow->status >> by copying text->string.multi_byte without checking the length. >> >> gtk3_interface.c: >> >> This less-than-zero comparison of an unsigned value is never true. >> >> Using uninitialized value color. Field color.alpha is uninitialized. >> E.g. used at gtk3_interface.c:2287. >> >> XToolkit.c >> >> Using uninitialized value ret_timeout. >> E.g. in XToolkit.c:6809. >> >> XWindow.c >> >> Argument is incompatible with corresponding format string conversion. >> >> splashscreen_sys.c >> >> Overflowed or truncated value (or a value computed from an >> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >> (double)gdk_scale : native_scale used as return value. >> >> ec.c >> >> Using uninitialized value k.dp when calling mp_clear. >> >> ecdecode.c >> >> You might overrun the 291 byte fixed-size string genenc by copying >> curveParams->geny without checking the length. >> Added sanity check before doing the string concatenation. >> >> ecl_mult.c >> >> Using uninitialized value kt.flag when calling *group->point_mul. (The >> function pointer resolves to ec_GF2m_pt_mul_mont.) >> >> mpi.c >> >> Using uninitialized value s. Field s.flag is uninitialized when calling >> s_mp_exch. >> Using uninitialized value tmp. Field tmp.flag is uninitialized when >> calling s_mp_exch >> Using uninitialized value t.dp when calling mp_clear. >> >> p11_mutex.c >> >> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is >> uninitialized when calling memcpy. >> >> >> DataBufferNative.c >> >> Using uninitialized value lockInfo.rasBase when calling >> BN_GetPixelPointer. >> >> fontpath.c >> >> You might overrun the 512 byte fixed-size string fontDirPath by copying >> DirP->name[index] without checking the length. >> > -- Best regards, Sergey. From christoph.langer at sap.com Wed Nov 30 19:46:52 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Nov 2016 19:46:52 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: References: Message-ID: <9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap> Hi Goetz, I have some small remarks. src/java.desktop/unix/native/common/awt/fontpath.c: 247 fontDirPath[sizeof(fontDirPath)-1] = '\0'; -> you should add spaces left and right of '-' 248 strncat(fontDirPath, "/fonts.dir", sizeof(fontDirPath) - strlen(fontDirPath)); -> I think you need to subtract 1 from the 3rd parameter of strncat ('size_t n') because man page says: "If src contains n or more bytes, strncat() writes n+1 bytes to dest (n from src plus the terminating null byte). Therefore, the size of dest must be at least strlen(dest)+n+1." src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c: add spaces around '-' in the array index The rest looks fine to me. Best regards Christoph > -----Original Message----- > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf > Of Lindenmaier, Goetz > Sent: Mittwoch, 30. November 2016 16:41 > To: Vincent Ryan > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding > > Hi Vincent, > > thanks for the quit review! > Good catch that I lost the change to p11_mutex.c ... I had to change > it and it fell out of my patches. > I edited the Last Modified Date, and also updated the copyright messages. > New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > > Best regards, > Goetz. > > (Am I correct that your openJdk name is Vinnie?) > > > -----Original Message----- > > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > > Sent: Mittwoch, 30. November 2016 14:53 > > To: Lindenmaier, Goetz > > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > > Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > > > > Hello Goetz, > > > > Please modify the bug summary to reference ECC too. > > Your ECC changes look fine but the ?Last Modified Date? line in the 4 source > > code headers will need to be updated/added. > > > > BTW p11_mutex.c is listed below but appears to be missing from the webrev. > > > > Thanks. > > > > > > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > > > wrote: > > > > Hi, > > > > I?d like to propose a row of smaller fixes where code is noted down a > > bit questionable. > > SAP?s quality process requires that we fix these in our internal delivery, > > and I > > Would like to share my fixes with openJdk. Some of these fixes are of > > more > > theoretical nature as how I understand the code paths never allow the > > problematic situation, but fixing it nevertheless assures that nothing is > > overseen if the code changes. Most changes are in libawt_xawt, some > > are in libsunec. > > > > I?d appreciate a review: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > > > Changes in detail: > > > > awt_InputMethod.c: > > > > One might overrun the 100 byte fixed-size string statusWindow->status > > by copying text->string.multi_byte without checking the length. > > > > gtk3_interface.c: > > > > This less-than-zero comparison of an unsigned value is never true. > > > > Using uninitialized value color. Field color.alpha is uninitialized. > > E.g. used at gtk3_interface.c:2287. > > > > XToolkit.c > > > > Using uninitialized value ret_timeout. > > E.g. in XToolkit.c:6809. > > > > XWindow.c > > > > Argument is incompatible with corresponding format string conversion. > > > > splashscreen_sys.c > > > > Overflowed or truncated value (or a value computed from an > > overflowed or truncated value) (gdk_scale > 0) ? native_scale * > > (double)gdk_scale : native_scale used as return value. > > > > ec.c > > > > Using uninitialized value k.dp when calling mp_clear. > > > > ecdecode.c > > > > You might overrun the 291 byte fixed-size string genenc by copying > > curveParams->geny without checking the length. > > Added sanity check before doing the string concatenation. > > > > ecl_mult.c > > > > Using uninitialized value kt.flag when calling *group->point_mul. (The > > function pointer resolves to ec_GF2m_pt_mul_mont.) > > > > mpi.c > > > > Using uninitialized value s. Field s.flag is uninitialized when calling > > s_mp_exch. > > Using uninitialized value tmp. Field tmp.flag is uninitialized when > > calling s_mp_exch > > Using uninitialized value t.dp when calling mp_clear. > > > > p11_mutex.c > > > > Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > > uninitialized when calling memcpy. > > > > > > DataBufferNative.c > > > > Using uninitialized value lockInfo.rasBase when calling > > BN_GetPixelPointer. > > > > fontpath.c > > > > You might overrun the 512 byte fixed-size string fontDirPath by copying > > DirP->name[index] without checking the length. > > From philip.race at oracle.com Wed Nov 30 19:58:44 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 Nov 2016 11:58:44 -0800 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> Message-ID: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> Hi Goetz, > DataBufferNative.c > Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer. 75 lockInfo.resBase = NULL; Did you actually compile this ? The variable is called "rasBase", not "resBase". And strictly there is no problem since inside DBN_GetPixelPointer the code calls ops->Lock which should initialise this. A "rasBase" of 0 isn't really any better than a random one .. Also I don't see why there's a problem here and not in the function immediately following since it is the exact same case. -phil. On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > cc 2d-dev. > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: >> Hi Vincent, >> >> thanks for the quit review! >> Good catch that I lost the change to p11_mutex.c ... I had to change >> it and it fell out of my patches. >> I edited the Last Modified Date, and also updated the copyright >> messages. >> New webrev: >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >> >> Best regards, >> Goetz. >> >> (Am I correct that your openJdk name is Vinnie?) >> >>> -----Original Message----- >>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>> Sent: Mittwoch, 30. November 2016 14:53 >>> To: Lindenmaier, Goetz >>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>> >>> Hello Goetz, >>> >>> Please modify the bug summary to reference ECC too. >>> Your ECC changes look fine but the ?Last Modified Date? line in the >>> 4 source >>> code headers will need to be updated/added. >>> >>> BTW p11_mutex.c is listed below but appears to be missing from the >>> webrev. >>> >>> Thanks. >>> >>> >>> >>> >>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>> > wrote: >>> >>> Hi, >>> >>> I?d like to propose a row of smaller fixes where code is noted >>> down a >>> bit questionable. >>> SAP?s quality process requires that we fix these in our internal >>> delivery, >>> and I >>> Would like to share my fixes with openJdk. Some of these fixes >>> are of >>> more >>> theoretical nature as how I understand the code paths never >>> allow the >>> problematic situation, but fixing it nevertheless assures that >>> nothing is >>> overseen if the code changes. Most changes are in libawt_xawt, >>> some >>> are in libsunec. >>> >>> I?d appreciate a review: >>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>> >>> Changes in detail: >>> >>> awt_InputMethod.c: >>> >>> One might overrun the 100 byte fixed-size string >>> statusWindow->status >>> by copying text->string.multi_byte without checking the length. >>> >>> gtk3_interface.c: >>> >>> This less-than-zero comparison of an unsigned value is never true. >>> >>> Using uninitialized value color. Field color.alpha is >>> uninitialized. >>> E.g. used at gtk3_interface.c:2287. >>> >>> XToolkit.c >>> >>> Using uninitialized value ret_timeout. >>> E.g. in XToolkit.c:6809. >>> >>> XWindow.c >>> >>> Argument is incompatible with corresponding format string >>> conversion. >>> >>> splashscreen_sys.c >>> >>> Overflowed or truncated value (or a value computed from an >>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>> (double)gdk_scale : native_scale used as return value. >>> >>> ec.c >>> >>> Using uninitialized value k.dp when calling mp_clear. >>> >>> ecdecode.c >>> >>> You might overrun the 291 byte fixed-size string genenc by copying >>> curveParams->geny without checking the length. >>> Added sanity check before doing the string concatenation. >>> >>> ecl_mult.c >>> >>> Using uninitialized value kt.flag when calling >>> *group->point_mul. (The >>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>> >>> mpi.c >>> >>> Using uninitialized value s. Field s.flag is uninitialized when >>> calling >>> s_mp_exch. >>> Using uninitialized value tmp. Field tmp.flag is uninitialized when >>> calling s_mp_exch >>> Using uninitialized value t.dp when calling mp_clear. >>> >>> p11_mutex.c >>> >>> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is >>> uninitialized when calling memcpy. >>> >>> >>> DataBufferNative.c >>> >>> Using uninitialized value lockInfo.rasBase when calling >>> BN_GetPixelPointer. >>> >>> fontpath.c >>> >>> You might overrun the 512 byte fixed-size string fontDirPath by >>> copying >>> DirP->name[index] without checking the length. >>> >> > >