From sergei.kovalev at oracle.com Mon Oct 3 10:07:56 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 13:07:56 +0300 Subject: RFR(s): 8166378: Missing dependencies in several java/security tests In-Reply-To: References: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com> Message-ID: Resending this for review 27.09.16 15:56, Sergei Kovalev wrote: > Hello team, > > This is re-request for review. > > > 20.09.16 16:32, Sergei Kovalev wrote: >> Hello team, >> >> Please review very small fix for several regression tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8166378 >> WebReview: http://cr.openjdk.java.net/~skovalev/8166378/webrev.00 >> >> Issue: The tests has no declared dependencies on jdk.security >> modules. This leads the tests to fail in case of usage >> "--limit-modules" java command line option. >> >> Solution: add missed dependencies if required. >> > -- With best regards, Sergei From svetlana.nikandrova at oracle.com Mon Oct 3 12:55:04 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Mon, 03 Oct 2016 15:55:04 +0300 Subject: RFR 8166976: TestCipherPBECons has wrong @run line In-Reply-To: References: Message-ID: <57F25528.6040907@oracle.com> Martin, thank you for catching this! Best regards, Svetlana On 30.09.2016 20:41, Martin Buchholz wrote: > https://bugs.openjdk.java.net/browse/JDK-8166976 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TestCipherPBECons/ > From sergei.kovalev at oracle.com Tue Oct 4 08:56:23 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 4 Oct 2016 11:56:23 +0300 Subject: RFR(s): 8166378: Missing dependencies in several java/security tests In-Reply-To: References: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com> Message-ID: Thank you for review 27.09.16 16:06, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 9/20/2016 9:32 PM, Sergei Kovalev wrote: >> Hello team, >> >> Please review very small fix for several regression tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8166378 >> WebReview: http://cr.openjdk.java.net/~skovalev/8166378/webrev.00 >> >> Issue: The tests has no declared dependencies on jdk.security modules. >> This leads the tests to fail in case of usage "--limit-modules" java >> command line option. >> >> Solution: add missed dependencies if required. >> > -- With best regards, Sergei From valerie.peng at oracle.com Tue Oct 4 22:07:20 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 4 Oct 2016 15:07:20 -0700 Subject: [9] RFR 8165275: Replace the reflective call to the implUpdate method in HandshakeMessage::digestKey Message-ID: Hi Xuelei, Could you please help reviewing this JSSE-related code refactoring? Bug: https://bugs.openjdk.java.net/browse/JDK-8165275 Webrev: http://cr.openjdk.java.net/~valeriep/8165275/webrev.00/ Thanks, Valerie From j.p.cranendonk at gmail.com Wed Oct 5 08:06:33 2016 From: j.p.cranendonk at gmail.com (Jeroen Cranendonk) Date: Wed, 5 Oct 2016 10:06:33 +0200 Subject: Java 9 - Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files Message-ID: Hi! The bane of my existance for the last decade or so has been dealing with errors because the Java Unlimited Strength Jurisdiction Policy Files have not been installed, and finding ways of getting them installed. I was wondering what the state of this is for Java 9? I can't find any Java 9 policy files for the current ea builds of Java 9. But I also can't find any mention of them no longer being required. Worryingly, the old test for whether they're installled, based on AES max cipher length, still gives me 128 (code pasted after this mail), which suggests they are still needed. It seems that the requirement for having unlimited strength jurisdiction policy files has been dropped a long long time ago, but noone ever got around to actually implementing the change: https://bugs.openjdk.java.net/browse/JDK-7024850 I was hoping with Java 9 this would finalyl be solved :) Test: import javax.crypto.Cipher; class Test { public static void main(String[] args) { try { System.out.println("Hello World!"); int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES"); System.out.println(maxKeyLen); } catch (Exception e){ System.out.println("Sad world :("); } } } From vincent.x.ryan at oracle.com Wed Oct 5 10:22:53 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 5 Oct 2016 11:22:53 +0100 Subject: Java 9 - Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files In-Reply-To: References: Message-ID: JDK-8061842 has added improvements in JDK 9 to simplify the management of crypto strength. See README.txt for details. Adding, 'Security.setProperty(?crypto.policy?, ?unlimited?);' or editing the java.security configuration file will enable unlimited strength. > On 5 Oct 2016, at 09:06, Jeroen Cranendonk wrote: > > Hi! > > The bane of my existance for the last decade or so has been dealing > with errors because the Java Unlimited Strength Jurisdiction Policy > Files have not been installed, and finding ways of getting them > installed. > > I was wondering what the state of this is for Java 9? > > I can't find any Java 9 policy files for the current ea builds of Java 9. > But I also can't find any mention of them no longer being required. > Worryingly, the old test for whether they're installled, based on AES > max cipher length, still gives me 128 (code pasted after this mail), > which suggests they are still needed. > > It seems that the requirement for having unlimited strength > jurisdiction policy files has been dropped a long long time ago, but > noone ever got around to actually implementing the change: > https://bugs.openjdk.java.net/browse/JDK-7024850 > > I was hoping with Java 9 this would finalyl be solved :) > > Test: > import javax.crypto.Cipher; > class Test { > public static void main(String[] args) { > try { > System.out.println("Hello World!"); > int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES"); > System.out.println(maxKeyLen); > } catch (Exception e){ > System.out.println("Sad world :("); > } > } > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Oct 5 14:57:20 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 5 Oct 2016 10:57:20 -0400 Subject: RFR:8166632: Document how to grant permissions for a module jrt:/ in the image Message-ID: <8bb3a090-993f-e13f-714f-9137f855159a@oracle.com> The "jrt" URL scheme syntax is new and not widely known yet, so an example has been added to the conf/security/java.policy file to help users show how to grant permissions to a module: http://cr.openjdk.java.net/~mullan/webrevs/8166632/webrev.00/ Thanks, Sean From Alan.Bateman at oracle.com Wed Oct 5 14:58:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Oct 2016 15:58:41 +0100 Subject: RFR:8166632: Document how to grant permissions for a module jrt:/ in the image In-Reply-To: <8bb3a090-993f-e13f-714f-9137f855159a@oracle.com> References: <8bb3a090-993f-e13f-714f-9137f855159a@oracle.com> Message-ID: <617860f1-b8d7-3e4b-3e1d-97c7f06dc20e@oracle.com> On 05/10/2016 15:57, Sean Mullan wrote: > The "jrt" URL scheme syntax is new and not widely known yet, so an > example has been added to the conf/security/java.policy file to help > users show how to grant permissions to a module: > > http://cr.openjdk.java.net/~mullan/webrevs/8166632/webrev.00/ It might be clearer to say "for modules linked into the runtime image" rather just "for modules", just in case someone thing this is the way to grant permissions to modules on the module path. -Alan From sean.mullan at oracle.com Wed Oct 5 15:18:37 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 5 Oct 2016 11:18:37 -0400 Subject: RFR:8166632: Document how to grant permissions for a module jrt:/ in the image In-Reply-To: <617860f1-b8d7-3e4b-3e1d-97c7f06dc20e@oracle.com> References: <8bb3a090-993f-e13f-714f-9137f855159a@oracle.com> <617860f1-b8d7-3e4b-3e1d-97c7f06dc20e@oracle.com> Message-ID: <831fd737-5674-cd28-cc37-dd2141cbd708@oracle.com> On 10/05/2016 10:58 AM, Alan Bateman wrote: > > > On 05/10/2016 15:57, Sean Mullan wrote: >> The "jrt" URL scheme syntax is new and not widely known yet, so an >> example has been added to the conf/security/java.policy file to help >> users show how to grant permissions to a module: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8166632/webrev.00/ > It might be clearer to say "for modules linked into the runtime image" > rather just "for modules", just in case someone thing this is the way to > grant permissions to modules on the module path. Good point. Will make that change. --Sean From mandy.chung at oracle.com Wed Oct 5 16:08:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 5 Oct 2016 09:08:37 -0700 Subject: RFR:8166632: Document how to grant permissions for a module jrt:/ in the image In-Reply-To: <831fd737-5674-cd28-cc37-dd2141cbd708@oracle.com> References: <8bb3a090-993f-e13f-714f-9137f855159a@oracle.com> <617860f1-b8d7-3e4b-3e1d-97c7f06dc20e@oracle.com> <831fd737-5674-cd28-cc37-dd2141cbd708@oracle.com> Message-ID: <730FCF6E-6530-48E7-ABF0-B113C4539206@oracle.com> > On Oct 5, 2016, at 8:18 AM, Sean Mullan wrote: > > On 10/05/2016 10:58 AM, Alan Bateman wrote: >> >> >> On 05/10/2016 15:57, Sean Mullan wrote: >>> The "jrt" URL scheme syntax is new and not widely known yet, so an >>> example has been added to the conf/security/java.policy file to help >>> users show how to grant permissions to a module: >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/8166632/webrev.00/ >> It might be clearer to say "for modules linked into the runtime image" >> rather just "for modules", just in case someone thing this is the way to >> grant permissions to modules on the module path. > > Good point. Will make that change. +1. Mandy From bradford.wetmore at oracle.com Wed Oct 5 19:53:57 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 5 Oct 2016 12:53:57 -0700 Subject: Java 9 - Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files In-Reply-To: References: Message-ID: <70c2dbe5-1277-85a9-b8a6-8d2cd0505c7e@oracle.com> > The bane of my existance for the last decade Us too. > See README.txt for details. Better still, see: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f82971b324f6/src/java.base/share/conf/security/java.security Lines 807-855 crypto.policydir-tbd defaults to "limited" in an OracleJDK build. See: /jdk9-dev/jdk/make/gendata/Gendata-java.base.gmk Brad On 10/5/2016 3:22 AM, Vincent Ryan wrote: > JDK-8061842 has added > improvements in JDK 9 to simplify the management of crypto strength. > See README.txt > for > details. > > Adding, 'Security.setProperty(?crypto.policy?, ?unlimited?);' or editing > the java.security configuration file > will enable unlimited strength. > > >> On 5 Oct 2016, at 09:06, Jeroen Cranendonk > > wrote: >> >> Hi! >> >> The bane of my existance for the last decade or so has been dealing >> with errors because the Java Unlimited Strength Jurisdiction Policy >> Files have not been installed, and finding ways of getting them >> installed. >> >> I was wondering what the state of this is for Java 9? >> >> I can't find any Java 9 policy files for the current ea builds of Java 9. >> But I also can't find any mention of them no longer being required. >> Worryingly, the old test for whether they're installled, based on AES >> max cipher length, still gives me 128 (code pasted after this mail), >> which suggests they are still needed. >> >> It seems that the requirement for having unlimited strength >> jurisdiction policy files has been dropped a long long time ago, but >> noone ever got around to actually implementing the change: >> https://bugs.openjdk.java.net/browse/JDK-7024850 >> >> I was hoping with Java 9 this would finalyl be solved :) >> >> Test: >> import javax.crypto.Cipher; >> class Test { >> public static void main(String[] args) { >> try { >> System.out.println("Hello World!"); >> int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES"); >> System.out.println(maxKeyLen); >> } catch (Exception e){ >> System.out.println("Sad world :("); >> } >> } >> } > From anthony.scarpino at oracle.com Wed Oct 5 20:20:49 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 5 Oct 2016 13:20:49 -0700 Subject: RFR: 8165101 AnchorCertificates throws NPE when cacerts file not found Message-ID: <57F560A1.2060507@oracle.com> Hi, I'd like a review of this simple fix. There's no test as the fix is trivial and it's not practical to test a non-existent cacerts file in a concurrent testing environment http://cr.openjdk.java.net/~ascarpino/8165101/webrev/ Tony From anthony.scarpino at oracle.com Wed Oct 5 20:20:56 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 5 Oct 2016 13:20:56 -0700 Subject: 8165103: Update to "denyAfter constraint check" exception message Message-ID: <57F560A8.6050005@oracle.com> Hi, I'd like a review of this change away from a generic error messages in the denyAfter constraint. The message better specify which date was checked against the constraint now. Testing is handled elsewhere. http://cr.openjdk.java.net/~ascarpino/8165103/webrev/ Tony From valerie.peng at oracle.com Wed Oct 5 23:58:36 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 5 Oct 2016 16:58:36 -0700 Subject: 8165103: Update to "denyAfter constraint check" exception message In-Reply-To: <57F560A8.6050005@oracle.com> References: <57F560A8.6050005@oracle.com> Message-ID: <5aa481b0-89b6-4c85-a3b2-a7bdfd504f1a@oracle.com> Instead of duplicating the if-check block, how about just add another String variable "dateType" and assign value to it in the first if-check block? Rest looks fine. Valerie On 10/5/2016 1:20 PM, Anthony Scarpino wrote: > Hi, > > I'd like a review of this change away from a generic error messages in > the denyAfter constraint. The message better specify which date was > checked against the constraint now. Testing is handled elsewhere. > > http://cr.openjdk.java.net/~ascarpino/8165103/webrev/ > > Tony > From anthony.scarpino at oracle.com Thu Oct 6 03:29:59 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 5 Oct 2016 20:29:59 -0700 Subject: 8165103: Update to "denyAfter constraint check" exception message In-Reply-To: <5aa481b0-89b6-4c85-a3b2-a7bdfd504f1a@oracle.com> References: <57F560A8.6050005@oracle.com> <5aa481b0-89b6-4c85-a3b2-a7bdfd504f1a@oracle.com> Message-ID: <57F5C537.7020600@oracle.com> This is intentional as an optimization. Setting the String is only needed in the failure case, so I separated them to optimize the success case. That's why I have the comment there. Tony On 10/05/2016 04:58 PM, Valerie Peng wrote: > > Instead of duplicating the if-check block, how about just add another > String variable "dateType" and assign value to it in the first if-check > block? > Rest looks fine. > Valerie > > On 10/5/2016 1:20 PM, Anthony Scarpino wrote: >> Hi, >> >> I'd like a review of this change away from a generic error messages in >> the denyAfter constraint. The message better specify which date was >> checked against the constraint now. Testing is handled elsewhere. >> >> http://cr.openjdk.java.net/~ascarpino/8165103/webrev/ >> >> Tony >> > From weijun.wang at oracle.com Thu Oct 6 16:55:58 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 7 Oct 2016 00:55:58 +0800 Subject: RFR 8167181: Exported elements referring to inaccessible types in jdk.security.jgss Message-ID: <7db6e5fd-3d7e-be81-63fa-c5c62bd02d0d@oracle.com> Please review the code change for jdk9/dev/jdk repo at http://cr.openjdk.java.net/~weijun/8167181/webrev.00 and for jdk9/dev which is simply diff --git a/make/CompileJavaModules.gmk b/make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk +++ b/make/CompileJavaModules.gmk @@ -452,10 +452,6 @@ ################################################################################ -jdk.security.jgss_ADD_JAVAC_FLAGS := -Xlint:-exports - -################################################################################ - jdk.vm.ci_ADD_JAVAC_FLAGS := -Xlint:-exports ################################################################################ After the change the *Impl classes disappeared from javadoc [1]. I wish I had noticed them before. Thanks Max [1] http://download.java.net/java/jdk9/docs/jre/api/security/jgss/spec/com/sun/security/jgss/package-summary.html From mandy.chung at oracle.com Thu Oct 6 17:02:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 6 Oct 2016 10:02:29 -0700 Subject: RFR 8167181: Exported elements referring to inaccessible types in jdk.security.jgss In-Reply-To: <7db6e5fd-3d7e-be81-63fa-c5c62bd02d0d@oracle.com> References: <7db6e5fd-3d7e-be81-63fa-c5c62bd02d0d@oracle.com> Message-ID: <9482B27C-D237-4E5F-86DB-8ADDF855B1FC@oracle.com> > On Oct 6, 2016, at 9:55 AM, Wang Weijun wrote: > > Please review the code change for jdk9/dev/jdk repo at > > http://cr.openjdk.java.net/~weijun/8167181/webrev.00 This looks good to me. Thanks Mandy From valerie.peng at oracle.com Fri Oct 7 00:06:09 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 6 Oct 2016 17:06:09 -0700 Subject: 8165103: Update to "denyAfter constraint check" exception message In-Reply-To: <57F5C537.7020600@oracle.com> References: <57F560A8.6050005@oracle.com> <5aa481b0-89b6-4c85-a3b2-a7bdfd504f1a@oracle.com> <57F5C537.7020600@oracle.com> Message-ID: <2935ac16-3314-1901-e051-081751c33d0d@oracle.com> I know it's intentional, however I doubt how much difference this makes. Code duplication is kind of error prone. Just my preference, Valerie On 10/5/2016 8:29 PM, Anthony Scarpino wrote: > This is intentional as an optimization. Setting the String is only > needed in the failure case, so I separated them to optimize the > success case. That's why I have the comment there. > > Tony > > On 10/05/2016 04:58 PM, Valerie Peng wrote: >> >> Instead of duplicating the if-check block, how about just add another >> String variable "dateType" and assign value to it in the first if-check >> block? >> Rest looks fine. >> Valerie >> >> On 10/5/2016 1:20 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I'd like a review of this change away from a generic error messages in >>> the denyAfter constraint. The message better specify which date was >>> checked against the constraint now. Testing is handled elsewhere. >>> >>> http://cr.openjdk.java.net/~ascarpino/8165103/webrev/ >>> >>> Tony >>> >> > From sean.mullan at oracle.com Fri Oct 7 13:06:20 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Oct 2016 09:06:20 -0400 Subject: RFR: 8165101 AnchorCertificates throws NPE when cacerts file not found In-Reply-To: <57F560A1.2060507@oracle.com> References: <57F560A1.2060507@oracle.com> Message-ID: <4fadae03-76b7-8e00-3e3b-99ee80499e49@oracle.com> Looks good to me. --Sean On 10/05/2016 04:20 PM, Anthony Scarpino wrote: > Hi, > > I'd like a review of this simple fix. There's no test as the fix is > trivial and it's not practical to test a non-existent cacerts file in a > concurrent testing environment > > http://cr.openjdk.java.net/~ascarpino/8165101/webrev/ > > Tony From artem.smotrakov at oracle.com Fri Oct 7 20:33:58 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 7 Oct 2016 13:33:58 -0700 Subject: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently Message-ID: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> Hello, Please review the patch below for sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. The test has been observed to fail intermittently, but the failure is not reproducible standalone. The patch updates the test to follow the approach from SSLSocketSample.java http://hg.openjdk.java.net/jdk9/dev/jdk/file/1f044f413e6c/test/javax/net/ssl/templates/SSLSocketSample.java I merged OriginServer.java to ProxyAuthTest.java since only this test uses that file. I also added a couple of new common methods to SSLTest.java. They are not used by ProxyAuthTest.java, but can be useful in other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166530 Webrev: http://cr.openjdk.java.net/~asmotrak/8166530/webrev.00/ Artem From xuelei.fan at oracle.com Mon Oct 10 10:15:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Oct 2016 18:15:37 +0800 Subject: [9] RFR 8165275: Replace the reflective call to the implUpdate method in HandshakeMessage::digestKey In-Reply-To: References: Message-ID: <27da5d37-f9df-12e6-d1a5-8874b3008693@oracle.com> As this API is only used for legacy SSL 3.0, alternatively we may deprecate and remove the support of MessageDigestSpi2 in the future. I may add a note to MessageDigestSpi2, like: This is for SSL 3.0 implementation only, please don't use it for other purpose. Otherwise, looks fine to me. Thanks, Xuelei On 10/5/2016 6:07 AM, Valerie Peng wrote: > Hi Xuelei, > > Could you please help reviewing this JSSE-related code refactoring? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165275 > Webrev: http://cr.openjdk.java.net/~valeriep/8165275/webrev.00/ > > Thanks, > Valerie From anthony.scarpino at oracle.com Mon Oct 10 18:33:30 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 10 Oct 2016 11:33:30 -0700 Subject: 8165103: Update to "denyAfter constraint check" exception message In-Reply-To: <2935ac16-3314-1901-e051-081751c33d0d@oracle.com> References: <57F560A8.6050005@oracle.com> <5aa481b0-89b6-4c85-a3b2-a7bdfd504f1a@oracle.com> <57F5C537.7020600@oracle.com> <2935ac16-3314-1901-e051-081751c33d0d@oracle.com> Message-ID: <57FBDEFA.9070201@oracle.com> Ok.. I have included it into the first if statement.. http://cr.openjdk.java.net/~ascarpino/8165103/webrev.01/ Tony On 10/06/2016 05:06 PM, Valerie Peng wrote: > > I know it's intentional, however I doubt how much difference this makes. > Code duplication is kind of error prone. > Just my preference, > Valerie > > On 10/5/2016 8:29 PM, Anthony Scarpino wrote: >> This is intentional as an optimization. Setting the String is only >> needed in the failure case, so I separated them to optimize the >> success case. That's why I have the comment there. >> >> Tony >> >> On 10/05/2016 04:58 PM, Valerie Peng wrote: >>> >>> Instead of duplicating the if-check block, how about just add another >>> String variable "dateType" and assign value to it in the first if-check >>> block? >>> Rest looks fine. >>> Valerie >>> >>> On 10/5/2016 1:20 PM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I'd like a review of this change away from a generic error messages in >>>> the denyAfter constraint. The message better specify which date was >>>> checked against the constraint now. Testing is handled elsewhere. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8165103/webrev/ >>>> >>>> Tony >>>> >>> >> > From anthony.scarpino at oracle.com Mon Oct 10 18:53:13 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 10 Oct 2016 11:53:13 -0700 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate Message-ID: <57FBE399.6020308@oracle.com> Hi, I need a review of a fix to JEP 288 were certpath algorithm checking wasn't checking OCSP certs against the jdkCA keyword. http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ thanks Tony From sean.mullan at oracle.com Mon Oct 10 19:29:50 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Oct 2016 15:29:50 -0400 Subject: RFR: JDK-8162723 : Array index overflow in Base64 utility class Message-ID: <6cdc863b-6580-2899-b9f0-4dad4171610f@oracle.com> Please review this change to fix a potential array index overflow in the XML security Base64 encoding class. This is a direct import of the corresponding patch that has already been made to the Apache code. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8162723/webrev.00/ Thanks, Sean From anthony.scarpino at oracle.com Mon Oct 10 19:40:44 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 10 Oct 2016 12:40:44 -0700 Subject: RFR: JDK-8162723 : Array index overflow in Base64 utility class In-Reply-To: <6cdc863b-6580-2899-b9f0-4dad4171610f@oracle.com> References: <6cdc863b-6580-2899-b9f0-4dad4171610f@oracle.com> Message-ID: <57FBEEBC.6050503@oracle.com> On 10/10/2016 12:29 PM, Sean Mullan wrote: > Please review this change to fix a potential array index overflow in the > XML security Base64 encoding class. This is a direct import of the > corresponding patch that has already been made to the Apache code. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8162723/webrev.00/ > > Thanks, > Sean Some of the typecasting seems excessive, but it's better to keep the code-bases synchronized than worry about harmless nits. Looks good to me.. Tony From valerie.peng at oracle.com Mon Oct 10 19:49:46 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 10 Oct 2016 12:49:46 -0700 Subject: [9] RFR 8165275: Replace the reflective call to the implUpdate method in HandshakeMessage::digestKey In-Reply-To: <27da5d37-f9df-12e6-d1a5-8874b3008693@oracle.com> References: <27da5d37-f9df-12e6-d1a5-8874b3008693@oracle.com> Message-ID: <8bda9ee9-6d79-450d-3d46-402521802350@oracle.com> Thanks for the review. I have updated the MessageDigestSpi2 class accordingly: http://cr.openjdk.java.net/~valeriep/8165275/webrev.01/src/java.base/share/classes/sun/security/util/MessageDigestSpi2.java.html Valerie On 10/10/2016 3:15 AM, Xuelei Fan wrote: > As this API is only used for legacy SSL 3.0, alternatively we may > deprecate and remove the support of MessageDigestSpi2 in the future. > I may add a note to MessageDigestSpi2, like: > > This is for SSL 3.0 implementation only, please don't > use it for other purpose. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 10/5/2016 6:07 AM, Valerie Peng wrote: >> Hi Xuelei, >> >> Could you please help reviewing this JSSE-related code refactoring? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165275 >> Webrev: http://cr.openjdk.java.net/~valeriep/8165275/webrev.00/ >> >> Thanks, >> Valerie From mandy.chung at oracle.com Mon Oct 10 21:24:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Oct 2016 14:24:02 -0700 Subject: [9] RFR 8165275: Replace the reflective call to the implUpdate method in HandshakeMessage::digestKey In-Reply-To: References: Message-ID: On Oct 4, 2016, at 3:07 PM, Valerie Peng wrote: > > Hi Xuelei, > > Could you please help reviewing this JSSE-related code refactoring? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165275 > Webrev: http://cr.openjdk.java.net/~valeriep/8165275/webrev.00/ > Looks okay to me. Mandy From bradford.wetmore at oracle.com Mon Oct 10 22:57:42 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 10 Oct 2016 15:57:42 -0700 Subject: RFR 8167459: Add debug output for indicating if a chosen ciphersuite was legacy. Message-ID: Hi Xuelei, We should provide more information about which ciphersuites were actually considered for a handshake and why they were ultimately chosen/not chosen, but for now we have been requested to add a debug message to indicate whether or not the selected ciphersuite was legacy. Examples: % java -Djavax.net.debug=all MyClass // or % java -Djavax.net.debug=ssl MyClass ...deleted... Standard ciphersuite chosen: TLS_RSA_WITH_AES_128_CBC_SHA ...deleted... or ...deleted... Legacy ciphersuite chosen: SSL_RSA_WITH_RC4_128_SHA ...deleted... The proposed simple change is: https://bugs.openjdk.java.net/browse/JDK-8167459 http://cr.openjdk.java.net/~wetmore/8167459/webrev.00/ Thanks, Brad From xuelei.fan at oracle.com Tue Oct 11 01:30:56 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Oct 2016 09:30:56 +0800 Subject: [9] RFR 8165275: Replace the reflective call to the implUpdate method in HandshakeMessage::digestKey In-Reply-To: <8bda9ee9-6d79-450d-3d46-402521802350@oracle.com> References: <27da5d37-f9df-12e6-d1a5-8874b3008693@oracle.com> <8bda9ee9-6d79-450d-3d46-402521802350@oracle.com> Message-ID: Thanks for the update. Looks fine to me. Xuelei On 10/11/2016 3:49 AM, Valerie Peng wrote: > > Thanks for the review. I have updated the MessageDigestSpi2 class > accordingly: > http://cr.openjdk.java.net/~valeriep/8165275/webrev.01/src/java.base/share/classes/sun/security/util/MessageDigestSpi2.java.html > > > Valerie > > On 10/10/2016 3:15 AM, Xuelei Fan wrote: >> As this API is only used for legacy SSL 3.0, alternatively we may >> deprecate and remove the support of MessageDigestSpi2 in the future. >> I may add a note to MessageDigestSpi2, like: >> >> This is for SSL 3.0 implementation only, please don't >> use it for other purpose. >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> On 10/5/2016 6:07 AM, Valerie Peng wrote: >>> Hi Xuelei, >>> >>> Could you please help reviewing this JSSE-related code refactoring? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165275 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8165275/webrev.00/ >>> >>> Thanks, >>> Valerie > From xuelei.fan at oracle.com Tue Oct 11 01:32:43 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Oct 2016 09:32:43 +0800 Subject: RFR 8167459: Add debug output for indicating if a chosen ciphersuite was legacy. In-Reply-To: References: Message-ID: <32c808ce-425e-a9de-8430-6611fb21ccdb@oracle.com> Nice update, and thanks! Xuelei On 10/11/2016 6:57 AM, Bradford Wetmore wrote: > > Hi Xuelei, > > We should provide more information about which ciphersuites were > actually considered for a handshake and why they were ultimately > chosen/not chosen, but for now we have been requested to add a debug > message to indicate whether or not the selected ciphersuite was legacy. > > Examples: > > % java -Djavax.net.debug=all MyClass // or % java -Djavax.net.debug=ssl > MyClass > ...deleted... > Standard ciphersuite chosen: TLS_RSA_WITH_AES_128_CBC_SHA > ...deleted... > > or > > ...deleted... > Legacy ciphersuite chosen: SSL_RSA_WITH_RC4_128_SHA > ...deleted... > > The proposed simple change is: > > https://bugs.openjdk.java.net/browse/JDK-8167459 > http://cr.openjdk.java.net/~wetmore/8167459/webrev.00/ > > Thanks, > > Brad From weijun.wang at oracle.com Tue Oct 11 02:40:45 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2016 10:40:45 +0800 Subject: RFR: Release note for 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: <402a1cac-6fbc-3152-66ef-c4ec42971012@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8165836 I added more words, please take another look. Thanks Max On 9/13/2016 2:13, Brian Burkhalter wrote: > Only picky comments: not sure but maybe change: > > 1) vice versa -> and vice versa > 2) When it?s set to true -> When true > 3) just like before -> as before > > Brian > > On Sep 12, 2016, at 12:23 AM, Weijun Wang > wrote: > >> BTW, please also review the release note at >> >> https://bugs.openjdk.java.net/browse/JDK-8165836 >> >> Thanks >> Max > From xuelei.fan at oracle.com Tue Oct 11 05:06:14 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Oct 2016 13:06:14 +0800 Subject: Code Review Request, JDK-8167472, Chrome interop regression with JDK-8148516 Message-ID: Hi, Please review this update: http://cr.openjdk.java.net/~xuelei/8167472/webrev.00/ The root cause is that in the update of JDK-8148516, we removed some EC curves from the default supported EC curves list. However, while select the preferable curves requested by the client side, the server does not check whether the curves are supported or not. Actually, only supported EC curves should be selected. I tested the patch with Chrome, and no new test is added. Thanks, Xuelei From weijun.wang at oracle.com Tue Oct 11 05:44:08 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2016 13:44:08 +0800 Subject: Code Review Request, JDK-8167472, Chrome interop regression with JDK-8148516 In-Reply-To: References: Message-ID: <1f88f8d9-fd30-681b-fd37-c8cddb8a0318@oracle.com> Code change looks fine. Or you can write if (isSupported && permits).... Thanks Max On 10/11/2016 13:06, Xuelei Fan wrote: > Hi, > > Please review this update: > > http://cr.openjdk.java.net/~xuelei/8167472/webrev.00/ > > The root cause is that in the update of JDK-8148516, we removed some EC > curves from the default supported EC curves list. However, while select > the preferable curves requested by the client side, the server does not > check whether the curves are supported or not. Actually, only supported > EC curves should be selected. > > I tested the patch with Chrome, and no new test is added. > > Thanks, > Xuelei From xuelei.fan at oracle.com Tue Oct 11 06:07:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Oct 2016 14:07:16 +0800 Subject: Code Review Request, JDK-8167472, Chrome interop regression with JDK-8148516 In-Reply-To: <1f88f8d9-fd30-681b-fd37-c8cddb8a0318@oracle.com> References: <1f88f8d9-fd30-681b-fd37-c8cddb8a0318@oracle.com> Message-ID: On 10/11/2016 1:44 PM, Weijun Wang wrote: > Code change looks fine. > > Or you can write if (isSupported && permits).... > Nice coding. Thanks! Xuelei > Thanks > Max > > On 10/11/2016 13:06, Xuelei Fan wrote: >> Hi, >> >> Please review this update: >> >> http://cr.openjdk.java.net/~xuelei/8167472/webrev.00/ >> >> The root cause is that in the update of JDK-8148516, we removed some EC >> curves from the default supported EC curves list. However, while select >> the preferable curves requested by the client side, the server does not >> check whether the curves are supported or not. Actually, only supported >> EC curves should be selected. >> >> I tested the patch with Chrome, and no new test is added. >> >> Thanks, >> Xuelei From sean.mullan at oracle.com Wed Oct 12 14:55:33 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Oct 2016 10:55:33 -0400 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <57FBE399.6020308@oracle.com> References: <57FBE399.6020308@oracle.com> Message-ID: <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> * AlgorithmChecker Not sure why these changes are necessary or why the check method has been made non-static. Isn't the previous code sufficient? * OCSP 129 responderURI, new OCSPResponse.IssuerInfo(null, issuerCert), null, Passing null to OCSPResponse.IssuerInfo will throw an NPE. (but see comment below) * OCSPResponse For IssuerInfo, you don't always have/know the TrustAnchor, so shouldn't it be optional? 1061 return anchor; should be indented 4 spaces --Sean On 10/10/2016 02:53 PM, Anthony Scarpino wrote: > Hi, > > I need a review of a fix to JEP 288 were certpath algorithm checking > wasn't checking OCSP certs against the jdkCA keyword. > > http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ > > thanks > > Tony From anthony.scarpino at oracle.com Wed Oct 12 17:47:04 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 12 Oct 2016 10:47:04 -0700 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> References: <57FBE399.6020308@oracle.com> <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> Message-ID: <57FE7718.7020204@oracle.com> New webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.02/ On 10/12/2016 07:55 AM, Sean Mullan wrote: > * AlgorithmChecker > > Not sure why these changes are necessary or why the check method has > been made non-static. Isn't the previous code sufficient? > Yeah, that change doesn't appear to be necessary anymore.. > * OCSP > > 129 responderURI, new OCSPResponse.IssuerInfo(null, > issuerCert), null, > > Passing null to OCSPResponse.IssuerInfo will throw an NPE. (but see > comment below) > You must have loaded the page just before I refreshed the webrev. I fixed. I also added some changes in the exception messages to DisabledAlgorithmConstraints to give the cert subject, algorithm and/or keysize if used.. > * OCSPResponse > > For IssuerInfo, you don't always have/know the TrustAnchor, so shouldn't > it be optional? RevocationChecker always has a TrustAnchor as PKIXCertPathValidator passes it. AlgorithmChecker always needs a TrustAnchor, which PKIXCertPathValidator call. So I don't see a situation where we don't always have an TrustAnchor. > > 1061 return anchor; > > should be indented 4 spaces > > --Sean > > On 10/10/2016 02:53 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of a fix to JEP 288 were certpath algorithm checking >> wasn't checking OCSP certs against the jdkCA keyword. >> >> http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ >> >> thanks >> >> Tony From sean.mullan at oracle.com Wed Oct 12 19:15:30 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Oct 2016 15:15:30 -0400 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <57FE7718.7020204@oracle.com> References: <57FBE399.6020308@oracle.com> <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> <57FE7718.7020204@oracle.com> Message-ID: <7fffa4e6-0c11-1846-2a78-22b4be962398@oracle.com> On 10/12/2016 01:47 PM, Anthony Scarpino wrote: > New webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.02/ * DisabledAlgorithmConstraints 700 "Algorithm constraints check failed on keysize limits." 701 + algorithm + " " + size + "bit used with " + Looks like you could insert a couple of spaces above, one after "limits." and one before "bit ...". Also do you want to say " bit key ...". * OCSP 129 responderURI, new OCSPResponse.IssuerInfo(null, issuerCert), null, This will still throw NPE. 169 new TrustAnchor(issuerCert.getSubjectX500Principal(), 170 issuerCert.getPublicKey(), null), Why are you using the issuerCert's key and dn as the trust anchor here? We don't actually know if that is the trust anchor, so I would just use null. --Sean > > On 10/12/2016 07:55 AM, Sean Mullan wrote: >> * AlgorithmChecker >> >> Not sure why these changes are necessary or why the check method has >> been made non-static. Isn't the previous code sufficient? >> > > Yeah, that change doesn't appear to be necessary anymore.. > >> * OCSP >> >> 129 responderURI, new OCSPResponse.IssuerInfo(null, >> issuerCert), null, >> >> Passing null to OCSPResponse.IssuerInfo will throw an NPE. (but see >> comment below) >> > > You must have loaded the page just before I refreshed the webrev. I fixed. > > I also added some changes in the exception messages to > DisabledAlgorithmConstraints to give the cert subject, algorithm and/or > keysize if used.. > > >> * OCSPResponse >> >> For IssuerInfo, you don't always have/know the TrustAnchor, so shouldn't >> it be optional? > > RevocationChecker always has a TrustAnchor as PKIXCertPathValidator > passes it. AlgorithmChecker always needs a TrustAnchor, which > PKIXCertPathValidator call. So I don't see a situation where we don't > always have an TrustAnchor. > >> >> 1061 return anchor; >> >> should be indented 4 spaces >> >> --Sean >> >> On 10/10/2016 02:53 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a review of a fix to JEP 288 were certpath algorithm checking >>> wasn't checking OCSP certs against the jdkCA keyword. >>> >>> http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ >>> >>> thanks >>> >>> Tony > From anthony.scarpino at oracle.com Wed Oct 12 20:06:18 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 12 Oct 2016 13:06:18 -0700 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <7fffa4e6-0c11-1846-2a78-22b4be962398@oracle.com> References: <57FBE399.6020308@oracle.com> <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> <57FE7718.7020204@oracle.com> <7fffa4e6-0c11-1846-2a78-22b4be962398@oracle.com> Message-ID: <57FE97BA.60408@oracle.com> On 10/12/2016 12:15 PM, Sean Mullan wrote: > On 10/12/2016 01:47 PM, Anthony Scarpino wrote: >> New webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.02/ > > * DisabledAlgorithmConstraints > > 700 "Algorithm constraints check failed on > keysize limits." > 701 + algorithm + " " + size + "bit > used with " + > > Looks like you could insert a couple of spaces above, one after > "limits." and one before "bit ...". Also do you want to say " bit key ...". > > * OCSP > > 129 responderURI, new OCSPResponse.IssuerInfo(null, > issuerCert), null, Ack.. I thought I only had one of these so that's why I discounted it.. I need to add what I did below with a TrustAnchor object using issuerCert. > > This will still throw NPE. > > 169 new TrustAnchor(issuerCert.getSubjectX500Principal(), > 170 issuerCert.getPublicKey(), null), > > Why are you using the issuerCert's key and dn as the trust anchor here? > We don't actually know if that is the trust anchor, so I would just use > null. Later in the verify(), AlgorithmChecker needs a TrustAnchor object. In this case, because it's the old method that deploy is using, I have to manufacture a TrustAnchor until they can use the new method with the real TrustAnchor. Either way, if I pass null for the trust anchor, IssuerInfo will need to create a TrustAnchor from the same data. Do you want me to add a comment what the TrustAnchor object is? Unless there is further discussion about TrustAnchor part, I can easily fix the above two comments without a new webrev. Tony > --Sean > >> >> On 10/12/2016 07:55 AM, Sean Mullan wrote: >>> * AlgorithmChecker >>> >>> Not sure why these changes are necessary or why the check method has >>> been made non-static. Isn't the previous code sufficient? >>> >> >> Yeah, that change doesn't appear to be necessary anymore.. >> >>> * OCSP >>> >>> 129 responderURI, new OCSPResponse.IssuerInfo(null, >>> issuerCert), null, >>> >>> Passing null to OCSPResponse.IssuerInfo will throw an NPE. (but see >>> comment below) >>> >> >> You must have loaded the page just before I refreshed the webrev. I >> fixed. >> >> I also added some changes in the exception messages to >> DisabledAlgorithmConstraints to give the cert subject, algorithm and/or >> keysize if used.. >> >> >>> * OCSPResponse >>> >>> For IssuerInfo, you don't always have/know the TrustAnchor, so shouldn't >>> it be optional? >> >> RevocationChecker always has a TrustAnchor as PKIXCertPathValidator >> passes it. AlgorithmChecker always needs a TrustAnchor, which >> PKIXCertPathValidator call. So I don't see a situation where we don't >> always have an TrustAnchor. >> >>> >>> 1061 return anchor; >>> >>> should be indented 4 spaces >>> >>> --Sean >>> >>> On 10/10/2016 02:53 PM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I need a review of a fix to JEP 288 were certpath algorithm checking >>>> wasn't checking OCSP certs against the jdkCA keyword. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ >>>> >>>> thanks >>>> >>>> Tony >> From sean.mullan at oracle.com Wed Oct 12 20:41:11 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Oct 2016 16:41:11 -0400 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <57FE97BA.60408@oracle.com> References: <57FBE399.6020308@oracle.com> <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> <57FE7718.7020204@oracle.com> <7fffa4e6-0c11-1846-2a78-22b4be962398@oracle.com> <57FE97BA.60408@oracle.com> Message-ID: <15d5c0fe-8e7a-595a-a841-a13830876fa3@oracle.com> On 10/12/2016 04:06 PM, Anthony Scarpino wrote: > On 10/12/2016 12:15 PM, Sean Mullan wrote: >> On 10/12/2016 01:47 PM, Anthony Scarpino wrote: >>> New webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.02/ >> >> * DisabledAlgorithmConstraints >> >> 700 "Algorithm constraints check failed on >> keysize limits." >> 701 + algorithm + " " + size + "bit >> used with " + >> >> Looks like you could insert a couple of spaces above, one after >> "limits." and one before "bit ...". Also do you want to say " bit key >> ...". >> >> * OCSP >> >> 129 responderURI, new OCSPResponse.IssuerInfo(null, >> issuerCert), null, > > Ack.. I thought I only had one of these so that's why I discounted it.. > I need to add what I did below with a TrustAnchor object using issuerCert. > >> >> This will still throw NPE. >> >> 169 new >> TrustAnchor(issuerCert.getSubjectX500Principal(), >> 170 issuerCert.getPublicKey(), null), >> >> Why are you using the issuerCert's key and dn as the trust anchor here? >> We don't actually know if that is the trust anchor, so I would just use >> null. > > Later in the verify(), AlgorithmChecker needs a TrustAnchor object. In > this case, because it's the old method that deploy is using, I have to > manufacture a TrustAnchor until they can use the new method with the > real TrustAnchor. Either way, if I pass null for the trust anchor, > IssuerInfo will need to create a TrustAnchor from the same data. Do you > want me to add a comment what the TrustAnchor object is? So, I think what you should do is skip the constraints check if it contains the jdkCA constraint and the trust anchor is null, because you need the trust anchor in order to do the check. I would also log a warning with a debug message in this case. --Sean > > Unless there is further discussion about TrustAnchor part, I can easily > fix the above two comments without a new webrev. > > Tony > > > >> --Sean >> >>> >>> On 10/12/2016 07:55 AM, Sean Mullan wrote: >>>> * AlgorithmChecker >>>> >>>> Not sure why these changes are necessary or why the check method has >>>> been made non-static. Isn't the previous code sufficient? >>>> >>> >>> Yeah, that change doesn't appear to be necessary anymore.. >>> >>>> * OCSP >>>> >>>> 129 responderURI, new OCSPResponse.IssuerInfo(null, >>>> issuerCert), null, >>>> >>>> Passing null to OCSPResponse.IssuerInfo will throw an NPE. (but see >>>> comment below) >>>> >>> >>> You must have loaded the page just before I refreshed the webrev. I >>> fixed. >>> >>> I also added some changes in the exception messages to >>> DisabledAlgorithmConstraints to give the cert subject, algorithm and/or >>> keysize if used.. >>> >>> >>>> * OCSPResponse >>>> >>>> For IssuerInfo, you don't always have/know the TrustAnchor, so >>>> shouldn't >>>> it be optional? >>> >>> RevocationChecker always has a TrustAnchor as PKIXCertPathValidator >>> passes it. AlgorithmChecker always needs a TrustAnchor, which >>> PKIXCertPathValidator call. So I don't see a situation where we don't >>> always have an TrustAnchor. >>> >>>> >>>> 1061 return anchor; >>>> >>>> should be indented 4 spaces >>>> >>>> --Sean >>>> >>>> On 10/10/2016 02:53 PM, Anthony Scarpino wrote: >>>>> Hi, >>>>> >>>>> I need a review of a fix to JEP 288 were certpath algorithm checking >>>>> wasn't checking OCSP certs against the jdkCA keyword. >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8165274/webrev/ >>>>> >>>>> thanks >>>>> >>>>> Tony >>> > From anthony.scarpino at oracle.com Thu Oct 13 05:29:21 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 12 Oct 2016 22:29:21 -0700 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <15d5c0fe-8e7a-595a-a841-a13830876fa3@oracle.com> References: <57FBE399.6020308@oracle.com> <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> <57FE7718.7020204@oracle.com> <7fffa4e6-0c11-1846-2a78-22b4be962398@oracle.com> <57FE97BA.60408@oracle.com> <15d5c0fe-8e7a-595a-a841-a13830876fa3@oracle.com> Message-ID: <57FF1BB1.8020506@oracle.com> On 10/12/2016 01:41 PM, Sean Mullan wrote: > On 10/12/2016 04:06 PM, Anthony Scarpino wrote: >> Later in the verify(), AlgorithmChecker needs a TrustAnchor object. In >> this case, because it's the old method that deploy is using, I have to >> manufacture a TrustAnchor until they can use the new method with the >> real TrustAnchor. Either way, if I pass null for the trust anchor, >> IssuerInfo will need to create a TrustAnchor from the same data. Do you >> want me to add a comment what the TrustAnchor object is? > > So, I think what you should do is skip the constraints check if it > contains the jdkCA constraint and the trust anchor is null, because you > need the trust anchor in order to do the check. I would also log a > warning with a debug message in this case. > > --Sean > I believe this is what you're looking for. I changed AlgorithmChecker to allow a null TrustAnchor and undid much of the other code to protect against nulls. webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.03/ Tony From vincent.x.ryan at oracle.com Thu Oct 13 10:33:31 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 13 Oct 2016 11:33:31 +0100 Subject: [9] RFR 8167371: KeyStoreSpi.engineSetEntry should throw an Exception if password protection alg is specified Message-ID: <3E47F9EC-B964-44A6-ABBD-4F62E4C7D54B@oracle.com> Please review this fix to add a check to the default implementation of KeyStore setEntry and getEntry (in KeyStoreSpi). An exception is thrown if a password protection algorithm is specified. An existing test has been updated to validate the fix. Keystore implementations that support a user-supplied password protection algorithm override the default implementation of these setEntry/getEntry methods and are unaffected by this fix. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8167371 Webrev: http://cr.openjdk.java.net/~vinnie/8167371/webrev.00/ From xuelei.fan at oracle.com Thu Oct 13 10:52:24 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Oct 2016 18:52:24 +0800 Subject: [9] RFR 8167371: KeyStoreSpi.engineSetEntry should throw an Exception if password protection alg is specified In-Reply-To: <3E47F9EC-B964-44A6-ABBD-4F62E4C7D54B@oracle.com> References: <3E47F9EC-B964-44A6-ABBD-4F62E4C7D54B@oracle.com> Message-ID: <458828de-2f00-8ca1-f317-70cd2f5cf70f@oracle.com> Nice catch! Looks fine to me. Xuelei On 10/13/2016 6:33 PM, Vincent Ryan wrote: > Please review this fix to add a check to the default implementation of KeyStore setEntry and getEntry (in KeyStoreSpi). > An exception is thrown if a password protection algorithm is specified. An existing test has been updated to validate the fix. > > Keystore implementations that support a user-supplied password protection algorithm override the default implementation > of these setEntry/getEntry methods and are unaffected by this fix. > > Thanks. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167371 > Webrev: http://cr.openjdk.java.net/~vinnie/8167371/webrev.00/ > From xuelei.fan at oracle.com Thu Oct 13 14:36:58 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Oct 2016 22:36:58 +0800 Subject: Code Review Request, JDK-8167680, DTLS implementation bugs Message-ID: Hi, Please review the fix for JDK-8167680: http://cr.openjdk.java.net/~xuelei/8167680/webrev.00/ There are a few implementation bugs in JDK. 1. The sequence number is increased by 2 for GCM cipher suites. Both GCM crypto operation and DTLS record use the sequence number. The current implementation may increase the sequence number for each of the two operations. It is not the expected behavior. 2. The implementation does not response to handshake retransmissions. In the current implementation, receiving of retransmitted handshake messages does not kick off a retransmission of the previous delivered flight. Retransmission happens on timeout. Timeout is expensive. Supporting response to peer retransmitted handshake messages would speed up the handshaking. 3. the final CCC and finished message cannot be retransmitted. It is an implementation bug. Every handshake message should be able to get retransmitted. 4. the first application data may be discarded if the last flight get lost. Applications may send application data immediately after the handshake completed. However, the peer may have not receive the handshake complete message, and therefor discard the application data. As may impact application logic. For example Client Server .... -- ClientKeyExchange --> -- ChangeCipherSpec --> -- Finished --> X <-- ChangeCipherSpec -- X <-- Finished -- <-- Application Data -- ----- ... ---> -- ClientKeyExchange --> -- ChangeCipherSpec --> -- Finished --> <-- ChangeCipherSpec -- <-- Finished -- 1. (omit the previous handshake messages) server sends ChangeCipherSpec and Finished messages. 2. server handshake complete 3. server send application 4. client does not receive the ChangeCipherSpec or Finished messages. 5. client receives the application data. Client cannot handle the encrypted message, and may discard it. Client re-transmit the previous flight. 6. server retransmit the last flight. 7. client receives the last flight. In this update, the last flight will be transmit twice. As may mitigate the impact of the issue. 5. resuming handshaking need no cookie exchange. It is an implementation bug. Cookie exchange is performed for handshaking resuming now. It is not the expected behavior. 6. need more debug log for DTLS handshake message fragmentation and reassembly. Thanks, Xuelei From sean.mullan at oracle.com Thu Oct 13 15:27:39 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Oct 2016 11:27:39 -0400 Subject: RFR 8165274: SHA1 certpath constraint check fails with OCSP certificate In-Reply-To: <57FF1BB1.8020506@oracle.com> References: <57FBE399.6020308@oracle.com> <813336bb-cc60-91c7-43cd-d5b982a3939b@oracle.com> <57FE7718.7020204@oracle.com> <7fffa4e6-0c11-1846-2a78-22b4be962398@oracle.com> <57FE97BA.60408@oracle.com> <15d5c0fe-8e7a-595a-a841-a13830876fa3@oracle.com> <57FF1BB1.8020506@oracle.com> Message-ID: <1a61ae40-02dc-dcdd-2b6b-b1f17fc64564@oracle.com> On 10/13/2016 01:29 AM, Anthony Scarpino wrote: > On 10/12/2016 01:41 PM, Sean Mullan wrote: >> On 10/12/2016 04:06 PM, Anthony Scarpino wrote: >>> Later in the verify(), AlgorithmChecker needs a TrustAnchor object. In >>> this case, because it's the old method that deploy is using, I have to >>> manufacture a TrustAnchor until they can use the new method with the >>> real TrustAnchor. Either way, if I pass null for the trust anchor, >>> IssuerInfo will need to create a TrustAnchor from the same data. Do you >>> want me to add a comment what the TrustAnchor object is? >> >> So, I think what you should do is skip the constraints check if it >> contains the jdkCA constraint and the trust anchor is null, because you >> need the trust anchor in order to do the check. I would also log a >> warning with a debug message in this case. >> >> --Sean >> > > I believe this is what you're looking for. I changed AlgorithmChecker > to allow a null TrustAnchor and undid much of the other code to protect > against nulls. > > webrev: http://cr.openjdk.java.net/~ascarpino/8165274/webrev.03/ Right, that's more along the lines I was thinking. Thanks, Sean From sean.mullan at oracle.com Thu Oct 13 19:44:18 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Oct 2016 15:44:18 -0400 Subject: RFR: 8165712: Grant permission to read specific properties instead of all to the jdk.crypto.ucrypto module Message-ID: Please review this fix to only grant the necessary PropertyPermissions to the jdk.crypto.ucrypto module. In UcryptoProvider I also moved the System.getProperty("os.name") inside doPrivileged (just in case permission to read this property has not been granted to the caller) and did some minor refactoring. http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/ --Sean From sean.mullan at oracle.com Mon Oct 17 14:51:24 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Oct 2016 10:51:24 -0400 Subject: RFR: 8168078: Remove permission to read all system properties granted to the jdk.crypto.ec module Message-ID: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> Please review this fix to remove granting the unnecessary PropertyPermission to the jdk.crypto.ec module: http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/ The existing TestEC test has been modified to also run under a SecurityManager to verify that removing the permission does not break anything. --Sean From vincent.x.ryan at oracle.com Mon Oct 17 15:02:12 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 17 Oct 2016 16:02:12 +0100 Subject: RFR: 8168078: Remove permission to read all system properties granted to the jdk.crypto.ec module In-Reply-To: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> References: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> Message-ID: <274F7ED4-4E54-460A-BF89-88FA3D3FC6B2@oracle.com> Your fix looks fine to me Sean. Thanks. > On 17 Oct 2016, at 15:51, Sean Mullan wrote: > > Please review this fix to remove granting the unnecessary PropertyPermission to the jdk.crypto.ec module: > > http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/ > > The existing TestEC test has been modified to also run under a SecurityManager to verify that removing the permission does not break anything. > > --Sean From xuelei.fan at oracle.com Mon Oct 17 15:09:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Oct 2016 23:09:18 +0800 Subject: RFR: 8165712: Grant permission to read specific properties instead of all to the jdk.crypto.ucrypto module In-Reply-To: References: Message-ID: <5c8cccb6-6469-6224-aac8-7e86d788a0f8@oracle.com> Looks fine to me. Xuelei On 10/14/2016 3:44 AM, Sean Mullan wrote: > Please review this fix to only grant the necessary PropertyPermissions > to the jdk.crypto.ucrypto module. > > In UcryptoProvider I also moved the System.getProperty("os.name") inside > doPrivileged (just in case permission to read this property has not been > granted to the caller) and did some minor refactoring. > > http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/ > > --Sean From xuelei.fan at oracle.com Mon Oct 17 15:10:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Oct 2016 23:10:28 +0800 Subject: RFR: 8168078: Remove permission to read all system properties granted to the jdk.crypto.ec module In-Reply-To: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> References: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> Message-ID: Looks fine to me. Xuelei On 10/17/2016 10:51 PM, Sean Mullan wrote: > Please review this fix to remove granting the unnecessary > PropertyPermission to the jdk.crypto.ec module: > > http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/ > > The existing TestEC test has been modified to also run under a > SecurityManager to verify that removing the permission does not break > anything. > > --Sean From sean.mullan at oracle.com Mon Oct 17 21:18:36 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Oct 2016 17:18:36 -0400 Subject: RFR: 8168078: Remove permission to read all system properties granted to the jdk.crypto.ec module In-Reply-To: References: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> Message-ID: I had to make a small update to the webrev to PKCS11Test.java because the TestEC test failed on Windows. Some deployment-specific security providers will throw a ServiceConfigurationError if not granted the right permissions. These permissions may not be configured correctly and are outside the scope of the jdk.crypto.ec module, so the exception is ignored. (This is the same way we load providers in sun.security.jca.ProviderConfig) new webrev: http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.01/ Thanks, Sean On 10/17/2016 11:10 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 10/17/2016 10:51 PM, Sean Mullan wrote: >> Please review this fix to remove granting the unnecessary >> PropertyPermission to the jdk.crypto.ec module: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/ >> >> The existing TestEC test has been modified to also run under a >> SecurityManager to verify that removing the permission does not break >> anything. >> >> --Sean From artem.smotrakov at oracle.com Tue Oct 18 00:02:58 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 17 Oct 2016 17:02:58 -0700 Subject: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently In-Reply-To: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> References: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> Message-ID: Hello, Please take a look. Artem On 10/07/2016 01:33 PM, Artem Smotrakov wrote: > Hello, > > Please review the patch below for > sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. > > The test has been observed to fail intermittently, but the failure is > not reproducible standalone. The patch updates the test to follow the > approach from SSLSocketSample.java > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/1f044f413e6c/test/javax/net/ssl/templates/SSLSocketSample.java > > > I merged OriginServer.java to ProxyAuthTest.java since only this test > uses that file. I also added a couple of new common methods to > SSLTest.java. They are not used by ProxyAuthTest.java, but can be > useful in other tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166530 > Webrev: http://cr.openjdk.java.net/~asmotrak/8166530/webrev.00/ > > Artem > From xuelei.fan at oracle.com Tue Oct 18 05:39:36 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 18 Oct 2016 13:39:36 +0800 Subject: RFR: 8168078: Remove permission to read all system properties granted to the jdk.crypto.ec module In-Reply-To: References: <1688dc22-478c-72fb-358f-dc67aafa2998@oracle.com> Message-ID: <9a3ada70-ec47-4bf1-ad26-9670df1f6a8c@oracle.com> OK. Xuelei On 10/18/2016 5:18 AM, Sean Mullan wrote: > I had to make a small update to the webrev to PKCS11Test.java because > the TestEC test failed on Windows. Some deployment-specific security > providers will throw a ServiceConfigurationError if not granted the > right permissions. These permissions may not be configured correctly and > are outside the scope of the jdk.crypto.ec module, so the exception is > ignored. (This is the same way we load providers in > sun.security.jca.ProviderConfig) > > new webrev: http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.01/ > > Thanks, > Sean > > On 10/17/2016 11:10 AM, Xuelei Fan wrote: >> Looks fine to me. >> >> Xuelei >> >> On 10/17/2016 10:51 PM, Sean Mullan wrote: >>> Please review this fix to remove granting the unnecessary >>> PropertyPermission to the jdk.crypto.ec module: >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/8168078/webrev.00/ >>> >>> The existing TestEC test has been modified to also run under a >>> SecurityManager to verify that removing the permission does not break >>> anything. >>> >>> --Sean From chris.hegarty at oracle.com Tue Oct 18 11:15:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Oct 2016 12:15:10 +0100 Subject: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently In-Reply-To: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> References: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> Message-ID: > On 7 Oct 2016, at 21:33, Artem Smotrakov wrote: > > Hello, > > Please review the patch below for sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. > > The test has been observed to fail intermittently, but the failure is not reproducible standalone. The patch updates the test to follow the approach from SSLSocketSample.java > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/1f044f413e6c/test/javax/net/ssl/templates/SSLSocketSample.java > > I merged OriginServer.java to ProxyAuthTest.java since only this test uses that file. I also added a couple of new common methods to SSLTest.java. They are not used by ProxyAuthTest.java, but can be useful in other tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166530 > Webrev: http://cr.openjdk.java.net/~asmotrak/8166530/webrev.00/ From my point of view, this looks ok. -Chris. From weijun.wang at oracle.com Wed Oct 19 01:26:45 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 19 Oct 2016 09:26:45 +0800 Subject: RFR 8167647: Copy-and-paste bug in javax.security.auth.kerberos.KerberosTicket.toString() Message-ID: <4bff958b-beb2-a554-6d10-8facee7060df@oracle.com> Please take a review on this change: diff --git a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java --- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java +++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java @@ -694,7 +694,7 @@ "Proxy Ticket " + flags[PROXY_TICKET_FLAG] + "\n" + "Postdated Ticket " + flags[POSTDATED_TICKET_FLAG] + "\n" + "Renewable Ticket " + flags[RENEWABLE_TICKET_FLAG] + "\n" + - "Initial Ticket " + flags[RENEWABLE_TICKET_FLAG] + "\n" + + "Initial Ticket " + flags[INITIAL_TICKET_FLAG] + "\n" + "Auth Time = " + String.valueOf(authTime) + "\n" + "Start Time = " + String.valueOf(startTime) + "\n" + "End Time = " + endTime.toString() + "\n" + Noreg-trivial. Thanks Max From Xuelei.Fan at Oracle.Com Wed Oct 19 03:37:40 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 19 Oct 2016 11:37:40 +0800 Subject: RFR 8167647: Copy-and-paste bug in javax.security.auth.kerberos.KerberosTicket.toString() In-Reply-To: <4bff958b-beb2-a554-6d10-8facee7060df@oracle.com> References: <4bff958b-beb2-a554-6d10-8facee7060df@oracle.com> Message-ID: <9541D145-D968-4A70-8185-6C87849E951F@Oracle.Com> Looks fine to me. Xuelei > On 19 Oct 2016, at 9:26 AM, Wang Weijun wrote: > > Please take a review on this change: > > diff --git a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java > --- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java > +++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java > @@ -694,7 +694,7 @@ > "Proxy Ticket " + flags[PROXY_TICKET_FLAG] + "\n" + > "Postdated Ticket " + flags[POSTDATED_TICKET_FLAG] + "\n" + > "Renewable Ticket " + flags[RENEWABLE_TICKET_FLAG] + "\n" + > - "Initial Ticket " + flags[RENEWABLE_TICKET_FLAG] + "\n" + > + "Initial Ticket " + flags[INITIAL_TICKET_FLAG] + "\n" + > "Auth Time = " + String.valueOf(authTime) + "\n" + > "Start Time = " + String.valueOf(startTime) + "\n" + > "End Time = " + endTime.toString() + "\n" + > > Noreg-trivial. > > Thanks > Max > From weijun.wang at oracle.com Wed Oct 19 07:36:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 19 Oct 2016 15:36:42 +0800 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar Message-ID: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8163304/webrev.01/ With this change, "jarsigner -verify -verbose" will print out how a jar was signed. For example, a jar which was signed and timestamped with many weak algorithms will show - Signed by "CN=old" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 2048-bit key Timestamped by "CN=tsbad1" on Wed Oct 19 07:32:22 UTC 2016 Timestamp digest algorithm: MD2 (weak) Timestamp signature algorithm: SHA1withRSA, 512-bit key (weak) WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property: jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024, DSA keySize < 1024 Thanks Max From anthony.scarpino at oracle.com Wed Oct 19 17:42:03 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 19 Oct 2016 10:42:03 -0700 Subject: RFR 8167591: Add MD5 to signed JAR restrictions Message-ID: <5807B06B.3040200@oracle.com> Hi, I need a simple review of adding MD5 to the jdk.jar.disabledAlgorithms security property. It's really a one line change, the comments got moved to a different location in the file which makes it look bigger. http://cr.openjdk.java.net/~ascarpino/8167591/webrev/ Tony From sean.mullan at oracle.com Wed Oct 19 17:48:52 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Oct 2016 13:48:52 -0400 Subject: RFR 8167591: Add MD5 to signed JAR restrictions In-Reply-To: <5807B06B.3040200@oracle.com> References: <5807B06B.3040200@oracle.com> Message-ID: <94da90bb-fc8d-acd0-b937-c46031aa5198@oracle.com> Looks good. --Sean On 10/19/2016 01:42 PM, Anthony Scarpino wrote: > Hi, > > I need a simple review of adding MD5 to the jdk.jar.disabledAlgorithms > security property. It's really a one line change, the comments got > moved to a different location in the file which makes it look bigger. > > http://cr.openjdk.java.net/~ascarpino/8167591/webrev/ > > Tony From sean.mullan at oracle.com Wed Oct 19 20:13:24 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Oct 2016 16:13:24 -0400 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> References: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> Message-ID: * Main.java 98 private static final DisabledAlgorithmConstraints SIGN_CHECK = 99 new DisabledAlgorithmConstraints( 100 DisabledAlgorithmConstraints.PROPERTY_CERTPATH_DISABLED_ALGS); This should be changed to PROPERTY_JAR_DISABLED_ALGS now that the fix for 8167594 is in 9. * Resources.java 150 "The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.\n\nRe-run jarsigner with the -verbose option for more details."}, Should this also have "WARNING:" at the beginning like the other 2 unsigned warning messages? * JarUtils.java 45 * a new jar entry will be created with the file name itself the content. 70 * with the file name itself the content. These 2 lines would be more understandable if you changed "itself the content" to "itself as the content". * TimestampCheck.java You will need to update this test based on the new MD5 restrictions added in 8167594. --Sean On 10/19/2016 03:36 AM, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8163304/webrev.01/ > > With this change, "jarsigner -verify -verbose" will print out how a jar was signed. > > For example, a jar which was signed and timestamped with many weak algorithms will show > > - Signed by "CN=old" > Digest algorithm: MD2 (weak) > Signature algorithm: MD2withRSA (weak), 2048-bit key > Timestamped by "CN=tsbad1" on Wed Oct 19 07:32:22 UTC 2016 > Timestamp digest algorithm: MD2 (weak) > Timestamp signature algorithm: SHA1withRSA, 512-bit key (weak) > > WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property: > > jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024, DSA keySize < 1024 > > Thanks > Max > From ecki at zusammenkunft.net Wed Oct 19 20:30:09 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 19 Oct 2016 22:30:09 +0200 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: References: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> Message-ID: <20161019223009.00007587.ecki@zusammenkunft.net> Am Wed, 19 Oct 2016 16:13:24 -0400 schrieb Sean Mullan : > 150 "The jar will be treated as unsigned, because it > is signed with a weak algorithm that is now disabled.\n\nRe-run > jarsigner with the -verbose option for more details."}, I also wondered: what if there are multiple signatures. So a "because it is signed only with weak algorithms" might be better? Gruss Bernd From weijun.wang at oracle.com Wed Oct 19 23:16:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 20 Oct 2016 07:16:40 +0800 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: References: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> Message-ID: <480F8993-7481-483F-A999-9F7B33309AD1@oracle.com> > On Oct 20, 2016, at 4:13 AM, Sean Mullan wrote: > > * Main.java > > 98 private static final DisabledAlgorithmConstraints SIGN_CHECK = > 99 new DisabledAlgorithmConstraints( > 100 DisabledAlgorithmConstraints.PROPERTY_CERTPATH_DISABLED_ALGS); > > This should be changed to PROPERTY_JAR_DISABLED_ALGS now that the fix for 8167594 is in 9. Yes. > > * Resources.java > > 150 "The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.\n\nRe-run jarsigner with the -verbose option for more details."}, > > Should this also have "WARNING:" at the beginning like the other 2 unsigned warning messages? You suggested this some time ago: I think we should say "WARNING: Signature not parsable or verifiable. ..." Without the word "WARNING", the impact (to me) seems to get lost in the verbose output. The "WARNING" part is not needed if -verbose is not specified. > > * JarUtils.java > > 45 * a new jar entry will be created with the file name itself the content. > 70 * with the file name itself the content. > > These 2 lines would be more understandable if you changed "itself the content" to "itself as the content". Yes. > > * TimestampCheck.java > > You will need to update this test based on the new MD5 restrictions added in 8167594. Yes. Thanks Max > > --Sean > > On 10/19/2016 03:36 AM, Wang Weijun wrote: >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8163304/webrev.01/ >> >> With this change, "jarsigner -verify -verbose" will print out how a jar was signed. >> >> For example, a jar which was signed and timestamped with many weak algorithms will show >> >> - Signed by "CN=old" >> Digest algorithm: MD2 (weak) >> Signature algorithm: MD2withRSA (weak), 2048-bit key >> Timestamped by "CN=tsbad1" on Wed Oct 19 07:32:22 UTC 2016 >> Timestamp digest algorithm: MD2 (weak) >> Timestamp signature algorithm: SHA1withRSA, 512-bit key (weak) >> >> WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property: >> >> jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024, DSA keySize < 1024 >> >> Thanks >> Max >> From weijun.wang at oracle.com Wed Oct 19 23:58:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 20 Oct 2016 07:58:33 +0800 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: References: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> Message-ID: > Am Wed, 19 Oct 2016 16:13:24 -0400 > schrieb Sean Mullan < > sean.mullan at oracle.com > >: > > > > 150 "The jar will be treated as unsigned, because it > > > > is signed with a weak algorithm that is now disabled.\n\nRe-run > > > > jarsigner with the -verbose option for more details."}, > > > I also wondered: what if there are multiple signatures. So a "because > it is signed only with weak algorithms" might be better? This is more precise. But probably not more helpful. This warning only shows when all algorithms are weak and saying one algorithm is weak is not misleading. IMO, people will only get confused when one signature is weak and the other is not. In this case, the history prints out 2 signatures but "jarsigner -verify -verbose -certs" only shows one for the entries. I hope the weak label there could be meaningful. Thanks Max > > Gruss > Bernd From weijun.wang at oracle.com Thu Oct 20 00:07:23 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 20 Oct 2016 08:07:23 +0800 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: <480F8993-7481-483F-A999-9F7B33309AD1@oracle.com> References: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> <480F8993-7481-483F-A999-9F7B33309AD1@oracle.com> Message-ID: <631E523D-74CA-4E54-81B6-B9203E66A0C0@oracle.com> Updated at http://cr.openjdk.java.net/~weijun/8163304/webrev.02/ changes to webrev.01 is at http://cr.openjdk.java.net/~weijun/8163304/webrev.02/interdiff.patch.html Thanks Max From sean.mullan at oracle.com Thu Oct 20 01:05:40 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Oct 2016 21:05:40 -0400 Subject: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: <631E523D-74CA-4E54-81B6-B9203E66A0C0@oracle.com> References: <39FD8E8A-FF36-4CD0-9CDF-2C22DFD6051F@oracle.com> <480F8993-7481-483F-A999-9F7B33309AD1@oracle.com> <631E523D-74CA-4E54-81B6-B9203E66A0C0@oracle.com> Message-ID: Looks good. > On Oct 19, 2016, at 8:07 PM, Wang Weijun wrote: > > Updated at > > http://cr.openjdk.java.net/~weijun/8163304/webrev.02/ > > changes to webrev.01 is at > > http://cr.openjdk.java.net/~weijun/8163304/webrev.02/interdiff.patch.html > > Thanks > Max > From weijun.wang at oracle.com Thu Oct 20 02:47:31 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 20 Oct 2016 10:47:31 +0800 Subject: RFR 8168127: FilePermissionCollection merges incorrectly Message-ID: Please review the code change at http://cr.openjdk.java.net/~weijun/8168127/webrev.00/ Two changes: 1. npath2 is considered in equals and hashCode of FilePermission, so 2 objects with different npath2 can be added to a map and different entries. 2. special name for newPermUsingAltPath and newPermPlusAltPath results, so FilePermissionCollection::add will not merge one with the original. Thanks Max From weijun.wang at oracle.com Thu Oct 20 04:21:25 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 20 Oct 2016 12:21:25 +0800 Subject: RFR 8168374: TsacertOptionTest.java fails on all platforms Message-ID: Please review this test change: diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java b/test/sun/security/tools/jarsigner/TsacertOptionTest.java --- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java +++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java @@ -31,6 +31,7 @@ * @library /lib/testlibrary warnings * @modules java.base/sun.security.pkcs * java.base/sun.security.timestamp + * java.base/sun.security.tools.keytool * java.base/sun.security.util * java.base/sun.security.x509 * java.management TsacertOptionTest.java references another file TimestampCheck.java which uses a class in this private package, and compilation fails. Unfortunately JPRT has not caught this because TimestampCheck.java was executed earlier (which itself is also a @test and includes the property @modules line). Noreg-self. Thanks Max From amy.lu at oracle.com Thu Oct 20 05:15:02 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 20 Oct 2016 13:15:02 +0800 Subject: RFR 8168374: TsacertOptionTest.java fails on all platforms In-Reply-To: References: Message-ID: Looks good. Thank you for the quick fix! (I'm not an official reviewer.) Thanks, Amy On 10/20/16 12:21 PM, Wang Weijun wrote: > Please review this test change: > > diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java b/test/sun/security/tools/jarsigner/TsacertOptionTest.java > --- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java > +++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java > @@ -31,6 +31,7 @@ > * @library /lib/testlibrary warnings > * @modules java.base/sun.security.pkcs > * java.base/sun.security.timestamp > + * java.base/sun.security.tools.keytool > * java.base/sun.security.util > * java.base/sun.security.x509 > * java.management > > TsacertOptionTest.java references another file TimestampCheck.java which uses a class in this private package, and compilation fails. > > Unfortunately JPRT has not caught this because TimestampCheck.java was executed earlier (which itself is also a @test and includes the property @modules line). > > Noreg-self. > > Thanks > Max > From vincent.x.ryan at oracle.com Thu Oct 20 06:08:51 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 20 Oct 2016 07:08:51 +0100 Subject: RFR 8168374: TsacertOptionTest.java fails on all platforms In-Reply-To: References: Message-ID: Your fix looks fine to me. Thanks. > On 20 Oct 2016, at 05:21, Wang Weijun wrote: > > Please review this test change: > > diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java b/test/sun/security/tools/jarsigner/TsacertOptionTest.java > --- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java > +++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java > @@ -31,6 +31,7 @@ > * @library /lib/testlibrary warnings > * @modules java.base/sun.security.pkcs > * java.base/sun.security.timestamp > + * java.base/sun.security.tools.keytool > * java.base/sun.security.util > * java.base/sun.security.x509 > * java.management > > TsacertOptionTest.java references another file TimestampCheck.java which uses a class in this private package, and compilation fails. > > Unfortunately JPRT has not caught this because TimestampCheck.java was executed earlier (which itself is also a @test and includes the property @modules line). > > Noreg-self. > > Thanks > Max > From weijun.wang at oracle.com Thu Oct 20 08:51:10 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 20 Oct 2016 16:51:10 +0800 Subject: RFR 8167646: Better invalid FilePermission In-Reply-To: References: Message-ID: Please review the code change at http://cr.openjdk.java.net/~weijun/8167646/webrev.00/ A new flag invalid is added so invalid FilePermissions (invalid Path) do not equal or imply or is implied by anything else except for itself. Thanks Max From sean.mullan at oracle.com Thu Oct 20 15:22:16 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 20 Oct 2016 11:22:16 -0400 Subject: RFR: 8168313: Tighten permissions granted to jdk.crypto.pkcs11 module Message-ID: Please review this change to tighten or remove unnecessary permissions granted to the jdk.crypto.pkcs11 module: http://cr.openjdk.java.net/~mullan/webrevs/8168313/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8168313 In doing so, I refactored the code a little to not use sun.security.action APIs and was able to remove a qualified export from java.base. I also moved the reading of the os.name and os.arch system properties inside a doPrivileged block just in case the caller(s) do not have permission to read them. --Sean From bdhess at pobox.com Thu Oct 20 17:06:36 2016 From: bdhess at pobox.com (Bradley Hess) Date: Thu, 20 Oct 2016 17:06:36 +0000 Subject: RFR 9044691: Memory leak in JceSecurity Message-ID: I posted an issue (assigned ID # 90444691) using the public facing bug submission page, as I don't have an OpenJDK account. There's a slow memory leak in JceSecurity. The original source uses an IdentityHashMap, which I believe is done to avoid a case where a trusted Provider has a bad implementation of hashCode/equals that a rogue Provider is able to mimic in order to avoid verification. In my patch, I change the map to be a WeakHashMap, Object>, which I believe provides the same guarantees (that a Provider class has actually been validated) without leaking memory. This also provides an additional optimization: new instances of a previously-verified provider class do not cause the CodeSource to be re-verified. Attached is a patch that I believe addresses this issue. Cheers, Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 9044691.patch Type: application/octet-stream Size: 2845 bytes Desc: not available URL: From ivan.gerasimov at oracle.com Thu Oct 20 18:15:24 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 20 Oct 2016 21:15:24 +0300 Subject: [8u-dev] Request for Review and Approval to backport: 8167591: Add MD5 to signed JAR restrictions Message-ID: Hello! Would you please help review and give the approval to backport this fix? The changes in the backport, comparing to the fix in 9, are due to different file structure and the different previous value of the property. Bug: https://bugs.openjdk.java.net/browse/JDK-8167591 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/aabbe4707f1f Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-October/014995.html Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8167591/00/webrev/ With kind regards, Ivan From anthony.scarpino at oracle.com Thu Oct 20 21:06:43 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 20 Oct 2016 14:06:43 -0700 Subject: [8u-dev] Request for Review and Approval to backport: 8167591: Add MD5 to signed JAR restrictions In-Reply-To: References: Message-ID: <580931E3.9010506@oracle.com> On 10/20/2016 11:15 AM, Ivan Gerasimov wrote: > Hello! > > Would you please help review and give the approval to backport this fix? > > The changes in the backport, comparing to the fix in 9, are due to > different file structure and the different previous value of the property. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167591 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/aabbe4707f1f > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2016-October/014995.html > > Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8167591/00/webrev/ > > With kind regards, > Ivan > This looks fine to me. Tony From sean.coffey at oracle.com Thu Oct 20 21:16:46 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 20 Oct 2016 22:16:46 +0100 Subject: [8u-dev] Request for Review and Approval to backport: 8167591: Add MD5 to signed JAR restrictions In-Reply-To: <580931E3.9010506@oracle.com> References: <580931E3.9010506@oracle.com> Message-ID: <597123d4-e1db-1633-0eb0-df9000b1671c@oracle.com> Approved. Regards, Sean. On 20/10/2016 22:06, Anthony Scarpino wrote: > On 10/20/2016 11:15 AM, Ivan Gerasimov wrote: >> Hello! >> >> Would you please help review and give the approval to backport this fix? >> >> The changes in the backport, comparing to the fix in 9, are due to >> different file structure and the different previous value of the >> property. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8167591 >> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/aabbe4707f1f >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/security-dev/2016-October/014995.html >> >> >> Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8167591/00/webrev/ >> >> With kind regards, >> Ivan >> > > This looks fine to me. > > Tony > From anthony.scarpino at oracle.com Thu Oct 20 23:37:20 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 20 Oct 2016 16:37:20 -0700 Subject: RFR: 8168313: Tighten permissions granted to jdk.crypto.pkcs11 module In-Reply-To: References: Message-ID: <58095530.4010607@oracle.com> On 10/20/2016 08:22 AM, Sean Mullan wrote: > Please review this change to tighten or remove unnecessary permissions > granted to the jdk.crypto.pkcs11 module: > > http://cr.openjdk.java.net/~mullan/webrevs/8168313/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8168313 > > In doing so, I refactored the code a little to not use > sun.security.action APIs and was able to remove a qualified export from > java.base. I also moved the reading of the os.name and os.arch system > properties inside a doPrivileged block just in case the caller(s) do not > have permission to read them. > > --Sean Change looks good to me. Tony From rob.mckenna at oracle.com Fri Oct 21 02:31:45 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 21 Oct 2016 03:31:45 +0100 Subject: [8u-dev] Request for Review & Approval - 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar Message-ID: <20161021023145.GB2435@vimes> Hi folks, Looking for a codereview and push approval for the following: bug: https://bugs.openjdk.java.net/browse/JDK-8163304 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a25dbe45e61 8 webrev: http://cr.openjdk.java.net/~robm/8163304/webrev.02/ Thanks, -Rob From weijun.wang at oracle.com Fri Oct 21 02:38:20 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 21 Oct 2016 10:38:20 +0800 Subject: [8u-dev] Request for Review & Approval - 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: <20161021023145.GB2435@vimes> References: <20161021023145.GB2435@vimes> Message-ID: <3D18888E-185F-4CF7-92C2-D5014E6544F9@oracle.com> An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Oct 21 03:31:50 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Oct 2016 11:31:50 +0800 Subject: Code Review Request, JDK-8167680, DTLS implementation bugs In-Reply-To: References: Message-ID: <12ffdb04-a598-9512-fe17-fa252203cb70@oracle.com> Updated webrev per Jamil's comments: http://cr.openjdk.java.net/~xuelei/8167680/webrev.01/ Xuelei On 10/13/2016 10:36 PM, Xuelei Fan wrote: > Hi, > > Please review the fix for JDK-8167680: > http://cr.openjdk.java.net/~xuelei/8167680/webrev.00/ > > There are a few implementation bugs in JDK. > > 1. The sequence number is increased by 2 for GCM cipher suites. > Both GCM crypto operation and DTLS record use the sequence number. The > current implementation may increase the sequence number for each of the > two operations. It is not the expected behavior. > > 2. The implementation does not response to handshake retransmissions. > In the current implementation, receiving of retransmitted handshake > messages does not kick off a retransmission of the previous delivered > flight. Retransmission happens on timeout. Timeout is expensive. > Supporting response to peer retransmitted handshake messages would speed > up the handshaking. > > 3. the final CCC and finished message cannot be retransmitted. > It is an implementation bug. Every handshake message should be able to > get retransmitted. > > 4. the first application data may be discarded if the last flight get lost. > Applications may send application data immediately after the handshake > completed. However, the peer may have not receive the handshake > complete message, and therefor discard the application data. As may > impact application logic. > > For example > > Client Server > .... > -- ClientKeyExchange --> > -- ChangeCipherSpec --> > -- Finished --> > > > X <-- ChangeCipherSpec -- > X <-- Finished -- > > <-- Application Data -- > > ----- ... ---> > -- ClientKeyExchange --> > -- ChangeCipherSpec --> > -- Finished --> > > <-- ChangeCipherSpec -- > <-- Finished -- > > > 1. (omit the previous handshake messages) server sends ChangeCipherSpec > and Finished messages. > 2. server handshake complete > 3. server send application > 4. client does not receive the ChangeCipherSpec or Finished messages. > 5. client receives the application data. Client cannot handle the > encrypted message, and may discard it. Client re-transmit the previous > flight. > 6. server retransmit the last flight. > 7. client receives the last flight. > > In this update, the last flight will be transmit twice. As may mitigate > the impact of the issue. > > 5. resuming handshaking need no cookie exchange. > It is an implementation bug. Cookie exchange is performed for > handshaking resuming now. It is not the expected behavior. > > 6. need more debug log for DTLS handshake message fragmentation and > reassembly. > > > Thanks, > Xuelei From sha.jiang at oracle.com Fri Oct 21 05:13:14 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 21 Oct 2016 13:13:14 +0800 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" Message-ID: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> Hi, Please review this patch for fixing an intermittent issue on test sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. The fix applies the pattern from test/javax/net/ssl/templates/SSLSocketSample.java Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 Best regards, John Jiang From sean.coffey at oracle.com Fri Oct 21 05:30:28 2016 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 21 Oct 2016 06:30:28 +0100 Subject: [8u-dev] Request for Review & Approval - 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar In-Reply-To: <3D18888E-185F-4CF7-92C2-D5014E6544F9@oracle.com> References: <20161021023145.GB2435@vimes> <3D18888E-185F-4CF7-92C2-D5014E6544F9@oracle.com> Message-ID: Approved. Regards, Sean. On 21 October 2016 03:38:20 GMT+01:00, Wang Weijun wrote: > > >On Oct 21, 2016, at 10:31 AM, Rob McKenna >wrote: > >Hi folks, > >Looking for a codereview and push approval for the following: > >bug: https://bugs.openjdk.java.net/browse/JDK-8163304 >9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a25dbe45e61 >8 webrev: http://cr.openjdk.java.net/~robm/8163304/webrev.02/ > > >The code change looks good to me. > >Thanks >Max > > >Thanks, > > -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Oct 21 08:04:58 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Oct 2016 16:04:58 +0800 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" In-Reply-To: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> References: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> Message-ID: Looks fine to me. Xuelei On 10/21/2016 1:13 PM, John Jiang wrote: > Hi, > Please review this patch for fixing an intermittent issue on test > sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. > The fix applies the pattern from > test/javax/net/ssl/templates/SSLSocketSample.java > > Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 > > Best regards, > John Jiang > From ivan.gerasimov at oracle.com Fri Oct 21 09:37:45 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 21 Oct 2016 12:37:45 +0300 Subject: RFR: 8168468: [TEST_BUG] CheckNullEntity.java fails to compile Message-ID: Hello! A compilation issue with the regression test was observed due to ambiguity between two X509ExtendedTrustManager classes. The fix is to organize the imports. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168468 WEBREV: http://cr.openjdk.java.net/~igerasim/8168468/00/webrev/ Would you please help review this? With kind regards, Ivan From sean.mullan at oracle.com Fri Oct 21 11:34:06 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Oct 2016 07:34:06 -0400 Subject: RFR: 8168468: [TEST_BUG] CheckNullEntity.java fails to compile In-Reply-To: References: Message-ID: <044c7518-50ec-6e3f-ae04-ed7186830ad2@oracle.com> Looks good. Add noreg-self label to the bug. --Sean On 10/21/2016 05:37 AM, Ivan Gerasimov wrote: > Hello! > > A compilation issue with the regression test was observed due to > ambiguity between two X509ExtendedTrustManager classes. > > The fix is to organize the imports. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168468 > WEBREV: http://cr.openjdk.java.net/~igerasim/8168468/00/webrev/ > > Would you please help review this? > > With kind regards, > Ivan > From ivan.gerasimov at oracle.com Fri Oct 21 13:56:48 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 21 Oct 2016 16:56:48 +0300 Subject: RFR: 8168468: [TEST_BUG] CheckNullEntity.java fails to compile In-Reply-To: <044c7518-50ec-6e3f-ae04-ed7186830ad2@oracle.com> References: <044c7518-50ec-6e3f-ae04-ed7186830ad2@oracle.com> Message-ID: <222424bb-05d6-ddf8-1b6a-afb7bddb52b5@oracle.com> Thank you Sean! However, my initial evaluation occurred to be wrong: the failure was due to a different reason, so I reassigned the bug. With kind regards, Ivan On 21.10.2016 14:34, Sean Mullan wrote: > Looks good. Add noreg-self label to the bug. > > --Sean > > On 10/21/2016 05:37 AM, Ivan Gerasimov wrote: >> Hello! >> >> A compilation issue with the regression test was observed due to >> ambiguity between two X509ExtendedTrustManager classes. >> >> The fix is to organize the imports. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168468 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8168468/00/webrev/ >> >> Would you please help review this? >> >> With kind regards, >> Ivan >> > From mandy.chung at oracle.com Fri Oct 21 15:44:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 21 Oct 2016 08:44:53 -0700 Subject: RFR: 8168313: Tighten permissions granted to jdk.crypto.pkcs11 module In-Reply-To: References: Message-ID: <6D816321-1ED7-42B0-ACE7-0DC046EEC198@oracle.com> Looks good to me. Mandy > On Oct 20, 2016, at 8:22 AM, Sean Mullan wrote: > > Please review this change to tighten or remove unnecessary permissions granted to the jdk.crypto.pkcs11 module: > > http://cr.openjdk.java.net/~mullan/webrevs/8168313/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8168313 > > In doing so, I refactored the code a little to not use sun.security.action APIs and was able to remove a qualified export from java.base. I also moved the reading of the os.name and os.arch system properties inside a doPrivileged block just in case the caller(s) do not have permission to read them. > > --Sean From artem.smotrakov at oracle.com Fri Oct 21 17:50:31 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 21 Oct 2016 10:50:31 -0700 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" In-Reply-To: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> References: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> Message-ID: <72883158-b5aa-0b41-6aa6-a65a970a9f08@oracle.com> Hi John, It may be better to use SSLTest.java to avoid duplicate code. The class basically contains parts of SSLSocketSample.java http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/javax/net/ssl/templates/SSLTest.java Here is an example http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java Artem On 10/20/2016 10:13 PM, John Jiang wrote: > Hi, > Please review this patch for fixing an intermittent issue on test > sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. > The fix applies the pattern from > test/javax/net/ssl/templates/SSLSocketSample.java > > Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 > > Best regards, > John Jiang > From sean.mullan at oracle.com Fri Oct 21 20:24:37 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Oct 2016 16:24:37 -0400 Subject: RFR 9044691: Memory leak in JceSecurity In-Reply-To: References: Message-ID: <06e76674-1ee6-2b99-c58d-adbe833f1187@oracle.com> Hi Bradley, Thanks for filing the bug, and coming up with a potential patch for the issue. The bug has just made its way into our system, so we have not looked at it in detail yet, but in the meantime I added a link to your post as a comment. You can see the bug here: https://bugs.openjdk.java.net/browse/JDK-8168469 --Sean On 10/20/2016 01:06 PM, Bradley Hess wrote: > I posted an issue (assigned ID # 90444691) using the public facing bug > submission page, as I don't have an OpenJDK account. > > There's a slow memory leak in JceSecurity. The original source uses an > IdentityHashMap, which I believe is done to avoid a case where a trusted > Provider has a bad implementation of hashCode/equals that a rogue > Provider is able to mimic in order to avoid verification. > > In my patch, I change the map to be a WeakHashMap Provider>, Object>, which I believe provides the same guarantees (that a > Provider class has actually been validated) without leaking memory. > This also provides an additional optimization: new instances of a > previously-verified provider class do not cause the CodeSource to be > re-verified. > > Attached is a patch that I believe addresses this issue. > > Cheers, > Brad From ivan.gerasimov at oracle.com Fri Oct 21 21:06:47 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 22 Oct 2016 00:06:47 +0300 Subject: PING : Re: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should use operator new (nothrow) for allocations In-Reply-To: References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com> <82695145-098c-4707-1012-49b468a2221e@oracle.com> <8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com> <5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com> <0bd21ac9c0bf4f6e87ae15e3adc47962@DEWDFE13DE11.global.corp.sap> <9b049419-8d5a-0aa3-7cf4-95767ea908fc@oracle.com> Message-ID: <519652be-dc8a-385e-093a-9ac0ae229474@oracle.com> Hello! Could someone with the Reviewer's rights please help review and approve this fix? The latest webrev can be found here: http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/ Thanks in advance, Ivan From vincent.x.ryan at oracle.com Fri Oct 21 21:39:31 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 21 Oct 2016 22:39:31 +0100 Subject: PING : Re: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should use operator new (nothrow) for allocations In-Reply-To: <519652be-dc8a-385e-093a-9ac0ae229474@oracle.com> References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com> <82695145-098c-4707-1012-49b468a2221e@oracle.com> <8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com> <5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com> <0bd21ac9c0bf4f6e87ae15e3adc47962@DEWDFE13DE11.global.corp.sap> <9b049419-8d5a-0aa3-7cf4-95767ea908fc@oracle.com> <519652be-dc8a-385e-093a-9ac0ae229474@oracle.com> Message-ID: <9146215F-7108-4DCD-83A4-D379824B37C8@oracle.com> Your fix looks good Ivan. Thanks. > On 21 Oct 2016, at 22:06, Ivan Gerasimov wrote: > > Hello! > > Could someone with the Reviewer's rights please help review and approve this fix? > > The latest webrev can be found here: > http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/ > > Thanks in advance, > Ivan > > From sha.jiang at oracle.com Mon Oct 24 10:24:06 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 24 Oct 2016 18:24:06 +0800 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" In-Reply-To: <72883158-b5aa-0b41-6aa6-a65a970a9f08@oracle.com> References: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> <72883158-b5aa-0b41-6aa6-a65a970a9f08@oracle.com> Message-ID: Hi Artem, Thanks for your review. Would you like take a look at the updated webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.01/ I also modified SSLTest.java a bit to expose SSLServerSocket instance to support the fixing. Best regards, John Jiang On 2016/10/22 1:50, Artem Smotrakov wrote: > Hi John, > > It may be better to use SSLTest.java to avoid duplicate code. The > class basically contains parts of SSLSocketSample.java > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/javax/net/ssl/templates/SSLTest.java > > > Here is an example > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java > > > Artem > > > On 10/20/2016 10:13 PM, John Jiang wrote: >> Hi, >> Please review this patch for fixing an intermittent issue on test >> sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. >> The fix applies the pattern from >> test/javax/net/ssl/templates/SSLSocketSample.java >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 >> >> Best regards, >> John Jiang >> > > From artem.smotrakov at oracle.com Mon Oct 24 17:33:00 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 24 Oct 2016 10:33:00 -0700 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" In-Reply-To: References: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> <72883158-b5aa-0b41-6aa6-a65a970a9f08@oracle.com> Message-ID: <7be6b60e-e5d8-209c-2f5f-fbe014580434@oracle.com> Hi John, I think it is too late to set parameters for server socket in setServerApplication() because handshaking is already done at this point. You can use setServerPeer() and setClientPeer() if you need to configure server socket. In this case, you need to follow SSLSocketSample.java to implement doServerSide(). Artem On 10/24/2016 03:24 AM, John Jiang wrote: > Hi Artem, > Thanks for your review. > Would you like take a look at the updated webrev: > http://cr.openjdk.java.net/~jjiang/8168064/webrev.01/ > I also modified SSLTest.java a bit to expose SSLServerSocket instance > to support the fixing. > > Best regards, > John Jiang > > > On 2016/10/22 1:50, Artem Smotrakov wrote: >> Hi John, >> >> It may be better to use SSLTest.java to avoid duplicate code. The >> class basically contains parts of SSLSocketSample.java >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/javax/net/ssl/templates/SSLTest.java >> >> >> Here is an example >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java >> >> >> Artem >> >> >> On 10/20/2016 10:13 PM, John Jiang wrote: >>> Hi, >>> Please review this patch for fixing an intermittent issue on test >>> sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. >>> The fix applies the pattern from >>> test/javax/net/ssl/templates/SSLSocketSample.java >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 >>> >>> Best regards, >>> John Jiang >>> >> >> > From sscheck at silverspringnet.com Mon Oct 24 20:40:13 2016 From: sscheck at silverspringnet.com (Steve Scheck) Date: Mon, 24 Oct 2016 20:40:13 +0000 Subject: DTLS/JEP 219 in Java 9 preview builds? Message-ID: <23B47BE6-C4B7-4213-A7CD-0F0FD60B3FD6@silverspringnet.com> Hello, What is the status of JEP 219? I tried to find some details on the new DTLS API in the Java 9 preview builds, but it doesn?t appear to be there. Is there somewhere interested parties can obtain preview access to it? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Mon Oct 24 20:59:26 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 24 Oct 2016 13:59:26 -0700 Subject: DTLS/JEP 219 in Java 9 preview builds? In-Reply-To: <23B47BE6-C4B7-4213-A7CD-0F0FD60B3FD6@silverspringnet.com> References: <23B47BE6-C4B7-4213-A7CD-0F0FD60B3FD6@silverspringnet.com> Message-ID: Integrated. Look at the attached bug, and you can see the changes that went in. Basically, request a "DTLS", "DTLSv1.0", or "DTLSv1.2" SSLContext and use the SSLEngine API. Brad On 10/24/2016 1:40 PM, Steve Scheck wrote: > Hello, > > > > What is the status of JEP 219? I tried to find some details on the new > DTLS API in the Java 9 preview builds, but it doesn?t appear to be > there. Is there somewhere interested parties can obtain preview access > to it? > > > > Thanks. > > > From weijun.wang at oracle.com Tue Oct 25 04:18:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Oct 2016 12:18:14 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 Message-ID: http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the reason. This code change includes: 1. Add a hashAlg field in AuthTimeWithHash.java. 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. 3. The fix of the bug is inside DflCache.java: @@ -300,7 +302,7 @@ if (time.equals(a)) { // Exact match, must be a replay throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); - } else if (time.isSameIgnoresHash(a)) { + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { // Two different authenticators in the same second. // Remember it seeNewButNotSame = true; When a AuthTimeWithHash is seen with a different hash, we believe it's a new one. Before this fix, we simply compare the HASH string. Now that the algorithm can be different, we only treat it a new one if the algorithm is the same and the hash value is different. This code change has not tried to understand what a different hashAlg means and try to re-calculate with it. It is just treated as unknown. Tests updated. ReplayCacheTestProc.java enhanced so it can be called with some special system properties to test interop between a non-system-default native library or even between 2 different native libraries. Thanks Max From xuelei.fan at oracle.com Tue Oct 25 05:40:40 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Oct 2016 13:40:40 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: References: Message-ID: Is the "HASH" algorithm a new name? I'm not sure why introduce this none-standard name. 39 // The hash algorithm can be "HASH" or "SHA256". What if the algorithm is not one of the two? Why not use the standard names? Do you want to support SHA3? As the DEFAULT_HASH_ALG system property is customizable, the value may be not valid. Therefore, the AssertionError may be too strong to use in line 310 of KrbApReq.java, and the message can have more information. Otherwise, looks fine to me. Xuelei On 10/25/2016 12:18 PM, Wang Weijun wrote: > http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ > > Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the reason. This code change includes: > > 1. Add a hashAlg field in AuthTimeWithHash.java. > > 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. > > 3. The fix of the bug is inside DflCache.java: > > @@ -300,7 +302,7 @@ > > if (time.equals(a)) { > // Exact match, must be a replay > throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); > > - } else if (time.isSameIgnoresHash(a)) { > + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { > > // Two different authenticators in the same second. > // Remember it > seeNewButNotSame = true; > > When a AuthTimeWithHash is seen with a different hash, we believe it's a new one. Before this fix, we simply compare the HASH string. Now that the algorithm can be different, we only treat it a new one if the algorithm is the same and the hash value is different. > > This code change has not tried to understand what a different hashAlg means and try to re-calculate with it. It is just treated as unknown. > > Tests updated. ReplayCacheTestProc.java enhanced so it can be called with some special system properties to test interop between a non-system-default native library or even between 2 different native libraries. > > Thanks > Max > > > > > From weijun.wang at oracle.com Tue Oct 25 05:46:07 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Oct 2016 13:46:07 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: References: Message-ID: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> On 10/25/2016 1:40 PM, Xuelei Fan wrote: > Is the "HASH" algorithm a new name? I'm not sure why introduce this > none-standard name. HASH is actually MD5, it is the label used by MIT krb5 in its previous releases. In 1.15, it's SHA256. I just want it to the same with MIT krb5. > 39 // The hash algorithm can be "HASH" or "SHA256". > What if the algorithm is not one of the two? Why not use the standard > names? Do you want to support SHA3? No. The system property is not meant to be fully customizable. The only usage is that you can set it to SHA256 if you want full krb5-1.15 interoperability. I mainly created it so I can test on it. > > As the DEFAULT_HASH_ALG system property is customizable, the value may > be not valid. Therefore, the AssertionError may be too strong to use in > line 310 of KrbApReq.java, and the message can have more information. OK, I'll change the message. > > Otherwise, looks fine to me. > > Xuelei > > On 10/25/2016 12:18 PM, Wang Weijun wrote: >> http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ >> >> Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the >> reason. This code change includes: >> >> 1. Add a hashAlg field in AuthTimeWithHash.java. >> >> 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. >> >> 3. The fix of the bug is inside DflCache.java: >> >> @@ -300,7 +302,7 @@ >> >> if (time.equals(a)) { >> // Exact match, must be a replay >> throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); >> >> - } else if (time.isSameIgnoresHash(a)) { >> + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { >> >> // Two different authenticators in the same second. >> // Remember it >> seeNewButNotSame = true; >> >> When a AuthTimeWithHash is seen with a different hash, we believe it's >> a new one. Before this fix, we simply compare the HASH string. Now >> that the algorithm can be different, we only treat it a new one if the >> algorithm is the same and the hash value is different. >> >> This code change has not tried to understand what a different hashAlg >> means and try to re-calculate with it. It is just treated as unknown. >> >> Tests updated. ReplayCacheTestProc.java enhanced so it can be called >> with some special system properties to test interop between a >> non-system-default native library or even between 2 different native >> libraries. >> >> Thanks >> Max >> >> >> >> >> From weijun.wang at oracle.com Tue Oct 25 07:36:47 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Oct 2016 15:36:47 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> References: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> Message-ID: Hi Xuelei I rethink about it. Here is the updated webrev: http://cr.openjdk.java.net/~weijun/8168518/webrev.01/ Changes from webrev.00: 1. Default value is now SHA256. This is also the same default for latest MIT krb5. 2. User can only revert it to HASH with a boolean system property. No more free setting. 3. Test fixed. I forgot to pass the system property to child process. Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8168635. Thanks Max > On Oct 25, 2016, at 1:46 PM, Wang Weijun wrote: > > > > On 10/25/2016 1:40 PM, Xuelei Fan wrote: >> Is the "HASH" algorithm a new name? I'm not sure why introduce this >> none-standard name. > > HASH is actually MD5, it is the label used by MIT krb5 in its previous releases. In 1.15, it's SHA256. I just want it to the same with MIT krb5. > >> 39 // The hash algorithm can be "HASH" or "SHA256". >> What if the algorithm is not one of the two? Why not use the standard >> names? Do you want to support SHA3? > > No. > > The system property is not meant to be fully customizable. The only usage is that you can set it to SHA256 if you want full krb5-1.15 interoperability. I mainly created it so I can test on it. > >> >> As the DEFAULT_HASH_ALG system property is customizable, the value may >> be not valid. Therefore, the AssertionError may be too strong to use in >> line 310 of KrbApReq.java, and the message can have more information. > > OK, I'll change the message. > > >> >> Otherwise, looks fine to me. >> >> Xuelei >> >> On 10/25/2016 12:18 PM, Wang Weijun wrote: >>> http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ >>> >>> Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the >>> reason. This code change includes: >>> >>> 1. Add a hashAlg field in AuthTimeWithHash.java. >>> >>> 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. >>> >>> 3. The fix of the bug is inside DflCache.java: >>> >>> @@ -300,7 +302,7 @@ >>> >>> if (time.equals(a)) { >>> // Exact match, must be a replay >>> throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); >>> >>> - } else if (time.isSameIgnoresHash(a)) { >>> + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { >>> >>> // Two different authenticators in the same second. >>> // Remember it >>> seeNewButNotSame = true; >>> >>> When a AuthTimeWithHash is seen with a different hash, we believe it's >>> a new one. Before this fix, we simply compare the HASH string. Now >>> that the algorithm can be different, we only treat it a new one if the >>> algorithm is the same and the hash value is different. >>> >>> This code change has not tried to understand what a different hashAlg >>> means and try to re-calculate with it. It is just treated as unknown. >>> >>> Tests updated. ReplayCacheTestProc.java enhanced so it can be called >>> with some special system properties to test interop between a >>> non-system-default native library or even between 2 different native >>> libraries. >>> >>> Thanks >>> Max >>> >>> >>> >>> >>> From xuelei.fan at oracle.com Tue Oct 25 08:53:49 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Oct 2016 16:53:49 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: References: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> Message-ID: <8f9a2843-ac15-4ddf-b8a1-175d415bc102@oracle.com> >>> Is the "HASH" algorithm a new name? I'm not sure why introduce this >>> none-standard name. >> >> HASH is actually MD5, it is the label used by MIT krb5 in its >> previous releases. In 1.15, it's SHA256. I just want it to the >> same with MIT krb5. I see. As the HASH and SHA256 was converted to MD5 and SHA-256 if using (with realAlg()), and the names are never expose to external, it may be not necessary to use the intermediate variables and realAlg() method. if (the system property is true) { // make a note, it is the same name as HASH in MIT world. set the alg to MD5 } else { // make a note, it is the same name as SHA256 in MIT world. set the alg to SHA-56. } Personally, I'd like to use "useMD5" as the ending part of the system property. Otherwise, the source code looks fine to me. For the release note, it compatibility impact on JDK 9/8 are mentioned. What about JDK 7/6? I guess not. Would you mind mention the impact on JDK 7/6 explicitly? BTW, can the rcache file can be refreshed to use SHA-256 if MD5 was used previously? Thanks, Xuelei On 10/25/2016 3:36 PM, Wang Weijun wrote: > Hi Xuelei > > I rethink about it. Here is the updated webrev: > > http://cr.openjdk.java.net/~weijun/8168518/webrev.01/ > > Changes from webrev.00: > > 1. Default value is now SHA256. This is also the same default for latest MIT krb5. > > 2. User can only revert it to HASH with a boolean system property. No more free setting. > > 3. Test fixed. I forgot to pass the system property to child process. > > Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8168635. > > Thanks > Max > >> On Oct 25, 2016, at 1:46 PM, Wang Weijun wrote: >> >> >> >> On 10/25/2016 1:40 PM, Xuelei Fan wrote: >>> Is the "HASH" algorithm a new name? I'm not sure why introduce this >>> none-standard name. >> >> HASH is actually MD5, it is the label used by MIT krb5 in its previous releases. In 1.15, it's SHA256. I just want it to the same with MIT krb5. >> >>> 39 // The hash algorithm can be "HASH" or "SHA256". >>> What if the algorithm is not one of the two? Why not use the standard >>> names? Do you want to support SHA3? >> >> No. >> >> The system property is not meant to be fully customizable. The only usage is that you can set it to SHA256 if you want full krb5-1.15 interoperability. I mainly created it so I can test on it. >> >>> >>> As the DEFAULT_HASH_ALG system property is customizable, the value may >>> be not valid. Therefore, the AssertionError may be too strong to use in >>> line 310 of KrbApReq.java, and the message can have more information. >> >> OK, I'll change the message. >> >> >>> >>> Otherwise, looks fine to me. >>> >>> Xuelei >>> >>> On 10/25/2016 12:18 PM, Wang Weijun wrote: >>>> http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ >>>> >>>> Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the >>>> reason. This code change includes: >>>> >>>> 1. Add a hashAlg field in AuthTimeWithHash.java. >>>> >>>> 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. >>>> >>>> 3. The fix of the bug is inside DflCache.java: >>>> >>>> @@ -300,7 +302,7 @@ >>>> >>>> if (time.equals(a)) { >>>> // Exact match, must be a replay >>>> throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); >>>> >>>> - } else if (time.isSameIgnoresHash(a)) { >>>> + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { >>>> >>>> // Two different authenticators in the same second. >>>> // Remember it >>>> seeNewButNotSame = true; >>>> >>>> When a AuthTimeWithHash is seen with a different hash, we believe it's >>>> a new one. Before this fix, we simply compare the HASH string. Now >>>> that the algorithm can be different, we only treat it a new one if the >>>> algorithm is the same and the hash value is different. >>>> >>>> This code change has not tried to understand what a different hashAlg >>>> means and try to re-calculate with it. It is just treated as unknown. >>>> >>>> Tests updated. ReplayCacheTestProc.java enhanced so it can be called >>>> with some special system properties to test interop between a >>>> non-system-default native library or even between 2 different native >>>> libraries. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> >>>> >>>> > From weijun.wang at oracle.com Tue Oct 25 09:06:10 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Oct 2016 17:06:10 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: <8f9a2843-ac15-4ddf-b8a1-175d415bc102@oracle.com> References: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> <8f9a2843-ac15-4ddf-b8a1-175d415bc102@oracle.com> Message-ID: > On Oct 25, 2016, at 4:53 PM, Xuelei Fan wrote: > > >>> Is the "HASH" algorithm a new name? I'm not sure why introduce this > >>> none-standard name. > >> > >> HASH is actually MD5, it is the label used by MIT krb5 in its > >> previous releases. In 1.15, it's SHA256. I just want it to the > >> same with MIT krb5. > I see. As the HASH and SHA256 was converted to MD5 and SHA-256 if using (with realAlg()), and the names are never expose to external, it may be not necessary to use the intermediate variables and realAlg() method. > > if (the system property is true) { > // make a note, it is the same name as HASH in MIT world. > set the alg to MD5 > } else { > // make a note, it is the same name as SHA256 in MIT world. > set the alg to SHA-56. > } I have to do translation between arg in MessageDigest.getInstance(arg) and the label inside the rcache file, and store a field name inside AuthTimeWithHash. Do you mean a boolean is enough? Although the value is not fully customizable now I still want it to a string instead of boolean so we can be free to change later. > > Personally, I'd like to use "useMD5" as the ending part of the system property. OK. > > Otherwise, the source code looks fine to me. > > For the release note, it compatibility impact on JDK 9/8 are mentioned. What about JDK 7/6? I guess not. Would you mind mention the impact on JDK 7/6 explicitly? OK, I remember hash was introduced in jdk7, will double check. > > BTW, can the rcache file can be refreshed to use SHA-256 if MD5 was used previously? You mean inside the same file? Newly added entries will be SHA-256 and the old ones remains. Still interoperable but just ignored. Thanks Max > > Thanks, > Xuelei > > On 10/25/2016 3:36 PM, Wang Weijun wrote: >> Hi Xuelei >> >> I rethink about it. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~weijun/8168518/webrev.01/ >> >> Changes from webrev.00: >> >> 1. Default value is now SHA256. This is also the same default for latest MIT krb5. >> >> 2. User can only revert it to HASH with a boolean system property. No more free setting. >> >> 3. Test fixed. I forgot to pass the system property to child process. >> >> Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8168635. >> >> Thanks >> Max >> >>> On Oct 25, 2016, at 1:46 PM, Wang Weijun wrote: >>> >>> >>> >>> On 10/25/2016 1:40 PM, Xuelei Fan wrote: >>>> Is the "HASH" algorithm a new name? I'm not sure why introduce this >>>> none-standard name. >>> >>> HASH is actually MD5, it is the label used by MIT krb5 in its previous releases. In 1.15, it's SHA256. I just want it to the same with MIT krb5. >>> >>>> 39 // The hash algorithm can be "HASH" or "SHA256". >>>> What if the algorithm is not one of the two? Why not use the standard >>>> names? Do you want to support SHA3? >>> >>> No. >>> >>> The system property is not meant to be fully customizable. The only usage is that you can set it to SHA256 if you want full krb5-1.15 interoperability. I mainly created it so I can test on it. >>> >>>> >>>> As the DEFAULT_HASH_ALG system property is customizable, the value may >>>> be not valid. Therefore, the AssertionError may be too strong to use in >>>> line 310 of KrbApReq.java, and the message can have more information. >>> >>> OK, I'll change the message. >>> >>> >>>> >>>> Otherwise, looks fine to me. >>>> >>>> Xuelei >>>> >>>> On 10/25/2016 12:18 PM, Wang Weijun wrote: >>>>> http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ >>>>> >>>>> Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the >>>>> reason. This code change includes: >>>>> >>>>> 1. Add a hashAlg field in AuthTimeWithHash.java. >>>>> >>>>> 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. >>>>> >>>>> 3. The fix of the bug is inside DflCache.java: >>>>> >>>>> @@ -300,7 +302,7 @@ >>>>> >>>>> if (time.equals(a)) { >>>>> // Exact match, must be a replay >>>>> throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); >>>>> >>>>> - } else if (time.isSameIgnoresHash(a)) { >>>>> + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { >>>>> >>>>> // Two different authenticators in the same second. >>>>> // Remember it >>>>> seeNewButNotSame = true; >>>>> >>>>> When a AuthTimeWithHash is seen with a different hash, we believe it's >>>>> a new one. Before this fix, we simply compare the HASH string. Now >>>>> that the algorithm can be different, we only treat it a new one if the >>>>> algorithm is the same and the hash value is different. >>>>> >>>>> This code change has not tried to understand what a different hashAlg >>>>> means and try to re-calculate with it. It is just treated as unknown. >>>>> >>>>> Tests updated. ReplayCacheTestProc.java enhanced so it can be called >>>>> with some special system properties to test interop between a >>>>> non-system-default native library or even between 2 different native >>>>> libraries. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> >>>>> >>>>> >> From xuelei.fan at oracle.com Tue Oct 25 09:11:18 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Oct 2016 17:11:18 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: References: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> <8f9a2843-ac15-4ddf-b8a1-175d415bc102@oracle.com> Message-ID: <10640b69-863b-c652-de3f-a20548c26dc5@oracle.com> On 10/25/2016 5:06 PM, Wang Weijun wrote: > >> On Oct 25, 2016, at 4:53 PM, Xuelei Fan wrote: >> >>>>> Is the "HASH" algorithm a new name? I'm not sure why introduce this >>>>> none-standard name. >>>> >>>> HASH is actually MD5, it is the label used by MIT krb5 in its >>>> previous releases. In 1.15, it's SHA256. I just want it to the >>>> same with MIT krb5. >> I see. As the HASH and SHA256 was converted to MD5 and SHA-256 if using (with realAlg()), and the names are never expose to external, it may be not necessary to use the intermediate variables and realAlg() method. >> >> if (the system property is true) { >> // make a note, it is the same name as HASH in MIT world. >> set the alg to MD5 >> } else { >> // make a note, it is the same name as SHA256 in MIT world. >> set the alg to SHA-56. >> } > > I have to do translation between arg in MessageDigest.getInstance(arg) and the label inside the rcache file, and store a field name inside AuthTimeWithHash. OK, I missed this point. > Do you mean a boolean is enough? Although the value is not fully customizable now I still want it to a string instead of boolean so we can be free to change later. > >> >> Personally, I'd like to use "useMD5" as the ending part of the system property. > > OK. > >> >> Otherwise, the source code looks fine to me. >> >> For the release note, it compatibility impact on JDK 9/8 are mentioned. What about JDK 7/6? I guess not. Would you mind mention the impact on JDK 7/6 explicitly? > > OK, I remember hash was introduced in jdk7, will double check. > >> >> BTW, can the rcache file can be refreshed to use SHA-256 if MD5 was used previously? > > You mean inside the same file? Newly added entries will be SHA-256 and the old ones remains. Still interoperable but just ignored. > That's fine. Thanks, Xuelei > Thanks > Max > >> >> Thanks, >> Xuelei >> >> On 10/25/2016 3:36 PM, Wang Weijun wrote: >>> Hi Xuelei >>> >>> I rethink about it. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~weijun/8168518/webrev.01/ >>> >>> Changes from webrev.00: >>> >>> 1. Default value is now SHA256. This is also the same default for latest MIT krb5. >>> >>> 2. User can only revert it to HASH with a boolean system property. No more free setting. >>> >>> 3. Test fixed. I forgot to pass the system property to child process. >>> >>> Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8168635. >>> >>> Thanks >>> Max >>> >>>> On Oct 25, 2016, at 1:46 PM, Wang Weijun wrote: >>>> >>>> >>>> >>>> On 10/25/2016 1:40 PM, Xuelei Fan wrote: >>>>> Is the "HASH" algorithm a new name? I'm not sure why introduce this >>>>> none-standard name. >>>> >>>> HASH is actually MD5, it is the label used by MIT krb5 in its previous releases. In 1.15, it's SHA256. I just want it to the same with MIT krb5. >>>> >>>>> 39 // The hash algorithm can be "HASH" or "SHA256". >>>>> What if the algorithm is not one of the two? Why not use the standard >>>>> names? Do you want to support SHA3? >>>> >>>> No. >>>> >>>> The system property is not meant to be fully customizable. The only usage is that you can set it to SHA256 if you want full krb5-1.15 interoperability. I mainly created it so I can test on it. >>>> >>>>> >>>>> As the DEFAULT_HASH_ALG system property is customizable, the value may >>>>> be not valid. Therefore, the AssertionError may be too strong to use in >>>>> line 310 of KrbApReq.java, and the message can have more information. >>>> >>>> OK, I'll change the message. >>>> >>>> >>>>> >>>>> Otherwise, looks fine to me. >>>>> >>>>> Xuelei >>>>> >>>>> On 10/25/2016 12:18 PM, Wang Weijun wrote: >>>>>> http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ >>>>>> >>>>>> Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the >>>>>> reason. This code change includes: >>>>>> >>>>>> 1. Add a hashAlg field in AuthTimeWithHash.java. >>>>>> >>>>>> 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. >>>>>> >>>>>> 3. The fix of the bug is inside DflCache.java: >>>>>> >>>>>> @@ -300,7 +302,7 @@ >>>>>> >>>>>> if (time.equals(a)) { >>>>>> // Exact match, must be a replay >>>>>> throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT); >>>>>> >>>>>> - } else if (time.isSameIgnoresHash(a)) { >>>>>> + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) { >>>>>> >>>>>> // Two different authenticators in the same second. >>>>>> // Remember it >>>>>> seeNewButNotSame = true; >>>>>> >>>>>> When a AuthTimeWithHash is seen with a different hash, we believe it's >>>>>> a new one. Before this fix, we simply compare the HASH string. Now >>>>>> that the algorithm can be different, we only treat it a new one if the >>>>>> algorithm is the same and the hash value is different. >>>>>> >>>>>> This code change has not tried to understand what a different hashAlg >>>>>> means and try to re-calculate with it. It is just treated as unknown. >>>>>> >>>>>> Tests updated. ReplayCacheTestProc.java enhanced so it can be called >>>>>> with some special system properties to test interop between a >>>>>> non-system-default native library or even between 2 different native >>>>>> libraries. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> > From sha.jiang at oracle.com Wed Oct 26 11:45:38 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 26 Oct 2016 19:45:38 +0800 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" In-Reply-To: <7be6b60e-e5d8-209c-2f5f-fbe014580434@oracle.com> References: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> <72883158-b5aa-0b41-6aa6-a65a970a9f08@oracle.com> <7be6b60e-e5d8-209c-2f5f-fbe014580434@oracle.com> Message-ID: <8c6b43b6-78bd-c5d3-9216-991a9e826e19@oracle.com> Hi Artem, Please take a look at this version: http://cr.openjdk.java.net/~jjiang/8168064/webrev.02/ It set a new Server peer. Best regards, John Jiang On 2016/10/25 1:33, Artem Smotrakov wrote: > Hi John, > > I think it is too late to set parameters for server socket in > setServerApplication() because handshaking is already done at this point. > > You can use setServerPeer() and setClientPeer() if you need to > configure server socket. In this case, you need to follow > SSLSocketSample.java to implement doServerSide(). > > Artem > > > On 10/24/2016 03:24 AM, John Jiang wrote: >> Hi Artem, >> Thanks for your review. >> Would you like take a look at the updated webrev: >> http://cr.openjdk.java.net/~jjiang/8168064/webrev.01/ >> I also modified SSLTest.java a bit to expose SSLServerSocket instance >> to support the fixing. >> >> Best regards, >> John Jiang >> >> >> On 2016/10/22 1:50, Artem Smotrakov wrote: >>> Hi John, >>> >>> It may be better to use SSLTest.java to avoid duplicate code. The >>> class basically contains parts of SSLSocketSample.java >>> >>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/javax/net/ssl/templates/SSLTest.java >>> >>> >>> Here is an example >>> >>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java >>> >>> >>> Artem >>> >>> >>> On 10/20/2016 10:13 PM, John Jiang wrote: >>>> Hi, >>>> Please review this patch for fixing an intermittent issue on test >>>> sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. >>>> The fix applies the pattern from >>>> test/javax/net/ssl/templates/SSLSocketSample.java >>>> >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 >>>> >>>> Best regards, >>>> John Jiang >>>> >>> >>> >> > > From bradford.wetmore at oracle.com Wed Oct 26 16:31:19 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 26 Oct 2016 09:31:19 -0700 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <051486bd-159d-ef4b-486b-f007a9ccb636@oracle.com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> <051486bd-159d-ef4b-486b-f007a9ccb636@oracle.com> Message-ID: Xuelei, Sorry that I didn't have time to look at this earlier. Why did you create a new file SSLSocketSample.java instead of just updating SSLSocketTemplate.java? Why should I use one vs the other? IMHO, unless there's a good reason to keep both, we should just copy the contents of SSLSocketSample.java to SSLSocketTemplate.java, and remove SSLSocketSample.java. Brad On 7/24/2016 10:22 PM, Weijun Wang wrote: > > > On 7/25/2016 13:14, Xuelei Fan wrote: >> On 7/25/2016 12:15 PM, Weijun Wang wrote: >>> Is it possible to use a single new CountDownLatch(2)? >>> >> Per the spec, the countDown() release all waiting threads if the count >> reaches zero, and the await() will not return until the latch has >> counted down to zero, or interrupted or timeout. It's difficult to use >> one instance of CountDownLatch(2) for two conditions. > > Ah, yes. I forgot about that. > >> >>> Also, I think comments on lines 145-149 and 199-203 are not really >>> necessary, the println() lines after them are quite clear. >>> >> The comments make the logic easier to understand, I think. Let's keep >> the comments if it is not a big concern of yours. > > Sure. > > So everything looks fine to me. > > Thanks > Max > >> >> Thanks, >> Xuelei >> >>> --Max >>> >>> On 7/25/2016 11:38, Xuelei Fan wrote: >>>> Hi Weijun, >>>> >>>> Please review this update. Per you suggestion, I updated to use >>>> CountDownLatch for the synchronization between client and server. >>>> CountDownLatch is more simple than ReentrantLock in the context. >>>> >>>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ >>>> >>>> Thanks, >>>> Xuelei >>>> >> From Xuelei.Fan at Oracle.Com Wed Oct 26 16:45:10 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 27 Oct 2016 00:45:10 +0800 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> <051486bd-159d-ef4b-486b-f007a9ccb636@oracle.com> Message-ID: <8DED1BAE-8B24-4F0B-8E24-2DAA6AAED8F3@Oracle.Com> The new test case is just a test in order to make sure this approach works in the testing environment. I plan to remove both of the sample and template, and re-org them to a class that can be inherited from. Xuelei > On 27 Oct 2016, at 12:31 AM, Bradford Wetmore wrote: > > Xuelei, > > Sorry that I didn't have time to look at this earlier. > > Why did you create a new file SSLSocketSample.java instead of just updating SSLSocketTemplate.java? Why should I use one vs the other? > > IMHO, unless there's a good reason to keep both, we should just copy the contents of SSLSocketSample.java to SSLSocketTemplate.java, and remove SSLSocketSample.java. > > Brad > > > >> On 7/24/2016 10:22 PM, Weijun Wang wrote: >> >> >>> On 7/25/2016 13:14, Xuelei Fan wrote: >>>> On 7/25/2016 12:15 PM, Weijun Wang wrote: >>>> Is it possible to use a single new CountDownLatch(2)? >>>> >>> Per the spec, the countDown() release all waiting threads if the count >>> reaches zero, and the await() will not return until the latch has >>> counted down to zero, or interrupted or timeout. It's difficult to use >>> one instance of CountDownLatch(2) for two conditions. >> >> Ah, yes. I forgot about that. >> >>> >>>> Also, I think comments on lines 145-149 and 199-203 are not really >>>> necessary, the println() lines after them are quite clear. >>>> >>> The comments make the logic easier to understand, I think. Let's keep >>> the comments if it is not a big concern of yours. >> >> Sure. >> >> So everything looks fine to me. >> >> Thanks >> Max >> >>> >>> Thanks, >>> Xuelei >>> >>>> --Max >>>> >>>>> On 7/25/2016 11:38, Xuelei Fan wrote: >>>>> Hi Weijun, >>>>> >>>>> Please review this update. Per you suggestion, I updated to use >>>>> CountDownLatch for the synchronization between client and server. >>>>> CountDownLatch is more simple than ReentrantLock in the context. >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>> From artem.smotrakov at oracle.com Wed Oct 26 20:02:09 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 26 Oct 2016 13:02:09 -0700 Subject: RFR[9] JDK-8168064: sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java failed with "Received fatal alert: handshake_failure" In-Reply-To: <8c6b43b6-78bd-c5d3-9216-991a9e826e19@oracle.com> References: <68e1dd94-e27f-ecdf-f388-f0882d82fdfe@oracle.com> <72883158-b5aa-0b41-6aa6-a65a970a9f08@oracle.com> <7be6b60e-e5d8-209c-2f5f-fbe014580434@oracle.com> <8c6b43b6-78bd-c5d3-9216-991a9e826e19@oracle.com> Message-ID: Hi John, Looks good to me, thank you for the update. Artem On 10/26/2016 04:45 AM, John Jiang wrote: > Hi Artem, > Please take a look at this version: > http://cr.openjdk.java.net/~jjiang/8168064/webrev.02/ > It set a new Server peer. > > Best regards, > John Jiang > > On 2016/10/25 1:33, Artem Smotrakov wrote: >> Hi John, >> >> I think it is too late to set parameters for server socket in >> setServerApplication() because handshaking is already done at this >> point. >> >> You can use setServerPeer() and setClientPeer() if you need to >> configure server socket. In this case, you need to follow >> SSLSocketSample.java to implement doServerSide(). >> >> Artem >> >> >> On 10/24/2016 03:24 AM, John Jiang wrote: >>> Hi Artem, >>> Thanks for your review. >>> Would you like take a look at the updated webrev: >>> http://cr.openjdk.java.net/~jjiang/8168064/webrev.01/ >>> I also modified SSLTest.java a bit to expose SSLServerSocket >>> instance to support the fixing. >>> >>> Best regards, >>> John Jiang >>> >>> >>> On 2016/10/22 1:50, Artem Smotrakov wrote: >>>> Hi John, >>>> >>>> It may be better to use SSLTest.java to avoid duplicate code. The >>>> class basically contains parts of SSLSocketSample.java >>>> >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/javax/net/ssl/templates/SSLTest.java >>>> >>>> >>>> Here is an example >>>> >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/0fb9ba19a63a/test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java >>>> >>>> >>>> Artem >>>> >>>> >>>> On 10/20/2016 10:13 PM, John Jiang wrote: >>>>> Hi, >>>>> Please review this patch for fixing an intermittent issue on test >>>>> sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java. >>>>> The fix applies the pattern from >>>>> test/javax/net/ssl/templates/SSLSocketSample.java >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8168064/webrev.00/ >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8168064 >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>> >>>> >>> >> >> > From artem.smotrakov at oracle.com Wed Oct 26 20:15:22 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 26 Oct 2016 13:15:22 -0700 Subject: Code Review Request JDK-8161106 Improve SSLSocket test template In-Reply-To: <8DED1BAE-8B24-4F0B-8E24-2DAA6AAED8F3@Oracle.Com> References: <0be19482-a639-3e1d-6699-190ae78cb3ef@oracle.com> <033b91ce-91ed-697d-438d-f2b0cc5fcee2@oracle.com> <578522C6.8040402@oracle.com> <57867E0C.7000705@oracle.com> <8b433a77-0814-0a02-047b-5036900b51c6@oracle.com> <86e9b686-6667-65bf-f791-eac4d2c8dadf@oracle.com> <051486bd-159d-ef4b-486b-f007a9ccb636@oracle.com> <8DED1BAE-8B24-4F0B-8E24-2DAA6AAED8F3@Oracle.Com> Message-ID: <7ba2b36f-cdf5-617e-a235-efe12a57891c@oracle.com> There is SSLTest.java which follows SSLSocketSample.java and can be used by other tests. Artem On 10/26/2016 09:45 AM, Xuelei Fan wrote: > The new test case is just a test in order to make sure this approach works in the testing environment. I plan to remove both of the sample and template, and re-org them to a class that can be inherited from. > > Xuelei > >> On 27 Oct 2016, at 12:31 AM, Bradford Wetmore wrote: >> >> Xuelei, >> >> Sorry that I didn't have time to look at this earlier. >> >> Why did you create a new file SSLSocketSample.java instead of just updating SSLSocketTemplate.java? Why should I use one vs the other? >> >> IMHO, unless there's a good reason to keep both, we should just copy the contents of SSLSocketSample.java to SSLSocketTemplate.java, and remove SSLSocketSample.java. >> >> Brad >> >> >> >>> On 7/24/2016 10:22 PM, Weijun Wang wrote: >>> >>> >>>> On 7/25/2016 13:14, Xuelei Fan wrote: >>>>> On 7/25/2016 12:15 PM, Weijun Wang wrote: >>>>> Is it possible to use a single new CountDownLatch(2)? >>>>> >>>> Per the spec, the countDown() release all waiting threads if the count >>>> reaches zero, and the await() will not return until the latch has >>>> counted down to zero, or interrupted or timeout. It's difficult to use >>>> one instance of CountDownLatch(2) for two conditions. >>> Ah, yes. I forgot about that. >>> >>>>> Also, I think comments on lines 145-149 and 199-203 are not really >>>>> necessary, the println() lines after them are quite clear. >>>>> >>>> The comments make the logic easier to understand, I think. Let's keep >>>> the comments if it is not a big concern of yours. >>> Sure. >>> >>> So everything looks fine to me. >>> >>> Thanks >>> Max >>> >>>> Thanks, >>>> Xuelei >>>> >>>>> --Max >>>>> >>>>>> On 7/25/2016 11:38, Xuelei Fan wrote: >>>>>> Hi Weijun, >>>>>> >>>>>> Please review this update. Per you suggestion, I updated to use >>>>>> CountDownLatch for the synchronization between client and server. >>>>>> CountDownLatch is more simple than ReentrantLock in the context. >>>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8161106/webrev.03/ >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> From xuelei.fan at oracle.com Thu Oct 27 00:04:02 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 27 Oct 2016 08:04:02 +0800 Subject: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs Message-ID: Hi, Please review the simple fix: http://cr.openjdk.java.net/~xuelei/8168822/webrev/ Algorithm restrictions do not apply to trusted certs as the application or customer has made the decision to trust the "trusted cert". However, this point is not explicit for general developers and users. We'd better to clarify this point explicitly. In the update, I add a short note for each algorithm constraint security properties: Note: Algorithm restrictions do not apply to trusted certificates. Doc only update, no new regression test. Thanks, Xuelei From weijun.wang at oracle.com Thu Oct 27 00:30:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 27 Oct 2016 08:30:32 +0800 Subject: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs In-Reply-To: References: Message-ID: I don't think this applies to jdk.jar.disabledAlgorithms. While the private key algorithm and key size are determined by the certificate, I think they are always checked even if the end-entity cert is trusted (For example, a trusted self-signed cert). Thanks Max On 10/27/2016 8:04 AM, Xuelei Fan wrote: > Hi, > > Please review the simple fix: > > http://cr.openjdk.java.net/~xuelei/8168822/webrev/ > > Algorithm restrictions do not apply to trusted certs as the > application or customer has made the decision to trust the "trusted > cert". However, this point is not explicit for general developers and > users. We'd better to clarify this point explicitly. > > In the update, I add a short note for each algorithm constraint security > properties: > > Note: Algorithm restrictions do not apply to trusted certificates. > > Doc only update, no new regression test. > > Thanks, > Xuelei From weijun.wang at oracle.com Thu Oct 27 00:34:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 27 Oct 2016 08:34:08 +0800 Subject: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs In-Reply-To: References: Message-ID: <743cffb3-fa7b-9915-b355-87972462934a@oracle.com> One question: I thought for TLS, you check twice. First using jdk.tls.disabledAlgorithms on cipher suites etc, and second using jdk.certpath.disabledAlgorithms on certificates. Why is jdk.tls.disabledAlgorithms applied to cert at all? Thanks Max On 10/27/2016 8:30 AM, Wang Weijun wrote: > I don't think this applies to jdk.jar.disabledAlgorithms. While the > private key algorithm and key size are determined by the certificate, I > think they are always checked even if the end-entity cert is trusted > (For example, a trusted self-signed cert). > > Thanks > Max > > On 10/27/2016 8:04 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the simple fix: >> >> http://cr.openjdk.java.net/~xuelei/8168822/webrev/ >> >> Algorithm restrictions do not apply to trusted certs as the >> application or customer has made the decision to trust the "trusted >> cert". However, this point is not explicit for general developers and >> users. We'd better to clarify this point explicitly. >> >> In the update, I add a short note for each algorithm constraint security >> properties: >> >> Note: Algorithm restrictions do not apply to trusted certificates. >> >> Doc only update, no new regression test. >> >> Thanks, >> Xuelei From xuelei.fan at oracle.com Thu Oct 27 00:37:02 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 27 Oct 2016 08:37:02 +0800 Subject: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs In-Reply-To: <743cffb3-fa7b-9915-b355-87972462934a@oracle.com> References: <743cffb3-fa7b-9915-b355-87972462934a@oracle.com> Message-ID: <6e8b3490-2ad5-f359-bd6c-42a3f9f1a552@oracle.com> New webrev: http://cr.openjdk.java.net/~xuelei/8168822/webrev.01/ On 10/27/2016 8:34 AM, Wang Weijun wrote: > One question: I thought for TLS, you check twice. First using > jdk.tls.disabledAlgorithms on cipher suites etc, and second using > jdk.certpath.disabledAlgorithms on certificates. Why is > jdk.tls.disabledAlgorithms applied to cert at all? > jdk.tls.disabledAlgorithms also check certificates used during handshaking, not only cipher suites. > Thanks > Max > > On 10/27/2016 8:30 AM, Wang Weijun wrote: >> I don't think this applies to jdk.jar.disabledAlgorithms. While the >> private key algorithm and key size are determined by the certificate, I >> think they are always checked even if the end-entity cert is trusted >> (For example, a trusted self-signed cert). >> Make sense to me. I removed the update on jdk.jar.disabledAlgorithms. Thanks, Xuelei >> Thanks >> Max >> >> On 10/27/2016 8:04 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the simple fix: >>> >>> http://cr.openjdk.java.net/~xuelei/8168822/webrev/ >>> >>> Algorithm restrictions do not apply to trusted certs as the >>> application or customer has made the decision to trust the "trusted >>> cert". However, this point is not explicit for general developers and >>> users. We'd better to clarify this point explicitly. >>> >>> In the update, I add a short note for each algorithm constraint security >>> properties: >>> >>> Note: Algorithm restrictions do not apply to trusted certificates. >>> >>> Doc only update, no new regression test. >>> >>> Thanks, >>> Xuelei From sha.jiang at oracle.com Thu Oct 27 04:36:40 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 27 Oct 2016 12:36:40 +0800 Subject: RFR[9] JDK-8164595: javax/net/ssl/FixingJavadocs/SSLSessionNulls.java fails intermittently with javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake Message-ID: <9514b33b-e256-d17a-8ed7-e31dbffe8166@oracle.com> 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 xuelei.fan at oracle.com Thu Oct 27 12:50:56 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 27 Oct 2016 20:50:56 +0800 Subject: Code Review Request, JDK-8167680, DTLS implementation bugs In-Reply-To: <12ffdb04-a598-9512-fe17-fa252203cb70@oracle.com> References: <12ffdb04-a598-9512-fe17-fa252203cb70@oracle.com> Message-ID: Updated to handle handle optional CertificateVerify message: http://cr.openjdk.java.net/~xuelei/8167680/webrev.02/ Thanks, Xuelei On 10/21/2016 11:31 AM, Xuelei Fan wrote: > Updated webrev per Jamil's comments: > > http://cr.openjdk.java.net/~xuelei/8167680/webrev.01/ > > Xuelei > > On 10/13/2016 10:36 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the fix for JDK-8167680: >> http://cr.openjdk.java.net/~xuelei/8167680/webrev.00/ >> >> There are a few implementation bugs in JDK. >> >> 1. The sequence number is increased by 2 for GCM cipher suites. >> Both GCM crypto operation and DTLS record use the sequence number. The >> current implementation may increase the sequence number for each of the >> two operations. It is not the expected behavior. >> >> 2. The implementation does not response to handshake retransmissions. >> In the current implementation, receiving of retransmitted handshake >> messages does not kick off a retransmission of the previous delivered >> flight. Retransmission happens on timeout. Timeout is expensive. >> Supporting response to peer retransmitted handshake messages would speed >> up the handshaking. >> >> 3. the final CCC and finished message cannot be retransmitted. >> It is an implementation bug. Every handshake message should be able to >> get retransmitted. >> >> 4. the first application data may be discarded if the last flight get >> lost. >> Applications may send application data immediately after the handshake >> completed. However, the peer may have not receive the handshake >> complete message, and therefor discard the application data. As may >> impact application logic. >> >> For example >> >> Client Server >> .... >> -- ClientKeyExchange --> >> -- ChangeCipherSpec --> >> -- Finished --> >> >> >> X <-- ChangeCipherSpec -- >> X <-- Finished -- >> >> <-- Application Data -- >> >> ----- ... ---> >> -- ClientKeyExchange --> >> -- ChangeCipherSpec --> >> -- Finished --> >> >> <-- ChangeCipherSpec -- >> <-- Finished -- >> >> >> 1. (omit the previous handshake messages) server sends ChangeCipherSpec >> and Finished messages. >> 2. server handshake complete >> 3. server send application >> 4. client does not receive the ChangeCipherSpec or Finished messages. >> 5. client receives the application data. Client cannot handle the >> encrypted message, and may discard it. Client re-transmit the previous >> flight. >> 6. server retransmit the last flight. >> 7. client receives the last flight. >> >> In this update, the last flight will be transmit twice. As may mitigate >> the impact of the issue. >> >> 5. resuming handshaking need no cookie exchange. >> It is an implementation bug. Cookie exchange is performed for >> handshaking resuming now. It is not the expected behavior. >> >> 6. need more debug log for DTLS handshake message fragmentation and >> reassembly. >> >> >> Thanks, >> Xuelei From sean.mullan at oracle.com Thu Oct 27 16:09:30 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Oct 2016 12:09:30 -0400 Subject: RFR: 8167512: Tighten permissions granted to the jdk.crypto.ucrypto module Message-ID: <8057bcc2-2416-e3ec-b747-fd5b53d9d754@oracle.com> Please review this change to tighten or remove unnecessary permissions granted to the jdk.crypto.ucrypto module: https://bugs.openjdk.java.net/browse/JDK-8167512 http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/ Thanks, Sean From vincent.x.ryan at oracle.com Thu Oct 27 16:28:41 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 27 Oct 2016 17:28:41 +0100 Subject: RFR: 8167512: Tighten permissions granted to the jdk.crypto.ucrypto module In-Reply-To: <8057bcc2-2416-e3ec-b747-fd5b53d9d754@oracle.com> References: <8057bcc2-2416-e3ec-b747-fd5b53d9d754@oracle.com> Message-ID: <7D24EE6F-C85B-4946-9286-9695D00AF86C@oracle.com> Your fix looks fine to me Sean. > On 27 Oct 2016, at 17:09, Sean Mullan wrote: > > Please review this change to tighten or remove unnecessary permissions > granted to the jdk.crypto.ucrypto module: > > https://bugs.openjdk.java.net/browse/JDK-8167512 > http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/ > > Thanks, > Sean From sean.mullan at oracle.com Thu Oct 27 17:00:07 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Oct 2016 13:00:07 -0400 Subject: RFR: 8168851: Tighten permissions granted to the java.smartcardio module In-Reply-To: <7D24EE6F-C85B-4946-9286-9695D00AF86C@oracle.com> References: <8057bcc2-2416-e3ec-b747-fd5b53d9d754@oracle.com> <7D24EE6F-C85B-4946-9286-9695D00AF86C@oracle.com> Message-ID: <2b3038dd-f19f-5884-f0bc-1052950d2a1d@oracle.com> I accidentally used the wrong bugid. I have updated the Subject line and links to reflect that this fix is for the java.smartcardio module, not the jdk.crypto.ucrypto module: https://bugs.openjdk.java.net/browse/JDK-8168851 http://cr.openjdk.java.net/~mullan/webrevs/8168851/webrev.00/ --Sean On 10/27/2016 12:28 PM, Vincent Ryan wrote: > Your fix looks fine to me Sean. > > >> On 27 Oct 2016, at 17:09, Sean Mullan wrote: >> >> Please review this change to tighten or remove unnecessary permissions >> granted to the jdk.crypto.ucrypto module: >> >> https://bugs.openjdk.java.net/browse/JDK-8167512 >> http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/ >> >> Thanks, >> Sean > From vincent.x.ryan at oracle.com Thu Oct 27 17:04:11 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 27 Oct 2016 18:04:11 +0100 Subject: RFR: 8168851: Tighten permissions granted to the java.smartcardio module In-Reply-To: <2b3038dd-f19f-5884-f0bc-1052950d2a1d@oracle.com> References: <8057bcc2-2416-e3ec-b747-fd5b53d9d754@oracle.com> <7D24EE6F-C85B-4946-9286-9695D00AF86C@oracle.com> <2b3038dd-f19f-5884-f0bc-1052950d2a1d@oracle.com> Message-ID: <408E422A-491F-495C-A7D5-0FECDF5BC5D8@oracle.com> Your fix still looks fine to me. > On 27 Oct 2016, at 18:00, Sean Mullan wrote: > > I accidentally used the wrong bugid. I have updated the Subject line and links to reflect that this fix is for the java.smartcardio module, not the jdk.crypto.ucrypto module: > > https://bugs.openjdk.java.net/browse/JDK-8168851 > http://cr.openjdk.java.net/~mullan/webrevs/8168851/webrev.00/ > > --Sean > > On 10/27/2016 12:28 PM, Vincent Ryan wrote: >> Your fix looks fine to me Sean. >> >> >>> On 27 Oct 2016, at 17:09, Sean Mullan wrote: >>> >>> Please review this change to tighten or remove unnecessary permissions >>> granted to the jdk.crypto.ucrypto module: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8167512 >>> http://cr.openjdk.java.net/~mullan/webrevs/8167512/webrev.00/ >>> >>> Thanks, >>> Sean >> From mandy.chung at oracle.com Thu Oct 27 17:07:31 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Oct 2016 10:07:31 -0700 Subject: RFR: 8168851: Tighten permissions granted to the java.smartcardio module In-Reply-To: <2b3038dd-f19f-5884-f0bc-1052950d2a1d@oracle.com> References: <8057bcc2-2416-e3ec-b747-fd5b53d9d754@oracle.com> <7D24EE6F-C85B-4946-9286-9695D00AF86C@oracle.com> <2b3038dd-f19f-5884-f0bc-1052950d2a1d@oracle.com> Message-ID: <6BE1E036-B8B0-447F-84DB-558940894BD8@oracle.com> > On Oct 27, 2016, at 10:00 AM, Sean Mullan wrote: > > I accidentally used the wrong bugid. I have updated the Subject line and links to reflect that this fix is for the java.smartcardio module, not the jdk.crypto.ucrypto module: > > https://bugs.openjdk.java.net/browse/JDK-8168851 > http://cr.openjdk.java.net/~mullan/webrevs/8168851/webrev.00/ > +1 Mandy From sean.mullan at oracle.com Thu Oct 27 20:42:27 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Oct 2016 16:42:27 -0400 Subject: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs In-Reply-To: <6e8b3490-2ad5-f359-bd6c-42a3f9f1a552@oracle.com> References: <743cffb3-fa7b-9915-b355-87972462934a@oracle.com> <6e8b3490-2ad5-f359-bd6c-42a3f9f1a552@oracle.com> Message-ID: <0f4a7ca4-87ee-0f1a-c209-8282440143ae@oracle.com> I'm not sure I like the word "trusted". That is too general and fairly subjective. I would say the following: "do not apply to trust anchors or self-signed certificates". --Sean On 10/26/2016 08:37 PM, Xuelei Fan wrote: > New webrev: > http://cr.openjdk.java.net/~xuelei/8168822/webrev.01/ > > On 10/27/2016 8:34 AM, Wang Weijun wrote: >> One question: I thought for TLS, you check twice. First using >> jdk.tls.disabledAlgorithms on cipher suites etc, and second using >> jdk.certpath.disabledAlgorithms on certificates. Why is >> jdk.tls.disabledAlgorithms applied to cert at all? >> > jdk.tls.disabledAlgorithms also check certificates used during > handshaking, not only cipher suites. > >> Thanks >> Max >> >> On 10/27/2016 8:30 AM, Wang Weijun wrote: >>> I don't think this applies to jdk.jar.disabledAlgorithms. While the >>> private key algorithm and key size are determined by the certificate, I >>> think they are always checked even if the end-entity cert is trusted >>> (For example, a trusted self-signed cert). >>> > Make sense to me. I removed the update on jdk.jar.disabledAlgorithms. > > Thanks, > Xuelei > >>> Thanks >>> Max >>> >>> On 10/27/2016 8:04 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the simple fix: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8168822/webrev/ >>>> >>>> Algorithm restrictions do not apply to trusted certs as the >>>> application or customer has made the decision to trust the "trusted >>>> cert". However, this point is not explicit for general developers and >>>> users. We'd better to clarify this point explicitly. >>>> >>>> In the update, I add a short note for each algorithm constraint >>>> security >>>> properties: >>>> >>>> Note: Algorithm restrictions do not apply to trusted certificates. >>>> >>>> Doc only update, no new regression test. >>>> >>>> Thanks, >>>> Xuelei From xuelei.fan at oracle.com Thu Oct 27 22:55:06 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 28 Oct 2016 06:55:06 +0800 Subject: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs In-Reply-To: <0f4a7ca4-87ee-0f1a-c209-8282440143ae@oracle.com> References: <743cffb3-fa7b-9915-b355-87972462934a@oracle.com> <6e8b3490-2ad5-f359-bd6c-42a3f9f1a552@oracle.com> <0f4a7ca4-87ee-0f1a-c209-8282440143ae@oracle.com> Message-ID: <8a42b7d1-87ed-fd0b-5b36-d77b368f6ae7@oracle.com> Hi Sean, Thanks for the review. I will use trust your suggested words. Xuelei On 10/28/2016 4:42 AM, Sean Mullan wrote: > I'm not sure I like the word "trusted". That is too general and fairly > subjective. > > I would say the following: "do not apply to trust anchors or self-signed > certificates". > > --Sean > > On 10/26/2016 08:37 PM, Xuelei Fan wrote: >> New webrev: >> http://cr.openjdk.java.net/~xuelei/8168822/webrev.01/ >> >> On 10/27/2016 8:34 AM, Wang Weijun wrote: >>> One question: I thought for TLS, you check twice. First using >>> jdk.tls.disabledAlgorithms on cipher suites etc, and second using >>> jdk.certpath.disabledAlgorithms on certificates. Why is >>> jdk.tls.disabledAlgorithms applied to cert at all? >>> >> jdk.tls.disabledAlgorithms also check certificates used during >> handshaking, not only cipher suites. >> >>> Thanks >>> Max >>> >>> On 10/27/2016 8:30 AM, Wang Weijun wrote: >>>> I don't think this applies to jdk.jar.disabledAlgorithms. While the >>>> private key algorithm and key size are determined by the certificate, I >>>> think they are always checked even if the end-entity cert is trusted >>>> (For example, a trusted self-signed cert). >>>> >> Make sense to me. I removed the update on jdk.jar.disabledAlgorithms. >> >> Thanks, >> Xuelei >> >>>> Thanks >>>> Max >>>> >>>> On 10/27/2016 8:04 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the simple fix: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8168822/webrev/ >>>>> >>>>> Algorithm restrictions do not apply to trusted certs as the >>>>> application or customer has made the decision to trust the "trusted >>>>> cert". However, this point is not explicit for general developers and >>>>> users. We'd better to clarify this point explicitly. >>>>> >>>>> In the update, I add a short note for each algorithm constraint >>>>> security >>>>> properties: >>>>> >>>>> Note: Algorithm restrictions do not apply to trusted certificates. >>>>> >>>>> Doc only update, no new regression test. >>>>> >>>>> Thanks, >>>>> Xuelei From bradford.wetmore at oracle.com Fri Oct 28 19:06:50 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 28 Oct 2016 12:06:50 -0700 Subject: RFR: 4985694: Incomplete spec for most of the getInstances Message-ID: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> 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 artem.smotrakov at oracle.com Fri Oct 28 20:26:12 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 28 Oct 2016 13:26:12 -0700 Subject: Code Review Request, JDK-8167680, DTLS implementation bugs In-Reply-To: References: <12ffdb04-a598-9512-fe17-fa252203cb70@oracle.com> Message-ID: <215e6814-aca2-c333-e146-3f83eace7b62@oracle.com> Hi Xuelei, Looks good to me. Artem On 10/27/2016 05:50 AM, Xuelei Fan wrote: > Updated to handle handle optional CertificateVerify message: > > http://cr.openjdk.java.net/~xuelei/8167680/webrev.02/ > > Thanks, > Xuelei > > On 10/21/2016 11:31 AM, Xuelei Fan wrote: >> Updated webrev per Jamil's comments: >> >> http://cr.openjdk.java.net/~xuelei/8167680/webrev.01/ >> >> Xuelei >> >> On 10/13/2016 10:36 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the fix for JDK-8167680: >>> http://cr.openjdk.java.net/~xuelei/8167680/webrev.00/ >>> >>> There are a few implementation bugs in JDK. >>> >>> 1. The sequence number is increased by 2 for GCM cipher suites. >>> Both GCM crypto operation and DTLS record use the sequence number. The >>> current implementation may increase the sequence number for each of the >>> two operations. It is not the expected behavior. >>> >>> 2. The implementation does not response to handshake retransmissions. >>> In the current implementation, receiving of retransmitted handshake >>> messages does not kick off a retransmission of the previous delivered >>> flight. Retransmission happens on timeout. Timeout is expensive. >>> Supporting response to peer retransmitted handshake messages would >>> speed >>> up the handshaking. >>> >>> 3. the final CCC and finished message cannot be retransmitted. >>> It is an implementation bug. Every handshake message should be able to >>> get retransmitted. >>> >>> 4. the first application data may be discarded if the last flight get >>> lost. >>> Applications may send application data immediately after the handshake >>> completed. However, the peer may have not receive the handshake >>> complete message, and therefor discard the application data. As may >>> impact application logic. >>> >>> For example >>> >>> Client Server >>> .... >>> -- ClientKeyExchange --> >>> -- ChangeCipherSpec --> >>> -- Finished --> >>> >>> >>> X <-- ChangeCipherSpec -- >>> X <-- Finished -- >>> >>> <-- Application Data -- >>> >>> ----- ... ---> >>> -- ClientKeyExchange --> >>> -- ChangeCipherSpec --> >>> -- Finished --> >>> >>> <-- ChangeCipherSpec -- >>> <-- Finished -- >>> >>> >>> 1. (omit the previous handshake messages) server sends ChangeCipherSpec >>> and Finished messages. >>> 2. server handshake complete >>> 3. server send application >>> 4. client does not receive the ChangeCipherSpec or Finished messages. >>> 5. client receives the application data. Client cannot handle the >>> encrypted message, and may discard it. Client re-transmit the previous >>> flight. >>> 6. server retransmit the last flight. >>> 7. client receives the last flight. >>> >>> In this update, the last flight will be transmit twice. As may >>> mitigate >>> the impact of the issue. >>> >>> 5. resuming handshaking need no cookie exchange. >>> It is an implementation bug. Cookie exchange is performed for >>> handshaking resuming now. It is not the expected behavior. >>> >>> 6. need more debug log for DTLS handshake message fragmentation and >>> reassembly. >>> >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Sat Oct 29 00:13:51 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 29 Oct 2016 08:13:51 +0800 Subject: RFR: 4985694: Incomplete spec for most of the getInstances In-Reply-To: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> References: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> Message-ID: 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 bradford.wetmore at oracle.com Sat Oct 29 00:17:22 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 28 Oct 2016 17:17:22 -0700 Subject: RFR: 4985694: Incomplete spec for most of the getInstances In-Reply-To: References: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> Message-ID: 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 weijun.wang at oracle.com Sun Oct 30 08:37:44 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 30 Oct 2016 16:37:44 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: <10640b69-863b-c652-de3f-a20548c26dc5@oracle.com> References: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> <8f9a2843-ac15-4ddf-b8a1-175d415bc102@oracle.com> <10640b69-863b-c652-de3f-a20548c26dc5@oracle.com> Message-ID: <74C3EB55-2023-44E8-85D3-AE6D975C25EA@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8168518/webrev.02/ The only change in src/ is the system property name from "jdk.krb5.rcache.usemd5" to "jdk.krb5.rcache.useMD5". Test enhanced, now I can launch the test like jtreg -javacoption:-XDignore.symbol.file \ -javacoption:-source -javacoption:8 \ -javacoption:-target -javacoption:8 \ -Dtest.libs=J,N,J9=$J9/bin/java,J8=$J8/bin/java,N14=/krb5-1.14.4/build/lib/libgssapi_krb5.dylib,N15=/krb5-1.15-beta1/build/lib/libgssapi_krb5.dylib \ -Dtest.runs \ test/sun/security/krb5/auto/ReplayCacheTestProc.java to test interop between all possibilities. I need to stop spending more time on this one. Thanks Max From sean.mullan at oracle.com Sun Oct 30 17:56:31 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 30 Oct 2016 13:56:31 -0400 Subject: RFR: 4985694: Incomplete spec for most of the getInstances In-Reply-To: References: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> Message-ID: <6587c593-466f-d681-5880-6cb6ccd00584@oracle.com> 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 xuelei.fan at oracle.com Mon Oct 31 00:23:25 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 31 Oct 2016 08:23:25 +0800 Subject: RFR 8168518: rcache interop with krb5-1.15 In-Reply-To: <74C3EB55-2023-44E8-85D3-AE6D975C25EA@oracle.com> References: <395755a6-6219-c133-55f6-d335502caf1e@oracle.com> <8f9a2843-ac15-4ddf-b8a1-175d415bc102@oracle.com> <10640b69-863b-c652-de3f-a20548c26dc5@oracle.com> <74C3EB55-2023-44E8-85D3-AE6D975C25EA@oracle.com> Message-ID: Looks fine to me. Xuelei On 10/30/2016 4:37 PM, Wang Weijun wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8168518/webrev.02/ > > The only change in src/ is the system property name from "jdk.krb5.rcache.usemd5" to "jdk.krb5.rcache.useMD5". > > Test enhanced, now I can launch the test like > > jtreg -javacoption:-XDignore.symbol.file \ > -javacoption:-source -javacoption:8 \ > -javacoption:-target -javacoption:8 \ > -Dtest.libs=J,N,J9=$J9/bin/java,J8=$J8/bin/java,N14=/krb5-1.14.4/build/lib/libgssapi_krb5.dylib,N15=/krb5-1.15-beta1/build/lib/libgssapi_krb5.dylib \ > -Dtest.runs \ > test/sun/security/krb5/auto/ReplayCacheTestProc.java > > to test interop between all possibilities. > > I need to stop spending more time on this one. > > Thanks > Max > From bradford.wetmore at oracle.com Mon Oct 31 21:19:01 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 31 Oct 2016 14:19:01 -0700 Subject: RFR: 4985694: Incomplete spec for most of the getInstances In-Reply-To: <6587c593-466f-d681-5880-6cb6ccd00584@oracle.com> References: <0294489c-a45f-a2d5-06eb-92722e71315f@oracle.com> <6587c593-466f-d681-5880-6cb6ccd00584@oracle.com> Message-ID: <12091979-f821-1ace-829b-dcce2cd6133b@oracle.com> 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 veniyer at cisco.com Wed Oct 12 19:38:41 2016 From: veniyer at cisco.com (Venkat Iyer (veniyer)) Date: Wed, 12 Oct 2016 19:38:41 -0000 Subject: Windows LSA cache and Kerberos delegation Message-ID: Do you know if the problem of obtaining TGT session key on Windows from LSA credential cache is resolved (see snippet below)? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jurrian.fahner at gmail.com Sat Oct 29 15:08:44 2016 From: jurrian.fahner at gmail.com (Jurrian Fahner) Date: Sat, 29 Oct 2016 15:08:44 +0000 Subject: Updates to documentation for JEP 287 Message-ID: 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: