From sha.jiang at oracle.com Wed May 1 01:24:36 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 1 May 2019 09:24:36 +0800 Subject: RFR[13] JDK-8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: <43c5e7ea-e459-9399-4d1b-f3d62dfc255d@oracle.com> References: <43c5e7ea-e459-9399-4d1b-f3d62dfc255d@oracle.com> Message-ID: Hi Valeria, On 2019/5/1 04:25, Valerie Peng wrote: > Looks fine to me. Thanks for your review! With further testing, sun/security/tools/keytool/NssTest.java may fail due to some dependencies are not found. But this failure should not be related to this NSS libs upgrade, because it could also raise without this fix. So, just loading the dependencies explicitly. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8204203/webrev.01/ > > Just curious, how do we see the changes on the artifactory side? Please search the below files in our Artifactory. nsslib-macosx_x64-3.41.zip nsslib-windows_x64-3.41-VS2017.zip nsslib-windows_x86-3.41-VS2017.zip Best regards, John Jiang > > Valerie > > On 4/23/2019 7:39 PM, sha.jiang at oracle.com wrote: >> Hi, >> NSS 3.41 has been approved, so just build this version for windows >> (with VS2017) and macosx. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8204203/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8204203 >> >> Best regards, >> John Jiang >> > From christoph.langer at sap.com Wed May 1 13:09:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 1 May 2019 13:09:53 +0000 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate In-Reply-To: <1ed9610c-8a81-9c5d-f261-2056f617003b@oracle.com> References: <1ed9610c-8a81-9c5d-f261-2056f617003b@oracle.com> Message-ID: Thank you, Rajan. From: Rajan Halade Sent: Dienstag, 30. April 2019 20:08 To: Langer, Christoph Cc: security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Sean Mullan Subject: Re: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate Thanks Christoph for this. I have pushed fix to jdk/jdk repository. - Rajan On 4/29/19 12:31 AM, Langer, Christoph wrote: Hi, the change to add GlobalSign's R6 Root certificate has only been pushed to jdk12 updates (12.0.1) so far. According to [0], it was an oversight to not have it added to jdk/jdk. I also want to bring it to 11u. Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not apply cleanly. test/jdk/sun/security/lib/cacerts/VerifyCACerts.java fails to resolve because of changed license header and different bug ids in the @bug tag. So, please review the resolved change. It's the same for both repos. Webrev jdk/jdk: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk/ Webrev jdk11u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk11u-dev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216577 Please review. @Rajan Halade: please let me know whether I shall push it to jdk/jdk or feel free to do it yourself. Thanks & Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019766.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed May 1 13:19:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 1 May 2019 13:19:10 +0000 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> Message-ID: Hi Rajan, I?ll take this to jdk11 updates. What about jdk12 updates? I can process both releases, if you want. Best regards Christoph From: security-dev On Behalf Of Rajan Halade Sent: Dienstag, 30. April 2019 20:39 To: Sean Mullan ; security-dev Subject: RFR: 8222137: Remove T-Systems root CA certificate Please review this fix for removal of T-Systems Deutsche Telekom Root CA 2 certificate. Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Wed May 1 14:14:21 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 01 May 2019 16:14:21 +0200 Subject: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: References: <1550666474.2433.13.camel@paratix.ch> <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> <1556603804.2432.11.camel@paratix.ch> Message-ID: <1556720061.2432.25.camel@paratix.ch> Hi Max and everyone, With respect to the previous patch, parentheses moved from storeHash to printCert, bug number added, and some comments added and clarified. Regards,Philipp On Tue, 2019-04-30 at 14:45 +0800, Weijun Wang wrote: > > On Apr 30, 2019, at 1:56 PM, Philipp Kunz > > wrote: > > > > Hi Max, > > > > I agree that the parentheses are superfluous, however, I would > > slightly prefer going small steps. > > > > Would the parentheses have to come from a resource bundle as well > > like SPACE or COMMA when removed from storeHash values? > > No. It's hardcoded and not localized in printCert. > > > Now that with the patch, storeHash is not any longer useful to > > check whether it contains ckaliases in inKeyStoreForOneSigner (but > > currently still useful to save another call to > > store.getCertificateAlias in printCert lateron), would it be a > > worth a consideration to rearrange the code populating storeHash > > closer to printCert in some way or even just completely remove > > storeHash and replace it with store.getCertificateAlias in > > printCert or anything similar? > > Probably not. I believe storeHash was introduced to avoid too many > calls to store.getCertificateAlias when there are hundreds of classes > in a signed jar.? > > --Max > > > Regards, > > Philipp > > > > > > > > > > > > On Sat, 2019-03-30 at 23:01 +0800, Weijun Wang wrote: > > > Hi Philipp, > > > > > > Sorry I'm so late giving a response. I've filed > > > > > > ??? > > > https://bugs.openjdk.java.net/browse/JDK-8221719 > > > > > > ???Jarsigner Fails To Verify Signed By Alias If Alias Given In > > > Wrong Case > > > > > > The fix is good. Since we don't support identitydb anymore I > > > think we can remove the parenthesis around the alias in the > > > storeHash now. > > > > > > Thanks, > > > Max > > > > > > > > > > On Feb 20, 2019, at 8:41 PM, Philipp Kunz < > > > > philipp.kunz at paratix.ch > > > > > wrote: > > > > > > > > Hi, > > > > > > > > When signing a jarfile the specified alias is converted by > > > > JavaKeyStore (storetype JKS) to lower case. > > > > When verifying the jarfile with the same alias, it is currently > > > > not converted by JKS to lower case and jarsigner reports that > > > > the jar is not signed by the alias even after having just > > > > signed it with that same alias if not all characters are in > > > > lower case. > > > > > > > > I found no statement in the documentation that an alias would > > > > support only lower case or which characters could be used. It > > > > could, however, be worth noting in the documentation of > > > > JavaKeyStore or the keytool that the alias can be changed by > > > > the keystore in certain circumstances. > > > > In my opinion, it feels like a bug that aliases are treated > > > > differently when signing and verifying with respect to their > > > > upper and lower case. > > > > > > > > Find a patch attached. Some explanations, just in case not too > > > > obvious anyway: > > > > > > > > - The jarsigner never changed the upper and lower cases of > > > > aliases itself and neither does with the patch. That is now > > > > delegated to the keystore implementation not only for signing > > > > but in addition also for verifying. The fix is therefore not > > > > JSK-specific. > > > > - I assume it is correct that the if (store != null) check and > > > > the try catch KeyStoreException can both be moved outside the > > > > for loop over the certificates because before as well as now > > > > with the patch the result was alway 0 if store was null and > > > > KeyStoreException can happen only when loading the keystore, > > > > which is certainly true for JKS. > > > > - storeHash is used only by printCert and > > > > inKeyStoreForOneSigner and contains the aliases as values > > > > enclosed in parentheses "(" and ")" which is how it is printed > > > > by printCert. It would have probably been easier to add the > > > > parentheses only later in printCert but then I tried to change > > > > as little as possible. > > > > - Two pairs of "result |= " statements were duplicate. > > > > Therefore there are the two methods in the test which show that > > > > both actually failed with "ckaliases.contains" being the > > > > offending piece of code. In the patch I refactored to recombine > > > > them. > > > > - I really wonder how "result |= SIGNED_BY_ALIAS;" should be > > > > set for any certificate c and not only the one an alias in > > > > ckaliases points at but I guess that is another story if one at > > > > all and might have come from filling storeHash with all > > > > certificates and not only the ones in ckaliases or so. > > > > - At first glance it might look like a mistake that "alias" is > > > > not used inside the loop over ckaliases but instead of > > > > comparing "alias" in lower case to ckaliases with unspecified > > > > case, the certificate c is now compared to the one gotten from > > > > the keystore handling the alias case in its own way. > > > > > > > > Would someone sponsor this fix or can/should it be improved? > > > > > > > > Regards, > > > > Philipp > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20190501-JavaKeyStoreAliasCaseInsensitive.patch Type: text/x-patch Size: 10737 bytes Desc: not available URL: From weijun.wang at oracle.com Wed May 1 15:20:58 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 May 2019 23:20:58 +0800 Subject: RFR 8223063: Support CNG RSA keys In-Reply-To: References: Message-ID: It looks the Mach5 machines are Windows Server 2012 but mine is 2019. I removed the "-f" option and everything looks fine now. --Max > On May 1, 2019, at 7:18 AM, Weijun Wang wrote: > > Please take a look at > > https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ > > Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with > > Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] > A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 > A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 > CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) > CertUtil: The requested operation is not supported. > > Maybe there is a permission issue. > > I'll study it for more, but If anyone of you can fix it I'll be very happy. > > Thanks, > Max > From rajan.halade at oracle.com Wed May 1 19:07:43 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 1 May 2019 12:07:43 -0700 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> Message-ID: <682255ff-08d3-4856-758f-1fb68ec13ea1@oracle.com> I have created needed backports including 12-pool, 11-pool, 8-pool, and 7-pool. These are assigned to Sean C. for now. Please co-ordinate with him. Thanks, Rajan On 5/1/19 6:19 AM, Langer, Christoph wrote: > > Hi Rajan, > > I?ll take this to jdk11 updates. What about jdk12 updates? I can > process both releases, if you want. > > Best regards > > Christoph > > *From:*security-dev *On Behalf > Of *Rajan Halade > *Sent:* Dienstag, 30. April 2019 20:39 > *To:* Sean Mullan ; security-dev > > *Subject:* RFR: 8222137: Remove T-Systems root CA certificate > > Please review this fix for removal of T-Systems Deutsche Telekom Root > CA 2 certificate. > > Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ > > Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 > > Thanks, > Rajan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Wed May 1 20:09:33 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 1 May 2019 20:09:33 +0000 Subject: RFR 8223063: Support CNG RSA keys In-Reply-To: References: , Message-ID: Max, would it make sense to specify ` -csp "Microsoft Software Key Storage Provider"` to make sure it stores the key in a CNG KSP? (I am not sure what the default provider is). Also maybe make the key non-exportable to make sure key-handles are actually used for the operations? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Weijun Wang Gesendet: Mittwoch, Mai 1, 2019 7:21 PM An: security-dev at openjdk.java.net Betreff: Re: RFR 8223063: Support CNG RSA keys It looks the Mach5 machines are Windows Server 2012 but mine is 2019. I removed the "-f" option and everything looks fine now. --Max > On May 1, 2019, at 7:18 AM, Weijun Wang wrote: > > Please take a look at > > https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ > > Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with > > Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] > A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 > A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 > CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) > CertUtil: The requested operation is not supported. > > Maybe there is a permission issue. > > I'll study it for more, but If anyone of you can fix it I'll be very happy. > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu May 2 07:48:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 May 2019 07:48:28 +0000 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: <682255ff-08d3-4856-758f-1fb68ec13ea1@oracle.com> References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> <682255ff-08d3-4856-758f-1fb68ec13ea1@oracle.com> Message-ID: Thanks, Raj. Hi Se?n, since there is an 11-pool request, I guess you should push the change to some 11.o.-oracle repository first such that you?ll get this item resolved by hgupdater. Please let me know how to proceed. Thanks Christoph From: Rajan Halade Sent: Mittwoch, 1. Mai 2019 21:08 To: Langer, Christoph Cc: Sean Mullan ; security-dev ; Se?n Coffey Subject: Re: RFR: 8222137: Remove T-Systems root CA certificate I have created needed backports including 12-pool, 11-pool, 8-pool, and 7-pool. These are assigned to Sean C. for now. Please co-ordinate with him. Thanks, Rajan On 5/1/19 6:19 AM, Langer, Christoph wrote: Hi Rajan, I?ll take this to jdk11 updates. What about jdk12 updates? I can process both releases, if you want. Best regards Christoph From: security-dev On Behalf Of Rajan Halade Sent: Dienstag, 30. April 2019 20:39 To: Sean Mullan ; security-dev Subject: RFR: 8222137: Remove T-Systems root CA certificate Please review this fix for removal of T-Systems Deutsche Telekom Root CA 2 certificate. Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu May 2 08:24:47 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 May 2019 09:24:47 +0100 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> <682255ff-08d3-4856-758f-1fb68ec13ea1@oracle.com> Message-ID: <4eb3cc4b-9d5a-72e3-a6fb-d29e4d607975@oracle.com> Christoph, if possible, can you create an "11.0.4" fixVersion backport before pushing your changeset? That will help with JBS records. Alternatively, I'll just ensure there's an 11-pool or 11.0.5 record before I push. regards, Sean. On 02/05/2019 08:48, Langer, Christoph wrote: > > Thanks, Raj. > > Hi Se?n, > > since there is an 11-pool request, I guess you should push the change > to some 11.o.-oracle repository first such that you?ll get this > item resolved by hgupdater. Please let me know how to proceed. > > Thanks > > Christoph > > *From:*Rajan Halade > *Sent:* Mittwoch, 1. Mai 2019 21:08 > *To:* Langer, Christoph > *Cc:* Sean Mullan ; security-dev > ; Se?n Coffey > *Subject:* Re: RFR: 8222137: Remove T-Systems root CA certificate > > I have created needed backports including 12-pool, 11-pool, 8-pool, > and 7-pool. These are assigned to Sean C. for now. Please co-ordinate > with him. > > Thanks, > Rajan > > On 5/1/19 6:19 AM, Langer, Christoph wrote: > > Hi Rajan, > > I?ll take this to jdk11 updates. What about jdk12 updates? I can > process both releases, if you want. > > Best regards > > Christoph > > *From:*security-dev > *On Behalf Of > *Rajan Halade > *Sent:* Dienstag, 30. April 2019 20:39 > *To:* Sean Mullan > ; security-dev > > *Subject:* RFR: 8222137: Remove T-Systems root CA certificate > > Please review this fix for removal of T-Systems Deutsche Telekom > Root CA 2 certificate. > > Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ > > Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 > > Thanks, > Rajan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu May 2 08:27:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 May 2019 08:27:11 +0000 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: <4eb3cc4b-9d5a-72e3-a6fb-d29e4d607975@oracle.com> References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> <682255ff-08d3-4856-758f-1fb68ec13ea1@oracle.com> <4eb3cc4b-9d5a-72e3-a6fb-d29e4d607975@oracle.com> Message-ID: Hi Sean, sounds good. I?ll create an 11.0.4 bug before pushing to jkd11u-dev. I assume you?ll take care of jdk12u? Thanks Christoph From: Se?n Coffey Sent: Donnerstag, 2. Mai 2019 10:25 To: Langer, Christoph Cc: Rajan Halade ; Sean Mullan ; security-dev Subject: Re: RFR: 8222137: Remove T-Systems root CA certificate Christoph, if possible, can you create an "11.0.4" fixVersion backport before pushing your changeset? That will help with JBS records. Alternatively, I'll just ensure there's an 11-pool or 11.0.5 record before I push. regards, Sean. On 02/05/2019 08:48, Langer, Christoph wrote: Thanks, Raj. Hi Se?n, since there is an 11-pool request, I guess you should push the change to some 11.o.-oracle repository first such that you?ll get this item resolved by hgupdater. Please let me know how to proceed. Thanks Christoph From: Rajan Halade Sent: Mittwoch, 1. Mai 2019 21:08 To: Langer, Christoph Cc: Sean Mullan ; security-dev ; Se?n Coffey Subject: Re: RFR: 8222137: Remove T-Systems root CA certificate I have created needed backports including 12-pool, 11-pool, 8-pool, and 7-pool. These are assigned to Sean C. for now. Please co-ordinate with him. Thanks, Rajan On 5/1/19 6:19 AM, Langer, Christoph wrote: Hi Rajan, I?ll take this to jdk11 updates. What about jdk12 updates? I can process both releases, if you want. Best regards Christoph From: security-dev On Behalf Of Rajan Halade Sent: Dienstag, 30. April 2019 20:39 To: Sean Mullan ; security-dev Subject: RFR: 8222137: Remove T-Systems root CA certificate Please review this fix for removal of T-Systems Deutsche Telekom Root CA 2 certificate. Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu May 2 08:29:29 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 2 May 2019 09:29:29 +0100 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> <682255ff-08d3-4856-758f-1fb68ec13ea1@oracle.com> <4eb3cc4b-9d5a-72e3-a6fb-d29e4d607975@oracle.com> Message-ID: On 02/05/2019 09:27, Langer, Christoph wrote: > > Hi Sean, > > sounds good. I?ll create an 11.0.4 bug before pushing to jkd11u-dev. > > I assume you?ll take care of jdk12u? > Sure - I'm happy to push 12u. I'll add the necessary request label shortly. regards, Sean. > Thanks > > Christoph > > *From:*Se?n Coffey > *Sent:* Donnerstag, 2. Mai 2019 10:25 > *To:* Langer, Christoph > *Cc:* Rajan Halade ; Sean Mullan > ; security-dev > *Subject:* Re: RFR: 8222137: Remove T-Systems root CA certificate > > Christoph, > > if possible, can you create an "11.0.4" fixVersion backport before > pushing your changeset? That will help with JBS records. > Alternatively, I'll just ensure there's an 11-pool or 11.0.5 record > before I push. > > regards, > Sean. > > On 02/05/2019 08:48, Langer, Christoph wrote: > > Thanks, Raj. > > Hi Se?n, > > since there is an 11-pool request, I guess you should push the > change to some 11.o.-oracle repository first such that you?ll > get this item resolved by hgupdater. Please let me know how to > proceed. > > Thanks > > Christoph > > *From:*Rajan Halade > > *Sent:* Mittwoch, 1. Mai 2019 21:08 > *To:* Langer, Christoph > > *Cc:* Sean Mullan > ; security-dev > > ; Se?n Coffey > > *Subject:* Re: RFR: 8222137: Remove T-Systems root CA certificate > > I have created needed backports including 12-pool, 11-pool, > 8-pool, and 7-pool. These are assigned to Sean C. for now. Please > co-ordinate with him. > > Thanks, > Rajan > > On 5/1/19 6:19 AM, Langer, Christoph wrote: > > Hi Rajan, > > I?ll take this to jdk11 updates. What about jdk12 updates? I > can process both releases, if you want. > > Best regards > > Christoph > > *From:*security-dev > *On Behalf Of > *Rajan Halade > *Sent:* Dienstag, 30. April 2019 20:39 > *To:* Sean Mullan > ; security-dev > > > *Subject:* RFR: 8222137: Remove T-Systems root CA certificate > > Please review this fix for removal of T-Systems Deutsche > Telekom Root CA 2 certificate. > > Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ > > Release note is at - > https://bugs.openjdk.java.net/browse/JDK-8223161 > > Thanks, > Rajan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu May 2 12:55:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 May 2019 12:55:25 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Message-ID: Hi, as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: 8191844: Remove SECOM root (secomevrootca1) 8189949: Remove Baltimore Cybertrust Code Signing CA 8191031: Remove several Symantec Root CAs 8196141: Add GoDaddy root certificates 8204923: Restore Symantec root verisignclass2g2ca 8195774: Add Entrust root certificates 8199779: Add T-Systems, GlobalSign and Starfield services root certificates 8209506: Add Google Trust Services GlobalSign root certificates 8210432: Add additional TeliaSonera root certificate 8195793: Remove GTE CyberTrust Global Root 8216577: Add GlobalSign's R6 Root certificate 8222137: Remove T-Systems root CA certificate Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. To make the test run in JDK8, I had to a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html [2] https://bugs.openjdk.java.net/browse/JDK-8189131 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu May 2 20:11:39 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 2 May 2019 13:11:39 -0700 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl Message-ID: Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8219991/webrev.00/ The March5 test looks good, and the external test described in JDK-8219658 passed. No new regression test. Thanks, Xuelei From valerie.peng at oracle.com Fri May 3 01:19:52 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 2 May 2019 18:19:52 -0700 Subject: RFR[13] JDK-8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: <43c5e7ea-e459-9399-4d1b-f3d62dfc255d@oracle.com> Message-ID: <4c0a0256-9fde-b2ad-a6c2-f3309d2e77d9@oracle.com> Updated webrev looks good. Thanks, Valerie On 4/30/2019 6:24 PM, sha.jiang at oracle.com wrote: > Hi Valeria, > > On 2019/5/1 04:25, Valerie Peng wrote: >> Looks fine to me. > Thanks for your review! > > With further testing, sun/security/tools/keytool/NssTest.java may fail > due to some dependencies are not found. > But this failure should not be related to this NSS libs upgrade, > because it could also raise without this fix. > So, just loading the dependencies explicitly. > Please review the updated webrev: > http://cr.openjdk.java.net/~jjiang/8204203/webrev.01/ > >> >> Just curious, how do we see the changes on the artifactory side? > > Please search the below files in our Artifactory. > nsslib-macosx_x64-3.41.zip > nsslib-windows_x64-3.41-VS2017.zip > nsslib-windows_x86-3.41-VS2017.zip > > Best regards, > John Jiang > >> >> Valerie >> >> On 4/23/2019 7:39 PM, sha.jiang at oracle.com wrote: >>> Hi, >>> NSS 3.41 has been approved, so just build this version for windows >>> (with VS2017) and macosx. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8204203/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8204203 >>> >>> Best regards, >>> John Jiang >>> >> From daniel.fuchs at oracle.com Fri May 3 11:11:10 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 3 May 2019 12:11:10 +0100 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: References: Message-ID: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> Hi Xuelei, I believe there is still a small window of opportunity for which `readLockedDeplete();` will never be called. The issue is in `deplete()`: If tryLock() fails to lock at line 1046 if (readLock.tryLock()) { then there's no guarantee that the reading thread will not release the readLock before the else { } statement is executed at line: 1054 isClosing = true; Thread 1: enters `read`, locks `readLock` Thread 2: enters `deplete`, fails to lock Thread 1: finishes reading, find `isClosing` is false, releases `readLock`. Thread 2: `deplete` sets `isClosing` to true and returns then any further call to `read` will find `isClosing == true` and return EOF. If that happens and I'm not mistaken, then `readLockedDeplete();` will never be called. best regards, -- daniel On 02/05/2019 21:11, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > ?? http://cr.openjdk.java.net/~xuelei/8219991/webrev.00/ > > The March5 test looks good, and the external test described in > JDK-8219658 passed.? No new regression test. > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri May 3 13:03:00 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 May 2019 06:03:00 -0700 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> Message-ID: <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> Hi Daniel, Good catch! Here is a new webrev that's trying to address the problem. http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ The isClosing field update is moving ahead, and a new filed hasDepleted was added for threads competition. The external test described in JDK-8219658 passed, and the regressing testing jobs are still in progress. I will update if there is a surprise in the regression testing. Thanks, Xuelei On 5/3/2019 4:11 AM, Daniel Fuchs wrote: > Hi Xuelei, > > I believe there is still a small window of opportunity > for which `readLockedDeplete();` will never be called. > > The issue is in `deplete()`: > > If tryLock() fails to lock at line > 1046???????????? if (readLock.tryLock()) { > then there's no guarantee that the reading > thread will not release the readLock before > the else { } statement is executed at line: > 1054???????????????? isClosing = true; > > Thread 1:? enters `read`, locks `readLock` > Thread 2:? enters `deplete`, fails to lock > Thread 1:? finishes reading, find `isClosing` is false, > ?????????? releases `readLock`. > Thread 2:? `deplete` sets `isClosing` to true and returns > > then any further call to `read` will find `isClosing == true` > and return EOF. > > If that happens and I'm not mistaken, then > `readLockedDeplete();` will never be called. > > best regards, > > -- daniel > > > > On 02/05/2019 21:11, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.00/ >> >> The March5 test looks good, and the external test described in >> JDK-8219658 passed.? No new regression test. >> >> Thanks, >> Xuelei > From daniel.fuchs at oracle.com Fri May 3 13:45:48 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 3 May 2019 14:45:48 +0100 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> Message-ID: Hi Xuelei, I agree this should fix the issue I was speaking of. Looks good to me - but maybe you'll want a second reviewer from the security-dev team :-) best regards, -- daniel On 03/05/2019 14:03, Xuelei Fan wrote: > Hi Daniel, > > Good catch! > > Here is a new webrev that's trying to address the problem. > ? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ > > The isClosing field update is moving ahead, and a new filed hasDepleted > was added for threads competition. > > The external test described in JDK-8219658 passed, and the regressing > testing jobs are still in progress.? I will update if there is a > surprise in the regression testing. > > Thanks, > Xuelei > > On 5/3/2019 4:11 AM, Daniel Fuchs wrote: >> Hi Xuelei, >> >> I believe there is still a small window of opportunity >> for which `readLockedDeplete();` will never be called. >> >> The issue is in `deplete()`: >> >> If tryLock() fails to lock at line >> 1046???????????? if (readLock.tryLock()) { >> then there's no guarantee that the reading >> thread will not release the readLock before >> the else { } statement is executed at line: >> 1054???????????????? isClosing = true; >> >> Thread 1:? enters `read`, locks `readLock` >> Thread 2:? enters `deplete`, fails to lock >> Thread 1:? finishes reading, find `isClosing` is false, >> ??????????? releases `readLock`. >> Thread 2:? `deplete` sets `isClosing` to true and returns >> >> then any further call to `read` will find `isClosing == true` >> and return EOF. >> >> If that happens and I'm not mistaken, then >> `readLockedDeplete();` will never be called. >> >> best regards, >> >> -- daniel >> >> >> >> On 02/05/2019 21:11, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed? >>> >>> ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.00/ >>> >>> The March5 test looks good, and the external test described in >>> JDK-8219658 passed.? No new regression test. >>> >>> Thanks, >>> Xuelei >> From xuelei.fan at oracle.com Sat May 4 01:23:38 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 May 2019 18:23:38 -0700 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> Message-ID: <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> Hi, There is a surprise in the regression test. I made the update, and now the testing passed. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ Thanks, Xuelei On 5/3/2019 6:45 AM, Daniel Fuchs wrote: > Hi Xuelei, > > I agree this should fix the issue I was speaking of. > Looks good to me - but maybe you'll want a second > reviewer from the security-dev team :-) > > best regards, > > -- daniel > > On 03/05/2019 14:03, Xuelei Fan wrote: >> Hi Daniel, >> >> Good catch! >> >> Here is a new webrev that's trying to address the problem. >> ?? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ >> >> The isClosing field update is moving ahead, and a new filed >> hasDepleted was added for threads competition. >> >> The external test described in JDK-8219658 passed, and the regressing >> testing jobs are still in progress.? I will update if there is a >> surprise in the regression testing. >> >> Thanks, >> Xuelei >> >> On 5/3/2019 4:11 AM, Daniel Fuchs wrote: >>> Hi Xuelei, >>> >>> I believe there is still a small window of opportunity >>> for which `readLockedDeplete();` will never be called. >>> >>> The issue is in `deplete()`: >>> >>> If tryLock() fails to lock at line >>> 1046???????????? if (readLock.tryLock()) { >>> then there's no guarantee that the reading >>> thread will not release the readLock before >>> the else { } statement is executed at line: >>> 1054???????????????? isClosing = true; >>> >>> Thread 1:? enters `read`, locks `readLock` >>> Thread 2:? enters `deplete`, fails to lock >>> Thread 1:? finishes reading, find `isClosing` is false, >>> ??????????? releases `readLock`. >>> Thread 2:? `deplete` sets `isClosing` to true and returns >>> >>> then any further call to `read` will find `isClosing == true` >>> and return EOF. >>> >>> If that happens and I'm not mistaken, then >>> `readLockedDeplete();` will never be called. >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> >>> On 02/05/2019 21:11, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Could I get the following update reviewed? >>>> >>>> ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.00/ >>>> >>>> The March5 test looks good, and the external test described in >>>> JDK-8219658 passed.? No new regression test. >>>> >>>> Thanks, >>>> Xuelei >>> > From xuelei.fan at oracle.com Sat May 4 01:24:55 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 May 2019 18:24:55 -0700 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> Message-ID: <04134ad6-a04f-43ef-c1af-d428f8ea85f9@oracle.com> Oops, forgot to update the link of the webrev. It should be: http://cr.openjdk.java.net/~xuelei/8219991/webrev.02/ Xuelei On 5/3/2019 6:23 PM, Xuelei Fan wrote: > Hi, > > There is a surprise in the regression test.? I made the update, and now > the testing passed.? Here is the new webrev: > ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ http://cr.openjdk.java.net/~xuelei/8219991/webrev.02/ > > Thanks, > Xuelei > > On 5/3/2019 6:45 AM, Daniel Fuchs wrote: >> Hi Xuelei, >> >> I agree this should fix the issue I was speaking of. >> Looks good to me - but maybe you'll want a second >> reviewer from the security-dev team :-) >> >> best regards, >> >> -- daniel >> >> On 03/05/2019 14:03, Xuelei Fan wrote: >>> Hi Daniel, >>> >>> Good catch! >>> >>> Here is a new webrev that's trying to address the problem. >>> ?? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ >>> >>> The isClosing field update is moving ahead, and a new filed >>> hasDepleted was added for threads competition. >>> >>> The external test described in JDK-8219658 passed, and the regressing >>> testing jobs are still in progress.? I will update if there is a >>> surprise in the regression testing. >>> >>> Thanks, >>> Xuelei >>> >>> On 5/3/2019 4:11 AM, Daniel Fuchs wrote: >>>> Hi Xuelei, >>>> >>>> I believe there is still a small window of opportunity >>>> for which `readLockedDeplete();` will never be called. >>>> >>>> The issue is in `deplete()`: >>>> >>>> If tryLock() fails to lock at line >>>> 1046???????????? if (readLock.tryLock()) { >>>> then there's no guarantee that the reading >>>> thread will not release the readLock before >>>> the else { } statement is executed at line: >>>> 1054???????????????? isClosing = true; >>>> >>>> Thread 1:? enters `read`, locks `readLock` >>>> Thread 2:? enters `deplete`, fails to lock >>>> Thread 1:? finishes reading, find `isClosing` is false, >>>> ??????????? releases `readLock`. >>>> Thread 2:? `deplete` sets `isClosing` to true and returns >>>> >>>> then any further call to `read` will find `isClosing == true` >>>> and return EOF. >>>> >>>> If that happens and I'm not mistaken, then >>>> `readLockedDeplete();` will never be called. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> >>>> On 02/05/2019 21:11, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Could I get the following update reviewed? >>>>> >>>>> ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.00/ >>>>> >>>>> The March5 test looks good, and the external test described in >>>>> JDK-8219658 passed.? No new regression test. >>>>> >>>>> Thanks, >>>>> Xuelei >>>> >> From Alan.Bateman at oracle.com Sat May 4 06:27:16 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 4 May 2019 07:27:16 +0100 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> Message-ID: <501c6419-a6d1-5beb-abd9-57964a7347dc@oracle.com> On 04/05/2019 02:23, Xuelei Fan wrote: > Hi, > > There is a surprise in the regression test.? I made the update, and > now the testing passed.? Here is the new webrev: > ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ I assume you can save two volatile writes by not initializing isClosing and hasDepleted to false (their initial value). If readLockedDeplete were to throw an exception (and there several opportunities for exceptions in that metho) then read would unwind without unlocking. You may need to structure it to reduce that possibility. -Alan From weijun.wang at oracle.com Sun May 5 04:47:20 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 5 May 2019 12:47:20 +0800 Subject: RFR 8223063: Support CNG RSA keys In-Reply-To: References: Message-ID: <392E73FD-F367-4E52-90C1-5BA57E3E14B5@oracle.com> OK, the command is now certutil -v -p changeit -csp "Microsoft Software Key Storage Provider" -user -importpfx MY ks NoRoot,NoExport Test still passes. Thanks, Max > On May 2, 2019, at 4:09 AM, Bernd Eckenfels wrote: > > Max, would it make sense to specify ` -csp "Microsoft Software Key Storage Provider"` to make sure it stores the key in a CNG KSP? (I am not sure what the default provider is). Also maybe make the key non-exportable to make sure key-handles are actually used for the operations? > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > Von: security-dev im Auftrag von Weijun Wang > Gesendet: Mittwoch, Mai 1, 2019 7:21 PM > An: security-dev at openjdk.java.net > Betreff: Re: RFR 8223063: Support CNG RSA keys > > It looks the Mach5 machines are Windows Server 2012 but mine is 2019. I removed the "-f" option and everything looks fine now. > > --Max > > > On May 1, 2019, at 7:18 AM, Weijun Wang wrote: > > > > Please take a look at > > > > https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ > > > > Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with > > > > Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] > > A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 > > A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 > > CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) > > CertUtil: The requested operation is not supported. > > > > Maybe there is a permission issue. > > > > I'll study it for more, but If anyone of you can fix it I'll be very happy. > > > > Thanks, > > Max > > > From weijun.wang at oracle.com Sun May 5 04:53:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 5 May 2019 12:53:51 +0800 Subject: RFR 8219013: Update Apache Santuario (XML Signature) to version 2.1.3 Message-ID: <522190C1-BC19-48B7-BC3F-9373B37D3293@oracle.com> Hi Sean, Please take a review at https://cr.openjdk.java.net/~weijun/8219013/webrev.00/ Most of the changes are around 1) ECKeyValue 2) new BASE64 methods 3) XMLUtils.getFullTextChildrenFromNode. There are also quite a bunch of changes only including year and an apache-style $Id (Ex: DOMHMACSignatureMethod.java) because the previous JDK-8217878 fix had not updated the year. What kind of noreg label I should choose? I am thinking of noreg-other with an explanation that this is a sync with upstream repo. Thanks, Max From weijun.wang at oracle.com Sun May 5 05:06:09 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 5 May 2019 13:06:09 +0800 Subject: 8200400: Restrict Sasl mechanisms Message-ID: <90B87CA3-2BEC-4AFC-A05A-BD727FA6635E@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8200400/webrev.01/ There is a CSR at https://bugs.openjdk.java.net/browse/JDK-8214331 Thanks, Max From weijun.wang at oracle.com Sun May 5 08:33:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 5 May 2019 16:33:51 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> Message-ID: Hi Michael and Nico, > > sspi.cpp: > * KRB5_TRACE If you think a different name is better I'll change it. And then I'd like to revert to my old code that it always print to stderr. I don't have a need to print it to any file. > * showTime(): please use a readable format akin to %FT%T What is %FT%T? > > * NewContext(): > ** why don't you just pass the package name as WCHAR pointer? There is > no clear definition what happens if it is not SPNEGO w/o looking into > the code What I really want to express here is that I am only supporting 2 mechanisms now, and using a WCHAR might lead to an unsupported one. I also don't want to do OID<->string translation a lot. If you are only unsatisfied with the name, is negOrKrb5 better? > ** If you log the token size you should also log if SecurityStatus isn't > positive, just in case I didn't use cbMaxMessage. Will remove it. > ** new_context minor_status is never written, remove it? It was used by the SEC_SUCCESS macro. Now that I won't call QuerySecurityPackageInfo it's useless. Will remove it. > > * get_full_name()!!!: > ** What is the purpose of this function? It will not work reliably if > you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN > HTTP/travel.siemens.com It's only used by gss_export and gss_canonicalize. A service must have a realm in the output of these 2 functions. The realm is not used in init_sec_context. > ** I don't like the idea using Heimdal-internal identifiers. Shouldn't > we define JGSS specific ones? At least create a define for. Well MIT krb5 is already using it (I see it in the exported byte array) so I think it's fine. I don't want to invent a new one. However I cannot use it now because of the permission check. I would think about supporting realm-less name in ServicePermission. > ** your concat fails if USERDNSDOMAIN is empty, you end up ith > service/instance@ That's sad, but I think it should never be empty if the client machine is in a domain and that's what this library wants to support. > ** Why do you check for '\\' what can be escaped here? Requires a better > comment I think Nico answered this in full detail. > * gss_import_name(): > ** BOOLEAN isNegotiate isn't really readable code > ** " value[len] = 0;" rather '\0'? This idiom repeats over and over Sometimes it's '\0' and sometimes it could even be L'\0'. I really don't want to make it too precise here. > ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function Yes. > ** "if (value[len-1] == '@') {" you should comment this block and > explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? I suspect there will be empty/ignorable realms. > ** SPN conversion, why do you replace the '@' with '/' explicitly for > SSPI? A non-mech specific hostbased service is always neutral with '@' I just want to support Kerberos, and I don't want to replace it before calling InitSecContext. > > * gss_canonicalize_name(): something is fishy consider the following case: > gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to > receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but > get_full_name() doesn't do this The realm part is a problem because I cannot get the real one. The '@' should not be changed to '/' if name type is not HOSTBASED-SERVICE. > * gss_export_name(): probably the same issues as with gss_import_name() > > > * gss_init_sec_context(): > ** Line 909, wrong case for package name The one in PackageList? Fixed. It did work. > > I will try to setup a compile env after the next webrev and see how far > I get. I have enough cross-realm stuff around here. Great. If an app calls canonicalize/export and feed back the result into InitSecContext then there might be a problem. Maybe I should always strip the realm part before calling it? That sound like a part of the information is lost. Or maybe it's really useless for Windows? I know giving a wrong realm will fail. Or maybe I should use "WELLKNOWN:ORG.H5L.REFERALS-REALM". I'll do some experiment. Thanks, Max > > Michael From xuelei.fan at oracle.com Sun May 5 15:18:47 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 5 May 2019 08:18:47 -0700 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <501c6419-a6d1-5beb-abd9-57964a7347dc@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> <501c6419-a6d1-5beb-abd9-57964a7347dc@oracle.com> Message-ID: <15820aa1-55ee-6480-f437-c2c6349b7f31@oracle.com> All good catches! I made the update accordingly. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8219991/webrev.03/ Thanks, Xuelei On 5/3/2019 11:27 PM, Alan Bateman wrote: > On 04/05/2019 02:23, Xuelei Fan wrote: >> Hi, >> >> There is a surprise in the regression test.? I made the update, and >> now the testing passed.? Here is the new webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ > I assume you can save two volatile writes by not initializing isClosing > and hasDepleted to false (their initial value). > > If readLockedDeplete were to throw an exception (and there several > opportunities for exceptions in that metho) then read would unwind > without unlocking. You may need to structure it to reduce that possibility. > > -Alan > > From Alan.Bateman at oracle.com Sun May 5 18:31:11 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 5 May 2019 19:31:11 +0100 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <15820aa1-55ee-6480-f437-c2c6349b7f31@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> <501c6419-a6d1-5beb-abd9-57964a7347dc@oracle.com> <15820aa1-55ee-6480-f437-c2c6349b7f31@oracle.com> Message-ID: On 05/05/2019 16:18, Xuelei Fan wrote: > All good catches! > > I made the update accordingly.? Here is the new webrev: > ? http://cr.openjdk.java.net/~xuelei/8219991/webrev.03/ This update looks okay to me (an aternative for read is a nested try/finally but what you have is okay). -Alan From sean.mullan at oracle.com Mon May 6 17:56:43 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 May 2019 13:56:43 -0400 Subject: RFR 8219013: Update Apache Santuario (XML Signature) to version 2.1.3 In-Reply-To: <522190C1-BC19-48B7-BC3F-9373B37D3293@oracle.com> References: <522190C1-BC19-48B7-BC3F-9373B37D3293@oracle.com> Message-ID: On 5/5/19 12:53 AM, Weijun Wang wrote: > Hi Sean, > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8219013/webrev.00/ > > Most of the changes are around 1) ECKeyValue 2) new BASE64 methods 3) XMLUtils.getFullTextChildrenFromNode. There are also quite a bunch of changes only including year and an apache-style $Id (Ex: DOMHMACSignatureMethod.java) because the previous JDK-8217878 fix had not updated the year. Looks good to me. > What kind of noreg label I should choose? I am thinking of noreg-other with an explanation that this is a sync with upstream repo. noreg-other with an explanation sounds right to me. --Sean From sean.mullan at oracle.com Mon May 6 18:06:11 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 May 2019 14:06:11 -0400 Subject: 8200400: Restrict Sasl mechanisms In-Reply-To: <90B87CA3-2BEC-4AFC-A05A-BD727FA6635E@oracle.com> References: <90B87CA3-2BEC-4AFC-A05A-BD727FA6635E@oracle.com> Message-ID: <68b87231-0732-3283-e8d9-e3b3fd5d8a86@oracle.com> On 5/5/19 1:06 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8200400/webrev.01/ The java.security property description is not up-to-date with the CSR. Also, we don't support a system property override in the other jdk.*.disabled properties. So I don't think we should add that unless or until we see a need for it. In Sasl.java, can we log or add some debug information if a mechanism is disabled? Otherwise it can be hard to debug. --Sean > There is a CSR at > > https://bugs.openjdk.java.net/browse/JDK-8214331 > > Thanks, > Max > From jay at elastic.co Thu May 2 18:58:59 2019 From: jay at elastic.co (Jay Modi) Date: Thu, 2 May 2019 12:58:59 -0600 Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o shutdown In-Reply-To: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com> References: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com> Message-ID: With the release of 12.0.1, I tested this again and still see issues with an endless loop in the way the HttpsServer handles this situation so I do not believe this is the same issue as JDK-8214418. Jay On Mon, Feb 11, 2019 at 2:59 AM Daniel Fuchs wrote: > Hi Jay, > > > It looks like this is JDK-8214418 - which has been fixed > in 12.0.1 b03 and 13-ea b04. The issue was with the > half closed semantics of the SSL engine in TLS 1.3. > > best regards, > > -- daniel > > On 08/02/2019 21:43, Jay Modi wrote: > > Hi, > > > > I've been doing some testing with Apache HttpClient against the > > com.sun.net.httpserver.HttpsServer that is included with the JDK and > > came across some interesting behavior that occurs when using TLSv1.3, > > but TLSv1.2 works normally. If the client manually calls > > Socket#shutdownOutput and Socket#shutdownInput before closing the > > socket, the HttpsServer goes into an endless loop while trying send the > > close back to the client. Is this expected? I've done my best to create > > a minimal reproducer without Apache HttpClient[1]. > > > > To me this behavior does not seem right and as I mentioned, I did not > > have these issues when using TLSv1.2. I'm running on macOS with the > > following JDK: > > openjdk version "11.0.2" 2019-01-15 > > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) > > > > Jay > > > > [1] https://gist.github.com/jaymode/3a6562beaa7ea789b287372bd10d4d1d > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue May 7 08:26:54 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 7 May 2019 09:26:54 +0100 Subject: Code Review Request, JDK-8219991 : New fix of the deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <15820aa1-55ee-6480-f437-c2c6349b7f31@oracle.com> References: <094122e4-832c-09bf-506c-060d78fa95cf@oracle.com> <77a1213d-eae9-aaa4-325d-1d97c258604e@oracle.com> <81bbe178-3601-ebd0-d99a-9e4a4d11fb55@oracle.com> <501c6419-a6d1-5beb-abd9-57964a7347dc@oracle.com> <15820aa1-55ee-6480-f437-c2c6349b7f31@oracle.com> Message-ID: <182c797d-521e-e8c1-54db-6a6040a88491@oracle.com> Hi Xuelei, looks good to me as well. best regards, -- daniel On 05/05/2019 16:18, Xuelei Fan wrote: > All good catches! > > I made the update accordingly.? Here is the new webrev: > ? http://cr.openjdk.java.net/~xuelei/8219991/webrev.03/ > > Thanks, > Xuelei > > On 5/3/2019 11:27 PM, Alan Bateman wrote: >> On 04/05/2019 02:23, Xuelei Fan wrote: >>> Hi, >>> >>> There is a surprise in the regression test.? I made the update, and >>> now the testing passed.? Here is the new webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8219991/webrev.01/ >> I assume you can save two volatile writes by not initializing >> isClosing and hasDepleted to false (their initial value). >> >> If readLockedDeplete were to throw an exception (and there several >> opportunities for exceptions in that metho) then read would unwind >> without unlocking. You may need to structure it to reduce that >> possibility. >> >> -Alan >> >> From christoph.langer at sap.com Tue May 7 14:15:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 14:15:15 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: Ping: can I please have a review for this? From: Langer, Christoph Sent: Donnerstag, 2. Mai 2019 14:55 To: 'jdk8u-dev at openjdk.java.net' ; security-dev Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Hi, as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: 8191844: Remove SECOM root (secomevrootca1) 8189949: Remove Baltimore Cybertrust Code Signing CA 8191031: Remove several Symantec Root CAs 8196141: Add GoDaddy root certificates 8204923: Restore Symantec root verisignclass2g2ca 8195774: Add Entrust root certificates 8199779: Add T-Systems, GlobalSign and Starfield services root certificates 8209506: Add Google Trust Services GlobalSign root certificates 8210432: Add additional TeliaSonera root certificate 8195793: Remove GTE CyberTrust Global Root 8216577: Add GlobalSign's R6 Root certificate 8222137: Remove T-Systems root CA certificate Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. To make the test run in JDK8, I had to a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html [2] https://bugs.openjdk.java.net/browse/JDK-8189131 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue May 7 14:28:20 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 7 May 2019 10:28:20 -0400 Subject: RFR: 8191808: Configurable read timeout for CRLs Message-ID: Please review this change to add a system property for configuring the read timeout when downloading CRLs with a default value of 15 seconds. Currently there is no timeout so downloads of large CRLs can block for a long time or indefinitely. Current workaround is to use the sun.net.client.defaultReadTimeout system property but that affects all connections. bug: https://bugs.openjdk.java.net/browse/JDK-8191808 CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ Thanks, Sean From xuelei.fan at oracle.com Tue May 7 15:28:02 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 May 2019 08:28:02 -0700 Subject: RFR: 8191808: Configurable read timeout for CRLs In-Reply-To: References: Message-ID: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> What do you think if com.sun.security.crl.readtimeout is not set, CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT? Otherwise, looks fine to me. Xuelei On 5/7/2019 7:28 AM, Sean Mullan wrote: > Please review this change to add a system property for configuring the > read timeout when downloading CRLs with a default value of 15 seconds. > Currently there is no timeout so downloads of large CRLs can block for a > long time or indefinitely. Current workaround is to use the > sun.net.client.defaultReadTimeout system property but that affects all > connections. > > bug: https://bugs.openjdk.java.net/browse/JDK-8191808 > CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ > > Thanks, > Sean From weijun.wang at oracle.com Tue May 7 15:31:09 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 May 2019 23:31:09 +0800 Subject: 8200400: Restrict Sasl mechanisms In-Reply-To: <68b87231-0732-3283-e8d9-e3b3fd5d8a86@oracle.com> References: <90B87CA3-2BEC-4AFC-A05A-BD727FA6635E@oracle.com> <68b87231-0732-3283-e8d9-e3b3fd5d8a86@oracle.com> Message-ID: Updated webrev at http://cr.openjdk.java.net/~weijun/8200400/webrev.02/ The CSR at https://bugs.openjdk.java.net/browse/JDK-821433 is also updated. I reuse the Logger name "javax.security.sasl" used by our SASL providers. The name looks high-level enough to be used here. Thanks, Max > On May 7, 2019, at 2:06 AM, Sean Mullan wrote: > > On 5/5/19 1:06 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8200400/webrev.01/ > > The java.security property description is not up-to-date with the CSR. Also, we don't support a system property override in the other jdk.*.disabled properties. So I don't think we should add that unless or until we see a need for it. > > In Sasl.java, can we log or add some debug information if a mechanism is disabled? Otherwise it can be hard to debug. > > --Sean > >> There is a CSR at >> https://bugs.openjdk.java.net/browse/JDK-8214331 >> Thanks, >> Max From sean.mullan at oracle.com Tue May 7 16:16:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 7 May 2019 12:16:54 -0400 Subject: RFR: 8191808: Configurable read timeout for CRLs In-Reply-To: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> References: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> Message-ID: <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> On 5/7/19 11:28 AM, Xuelei Fan wrote: > What do you think if com.sun.security.crl.readtimeout is not set, > CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT? There may be good reasons you would want different values for these two properties, so if com.sun.security.crl.readtimeout is not set, I think it is better to have a fixed default value and not have it be the same as CRL_CONNECT_TIMEOUT. > > Otherwise, looks fine to me. Thanks. Could you also add your name as the CSR Reviewer? --Sean > > Xuelei > > On 5/7/2019 7:28 AM, Sean Mullan wrote: >> Please review this change to add a system property for configuring the >> read timeout when downloading CRLs with a default value of 15 seconds. >> Currently there is no timeout so downloads of large CRLs can block for >> a long time or indefinitely. Current workaround is to use the >> sun.net.client.defaultReadTimeout system property but that affects all >> connections. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8191808 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ >> >> Thanks, >> Sean From xuelei.fan at oracle.com Tue May 7 16:28:43 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 May 2019 09:28:43 -0700 Subject: RFR: 8191808: Configurable read timeout for CRLs In-Reply-To: <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> References: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> Message-ID: <58c91932-9d4c-a82e-9c77-3528de7442ff@oracle.com> On 5/7/2019 9:16 AM, Sean Mullan wrote: > On 5/7/19 11:28 AM, Xuelei Fan wrote: >> What do you think if com.sun.security.crl.readtimeout is not set, >> CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT? > > There may be good reasons you would want different values for these two > properties, so if com.sun.security.crl.readtimeout is not set, I think > it is better to have a fixed default value and not have it be the same > as CRL_CONNECT_TIMEOUT. > It's okay to me. >> >> Otherwise, looks fine to me. > > Thanks. Could you also add your name as the CSR Reviewer? > I added myself as the reviewer. Xuelei > --Sean > >> >> Xuelei >> >> On 5/7/2019 7:28 AM, Sean Mullan wrote: >>> Please review this change to add a system property for configuring >>> the read timeout when downloading CRLs with a default value of 15 >>> seconds. Currently there is no timeout so downloads of large CRLs can >>> block for a long time or indefinitely. Current workaround is to use >>> the sun.net.client.defaultReadTimeout system property but that >>> affects all connections. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8191808 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ >>> >>> Thanks, >>> Sean From Nico.Williams at twosigma.com Tue May 7 16:53:35 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 7 May 2019 16:53:35 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> Message-ID: <20190507165335.GA7457@twosigma.com> On Thu, Mar 21, 2019 at 11:01:32AM +0800, Weijun Wang wrote: > All of them at > > https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams > > You might want to add more descriptions. Below is the commentary I've collated from GitHub, along with my responses. - src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java By: Peter Burka Status: ACCEPT Comment: > + * especially when they are using a keytab. + * + * If the user is using a password, then the realm matters more. An + * untrusted actor could cause KDCs for a realm they control to see + * material they could attack offline, but that was already the case + * anyways, and the answer is the same in all cases: use stronger + * passwords, use randomized keys in a keytab, or let us implement + * SPAKE or similar alternatives to the venerable PA-ENC-TIMESTAMP. + */ + if ((this.getName().equals("krbtgt/@") && + p.getName().startsWith("krbtgt/")) || + (p.getName().equals("krbtgt/@") && + this.getName().startsWith("krbtgt/"))) + return true; + + char[] n = this.getName().toCharArray(); Converting this to a char[] is an unnecessary copy. Just operate on the String directly. - src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java By: Peter Burka Status: ACCEPT Comment: > + */ + if ((this.getName().equals("krbtgt/@") && + p.getName().startsWith("krbtgt/")) || + (p.getName().equals("krbtgt/@") && + this.getName().startsWith("krbtgt/"))) + return true; + + char[] n = this.getName().toCharArray(); + int i; + for (i = 0; i < n.length; i++) { + if (n[i] == '\\') { + i++; + continue; + } + if (n[i] == '@') { + String s = new String(n, 0, i + 1); This allocation is unnecessary. Use String#regionMatches instead. - src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java By: Peter Burka Status: ACCEPT Comment: > - if (name instanceof GSSNameImpl) { - try { - GSSNameSpi ne = ((GSSNameImpl) name).getElement - (GSS_KRB5_MECH_OID); - String krbName = ne.toString(); - if (ne instanceof Krb5NameElement) { - krbName = - ((Krb5NameElement) ne).getKrb5PrincipalName().getName(); - } - KerberosPrincipal krbPrinc = new KerberosPrincipal(krbName); - krb5Principals.add(krbPrinc); - } catch (GSSException ge) { - debug("Skipped name " + name + " due to " + ge); - } - } + Set names = new HashSet(); Use `new HashSet<>()` (it's no longer necessary to repeat GSSName here). - src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java By: Peter Burka Status: REJECT Comment: > - while (iterator.hasNext()) { - GSSCredentialImpl cred = iterator.next(); - debug("...Found cred" + cred); - try { - GSSCredentialSpi ce = - cred.getElement(mech, initiate); - debug("......Found element: " + ce); - if (ce.getClass().equals(credCls) && - (name == null || - name.equals((Object) ce.getName()))) { + if (accSubj == null) { + debug("No Subject"); + return result; + } + + result = new Vector(); I know this is pre-existing, but Vectors are very 1998. Consider using an ArrayList. - src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java By: Peter Burka Status: REJECT Comment: > - GSSCredentialSpi ce = - cred.getElement(mech, initiate); - debug("......Found element: " + ce); - if (ce.getClass().equals(credCls) && - (name == null || - name.equals((Object) ce.getName()))) { + if (accSubj == null) { + debug("No Subject"); + return result; + } + + result = new Vector(); + Iterator iterator = + accSubj.getPrivateCredentials + (GSSCredentialImpl.class).iterator(); + while (iterator.hasNext()) { Again, pre-existing code, but consider using a for-each here. (`for (GSSCredentialImpl cred : accSubj.getPrivateCredentials(...)) ...` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > @@ -65,8 +66,17 @@ public LoginConfigImpl(GSSCaller caller, Oid mech) { this.caller = caller; - if (mech.equals(GSSUtil.GSS_KRB5_MECH_OID)) { + useNative = "true".equalsIgnoreCase( + System.getProperty("sun.security.jgss.native")); + Consider `useNative = Boolean.getBoolean("sun.security.jgss.native")` - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java By: Peter Burka Status: ACCEPT Comment: > @@ -47,6 +47,7 @@ private final Krb5NameElement name; private final ServiceCreds screds; + private boolean isDefCred = false; Can you make this final? - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java By: Peter Burka Status: ACCEPT Comment: > @@ -134,7 +137,8 @@ private Krb5InitCredential(Krb5NameElement name, this.name = name; // A delegated cred does not have all fields set. So do not try to - // creat new Credentials out of the delegatedCred. + // creat new Credentials out of the delegatedCred. Also, a delegated "create", unless you're referring to O_CREAT. - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5NameElement.java - src/java.security.jgss/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java - src/java.security.jgss/share/classes/sun/security/jgss/spi/GSSNameSpi.java - src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java By: Peter Burka Status: ACCEPT Comment: + /** + * Returns true if the credential is a default credential. + * + * @return true if the credential is a default credential, else false. + */ + public boolean isDefaultCredential() { `final`, unless you expect subclasses to override. - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java - src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java By: Peter Burka Status: ACCEPT Response: will make private and final Comment: > @@ -42,9 +42,14 @@ long pCred; // Pointer to the gss_cred_id_t structure private GSSNameElement name = null; private GSSLibStub cStub; + public boolean isDefCred; Are you sure you want this to be public? Especially since it's not final! What if someone else changes it? - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java By: Peter Burka Status: ACCEPT Response: huh, might want to do the same for GSSLibStub.java... Comment: > @@ -53,6 +53,7 @@ long pName = 0; // Pointer to the gss_name_t structure private String printableName; private Oid printableType; + private Oid mech; Can this be made final? - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java By: Peter Burka Status: ACCEPT Comment: > private int flags; private int lifetime = GSSCredential.DEFAULT_LIFETIME; private final GSSLibStub cStub; - private boolean skipDelegPermCheck; - private boolean skipServicePermCheck; + private boolean skipDelegPermCheck = false; This isn't strictly necessary. `false` is already the default value. (But explicit initialization is clearer, IMO.) - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java By: Peter Burka Status: REJECT Comment: > } + } catch (GSSException ge) { + dispose(); This should be a finally block. I presume you want to call `dispose()` if _any_ exception occurs, not just `GSSException`. Reason: in the success case we need `this`. In the failure case we want to dispose() early because the object is an iceberg to the Java GC: it's much larger than the GC knows, so if these accumulate there will be more memory pressure than the GC knows about. - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java By: Peter Burka Status: ACCEPT Comment: > // Do Service Permission check when importing SPNEGO context - // just to be safe + // just to be safe. WAT, no. If the caller has an exported sec Let's not push 'Wat no' - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java By: Peter Burka Status: HMMM Comment: > @@ -346,9 +363,13 @@ public boolean isEstablished() { } public void dispose() throws GSSException { Is this meant to be thread safe? (It doesn't look thread safe.) Reason: It's not really thread-safe, no, but it's already so before my changes, and a) we don't dispose() of objects passed by the caller, only those we create ephemerally. The application should not call dispose() on objects that might be used by other threads concurrently. Perhaps we should document that. Or we could make synchronized all the native GSS methods that refer to these C pointers... I guess that's not a big deal. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: REJECT Comment: > @@ -455,6 +455,14 @@ void throwOutOfMemoryError(JNIEnv *env, const char *message) { throwByName(env, "java/lang/OutOfMemoryError", message); } +static jsize +safe_jsize(size_t n) +{ + jsize res = (jsize)n; I'm not convinced this function is safe. I suspect it invokes undefined behavior more than once. Reason: I believe this function is safe indeed. It's using C casts to detect whether a size_t value is too large to represent as a jsize value. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: ACCEPT Comment: > - (*env)->SetByteArrayRegion(env, jbytes, 0, len, (jbyte *) bytes->value); - if ((*env)->ExceptionCheck(env)) { - goto finish; - } + /* constructs the String object with new String(byte[]) */ This was pre-existing, but it's likely unsafe. This will use whatever the default Java character encoding is. You probably want to use an explicit code page. And if you're not going to do that, it would be simpler to decode the name yourself and use `(*env)->NewString(...)` Response: OK, will use NewStringUTF(). - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: ACCEPT Comment: > void* value; - if (jbytes != NULL) { - len = (*env)->GetArrayLength(env, jbytes); - value = malloc(len); - if (value == NULL) { + cbytes->length = 0; + cbytes->value = NULL; + + if (jbytes == NULL || + (len = (*env)->GetArrayLength(env, jbytes)) == 0) + return; + + cbytes->length = len; + + if (wantCopy == JNI_FALSE) { + cbytes->value = (*env)->GetByteArrayElements(env, jbytes, &isCopy); If you don't plan to read `isCopy`, just pass in `NULL`. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: IGNORE Comment: > void* value; - if (jbytes != NULL) { - len = (*env)->GetArrayLength(env, jbytes); - value = malloc(len); - if (value == NULL) { + cbytes->length = 0; + cbytes->value = NULL; + + if (jbytes == NULL || + (len = (*env)->GetArrayLength(env, jbytes)) == 0) + return; + + cbytes->length = len; + + if (wantCopy == JNI_FALSE) { + cbytes->value = (*env)->GetByteArrayElements(env, jbytes, &isCopy); ... and what will you do if `GetByteArrayElements` doesn't return a copy to you?? Response: If we want a copy, then we malloc() and copy (and later free()). Otherwise we rely on ReleaseByteArrayElements() to release the copy. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: REJECT Comment: > void* value; - if (jbytes != NULL) { - len = (*env)->GetArrayLength(env, jbytes); - value = malloc(len); - if (value == NULL) { + cbytes->length = 0; + cbytes->value = NULL; + + if (jbytes == NULL || + (len = (*env)->GetArrayLength(env, jbytes)) == 0) + return; + + cbytes->length = len; + + if (wantCopy == JNI_FALSE) { + cbytes->value = (*env)->GetByteArrayElements(env, jbytes, &isCopy); I think this whole function is unnecessarily complicated. In practice, any modern JVM will return a copy from GetByteArrayElements, anyway. So what do you gain from having two codepaths here? Response: This is an artifact of our support for 7, 8, .., master. We could rely on the copy behavior, but for now I'll leave it as-is. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: Comment: > } } +/* + * Utility routine for initializing gss_buffer_t structure + * with a String. + * NOTE: need to call resetGSSBufferString(...) to free up + * the resources. + */ +void initGSSBufferString(JNIEnv* env, jstring jstr, gss_buffer_t buf) +{ + const char *s; + + buf->length = 0; + buf->value = NULL; + if (jstr != NULL) { + s = (*env)->GetStringUTFChars(env, jstr, NULL); Does GSS expect UTF8 encoded strings? Response: Yes. GSS is undespecified as to codeset, but UTF-8 is the only thing that makes sense. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: ACCEPT Comment: > + } else { + buf->length = strlen(s); + buf->value = (char *)s; /* Drop const */ + } + } +} + +/* + * Utility routine for unpinning/releasing the String + * associated with the specified jstring object. + * NOTE: used in conjunction with initGSSBufferString(...). + */ +void resetGSSBufferString(JNIEnv *env, jstring jstr, gss_buffer_t buf) +{ + if (jstr != NULL && buf->value != NULL) + (*env)->ReleaseStringUTFChars(env, jstr, buf->value); `buf->value = NULL` Response: Ah yes, we're assuming that length == 0 -> no need to release. That's not necessarily true. - src/java.security.jgss/share/native/libj2gss/NativeUtil.c By: Peter Burka Status: REJECT Comment: > @@ -724,66 +786,47 @@ jobject getJavaOID(JNIEnv *env, gss_OID cOid) { if (jbytes == NULL) { return NULL; } - (*env)->SetByteArrayRegion(env, jbytes, 0, 2, (jbyte *) oidHdr); - if ((*env)->ExceptionCheck(env)) { - return NULL; + if (!(*env)->ExceptionCheck(env)) { Consider using `GetPrimitiveArrayCritical()` instead. I think it would result in simpler, faster code. pburka commented on this pull request. Reason: This doesn't have to be faster, and it's simple enough. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.security.auth.module; + +import java.io.*; Generally, wildcard imports are discouraged in modern code. Commentary: well, it was in the original, in Krb5LoginModule. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + +import org.ietf.jgss.GSSManager; +import org.ietf.jgss.GSSException; +import org.ietf.jgss.GSSContext; +import org.ietf.jgss.GSSCredential; +import org.ietf.jgss.GSSName; +import org.ietf.jgss.Oid; + +import static sun.security.util.ResourcesMgr.getAuthResourceString; + +/** + *

This LoginModule authenticates users using the + * GSS-API.

+ */ + +public class GssLoginModule implements LoginModule { Is this class meant to be subclassed? If not, it should be final. Reason: All the *LoginModule classes are non-final. Perhaps they should be final, but I won't make that decision. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + * It stands to reason that when sun.security.jgss.native=false the + * login modules corresponding to the actual GSS mechanisms coded in + * Java are the ones that should be acquiring their corresponding + * credentials. + * + * A policy like "let the application use GSS credentials but not the + * raw, underlying Krb5 credentials" when + * sun.security.jgss.native=false" could be expressible by adding a + * module option to Krb5LoginModule that causes it to add only GSS + * credentials to the Subject, not Krb5 credentials. + * + * (It has never been possible to express such a policy, so we lose + * nothing by punting here when sun.security.jgss.native=false.) + */ + useNative = "true".equalsIgnoreCase( + System.getProperty("sun.security.jgss.native")); Consider `Boolean.getBoolean("sun.security.jgss.native")` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + * module option to Krb5LoginModule that causes it to add only GSS + * credentials to the Subject, not Krb5 credentials. + * + * (It has never been possible to express such a policy, so we lose + * nothing by punting here when sun.security.jgss.native=false.) + */ + useNative = "true".equalsIgnoreCase( + System.getProperty("sun.security.jgss.native")); + if (!useNative) + return; + + manager = GSSManager.getInstance(); + + // initialize any configured options + + debug = "true".equalsIgnoreCase((String)options.get("debug")); Consider `Boolean.parseBoolean((String)options.get("debug"))` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + * + * (It has never been possible to express such a policy, so we lose + * nothing by punting here when sun.security.jgss.native=false.) + */ + useNative = "true".equalsIgnoreCase( + System.getProperty("sun.security.jgss.native")); + if (!useNative) + return; + + manager = GSSManager.getInstance(); + + // initialize any configured options + + debug = "true".equalsIgnoreCase((String)options.get("debug")); + doNotPrompt = + "true".equalsIgnoreCase(getWithDefault("doNotPrompt", "true")); ditto. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + + debug = "true".equalsIgnoreCase((String)options.get("debug")); + doNotPrompt = + "true".equalsIgnoreCase(getWithDefault("doNotPrompt", "true")); + defName = (String)options.get("name"); + nametype = (String)options.get("nametype"); + + if (defName == null) + defName = System.getProperty("sun.security.gss.name"); + if (nametype == null) + nametype = System.getProperty("sun.security.gss.nametype"); + if (nametype == null || nametype.equals("username")) { + nametypeOid = GSSName.NT_USER_NAME; + } else if (nametype.equals("hostbased")) { + nametypeOid = GSSName.NT_HOSTBASED_SERVICE; + } else if (!nametype.equals("")) { `!nametype.isEmpty()` Reason: it's good enough as it is. > + nametypeOid = GSSName.NT_HOSTBASED_SERVICE; + } else if (!nametype.equals("")) { + try { + nametypeOid = new Oid(nametype); + } catch (GSSException e) { + if (debug) + System.out.print("Unknown name type OID " + nametype); + nametypeOid = null; + } + } else { + nametype = ""; + nametypeOid = GSSName.NT_USER_NAME; + } + + tryFirstPass = + "true".equalsIgnoreCase(getWithDefault("tryFirstPass", "true")); `Boolean.parseBoolean` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + try { + nametypeOid = new Oid(nametype); + } catch (GSSException e) { + if (debug) + System.out.print("Unknown name type OID " + nametype); + nametypeOid = null; + } + } else { + nametype = ""; + nametypeOid = GSSName.NT_USER_NAME; + } + + tryFirstPass = + "true".equalsIgnoreCase(getWithDefault("tryFirstPass", "true")); + useFirstPass = + "true".equalsIgnoreCase( `Boolean.parseBoolean` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + useFirstPass = + "true".equalsIgnoreCase( + getWithDefault("useFirstPass", + doNotPrompt ? "true" : "false")); + storePass = + "true".equalsIgnoreCase((String)options.get("storePass")); + clearPass = + "true".equalsIgnoreCase((String)options.get("clearPass")); + initiate = + "true".equalsIgnoreCase((String)options.get("initiate")); + accept = + "true".equalsIgnoreCase((String)options.get("accept")); + tryDefaultCreds = + "true".equalsIgnoreCase(getWithDefault("tryDefaultCreds", "true")); + useDefaultCreds = + "true".equalsIgnoreCase( ditto ditto ditto ditto - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + le.getMessage()); + } + if (useFirstPass) + throw le; + } + + // The first password didn't work or we didn't try it, try prompting + try { + attemptAuthentication(false); + if (debug) + System.out.println("\t\t[GssLoginModule] " + + "authentication succeeded"); + succeeded = true; + cleanState(); + return true; + } catch (LoginException le2) { This looks weirdly like 1e2 Reason: but obviously it cannot be a number... - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + } + if (useFirstPass) + throw le; + } + + // The first password didn't work or we didn't try it, try prompting + try { + attemptAuthentication(false); + if (debug) + System.out.println("\t\t[GssLoginModule] " + + "authentication succeeded"); + succeeded = true; + cleanState(); + return true; + } catch (LoginException le2) { + cleanState(); This should be in a `finally` block, I think. Reason: You're right that cleanState() could be called in a `finally` block, but it wouldn't reduce loc count. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + gssName = gssICred.getName(); + if (gssName == null && gssACred != null) + gssName = gssACred.getName(); + } + + private void attemptAuthentication(boolean getPasswdFromSharedState) + throws LoginException { + + // Get a name, maybe + if (name == null) { + if (useDefaultCreds) { + try { + getcreds(); + return; + } catch (GSSException e) { + throw new LoginException(e.getMessage()); Consider adding `e` as a cause to the `LoginException` Reason: LoginException is ancient. I'm not going to fix LoginException :/ - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + + // Get a name, maybe + if (name == null) { + if (useDefaultCreds) { + try { + getcreds(); + return; + } catch (GSSException e) { + throw new LoginException(e.getMessage()); + } + } + if (tryDefaultCreds) { + try { + getcreds(); + return; + } catch (GSSException e) { } Ignoring exceptions is a bad smell. Add a comment explaining why it's ok. Reason: I think the code is self-explanatory. We're trying one path and falling back onto the other, and I'm not nesting try blocks unnecessarily because too much indentation makes code hard to read. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + if (tryDefaultCreds) { + try { + getcreds(); + return; + } catch (GSSException e) { } + } + + promptForName(getPasswdFromSharedState); + if (name == null) + throw new LoginException ("Unable to determine a GSS name"); + } + + try { + gssName = manager.createName(name, nametypeOid); + } catch (GSSException e) { + throw new LoginException ("Unable to import GSS name"); Consider reporting `e` as the cause of the `LoginException` Reason: LoginException is ancient. I'm not going to fix LoginException :/ - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + + promptForPass(getPasswdFromSharedState); + + try { + getcreds(); + } catch (GSSException e) { + throw new LoginException(e.getMessage()); + } + } + + private void promptForName(boolean getPasswdFromSharedState) + throws LoginException { + if (getPasswdFromSharedState) { + // use the name saved by a module earlier in the stack + name = (String)sharedState.get(NAME); + if (name == null || name.length() == 0) use `name.isEmpty()` instead of checking the length. Reason: it's good enough as it is. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + + if (callbackHandler == null) + throw new LoginException("No CallbackHandler " + + "available " + + "to prompt for authentication " + + "information from the user"); + + try { + String defUsername = System.getProperty("user.name"); + + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "GSS.name.defName.")); + Object[] source = {defUsername}; + callbacks[0] = new NameCallback(form.format(source)); Why not allocate and initialize `callbacks` on one line, like you do for `source` on the previous line? - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + + "available " + + "to prompt for authentication " + + "information from the user"); + + try { + String defUsername = System.getProperty("user.name"); + + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "GSS.name.defName.")); + Object[] source = {defUsername}; + callbacks[0] = new NameCallback(form.format(source)); + callbackHandler.handle(callbacks); + name = ((NameCallback)callbacks[0]).getName(); + if (name != null && name.length() == 0) `isEmpty()` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + throw new LoginException("No CallbackHandler " + + "available " + + "to prompt for authentication " + + "information from the user"); + + try { + String defUsername = System.getProperty("user.name"); + + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "GSS.name.defName.")); + Object[] source = {defUsername}; + callbacks[0] = new NameCallback(form.format(source)); + callbackHandler.handle(callbacks); + name = ((NameCallback)callbacks[0]).getName(); This feels needlessly roundabout. Just store the callback in an appropriately typed local. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + + try { + String defUsername = System.getProperty("user.name"); + + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "GSS.name.defName.")); + Object[] source = {defUsername}; + callbacks[0] = new NameCallback(form.format(source)); + callbackHandler.handle(callbacks); + name = ((NameCallback)callbacks[0]).getName(); + if (name != null && name.length() == 0) + name = null; + if (name == null && defUsername != null && + defUsername.length() != 0) `isEmpty()` pburka commented on this pull request. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "GSS.name.defName.")); + Object[] source = {defUsername}; + callbacks[0] = new NameCallback(form.format(source)); + callbackHandler.handle(callbacks); + name = ((NameCallback)callbacks[0]).getName(); + if (name != null && name.length() == 0) + name = null; + if (name == null && defUsername != null && + defUsername.length() != 0) + name = defUsername; + } catch (java.io.IOException ioe) { + throw new LoginException(ioe.getMessage()); Include `ioe` as cause. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + MessageFormat form = new MessageFormat( + getAuthResourceString( + "GSS.name.defName.")); + Object[] source = {defUsername}; + callbacks[0] = new NameCallback(form.format(source)); + callbackHandler.handle(callbacks); + name = ((NameCallback)callbacks[0]).getName(); + if (name != null && name.length() == 0) + name = null; + if (name == null && defUsername != null && + defUsername.length() != 0) + name = defUsername; + } catch (java.io.IOException ioe) { + throw new LoginException(ioe.getMessage()); + } catch (UnsupportedCallbackException uce) { + throw new LoginException Include `uce` as cause. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + private void promptForPass(boolean getPasswdFromSharedState) + throws LoginException { + + char[] pw; + + if (getPasswdFromSharedState) { + // use the password saved by the first module in the stack + pw = (char[])sharedState.get(PWD); + if (pw == null) { + if (debug) + System.out.println("\t\t[GssLoginModule] password from" + + " shared state is null"); + throw new LoginException + ("Password can not be obtained from sharedstate "); + } + password = new String(pw); This uses the default encoding. That's almost certainly not what you want. Reason: It's what Krb5LoginModule does, and I believe it's correct. later, in the C JNI code we'll ask for the string's UTF-8 contents, so presumably Java will convert then. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + + if (getPasswdFromSharedState) { + // use the password saved by the first module in the stack + pw = (char[])sharedState.get(PWD); + if (pw == null) { + if (debug) + System.out.println("\t\t[GssLoginModule] password from" + + " shared state is null"); + throw new LoginException + ("Password can not be obtained from sharedstate "); + } + password = new String(pw); + return; + } + if (doNotPrompt) + throw new LoginException("Unable to prompt for password\n"); Remove the `\n` - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: ACCEPT Comment: > + if (doNotPrompt) + throw new LoginException("Unable to prompt for password\n"); + + if (callbackHandler == null) { + throw new LoginException("No CallbackHandler " + + "available " + + "to garner authentication " + + "information from the user"); + } + try { + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "Kerberos.password.for.username.")); + Object[] source = {name}; + callbacks[0] = new PasswordCallback(form.format(source), false); ditto -- alloc and initialize on one line. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + Callback[] callbacks = new Callback[1]; + MessageFormat form = new MessageFormat( + getAuthResourceString( + "Kerberos.password.for.username.")); + Object[] source = {name}; + callbacks[0] = new PasswordCallback(form.format(source), false); + callbackHandler.handle(callbacks); + char[] tmpPassword = ((PasswordCallback) + callbacks[0]).getPassword(); + if (tmpPassword == null) + throw new LoginException("No password provided"); + password = new String(tmpPassword); + ((PasswordCallback)callbacks[0]).clearPassword(); + + // clear tmpPassword + for (int i = 0; i < tmpPassword.length; i++) `Arrays.fill(tmpPassword, ' ')` Reason: Interesting, but not too compelling. Also, this clearing of passwords thing (which here I copied from Krb5LoginModule) is cargo culting. The GC may well have moved the password and there may well be copies in memory. I'd sooner remove this code than rewrite it. - src/jdk.security.auth/share/classes/com/sun/security/auth/module/GssLoginModule.java By: Peter Burka Status: REJECT Comment: > + "Kerberos.password.for.username.")); + Object[] source = {name}; + callbacks[0] = new PasswordCallback(form.format(source), false); + callbackHandler.handle(callbacks); + char[] tmpPassword = ((PasswordCallback) + callbacks[0]).getPassword(); + if (tmpPassword == null) + throw new LoginException("No password provided"); + password = new String(tmpPassword); + ((PasswordCallback)callbacks[0]).clearPassword(); + + // clear tmpPassword + for (int i = 0; i < tmpPassword.length; i++) + tmpPassword[i] = ' '; + } catch (java.io.IOException ioe) { + throw new LoginException(ioe.getMessage()); Report the cause. - Regaring various createCredential() methods and credential class constructors that now have a password argument By: Michael Osipov Status: REJECT Comment: Shouldn't the password be a char array? To securely wipe the password from memory against immutable strings in Java. In C you can safely to memset with zero, you Java you can't. Reason: Not really. There's no win. The GC can move arrays, leaving behind copies of the password. There's no easy way to prevent this. - src/java.security.jgss/share/classes/sun/security/jgss/LoginConfigImpl.java By: Michael Osipov Status: REJECT Comment: > } return new AppConfigurationEntry[] { new AppConfigurationEntry( - "com.sun.security.auth.module.Krb5LoginModule", + "com.sun.security.auth.module.GssLoginModule", This is a change in behavior, why? This is backwards-compatible. We now specify GssLoginModule as required in the default JAAS config, but it returns ignore if it's not applicable, and then we have Krb5LoginModule as sufficient, which means any failure from it will be ignored if GssLoginModule succeeds. From mbalao at redhat.com Tue May 7 19:45:02 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 7 May 2019 16:45:02 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client Message-ID: Hi, I'd like to propose a fix for "8223482: Unsupported ciphersuites may be offered by a TLS client" [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ Testing: * FipsModeTLS12 (after Webrev.00 modifications) reproduces this bug and works as a regression test * No regressions found in jdk/sun/security/ssl I'd be grateful if someone can have a look. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8223482 From xuelei.fan at oracle.com Tue May 7 19:53:46 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 May 2019 12:53:46 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: References: Message-ID: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> Hi Martin, Would you mind evaluate the performance impact of the fix and improve it accordingly? Thanks, Xuelei On 5/7/2019 12:45 PM, Martin Balao wrote: > Hi, > > I'd like to propose a fix for "8223482: Unsupported ciphersuites may be > offered by a TLS client" [1]: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ > > Testing: > > * FipsModeTLS12 (after Webrev.00 modifications) reproduces this bug and > works as a regression test > > * No regressions found in jdk/sun/security/ssl > > I'd be grateful if someone can have a look. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8223482 > From mbalao at redhat.com Tue May 7 20:33:53 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 7 May 2019 17:33:53 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> Message-ID: <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> Hi Xuelei, Thanks for having a look. I'll work on a benchmark to see the impact of this proposal. I have a couple of ideas but wish we could discuss them before moving to their implementation. #1 ............................... Under the assumption that security providers do not change in run time, we can store "supports" results when SSLCipher instances are created. There would be a static initialization cost but a negligible run time cost. The drawback is that the assumption that security providers do not change in run time is not correct for all use-cases. #2 ............................... We create many cipher instances to decide if an algorithm is supported and one of them -depending on which ciphersuite the server chooses- will be used. We can make something to avoid creating an instance we already had. Gain would be very low I guess because most of the instances would be wasted. Is there something else on your mind? What do you think of this options? I'll keep thinking. Kind regards, Martin.- On 5/7/19 4:53 PM, Xuelei Fan wrote: > Hi Martin, > > Would you mind evaluate the performance impact of the fix and improve it > accordingly? > > Thanks, > Xuelei > > On 5/7/2019 12:45 PM, Martin Balao wrote: >> Hi, >> >> I'd like to propose a fix for "8223482: Unsupported ciphersuites may be >> offered by a TLS client" [1]: >> >> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ >> >> Testing: >> >> ? * FipsModeTLS12 (after Webrev.00 modifications) reproduces this bug and >> works as a regression test >> >> ? * No regressions found in jdk/sun/security/ssl >> >> I'd be grateful if someone can have a look. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8223482 >> From xuelei.fan at oracle.com Tue May 7 22:52:07 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 May 2019 15:52:07 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> Message-ID: <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> If I remember correct, there was a serious performance impact when trying to check every crypto operations before using them (suspend for seconds or minutes, I cannot remember numbers). That's the underlying reason why most of the checking got removed in latest JDK releases. The best approach is still not checking. If it is too ideal, checking at least as possible. An provider MUST support the JDK required algorithms; and provider MUST support TLS required algorithms. So there is no need to check those algorithms. What happens if a provider does not support those algorithms? Configure the application to avoid the use of the algorithms, or don't use the provider, as the workaround. Anyway, it depends on the benchmark. If the performance impact is minimal, we are happy. Otherwise, we may want to think about alternative solutions. Thanks, Xuelei On 5/7/2019 1:33 PM, Martin Balao wrote: > Hi Xuelei, > > Thanks for having a look. > > I'll work on a benchmark to see the impact of this proposal. > > I have a couple of ideas but wish we could discuss them before moving to > their implementation. > > #1 > ............................... > > Under the assumption that security providers do not change in run time, > we can store "supports" results when SSLCipher instances are created. > There would be a static initialization cost but a negligible run time > cost. The drawback is that the assumption that security providers do not > change in run time is not correct for all use-cases. > > #2 > ............................... > > We create many cipher instances to decide if an algorithm is supported > and one of them -depending on which ciphersuite the server chooses- will > be used. We can make something to avoid creating an instance we already > had. Gain would be very low I guess because most of the instances would > be wasted. > > Is there something else on your mind? What do you think of this options? > > I'll keep thinking. > > Kind regards, > Martin.- > > > > On 5/7/19 4:53 PM, Xuelei Fan wrote: >> Hi Martin, >> >> Would you mind evaluate the performance impact of the fix and improve it >> accordingly? >> >> Thanks, >> Xuelei >> >> On 5/7/2019 12:45 PM, Martin Balao wrote: >>> Hi, >>> >>> I'd like to propose a fix for "8223482: Unsupported ciphersuites may be >>> offered by a TLS client" [1]: >>> >>> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ >>> >>> Testing: >>> >>> ? * FipsModeTLS12 (after Webrev.00 modifications) reproduces this bug and >>> works as a regression test >>> >>> ? * No regressions found in jdk/sun/security/ssl >>> >>> I'd be grateful if someone can have a look. >>> >>> Thanks, >>> Martin.- >>> >>> -- >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8223482 >>> > From christoph.langer at sap.com Wed May 8 08:21:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 08:21:17 +0000 Subject: RFR(XS): 8223555: Cleanups in cacerts tests Message-ID: Hi, please review this small change which contains a few minor cleanups to the tests for the CA certificates. I had it in my mercurial queue for quite some time and always wanted to contribute it ?? Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223555.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223555 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed May 8 13:57:33 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 May 2019 06:57:33 -0700 Subject: RFR(XS): 8223555: Cleanups in cacerts tests In-Reply-To: References: Message-ID: <80f7649a-88a7-5cc1-9548-bc3ca62c8b0f@oracle.com> Hi Christoph, Did you see compiler warning for the files? I tried with the JDK repository build, no compiler warning message. The update is safe. I may miss something about why we want to make the update. Thanks, Xuelei On 5/8/2019 1:21 AM, Langer, Christoph wrote: > Hi, > > please review this small change which contains a few minor cleanups to > the tests for the CA certificates. I had it in my mercurial queue for > quite some time and always wanted to contribute it ?? > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223555.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223555 > > Thanks > > Christoph > From christoph.langer at sap.com Wed May 8 14:01:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 14:01:45 +0000 Subject: RFR(XS): 8223555: Cleanups in cacerts tests In-Reply-To: <80f7649a-88a7-5cc1-9548-bc3ca62c8b0f@oracle.com> References: <80f7649a-88a7-5cc1-9548-bc3ca62c8b0f@oracle.com> Message-ID: Hi Xuelei, thanks for looking. The warnings would appear in my Eclipse IDE. During the tests (build) nothing had been observed and this will hopefully still be the same. ?? So you are good with the changes? Best regards Christoph > -----Original Message----- > From: Xuelei Fan > Sent: Mittwoch, 8. Mai 2019 15:58 > To: Langer, Christoph ; security-dev dev at openjdk.java.net> > Subject: Re: RFR(XS): 8223555: Cleanups in cacerts tests > > Hi Christoph, > > Did you see compiler warning for the files? I tried with the JDK > repository build, no compiler warning message. The update is safe. I > may miss something about why we want to make the update. > > Thanks, > Xuelei > > On 5/8/2019 1:21 AM, Langer, Christoph wrote: > > Hi, > > > > please review this small change which contains a few minor cleanups to > > the tests for the CA certificates. I had it in my mercurial queue for > > quite some time and always wanted to contribute it ?? > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223555.0/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223555 > > > > Thanks > > > > Christoph > > From xuelei.fan at oracle.com Wed May 8 14:06:01 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 May 2019 07:06:01 -0700 Subject: RFR(XS): 8223555: Cleanups in cacerts tests In-Reply-To: References: <80f7649a-88a7-5cc1-9548-bc3ca62c8b0f@oracle.com> Message-ID: Thank you! Yes, the change is good to me. Regards, Xuelei On 5/8/2019 7:01 AM, Langer, Christoph wrote: > Hi Xuelei, > > thanks for looking. > > The warnings would appear in my Eclipse IDE. During the tests (build) nothing had been observed and this will hopefully still be the same. ?? > > So you are good with the changes? > > Best regards > Christoph > >> -----Original Message----- >> From: Xuelei Fan >> Sent: Mittwoch, 8. Mai 2019 15:58 >> To: Langer, Christoph ; security-dev > dev at openjdk.java.net> >> Subject: Re: RFR(XS): 8223555: Cleanups in cacerts tests >> >> Hi Christoph, >> >> Did you see compiler warning for the files? I tried with the JDK >> repository build, no compiler warning message. The update is safe. I >> may miss something about why we want to make the update. >> >> Thanks, >> Xuelei >> >> On 5/8/2019 1:21 AM, Langer, Christoph wrote: >>> Hi, >>> >>> please review this small change which contains a few minor cleanups to >>> the tests for the CA certificates. I had it in my mercurial queue for >>> quite some time and always wanted to contribute it ?? >>> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223555.0/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223555 >>> >>> Thanks >>> >>> Christoph >>> From weijun.wang at oracle.com Wed May 8 14:58:48 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 May 2019 22:58:48 +0800 Subject: RFR 8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC Message-ID: <60CBA5B8-1421-4357-A642-5E5D2842EE27@oracle.com> This test timed out on solaris-sparc multiple times while generating an 8192-bit RSA key pair. Since the test is used to ensure keytool's support for the RSASSA-PSS algorithm (and the default signature algorithm depending on the key size) it's not platform related. Therefore I suggest simply ignoring the test on Solaris. Please take a review on the patch below: diff --git a/test/jdk/sun/security/tools/keytool/PSS.java b/test/jdk/sun/security/tools/keytool/PSS.java --- a/test/jdk/sun/security/tools/keytool/PSS.java +++ b/test/jdk/sun/security/tools/keytool/PSS.java @@ -23,11 +23,12 @@ /* * @test - * @bug 8215694 + * @bug 8215694 8222987 * @summary keytool cannot generate RSASSA-PSS certificates * @library /test/lib * @modules java.base/sun.security.util * java.base/sun.security.x509 + * @requires os.family != "solaris" * @run main PSS */ Thanks, Max From sean.mullan at oracle.com Wed May 8 16:24:04 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 May 2019 12:24:04 -0400 Subject: RFR 8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC In-Reply-To: <60CBA5B8-1421-4357-A642-5E5D2842EE27@oracle.com> References: <60CBA5B8-1421-4357-A642-5E5D2842EE27@oracle.com> Message-ID: <608cb243-c1da-23bd-e761-c1b976f22168@oracle.com> I think it would be useful to add a comment in the test and/or in the bug report with a brief explanation as to why it is not run on Solaris. Otherwise, fix looks fine. --Sean On 5/8/19 10:58 AM, Weijun Wang wrote: > This test timed out on solaris-sparc multiple times while generating an 8192-bit RSA key pair. Since the test is used to ensure keytool's support for the RSASSA-PSS algorithm (and the default signature algorithm depending on the key size) it's not platform related. Therefore I suggest simply ignoring the test on Solaris. > > Please take a review on the patch below: > > diff --git a/test/jdk/sun/security/tools/keytool/PSS.java b/test/jdk/sun/security/tools/keytool/PSS.java > --- a/test/jdk/sun/security/tools/keytool/PSS.java > +++ b/test/jdk/sun/security/tools/keytool/PSS.java > @@ -23,11 +23,12 @@ > > /* > * @test > - * @bug 8215694 > + * @bug 8215694 8222987 > * @summary keytool cannot generate RSASSA-PSS certificates > * @library /test/lib > * @modules java.base/sun.security.util > * java.base/sun.security.x509 > + * @requires os.family != "solaris" > * @run main PSS > */ > > Thanks, > Max > From xuelei.fan at oracle.com Wed May 8 15:32:13 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 May 2019 08:32:13 -0700 Subject: RFR 8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC In-Reply-To: <60CBA5B8-1421-4357-A642-5E5D2842EE27@oracle.com> References: <60CBA5B8-1421-4357-A642-5E5D2842EE27@oracle.com> Message-ID: <241aad5e-784a-37a7-b407-020c69d5854e@oracle.com> It looks good to me. Xuelei On 5/8/2019 7:58 AM, Weijun Wang wrote: > This test timed out on solaris-sparc multiple times while generating an 8192-bit RSA key pair. Since the test is used to ensure keytool's support for the RSASSA-PSS algorithm (and the default signature algorithm depending on the key size) it's not platform related. Therefore I suggest simply ignoring the test on Solaris. > > Please take a review on the patch below: > > diff --git a/test/jdk/sun/security/tools/keytool/PSS.java b/test/jdk/sun/security/tools/keytool/PSS.java > --- a/test/jdk/sun/security/tools/keytool/PSS.java > +++ b/test/jdk/sun/security/tools/keytool/PSS.java > @@ -23,11 +23,12 @@ > > /* > * @test > - * @bug 8215694 > + * @bug 8215694 8222987 > * @summary keytool cannot generate RSASSA-PSS certificates > * @library /test/lib > * @modules java.base/sun.security.util > * java.base/sun.security.x509 > + * @requires os.family != "solaris" > * @run main PSS > */ > > Thanks, > Max > From weijun.wang at oracle.com Thu May 9 00:51:25 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 May 2019 08:51:25 +0800 Subject: RFR 8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC In-Reply-To: <608cb243-c1da-23bd-e761-c1b976f22168@oracle.com> References: <60CBA5B8-1421-4357-A642-5E5D2842EE27@oracle.com> <608cb243-c1da-23bd-e761-c1b976f22168@oracle.com> Message-ID: <36F6CDAE-FB40-4493-87E6-73ED436F9F42@oracle.com> I've added comments to both and pushed it. Thanks, Max > On May 9, 2019, at 12:24 AM, Sean Mullan wrote: > > I think it would be useful to add a comment in the test and/or in the bug report with a brief explanation as to why it is not run on Solaris. Otherwise, fix looks fine. > > --Sean > > On 5/8/19 10:58 AM, Weijun Wang wrote: >> This test timed out on solaris-sparc multiple times while generating an 8192-bit RSA key pair. Since the test is used to ensure keytool's support for the RSASSA-PSS algorithm (and the default signature algorithm depending on the key size) it's not platform related. Therefore I suggest simply ignoring the test on Solaris. >> Please take a review on the patch below: >> diff --git a/test/jdk/sun/security/tools/keytool/PSS.java b/test/jdk/sun/security/tools/keytool/PSS.java >> --- a/test/jdk/sun/security/tools/keytool/PSS.java >> +++ b/test/jdk/sun/security/tools/keytool/PSS.java >> @@ -23,11 +23,12 @@ >> /* >> * @test >> - * @bug 8215694 >> + * @bug 8215694 8222987 >> * @summary keytool cannot generate RSASSA-PSS certificates >> * @library /test/lib >> * @modules java.base/sun.security.util >> * java.base/sun.security.x509 >> + * @requires os.family != "solaris" >> * @run main PSS >> */ >> Thanks, >> Max From weijun.wang at oracle.com Thu May 9 03:40:49 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 May 2019 11:40:49 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190507165335.GA7457@twosigma.com> References: <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> Message-ID: <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> Wow, this is overwhelming. Please post updated webrevs here and we will push the final agreed version, one by one. IANAL, but I think the principal is that the content of all changes should be from you -- the OCA signers. As long as there is only discussion and no actual code contribution, talking about these on GitHub or anywhere else is OK. Thanks, Max > On May 8, 2019, at 12:53 AM, Nico Williams wrote: > > On Thu, Mar 21, 2019 at 11:01:32AM +0800, Weijun Wang wrote: >> All of them at >> >> https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams >> >> You might want to add more descriptions. > > Below is the commentary I've collated from GitHub, along with my > responses. From weijun.wang at oracle.com Thu May 9 04:43:04 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 May 2019 12:43:04 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> References: <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> Message-ID: > On May 9, 2019, at 11:40 AM, Weijun Wang wrote: > > Wow, this is overwhelming. Please post updated webrevs here and we will push the final agreed version, one by one. Also, all your comments and responses posted in the previous mail are on files but not on a specific bug. Now that all bugs/RFEs are created [2], for each change, you can either post a new webrev, or use one I posted earlier [1]. We will then discuss on it, and you can collect your internal discussions between you three and post it here, update the webrev if necessary, and then I will push the final change for you (before you become a committer). --Max [1] http://cr.openjdk.java.net/~weijun/twosigma-gss/ [2] https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams From weijun.wang at oracle.com Thu May 9 08:44:22 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 May 2019 16:44:22 +0800 Subject: RFR 8221719: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: <1556720061.2432.25.camel@paratix.ch> References: <1550666474.2433.13.camel@paratix.ch> <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> <1556603804.2432.11.camel@paratix.ch> <1556720061.2432.25.camel@paratix.ch> Message-ID: <377A65F8-6E14-47CE-A6A2-F2EF0C64F717@oracle.com> Hi Philipp, I've posted your patch at http://cr.openjdk.java.net/~weijun/8221719/webrev.00/ Everyone please take a review. I think it looks fine. Just one question: why do you need to create the Manifest in the test. Can you just create a jar without MANIFEST.MF and let jarsigner add it? Thanks, Max > On May 1, 2019, at 10:14 PM, Philipp Kunz wrote: > > Hi Max and everyone, > > With respect to the previous patch, parentheses moved from storeHash to printCert, bug number added, and some comments added and clarified. > > Regards, > Philipp > > From weijun.wang at oracle.com Thu May 9 08:47:57 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 May 2019 16:47:57 +0800 Subject: RFR 8223063: Support CNG RSA keys In-Reply-To: References: Message-ID: <2A93C2F9-32C9-44FE-B46C-018E8980971A@oracle.com> Updated webrev at http://cr.openjdk.java.net/~weijun/8223063/webrev.01/ Mostly test change. One unused export removed. Thanks, Max > On May 1, 2019, at 7:18 AM, Weijun Wang wrote: > > Please take a look at > > https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ > > Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with > > Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] > A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 > A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 > CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) > CertUtil: The requested operation is not supported. > > Maybe there is a permission issue. > > I'll study it for more, but If anyone of you can fix it I'll be very happy. > > Thanks, > Max > From sean.coffey at oracle.com Thu May 9 15:29:23 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 May 2019 16:29:23 +0100 Subject: RFR: 8191808: Configurable read timeout for CRLs In-Reply-To: <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> References: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> Message-ID: <4c9d0ac1-52e6-5439-0dd7-cd0a5f2770aa@oracle.com> Nice feature to have Sean. Thanks. What do you think about adding a debug print if such a value is set ? (perhaps in initializeTimeout method) regards, Sean. On 07/05/2019 17:16, Sean Mullan wrote: > On 5/7/19 11:28 AM, Xuelei Fan wrote: >> What do you think if com.sun.security.crl.readtimeout is not set, >> CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT? > > There may be good reasons you would want different values for these > two properties, so if com.sun.security.crl.readtimeout is not set, I > think it is better to have a fixed default value and not have it be > the same as CRL_CONNECT_TIMEOUT. > >> >> Otherwise, looks fine to me. > > Thanks. Could you also add your name as the CSR Reviewer? > > --Sean > >> >> Xuelei >> >> On 5/7/2019 7:28 AM, Sean Mullan wrote: >>> Please review this change to add a system property for configuring >>> the read timeout when downloading CRLs with a default value of 15 >>> seconds. Currently there is no timeout so downloads of large CRLs >>> can block for a long time or indefinitely. Current workaround is to >>> use the sun.net.client.defaultReadTimeout system property but that >>> affects all connections. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8191808 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ >>> >>> Thanks, >>> Sean From Nico.Williams at twosigma.com Thu May 9 15:51:03 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 9 May 2019 15:51:03 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> References: <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> Message-ID: <20190509155103.GB7457@twosigma.com> On Thu, May 09, 2019 at 11:40:49AM +0800, Weijun Wang wrote: > Wow, this is overwhelming. Please post updated webrevs here and we will push > the final agreed version, one by one. I posted only the collated commentary from GitHub and my responses to the comments. The "diffs" in the commentary are what appeared in the emails GitHub sent me for each comment made -- they aren't proposed changes but changes that I had made being quoted by those emails. I haven't yet made all the changes I agreed to make, so there's no new webrevs to post yet. > IANAL, but I think the principal is that the content of all changes should be > from you -- the OCA signers. As long as there is only discussion and no > actual code contribution, talking about these on GitHub or anywhere else is > OK. No changes were contributed by the reviewers. I'm the source of all changes. The OCA is not being violated. Nico -- From Nico.Williams at twosigma.com Thu May 9 15:53:52 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 9 May 2019 15:53:52 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> Message-ID: <20190509155352.GC7457@twosigma.com> On Thu, May 09, 2019 at 12:43:04PM +0800, Weijun Wang wrote: > Also, all your comments and responses posted in the previous mail are > on files but not on a specific bug. Now that all bugs/RFEs are created > [...] When I'm done making the changes I agreed to make, I'll make sure to have a "fixup" commit for each change naming the original commit it is modifying so that you'll be able to see those changes, then we can squash them later. If you have not reviewed any of my contribution yet, then I might as well just squash the changes I make in response to external code review. Nico -- From sean.mullan at oracle.com Thu May 9 16:38:55 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 May 2019 12:38:55 -0400 Subject: RFR: 8191808: Configurable read timeout for CRLs In-Reply-To: <4c9d0ac1-52e6-5439-0dd7-cd0a5f2770aa@oracle.com> References: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> <4c9d0ac1-52e6-5439-0dd7-cd0a5f2770aa@oracle.com> Message-ID: <05cf926b-189b-d7ac-32b8-5ec4618a3773@oracle.com> On 5/9/19 11:29 AM, Se?n Coffey wrote: > Nice feature to have Sean. Thanks. > > What do you think about adding a debug print if such a value is set ? > (perhaps in initializeTimeout method) Good suggestion. I've added the following to the intializeTimeout method: + private static int initializeTimeout(String prop, int def) { + Integer tmp = GetIntegerAction.privilegedGetProperty(prop); if (tmp == null || tmp < 0) { - return DEFAULT_CRL_CONNECT_TIMEOUT; + return def; + } + if (debug != null) { + debug.println(prop + " set to " + tmp + " seconds"); } --Sean > > regards, > Sean. > > On 07/05/2019 17:16, Sean Mullan wrote: >> On 5/7/19 11:28 AM, Xuelei Fan wrote: >>> What do you think if com.sun.security.crl.readtimeout is not set, >>> CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT? >> >> There may be good reasons you would want different values for these >> two properties, so if com.sun.security.crl.readtimeout is not set, I >> think it is better to have a fixed default value and not have it be >> the same as CRL_CONNECT_TIMEOUT. >> >>> >>> Otherwise, looks fine to me. >> >> Thanks. Could you also add your name as the CSR Reviewer? >> >> --Sean >> >>> >>> Xuelei >>> >>> On 5/7/2019 7:28 AM, Sean Mullan wrote: >>>> Please review this change to add a system property for configuring >>>> the read timeout when downloading CRLs with a default value of 15 >>>> seconds. Currently there is no timeout so downloads of large CRLs >>>> can block for a long time or indefinitely. Current workaround is to >>>> use the sun.net.client.defaultReadTimeout system property but that >>>> affects all connections. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8191808 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ >>>> >>>> Thanks, >>>> Sean From sean.coffey at oracle.com Thu May 9 16:46:09 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 May 2019 17:46:09 +0100 Subject: RFR: 8191808: Configurable read timeout for CRLs In-Reply-To: <05cf926b-189b-d7ac-32b8-5ec4618a3773@oracle.com> References: <9ae16cba-9f72-a6cf-3655-17431be9cab4@oracle.com> <61718194-370d-08f7-afed-274a495a1aa7@oracle.com> <4c9d0ac1-52e6-5439-0dd7-cd0a5f2770aa@oracle.com> <05cf926b-189b-d7ac-32b8-5ec4618a3773@oracle.com> Message-ID: <42cc52f8-b1eb-689e-ac60-84af4e034693@oracle.com> Thanks. Looks good. regards, Sean. On 09/05/2019 17:38, Sean Mullan wrote: > On 5/9/19 11:29 AM, Se?n Coffey wrote: >> Nice feature to have Sean. Thanks. >> >> What do you think about adding a debug print if such a value is set ? >> (perhaps in initializeTimeout method) > > Good suggestion. I've added the following to the intializeTimeout method: > > +??? private static int initializeTimeout(String prop, int def) { > +??????? Integer tmp = GetIntegerAction.privilegedGetProperty(prop); > ???????? if (tmp == null || tmp < 0) { > -??????????? return DEFAULT_CRL_CONNECT_TIMEOUT; > +??????????? return def; > +??????? } > +??????? if (debug != null) { > +??????????? debug.println(prop + " set to " + tmp + " seconds"); > ???????? } > > --Sean > >> >> regards, >> Sean. >> >> On 07/05/2019 17:16, Sean Mullan wrote: >>> On 5/7/19 11:28 AM, Xuelei Fan wrote: >>>> What do you think if com.sun.security.crl.readtimeout is not set, >>>> CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT? >>> >>> There may be good reasons you would want different values for these >>> two properties, so if com.sun.security.crl.readtimeout is not set, I >>> think it is better to have a fixed default value and not have it be >>> the same as CRL_CONNECT_TIMEOUT. >>> >>>> >>>> Otherwise, looks fine to me. >>> >>> Thanks. Could you also add your name as the CSR Reviewer? >>> >>> --Sean >>> >>>> >>>> Xuelei >>>> >>>> On 5/7/2019 7:28 AM, Sean Mullan wrote: >>>>> Please review this change to add a system property for configuring >>>>> the read timeout when downloading CRLs with a default value of 15 >>>>> seconds. Currently there is no timeout so downloads of large CRLs >>>>> can block for a long time or indefinitely. Current workaround is >>>>> to use the sun.net.client.defaultReadTimeout system property but >>>>> that affects all connections. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8191808 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223310 >>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191808/webrev.00/ >>>>> >>>>> Thanks, >>>>> Sean From sean.mullan at oracle.com Thu May 9 18:42:48 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 May 2019 14:42:48 -0400 Subject: 8200400: Restrict Sasl mechanisms In-Reply-To: References: <90B87CA3-2BEC-4AFC-A05A-BD727FA6635E@oracle.com> <68b87231-0732-3283-e8d9-e3b3fd5d8a86@oracle.com> Message-ID: <2a687dac-b0c6-f813-c6d8-903909ff86bd@oracle.com> Looks good, but just a reminder to change system to security property in the javadoc per Joe's comment in the CSR. --Sean On 5/7/19 11:31 AM, Weijun Wang wrote: > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8200400/webrev.02/ > > The CSR at https://bugs.openjdk.java.net/browse/JDK-821433 is also updated. > > I reuse the Logger name "javax.security.sasl" used by our SASL providers. The name looks high-level enough to be used here. > > Thanks, > Max > > >> On May 7, 2019, at 2:06 AM, Sean Mullan wrote: >> >> On 5/5/19 1:06 AM, Weijun Wang wrote: >>> Please take a review at >>> https://cr.openjdk.java.net/~weijun/8200400/webrev.01/ >> >> The java.security property description is not up-to-date with the CSR. Also, we don't support a system property override in the other jdk.*.disabled properties. So I don't think we should add that unless or until we see a need for it. >> >> In Sasl.java, can we log or add some debug information if a mechanism is disabled? Otherwise it can be hard to debug. >> >> --Sean >> >>> There is a CSR at >>> https://bugs.openjdk.java.net/browse/JDK-8214331 >>> Thanks, >>> Max > From xuelei.fan at oracle.com Thu May 9 20:28:06 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 9 May 2019 13:28:06 -0700 Subject: Code Review Request, 8221253: TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 bytes Message-ID: Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8221253/webrev.00/ Because of the padding impact, the TLS 1.3 record in the JDK Reference implementation could exceed the limit. It is not the expected behavior. Thanks, Xuelei From weijun.wang at oracle.com Fri May 10 06:23:22 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 May 2019 14:23:22 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190509155352.GC7457@twosigma.com> References: <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> <20190509155352.GC7457@twosigma.com> Message-ID: <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> I have read some but probably not as strictly as a reviewer. Anyway, let's start dealing with them one by one. The following 2 lists should have the same orders. https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams%20ORDER%20BY%20key%20ASC http://cr.openjdk.java.net/~weijun/twosigma-gss/ Each needs at least a code review request, zero or more feedback, and one yes as the record that it is reviewed. Thanks, Max > On May 9, 2019, at 11:53 PM, Nico Williams wrote: > > On Thu, May 09, 2019 at 12:43:04PM +0800, Weijun Wang wrote: >> Also, all your comments and responses posted in the previous mail are >> on files but not on a specific bug. Now that all bugs/RFEs are created >> [...] > > When I'm done making the changes I agreed to make, I'll make sure to > have a "fixup" commit for each change naming the original commit it is > modifying so that you'll be able to see those changes, then we can > squash them later. > > If you have not reviewed any of my contribution yet, then I might as > well just squash the changes I make in response to external code review. > > Nico > -- From weijun.wang at oracle.com Fri May 10 09:04:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 May 2019 17:04:38 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE Message-ID: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> Please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8223682 The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. The code change is exactly the same as the specification, so no webrev. Thanks, Max From Nico.Williams at twosigma.com Fri May 10 15:55:18 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 10 May 2019 15:55:18 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> References: <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> <20190509155352.GC7457@twosigma.com> <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> Message-ID: <20190510155518.GD7457@twosigma.com> On Fri, May 10, 2019 at 02:23:22PM +0800, Weijun Wang wrote: > I have read some but probably not as strictly as a reviewer. Anyway, let's start dealing with them one by one. > > The following 2 lists should have the same orders. > > https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams%20ORDER%20BY%20key%20ASC > > http://cr.openjdk.java.net/~weijun/twosigma-gss/ > > Each needs at least a code review request, zero or more feedback, and one yes > as the record that it is reviewed. Who can review? From jamil.j.nimeh at oracle.com Fri May 10 16:22:17 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 10 May 2019 09:22:17 -0700 Subject: Code Review Request, 8221253: TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 bytes In-Reply-To: References: Message-ID: <0d3332f6-a4f7-7b66-1948-a13a5454d450@oracle.com> This looks good to me.? One question, more for my curiosity than anything else: Is the way you loaded the appData array in the test code done for any specific reason?? Or did you just want to make sure you had printable ASCII that wasn't all just the same character, so it looked "random-ish"? --Jamil On 5/9/2019 1:28 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > ?? http://cr.openjdk.java.net/~xuelei/8221253/webrev.00/ > > Because of the padding impact, the TLS 1.3 record in the JDK Reference > implementation could exceed the limit.? It is not the expected behavior. > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri May 10 16:30:16 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 May 2019 09:30:16 -0700 Subject: Code Review Request, 8221253: TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 bytes In-Reply-To: <0d3332f6-a4f7-7b66-1948-a13a5454d450@oracle.com> References: <0d3332f6-a4f7-7b66-1948-a13a5454d450@oracle.com> Message-ID: <1e189ab8-e985-f703-d63a-c3efda9fdc21@oracle.com> Hi Jamil, Thank you for the review. On 5/10/2019 9:22 AM, Jamil Nimeh wrote: > This looks good to me.? One question, more for my curiosity than > anything else: Is the way you loaded the appData array in the test code > done for any specific reason?? Or did you just want to make sure you had > printable ASCII that wasn't all just the same character, so it looked > "random-ish"? > I used the printable ASCII bytes for debug log checking. It is easier to analysis the SSL record log with printable code. Thanks, Xuelei > --Jamil > > On 5/9/2019 1:28 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> ?? http://cr.openjdk.java.net/~xuelei/8221253/webrev.00/ >> >> Because of the padding impact, the TLS 1.3 record in the JDK Reference >> implementation could exceed the limit.? It is not the expected behavior. >> >> Thanks, >> Xuelei > From sean.mullan at oracle.com Fri May 10 20:44:27 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 10 May 2019 16:44:27 -0400 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> Message-ID: On 5/10/19 5:04 AM, Weijun Wang wrote: > Please take a review at the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8223682 Add an "@since 13" to the new constant. > > The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. > > One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? --Sean > > The code change is exactly the same as the specification, so no webrev. > > Thanks, > Max > From valerie.peng at oracle.com Fri May 10 23:36:41 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 10 May 2019 16:36:41 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> Message-ID: Hi Xuelei, Based on our earlier discussions, I experimented with a few approaches and updated the changes accordingly: http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/ Please let me know if you have more comments. Thanks, Valerie On 4/19/2019 3:58 PM, Valerie Peng wrote: > Ok, thanks for the double checking suggestion. > > Given the somewhat limited number of providers, I am exploring other > data structures such as WeakHashMap. > > Will have to put this on hold during my upcoming week-long vacation > and resume on 4/29. > > Thanks! > Valerie > On 4/16/2019 3:43 PM, Xuelei Fan wrote: >> On 4/16/2019 2:16 PM, Valerie Peng wrote: >>> Hi Xuelei, >>> >>> Thanks for the comments. >>> >>> On 4/16/2019 8:58 AM, Xuelei Fan wrote: >>>> 213-217: >>>> Previously, the set/get of both verificationResults and >>>> verifyingProviders are synchronized.? With this update, the get of >>>> verificationResults is not out of the set synchronized block, so >>>> there is a competition introduced.? I think it would be nice to >>>> double check the verificationResults in the synchronized block. >>>> ? synchronized (JceSecurity.class) { >>>> +???? //? double check if the provider has been verified >>>> ????? ... >>>> ? } >>>> >>> Hmm, are you talking about the verificationResults.get(pKey) call >>> (line 206) and move it inside the block of synchronized >>> (JceSecurity.class) (line 212)? >> I meant to get/check twice. >> ... getVerificationResult(Provider p) { >> ??? ... >> // get/check block >> ??? Object o = verificationResults.get(pKey); >> ??? if ( o == ...) { >> ??????? ... >> ??? } else if (o != null) { >> ??????? ... >> ??? } >> >> ??? synchronized (JceSecurity.class) { >> ?????? // double check if the provider has been verified. >> // use the get/check block again >> ?????? Object o = verificationResults.get(pKey); >> ?????? if ( o == ...) { >> ?????????? ... >> ?????? } else if (o != null) { >> ?????????? ... >> ?????? } >> >> ?????? // further operation is the provider has not been verified. >> ?????? .... >> ??? } >> } >> >>> If that's what you suggest, I think that'd take away the key idea of >>> this performance rfe fix. My understanding of the patch is to use a >>> ConcurrentHashMap for "verificationResult" so accesses to this >>> "verificationResult" cache are controlled by the finer-grained model >>> of ConcurrentHashMap. On the other hand, verifyingProviders map and >>> the time consuming/potentially complex verifyProvider(...) call are >>> still inside the synchronized (JceSecurity.class) block. Maybe it'd >>> be clearer if I had re-written the code and move the >>> verificationResults.put(...) calls outside of the synchronized >>> (JceSecurity.class) block. The way I look at it, this change >>> separates out the "verificationResult" cache from the rest of the >>> provider verification logic and uses ConcurrentHashMap instead of >>> JceSecurity.class in order to improve performance. >>> >> I think there is a competition.? If two threads try to get the lock, >> line 212-227 get executed in both thread.? The double checking scheme >> could avoid it as when the 2nd thread get the lock, it will use the >> result of the 1st thread. >> >>>> I did not get the idea to use verifyingProviders.? In line 219, a >>>> provider was inserted into the map, and in the final block, line >>>> 235, the provider was removed from the map.? There is no other >>>> update of the map, so the map should always be empty and not really >>>> used. Am I missing something?? Could the verifyingProviders field >>>> get removed? >>>> >>> The verifyingProviders field is for detecting potential recursions >>> during the provider verification. the verifyProvider(URL, Provider) >>> call will call ProviderVerifier.verify(). This will trigger provider >>> jar file verification. Depending on runtime provider verification, >>> this may trigger another provider being loaded/verified. As >>> getVerificationResult(Provider) is being called by the pkg private >>> static method JceSecurity.getInstance(...) which is used internally >>> by other JCA classes, it's possible for getVerificationResult(...) >>> to be recursively called and thus the verifyingProviders field will >>> help detect if somehow verifying the current provider will require >>> loading another JCA service from the current provider. >>> >> I see the point now.? Thanks! >> >>>> >>>> 406-426: >>>> I may add a blank line between two different blocks (methods, field >>>> and methods). >>>> >>> Sure, added. >>> >>> >>>> - 416 if (o instanceof IdentityWrapper == false) { >>>> + 416? if (!(o instanceof IdentityWrapper)) { >>>> >>>> I prefer to use "!" operator. >>> >>> Sure. >>> >> Thanks! >> >> Xuelei >> >>> Webrev updated at: >>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.01/ >>> >>> Thanks, >>> Valerie >>>> >>>> Xuelei >>>> >>>> On 4/15/2019 6:20 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has time to review this performance rfe? The fix is based >>>>> on Sergey's suggested patch. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ >>>>> >>>>> Mach5 run is clean. >>>>> >>>>> Thanks, >>>>> Valerie From weijun.wang at oracle.com Sat May 11 00:02:48 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 11 May 2019 08:02:48 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190510155518.GD7457@twosigma.com> References: <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> <20190509155352.GC7457@twosigma.com> <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> <20190510155518.GD7457@twosigma.com> Message-ID: <4CB61EBE-5BF7-4C11-A5D4-0DA416458CDF@oracle.com> > On May 10, 2019, at 11:55 PM, Nico Williams wrote: > > On Fri, May 10, 2019 at 02:23:22PM +0800, Weijun Wang wrote: >> I have read some but probably not as strictly as a reviewer. Anyway, let's start dealing with them one by one. >> >> The following 2 lists should have the same orders. >> >> https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams%20ORDER%20BY%20key%20ASC >> >> http://cr.openjdk.java.net/~weijun/twosigma-gss/ >> >> Each needs at least a code review request, zero or more feedback, and one yes >> as the record that it is reviewed. > > Who can review? Anyone who is watching security-dev at . The mail list is quite active. We've done this before. Below are the first 3 code review threads of your contributions: 8212165: JGSS: Fix cut/paste error in NativeUtil.c https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018489.html 8212216: JGSS: Fix leak in exception cases in getJavaOID() https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018506.html 8212217: JGSS: Don't dispose() of creds too eagerly https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018507.html You can see Sean and Alan replying, and of course I'll also review all changes. Thanks, Max From mbalao at redhat.com Sat May 11 00:05:25 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 10 May 2019 21:05:25 -0300 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> Message-ID: Hi, I'd like to propose Webrev.02: * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.02/ Security properties were introduced mirroring System properties. See CSR [1]. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8223172 From weijun.wang at oracle.com Sat May 11 00:07:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 11 May 2019 08:07:19 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> Message-ID: <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> > On May 11, 2019, at 4:44 AM, Sean Mullan wrote: > > On 5/10/19 5:04 AM, Weijun Wang wrote: >> Please take a review at the CSR at >> https://bugs.openjdk.java.net/browse/JDK-8223682 > > Add an "@since 13" to the new constant. > >> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. > > I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? Maybe a little complicated? https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 --Max > > --Sean > >> The code change is exactly the same as the specification, so no webrev. >> Thanks, >> Max From xuelei.fan at oracle.com Sat May 11 01:48:16 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 May 2019 18:48:16 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> Message-ID: 208 synchronized (JceSecurity.class) { 229 synchronized(verificationResults) { I did not get the point to use two locks. Using one lock, either JceSecurity.class or verificationResults should be fine. 229-232: I did not get the point of these 4 lines. Could line 231 move between line 226 and 267, and remove line 228-232? 208 synchronized (JceSecurity.class) { 209 o = verificationResults.get(pKey); 210 if (o == null) { ... 224 } finally { 225 verifyingProviders.remove(p); 226 } + + verificationResults.put(pKey, o); 227 } Otherwise, looks fine to me. Thanks, Xuelei On 5/10/2019 4:36 PM, Valerie Peng wrote: > Hi Xuelei, > > Based on our earlier discussions, I experimented with a few approaches > and updated the changes accordingly: > > http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/ > > Please let me know if you have more comments. > > Thanks, > Valerie > On 4/19/2019 3:58 PM, Valerie Peng wrote: >> Ok, thanks for the double checking suggestion. >> >> Given the somewhat limited number of providers, I am exploring other >> data structures such as WeakHashMap. >> >> Will have to put this on hold during my upcoming week-long vacation >> and resume on 4/29. >> >> Thanks! >> Valerie >> On 4/16/2019 3:43 PM, Xuelei Fan wrote: >>> On 4/16/2019 2:16 PM, Valerie Peng wrote: >>>> Hi Xuelei, >>>> >>>> Thanks for the comments. >>>> >>>> On 4/16/2019 8:58 AM, Xuelei Fan wrote: >>>>> 213-217: >>>>> Previously, the set/get of both verificationResults and >>>>> verifyingProviders are synchronized.? With this update, the get of >>>>> verificationResults is not out of the set synchronized block, so >>>>> there is a competition introduced.? I think it would be nice to >>>>> double check the verificationResults in the synchronized block. >>>>> ? synchronized (JceSecurity.class) { >>>>> +???? //? double check if the provider has been verified >>>>> ????? ... >>>>> ? } >>>>> >>>> Hmm, are you talking about the verificationResults.get(pKey) call >>>> (line 206) and move it inside the block of synchronized >>>> (JceSecurity.class) (line 212)? >>> I meant to get/check twice. >>> ... getVerificationResult(Provider p) { >>> ??? ... >>> // get/check block >>> ??? Object o = verificationResults.get(pKey); >>> ??? if ( o == ...) { >>> ??????? ... >>> ??? } else if (o != null) { >>> ??????? ... >>> ??? } >>> >>> ??? synchronized (JceSecurity.class) { >>> ?????? // double check if the provider has been verified. >>> // use the get/check block again >>> ?????? Object o = verificationResults.get(pKey); >>> ?????? if ( o == ...) { >>> ?????????? ... >>> ?????? } else if (o != null) { >>> ?????????? ... >>> ?????? } >>> >>> ?????? // further operation is the provider has not been verified. >>> ?????? .... >>> ??? } >>> } >>> >>>> If that's what you suggest, I think that'd take away the key idea of >>>> this performance rfe fix. My understanding of the patch is to use a >>>> ConcurrentHashMap for "verificationResult" so accesses to this >>>> "verificationResult" cache are controlled by the finer-grained model >>>> of ConcurrentHashMap. On the other hand, verifyingProviders map and >>>> the time consuming/potentially complex verifyProvider(...) call are >>>> still inside the synchronized (JceSecurity.class) block. Maybe it'd >>>> be clearer if I had re-written the code and move the >>>> verificationResults.put(...) calls outside of the synchronized >>>> (JceSecurity.class) block. The way I look at it, this change >>>> separates out the "verificationResult" cache from the rest of the >>>> provider verification logic and uses ConcurrentHashMap instead of >>>> JceSecurity.class in order to improve performance. >>>> >>> I think there is a competition.? If two threads try to get the lock, >>> line 212-227 get executed in both thread.? The double checking scheme >>> could avoid it as when the 2nd thread get the lock, it will use the >>> result of the 1st thread. >>> >>>>> I did not get the idea to use verifyingProviders.? In line 219, a >>>>> provider was inserted into the map, and in the final block, line >>>>> 235, the provider was removed from the map.? There is no other >>>>> update of the map, so the map should always be empty and not really >>>>> used. Am I missing something?? Could the verifyingProviders field >>>>> get removed? >>>>> >>>> The verifyingProviders field is for detecting potential recursions >>>> during the provider verification. the verifyProvider(URL, Provider) >>>> call will call ProviderVerifier.verify(). This will trigger provider >>>> jar file verification. Depending on runtime provider verification, >>>> this may trigger another provider being loaded/verified. As >>>> getVerificationResult(Provider) is being called by the pkg private >>>> static method JceSecurity.getInstance(...) which is used internally >>>> by other JCA classes, it's possible for getVerificationResult(...) >>>> to be recursively called and thus the verifyingProviders field will >>>> help detect if somehow verifying the current provider will require >>>> loading another JCA service from the current provider. >>>> >>> I see the point now.? Thanks! >>> >>>>> >>>>> 406-426: >>>>> I may add a blank line between two different blocks (methods, field >>>>> and methods). >>>>> >>>> Sure, added. >>>> >>>> >>>>> - 416 if (o instanceof IdentityWrapper == false) { >>>>> + 416? if (!(o instanceof IdentityWrapper)) { >>>>> >>>>> I prefer to use "!" operator. >>>> >>>> Sure. >>>> >>> Thanks! >>> >>> Xuelei >>> >>>> Webrev updated at: >>>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.01/ >>>> >>>> Thanks, >>>> Valerie >>>>> >>>>> Xuelei >>>>> >>>>> On 4/15/2019 6:20 PM, Valerie Peng wrote: >>>>>> >>>>>> Anyone has time to review this performance rfe? The fix is based >>>>>> on Sergey's suggested patch. >>>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ >>>>>> >>>>>> Mach5 run is clean. >>>>>> >>>>>> Thanks, >>>>>> Valerie From philipp.kunz at paratix.ch Sat May 11 08:16:53 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 11 May 2019 10:16:53 +0200 Subject: RFR 8221719: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: <377A65F8-6E14-47CE-A6A2-F2EF0C64F717@oracle.com> References: <1550666474.2433.13.camel@paratix.ch> <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> <1556603804.2432.11.camel@paratix.ch> <1556720061.2432.25.camel@paratix.ch> <377A65F8-6E14-47CE-A6A2-F2EF0C64F717@oracle.com> Message-ID: <1557562613.2443.7.camel@paratix.ch> Hi Max, You are right. An explicit manifest is not necessary. I don't remember why I added it in the first place. It works also without it. Regards, Philipp On Thu, 2019-05-09 at 16:44 +0800, Weijun Wang wrote: > Hi Philipp, > > I've posted your patch at > > ???http://cr.openjdk.java.net/~weijun/8221719/webrev.00/ > > Everyone please take a review. > > I think it looks fine. Just one question: why do you need to create > the Manifest in the test. Can you just create a jar without > MANIFEST.MF and let jarsigner add it? > > Thanks, > Max > > > On May 1, 2019, at 10:14 PM, Philipp Kunz > > wrote: > > > > Hi Max and everyone, > > > > With respect to the previous patch, parentheses moved from > > storeHash to printCert, bug number added, and some comments added > > and clarified. > > > > Regards, > > Philipp > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20190511-JavaKeyStoreAliasCaseInsensitive.patch Type: text/x-patch Size: 10517 bytes Desc: not available URL: From weijun.wang at oracle.com Sat May 11 15:27:30 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 11 May 2019 23:27:30 +0800 Subject: RFR 8221719: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: <1557562613.2443.7.camel@paratix.ch> References: <1550666474.2433.13.camel@paratix.ch> <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> <1556603804.2432.11.camel@paratix.ch> <1556720061.2432.25.camel@paratix.ch> <377A65F8-6E14-47CE-A6A2-F2EF0C64F717@oracle.com> <1557562613.2443.7.camel@paratix.ch> Message-ID: Hi Phillip, I've posted the updated patch to https://cr.openjdk.java.net/~weijun/8221719/webrev.01 after making 2 tiny changes. 1) move @test above imports. 2) remove 2 useless imports. I'm fine with the change. If there's no one else with any extra comment, I'll push it. Thanks, Max > On May 11, 2019, at 4:16 PM, Philipp Kunz wrote: > > Hi Max, > > You are right. An explicit manifest is not necessary. I don't remember why I added it in the first place. It works also without it. > > Regards, > Philipp > > > On Thu, 2019-05-09 at 16:44 +0800, Weijun Wang wrote: >> Hi Philipp, >> >> I've posted your patch at >> >> >> http://cr.openjdk.java.net/~weijun/8221719/webrev.00/ >> >> >> Everyone please take a review. >> >> I think it looks fine. Just one question: why do you need to create the Manifest in the test. Can you just create a jar without MANIFEST.MF and let jarsigner add it? >> >> Thanks, >> Max >> >> >>> >>> On May 1, 2019, at 10:14 PM, Philipp Kunz < >>> philipp.kunz at paratix.ch >>> > wrote: >>> >>> Hi Max and everyone, >>> >>> With respect to the previous patch, parentheses moved from storeHash to printCert, bug number added, and some comments added and clarified. >>> >>> Regards, >>> Philipp >>> >>> >>> >> >> >> > <20190511-JavaKeyStoreAliasCaseInsensitive.patch> From daniel.fuchs at oracle.com Mon May 13 09:04:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 May 2019 10:04:55 +0100 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> Message-ID: Hi Valery, On 11/05/2019 00:36, Valerie Peng wrote: > http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/ > > Please let me know if you have more comments. If I'm not mistaken, the only thing that references the IdentityWrapper is the key in the WeakHashMap. Therefore, it is only weakly referenced and can be immediatly garbage collected. I don't think this is what you want? I believe what you are trying to achieve there is rather to use a plain ConcurrentHashMap, and have IdentityWrapper extend WeakReference instead. You may need to store the hashCode in IdentityWrapper so that it doesn't change when the underlying Provider is garbage collected. Then you can use a ReferenceQueue to purge the map regularly. Hope this helps, -- daniel From Alan.Bateman at oracle.com Mon May 13 09:36:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2019 10:36:37 +0100 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> Message-ID: On 13/05/2019 10:04, Daniel Fuchs wrote: > Hi Valery, > > On 11/05/2019 00:36, Valerie Peng wrote: >> http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/ >> >> Please let me know if you have more comments. > > If I'm not mistaken, the only thing that references > the IdentityWrapper is the key in the WeakHashMap. > Therefore, it is only weakly referenced and can be immediatly > garbage collected. I don't think this is what you want? > > I believe what you are trying to achieve there is rather to use > a plain ConcurrentHashMap, and have IdentityWrapper extend > WeakReference instead. You may need to store > the hashCode in IdentityWrapper so that it doesn't change > when the underlying Provider is garbage collected. > > Then you can use a ReferenceQueue to purge the map regularly. Right, plus getVerificationResult is accessing the WeakHashMap without synchronization. I think it would be useful to get a summary on whether this issue is trying to address one or two points. For the scalability point then I assume a CHM + computeIfAbsent would help. If the issue is also that you want the key (Provider) to be weak then it will require additional work, as Daniel points out. -Alan From sean.mullan at oracle.com Mon May 13 12:10:04 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 May 2019 08:10:04 -0400 Subject: RFR 8223063: Support CNG RSA keys In-Reply-To: <2A93C2F9-32C9-44FE-B46C-018E8980971A@oracle.com> References: <2A93C2F9-32C9-44FE-B46C-018E8980971A@oracle.com> Message-ID: <197f7a21-2f0d-6f7d-cd17-76b4a5687f70@oracle.com> Looks fine to me. I assume you resolved the mach5 issue below? --Sean On 5/9/19 4:47 AM, Weijun Wang wrote: > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8223063/webrev.01/ > > Mostly test change. One unused export removed. > > Thanks, > Max > >> On May 1, 2019, at 7:18 AM, Weijun Wang wrote: >> >> Please take a look at >> >> https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ >> >> Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with >> >> Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] >> A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 >> A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 >> CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) >> CertUtil: The requested operation is not supported. >> >> Maybe there is a permission issue. >> >> I'll study it for more, but If anyone of you can fix it I'll be very happy. >> >> Thanks, >> Max >> > From weijun.wang at oracle.com Mon May 13 13:10:29 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 13 May 2019 21:10:29 +0800 Subject: RFR 8223063: Support CNG RSA keys In-Reply-To: <197f7a21-2f0d-6f7d-cd17-76b4a5687f70@oracle.com> References: <2A93C2F9-32C9-44FE-B46C-018E8980971A@oracle.com> <197f7a21-2f0d-6f7d-cd17-76b4a5687f70@oracle.com> Message-ID: <8B6507C6-7AAA-4B4C-AC7E-A763BCB7A280@oracle.com> > On May 13, 2019, at 8:10 PM, Sean Mullan wrote: > > Looks fine to me. I assume you resolved the mach5 issue below? Yes. The test passes on Mach5 now after removing the '-f' option. --Max > > --Sean > > On 5/9/19 4:47 AM, Weijun Wang wrote: >> Updated webrev at >> http://cr.openjdk.java.net/~weijun/8223063/webrev.01/ >> Mostly test change. One unused export removed. >> Thanks, >> Max >>> On May 1, 2019, at 7:18 AM, Weijun Wang wrote: >>> >>> Please take a look at >>> >>> https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ >>> >>> Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with >>> >>> Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] >>> A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 >>> A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 >>> CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) >>> CertUtil: The requested operation is not supported. >>> >>> Maybe there is a permission issue. >>> >>> I'll study it for more, but If anyone of you can fix it I'll be very happy. >>> >>> Thanks, >>> Max >>> From sean.mullan at oracle.com Mon May 13 14:51:45 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 May 2019 10:51:45 -0400 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> Message-ID: <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> On 5/10/19 8:07 PM, Weijun Wang wrote: > > >> On May 11, 2019, at 4:44 AM, Sean Mullan wrote: >> >> On 5/10/19 5:04 AM, Weijun Wang wrote: >>> Please take a review at the CSR at >>> https://bugs.openjdk.java.net/browse/JDK-8223682 >> >> Add an "@since 13" to the new constant. >> >>> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >>> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. >> >> I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? > > Maybe a little complicated? > > https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 Yes, perhaps, or more likely because it is optional to support ECParameters. Section 4.5.2.3 of the XML Signature Recommendation says: "Conformant applications must support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7." --Sean > > --Max > >> >> --Sean >> >>> The code change is exactly the same as the specification, so no webrev. >>> Thanks, >>> Max > From Nico.Williams at twosigma.com Mon May 13 16:43:54 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 13 May 2019 16:43:54 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <4CB61EBE-5BF7-4C11-A5D4-0DA416458CDF@oracle.com> References: <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> <20190509155352.GC7457@twosigma.com> <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> <20190510155518.GD7457@twosigma.com> <4CB61EBE-5BF7-4C11-A5D4-0DA416458CDF@oracle.com> Message-ID: <20190513164354.GF7457@twosigma.com> On Sat, May 11, 2019 at 08:02:48AM +0800, Weijun Wang wrote: > > On May 10, 2019, at 11:55 PM, Nico Williams wrote: > > Who can review? > > Anyone who is watching security-dev at . The mail list is quite active. OK, thanks. I'll ask Peter B. to subscribe. > We've done this before. Below are the first 3 code review threads of your contributions: > > 8212165: JGSS: Fix cut/paste error in NativeUtil.c > https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018489.html > > 8212216: JGSS: Fix leak in exception cases in getJavaOID() > https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018506.html > > 8212217: JGSS: Don't dispose() of creds too eagerly > https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018507.html > > You can see Sean and Alan replying, and of course I'll also review all changes. I've got new updates coming that respond to the code review comments I collated from GitHub and some comments received here. I've also added bindings for gss_acquire_cred_from() and gss_store_cred_into(), which makes GssLoginModule a drop-in replacement for Krb5LoginModule as far as functionality goes. Using these new bindings I've been able to write a Java-coded kinit, and a Java-coded ccache copy program. Nico -- From valerie.peng at oracle.com Mon May 13 22:32:52 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 13 May 2019 15:32:52 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> Message-ID: <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Hmm, thanks much for the feedback on how to use WeakReference. This bug/rfe is filed to address the scalability. However, it is noticed that storing Provider objects into the map have some side effect on memory, so I was trying to address both with minimum number of new code. Guess it does not quite work as I expected... The priority is the scalability.? I am not sure if it's worthwhile to address the memory-side-effect by adding another reference queue + purge the map + re-verify the provider if the underlying provider is GC'ed. So, I will update the webrev with CHM then. Thanks again for the feedback, Valerie On 5/13/2019 2:36 AM, Alan Bateman wrote: > > > On 13/05/2019 10:04, Daniel Fuchs wrote: >> Hi Valery, >> >> On 11/05/2019 00:36, Valerie Peng wrote: >>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/ >>> >>> Please let me know if you have more comments. >> >> If I'm not mistaken, the only thing that references >> the IdentityWrapper is the key in the WeakHashMap. >> Therefore, it is only weakly referenced and can be immediatly >> garbage collected. I don't think this is what you want? >> >> I believe what you are trying to achieve there is rather to use >> a plain ConcurrentHashMap, and have IdentityWrapper extend >> WeakReference instead. You may need to store >> the hashCode in IdentityWrapper so that it doesn't change >> when the underlying Provider is garbage collected. >> >> Then you can use a ReferenceQueue to purge the map regularly. > Right, plus getVerificationResult is accessing the WeakHashMap without > synchronization. > > I think it would be useful to get a summary on whether this issue is > trying to address one or two points. For the scalability point then I > assume a CHM + computeIfAbsent would help. If the issue is also that > you want the key (Provider) to be weak then it will require additional > work, as Daniel points out. > > -Alan > From weijun.wang at oracle.com Tue May 14 00:50:25 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 May 2019 08:50:25 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> Message-ID: <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> > On May 13, 2019, at 10:51 PM, Sean Mullan wrote: > > On 5/10/19 8:07 PM, Weijun Wang wrote: >>> On May 11, 2019, at 4:44 AM, Sean Mullan wrote: >>> >>> On 5/10/19 5:04 AM, Weijun Wang wrote: >>>> Please take a review at the CSR at >>>> https://bugs.openjdk.java.net/browse/JDK-8223682 Updated with @since 13 and no more @implNote. Thanks, Max >>> >>> Add an "@since 13" to the new constant. >>> >>>> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >>>> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. >>> >>> I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? >> Maybe a little complicated? >> https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 > > Yes, perhaps, or more likely because it is optional to support ECParameters. > > Section 4.5.2.3 of the XML Signature Recommendation says: > > "Conformant applications must support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7." > > --Sean > >> --Max >>> >>> --Sean >>> >>>> The code change is exactly the same as the specification, so no webrev. >>>> Thanks, >>>> Max From christoph.langer at sap.com Tue May 14 09:29:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 May 2019 09:29:14 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: Hi Martin, thanks for your review. Regarding the failing tests: They are not executed in any tier. You'd either have to execute all tests below jdk/test or the test group "jdk_security_infra". But anyway, I'll follow up on these tests as we see the issues in our test system and have to exclude them locally. /Christoph > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 14. Mai 2019 10:22 > To: Langer, Christoph ; 'jdk8u- > dev at openjdk.java.net' ; security-dev > > Subject: RE: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates > (Integration for JEP 319: Root Certificates) > > Hi Christoph, > > this looks good to me. > I don't know if anybody has issues with the failing tests. Should they get > added to a problem list? > > Best regards, > Martin > > > -----Original Message----- > From: jdk8u-dev On Behalf Of > Langer, Christoph > Sent: Dienstag, 7. Mai 2019 16:15 > To: 'jdk8u-dev at openjdk.java.net' ; security- > dev > Subject: [CAUTION] RE: [8u] RFR: 8189131: Open-source the Oracle JDK Root > Certificates (Integration for JEP 319: Root Certificates) > > Ping: can I please have a review for this? > > From: Langer, Christoph > Sent: Donnerstag, 2. Mai 2019 14:55 > To: 'jdk8u-dev at openjdk.java.net' ; security- > dev > Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates > (Integration for JEP 319: Root Certificates) > > Hi, > > as was already discussed and requested on the mailing lists ([0], [1]), I hereby > propose a change to add the root certificates of upstream OpenJDK to > OpenJDK 8 updates. > > The main bug that (initially) brought the Oracle certificates to OpenJDK is > 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed > change will also backport all updates to the contents of cacerts since then: > > 8191844: Remove SECOM root (secomevrootca1) > 8189949: Remove Baltimore Cybertrust Code Signing CA > 8191031: Remove several Symantec Root CAs > 8196141: Add GoDaddy root certificates > 8204923: Restore Symantec root verisignclass2g2ca > 8195774: Add Entrust root certificates > 8199779: Add T-Systems, GlobalSign and Starfield services root certificates > 8209506: Add Google Trust Services GlobalSign root certificates > 8210432: Add additional TeliaSonera root certificate > 8195793: Remove GTE CyberTrust Global Root > 8216577: Add GlobalSign's R6 Root certificate > 8222137: Remove T-Systems root CA certificate > > Please find the webrev here: > http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ > > I took the current state of cacerts from the jdk/jdk repo along with the > provided testcases and brought them down to the jdk8 repository layout. > > To make the test run in JDK8, I had to > a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: > 240 private static final HashSet EXPIRY_EXC_ENTRIES = new > HashSet() { > I needed to add the String type to the constructor of the HashSet, since the > JDK8 java compiler will not accept <> in that place. > > b) modify > test/security/infra/java/security/cert/CertPathValidator/certification/Validat > ePathWithParams.java > > 60 private static final String CACERTS_STORE = > System.getProperty("test.jdk") > > 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; > I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in > subdirectory jre there. > > Out of the tests in > test/security/infra/java/security/cert/CertPathValidator/certification, there > are 2 failing: > FAILED: > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va > FAILED: > security/infra/java/security/cert/CertPathValidator/certification/ComodoCA. > java > However, for jdk/jdk it is the same. JBS Issues for these tests exist and are > yet unresolved: JDK-8202651 and JDK-8215546. > > Since the tests don't seem to be part of any tier, I propose to include them in > this backport and later on also backport possible fixes to them. > > Thanks > Christoph > > [0] https://mail.openjdk.java.net/pipermail/security-dev/2019- > March/019557.html > [1] https://mail.openjdk.java.net/pipermail/security-dev/2019- > April/019733.html > [2] https://bugs.openjdk.java.net/browse/JDK-8189131 From martin.doerr at sap.com Tue May 14 08:22:26 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 14 May 2019 08:22:26 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: Hi Christoph, this looks good to me. I don't know if anybody has issues with the failing tests. Should they get added to a problem list? Best regards, Martin -----Original Message----- From: jdk8u-dev On Behalf Of Langer, Christoph Sent: Dienstag, 7. Mai 2019 16:15 To: 'jdk8u-dev at openjdk.java.net' ; security-dev Subject: [CAUTION] RE: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Ping: can I please have a review for this? From: Langer, Christoph Sent: Donnerstag, 2. Mai 2019 14:55 To: 'jdk8u-dev at openjdk.java.net' ; security-dev Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Hi, as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: 8191844: Remove SECOM root (secomevrootca1) 8189949: Remove Baltimore Cybertrust Code Signing CA 8191031: Remove several Symantec Root CAs 8196141: Add GoDaddy root certificates 8204923: Restore Symantec root verisignclass2g2ca 8195774: Add Entrust root certificates 8199779: Add T-Systems, GlobalSign and Starfield services root certificates 8209506: Add Google Trust Services GlobalSign root certificates 8210432: Add additional TeliaSonera root certificate 8195793: Remove GTE CyberTrust Global Root 8216577: Add GlobalSign's R6 Root certificate 8222137: Remove T-Systems root CA certificate Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. To make the test run in JDK8, I had to a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html [2] https://bugs.openjdk.java.net/browse/JDK-8189131 From 1983-01-06 at gmx.net Wed May 15 07:56:37 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Wed, 15 May 2019 09:56:37 +0200 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190513164354.GF7457@twosigma.com> References: <20190320212626.GE9177@twosigma.com> <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> <20190509155352.GC7457@twosigma.com> <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> <20190510155518.GD7457@twosigma.com> <4CB61EBE-5BF7-4C11-A5D4-0DA416458CDF@oracle.com> <20190513164354.GF7457@twosigma.com> Message-ID: <5b1b9fec-2e41-83f7-3483-cea3e7c15e70@gmx.net> Am 2019-05-13 um 18:43 schrieb Nico Williams: > On Sat, May 11, 2019 at 08:02:48AM +0800, Weijun Wang wrote: >>> On May 10, 2019, at 11:55 PM, Nico Williams wrote: >>> Who can review? >> >> Anyone who is watching security-dev at . The mail list is quite active. > > OK, thanks. I'll ask Peter B. to subscribe. > >> We've done this before. Below are the first 3 code review threads of your contributions: >> >> 8212165: JGSS: Fix cut/paste error in NativeUtil.c >> https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018489.html >> >> 8212216: JGSS: Fix leak in exception cases in getJavaOID() >> https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018506.html >> >> 8212217: JGSS: Don't dispose() of creds too eagerly >> https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018507.html >> >> You can see Sean and Alan replying, and of course I'll also review all changes. > > I've got new updates coming that respond to the code review comments I > collated from GitHub and some comments received here. > > I've also added bindings for gss_acquire_cred_from() and > gss_store_cred_into(), which makes GssLoginModule a drop-in > replacement for Krb5LoginModule as far as functionality goes. Terrific! Can you point me to those commits for a review? I am pretty thrilled to try that out next month when I have some spare cycles on OpenJDK 11 or 12 on a two-tier platform. Michael From sean.mullan at oracle.com Wed May 15 12:00:35 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 May 2019 08:00:35 -0400 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> Message-ID: <435cfa1d-0d05-3b69-95ce-78505a60f2f9@oracle.com> On 4/12/19 8:05 PM, Valerie Peng wrote: > > Anyone has time to review this? Besides the header files update, I added > support for AES/GCM/NoPadding support. Ran into some strange NSS error > with RSASSA-PSS signature mechanism, so I have not included the PSS > signature impl here. It would be very useful if we could include RSASSA-PSS as this should resolve https://bugs.openjdk.java.net/browse/JDK-8222937 Could you could debug this a bit more to see if you can resolve the NSS error? --Sean > > RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 > > Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 > > Thanks, > Valerie > > From Nico.Williams at twosigma.com Wed May 15 15:31:49 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 15 May 2019 15:31:49 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <5b1b9fec-2e41-83f7-3483-cea3e7c15e70@gmx.net> References: <20190507165335.GA7457@twosigma.com> <3771EE60-0F12-4857-9D92-A72C1B0A1013@oracle.com> <20190509155352.GC7457@twosigma.com> <894CA19F-6F8C-4485-B753-5A030B90C37C@oracle.com> <20190510155518.GD7457@twosigma.com> <4CB61EBE-5BF7-4C11-A5D4-0DA416458CDF@oracle.com> <20190513164354.GF7457@twosigma.com> <5b1b9fec-2e41-83f7-3483-cea3e7c15e70@gmx.net> Message-ID: <20190515153149.GG7457@twosigma.com> On Wed, May 15, 2019 at 09:56:37AM +0200, Michael Osipov wrote: > Am 2019-05-13 um 18:43 schrieb Nico Williams: > > On Sat, May 11, 2019 at 08:02:48AM +0800, Weijun Wang wrote: > > > > On May 10, 2019, at 11:55 PM, Nico Williams wrote: > > > > Who can review? > > > > > > Anyone who is watching security-dev at . The mail list is quite active. > > > > OK, thanks. I'll ask Peter B. to subscribe. > > > > > We've done this before. Below are the first 3 code review threads of your contributions: > > > > > > 8212165: JGSS: Fix cut/paste error in NativeUtil.c > > > https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018489.html > > > > > > 8212216: JGSS: Fix leak in exception cases in getJavaOID() > > > https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018506.html > > > > > > 8212217: JGSS: Don't dispose() of creds too eagerly > > > https://mail.openjdk.java.net/pipermail/security-dev/2018-October/018507.html > > > > > > You can see Sean and Alan replying, and of course I'll also review all changes. > > > > I've got new updates coming that respond to the code review comments I > > collated from GitHub and some comments received here. > > > > I've also added bindings for gss_acquire_cred_from() and > > gss_store_cred_into(), which makes GssLoginModule a drop-in > > replacement for Krb5LoginModule as far as functionality goes. > > Terrific! Can you point me to those commits for a review? I am pretty > thrilled to try that out next month when I have some spare cycles on > OpenJDK 11 or 12 on a two-tier platform. I just have to do git commit --fixup for all of them, one by one. Nico -- From mbalao at redhat.com Wed May 15 17:30:13 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 15 May 2019 14:30:13 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> Message-ID: <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> Hi Xuelei, I've developed a JMH benchmark to measure the impact of Webrev.00 for 8223482. This benchmark measures TLS renegotiations on FIPS (SunPKCS11 + NSS + FIPS) and NON-FIPS (all security providers enabled) TLS 1.2 scenarios. WITHOUT 8223482 FIX ============================================================ Benchmark (testMode) Mode Cnt Score Error Units SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 199.620 ? 3.795 ops/s SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 592.222 ? 15.944 ops/s WITH 8223482 FIX (Webrev.00) ============================================================ Benchmark (testMode) Mode Cnt Score Error Units SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 202.215 ? 3.343 ops/s SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 428.161 ? 11.767 ops/s More information: * Full results: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_results_v0 * Benchmark code: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/ciphersuites_benchmark_v0.tar.gz There is a performance penalty of ~28% in NON-FIPS mode. I think I can improve this number, with some trade-offs. Keep you posted. Thanks, Martin.- From xuelei.fan at oracle.com Wed May 15 17:52:17 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 May 2019 10:52:17 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> Message-ID: <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> Thanks for the benchmarking. Let's see if the impact could be minimized. Xuelei On 5/15/2019 10:30 AM, Martin Balao wrote: > Hi Xuelei, > > I've developed a JMH benchmark to measure the impact of Webrev.00 for > 8223482. > > This benchmark measures TLS renegotiations on FIPS (SunPKCS11 + NSS + > FIPS) and NON-FIPS (all security providers enabled) TLS 1.2 scenarios. > > WITHOUT 8223482 FIX > ============================================================ > > Benchmark (testMode) Mode Cnt > Score Error Units > SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 > 199.620 ? 3.795 ops/s > SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 > 592.222 ? 15.944 ops/s > > WITH 8223482 FIX (Webrev.00) > ============================================================ > > Benchmark (testMode) Mode Cnt > Score Error Units > SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 > 202.215 ? 3.343 ops/s > SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 > 428.161 ? 11.767 ops/s > > > More information: > > * Full results: > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_results_v0 > * Benchmark code: > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/ciphersuites_benchmark_v0.tar.gz > > There is a performance penalty of ~28% in NON-FIPS mode. I think I can > improve this number, with some trade-offs. Keep you posted. > > Thanks, > Martin.- > From rajan.halade at oracle.com Wed May 15 18:09:02 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 15 May 2019 11:09:02 -0700 Subject: RFR: 8222136: Remove two Comodo root CA certificates that are expiring Message-ID: Please review this fix for removal of two Comodo root CAcertificates. Webrev: http://cr.openjdk.java.net/~rhalade/8222136/webrev.00/ Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223976 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed May 15 19:11:20 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 May 2019 12:11:20 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Message-ID: I updated the webrev to switch to ConcurrentHashMap. The javadoc spec of computeIfAbsent method cautioned that the mapping func should be short and simple and must not attempt to update other mappings of this map. Provider verification code does not quite fit the above criteria for the mapping. So, I did not use computeIfAbsent method and just made minor update to webrev.01 with Xuelei's suggestion of re-checking the cache again inside the synchronized block. http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/ Comments? Thanks, Valerie On 5/13/2019 3:32 PM, Valerie Peng wrote: > > Hmm, thanks much for the feedback on how to use WeakReference. This > bug/rfe is filed to address the scalability. However, it is noticed > that storing Provider objects into the map have some side effect on > memory, so I was trying to address both with minimum number of new > code. Guess it does not quite work as I expected... > > The priority is the scalability.? I am not sure if it's worthwhile to > address the memory-side-effect by adding another reference queue + > purge the map + re-verify the provider if the underlying provider is > GC'ed. So, I will update the webrev with CHM then. > > Thanks again for the feedback, > Valerie > On 5/13/2019 2:36 AM, Alan Bateman wrote: >> >> >> On 13/05/2019 10:04, Daniel Fuchs wrote: >>> Hi Valery, >>> >>> On 11/05/2019 00:36, Valerie Peng wrote: >>>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/ >>>> >>>> Please let me know if you have more comments. >>> >>> If I'm not mistaken, the only thing that references >>> the IdentityWrapper is the key in the WeakHashMap. >>> Therefore, it is only weakly referenced and can be immediatly >>> garbage collected. I don't think this is what you want? >>> >>> I believe what you are trying to achieve there is rather to use >>> a plain ConcurrentHashMap, and have IdentityWrapper extend >>> WeakReference instead. You may need to store >>> the hashCode in IdentityWrapper so that it doesn't change >>> when the underlying Provider is garbage collected. >>> >>> Then you can use a ReferenceQueue to purge the map regularly. >> Right, plus getVerificationResult is accessing the WeakHashMap >> without synchronization. >> >> I think it would be useful to get a summary on whether this issue is >> trying to address one or two points. For the scalability point then I >> assume a CHM + computeIfAbsent would help. If the issue is also that >> you want the key (Provider) to be weak then it will require >> additional work, as Daniel points out. >> >> -Alan >> From valerie.peng at oracle.com Wed May 15 19:32:23 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 May 2019 12:32:23 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <435cfa1d-0d05-3b69-95ce-78505a60f2f9@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <435cfa1d-0d05-3b69-95ce-78505a60f2f9@oracle.com> Message-ID: Yes, I managed to add PSS support, will send out the updated webrev later today. Thanks, Valerie On 5/15/2019 5:00 AM, Sean Mullan wrote: > On 4/12/19 8:05 PM, Valerie Peng wrote: >> >> Anyone has time to review this? Besides the header files update, I >> added support for AES/GCM/NoPadding support. Ran into some strange >> NSS error with RSASSA-PSS signature mechanism, so I have not included >> the PSS signature impl here. > > It would be very useful if we could include RSASSA-PSS as this should > resolve https://bugs.openjdk.java.net/browse/JDK-8222937 > > Could you could debug this a bit more to see if you can resolve the > NSS error? > > --Sean > >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >> >> Thanks, >> Valerie >> >> From sean.mullan at oracle.com Wed May 15 20:17:17 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 May 2019 16:17:17 -0400 Subject: RFR: 8222136: Remove two Comodo root CA certificates that are expiring In-Reply-To: References: Message-ID: <3bf9ad36-4d32-b553-51bd-e797fb61b174@oracle.com> Looks good. --Sean On 5/15/19 2:09 PM, Rajan Halade wrote: > Please review this fix for removal of two Comodo root CAcertificates. > > Webrev: http://cr.openjdk.java.net/~rhalade/8222136/webrev.00/ > > Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223976 > > Thanks, > Rajan From daniel.fuchs at oracle.com Thu May 16 08:55:44 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 16 May 2019 09:55:44 +0100 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Message-ID: Hi Valerie, This looks good to me. I just wonder why IdentityWrapper has a parameter type as it seems it's only used with T = Provider. I mean - this is fine - and I understand why you did it this way as the general purpose parameterized class is much easier to name, but I wonder if you wouldn't get a "rawtype" warning at line 418 if you compiled that with -Xlint. best regards, -- daniel On 15/05/2019 20:11, Valerie Peng wrote: > I updated the webrev to switch to ConcurrentHashMap. The javadoc spec of > computeIfAbsent method cautioned that the mapping func should be short > and simple and must not attempt to update other mappings of this map. > Provider verification code does not quite fit the above criteria for the > mapping. So, I did not use computeIfAbsent method and just made minor > update to webrev.01 with Xuelei's suggestion of re-checking the cache > again inside the synchronized block. > > http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/ > > Comments? > > Thanks, > Valerie From Alan.Bateman at oracle.com Thu May 16 09:12:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2019 10:12:40 +0100 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Message-ID: On 15/05/2019 20:11, Valerie Peng wrote: > I updated the webrev to switch to ConcurrentHashMap. The javadoc spec > of computeIfAbsent method cautioned that the mapping func should be > short and simple and must not attempt to update other mappings of this > map. Provider verification code does not quite fit the above criteria > for the mapping. So, I did not use computeIfAbsent method and just > made minor update to webrev.01 with Xuelei's suggestion of re-checking > the cache again inside the synchronized block. > > http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/ > > Comments? Does it need to synchronize on JceSecurity.class? I'm mostly wondering if it can use computeIfAbsent. -Alan From rajan.halade at oracle.com Thu May 16 16:29:55 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 16 May 2019 09:29:55 -0700 Subject: RFR: 8223499: Remove two DocuSign root certificates that are expiring Message-ID: <7835b8aa-dcf7-c4da-9890-a6ca93a8d3c7@oracle.com> Please review this fix for removal of two DocuSign root CAcertificates. Webrev: http://cr.openjdk.java.net/~rhalade/8223499/webrev.00/ Release note is at - https://bugs.openjdk.java.net/browse/JDK-8224004 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Thu May 16 17:31:20 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 16 May 2019 14:31:20 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> Message-ID: <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> Hi Xuelei, Thanks for your feedback. We can move the supported ciphersuites check to SSLContextImpl.getApplicableCipherSuites method and affect the default list of enabled ciphersuites only. This list is set in SSLContextImpl initialization time, so the performance is not impacted. On the other hand, there are a couple of limitations: 1) if the user explicitly sets the list of enabled ciphersuites (by calling SSLSocket/SSLEngine.setEnabledCipherSuites), that overwrites the default list; and 2) if there are changes in the list of enabled security providers after SSLContextImpl is initialized, they won't be considered. I believe we can live with both limitations -and there is an improvement over not checking at all-, and remove the check from HandshakeContext.getActiveCipherSuites which was causing performance impact as it was executed per handshake negotiation. Here it's Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/ Benchmarks for Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_results_v1 Benchmarks summary: WITH Webrev.00: Benchmark (testMode) Mode Cnt Score Error Units SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 202.215 ?? 3.343 ops/s SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 428.161 ?? 11.767 ops/s WITH Webrev.01: Benchmark (testMode) Mode Cnt Score Error Units SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 214.637 ?? 1.756 ops/s SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 619.737 ?? 10.942 ops/s WITHOUT Webrev.01: Benchmark (testMode) Mode Cnt Score Error Units SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 199.620 ?? 3.795 ops/s SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 592.222 ?? 15.944 ops/s Thoughts? Thanks, Martin.- From sgehwolf at redhat.com Thu May 16 17:51:25 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 May 2019 19:51:25 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions Message-ID: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Hi, Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't seems to have this issue as with the TLS 1.3 feature (JDK-8196584) SessionId.hashCode() got changed to use Arrays.hashCode() already. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203190 The rationale for the fix are these assumptions: a) elements in trees on hash collision of LinkedHashMap used internally by the MemoryCache class become prohibitively large for many SessionId entries in the cache, b) moderate speed of the new hashCode() impl will not have a detrimental effect on performance overall. Comparison of performance of hashCode impls[1]: Benchmark Mode Cnt Score Error Units SessionIDBench.newHashCode thrpt 100 43649538.284 ? 678702.696 ops/s SessionIDBench.oldHashCode thrpt 100 94068843.923 ? 1379930.266 ops/s Collision testing[2] showed that indeed, the current hashCode() implementation of SessionId produces more collissions and, thus, produce more elements in trees for collision resolution in the underlying LinkedHashMap. The default cache expiry is 24 hours per entry and this can result in millions of entries in the cache in some circumstances[3]. Before: ################################################## Collision test for 100 sessions: ------------------------------------------------ Total number of collisions: 4 Max length of collision list over all buckets: 2 Collision test for 20480 sessions: ------------------------------------------------ Total number of collisions: 18311 Max length of collision list over all buckets: 30 Collision test for 10000000 sessions: ------------------------------------------------ Total number of collisions: 9996395 Max length of collision list over all buckets: 9709 ################################################## After: ################################################## Collision test for 100 sessions: ------------------------------------------------ Total number of collisions: 0 Collision test for 20480 sessions: ------------------------------------------------ Total number of collisions: 0 Collision test for 10000000 sessions: ------------------------------------------------ Total number of collisions: 11530 Max length of collision list over all buckets: 2 ################################################## Testing: Above testing, and make test. No new failures. Thoughts? Thanks, Severin [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIDBench.java [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIdCollissionTest.java [3] https://bugs.openjdk.java.net/browse/JDK-8210985 From gnu.andrew at redhat.com Thu May 16 18:10:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 16 May 2019 19:10:23 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Message-ID: <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> On 16/05/2019 18:51, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't > seems to have this issue as with the TLS 1.3 feature (JDK-8196584) > SessionId.hashCode() got changed to use Arrays.hashCode() already. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8203190 > > The rationale for the fix are these assumptions: > > a) elements in trees on hash collision of LinkedHashMap used internally > by the MemoryCache class become prohibitively large for many SessionId > entries in the cache, b) moderate speed of the new hashCode() impl will > not have a detrimental effect on performance overall. > > Comparison of performance of hashCode impls[1]: > > Benchmark Mode Cnt Score Error Units > SessionIDBench.newHashCode thrpt 100 43649538.284 ? 678702.696 ops/s > SessionIDBench.oldHashCode thrpt 100 94068843.923 ? 1379930.266 ops/s > > Collision testing[2] showed that indeed, the current hashCode() > implementation of SessionId produces more collissions and, thus, > produce more elements in trees for collision resolution in the > underlying LinkedHashMap. The default cache expiry is 24 hours per > entry and this can result in millions of entries in the cache in some > circumstances[3]. > > Before: > ################################################## > Collision test for 100 sessions: > ------------------------------------------------ > Total number of collisions: 4 > Max length of collision list over all buckets: 2 > > Collision test for 20480 sessions: > ------------------------------------------------ > Total number of collisions: 18311 > Max length of collision list over all buckets: 30 > > Collision test for 10000000 sessions: > ------------------------------------------------ > Total number of collisions: 9996395 > Max length of collision list over all buckets: 9709 > ################################################## > > After: > ################################################## > Collision test for 100 sessions: > ------------------------------------------------ > Total number of collisions: 0 > > Collision test for 20480 sessions: > ------------------------------------------------ > Total number of collisions: 0 > > Collision test for 10000000 sessions: > ------------------------------------------------ > Total number of collisions: 11530 > Max length of collision list over all buckets: 2 > ################################################## > > > Testing: Above testing, and make test. No new failures. > > Thoughts? > > Thanks, > Severin > > [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIDBench.java > [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIdCollissionTest.java > [3] https://bugs.openjdk.java.net/browse/JDK-8210985 > Change looks good. Is there a reason the tests aren't included in the webrev? I think it would be better to have them checked in, even if they can't be run automatically. They will need copyright headers and I'd correct the spelling of 'collision' too :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From sean.mullan at oracle.com Thu May 16 19:22:03 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 16 May 2019 15:22:03 -0400 Subject: RFR: 8223499: Remove two DocuSign root certificates that are expiring In-Reply-To: <7835b8aa-dcf7-c4da-9890-a6ca93a8d3c7@oracle.com> References: <7835b8aa-dcf7-c4da-9890-a6ca93a8d3c7@oracle.com> Message-ID: <3ec34a21-3efb-bf9f-734f-e59ec6f78f33@oracle.com> Looks good. --Sean On 5/16/19 12:29 PM, Rajan Halade wrote: > Please review this fix for removal of two DocuSign root CAcertificates. > > Webrev: http://cr.openjdk.java.net/~rhalade/8223499/webrev.00/ > > Release note is at - https://bugs.openjdk.java.net/browse/JDK-8224004 > > Thanks, > Rajan From anthony.scarpino at oracle.com Thu May 16 21:30:07 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 16 May 2019 14:30:07 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State Message-ID: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> I'm asking for a review of this rather large change to add support stateless tickets in the TLS 1.3 5077 RFC. https://bugs.openjdk.java.net/browse/JDK-8211018 http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 thanks Tony From daniel.fuchs at oracle.com Fri May 17 10:00:04 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 May 2019 11:00:04 +0100 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: References: Message-ID: Hi Arthur, On 17/05/2019 00:16, Arthur Eubanks wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8224081 > webrev: http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html > > Tests that try to use SOCKS v4 will fail in an IPv6 only environment > since SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6. Your changes to java/net/Socks/SocksProxyVersion.java look good to me. However I'd like your changes to test/jdk/sun/security/x509/URICertStore/SocksProxy.java to be reviewed by the security-dev team which I have added in cc:, since I believe this falls into their area. best regards, -- daniel From sgehwolf at redhat.com Fri May 17 11:37:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 13:37:21 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> Message-ID: <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> On Thu, 2019-05-16 at 19:10 +0100, Andrew John Hughes wrote: > > Change looks good. Thanks for the review. > Is there a reason the tests aren't included in the webrev? I think it > would be better to have them checked in, even if they can't be run > automatically. The reason was that it's not a good test to be run automatically. It would have to have some heuristic which it uses as "passed" and "fail". Checking in the code anyway has a tendency for it to bitrot. If you really feel strongly about it, I can add it. FWIW, the reference to the test isn't going away so it'll be available either way. > They will need copyright headers and I'd correct the spelling of > 'collision' too :-) :) Af for the typo: Well spotted. Thanks, Severin From sgehwolf at redhat.com Fri May 17 11:37:59 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 13:37:59 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Message-ID: <819a6c3f9fc84d347aa7102ef440efecc5b266ec.camel@redhat.com> On Fri, 2019-05-17 at 12:07 +0200, Aleksey Shipilev wrote: > On 5/16/19 7:51 PM, Severin Gehwolf wrote: > > Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't > > seems to have this issue as with the TLS 1.3 feature (JDK-8196584) > > SessionId.hashCode() got changed to use Arrays.hashCode() already. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ > > This looks good to me. Thanks for the review, Aleksey! Cheers, Severin From gnu.andrew at redhat.com Fri May 17 15:28:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 17 May 2019 16:28:12 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> Message-ID: On 17/05/2019 12:37, Severin Gehwolf wrote: snip... > > The reason was that it's not a good test to be run automatically. It > would have to have some heuristic which it uses as "passed" and "fail". > Checking in the code anyway has a tendency for it to bitrot. If you > really feel strongly about it, I can add it. FWIW, the reference to the > test isn't going away so it'll be available either way. > I get that, but there are other manual tests in the repositories. I saw one yesterday that required downloading a font before running it. I think it better to have everything in one place rather than relying on someone to find this e-mail thread. The bitrot argument seems a little odd, given it would be more open to updates in the repositories rather than on a web server where only you can update it :/ -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From sgehwolf at redhat.com Fri May 17 16:00:59 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 18:00:59 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> Message-ID: <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: > > On 17/05/2019 12:37, Severin Gehwolf wrote: > > snip... > > > The reason was that it's not a good test to be run automatically. It > > would have to have some heuristic which it uses as "passed" and "fail". > > Checking in the code anyway has a tendency for it to bitrot. If you > > really feel strongly about it, I can add it. FWIW, the reference to the > > test isn't going away so it'll be available either way. > > > > I get that, but there are other manual tests in the repositories. I saw > one yesterday that required downloading a font before running it. I > think it better to have everything in one place rather than relying on > someone to find this e-mail thread. > > The bitrot argument seems a little odd, given it would be more open to > updates in the repositories rather than on a web server where only you > can update it :/ Sure. Here the webrev with the test: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ OK to push? Thanks, Severin From gnu.andrew at redhat.com Fri May 17 16:13:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 17 May 2019 17:13:42 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> Message-ID: On 17/05/2019 17:00, Severin Gehwolf wrote: > On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: >> >> On 17/05/2019 12:37, Severin Gehwolf wrote: >> >> snip... >> >>> The reason was that it's not a good test to be run automatically. It >>> would have to have some heuristic which it uses as "passed" and "fail". >>> Checking in the code anyway has a tendency for it to bitrot. If you >>> really feel strongly about it, I can add it. FWIW, the reference to the >>> test isn't going away so it'll be available either way. >>> >> >> I get that, but there are other manual tests in the repositories. I saw >> one yesterday that required downloading a font before running it. I >> think it better to have everything in one place rather than relying on >> someone to find this e-mail thread. >> >> The bitrot argument seems a little odd, given it would be more open to >> updates in the repositories rather than on a web server where only you >> can update it :/ > > Sure. Here the webrev with the test: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ > > OK to push? > > Thanks, > Severin > Looks good to me. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From daniel.fuchs at oracle.com Fri May 17 16:15:39 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 May 2019 17:15:39 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> Message-ID: <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> Hi Severin, Here is an example of a manual test checked in in the jdk repo: http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/security/provider/PolicyParser/ExtDirs.java - it has an @test annotation - it has an @bug annotation - it has an @run main/manual line - it has a comment explaining how to run the test (if necessary) and should have also explain in which case it should be declared successful or failed... best regards, -- daniel On 17/05/2019 17:00, Severin Gehwolf wrote: > On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: >> >> On 17/05/2019 12:37, Severin Gehwolf wrote: >> >> snip... >> >>> The reason was that it's not a good test to be run automatically. It >>> would have to have some heuristic which it uses as "passed" and "fail". >>> Checking in the code anyway has a tendency for it to bitrot. If you >>> really feel strongly about it, I can add it. FWIW, the reference to the >>> test isn't going away so it'll be available either way. >>> >> >> I get that, but there are other manual tests in the repositories. I saw >> one yesterday that required downloading a font before running it. I >> think it better to have everything in one place rather than relying on >> someone to find this e-mail thread. >> >> The bitrot argument seems a little odd, given it would be more open to >> updates in the repositories rather than on a web server where only you >> can update it :/ > > Sure. Here the webrev with the test: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ > > OK to push? > > Thanks, > Severin > From aeubanks at google.com Fri May 17 16:50:18 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Fri, 17 May 2019 09:50:18 -0700 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> References: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> Message-ID: > > Looks good. > > Trivially, maybe amend the comment to be more explicit > > 86 // SOCKS V4 ( requires IPv4 ) > > -Chris. > Done http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ I will wait for another review from security-dev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri May 17 16:53:31 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2019 17:53:31 +0100 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: References: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> Message-ID: <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com> Arthur, > On 17 May 2019, at 17:50, Arthur Eubanks wrote: > > Looks good. > > Trivially, maybe amend the comment to be more explicit > > 86 // SOCKS V4 ( requires IPv4 ) > > -Chris. > Done > http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ > > I will wait for another review from security-dev. You have my Review ( conditional on a Reviewer for the test in the security area ). -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri May 17 16:58:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 18:58:51 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> Message-ID: <676689a0368a7469f72f5ba6ab09d2636e5e0583.camel@redhat.com> Hi Daniel, On Fri, 2019-05-17 at 17:15 +0100, Daniel Fuchs wrote: > Hi Severin, > > Here is an example of a manual test checked in in the jdk repo: > > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/security/provider/PolicyParser/ExtDirs.java > > - it has an @test annotation > - it has an @bug annotation > - it has an @run main/manual line > - it has a comment explaining how to run the test > (if necessary) and should have also explain > in which case it should be declared successful > or failed... Thanks! How about this? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/03/webrev/ Cheers, Severin > best regards, > > -- daniel > > On 17/05/2019 17:00, Severin Gehwolf wrote: > > On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: > > > On 17/05/2019 12:37, Severin Gehwolf wrote: > > > > > > snip... > > > > > > > The reason was that it's not a good test to be run > > > > automatically. It > > > > would have to have some heuristic which it uses as "passed" and > > > > "fail". > > > > Checking in the code anyway has a tendency for it to bitrot. If > > > > you > > > > really feel strongly about it, I can add it. FWIW, the > > > > reference to the > > > > test isn't going away so it'll be available either way. > > > > > > > > > > I get that, but there are other manual tests in the repositories. > > > I saw > > > one yesterday that required downloading a font before running it. > > > I > > > think it better to have everything in one place rather than > > > relying on > > > someone to find this e-mail thread. > > > > > > The bitrot argument seems a little odd, given it would be more > > > open to > > > updates in the repositories rather than on a web server where > > > only you > > > can update it :/ > > > > Sure. Here the webrev with the test: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ > > > > OK to push? > > > > Thanks, > > Severin > > From norman.maurer at googlemail.com Fri May 17 18:02:54 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 17 May 2019 20:02:54 +0200 Subject: Possible bug with JDK12 and ChaCha ciphers Message-ID: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> Hi there, We recently received a bug report in netty when JDK12 is used with ChaCha chiphers: https://github.com/netty/netty/issues/9150 Basically it seems like there is a problem in how it uses the ByteBuffer internally: Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703) at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188) at java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360) at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701) Unfortunately I have no standalone reproducer yet but I just wanted to bring it up here in case it helps. It only happens on JDK12 it seems. Check the Netty issue for more details? Bye Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyommani at gmail.com Fri May 17 10:02:27 2019 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 17 May 2019 15:32:27 +0530 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: References: Message-ID: +1 On Fri, May 17, 2019 at 3:29 PM Daniel Fuchs wrote: > Hi Arthur, > > On 17/05/2019 00:16, Arthur Eubanks wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224081 > > webrev: > http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html > > > > Tests that try to use SOCKS v4 will fail in an IPv6 only environment > > since SOCKS v4 does not support IPv6. SOCKS v5 does support IPv6. > > Your changes to java/net/Socks/SocksProxyVersion.java look good to me. > > However I'd like your changes to > test/jdk/sun/security/x509/URICertStore/SocksProxy.java > to be reviewed by the security-dev team which I have added > in cc:, since I believe this falls into their area. > > best regards, > > -- daniel > > -- Thanks, Vyom -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Fri May 17 10:07:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 17 May 2019 12:07:57 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Message-ID: On 5/16/19 7:51 PM, Severin Gehwolf wrote: > Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't > seems to have this issue as with the TLS 1.3 feature (JDK-8196584) > SessionId.hashCode() got changed to use Arrays.hashCode() already. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ This looks good to me. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From xuelei.fan at oracle.com Fri May 17 18:27:46 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 17 May 2019 11:27:46 -0700 Subject: Possible bug with JDK12 and ChaCha ciphers In-Reply-To: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> References: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> Message-ID: <7bc3de26-6d68-1bc6-2248-ed83a08eaf74@oracle.com> Hi Norman, If you are able to reproduce this issue, would you mind post the JSSE debug log (by using Java System Property, "javax.net.debug=all")? Please feel free to submit a bug. Thanks & Regards, Xuelei On 5/17/2019 11:02 AM, Norman Maurer wrote: > Hi there, > > We recently received a bug report in netty when JDK12 is used with > ChaCha chiphers: > > https://github.com/netty/netty/issues/9150 > > Basically it seems like there is a problem in how it uses the ByteBuffer > internally: > > > |Caused by: java.lang.RuntimeException: > javax.crypto.ShortBufferException: Output buffer too small at > java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703) > at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at > java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at > java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at > java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) > at > java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > at > java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) > at > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) > at > java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) > ... 25 common frames omitted Caused by: > javax.crypto.ShortBufferException: Output buffer too small at > java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360) > at > java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)| > > > > Unfortunately I have no standalone reproducer yet but I just wanted to > bring it up here in case it helps. > > It only happens on JDK12 it seems. Check the Netty issue for more details? > > > Bye > Norman > From norman.maurer at googlemail.com Fri May 17 18:38:02 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 17 May 2019 20:38:02 +0200 Subject: Possible bug with JDK12 and ChaCha ciphers In-Reply-To: <7bc3de26-6d68-1bc6-2248-ed83a08eaf74@oracle.com> References: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> <7bc3de26-6d68-1bc6-2248-ed83a08eaf74@oracle.com> Message-ID: <11B6324B-6E4A-429B-936F-B64442AF9E91@googlemail.com> Unfortunately I am very busy atm so it may take me a few days. I asked the original reported of the issue to provide some in the netty issue tracker. I will come back to you. Bye Norman > On 17. May 2019, at 20:27, Xuelei Fan wrote: > > Hi Norman, > > If you are able to reproduce this issue, would you mind post the JSSE debug log (by using Java System Property, "javax.net.debug=all")? > > Please feel free to submit a bug. > > Thanks & Regards, > Xuelei > > On 5/17/2019 11:02 AM, Norman Maurer wrote: >> Hi there, >> We recently received a bug report in netty when JDK12 is used with ChaCha chiphers: >> https://github.com/netty/netty/issues/9150 >> Basically it seems like there is a problem in how it uses the ByteBuffer internally: >> |Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703) at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188) at java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360) at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)| >> Unfortunately I have no standalone reproducer yet but I just wanted to bring it up here in case it helps. >> It only happens on JDK12 it seems. Check the Netty issue for more details? >> Bye >> Norman From daniel.fuchs at oracle.com Fri May 17 19:12:49 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 May 2019 20:12:49 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <676689a0368a7469f72f5ba6ab09d2636e5e0583.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> <676689a0368a7469f72f5ba6ab09d2636e5e0583.camel@redhat.com> Message-ID: <1c808da6-034a-e366-1010-0bba07a47c0b@oracle.com> On 17/05/19 17:58, Severin Gehwolf wrote: > Thanks! How about this? > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/03/webrev/ Yes, the test looks good to me! Thanks Severin, best regards, -- daniel From norman.maurer at googlemail.com Fri May 17 19:26:08 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 17 May 2019 21:26:08 +0200 Subject: Possible bug with JDK12 and ChaCha ciphers In-Reply-To: <11B6324B-6E4A-429B-936F-B64442AF9E91@googlemail.com> References: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> <7bc3de26-6d68-1bc6-2248-ed83a08eaf74@oracle.com> <11B6324B-6E4A-429B-936F-B64442AF9E91@googlemail.com> Message-ID: <28367A93-9498-4158-A289-2F906CDDB8FD@googlemail.com> The user did capture the log here: https://hasteb.in/ucalevob.makefile Hopefully it is helpful, Norman > On 17. May 2019, at 20:38, Norman Maurer wrote: > > Unfortunately I am very busy atm so it may take me a few days. I asked the original reported of the issue to provide some in the netty issue tracker. I will come back to you. > > Bye > Norman > > >> On 17. May 2019, at 20:27, Xuelei Fan wrote: >> >> Hi Norman, >> >> If you are able to reproduce this issue, would you mind post the JSSE debug log (by using Java System Property, "javax.net.debug=all")? >> >> Please feel free to submit a bug. >> >> Thanks & Regards, >> Xuelei >> >> On 5/17/2019 11:02 AM, Norman Maurer wrote: >>> Hi there, >>> We recently received a bug report in netty when JDK12 is used with ChaCha chiphers: >>> https://github.com/netty/netty/issues/9150 >>> Basically it seems like there is a problem in how it uses the ByteBuffer internally: >>> |Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703) at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188) at java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360) at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)| >>> Unfortunately I have no standalone reproducer yet but I just wanted to bring it up here in case it helps. >>> It only happens on JDK12 it seems. Check the Netty issue for more details? >>> Bye >>> Norman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri May 17 19:56:07 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 17 May 2019 12:56:07 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> Message-ID: <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> Thanks Martin for helping me troubleshoot NSS side, I added PSS support into PKCS11 provider and added PSS-specific regression tests. Please find webrev updated as below: http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ Can someone help review the CSR first as the approval may take a week or so. Thanks, Valerie On 4/12/2019 5:05 PM, Valerie Peng wrote: > > Anyone has time to review this? Besides the header files update, I > added support for AES/GCM/NoPadding support. Ran into some strange NSS > error with RSASSA-PSS signature mechanism, so I have not included the > PSS signature impl here. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 > > Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 > > Thanks, > Valerie > > From xuelei.fan at oracle.com Mon May 20 15:35:33 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 May 2019 08:35:33 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> Message-ID: <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> On 5/16/2019 10:31 AM, Martin Balao wrote: > Hi Xuelei, > > Thanks for your feedback. > > We can move the supported ciphersuites check to > SSLContextImpl.getApplicableCipherSuites method and affect the default > list of enabled ciphersuites only. This list is set in SSLContextImpl > initialization time, so the performance is not impacted. It is out of my expectation. However, SSLContextImpl initialization is an impact point we may want to consider (i.e., the loading performance impact). For better understanding, would you mind describe what performance you are testing for? Or the logic for the benchmark bellow? I appreciate if you could benchmark the SSLContext loading performance also well. Thanks, Xuelei > On the other > hand, there are a couple of limitations: 1) if the user explicitly sets > the list of enabled ciphersuites (by calling > SSLSocket/SSLEngine.setEnabledCipherSuites), that overwrites the default > list; and 2) if there are changes in the list of enabled security > providers after SSLContextImpl is initialized, they won't be considered. > I believe we can live with both limitations -and there is an improvement > over not checking at all-, and remove the check from > HandshakeContext.getActiveCipherSuites which was causing performance > impact as it was executed per handshake negotiation. > > Here it's Webrev.01: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/ > > Benchmarks for Webrev.01: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_results_v1 > > Benchmarks summary: > > WITH Webrev.00: > > Benchmark (testMode) Mode Cnt > Score Error Units > SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 > 202.215 ?? 3.343 ops/s > SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 > 428.161 ?? 11.767 ops/s > > WITH Webrev.01: > > Benchmark (testMode) Mode Cnt > Score Error Units > SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 > 214.637 ?? 1.756 ops/s > SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 > 619.737 ?? 10.942 ops/s > > WITHOUT Webrev.01: > > Benchmark (testMode) Mode Cnt > Score Error Units > SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 > 199.620 ?? 3.795 ops/s > SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 > 592.222 ?? 15.944 ops/s > > Thoughts? > > Thanks, > Martin.- > From sean.mullan at oracle.com Mon May 20 19:11:55 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 20 May 2019 15:11:55 -0400 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> Message-ID: <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> On 5/17/19 3:56 PM, Valerie Peng wrote: > > Thanks Martin for helping me troubleshoot NSS side, I added PSS support > into PKCS11 provider and added PSS-specific regression tests. Please > find webrev updated as below: > > http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ > > Can someone help review the CSR first as the approval may take a week or > so. I am curious why a CSR is needed? This seems to be strictly an implementation change with no compatibility effects. --Sean > > Thanks, > Valerie > On 4/12/2019 5:05 PM, Valerie Peng wrote: >> >> Anyone has time to review this? Besides the header files update, I >> added support for AES/GCM/NoPadding support. Ran into some strange NSS >> error with RSASSA-PSS signature mechanism, so I have not included the >> PSS signature impl here. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >> >> Thanks, >> Valerie >> >> From bradford.wetmore at oracle.com Tue May 21 20:17:02 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 21 May 2019 13:17:02 -0700 Subject: [13] RFR CSR 8224520: Support X25519 and X448 in TLS Message-ID: Please review the following CSR at: https://bugs.openjdk.java.net/browse/JDK-8224520 This adds the x25519/x448 named Elliptic Curves to TLS. Thanks, Brad From xuelei.fan at oracle.com Tue May 21 20:39:26 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 21 May 2019 13:39:26 -0700 Subject: [13] RFR CSR 8224520: Support X25519 and X448 in TLS In-Reply-To: References: Message-ID: <8a831266-3c1e-d00d-e59a-1ee2269784be@oracle.com> Hi Brad, Would like add a note about the preference order of x25519/x448? Thanks, Xuelei On 5/21/2019 1:17 PM, Bradford Wetmore wrote: > > Please review the following CSR at: > > ?? https://bugs.openjdk.java.net/browse/JDK-8224520 > > This adds the x25519/x448 named Elliptic Curves to TLS. > > Thanks, > > Brad From rajan.halade at oracle.com Tue May 21 21:31:30 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 21 May 2019 14:31:30 -0700 Subject: RFR: 8202651: Test ActalisCA.java and ComodoCA fails Message-ID: Please review this fix to update test certificates used in Actalis and Comodo CA interop tests. The bug also mentioned QuoVadisCA test but I am not able to reproduce the failure. For Actalis CA, I couldn't get revoked test certificate but the test is updated for valid certificate and will pass now by skipping expired revoked chain. Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202651 Thanks, Rajan From bradford.wetmore at oracle.com Tue May 21 21:45:12 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 21 May 2019 14:45:12 -0700 Subject: [13] RFR CSR 8224520: Support X25519 and X448 in TLS In-Reply-To: <8a831266-3c1e-d00d-e59a-1ee2269784be@oracle.com> References: <8a831266-3c1e-d00d-e59a-1ee2269784be@oracle.com> Message-ID: I've updated with the proposed ordered list of groups. Brad On 5/21/2019 1:39 PM, Xuelei Fan wrote: > Hi Brad, > > Would like add a note about the preference order of x25519/x448? > > Thanks, > Xuelei > > On 5/21/2019 1:17 PM, Bradford Wetmore wrote: >> >> Please review the following CSR at: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8224520 >> >> This adds the x25519/x448 named Elliptic Curves to TLS. >> >> Thanks, >> >> Brad From valerie.peng at oracle.com Tue May 21 23:19:03 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 21 May 2019 16:19:03 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> Message-ID: <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> I thought we always file CSR when updating the version of external standard, e.g. documenting the import aspect of JDK. I'd love to close/withdraw the CSR if it's not needed. Thanks, Valerie On 5/20/2019 12:11 PM, Sean Mullan wrote: > On 5/17/19 3:56 PM, Valerie Peng wrote: >> >> Thanks Martin for helping me troubleshoot NSS side, I added PSS >> support into PKCS11 provider and added PSS-specific regression tests. >> Please find webrev updated as below: >> >> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >> >> Can someone help review the CSR first as the approval may take a week >> or so. > > I am curious why a CSR is needed? This seems to be strictly an > implementation change with no compatibility effects. > > --Sean > >> >> Thanks, >> Valerie >> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>> >>> Anyone has time to review this? Besides the header files update, I >>> added support for AES/GCM/NoPadding support. Ran into some strange >>> NSS error with RSASSA-PSS signature mechanism, so I have not >>> included the PSS signature impl here. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>> >>> Thanks, >>> Valerie >>> >>> From anthony.scarpino at oracle.com Tue May 21 23:24:17 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 21 May 2019 16:24:17 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State Message-ID: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Hi All, Please review the CSR for the stateless Server Side https://bugs.openjdk.java.net/browse/JDK-8223922 thanks Tony From valerie.peng at oracle.com Wed May 22 00:02:36 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 21 May 2019 17:02:36 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Message-ID: <5a4007a2-da92-1a04-ca85-7ac06bf6b9af@oracle.com> Well, I initially tried to use the computeIfAbsent, and I really like how the resulting code looks. But then as I checked the javadoc of the computeIfAbsent method, it seems that the provider verification code does not meet the criteria of short, simple requirement of the mapping func. In addition, the verification of 3rd party provider may trigger the verification of other providers which means updating the other mappings of the same map which the javadoc says the mapping func *must not* do. I don't know the internals of ConcurrentHashMap, would this possibly lead to a deadlock? So, I just followed the existing model of sync'ing on JceSecurity class. I didn't proceed with performance measuring of computeIfAbsent given the above reason. Valerie On 5/16/2019 2:12 AM, Alan Bateman wrote: > On 15/05/2019 20:11, Valerie Peng wrote: >> I updated the webrev to switch to ConcurrentHashMap. The javadoc spec >> of computeIfAbsent method cautioned that the mapping func should be >> short and simple and must not attempt to update other mappings of >> this map. Provider verification code does not quite fit the above >> criteria for the mapping. So, I did not use computeIfAbsent method >> and just made minor update to webrev.01 with Xuelei's suggestion of >> re-checking the cache again inside the synchronized block. >> >> http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/ >> >> Comments? > Does it need to synchronize on JceSecurity.class? I'm mostly wondering > if it can use computeIfAbsent. > > -Alan From anthony.scarpino at oracle.com Wed May 22 00:35:39 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 21 May 2019 17:35:39 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> Message-ID: <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> Hi all, I?ve updated in-place some recent changes due to some additional testing Tony > On May 16, 2019, at 2:30 PM, Anthony Scarpino wrote: > > I'm asking for a review of this rather large change to add support stateless tickets in the TLS 1.3 5077 RFC. > https://bugs.openjdk.java.net/browse/JDK-8211018 > > http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 > > thanks > > Tony From valerie.peng at oracle.com Wed May 22 00:51:26 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 21 May 2019 17:51:26 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Message-ID: Hi Daniel, Good point, I assumed that this general purpose parameterized IdentityWrapper class can easily be leveraged for similar fixes if needed. As currently, only Provider type is used so it doesn't really needs to use parameter type. I will update and re-test. My local build and testing runs fine. I thought my mach5 job comes back ok as well. I will re-submit mach5 with the updated webrev just to be safe. Regards, Valerie On 5/16/2019 1:55 AM, Daniel Fuchs wrote: > Hi Valerie, > > This looks good to me. > > I just wonder why IdentityWrapper has a parameter type as it > seems it's only used with T = Provider. > I mean - this is fine - and I understand why you did it this way > as the general purpose parameterized class is much easier to name, > but I wonder if you wouldn't get a "rawtype" warning at line 418 if > you compiled that with -Xlint. > > best regards, > > -- daniel > > On 15/05/2019 20:11, Valerie Peng wrote: >> I updated the webrev to switch to ConcurrentHashMap. The javadoc spec >> of computeIfAbsent method cautioned that the mapping func should be >> short and simple and must not attempt to update other mappings of >> this map. Provider verification code does not quite fit the above >> criteria for the mapping. So, I did not use computeIfAbsent method >> and just made minor update to webrev.01 with Xuelei's suggestion of >> re-checking the cache again inside the synchronized block. >> >> http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/ >> >> Comments? >> >> Thanks, >> Valerie From weijun.wang at oracle.com Wed May 22 02:17:08 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 May 2019 10:17:08 +0800 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> Message-ID: Sorry for the late reply. Comments below: 1. ReferralsState::handleError cname = new PrincipalName(cname.getNameString().replaceAll( PrincipalName.NAME_REALM_SEPARATOR + "", "\\\\" + PrincipalName.NAME_REALM_SEPARATOR), cname.getNameType(), referredRealm.toString()); Why is the escape necessary? Wouldn't the getNameString() result already contain the backslash? Is it OK to use getNameStrings()? 2. EncKDCRepPart::init if (der.getData().available() > 0) { caddr = HostAddresses.parse(der.getData(), (byte) 0x0B, true); } if (der.getData().available() > 0) { pAData = PAData.parseSequence(der.getData(), (byte) 0x0C, true); } Is this safe? What if caddr is missing but paData is there? Then the first getData() returns paData and cannot be read correctly. 3. EncKDCRepPart::asn1Encode What is the benefit of renaming bytes to out? I have to review all the lines to make sure there is no problem. 4. KDCRep::msgType Is this field used elsewhere? Why make it public? 5. Looks like we will soon need a KrbTgsReqBuilder. 6. CredentialsUtil.java: - serviceCredsSingle. Why use this name? It could still call getTGTforRealm() which triggers more TGS-REQ (and might call into serviceCredsReferrals). Also, is the following check possibly false? String[] serverAsCredsNames = asCreds.getServer().getNameStrings(); if (serverAsCredsNames.length == 2 && serverAsCredsNames[0].equals( PrincipalName.TGS_DEFAULT_SRV_NAME)) { Shouldn't asCreds's server always be some krbtgt? - serviceCredsReferrals. This method can be called by every other TGS related call. Is it necessary to try referral for S4U2self, S4U2proxy, etc? PrincipalName cSname = (PrincipalName) sname.clone(); Not necessary. PrincipalName is immutable. I'll look more into this file. These serviceCreds* methods are little complicated. Thanks, Max > On May 11, 2019, at 8:05 AM, Martin Balao wrote: > > Hi, > > I'd like to propose Webrev.02: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.02/ > > Security properties were introduced mirroring System properties. See CSR > [1]. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8223172 From claes.redestad at oracle.com Wed May 22 10:14:48 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 22 May 2019 12:14:48 +0200 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties Message-ID: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> Hi, some recent security features have been pushing initialization of sun.security.util.SecurityProperties to happen earlier in the bootstrap sequence, which is affecting startup timings on a few targetted applications. This patch helps by desugaring potentially early bootstrap lambda use, and further keep the impact more neutral in cases where no SecurityManager is installed. Webrev: http://cr.openjdk.java.net/~redestad/8224589/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8224589 Thanks! /Claes From Alan.Bateman at oracle.com Wed May 22 10:19:44 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2019 11:19:44 +0100 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> References: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> Message-ID: <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> On 22/05/2019 11:14, Claes Redestad wrote: > Hi, > > some recent security features have been pushing initialization of > sun.security.util.SecurityProperties to happen earlier in the > bootstrap sequence, which is affecting startup timings on a few > targetted applications. > > This patch helps by desugaring potentially early bootstrap lambda use, > and further keep the impact more neutral in cases where no > SecurityManager is installed. > > Webrev: http://cr.openjdk.java.net/~redestad/8224589/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8224589 Looks okay although I assume it doesn't matter for the no-SM case. -Alan From Alan.Bateman at oracle.com Wed May 22 10:20:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2019 11:20:21 +0100 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <5a4007a2-da92-1a04-ca85-7ac06bf6b9af@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> <5a4007a2-da92-1a04-ca85-7ac06bf6b9af@oracle.com> Message-ID: On 22/05/2019 01:02, Valerie Peng wrote: > > Well, I initially tried to use the computeIfAbsent, and I really like > how the resulting code looks. But then as I checked the javadoc of the > computeIfAbsent method, it seems that the provider verification code > does not meet the criteria of short, simple requirement of the mapping > func. In addition, the verification of 3rd party provider may trigger > the verification of other providers which means updating the other > mappings of the same map which the javadoc says the mapping func *must > not* do. I don't know the internals of ConcurrentHashMap, would this > possibly lead to a deadlock? So, I just followed the existing model of > sync'ing on JceSecurity class. I didn't proceed with performance > measuring of computeIfAbsent given the above reason. Fair enough, if it does indeed take a lot of time to compute then what you have is okay. -Alan From claes.redestad at oracle.com Wed May 22 10:34:57 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 22 May 2019 12:34:57 +0200 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> References: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> Message-ID: <192ed6ff-6237-77b9-2172-d9a38aefd970@oracle.com> On 2019-05-22 12:19, Alan Bateman wrote: > Looks okay although I assume it doesn't matter for the no-SM case. You mean the SM case? Not as much as the no-SM case, no, which can be helped a lot in the smallest affected tests. /Claes From Alan.Bateman at oracle.com Wed May 22 10:50:42 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2019 11:50:42 +0100 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <192ed6ff-6237-77b9-2172-d9a38aefd970@oracle.com> References: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> <192ed6ff-6237-77b9-2172-d9a38aefd970@oracle.com> Message-ID: <211f54f9-4a59-40d5-4717-2d4c44ae1bf2@oracle.com> On 22/05/2019 11:34, Claes Redestad wrote: > : > > You mean the SM case? Not as much as the no-SM case, no, which can > be helped a lot in the smallest affected tests. Yes, I don't think the SM case should be performance/startup concern here. Up to you, I don't think it matters but I'm sure someone will be refactor it again. -Alan From claes.redestad at oracle.com Wed May 22 11:06:38 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 22 May 2019 13:06:38 +0200 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <211f54f9-4a59-40d5-4717-2d4c44ae1bf2@oracle.com> References: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> <192ed6ff-6237-77b9-2172-d9a38aefd970@oracle.com> <211f54f9-4a59-40d5-4717-2d4c44ae1bf2@oracle.com> Message-ID: <3c4d2aa7-4d0f-bf11-25bf-9cb30d9a8814@oracle.com> True, I'll skip the desugaring of the else branch, keeps it cleaner. On 2019-05-22 12:50, Alan Bateman wrote: > On 22/05/2019 11:34, Claes Redestad wrote: >> : >> >> You mean the SM case? Not as much as the no-SM case, no, which can >> be helped a lot in the smallest affected tests. > Yes, I don't think the SM case should be performance/startup concern > here. Up to you, I don't think it matters but I'm sure someone will be > refactor it again. > > -Alan From sean.mullan at oracle.com Wed May 22 12:12:02 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 May 2019 08:12:02 -0400 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <3c4d2aa7-4d0f-bf11-25bf-9cb30d9a8814@oracle.com> References: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> <192ed6ff-6237-77b9-2172-d9a38aefd970@oracle.com> <211f54f9-4a59-40d5-4717-2d4c44ae1bf2@oracle.com> <3c4d2aa7-4d0f-bf11-25bf-9cb30d9a8814@oracle.com> Message-ID: <1bbd0db4-c31f-f1db-7934-71137e7bcfb5@oracle.com> Looks ok, although with the changeset you pushed, there is no desugaring so you should probably update the bug description to reflect that. (I probably would have kept the desugaring in the SM case, but probably not a big deal either way) --Sean On 5/22/19 7:06 AM, Claes Redestad wrote: > True, I'll skip the desugaring of the else branch, keeps it cleaner. > > On 2019-05-22 12:50, Alan Bateman wrote: >> On 22/05/2019 11:34, Claes Redestad wrote: >>> : >>> >>> You mean the SM case? Not as much as the no-SM case, no, which can >>> be helped a lot in the smallest affected tests. >> Yes, I don't think the SM case should be performance/startup concern >> here. Up to you, I don't think it matters but I'm sure someone will be >> refactor it again. >> >> -Alan From claes.redestad at oracle.com Wed May 22 12:46:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 22 May 2019 14:46:28 +0200 Subject: RFR: 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <1bbd0db4-c31f-f1db-7934-71137e7bcfb5@oracle.com> References: <68337ffb-3652-0940-7391-83bd6b2a95e4@oracle.com> <73af6b86-133f-8040-0357-7176ca6f94d1@oracle.com> <192ed6ff-6237-77b9-2172-d9a38aefd970@oracle.com> <211f54f9-4a59-40d5-4717-2d4c44ae1bf2@oracle.com> <3c4d2aa7-4d0f-bf11-25bf-9cb30d9a8814@oracle.com> <1bbd0db4-c31f-f1db-7934-71137e7bcfb5@oracle.com> Message-ID: <1302b1e1-9bd4-1ba6-03d6-4bde3b3fc821@oracle.com> Thanks Sean, updated description. When we run with a SM installed, we'll initialize a few lambdas early on already, so gain from desugaring this path was not really measurable. /Claes On 2019-05-22 14:12, Sean Mullan wrote: > Looks ok, although with the changeset you pushed, there is no desugaring > so you should probably update the bug description to reflect that. > > (I probably would have kept the desugaring in the SM case, but probably > not a big deal either way) > > --Sean > > On 5/22/19 7:06 AM, Claes Redestad wrote: >> True, I'll skip the desugaring of the else branch, keeps it cleaner. >> >> On 2019-05-22 12:50, Alan Bateman wrote: >>> On 22/05/2019 11:34, Claes Redestad wrote: >>>> : >>>> >>>> You mean the SM case? Not as much as the no-SM case, no, which can >>>> be helped a lot in the smallest affected tests. >>> Yes, I don't think the SM case should be performance/startup concern >>> here. Up to you, I don't think it matters but I'm sure someone will >>> be refactor it again. >>> >>> -Alan From chris.hegarty at oracle.com Wed May 22 13:29:25 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 May 2019 14:29:25 +0100 Subject: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1 In-Reply-To: References: Message-ID: <80EDAE74-208E-4B7F-9E4E-CF2879D92C13@oracle.com> Arthur, > On 21 May 2019, at 00:50, Arthur Eubanks > wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224256 webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html > > test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a security manager works with "http://127.0.0.1 ". This fails on IPv6-only systems. > > This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 is available. Created a new class for testing ::1 since we can't have duplicate classes. I think this is ok. I?ve included security-dev, as the test in question is in their area. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed May 22 13:32:07 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 May 2019 14:32:07 +0100 Subject: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1 In-Reply-To: References: Message-ID: Arthur, > On 21 May 2019, at 00:50, Arthur Eubanks > wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224256 webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html > > test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a security manager works with "http://127.0.0.1 ". This fails on IPv6-only systems. > > This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 is available. Created a new class for testing ::1 since we can't have duplicate classes. I think this is ok. I?ve included security-dev, as the test in question is in their area. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed May 22 14:15:05 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 May 2019 15:15:05 +0100 Subject: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1 In-Reply-To: References: Message-ID: <7985fd58-3d71-b8c3-1114-cd10cc851bea@oracle.com> Hi Arthur, [adding security-dev] 18 // For IPSupport 19 grant { 20 permission java.net.SocketPermission "localhost:0", "listen,resolve"; 21 permission java.util.PropertyPermission "java.net.preferIPv4Stack", "read"; 22 }; It might be better if these permissions were granted to the library only. 90 // Base64 encoded bytes of simple class: "package bar2; public class Bar2 {}" 91 private final static String BAR2_CLASS = 92 "yv66vgAAADQADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEA" + ... Which version of javac did you use to generate the class? I wonder if it should have the same major/minor version than the other classes in that file. But maybe it doesn't matter. best regards, -- daniel On 21/05/2019 00:50, Arthur Eubanks wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8224256 > webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html > > test/jdk/java/security/SecureClassLoader/DefineClass.java checks that a > security manager works with "http://127.0.0.1". This fails on IPv6-only > systems. > > This change tests 127.0.0.1 if IPv4 is available, then tests ::1 if IPv6 > is available. Created a new class for testing ::1 since we can't have > duplicate classes. From sean.mullan at oracle.com Wed May 22 14:55:58 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 May 2019 10:55:58 -0400 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> Message-ID: <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> On 5/21/19 7:19 PM, Valerie Peng wrote: > > I thought we always file CSR when updating the version of external > standard, e.g. documenting the import aspect of JDK. Good point though I think that was primarily based on whether the external standard was referenced in the javadocs of the standard APIs or influenced the behavior of existing APIs in some way. I don't think PKCS#11 is referenced from any of our standard APIs, but since this new version does add support for additional crypto algorithms via the standard APIs that weren't previously available, that sounds like a good enough reason for filing the CSR. I would recommend adding some additional details to the CSR to list what new features/algorithms PKCS#11 v2.40 provides and which standard APIs those features are applicable to. It would also be helpful to add similar details to the main issue and the release note as there aren't many details about what features are in the new version. Thanks, Sean > > I'd love to close/withdraw the CSR if it's not needed. > > Thanks, > Valerie > On 5/20/2019 12:11 PM, Sean Mullan wrote: >> On 5/17/19 3:56 PM, Valerie Peng wrote: >>> >>> Thanks Martin for helping me troubleshoot NSS side, I added PSS >>> support into PKCS11 provider and added PSS-specific regression tests. >>> Please find webrev updated as below: >>> >>> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>> >>> Can someone help review the CSR first as the approval may take a week >>> or so. >> >> I am curious why a CSR is needed? This seems to be strictly an >> implementation change with no compatibility effects. >> >> --Sean >> >>> >>> Thanks, >>> Valerie >>> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>>> >>>> Anyone has time to review this? Besides the header files update, I >>>> added support for AES/GCM/NoPadding support. Ran into some strange >>>> NSS error with RSASSA-PSS signature mechanism, so I have not >>>> included the PSS signature impl here. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>> >>>> Thanks, >>>> Valerie >>>> >>>> From sean.mullan at oracle.com Wed May 22 15:39:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 May 2019 11:39:54 -0400 Subject: RFR: 8202651: Test ActalisCA.java and ComodoCA fails In-Reply-To: References: Message-ID: On 5/21/19 5:31 PM, Rajan Halade wrote: > Please review this fix to update test certificates used in Actalis and > Comodo CA interop tests. The bug also mentioned QuoVadisCA test but I am > not able to reproduce the failure. For Actalis CA, I couldn't get > revoked test certificate but the test is updated for valid certificate > and will pass now by skipping expired revoked chain. It looks like the test is still expecting a revoked status - is that still working because the IntCA is revoked?: 232 // Validate Revoked 233 pathValidator.validate(new String[]{REVOKED, INT_REVOKED}, 234 ValidatePathWithParams.Status.REVOKED, 235 "Fri Jan 29 01:06:42 PST 2016", System.out); 236 It should be ok if the revoked certificate is expired though as you can set the validation date to the past (within the interval where the certificate is still valid). Or is it because the Actalis OCSP responder is no longer reporting that the certificate is revoked? --Sean > > Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8202651 > > Thanks, > Rajan From rajan.halade at oracle.com Wed May 22 16:04:51 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 22 May 2019 09:04:51 -0700 Subject: RFR: 8202651: Test ActalisCA.java and ComodoCA fails In-Reply-To: References: Message-ID: <85afb9b2-ed71-997e-e6e2-bbb8a37ff9f0@oracle.com> On 5/22/19 8:39 AM, Sean Mullan wrote: > On 5/21/19 5:31 PM, Rajan Halade wrote: >> Please review this fix to update test certificates used in Actalis >> and Comodo CA interop tests. The bug also mentioned QuoVadisCA test >> but I am not able to reproduce the failure. For Actalis CA, I >> couldn't get revoked test certificate but the test is updated for >> valid certificate and will pass now by skipping expired revoked chain. > > It looks like the test is still expecting a revoked status - is that > still working because the IntCA is revoked?: It is working because revoked certificate is expired, test is skipped then. > > ?232???????? // Validate Revoked > ?233???????? pathValidator.validate(new String[]{REVOKED, INT_REVOKED}, > ?234???????????????? ValidatePathWithParams.Status.REVOKED, > ?235???????????????? "Fri Jan 29 01:06:42 PST 2016", System.out); > ?236 > > It should be ok if the revoked certificate is expired though as you > can set the validation date to the past (within the interval where the > certificate is still valid). > Or is it because the Actalis OCSP responder is no longer reporting > that the certificate is revoked? Earlier test had past validation with OCSP but for some time now OCSP is returning UNKNOWN status instead of REVOKED. This could be an issue depending on how implementation treats UNKNOWN status. We will have to follow up with CA to check on policy - Is this only happening because we are using test certificate or is it a policy? Thanks, Rajan > > --Sean > >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202651 >> >> Thanks, >> Rajan From sean.mullan at oracle.com Wed May 22 16:34:56 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 May 2019 12:34:56 -0400 Subject: RFR: 8202651: Test ActalisCA.java and ComodoCA fails In-Reply-To: <85afb9b2-ed71-997e-e6e2-bbb8a37ff9f0@oracle.com> References: <85afb9b2-ed71-997e-e6e2-bbb8a37ff9f0@oracle.com> Message-ID: On 5/22/19 12:04 PM, Rajan Halade wrote: > On 5/22/19 8:39 AM, Sean Mullan wrote: >> On 5/21/19 5:31 PM, Rajan Halade wrote: >>> Please review this fix to update test certificates used in Actalis >>> and Comodo CA interop tests. The bug also mentioned QuoVadisCA test >>> but I am not able to reproduce the failure. For Actalis CA, I >>> couldn't get revoked test certificate but the test is updated for >>> valid certificate and will pass now by skipping expired revoked chain. >> >> It looks like the test is still expecting a revoked status - is that >> still working because the IntCA is revoked?: > It is working because revoked certificate is expired, test is skipped then. Have you asked Actalis for a new revoked test certificate? If you can't get one, I would remove the revoked certificates and the test for it then, since you are not testing that behavior anymore and that is not apparent from the test right now. Also do you know why the revocation check for the intermediate CA is not working? >> >> ?232???????? // Validate Revoked >> ?233???????? pathValidator.validate(new String[]{REVOKED, INT_REVOKED}, >> ?234???????????????? ValidatePathWithParams.Status.REVOKED, >> ?235???????????????? "Fri Jan 29 01:06:42 PST 2016", System.out); >> ?236 >> >> It should be ok if the revoked certificate is expired though as you >> can set the validation date to the past (within the interval where the >> certificate is still valid). >> Or is it because the Actalis OCSP responder is no longer reporting >> that the certificate is revoked? > Earlier test had past validation with OCSP but for some time now OCSP is > returning UNKNOWN status instead of REVOKED. This could be an issue > depending on how implementation treats UNKNOWN status. We will have to > follow up with CA to check on policy - Is this only happening because we > are using test certificate or is it a policy? It depends, if it is a TLS certificate then it is usually acceptable to report the revoked certificate as UNKNOWN after it expires since you should not be trusting expired TLS certificates. For a code signing certificate, it is better to retain the REVOKED status for a longer time period after it expires since it may still be in use (for example, in a timestamped application). --Sean > > Thanks, > Rajan >> >> --Sean >> >>> >>> Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202651 >>> >>> Thanks, >>> Rajan > From valerie.peng at oracle.com Wed May 22 16:54:06 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 22 May 2019 09:54:06 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> <5a4007a2-da92-1a04-ca85-7ac06bf6b9af@oracle.com> Message-ID: Thanks, we do have optimization in place for default providers bundled with JDK. But for 3rd party providers, provider verification may get complicated and recursive. Thanks again for the comments/feedbacks, Valerie On 5/22/2019 3:20 AM, Alan Bateman wrote: > On 22/05/2019 01:02, Valerie Peng wrote: >> >> Well, I initially tried to use the computeIfAbsent, and I really like >> how the resulting code looks. But then as I checked the javadoc of >> the computeIfAbsent method, it seems that the provider verification >> code does not meet the criteria of short, simple requirement of the >> mapping func. In addition, the verification of 3rd party provider may >> trigger the verification of other providers which means updating the >> other mappings of the same map which the javadoc says the mapping >> func *must not* do. I don't know the internals of ConcurrentHashMap, >> would this possibly lead to a deadlock? So, I just followed the >> existing model of sync'ing on JceSecurity class. I didn't proceed >> with performance measuring of computeIfAbsent given the above reason. > Fair enough, if it does indeed take a lot of time to compute then what > you have is okay. > > -Alan From sean.mullan at oracle.com Wed May 22 17:18:51 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 May 2019 13:18:51 -0400 Subject: Fwd: Re: RFR: 8224202: Speed up Properties.load In-Reply-To: <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com> References: <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com> Message-ID: FYI, in case you are not subscribed to core-libs-dev. --Sean -------- Forwarded Message -------- Subject: Re: RFR: 8224202: Speed up Properties.load Date: Wed, 22 May 2019 19:15:07 +0200 From: Claes Redestad To: core-libs-dev Reworked after further analysis: - swapping out char[] for StringBuilder was only a win for the outgoing buffer - using locals for oft-accessed variables in readLine is a substantial interpreter-only optimization[1] - the skipLF logic can safely be folded into the end-of-line logic, thus removing a test from every non-comment character read - splitting apart the InputStream / Reader removes numerous branches and allows some improvements for the common InputStream case - at the price of some code duplication In total, this patch now means we need to execute almost half as much bytecode to load java.security. In my local tests this means we load java.security ~1.5-2ms faster. New webrev: http://cr.openjdk.java.net/~redestad/8224202/open.01/ /Claes [1] this optimization effort is motivated by startup regressions caused by loading java.security earlier during bootstrap in some configurations; the number of property files we load is typically small and happen early, so optimization focus is thus on making it faster during bootstrap, i.e., interpreted performance - if we were optimizing for parsing many property files we'd probably need to restructure the logic, e.g., splitting out duplicate code into smaller methods etc.. On 2019-05-21 12:22, Claes Redestad wrote: > Hi, > > a few smaller optimizations for Properties.load: > > - when parsing comment lines, we unnecessarily breaks the fast path loop > on backslashes, even though a backslash embedded in a comment line will > never have any effect on subsequent logical lines > > - inside that same loop, we always do two comparisons in the common > case: testing c <= '\r' && c >= '\n' would mean only one comparisonin > the common case, since c is very likely to be > '\r' (also when reading > from a byte stream) > > - we currently store everything into temporary char[]'s which we then > instantiate Strings with. Since Compact String this means we often > use more temporary storage than necessary, and do unnecessary work > packing from char[] to byte[] representation internally; by using > StringBuilder encoding transitions is handled more gracefully and is a > speed-up in general (both interpreted and compiled) while simplifying > the code somewhat. > > Result is ~5-20% faster depending on how comment-heavy the properties > file we're loading is. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8224202 > Webrev: http://cr.openjdk.java.net/~redestad/8224202/open.00/ > > Testing: tier1-3 > > Patch is applied on top of JDK-8224240, patch for which is out for > review here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060301.html > > Thanks! > > /Claes From valerie.peng at oracle.com Wed May 22 17:30:12 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 22 May 2019 10:30:12 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> Message-ID: <25da6754-8990-50a5-eb4c-ad30a3984af2@oracle.com> Updated per Daniel's feedback on IdentityWrapper: http://cr.openjdk.java.net/~valeriep/7107615/webrev.04/ Mach5 run is clean. Thanks, Valerie On 5/21/2019 5:51 PM, Valerie Peng wrote: > Hi Daniel, > > Good point, I assumed that this general purpose parameterized > IdentityWrapper class can easily be leveraged for similar fixes if > needed. As currently, only Provider type is used so it doesn't really > needs to use parameter type. I will update and re-test. > > My local build and testing runs fine. I thought my mach5 job comes > back ok as well. I will re-submit mach5 with the updated webrev just > to be safe. > > Regards, > Valerie > On 5/16/2019 1:55 AM, Daniel Fuchs wrote: >> Hi Valerie, >> >> This looks good to me. >> >> I just wonder why IdentityWrapper has a parameter type as it >> seems it's only used with T = Provider. >> I mean - this is fine - and I understand why you did it this way >> as the general purpose parameterized class is much easier to name, >> but I wonder if you wouldn't get a "rawtype" warning at line 418 if >> you compiled that with -Xlint. >> >> best regards, >> >> -- daniel >> >> On 15/05/2019 20:11, Valerie Peng wrote: >>> I updated the webrev to switch to ConcurrentHashMap. The javadoc >>> spec of computeIfAbsent method cautioned that the mapping func >>> should be short and simple and must not attempt to update other >>> mappings of this map. Provider verification code does not quite fit >>> the above criteria for the mapping. So, I did not use >>> computeIfAbsent method and just made minor update to webrev.01 with >>> Xuelei's suggestion of re-checking the cache again inside the >>> synchronized block. >>> >>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/ >>> >>> Comments? >>> >>> Thanks, >>> Valerie From daniel.fuchs at oracle.com Wed May 22 17:36:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 May 2019 18:36:55 +0100 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <25da6754-8990-50a5-eb4c-ad30a3984af2@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> <9a12e860-564f-bcca-6792-804eeb3462d6@oracle.com> <25da6754-8990-50a5-eb4c-ad30a3984af2@oracle.com> Message-ID: <895c0d9d-6d61-cd26-fe5f-0e2c42664e5c@oracle.com> Looks good to me Valerie! Best regards, -- daniel On 22/05/2019 18:30, Valerie Peng wrote: > Updated per Daniel's feedback on IdentityWrapper: > > http://cr.openjdk.java.net/~valeriep/7107615/webrev.04/ > > Mach5 run is clean. > > Thanks, > Valerie From rajan.halade at oracle.com Wed May 22 17:35:05 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 22 May 2019 10:35:05 -0700 Subject: RFR: 8202651: Test ActalisCA.java and ComodoCA fails In-Reply-To: References: <85afb9b2-ed71-997e-e6e2-bbb8a37ff9f0@oracle.com> Message-ID: On 5/22/19 9:34 AM, Sean Mullan wrote: > On 5/22/19 12:04 PM, Rajan Halade wrote: >> On 5/22/19 8:39 AM, Sean Mullan wrote: >>> On 5/21/19 5:31 PM, Rajan Halade wrote: >>>> Please review this fix to update test certificates used in Actalis >>>> and Comodo CA interop tests. The bug also mentioned QuoVadisCA test >>>> but I am not able to reproduce the failure. For Actalis CA, I >>>> couldn't get revoked test certificate but the test is updated for >>>> valid certificate and will pass now by skipping expired revoked chain. >>> >>> It looks like the test is still expecting a revoked status - is that >>> still working because the IntCA is revoked?: >> It is working because revoked certificate is expired, test is skipped >> then. > > Have you asked Actalis for a new revoked test certificate? If you > can't get one, I would remove the revoked certificates and the test > for it then, since you are not testing that behavior anymore and that > is not apparent from the test right now. I will follow up with CA then and leave this bug open for now. > > Also do you know why the revocation check for the intermediate CA is > not working? Revocation check on intermediate CA is working fine. INT_REVOKED is a good certificate, may name is misleading. INT_REVOKED here means that this is a intermediate CA for revoked EE certificate. Thanks, Rajan > >>> >>> ?232???????? // Validate Revoked >>> ?233???????? pathValidator.validate(new String[]{REVOKED, INT_REVOKED}, >>> ?234???????????????? ValidatePathWithParams.Status.REVOKED, >>> ?235???????????????? "Fri Jan 29 01:06:42 PST 2016", System.out); >>> ?236 >>> >>> It should be ok if the revoked certificate is expired though as you >>> can set the validation date to the past (within the interval where >>> the certificate is still valid). >>> Or is it because the Actalis OCSP responder is no longer reporting >>> that the certificate is revoked? >> Earlier test had past validation with OCSP but for some time now OCSP >> is returning UNKNOWN status instead of REVOKED. This could be an >> issue depending on how implementation treats UNKNOWN status. We will >> have to follow up with CA to check on policy - Is this only happening >> because we are using test certificate or is it a policy? > > It depends, if it is a TLS certificate then it is usually acceptable > to report the revoked certificate as UNKNOWN after it expires since > you should not be trusting expired TLS certificates. For a code > signing certificate, it is better to retain the REVOKED status for a > longer time period after it expires since it may still be in use (for > example, in a timestamped application). > > --Sean > >> >> Thanks, >> Rajan >>> >>> --Sean >>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202651 >>>> >>>> Thanks, >>>> Rajan >> From daniel.fuchs at oracle.com Wed May 22 17:40:23 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 May 2019 18:40:23 +0100 Subject: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1 In-Reply-To: References: <0645432e-e340-c017-761c-2d0b4e6c153e@oracle.com> Message-ID: <8cc82969-d102-6839-f488-ab93aad8dd50@oracle.com> Hi Arthur, On 22/05/2019 18:28, Arthur Eubanks wrote: > New webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.01/ Looks good to me - please just get someone from security-dev to review too. best regards, -- daniel From sha.jiang at oracle.com Thu May 23 03:28:17 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 23 May 2019 11:28:17 +0800 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> Message-ID: <004dea56-6d88-0e4f-c24f-1c8a3812b407@oracle.com> Hi Tony, The new introduced properties in the source and CSR are jdk.tls.client.sessionTicketExtension and jdk.tls.server.sessionCacheState, but the new tests ResumeChecksClientStateless.java and ResumeChecksServerStateless.java use javax.net.ssl.sessionTicketExtension and javax.net.ssl.sessionCacheServer. Best regards, John Jiang On 2019/5/22 08:35, Anthony Scarpino wrote: > Hi all, > > I?ve updated in-place some recent changes due to some additional testing > > Tony > >> On May 16, 2019, at 2:30 PM, Anthony Scarpino wrote: >> >> I'm asking for a review of this rather large change to add support stateless tickets in the TLS 1.3 5077 RFC. >> https://bugs.openjdk.java.net/browse/JDK-8211018 >> >> http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 >> >> thanks >> >> Tony > From anthony.scarpino at oracle.com Thu May 23 04:05:50 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 22 May 2019 21:05:50 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <004dea56-6d88-0e4f-c24f-1c8a3812b407@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> <004dea56-6d88-0e4f-c24f-1c8a3812b407@oracle.com> Message-ID: <92961fd2-a932-1d7a-f086-3117d494ef14@oracle.com> On 5/22/19 8:28 PM, sha.jiang at oracle.com wrote: > Hi Tony, > The new introduced properties in the source and CSR are > jdk.tls.client.sessionTicketExtension and jdk.tls.server.sessionCacheState, > but the new tests ResumeChecksClientStateless.java and > ResumeChecksServerStateless.java use > javax.net.ssl.sessionTicketExtension and javax.net.ssl.sessionCacheServer. > > Best regards, > John Jiang Ah.. thanks.. Apparently the rename by the IDE didn't rename everything.. strange.. Tony > > On 2019/5/22 08:35, Anthony Scarpino wrote: >> Hi all, >> >> I?ve updated in-place some recent changes due to some additional testing >> >> Tony >> >>> On May 16, 2019, at 2:30 PM, Anthony Scarpino >>> wrote: >>> >>> I'm asking for a review of this rather large change to add support >>> stateless tickets in the TLS 1.3 5077 RFC. >>> https://bugs.openjdk.java.net/browse/JDK-8211018 >>> >>> http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 >>> >>> thanks >>> >>> Tony >> From daniel.fuchs at oracle.com Thu May 23 09:32:38 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 23 May 2019 10:32:38 +0100 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed Message-ID: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Hi, Please find a patch below that temporarily problem lists java/security/SecureClassLoader/DefineClass.java on linux and windows until JDK-8224635 [1] is fixed: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed https://bugs.openjdk.java.net/browse/JDK-8224656 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/ best regards -- daniel diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -664,6 +664,7 @@ sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all sun/security/pkcs11/KeyStore/SecretKeysBasic.sh 8209398 generic-all +java/security/SecureClassLoader/DefineClass.java 8224635 windows-all,linux-all ############################################################################ From david.holmes at oracle.com Thu May 23 09:40:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 May 2019 19:40:11 +1000 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: <10b2ec3d-ebce-2e50-ebc3-e8fcc001b791@oracle.com> Looks good! Thanks Daniel. David On 23/05/2019 7:32 pm, Daniel Fuchs wrote: > Hi, > > Please find a patch below that temporarily problem lists > java/security/SecureClassLoader/DefineClass.java > on linux and windows until JDK-8224635 [1] is fixed: > > 8224656: Problem list java/security/SecureClassLoader/DefineClass.java > ???????? until JDK-8224635 is fixed > https://bugs.openjdk.java.net/browse/JDK-8224656 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/ > > best regards > > -- daniel > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -664,6 +664,7 @@ > ?sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all > > ?sun/security/pkcs11/KeyStore/SecretKeysBasic.sh 8209398 generic-all > +java/security/SecureClassLoader/DefineClass.java??????????????? 8224635 > windows-all,linux-all > > > ############################################################################ > > From Alan.Bateman at oracle.com Thu May 23 09:39:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 May 2019 10:39:47 +0100 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: On 23/05/2019 10:32, Daniel Fuchs wrote: > Hi, > > Please find a patch below that temporarily problem lists > java/security/SecureClassLoader/DefineClass.java > on linux and windows until JDK-8224635 [1] is fixed: > > 8224656: Problem list java/security/SecureClassLoader/DefineClass.java > ???????? until JDK-8224635 is fixed > https://bugs.openjdk.java.net/browse/JDK-8224656 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/ Looks fine. From chris.hegarty at oracle.com Thu May 23 09:40:58 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 May 2019 10:40:58 +0100 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: <7AB30D9D-23D0-407A-8D7A-2130F0237475@oracle.com> Daniel, > On 23 May 2019, at 10:32, Daniel Fuchs wrote: > > Hi, > > Please find a patch below that temporarily problem lists > java/security/SecureClassLoader/DefineClass.java > on linux and windows until JDK-8224635 [1] is fixed: > > 8224656: Problem list java/security/SecureClassLoader/DefineClass.java > until JDK-8224635 is fixed > https://bugs.openjdk.java.net/browse/JDK-8224656 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/ > Reviewed. Thanks, -Chris. From christoph.langer at sap.com Thu May 23 10:21:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 23 May 2019 10:21:16 +0000 Subject: RFR: 8202651: Test ActalisCA.java and ComodoCA fails In-Reply-To: References: <85afb9b2-ed71-997e-e6e2-bbb8a37ff9f0@oracle.com> Message-ID: Hi Rajan, Sean, first of all, thanks for the update on the tests. As I see, there are still open questions for the ActalisCA test. So I'm wondering whether the fix for ComodoCA can be pushed as fix for https://bugs.openjdk.java.net/browse/JDK-8215546 ? Furthermore, can we also exclude the ActalisCA test via the ProblemList for the time being? I believe this has not been done because these tests aren't part of any regular test tiers. However, we at SAP run all possible tests in the test folder in some suite of the test environment and it would be good if the test could be excluded then. I would file a bug and do the change if you agree. Other than that, I'm observing another issue in the CRL test for ActalisCA. It fails with this message: "Received exception: java.security.cert.CertPathValidatorException: sun.security.provider.certpath.PKIX$CertStoreTypeException: Invalid name: cn=Actalis Authentication Root CA,o=Actalis S.p.A./03358520967,c=IT". The problem is that the certificate's issue name is literally taken as javax.naming. CompositeName in LDAPCertStoreImpl. The forward slash symbol '/' is, however, used as component separator in LDAP composite names. So it needs escaping. I'll file a bug and propose a fix for this in a separate thread. I'm actually wondering why this hasn't been reported yet but I don't see similar bugs... Thank you Christoph > -----Original Message----- > From: security-dev On Behalf Of > Rajan Halade > Sent: Mittwoch, 22. Mai 2019 19:35 > To: Sean Mullan > Cc: security-dev > Subject: Re: RFR: 8202651: Test ActalisCA.java and ComodoCA fails > > On 5/22/19 9:34 AM, Sean Mullan wrote: > > On 5/22/19 12:04 PM, Rajan Halade wrote: > >> On 5/22/19 8:39 AM, Sean Mullan wrote: > >>> On 5/21/19 5:31 PM, Rajan Halade wrote: > >>>> Please review this fix to update test certificates used in Actalis > >>>> and Comodo CA interop tests. The bug also mentioned QuoVadisCA > test > >>>> but I am not able to reproduce the failure. For Actalis CA, I > >>>> couldn't get revoked test certificate but the test is updated for > >>>> valid certificate and will pass now by skipping expired revoked chain. > >>> > >>> It looks like the test is still expecting a revoked status - is that > >>> still working because the IntCA is revoked?: > >> It is working because revoked certificate is expired, test is skipped > >> then. > > > > Have you asked Actalis for a new revoked test certificate? If you > > can't get one, I would remove the revoked certificates and the test > > for it then, since you are not testing that behavior anymore and that > > is not apparent from the test right now. > I will follow up with CA then and leave this bug open for now. > > > > Also do you know why the revocation check for the intermediate CA is > > not working? > Revocation check on intermediate CA is working fine. INT_REVOKED is a > good certificate, may name is misleading. INT_REVOKED here means that > this is a intermediate CA for revoked EE certificate. > > Thanks, > Rajan > > > >>> > >>> ?232???????? // Validate Revoked > >>> ?233???????? pathValidator.validate(new String[]{REVOKED, INT_REVOKED}, > >>> ?234???????????????? ValidatePathWithParams.Status.REVOKED, > >>> ?235???????????????? "Fri Jan 29 01:06:42 PST 2016", System.out); > >>> ?236 > >>> > >>> It should be ok if the revoked certificate is expired though as you > >>> can set the validation date to the past (within the interval where > >>> the certificate is still valid). > >>> Or is it because the Actalis OCSP responder is no longer reporting > >>> that the certificate is revoked? > >> Earlier test had past validation with OCSP but for some time now OCSP > >> is returning UNKNOWN status instead of REVOKED. This could be an > >> issue depending on how implementation treats UNKNOWN status. We > will > >> have to follow up with CA to check on policy - Is this only happening > >> because we are using test certificate or is it a policy? > > > > It depends, if it is a TLS certificate then it is usually acceptable > > to report the revoked certificate as UNKNOWN after it expires since > > you should not be trusting expired TLS certificates. For a code > > signing certificate, it is better to retain the REVOKED status for a > > longer time period after it expires since it may still be in use (for > > example, in a timestamped application). > > > > --Sean > > > >> > >> Thanks, > >> Rajan > >>> > >>> --Sean > >>> > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/ > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202651 > >>>> > >>>> Thanks, > >>>> Rajan > >> From daniel.fuchs at oracle.com Thu May 23 10:30:22 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 23 May 2019 11:30:22 +0100 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: Hi, I have observed an intermittent failure on Solaris. So I changed the patch to problem-list the test on all platform. Is that still OK? http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 best regards, -- daniel On 23/05/2019 10:32, Daniel Fuchs wrote: > Hi, > > Please find a patch below that temporarily problem lists > java/security/SecureClassLoader/DefineClass.java > on linux and windows until JDK-8224635 [1] is fixed: > > 8224656: Problem list java/security/SecureClassLoader/DefineClass.java > ???????? until JDK-8224635 is fixed > https://bugs.openjdk.java.net/browse/JDK-8224656 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/ From Alan.Bateman at oracle.com Thu May 23 10:31:50 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 May 2019 11:31:50 +0100 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: <2018ec3e-cc90-9117-6467-51d24fdddf59@oracle.com> On 23/05/2019 11:30, Daniel Fuchs wrote: > Hi, > > I have observed an intermittent failure on Solaris. > So I changed the patch to problem-list the test on all platform. > > Is that still OK? > > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 Looks fine. From chris.hegarty at oracle.com Thu May 23 10:34:13 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 May 2019 11:34:13 +0100 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: Daniel, > On 23 May 2019, at 11:30, Daniel Fuchs wrote: > > Hi, > > I have observed an intermittent failure on Solaris. > So I changed the patch to problem-list the test on all platform. > > Is that still OK? > > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 Looks good. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeubanks at google.com Thu May 23 16:08:01 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 23 May 2019 09:08:01 -0700 Subject: [RFR] 8224635: Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8224635 webrev: http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html Test java/security/SecureClassLoader/DefineClass.java is failing after JDK-8224256 This change reverts the changes in JDK-8224256 and adds back in the test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu May 23 16:21:12 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 May 2019 12:21:12 -0400 Subject: [RFR] 8224635: Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test In-Reply-To: References: Message-ID: <0d24fa54-c371-8cce-6638-7bdb78f39e66@oracle.com> Looks fine although you should update the 8224635 title to match the changeset. Also, I assume you will file a followon bug for the original issue (JDK-8224256). I think a new bug must be filed instead of re-opening 8224256 because a changeset has already been pushed for it. --Sean On 5/23/19 12:08 PM, Arthur Eubanks wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8224635 > webrev: http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html > > Test java/security/SecureClassLoader/DefineClass.java is failing after > JDK-8224256 > This change reverts the changes in?JDK-8224256 and adds back in the test. From aeubanks at google.com Thu May 23 16:28:33 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 23 May 2019 09:28:33 -0700 Subject: [RFR] 8224635: Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test In-Reply-To: <0d24fa54-c371-8cce-6638-7bdb78f39e66@oracle.com> References: <0d24fa54-c371-8cce-6638-7bdb78f39e66@oracle.com> Message-ID: On Thu, May 23, 2019 at 9:23 AM Sean Mullan wrote: > Looks fine although you should update the 8224635 title to match the > changeset. > Done > > Also, I assume you will file a followon bug for the original issue > (JDK-8224256). I think a new bug must be filed instead of re-opening > 8224256 because a changeset has already been pushed for it. > Yes I will file another bug to get this back in, this time making sure that it passes on mach5 tier2 before submitting. > > --Sean > > On 5/23/19 12:08 PM, Arthur Eubanks wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224635 > > webrev: > http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html > > > > Test java/security/SecureClassLoader/DefineClass.java is failing after > > JDK-8224256 > > This change reverts the changes in JDK-8224256 and adds back in the test. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu May 23 18:16:09 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 May 2019 14:16:09 -0400 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: On 5/21/19 7:24 PM, Anthony Scarpino wrote: > Hi All, > > Please review the CSR for the stateless Server Side > https://bugs.openjdk.java.net/browse/JDK-8223922 Some initial comments/questions: I think the scope should be "JDK" since you are adding new JDK-specific system properties that users can set to change the behavior. For previous system properties that enable extensions, we have used a boolean property with the naming convention "jdk.tls.client.enable References: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> <7bc3de26-6d68-1bc6-2248-ed83a08eaf74@oracle.com> <11B6324B-6E4A-429B-936F-B64442AF9E91@googlemail.com> <28367A93-9498-4158-A289-2F906CDDB8FD@googlemail.com> Message-ID: Hi there, Did the debug log help at all or should I try to gather more informations from the user ? Bye Norman > On 17. May 2019, at 21:26, Norman Maurer wrote: > > The user did capture the log here: > > https://hasteb.in/ucalevob.makefile > > Hopefully it is helpful, > > Norman > > >> On 17. May 2019, at 20:38, Norman Maurer > wrote: >> >> Unfortunately I am very busy atm so it may take me a few days. I asked the original reported of the issue to provide some in the netty issue tracker. I will come back to you. >> >> Bye >> Norman >> >> >>> On 17. May 2019, at 20:27, Xuelei Fan > wrote: >>> >>> Hi Norman, >>> >>> If you are able to reproduce this issue, would you mind post the JSSE debug log (by using Java System Property, "javax.net.debug=all")? >>> >>> Please feel free to submit a bug. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> On 5/17/2019 11:02 AM, Norman Maurer wrote: >>>> Hi there, >>>> We recently received a bug report in netty when JDK12 is used with ChaCha chiphers: >>>> https://github.com/netty/netty/issues/9150 >>>> Basically it seems like there is a problem in how it uses the ByteBuffer internally: >>>> |Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703) at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188) at java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: Output buffer too small at java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360) at java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)| >>>> Unfortunately I have no standalone reproducer yet but I just wanted to bring it up here in case it helps. >>>> It only happens on JDK12 it seems. Check the Netty issue for more details? >>>> Bye >>>> Norman >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu May 23 18:25:55 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 May 2019 14:25:55 -0400 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: <272164b7-df09-e87f-ab29-af288d706a70@oracle.com> On 5/23/19 2:16 PM, Sean Mullan wrote: > I was wondering if you really need the jdk.tls.server.sessionCacheState > system property and if so, why the default is not "mixed". Shouldn't the > server decide to cache or not depending on whether the client sends the > SessionTicket Extension? Actually, I see now that there may be valid reasons for not enabling this feature on the server side. So yes I now see that the property is useful, and the default setting of it not being on makes sense. I was wondering if this could be a true/false property though - do we really need the "stateless" setting? --Sean From anthony.scarpino at oracle.com Thu May 23 18:39:49 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 23 May 2019 11:39:49 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: <272164b7-df09-e87f-ab29-af288d706a70@oracle.com> References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> <272164b7-df09-e87f-ab29-af288d706a70@oracle.com> Message-ID: I stayed away from a boolean value in case some day another option came around. "stateless" I don't see an often used option, but maybe someone wants to keep no cache for memory reasons. I didn't want to eliminate that options by using a boolean value. As far as defaults. Today it would be default "cache" and if all goes well maybe 14 it can be switch to "mixed" Tony On 5/23/19 11:25 AM, Sean Mullan wrote: > On 5/23/19 2:16 PM, Sean Mullan wrote: > >> I was wondering if you really need the >> jdk.tls.server.sessionCacheState system property and if so, why the >> default is not "mixed". Shouldn't the server decide to cache or not >> depending on whether the client sends the SessionTicket Extension? > > Actually, I see now that there may be valid reasons for not enabling > this feature on the server side. So yes I now see that the property is > useful, and the default setting of it not being on makes sense. I was > wondering if this could be a true/false property though - do we really > need the "stateless" setting? > > --Sean From anthony.scarpino at oracle.com Thu May 23 18:45:17 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 23 May 2019 11:45:17 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: On 5/23/19 11:16 AM, Sean Mullan wrote: > On 5/21/19 7:24 PM, Anthony Scarpino wrote: >> Hi All, >> >> Please review the CSR for the stateless Server Side >> https://bugs.openjdk.java.net/browse/JDK-8223922 > > Some initial comments/questions: > > I think the scope should be "JDK" since you are adding new JDK-specific > system properties that users can set to change the behavior. Sure > > For previous system properties that enable extensions, we have used a > boolean property with the naming convention > "jdk.tls.client.enable "jdk.tls.client.enableStatusRequestExtension", so we should probably > stick to that convention and call it > "jdk.tls.client.enableSessionTicketExtension" (with value true/false). In those other cases with "enable" are they never on by default. I don't have a problem with renaming it for consistency. But, when the property is enabled by default, it seems a bit funny wording-wise to have to use "j.t.c.enableSessionTicketExtension=false" > > I was wondering if you really need the jdk.tls.server.sessionCacheState > system property and if so, why the default is not "mixed". Shouldn't the > server decide to cache or not depending on whether the client sends the > SessionTicket Extension? > > Thanks, > Sean From jamil.j.nimeh at oracle.com Thu May 23 19:04:45 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 23 May 2019 12:04:45 -0700 Subject: Possible bug with JDK12 and ChaCha ciphers In-Reply-To: References: <7C6CE679-A5B4-4A24-A4FF-854E48373C42@googlemail.com> <7bc3de26-6d68-1bc6-2248-ed83a08eaf74@oracle.com> <11B6324B-6E4A-429B-936F-B64442AF9E91@googlemail.com> <28367A93-9498-4158-A289-2F906CDDB8FD@googlemail.com> Message-ID: <97043d43-49ad-9ca3-086f-ede3003ac187@oracle.com> It did help some, yes.? I'm trying to get to a point where I can reproduce the issue because it isn't immediately clear why that last record is causing the ShortBufferException.? I'm hoping there's a way to do that without having to hit that discord server.? Ideally I'd need to turn this into some kind of regression test that more easily isolates the issue. --Jamil On 5/23/2019 11:24 AM, Norman Maurer wrote: > Hi there, > > > Did the debug log help at all or should I try to gather more > informations from the user ? > > Bye > Norman > > >> On 17. May 2019, at 21:26, Norman Maurer >> > >> wrote: >> >> The user did capture the log here: >> >> https://hasteb.in/ucalevob.makefile >> >> Hopefully it is helpful, >> >> Norman >> >> >>> On 17. May 2019, at 20:38, Norman Maurer >>> > >>> wrote: >>> >>> Unfortunately I am very busy atm so it may take me a few days. I >>> asked the original reported of the issue to provide some in the >>> netty issue tracker. I will come back to you. >>> >>> Bye >>> Norman >>> >>> >>>> On 17. May 2019, at 20:27, Xuelei Fan >>> > wrote: >>>> >>>> Hi Norman, >>>> >>>> If you are able to reproduce this issue, would you mind post the >>>> JSSE debug log (by using Java System Property, "javax.net.debug=all")? >>>> >>>> Please feel free to submit a bug. >>>> >>>> Thanks & Regards, >>>> Xuelei >>>> >>>> On 5/17/2019 11:02 AM, Norman Maurer wrote: >>>>> Hi there, >>>>> We recently received a bug report in netty when JDK12 is used with >>>>> ChaCha chiphers: >>>>> https://github.com/netty/netty/issues/9150 >>>>> Basically it seems like there is a problem in how it uses the >>>>> ByteBuffer internally: >>>>> |Caused by: java.lang.RuntimeException: >>>>> javax.crypto.ShortBufferException: Output buffer too small at >>>>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703) >>>>> at >>>>> java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) >>>>> at >>>>> java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) >>>>> at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at >>>>> java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188) >>>>> at >>>>> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240) >>>>> at >>>>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197) >>>>> at >>>>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160) >>>>> at >>>>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) >>>>> at >>>>> java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) >>>>> at >>>>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) >>>>> at >>>>> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) >>>>> ... 25 common frames omitted Caused by: >>>>> javax.crypto.ShortBufferException: Output buffer too small at >>>>> java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360) >>>>> at >>>>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)| >>>>> Unfortunately I have no standalone reproducer yet but I just >>>>> wanted to bring it up here in case it helps. >>>>> It only happens on JDK12 it seems. Check the Netty issue for more >>>>> details? >>>>> Bye >>>>> Norman >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianglizhou at google.com Thu May 23 14:34:25 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 23 May 2019 07:34:25 -0700 Subject: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed In-Reply-To: References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com> Message-ID: Hi Daniel, Thanks for the quick action for problem listing the test! Best regards, Jiangli On Thu, May 23, 2019 at 3:30 AM Daniel Fuchs wrote: > > Hi, > > I have observed an intermittent failure on Solaris. > So I changed the patch to problem-list the test on all platform. > > Is that still OK? > > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 > > best regards, > > -- daniel > > On 23/05/2019 10:32, Daniel Fuchs wrote: > > Hi, > > > > Please find a patch below that temporarily problem lists > > java/security/SecureClassLoader/DefineClass.java > > on linux and windows until JDK-8224635 [1] is fixed: > > > > 8224656: Problem list java/security/SecureClassLoader/DefineClass.java > > until JDK-8224635 is fixed > > https://bugs.openjdk.java.net/browse/JDK-8224656 > > > > webrev: > > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/ From mbalao at redhat.com Thu May 23 19:52:00 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 23 May 2019 16:52:00 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> Message-ID: <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> Hi Xuelei, The JMH benchmark code is at http://cr.openjdk.java.net/~mbalao/webrevs/8223482/ciphersuites_benchmark_v0.tar.gz Once the crypto providers and SSL engines are initialized, the following sequence is measured: 1) Client and Server perform a handshake until status is HandshakeStatus.FINISHED on both ends 2) Server renegotiates the session (SSLEngine.beginHandshake is called) so the sequence repeats. See test_TLS12Communication method in ciphersuites/src/main/java/org/redhat/SupportedCiphersuites.java. Webrev.00 was affecting performance because in each TLS handshake, the client was testing ciphersuites before moving forward. In Webrev.01 a performance impact is not seen here because ciphersuites checking occurs only at SSLContextImpl static class initialization time (not per instance but per static class initializer). Thus, to have a performance impact we would need the class loader to get rid of SSLContextImpl class -subclasses to be accurate- and load it again in every loop -which would make no sense-. Here it's a call stack when "SSLContextImpl.getApplicableCipherSuites" gets executed: Thread [main] (Suspended (breakpoint at line 374 in SSLContextImpl)) SSLContextImpl.getApplicableCipherSuites(Collection, List) line: 374 SSLContextImpl.getApplicableSupportedCipherSuites(List) line: 339 SSLContextImpl$AbstractTLSContext.() line: 555 Class.forName0(String, boolean, ClassLoader, Class) line: not available [native method] Class.forName(String) line: 333 Provider$Service.getImplClass() line: 1842 Provider$Service.newInstance(Object) line: 1818 GetInstance.getInstance(Service, Class) line: 236 GetInstance.getInstance(String, Class, String, String) line: 206 SSLContext.getInstance(String, String) line: 229 SupportedCiphersuites.createSSLEngine(boolean) line: 273 SupportedCiphersuites.createSSLEngines() line: 256 SupportedCiphersuites.initialize() line: 239 SupportedCiphersuites.main(String[]) line: 71 You see there how "SSLContextImpl$AbstractTLSContext.()" static initializer is in the call stack. I've not found any possible execution path to "SSLContextImpl.getApplicableCipherSuites" that does not come from a static class initializer. Thanks, Martin.- From sean.mullan at oracle.com Thu May 23 20:04:01 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 May 2019 16:04:01 -0400 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: <868204bd-b2a8-f702-1a43-5197e0bd7c8c@oracle.com> On 5/23/19 2:45 PM, Anthony Scarpino wrote: >> For previous system properties that enable extensions, we have used a >> boolean property with the naming convention >> "jdk.tls.client.enable> "jdk.tls.client.enableStatusRequestExtension", so we should probably >> stick to that convention and call it >> "jdk.tls.client.enableSessionTicketExtension" (with value true/false). > > In those other cases with "enable" are they never on by > default.? I don't have a problem with renaming it for consistency.? But, > when the property is enabled by default, it seems a bit funny > wording-wise to have to use "j.t.c.enableSessionTicketExtension=false" Maybe, I guess you are saying that at some point, we might flip the default to being on. But if that were the case, I think it would be rare for someone to turn it off (probably mostly for debugging) and (to me anyway) the usage above doesn't seem so weird. --Sean From xuelei.fan at oracle.com Thu May 23 20:29:15 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 23 May 2019 13:29:15 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> Message-ID: <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> Thank you, Marin! I can understand the benchmark more clearly. The current update make an improvement by moving the checking to a singleton block. That's good. But I still has a concern about the loading performance impact of SSLContext. That's, how long it will take to load the SSLContextImpl if checking the crypto operations there? Thanks, Xuelei On 5/23/2019 12:52 PM, Martin Balao wrote: > Hi Xuelei, > > The JMH benchmark code is at > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/ciphersuites_benchmark_v0.tar.gz > > Once the crypto providers and SSL engines are initialized, the following > sequence is measured: > > 1) Client and Server perform a handshake until status is > HandshakeStatus.FINISHED on both ends > > 2) Server renegotiates the session (SSLEngine.beginHandshake is called) > so the sequence repeats. > > See test_TLS12Communication method in > ciphersuites/src/main/java/org/redhat/SupportedCiphersuites.java. > > Webrev.00 was affecting performance because in each TLS handshake, the > client was testing ciphersuites before moving forward. In Webrev.01 a > performance impact is not seen here because ciphersuites checking occurs > only at SSLContextImpl static class initialization time (not per > instance but per static class initializer). Thus, to have a performance > impact we would need the class loader to get rid of SSLContextImpl class > -subclasses to be accurate- and load it again in every loop -which would > make no sense-. > > Here it's a call stack when "SSLContextImpl.getApplicableCipherSuites" > gets executed: > > Thread [main] (Suspended (breakpoint at line 374 in SSLContextImpl)) > SSLContextImpl.getApplicableCipherSuites(Collection, > List) line: 374 > SSLContextImpl.getApplicableSupportedCipherSuites(List) > line: 339 > SSLContextImpl$AbstractTLSContext.() line: 555 > Class.forName0(String, boolean, ClassLoader, Class) line: not > available [native method] > Class.forName(String) line: 333 > Provider$Service.getImplClass() line: 1842 > Provider$Service.newInstance(Object) line: 1818 > GetInstance.getInstance(Service, Class) line: 236 > GetInstance.getInstance(String, Class, String, String) line: 206 > SSLContext.getInstance(String, String) line: 229 > SupportedCiphersuites.createSSLEngine(boolean) line: 273 > SupportedCiphersuites.createSSLEngines() line: 256 > SupportedCiphersuites.initialize() line: 239 > SupportedCiphersuites.main(String[]) line: 71 > > You see there how "SSLContextImpl$AbstractTLSContext.()" static > initializer is in the call stack. > > I've not found any possible execution path to > "SSLContextImpl.getApplicableCipherSuites" that does not come from a > static class initializer. > > Thanks, > Martin.- > From mbalao at redhat.com Thu May 23 22:19:39 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 23 May 2019 19:19:39 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> Message-ID: Hi Xuelei, I've developed a new benchmark to measure SSLContext loading: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_v0.tar.gz Results: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_v0_results_v0 Summary WITHOUT 8223482 FIX ============================================================ Benchmark Mode Cnt Score Error Units SSLContextLoading.test_SSLContextLoading thrpt 10 437456.584 ? 25620.210 ops/s WITH 8223482 FIX (Webrev.01) ============================================================ Benchmark Mode Cnt Score Error Units SSLContextLoading.test_SSLContextLoading thrpt 10 491894.639 ? 27959.271 ops/s However, I'm not sure that this is what you suggested. If we measure "SSLContext.getInstance("TLSv1.2")" alone in a loop, we will have the class static initializer executed only once unless we generate enough memory pressure for the garbage-collector to get rid of the class. I've verified this not only with static analysis but setting a breakpoint. Thus, and considering SSLContextImpl.getApplicableCipherSuites is only called from class static initializers, I would have not expected performance degradation there. Look forward to your answer. Kind regards, Martin.- From xuelei.fan at oracle.com Thu May 23 22:31:19 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 23 May 2019 15:31:19 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> Message-ID: <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> Thank you for the benchmarking. On 5/23/2019 3:19 PM, Martin Balao wrote: > Hi Xuelei, > > I've developed a new benchmark to measure SSLContext loading: > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_v0.tar.gz > > Results: > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_v0_results_v0 > > Summary > > WITHOUT 8223482 FIX > ============================================================ > > Benchmark Mode Cnt Score > Error Units > SSLContextLoading.test_SSLContextLoading thrpt 10 437456.584 ? > 25620.210 ops/s > > WITH 8223482 FIX (Webrev.01) > ============================================================ > > Benchmark Mode Cnt Score > Error Units > SSLContextLoading.test_SSLContextLoading thrpt 10 491894.639 ? > 27959.271 ops/s > > > However, I'm not sure that this is what you suggested. If we measure > "SSLContext.getInstance("TLSv1.2")" alone in a loop, we will have the > class static initializer executed only once unless we generate enough > memory pressure for the garbage-collector to get rid of the class. It is not as the static initialization get run once only. I think you could simplify the test without using the benchmark tool, just measure the start time, end time of the loading one time for each testing, and check it with different providers. No need to be accuracy, a roughly number is sufficient to get an idea if the impact is acceptable. Thanks, Xuelei > I've > verified this not only with static analysis but setting a breakpoint. > Thus, and considering SSLContextImpl.getApplicableCipherSuites is only > called from class static initializers, I would have not expected > performance degradation there. > > Look forward to your answer. > > Kind regards, > Martin.- > From aeubanks at google.com Fri May 24 00:14:07 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 23 May 2019 17:14:07 -0700 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com> References: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com> Message-ID: Ping on a review from security-dev. On Fri, May 17, 2019 at 9:53 AM Chris Hegarty wrote: > Arthur, > > On 17 May 2019, at 17:50, Arthur Eubanks wrote: > > Looks good. >> >> Trivially, maybe amend the comment to be more explicit >> >> 86 // SOCKS V4 ( requires IPv4 ) >> >> -Chris. >> > Done > http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ > > I will wait for another review from security-dev. > > > You have my Review ( conditional on a Reviewer for the test in the > security area ). > > -Chris. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri May 24 03:39:53 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 24 May 2019 11:39:53 +0800 Subject: RFR 6682540: Incorrect SASL DIGEST-MD5 behavior Message-ID: <4981F87D-5EC9-4AB7-A3F9-D67B44BF8EC3@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/6682540/webrev.00/ We don't support subsequent authentication, but at least we will support clients that support it. Thanks, Max From jamil.j.nimeh at oracle.com Fri May 24 05:58:29 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 23 May 2019 22:58:29 -0700 Subject: RFR 6682540: Incorrect SASL DIGEST-MD5 behavior In-Reply-To: <4981F87D-5EC9-4AB7-A3F9-D67B44BF8EC3@oracle.com> References: <4981F87D-5EC9-4AB7-A3F9-D67B44BF8EC3@oracle.com> Message-ID: Looks good to me. --Jamil On 5/23/2019 8:39 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/6682540/webrev.00/ > > We don't support subsequent authentication, but at least we will support clients that support it. > > Thanks, > Max > From christoph.langer at sap.com Fri May 24 08:00:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 May 2019 08:00:49 +0000 Subject: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification Message-ID: Hi, please review the problem listing of security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java and security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java until JDK-8202651 and JDK-8215546 are resolved. Bug: https://bugs.openjdk.java.net/browse/JDK-8224727 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224727.0/ Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri May 24 09:11:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 May 2019 09:11:48 +0000 Subject: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names Message-ID: Hi, please review this fix for an issue that I've discovered when working with test security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java. It fails when the test tries to do the CRL verification of the certificate. It has issues in the LDAP implementation because of the certificate's name "cn=Actalis Authentication Root CA,o=Actalis S.p.A./03358520967,c=IT". The name contains a forward slash which is at the same time a compound separator in javax.naming/LDAP. So it needs some escaping. I also cleaned up some debugging code and removed/commented out unused fields and methods. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8224729 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 24 12:02:14 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 May 2019 08:02:14 -0400 Subject: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names In-Reply-To: References: Message-ID: <5c050f33-7627-86ca-496e-7288602f1be0@oracle.com> Hi Christoph, I don't think this is the right fix. The LDAP URL in the Certificate is incorrect and the forward slash should be escaped. If we start to make workarounds in the code to accept certificates that are not properly encoded, it becomes a slipperly slope. I base my rationale on the following RFCs: 1. https://tools.ietf.org/html/rfc5280#section-4.2.1.13 When the LDAP URI scheme [RFC4516] is used, the URI MUST include a field containing the distinguished name of the entry holding the CRL, MUST include a single that contains an appropriate attribute description for the attribute that holds the CRL [RFC4523], and SHOULD include a (e.g., ). 2. https://tools.ietf.org/html/rfc4516#section-2 The is an LDAP Distinguished Name using the string format described in [RFC4514]. It identifies the base object of the LDAP search or the target of a non-search operation. 3. https://tools.ietf.org/html/rfc4514#section-2.4 If that UTF-8-encoded Unicode string does not have any of the following characters that need escaping, then that string can be used as the string representation of the value. ... - one of the characters '"', '+', ',', ';', '<', '>', or '\' (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, respectively); So, I think the proper way to handle this is to contact the CA and inform that the certificate does not comply with RFC 5280 and should be re-issued. Rajan or I can take care of that and get back to you. For now, if this is blocking your testing, I suggest putting the test on the ProblemList. Thanks, Sean On 5/24/19 5:11 AM, Langer, Christoph wrote: > Hi, > > please review this fix for an issue that I?ve discovered when working > with test > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java. > > It fails when the test tries to do the CRL verification of the > certificate. It has issues in the LDAP implementation because of the > certificate?s name ?cn=Actalis Authentication Root CA,o=Actalis > S.p.A./03358520967,c=IT?. The name contains a forward slash which is at > the same time a compound separator in javax.naming/LDAP. So it needs > some escaping. > > I also cleaned up some debugging code and removed/commented out unused > fields and methods. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224729 > > Thanks > > Christoph > From christoph.langer at sap.com Fri May 24 12:48:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 May 2019 12:48:31 +0000 Subject: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names In-Reply-To: <5c050f33-7627-86ca-496e-7288602f1be0@oracle.com> References: <5c050f33-7627-86ca-496e-7288602f1be0@oracle.com> Message-ID: Hi Sean, ok, I see, you're fully correct. So I hereby withdraw my fix proposal. As for the exclusion of the test: I have requested it this morning anyway: https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019966.html. So I would assume that you ask Actalis to reissue the certificates anyway and then eventually resolve 8202651 with a good certificate? As for Bug JDK-8224729: Shall I just close the ticket, dropping a comment about the ignorance of the author or shall I repurpose it to do the other cleanups in LDAPCertStoreImpl.java that I suggested? Don't know if these are appreciated... what do you think? Best regards Christoph > -----Original Message----- > From: Sean Mullan > Sent: Freitag, 24. Mai 2019 14:02 > To: Langer, Christoph ; security-dev dev at openjdk.java.net> > Subject: Re: RFR(S): 8224729: > sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle > forward slash characters in Certificate Issuer Names > > Hi Christoph, > > I don't think this is the right fix. The LDAP URL in the Certificate is > incorrect and the forward slash should be escaped. If we start to make > workarounds in the code to accept certificates that are not properly > encoded, it becomes a slipperly slope. I base my rationale on the > following RFCs: > > 1. https://tools.ietf.org/html/rfc5280#section-4.2.1.13 > > When the LDAP URI scheme [RFC4516] is > used, the URI MUST include a field containing the distinguished > name of the entry holding the CRL, MUST include a single > that contains an appropriate attribute description for the attribute > that holds the CRL [RFC4523], and SHOULD include a > (e.g., certificateRevocationList;binary>). > > 2. https://tools.ietf.org/html/rfc4516#section-2 > > The is an LDAP Distinguished Name using the string format > described in [RFC4514]. It identifies the base object of the LDAP > search or the target of a non-search operation. > > 3. https://tools.ietf.org/html/rfc4514#section-2.4 > > If that UTF-8-encoded Unicode > string does not have any of the following characters that need > escaping, then that string can be used as the string representation > of the value. > > ... > > - one of the characters '"', '+', ',', ';', '<', '>', or '\' > (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, > respectively); > > So, I think the proper way to handle this is to contact the CA and > inform that the certificate does not comply with RFC 5280 and should be > re-issued. Rajan or I can take care of that and get back to you. For > now, if this is blocking your testing, I suggest putting the test on the > ProblemList. > > Thanks, > Sean > > On 5/24/19 5:11 AM, Langer, Christoph wrote: > > Hi, > > > > please review this fix for an issue that I've discovered when working > > with test > > > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va. > > > > It fails when the test tries to do the CRL verification of the > > certificate. It has issues in the LDAP implementation because of the > > certificate's name "cn=Actalis Authentication Root CA,o=Actalis > > S.p.A./03358520967,c=IT". The name contains a forward slash which is at > > the same time a compound separator in javax.naming/LDAP. So it needs > > some escaping. > > > > I also cleaned up some debugging code and removed/commented out > unused > > fields and methods. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.0/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224729 > > > > Thanks > > > > Christoph > > From sean.mullan at oracle.com Fri May 24 13:43:05 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 May 2019 09:43:05 -0400 Subject: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification In-Reply-To: References: Message-ID: On 5/24/19 4:00 AM, Langer, Christoph wrote: > Hi, > > please review the problem listing of > > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java > and > > security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java > > until JDK-8202651 and JDK-8215546 are resolved. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224727 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224727.0/ I would prefer to just problem list ActalisCA.java. Rajan has a fix for ComodoCA which he posted the other day as part of https://bugs.openjdk.java.net/browse/JDK-8202651, so if he just splits that off into a separate bug then he can push that fix. Can you coordinate with Rajan the best way to handle this? There seems to be overlap in these various bugs for the failures in Actalis, Buypass and Comodo - I think we should clean this up so that there is one unique bug per failing test. --Sean From xuelei.fan at oracle.com Fri May 24 13:44:55 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 May 2019 06:44:55 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: jdk.tls.server.sessionTicketTimeout: Could we use the SSLSessionContext.getSessionTimeout() value for ticket session timeout? jdk.tls.server.statelessKeyTimeout: We may extend to use external key and key rotation to improve scalability. I was wondering, if it is possible to remove the property by using implicit key usage limit (as TLS 1.3 key usage limit, uncustomizable) rather than timeout? Thanks, Xuelei On 5/21/2019 4:24 PM, Anthony Scarpino wrote: > Hi All, > > Please review the CSR for the stateless Server Side > https://bugs.openjdk.java.net/browse/JDK-8223922 > > thanks > > Tony From sean.mullan at oracle.com Fri May 24 13:46:53 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 May 2019 09:46:53 -0400 Subject: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names In-Reply-To: References: <5c050f33-7627-86ca-496e-7288602f1be0@oracle.com> Message-ID: <9a45b3dd-8ffe-f11d-000e-a1a36ae20fa3@oracle.com> On 5/24/19 8:48 AM, Langer, Christoph wrote: > Hi Sean, > > ok, I see, you're fully correct. So I hereby withdraw my fix proposal. > > As for the exclusion of the test: I have requested it this morning anyway:https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019966.html. So I would assume that you ask Actalis to reissue the certificates anyway and then eventually resolve 8202651 with a good certificate? Yes, although I think we should have one bug per failing test. > As for Bug JDK-8224729: Shall I just close the ticket, dropping a comment about the ignorance of the author or shall I repurpose it to do the other cleanups in LDAPCertStoreImpl.java that I suggested? Don't know if these are appreciated... what do you think? Either way, the debugging does seem useful so either open a new bug or change the description of the existing bug. Please post an updated webrev w/o the ldap escaping change too. --Sean From xuelei.fan at oracle.com Fri May 24 15:51:43 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 May 2019 08:51:43 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> Message-ID: <36330acc-81f6-bc32-6b28-ddc98f77c126@oracle.com> SSLSessionContext.java ---------------------- As comment in the CSR review thread, I may not define the jdk.tls.server.sessionTicketTimeout property, and use one session timeout (SSLSessionContext.getSessionTimeout()) instead. The ticket timeout may be not necessary, read more please. SessionTicketExtension.java --------------------------- As comment in the CSR review thread, I may not define the key timeout. Instead, I may use key usage limit. As it is stateless server, I may not use the stateless session timeout as well, for less states. The key rotation scheme might be able to take place of timeout. For client side, the session context session timeout and management may be sufficient for the client side cache cleanup. StatelessKey.gcmspec: If I read it right, the same key and iv are used for every ticket encryption. This behavior is vulnerable. The IV should be unique for each encryption. I would like to avoid to create thread in the fundamental API implementation if possible. As the thread (KeyState.run()) is for invalid key cleanup only, the cleanup can be moved to the get methods. For each StatelessKey, one thread is created. I was wondering if there are any chance that there are multiple threads to manage the stateless keys, and potential memory leak? Anyway, I will try to avoid to use internal thread. I may use a key rotation scheme similar to cookie manager (use two keys, one for legacy and one for the current key, see HelloCookieManager.java). If the key is invalid, an exception will be thrown and then fail back to full handshake. Exception thrown and catch are expensive, I may not exception for the failback to full handshake. Let's discuss these issues firstly before we moving on with more code review. Hope it helps. Thanks, Xuelei On 5/21/2019 5:35 PM, Anthony Scarpino wrote: > Hi all, > > I?ve updated in-place some recent changes due to some additional testing > > Tony > >> On May 16, 2019, at 2:30 PM, Anthony Scarpino wrote: >> >> I'm asking for a review of this rather large change to add support stateless tickets in the TLS 1.3 5077 RFC. >> https://bugs.openjdk.java.net/browse/JDK-8211018 >> >> http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 >> >> thanks >> >> Tony > From rajan.halade at oracle.com Fri May 24 16:51:53 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 24 May 2019 09:51:53 -0700 Subject: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification In-Reply-To: References: Message-ID: <36b47958-01e3-45a9-461d-a538fe22b1d3@oracle.com> I have pushed fix for ComodoCA with JDK-8202651 and have filed JDK-8224768 to address ActalisCA issue. You can problem list ActalisCA for now with JDK-8224727. Thanks, Rajan On 5/24/19 6:43 AM, Sean Mullan wrote: > On 5/24/19 4:00 AM, Langer, Christoph wrote: >> Hi, >> >> please review the problem listing of >> >> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java >> and >> >> security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java >> >> >> until JDK-8202651 and JDK-8215546 are resolved. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224727 >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224727.0/ > > I would prefer to just problem list ActalisCA.java. Rajan has a fix > for ComodoCA which he posted the other day as part of > https://bugs.openjdk.java.net/browse/JDK-8202651, so if he just splits > that off into a separate bug then he can push that fix. Can you > coordinate with Rajan the best way to handle this? > > There seems to be overlap in these various bugs for the failures in > Actalis, Buypass and Comodo - I think we should clean this up so that > there is one unique bug per failing test. > > --Sean From anthony.scarpino at oracle.com Fri May 24 18:52:28 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 24 May 2019 11:52:28 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: On 5/24/19 6:44 AM, Xuelei Fan wrote: > jdk.tls.server.sessionTicketTimeout: > Could we use the SSLSessionContext.getSessionTimeout() value for ticket > session timeout? > The property is meant to complement the API. getSessionTimeout() will return the value of the property if it is set. I think this is the best choice because we can't assume the servers allow a user to change the timeout. For example in testing, if we don't have a property, the test has to be hardcoded for particular times. I thought using the same timeout for both the cache and the stateless sessions made the most sense > jdk.tls.server.statelessKeyTimeout: > We may extend to use external key and key rotation to improve > scalability.? I was wondering, if it is possible to remove the property > by using implicit key usage limit (as TLS 1.3 key usage limit, > uncustomizable) rather than timeout? --- cut-n-paste from the other thread--- The spec says the keys need to be rotated regularly. Of course "regularly" is up for interpretation. If a usage limit is implemented and the server is not frequently used, it's possible to have the same key used for the entire span of the session timeout. I don't feel that is often enough. ----- > > Thanks, > Xuelei > > > On 5/21/2019 4:24 PM, Anthony Scarpino wrote: >> Hi All, >> >> Please review the CSR for the stateless Server Side >> https://bugs.openjdk.java.net/browse/JDK-8223922 >> >> thanks >> >> Tony From anthony.scarpino at oracle.com Fri May 24 18:52:51 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 24 May 2019 11:52:51 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <36330acc-81f6-bc32-6b28-ddc98f77c126@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> <36330acc-81f6-bc32-6b28-ddc98f77c126@oracle.com> Message-ID: <527993e3-462b-9a28-f723-d46ef9af0e30@oracle.com> On 5/24/19 8:51 AM, Xuelei Fan wrote: > SSLSessionContext.java > ---------------------- > As comment in the CSR review thread, I may not define the > jdk.tls.server.sessionTicketTimeout property, and use one session > timeout (SSLSessionContext.getSessionTimeout()) instead. > > The ticket timeout may be not necessary, read more please. > > SessionTicketExtension.java > --------------------------- > As comment in the CSR review thread, I may not define the key timeout. > Instead, I may use key usage limit.? As it is stateless server, I may > not use the stateless session timeout as well, for less states.? The key > rotation scheme might be able to take place of timeout.? For client > side, the session context session timeout and management may be > sufficient for the client side cache cleanup. The spec says the keys need to be rotated regularly. Of course "regularly" is up for interpretation. If a usage limit is implemented and the server is not frequently used, it's possible to have the same key used for the entire span of the session timeout. I don't feel that is often enough. > > StatelessKey.gcmspec: > If I read it right, the same key and iv are used for every ticket > encryption.? This behavior is vulnerable.? The IV should be unique for > each encryption. GCM as a whole was probably the wrong choice > > I would like to avoid to create thread in the fundamental API > implementation if possible.? As the thread (KeyState.run()) is for > invalid key cleanup only, the cleanup can be moved to the get methods. How is this thread in the API? It is only started when the key is generated and not by a API call and it's the internal parts of the implementation. > > For each StatelessKey, one thread is created.? I was wondering if there > are any chance that there are multiple threads to manage the stateless > keys, and potential memory leak? Every time a new session key. Depending on the property the default is once an hour. It's possible multiple threads can be used if the timing is just right, but that only mean it runs through the list a few times. Hardly a performance issue. Each key is put in the hashmap, so there is no memory leak. Maybe I can trim it down to a static thread that runs when needed, that would eliminate the multiple threads, but maybe add more locks. > > Anyway, I will try to avoid to use internal thread.? I may use a key > rotation scheme similar to cookie manager (use two keys, one for legacy > and one for the current key, see HelloCookieManager.java). The thread is one piece for clean up, if I remove it from the thread, I will need to be put into the main code path. The keys have a longer life, the defaults are 1 hour and can last up to 24hrs. Those can be changed with the properties in a way that would require more keys to be stored. So rotating keys will involve some sort of Map or storage object. HelloCookieManager just needs to remember the previous secret and for a short period of time as the response from the client could be only a few seconds. As for the for the lock mechanism around the rotation. I don't see much difference between you using the ReentrantLock vs the synchronized block I have. I'm trying to minimize the amount of time in the lock generating the key. I'm not so concerned about a few extra keys being generated. Putting in more locks just means more chances for the main code path getting stopped. I don't see the significants to this other than being personal coding styles. > > If the key is invalid, an exception will be thrown and then fail back to > full handshake.? Exception thrown and catch are expensive, I may not > exception for the failback to full handshake. If there is an exception the full handshake is going to be more expensive than the exception. I could probably code away the exception. > > Let's discuss these issues firstly before we moving on with more code > review. > > Hope it helps. > > Thanks, > Xuelei > > > On 5/21/2019 5:35 PM, Anthony Scarpino wrote: >> Hi all, >> >> I?ve updated in-place some recent changes due to some additional testing >> >> Tony >> >>> On May 16, 2019, at 2:30 PM, Anthony Scarpino >>> wrote: >>> >>> I'm asking for a review of this rather large change to add support >>> stateless tickets in the TLS 1.3 5077 RFC. >>> https://bugs.openjdk.java.net/browse/JDK-8211018 >>> >>> http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 >>> >>> thanks >>> >>> Tony >> From mbalao at redhat.com Fri May 24 19:16:07 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 24 May 2019 16:16:07 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> Message-ID: <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> Hi Xuelei, Thanks for your reply. I think I now know what you mean. Here it's a new benchmark: http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_manual_v0.tar.gz In this new benchmark we measure the following sequence: long startTime = System.currentTimeMillis(); ctx = SSLContext.getInstance("TLSv1.2"); long stopTime = System.currentTimeMillis(); The SSLContext class gets initialized per run. We test both NON_FIPS (SunJCE) and FIPS (SunPKCS11) providers. Results summary (100 runs per case): FIPS_with_8223482_webrev01.txt average: 314.33 ms NON_FIPS_with_8223482_webrev01.txt average: 817.91 ms FIPS_without_8223482_webrev01.txt average: 358.42 ms NON_FIPS_without_8223482_webrev01.txt average: 771.34 ms So, yes, it seems that there is a ~6% startup impact on SunJCE. These numbers are not accurate though because of using System.currentTimeMillis to measure, they provide just a rough idea. Kind regards, Martin.- From sean.mullan at oracle.com Fri May 24 19:31:18 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 May 2019 15:31:18 -0400 Subject: RFR: 8224767: Add String constants for Canonical XML 1.1 URIs Message-ID: Please review this fix to add two new String constants to the XML Signature API for the Canonical XML 1.1 Algorithm URIs: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8224767/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8224773 Thanks, Sean From xuelei.fan at oracle.com Fri May 24 20:17:14 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 May 2019 13:17:14 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> Message-ID: The benchmark result looks good to me. I still have a few questions. Read inlines, please. On 5/24/2019 12:16 PM, Martin Balao wrote: > Hi Xuelei, > > Thanks for your reply. > > I think I now know what you mean. > > Here it's a new benchmark: > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_manual_v0.tar.gz > > In this new benchmark we measure the following sequence: > > long startTime = System.currentTimeMillis(); > ctx = SSLContext.getInstance("TLSv1.2"); > long stopTime = System.currentTimeMillis(); > > The SSLContext class gets initialized per run. > > We test both NON_FIPS (SunJCE) and FIPS (SunPKCS11) providers. > > Results summary (100 runs per case): > > FIPS_with_8223482_webrev01.txt average: 314.33 ms > NON_FIPS_with_8223482_webrev01.txt average: 817.91 ms > If I understand correctly, you run the test with the patch of webrev01? http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/ > FIPS_without_8223482_webrev01.txt average: 358.42 ms > NON_FIPS_without_8223482_webrev01.txt average: 771.34 ms > If I understand correctly, you run the test with the pacth of webrev00? http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ From the above numbers, the FIPS_with_8223482_webrev01 is better than FIPS_without_8223482_webrev01, but NON_FIPS_with_8223482_webrev01 is worse than NON_FIPS_without_8223482_webrev01. It is a little bit strange to me. Did you have the numbers for the latest JDK build, without any patch? > So, yes, it seems that there is a ~6% startup impact on SunJCE. These > numbers are not accurate though because of using > System.currentTimeMillis to measure, they provide just a rough idea. > A rough idea is okay. Maybe, you can use nanoseconds. But it is not really necessary. Thanks, Xuelei From mbalao at redhat.com Fri May 24 20:43:55 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 24 May 2019 17:43:55 -0300 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> Message-ID: <03a0db21-865d-0ad4-b2b8-32d42ce2c38c@redhat.com> Hi Max, Thanks for your review. 1) src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java: * When NT-ENTERPRISE names are used, a "@" char can be part of the name and we should not interpret it as a realm separator. If we don't escape, we may be missing part of the name when building a new PrincipalName. The exact place where this happens is in PrincipalName.parseName function. 2) src/java.security.jgss/share/classes/sun/security/krb5/internal/EncKDCRepPart.java: * My understanding is that there won't be confusion between caddr and padata because the tag for each one is different (0x0B and 0x0C). When the tag does not match, "parse" functions return null and execution continues. See for example HostAddress.parse or PAData.parseSequence methods. All the previous "optionals" work the same way. 3) src/java.security.jgss/share/classes/sun/security/krb5/internal/EncKDCRepPart.java: * This was a trivial renaming because I found more clear to have "out" for the final output and "temp / bytes" for intermediate outputs. I can revert this change and use a different name scheme that does not modify the original "bytes" variable if you wish. 4) src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCRep.java: * msgType being public is no longer needed (it was needed in a previous changeset). I'll fix it for Webrev.03. 5) KrbTgsReqBuilder * Yes, probably. 6) src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java * Perhaps "serviceCredsSingle" is not the best name. What I meant with single was in respect to cross-realm referrals (which are not handled in that method). getTGTforRealm won't be called when we get a cross-realm referral because there will be a match between the sname realm and the realm we will ask for a ticket (both elements are part of the cross-realm TGT). * In regards to the check being possibly false, you are probably correct. Let me do some checking and I'll fix it for Webrev.03. * In regards to cross-realm referrals for S4U2self and S4U2proxy, this will be my next step when proposing a patch for resource-based constrained delegation. * "PrincipalName cSname = (PrincipalName) sname.clone();" Right, I'll fix this for Webrev.03. Kind regards, Martin.- From mbalao at redhat.com Fri May 24 20:53:53 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 24 May 2019 17:53:53 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> Message-ID: Hi Xuelei, On 5/24/19 5:17 PM, Xuelei Fan wrote: > If I understand correctly, you run the test with the patch of webrev01? > ?? http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/ > Yes, this is correct. > >> FIPS_without_8223482_webrev01.txt average: 358.42 ms >> NON_FIPS_without_8223482_webrev01.txt average: 771.34 ms >> > If I understand correctly, you run the test with the pacth of webrev00? > ?? http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ No, this is not correct. "without_8223482" means no patch at all, just the base line JDK (at revision fb0cfce19262, 2019-05-23). In my opinion, it makes no sense to continue measuring Webrev.00 because it has a considerable impact as shown by previous benchmarks. > > From the above numbers, the FIPS_with_8223482_webrev01 is better than > FIPS_without_8223482_webrev01, but NON_FIPS_with_8223482_webrev01 is > worse than NON_FIPS_without_8223482_webrev01.? It is a little bit > strange to me. Yes, looks strange that FIPS with patch is better than without patch. However, we need to consider that the difference is not a big one and the margin of error we have. If you ask me, I'd say they are roughly the same. > > Did you have the numbers for the latest JDK build, without any patch? As I said, "without" means the latest JDK without any patch. Kind regards, Martin.- From sean.mullan at oracle.com Fri May 24 20:56:12 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 May 2019 16:56:12 -0400 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: References: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com> Message-ID: On 5/23/19 8:14 PM, Arthur Eubanks wrote: > Ping on a review from security-dev. > > On Fri, May 17, 2019 at 9:53 AM Chris Hegarty > wrote: > > Arthur, > >> On 17 May 2019, at 17:50, Arthur Eubanks > > wrote: >> >> Looks good. >> >> Trivially, maybe amend the comment to be more explicit >> >> ? ?86? ? ? ?// SOCKS V4 ( requires IPv4 ) >> >> -Chris. >> >> Done >> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ >> >> I will wait for another review from security-dev. > > You have my Review ( conditional on a Reviewer for the test in the > security area ). It seems ok but given that this area is a bit unpredictable I would recommend you be available/online to monitor CI results after you push the fix in case something breaks. --Sean From aeubanks at google.com Fri May 24 20:57:44 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Fri, 24 May 2019 13:57:44 -0700 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: References: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com> Message-ID: On Fri, May 24, 2019 at 1:56 PM Sean Mullan wrote: > On 5/23/19 8:14 PM, Arthur Eubanks wrote: > > Ping on a review from security-dev. > > > > On Fri, May 17, 2019 at 9:53 AM Chris Hegarty > > wrote: > > > > Arthur, > > > >> On 17 May 2019, at 17:50, Arthur Eubanks >> > wrote: > >> > >> Looks good. > >> > >> Trivially, maybe amend the comment to be more explicit > >> > >> 86 // SOCKS V4 ( requires IPv4 ) > >> > >> -Chris. > >> > >> Done > >> http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ > >> > >> I will wait for another review from security-dev. > > > > You have my Review ( conditional on a Reviewer for the test in the > > security area ). > > It seems ok but given that this area is a bit unpredictable I would > recommend you be available/online to monitor CI results after you push > the fix in case something breaks. > I will submit next week then. Thanks for the review. > > --Sean > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 24 20:58:11 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 May 2019 16:58:11 -0400 Subject: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6 In-Reply-To: References: <80d7fd4d-a266-1767-19e2-333f6097770a@oracle.com> <74A2AAEE-E43A-4CB9-B1E1-150CB478179E@oracle.com> Message-ID: <4cb52762-5d4c-dfb0-fc60-ecf88cdca0b0@oracle.com> On 5/24/19 4:56 PM, Sean Mullan wrote: > On 5/23/19 8:14 PM, Arthur Eubanks wrote: >> Ping on a review from security-dev. >> >> On Fri, May 17, 2019 at 9:53 AM Chris Hegarty >> > wrote: >> >> ??? Arthur, >> >>> ??? On 17 May 2019, at 17:50, Arthur Eubanks >> ??? > wrote: >>> >>> ??????? Looks good. >>> >>> ??????? Trivially, maybe amend the comment to be more explicit >>> >>> ??????? ? ?86? ? ? ?// SOCKS V4 ( requires IPv4 ) >>> >>> ??????? -Chris. >>> >>> ??? Done >>> ??? http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ >>> >>> ??? I will wait for another review from security-dev. >> >> ??? You have my Review ( conditional on a Reviewer for the test in the >> ??? security area ). > > It seems ok but given that this area is a bit unpredictable I would > recommend you be available/online to monitor CI results after you push > the fix in case something breaks. I should add that I would recommend not pushing this until Tuesday after the US Memorial Day weekend as many folks probably won't be online. --Sean From valerie.peng at oracle.com Fri May 24 22:37:29 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 24 May 2019 15:37:29 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> Message-ID: <06fc7210-c090-d82c-3462-0f50fa8afc29@oracle.com> Hi Sean, Thanks much for the suggestion. I have added the info on newly supported algorithms to both the CSR and the bug record. Please let me know if you have more comments. All, RFEs need to be integrated by 6/13. Can someone help reviewing this soon? Mach5 run is clean. I up'ed the version of webrev to webrev.01 due to the additional support for RSASSA-PSS signatures. RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ Thanks, Valerie On 5/22/2019 7:55 AM, Sean Mullan wrote: > On 5/21/19 7:19 PM, Valerie Peng wrote: >> >> I thought we always file CSR when updating the version of external >> standard, e.g. documenting the import aspect of JDK. > > Good point though I think that was primarily based on whether the > external standard was referenced in the javadocs of the standard APIs > or influenced the behavior of existing APIs in some way. I don't think > PKCS#11 is referenced from any of our standard APIs, but since this > new version does add support for additional crypto algorithms via the > standard APIs that weren't previously available, that sounds like a > good enough reason for filing the CSR. > > I would recommend adding some additional details to the CSR to list > what new features/algorithms PKCS#11 v2.40 provides and which standard > APIs those features are applicable to. It would also be helpful to add > similar details to the main issue and the release note as there aren't > many details about what features are in the new version. > > Thanks, > Sean > >> >> I'd love to close/withdraw the CSR if it's not needed. >> >> Thanks, >> Valerie >> On 5/20/2019 12:11 PM, Sean Mullan wrote: >>> On 5/17/19 3:56 PM, Valerie Peng wrote: >>>> >>>> Thanks Martin for helping me troubleshoot NSS side, I added PSS >>>> support into PKCS11 provider and added PSS-specific regression >>>> tests. Please find webrev updated as below: >>>> >>>> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>>> >>>> Can someone help review the CSR first as the approval may take a >>>> week or so. >>> >>> I am curious why a CSR is needed? This seems to be strictly an >>> implementation change with no compatibility effects. >>> >>> --Sean >>> >>>> >>>> Thanks, >>>> Valerie >>>> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has time to review this? Besides the header files update, I >>>>> added support for AES/GCM/NoPadding support. Ran into some strange >>>>> NSS error with RSASSA-PSS signature mechanism, so I have not >>>>> included the PSS signature impl here. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>>>> >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> From xuelei.fan at oracle.com Fri May 24 22:47:51 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 May 2019 15:47:51 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> Message-ID: <444a8dbe-aafb-ff21-a0de-8c35b7bc4551@oracle.com> Good, I have no further comment for this update. Please go ahead. I think there is a possible improvement by calling Cipher.getInstance(algorithm) only one time for each transformation algorithm. But may not worthy as the duplicated transformation algorithm number is still small. I'm fine if you want to leave it as it is. Thank you so much for your patient, especially for doing the benchmarking. Thanks, Xuelei On 5/24/2019 1:53 PM, Martin Balao wrote: > Hi Xuelei, > > On 5/24/19 5:17 PM, Xuelei Fan wrote: >> If I understand correctly, you run the test with the patch of webrev01? >> ?? http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/ >> > > Yes, this is correct. > >> >>> FIPS_without_8223482_webrev01.txt average: 358.42 ms >>> NON_FIPS_without_8223482_webrev01.txt average: 771.34 ms >>> >> If I understand correctly, you run the test with the pacth of webrev00? >> ?? http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/ > > No, this is not correct. "without_8223482" means no patch at all, just > the base line JDK (at revision fb0cfce19262, 2019-05-23). > > In my opinion, it makes no sense to continue measuring Webrev.00 because > it has a considerable impact as shown by previous benchmarks. > >> >> From the above numbers, the FIPS_with_8223482_webrev01 is better than >> FIPS_without_8223482_webrev01, but NON_FIPS_with_8223482_webrev01 is >> worse than NON_FIPS_without_8223482_webrev01.? It is a little bit >> strange to me. > > Yes, looks strange that FIPS with patch is better than without patch. > However, we need to consider that the difference is not a big one and > the margin of error we have. If you ask me, I'd say they are roughly the > same. > >> >> Did you have the numbers for the latest JDK build, without any patch? > > As I said, "without" means the latest JDK without any patch. > > Kind regards, > Martin.- > From xuelei.fan at oracle.com Fri May 24 22:50:05 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 May 2019 15:50:05 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <527993e3-462b-9a28-f723-d46ef9af0e30@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> <36330acc-81f6-bc32-6b28-ddc98f77c126@oracle.com> <527993e3-462b-9a28-f723-d46ef9af0e30@oracle.com> Message-ID: <8526c22a-29f7-fb8d-b465-e981e338c254@oracle.com> I meant to avoid to use threads in the implementation of fundamental APIs. Xuelei On 5/24/2019 11:52 AM, Anthony Scarpino wrote: >> I would like to avoid to create thread in the fundamental API >> implementation if possible.? As the thread (KeyState.run()) is for >> invalid key cleanup only, the cleanup can be moved to the get methods. > > How is this thread in the API?? It is only started when the key is > generated and not by a API call and it's the internal parts of the > implementation. From jamil.j.nimeh at oracle.com Fri May 24 22:51:08 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 24 May 2019 15:51:08 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working Message-ID: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Hello all, happy Friday! Please review the following CSR and code review.? This makes updates to the SunJCE implementation of PBES2-based AlgorithmParameters.? Many of the details are in the CSR (see the link below).? But a short list of the updates: * Add DER Encode/Decode support for the following OIDS from RFC 8018: o PRFs: HmacSHA512/224, HmacSHA512/256 o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 * Enforce init-time type consistency between AlgorithmParameterSpec objects and the algorithms they are used with (i.e. No using RC5ParameterSpec with AES-128-CBC. * Enforce sanity checks on AlgorithmParameterSpec objects used to init (e.g. IV length checks, integer range checks, etc.) * Fixed a bug where explicit DER decoding of the optional key length field in PBKDF2-params would cause the PRF to be forced to HmacSHA1 even if the DER indicated otherwise * Allow incoming DER encoded AlgorithmIdentifier structures to honor the OPTIONAL qualifier on the parameters field for both PRFs and Encryption Schemes. * If a null encryption scheme AlgorithmParameterSpec is provided during init time, omit the PBES2-params.encryptionScheme's parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 More details are in the CSR. CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Fri May 24 23:26:58 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 24 May 2019 16:26:58 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <8526c22a-29f7-fb8d-b465-e981e338c254@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> <36330acc-81f6-bc32-6b28-ddc98f77c126@oracle.com> <527993e3-462b-9a28-f723-d46ef9af0e30@oracle.com> <8526c22a-29f7-fb8d-b465-e981e338c254@oracle.com> Message-ID: Are you saying you don?t like any threads in the implementation? I don?t understand when you say ?fundamental API? as there is. I way to call the thread via the public API Tony > On May 24, 2019, at 3:50 PM, Xuelei Fan wrote: > > I meant to avoid to use threads in the implementation of fundamental APIs. > > Xuelei > > On 5/24/2019 11:52 AM, Anthony Scarpino wrote: >>> I would like to avoid to create thread in the fundamental API implementation if possible. As the thread (KeyState.run()) is for invalid key cleanup only, the cleanup can be moved to the get methods. >> How is this thread in the API? It is only started when the key is generated and not by a API call and it's the internal parts of the implementation. From Xuelei.Fan at Oracle.Com Fri May 24 23:39:06 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 24 May 2019 16:39:06 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> <17E322B2-761A-4B64-BEA2-011A223C2CD7@oracle.com> <36330acc-81f6-bc32-6b28-ddc98f77c126@oracle.com> <527993e3-462b-9a28-f723-d46ef9af0e30@oracle.com> <8526c22a-29f7-fb8d-b465-e981e338c254@oracle.com> Message-ID: > On May 24, 2019, at 4:26 PM, Anthony Scarpino wrote: > > Are you saying you don?t like any threads in the implementation? Right. > I don?t understand when you say ?fundamental API? as there is. It?s a very personal preference of mine. Applications may not want to use threads. I don?t know so I would avoid to use threads internally in JSSE code unless there is no other options. Xuelei From weijun.wang at oracle.com Sat May 25 00:23:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 25 May 2019 08:23:51 +0800 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <03a0db21-865d-0ad4-b2b8-32d42ce2c38c@redhat.com> References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> <03a0db21-865d-0ad4-b2b8-32d42ce2c38c@redhat.com> Message-ID: > On May 25, 2019, at 4:43 AM, Martin Balao wrote: > > Hi Max, > > Thanks for your review. > > 1) > src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java: > > * When NT-ENTERPRISE names are used, a "@" char can be part of the name > and we should not interpret it as a realm separator. If we don't escape, > we may be missing part of the name when building a new PrincipalName. > The exact place where this happens is in PrincipalName.parseName function. Is the character already escaped in the oldName? How about just changing new PrincipalName(oldName.getNameString().replace..., newRealm) to new PrincipalName(oldName.getNameStrings(), newRealm) > > 2) > src/java.security.jgss/share/classes/sun/security/krb5/internal/EncKDCRepPart.java: > > * My understanding is that there won't be confusion between caddr and > padata because the tag for each one is different (0x0B and 0x0C). When > the tag does not match, "parse" functions return null and execution > continues. See for example HostAddress.parse or PAData.parseSequence > methods. All the previous "optionals" work the same way. Oops, my wrong. I thought getData() would consume some bytes but actually it just "peekByte". > > 3) > src/java.security.jgss/share/classes/sun/security/krb5/internal/EncKDCRepPart.java: > > * This was a trivial renaming because I found more clear to have "out" > for the final output and "temp / bytes" for intermediate outputs. I can > revert this change and use a different name scheme that does not modify > the original "bytes" variable if you wish. Not really. Keep your change. > > 4) > src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCRep.java: > > * msgType being public is no longer needed (it was needed in a previous > changeset). I'll fix it for Webrev.03. > > 5) KrbTgsReqBuilder > > * Yes, probably. > > 6) > src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java > > * Perhaps "serviceCredsSingle" is not the best name. What I meant with > single was in respect to cross-realm referrals (which are not handled in > that method). getTGTforRealm won't be called when we get a cross-realm > referral because there will be a match between the sname realm and the > realm we will ask for a ticket (both elements are part of the > cross-realm TGT). > > * In regards to the check being possibly false, you are probably > correct. Let me do some checking and I'll fix it for Webrev.03. I was just thinking serviceCredsSingle() is called everywhere and for each one I would need to find out what the result of those "if" checks (if same realm, if krbtgt) are. It would be clearer to me that for some calls the request is really single. Maybe you can add some comments. > > * In regards to cross-realm referrals for S4U2self and S4U2proxy, this > will be my next step when proposing a patch for resource-based > constrained delegation. Great. It is also called by getTGTforRealm(). Is this for RFC 6806 "9. Cross-Realm Routing"? Thanks, Max > > * "PrincipalName cSname = (PrincipalName) sname.clone();" Right, I'll > fix this for Webrev.03. > > Kind regards, > Martin.- > From weijun.wang at oracle.com Sat May 25 00:37:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 25 May 2019 08:37:51 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> Message-ID: <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> The CSR is approved. Are you OK with the schema definition referencing "ECParametersType" but not defining it. If yes, I'll push the change. Thanks, Nax > On May 14, 2019, at 8:50 AM, Weijun Wang wrote: > > > >> On May 13, 2019, at 10:51 PM, Sean Mullan wrote: >> >> On 5/10/19 8:07 PM, Weijun Wang wrote: >>>> On May 11, 2019, at 4:44 AM, Sean Mullan wrote: >>>> >>>> On 5/10/19 5:04 AM, Weijun Wang wrote: >>>>> Please take a review at the CSR at >>>>> https://bugs.openjdk.java.net/browse/JDK-8223682 > > Updated with @since 13 and no more @implNote. > > Thanks, > Max > >>>> >>>> Add an "@since 13" to the new constant. >>>> >>>>> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >>>>> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. >>>> >>>> I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? >>> Maybe a little complicated? >>> https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 >> >> Yes, perhaps, or more likely because it is optional to support ECParameters. >> >> Section 4.5.2.3 of the XML Signature Recommendation says: >> >> "Conformant applications must support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7." >> >> --Sean >> >>> --Max >>>> >>>> --Sean >>>> >>>>> The code change is exactly the same as the specification, so no webrev. >>>>> Thanks, >>>>> Max > From christoph.langer at sap.com Sat May 25 05:50:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 25 May 2019 05:50:28 +0000 Subject: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification In-Reply-To: <36b47958-01e3-45a9-461d-a538fe22b1d3@oracle.com> References: <36b47958-01e3-45a9-461d-a538fe22b1d3@oracle.com> Message-ID: Hi Rajan, thanks for this. Problem list update would be then: http://cr.openjdk.java.net/~clanger/webrevs/8224727.1/ Please review. Thanks Christoph > -----Original Message----- > From: Rajan Halade > Sent: Freitag, 24. Mai 2019 18:52 > To: Langer, Christoph > Cc: Sean Mullan ; security-dev dev at openjdk.java.net> > Subject: Re: RFR(S): 8224727: Problem list 2 tests in > security/infra/java/security/cert/CertPathValidator/certification > > I have pushed fix for ComodoCA with JDK-8202651 and have filed > JDK-8224768 to address ActalisCA issue. You can problem list ActalisCA > for now with JDK-8224727. > > Thanks, > Rajan > > On 5/24/19 6:43 AM, Sean Mullan wrote: > > On 5/24/19 4:00 AM, Langer, Christoph wrote: > >> Hi, > >> > >> please review the problem listing of > >> > >> > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va > >> and > >> > >> > security/infra/java/security/cert/CertPathValidator/certification/ComodoCA. > java > >> > >> > >> until JDK-8202651 and JDK-8215546 are resolved. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224727 > >> > >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224727.0/ > > > > I would prefer to just problem list ActalisCA.java. Rajan has a fix > > for ComodoCA which he posted the other day as part of > > https://bugs.openjdk.java.net/browse/JDK-8202651, so if he just splits > > that off into a separate bug then he can push that fix. Can you > > coordinate with Rajan the best way to handle this? > > > > There seems to be overlap in these various bugs for the failures in > > Actalis, Buypass and Comodo - I think we should clean this up so that > > there is one unique bug per failing test. > > > > --Sean From christoph.langer at sap.com Sat May 25 06:00:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 25 May 2019 06:00:52 +0000 Subject: RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names In-Reply-To: <9a45b3dd-8ffe-f11d-000e-a1a36ae20fa3@oracle.com> References: <5c050f33-7627-86ca-496e-7288602f1be0@oracle.com> <9a45b3dd-8ffe-f11d-000e-a1a36ae20fa3@oracle.com> Message-ID: > > As for Bug JDK-8224729: Shall I just close the ticket, dropping a comment > about the ignorance of the author or shall I repurpose it to do the other > cleanups in LDAPCertStoreImpl.java that I suggested? Don't know if these > are appreciated... what do you think? > > Either way, the debugging does seem useful so either open a new bug or > change the description of the existing bug. Please post an updated > webrev w/o the ldap escaping change too. Ok, will do and start a new review thread. Thanks Christoph From rajan.halade at oracle.com Sat May 25 08:45:23 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Sat, 25 May 2019 01:45:23 -0700 Subject: RFR(S): 8224727: Problem list 2 tests in security/infra/java/security/cert/CertPathValidator/certification In-Reply-To: References: <36b47958-01e3-45a9-461d-a538fe22b1d3@oracle.com> Message-ID: Looks good, thanks! - Rajan On 5/24/19 10:50 PM, Langer, Christoph wrote: > Hi Rajan, > > thanks for this. Problem list update would be then: > http://cr.openjdk.java.net/~clanger/webrevs/8224727.1/ > > Please review. > > Thanks > Christoph > > >> -----Original Message----- >> From: Rajan Halade >> Sent: Freitag, 24. Mai 2019 18:52 >> To: Langer, Christoph >> Cc: Sean Mullan ; security-dev > dev at openjdk.java.net> >> Subject: Re: RFR(S): 8224727: Problem list 2 tests in >> security/infra/java/security/cert/CertPathValidator/certification >> >> I have pushed fix for ComodoCA with JDK-8202651 and have filed >> JDK-8224768 to address ActalisCA issue. You can problem list ActalisCA >> for now with JDK-8224727. >> >> Thanks, >> Rajan >> >> On 5/24/19 6:43 AM, Sean Mullan wrote: >>> On 5/24/19 4:00 AM, Langer, Christoph wrote: >>>> Hi, >>>> >>>> please review the problem listing of >>>> >>>> >> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja >> va >>>> and >>>> >>>> >> security/infra/java/security/cert/CertPathValidator/certification/ComodoCA. >> java >>>> >>>> until JDK-8202651 and JDK-8215546 are resolved. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224727 >>>> >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224727.0/ >>> I would prefer to just problem list ActalisCA.java. Rajan has a fix >>> for ComodoCA which he posted the other day as part of >>> https://bugs.openjdk.java.net/browse/JDK-8202651, so if he just splits >>> that off into a separate bug then he can push that fix. Can you >>> coordinate with Rajan the best way to handle this? >>> >>> There seems to be overlap in these various bugs for the failures in >>> Actalis, Buypass and Comodo - I think we should clean this up so that >>> there is one unique bug per failing test. >>> >>> --Sean From christoph.langer at sap.com Sat May 25 09:51:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 25 May 2019 09:51:30 +0000 Subject: RFR(S): Cleanups in sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java Message-ID: Hi, please review this small cleanup which started off under a different subject [0] but turned out to be the wrong thing to do. Still the cleanup parts seem to be valuable, so requesting a review for that here. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8224729 Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019967.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Mon May 27 00:36:42 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 26 May 2019 17:36:42 -0700 Subject: [13] RFR CSR 8224520: Support X25519 and X448 in TLS In-Reply-To: References: <8a831266-3c1e-d00d-e59a-1ee2269784be@oracle.com> Message-ID: I've made a few other modifications based on feedback, and have finalized. Cheers, Brad On 5/21/2019 2:45 PM, Bradford Wetmore wrote: > I've updated with the proposed ordered list of groups. > > Brad > > > On 5/21/2019 1:39 PM, Xuelei Fan wrote: >> Hi Brad, >> >> Would like add a note about the preference order of x25519/x448? >> >> Thanks, >> Xuelei >> >> On 5/21/2019 1:17 PM, Bradford Wetmore wrote: >>> >>> Please review the following CSR at: >>> >>> ??? https://bugs.openjdk.java.net/browse/JDK-8224520 >>> >>> This adds the x25519/x448 named Elliptic Curves to TLS. >>> >>> Thanks, >>> >>> Brad From mbalao at redhat.com Mon May 27 21:00:13 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 27 May 2019 18:00:13 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <444a8dbe-aafb-ff21-a0de-8c35b7bc4551@oracle.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> <444a8dbe-aafb-ff21-a0de-8c35b7bc4551@oracle.com> Message-ID: <9dff0eec-aaa1-f371-3535-da08af6d8ab1@redhat.com> Hi Xuelei, Thanks to you for raising these concerns and providing your feedback. On 5/24/19 7:47 PM, Xuelei Fan wrote: > Good, I have no further comment for this update.? Please go ahead. > > I think there is a possible improvement by calling > Cipher.getInstance(algorithm) only one time for each transformation > algorithm.? But may not worthy as the duplicated transformation > algorithm number is still small.? I'm fine if you want to leave it as it > is. Yes, I agree on both statements: there can be an improvement there but it won't be significant. Here it's Webrev.02: * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.02/ At Webrev.02, Cipher.getInstance results are cached so we don't need to create instances unnecessary. Benchmarks do not show any significant performance increase nor decrease compared to Webrev.01: Benchmark (testMode) Mode Cnt Score Error Units SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 167.393 ? 35.659 ops/s SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 593.441 ? 110.044 ops/s FIPS_with_8223482_webrev02.txt average: 396.86 NON_FIPS_with_8223482_webrev02.txt average: 888.05 Are you okay to go with Webrev.02? Kind regards, Martin.- From weijun.wang at oracle.com Tue May 28 00:55:22 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 May 2019 08:55:22 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> Message-ID: <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> Hi Everyone, Do you have any new comments? My major concern now is the canonicalization of service/host.dev.example.com to service/host.example.com at DEV.EXAMPLE.COM now. As Michael pointed out, it could well be service/host.example.com at EXAMPLE.COM. My suggestion now is to strip the realm part when InitSecurityContext is called. But when? If always, some information is lost if the realm is provided by the caller. So, how about we add "@WELLKNOWN:ORG.H5L.REFERALS-REALM" when it's a host-based service name? Thanks, Max > On May 5, 2019, at 4:33 PM, Weijun Wang wrote: > > Hi Michael and Nico, > >> >> sspi.cpp: >> * KRB5_TRACE > > If you think a different name is better I'll change it. And then I'd like to revert to my old code that it always print to stderr. I don't have a need to print it to any file. > >> * showTime(): please use a readable format akin to %FT%T > > What is %FT%T? > >> >> * NewContext(): >> ** why don't you just pass the package name as WCHAR pointer? There is >> no clear definition what happens if it is not SPNEGO w/o looking into >> the code > > What I really want to express here is that I am only supporting 2 mechanisms now, and using a WCHAR might lead to an unsupported one. I also don't want to do OID<->string translation a lot. If you are only unsatisfied with the name, is negOrKrb5 better? > >> ** If you log the token size you should also log if SecurityStatus isn't >> positive, just in case > > I didn't use cbMaxMessage. Will remove it. > >> ** new_context minor_status is never written, remove it? > > It was used by the SEC_SUCCESS macro. Now that I won't call QuerySecurityPackageInfo it's useless. Will remove it. > >> >> * get_full_name()!!!: >> ** What is the purpose of this function? It will not work reliably if >> you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN >> HTTP/travel.siemens.com > > It's only used by gss_export and gss_canonicalize. A service must have a realm in the output of these 2 functions. The realm is not used in init_sec_context. > >> ** I don't like the idea using Heimdal-internal identifiers. Shouldn't >> we define JGSS specific ones? At least create a define for. > > Well MIT krb5 is already using it (I see it in the exported byte array) so I think it's fine. I don't want to invent a new one. However I cannot use it now because of the permission check. I would think about supporting realm-less name in ServicePermission. > >> ** your concat fails if USERDNSDOMAIN is empty, you end up ith >> service/instance@ > > That's sad, but I think it should never be empty if the client machine is in a domain and that's what this library wants to support. > >> ** Why do you check for '\\' what can be escaped here? Requires a better >> comment > > I think Nico answered this in full detail. > >> * gss_import_name(): >> ** BOOLEAN isNegotiate isn't really readable code >> ** " value[len] = 0;" rather '\0'? This idiom repeats over and over > > Sometimes it's '\0' and sometimes it could even be L'\0'. I really don't want to make it too precise here. > >> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function > > Yes. > >> ** "if (value[len-1] == '@') {" you should comment this block and >> explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? > > I suspect there will be empty/ignorable realms. > >> ** SPN conversion, why do you replace the '@' with '/' explicitly for >> SSPI? A non-mech specific hostbased service is always neutral with '@' > > I just want to support Kerberos, and I don't want to replace it before calling InitSecContext. > >> >> * gss_canonicalize_name(): something is fishy consider the following case: >> gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to >> receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but >> get_full_name() doesn't do this > > The realm part is a problem because I cannot get the real one. The '@' should not be changed to '/' if name type is not HOSTBASED-SERVICE. > >> * gss_export_name(): probably the same issues as with gss_import_name() >> >> >> * gss_init_sec_context(): >> ** Line 909, wrong case for package name > > The one in PackageList? Fixed. It did work. > >> >> I will try to setup a compile env after the next webrev and see how far >> I get. I have enough cross-realm stuff around here. > > Great. If an app calls canonicalize/export and feed back the result into InitSecContext then there might be a problem. Maybe I should always strip the realm part before calling it? That sound like a part of the information is lost. Or maybe it's really useless for Windows? I know giving a wrong realm will fail. > > Or maybe I should use "WELLKNOWN:ORG.H5L.REFERALS-REALM". I'll do some experiment. > > Thanks, > Max > >> >> Michael > From weijun.wang at oracle.com Tue May 28 01:19:46 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 May 2019 09:19:46 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> References: <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> Message-ID: <3E1D5F44-D375-4502-A387-C5C324C4F640@oracle.com> > On May 28, 2019, at 8:55 AM, Weijun Wang wrote: > > Hi Everyone, > > Do you have any new comments? > > My major concern now is the canonicalization of service/host.dev.example.com to service/host.example.com at DEV.EXAMPLE.COM now. As Michael pointed out, it could well be service/host.example.com at EXAMPLE.COM. > > My suggestion now is to strip the realm part when InitSecurityContext is called. But when? If always, some information is lost if the realm is provided by the caller. So, how about we add "@WELLKNOWN:ORG.H5L.REFERALS-REALM" when it's a host-based service name? Or I can always add the current domain name (env var USERDNSDOMAIN) to a host-based service, and in InitSecurityContext always strip the domain part of it is the current domain name. --Max > > Thanks, > Max > >> On May 5, 2019, at 4:33 PM, Weijun Wang wrote: >> >> Hi Michael and Nico, >> >>> >>> sspi.cpp: >>> * KRB5_TRACE >> >> If you think a different name is better I'll change it. And then I'd like to revert to my old code that it always print to stderr. I don't have a need to print it to any file. >> >>> * showTime(): please use a readable format akin to %FT%T >> >> What is %FT%T? >> >>> >>> * NewContext(): >>> ** why don't you just pass the package name as WCHAR pointer? There is >>> no clear definition what happens if it is not SPNEGO w/o looking into >>> the code >> >> What I really want to express here is that I am only supporting 2 mechanisms now, and using a WCHAR might lead to an unsupported one. I also don't want to do OID<->string translation a lot. If you are only unsatisfied with the name, is negOrKrb5 better? >> >>> ** If you log the token size you should also log if SecurityStatus isn't >>> positive, just in case >> >> I didn't use cbMaxMessage. Will remove it. >> >>> ** new_context minor_status is never written, remove it? >> >> It was used by the SEC_SUCCESS macro. Now that I won't call QuerySecurityPackageInfo it's useless. Will remove it. >> >>> >>> * get_full_name()!!!: >>> ** What is the purpose of this function? It will not work reliably if >>> you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN >>> HTTP/travel.siemens.com >> >> It's only used by gss_export and gss_canonicalize. A service must have a realm in the output of these 2 functions. The realm is not used in init_sec_context. >> >>> ** I don't like the idea using Heimdal-internal identifiers. Shouldn't >>> we define JGSS specific ones? At least create a define for. >> >> Well MIT krb5 is already using it (I see it in the exported byte array) so I think it's fine. I don't want to invent a new one. However I cannot use it now because of the permission check. I would think about supporting realm-less name in ServicePermission. >> >>> ** your concat fails if USERDNSDOMAIN is empty, you end up ith >>> service/instance@ >> >> That's sad, but I think it should never be empty if the client machine is in a domain and that's what this library wants to support. >> >>> ** Why do you check for '\\' what can be escaped here? Requires a better >>> comment >> >> I think Nico answered this in full detail. >> >>> * gss_import_name(): >>> ** BOOLEAN isNegotiate isn't really readable code >>> ** " value[len] = 0;" rather '\0'? This idiom repeats over and over >> >> Sometimes it's '\0' and sometimes it could even be L'\0'. I really don't want to make it too precise here. >> >>> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function >> >> Yes. >> >>> ** "if (value[len-1] == '@') {" you should comment this block and >>> explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? >> >> I suspect there will be empty/ignorable realms. >> >>> ** SPN conversion, why do you replace the '@' with '/' explicitly for >>> SSPI? A non-mech specific hostbased service is always neutral with '@' >> >> I just want to support Kerberos, and I don't want to replace it before calling InitSecContext. >> >>> >>> * gss_canonicalize_name(): something is fishy consider the following case: >>> gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to >>> receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but >>> get_full_name() doesn't do this >> >> The realm part is a problem because I cannot get the real one. The '@' should not be changed to '/' if name type is not HOSTBASED-SERVICE. >> >>> * gss_export_name(): probably the same issues as with gss_import_name() >>> >>> >>> * gss_init_sec_context(): >>> ** Line 909, wrong case for package name >> >> The one in PackageList? Fixed. It did work. >> >>> >>> I will try to setup a compile env after the next webrev and see how far >>> I get. I have enough cross-realm stuff around here. >> >> Great. If an app calls canonicalize/export and feed back the result into InitSecContext then there might be a problem. Maybe I should always strip the realm part before calling it? That sound like a part of the information is lost. Or maybe it's really useless for Windows? I know giving a wrong realm will fail. >> >> Or maybe I should use "WELLKNOWN:ORG.H5L.REFERALS-REALM". I'll do some experiment. >> >> Thanks, >> Max >> >>> >>> Michael >> > From 1983-01-06 at gmx.net Tue May 28 06:03:21 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 28 May 2019 08:03:21 +0200 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> References: <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> Message-ID: <90f09ced-54b1-88a5-ab8d-ea2952b8e9ae@gmx.net> I will have a look at the outstanding emails today. Am 2019-05-28 um 02:55 schrieb Weijun Wang: > Hi Everyone, > > Do you have any new comments? > > My major concern now is the canonicalization of service/host.dev.example.com to service/host.example.com at DEV.EXAMPLE.COM now. As Michael pointed out, it could well be service/host.example.com at EXAMPLE.COM. > > My suggestion now is to strip the realm part when InitSecurityContext is called. But when? If always, some information is lost if the realm is provided by the caller. So, how about we add "@WELLKNOWN:ORG.H5L.REFERALS-REALM" when it's a host-based service name? > > Thanks, > Max > >> On May 5, 2019, at 4:33 PM, Weijun Wang wrote: >> >> Hi Michael and Nico, >> >>> >>> sspi.cpp: >>> * KRB5_TRACE >> >> If you think a different name is better I'll change it. And then I'd like to revert to my old code that it always print to stderr. I don't have a need to print it to any file. >> >>> * showTime(): please use a readable format akin to %FT%T >> >> What is %FT%T? >> >>> >>> * NewContext(): >>> ** why don't you just pass the package name as WCHAR pointer? There is >>> no clear definition what happens if it is not SPNEGO w/o looking into >>> the code >> >> What I really want to express here is that I am only supporting 2 mechanisms now, and using a WCHAR might lead to an unsupported one. I also don't want to do OID<->string translation a lot. If you are only unsatisfied with the name, is negOrKrb5 better? >> >>> ** If you log the token size you should also log if SecurityStatus isn't >>> positive, just in case >> >> I didn't use cbMaxMessage. Will remove it. >> >>> ** new_context minor_status is never written, remove it? >> >> It was used by the SEC_SUCCESS macro. Now that I won't call QuerySecurityPackageInfo it's useless. Will remove it. >> >>> >>> * get_full_name()!!!: >>> ** What is the purpose of this function? It will not work reliably if >>> you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN >>> HTTP/travel.siemens.com >> >> It's only used by gss_export and gss_canonicalize. A service must have a realm in the output of these 2 functions. The realm is not used in init_sec_context. >> >>> ** I don't like the idea using Heimdal-internal identifiers. Shouldn't >>> we define JGSS specific ones? At least create a define for. >> >> Well MIT krb5 is already using it (I see it in the exported byte array) so I think it's fine. I don't want to invent a new one. However I cannot use it now because of the permission check. I would think about supporting realm-less name in ServicePermission. >> >>> ** your concat fails if USERDNSDOMAIN is empty, you end up ith >>> service/instance@ >> >> That's sad, but I think it should never be empty if the client machine is in a domain and that's what this library wants to support. >> >>> ** Why do you check for '\\' what can be escaped here? Requires a better >>> comment >> >> I think Nico answered this in full detail. >> >>> * gss_import_name(): >>> ** BOOLEAN isNegotiate isn't really readable code >>> ** " value[len] = 0;" rather '\0'? This idiom repeats over and over >> >> Sometimes it's '\0' and sometimes it could even be L'\0'. I really don't want to make it too precise here. >> >>> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function >> >> Yes. >> >>> ** "if (value[len-1] == '@') {" you should comment this block and >>> explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? >> >> I suspect there will be empty/ignorable realms. >> >>> ** SPN conversion, why do you replace the '@' with '/' explicitly for >>> SSPI? A non-mech specific hostbased service is always neutral with '@' >> >> I just want to support Kerberos, and I don't want to replace it before calling InitSecContext. >> >>> >>> * gss_canonicalize_name(): something is fishy consider the following case: >>> gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to >>> receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but >>> get_full_name() doesn't do this >> >> The realm part is a problem because I cannot get the real one. The '@' should not be changed to '/' if name type is not HOSTBASED-SERVICE. >> >>> * gss_export_name(): probably the same issues as with gss_import_name() >>> >>> >>> * gss_init_sec_context(): >>> ** Line 909, wrong case for package name >> >> The one in PackageList? Fixed. It did work. >> >>> >>> I will try to setup a compile env after the next webrev and see how far >>> I get. I have enough cross-realm stuff around here. >> >> Great. If an app calls canonicalize/export and feed back the result into InitSecContext then there might be a problem. Maybe I should always strip the realm part before calling it? That sound like a part of the information is lost. Or maybe it's really useless for Windows? I know giving a wrong realm will fail. >> >> Or maybe I should use "WELLKNOWN:ORG.H5L.REFERALS-REALM". I'll do some experiment. >> >> Thanks, >> Max >> >>> >>> Michael >> > > From christoph.langer at sap.com Tue May 28 07:21:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 07:21:21 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation Message-ID: Hi, please review this backport of JDK-8208698: Improved ECC Implementation. Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ The patch did not apply cleanly because there were conflicts in src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. Unfortunately, JDK-8205476 can not be downported as prerequisite because it brings a behavioral change and is associated with a CSR. So I resolved the rejects manually. I add the rejects below. Thanks Christoph --- ECDHKeyAgreement.java +++ ECDHKeyAgreement.java @@ -99,42 +104,74 @@ ("Key must be a PublicKey with algorithm EC"); } - ECPublicKey ecKey = (ECPublicKey)key; - ECParameterSpec params = ecKey.getParams(); + this.publicKey = (ECPublicKey) key; - if (ecKey instanceof ECPublicKeyImpl) { - publicValue = ((ECPublicKeyImpl)ecKey).getEncodedPublicValue(); - } else { // instanceof ECPublicKey - publicValue = - ECUtil.encodePoint(ecKey.getW(), params.getCurve()); - } + ECParameterSpec params = publicKey.getParams(); int keyLenBits = params.getCurve().getField().getFieldSize(); secretLen = (keyLenBits + 7) >> 3; return null; } + private static void validateCoordinate(BigInteger c, BigInteger mod) { + if (c.compareTo(BigInteger.ZERO) < 0) { + throw new ProviderException("invalid coordinate"); + } + + if (c.compareTo(mod) >= 0) { + throw new ProviderException("invalid coordinate"); + } + } + + /* + * Check whether a public key is valid. Throw ProviderException + * if it is not valid or could not be validated. + */ + private static void validate(ECOperations ops, ECPublicKey key) { + + // ensure that integers are in proper range + BigInteger x = key.getW().getAffineX(); + BigInteger y = key.getW().getAffineY(); + + BigInteger p = ops.getField().getSize(); + validateCoordinate(x, p); + validateCoordinate(y, p); + + // ensure the point is on the curve + EllipticCurve curve = key.getParams().getCurve(); + BigInteger rhs = x.modPow(BigInteger.valueOf(3), p).add(curve.getA() + .multiply(x)).add(curve.getB()).mod(p); + BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); + if (!rhs.equals(lhs)) { + throw new ProviderException("point is not on curve"); + } + + // check the order of the point + ImmutableIntegerModuloP xElem = ops.getField().getElement(x); + ImmutableIntegerModuloP yElem = ops.getField().getElement(y); + AffinePoint affP = new AffinePoint(xElem, yElem); + byte[] order = key.getParams().getOrder().toByteArray(); + ArrayUtil.reverse(order); + Point product = ops.multiply(affP, order); + if (!ops.isNeutral(product)) { + throw new ProviderException("point has incorrect order"); + } + + } + // see JCE spec @Override protected byte[] engineGenerateSecret() throws IllegalStateException { - if ((privateKey == null) || (publicValue == null)) { + if ((privateKey == null) || (publicKey == null)) { throw new IllegalStateException("Not initialized correctly"); } - byte[] s = privateKey.getS().toByteArray(); - byte[] encodedParams = // DER OID - ECUtil.encodeECParameterSpec(null, privateKey.getParams()); - - try { - - byte[] result = deriveKey(s, publicValue, encodedParams); - publicValue = null; - return result; - - } catch (GeneralSecurityException e) { - throw new ProviderException("Could not derive key", e); - } - + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); + byte[] result = resultOpt.orElseGet( + () -> deriveKeyNative(privateKey, publicKey) + ); + publicKey = null; + return result; } // see JCE spec -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 28 09:46:41 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 May 2019 17:46:41 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <90f09ced-54b1-88a5-ab8d-ea2952b8e9ae@gmx.net> References: <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <90f09ced-54b1-88a5-ab8d-ea2952b8e9ae@gmx.net> Message-ID: <7FCC20FF-48FD-44A3-9EF4-10548953BB1D@oracle.com> Thanks. I tried a 2-realm environment and it seems even if I add the current realm to a service in another realm, the service ticket can still be acquired successfully. So it looks like I can always add the current realm to a host-based service and there is no need to strip it later. Precisely: This realm is D19.LOCAL, and the other realm is DEV.D19.LOCAL. The KDC for the latter is k1.dev.d19.local and it also has IIS installed. I can visit the webpage there (protected with Windows Authentication) from the KDC of D19.LOCAL. The TargetName passed into InitiateSecurityContext I used is http/k1.dev.d10.local at D19.LOCAL. --Max > On May 28, 2019, at 2:03 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > I will have a look at the outstanding emails today. > > Am 2019-05-28 um 02:55 schrieb Weijun Wang: >> Hi Everyone, >> >> Do you have any new comments? >> >> My major concern now is the canonicalization of service/host.dev.example.com to service/host.example.com at DEV.EXAMPLE.COM now. As Michael pointed out, it could well be service/host.example.com at EXAMPLE.COM. >> >> My suggestion now is to strip the realm part when InitSecurityContext is called. But when? If always, some information is lost if the realm is provided by the caller. So, how about we add "@WELLKNOWN:ORG.H5L.REFERALS-REALM" when it's a host-based service name? >> >> Thanks, >> Max >> >>> On May 5, 2019, at 4:33 PM, Weijun Wang wrote: >>> >>> Hi Michael and Nico, >>> >>>> >>>> sspi.cpp: >>>> * KRB5_TRACE >>> >>> If you think a different name is better I'll change it. And then I'd like to revert to my old code that it always print to stderr. I don't have a need to print it to any file. >>> >>>> * showTime(): please use a readable format akin to %FT%T >>> >>> What is %FT%T? >>> >>>> >>>> * NewContext(): >>>> ** why don't you just pass the package name as WCHAR pointer? There is >>>> no clear definition what happens if it is not SPNEGO w/o looking into >>>> the code >>> >>> What I really want to express here is that I am only supporting 2 mechanisms now, and using a WCHAR might lead to an unsupported one. I also don't want to do OID<->string translation a lot. If you are only unsatisfied with the name, is negOrKrb5 better? >>> >>>> ** If you log the token size you should also log if SecurityStatus isn't >>>> positive, just in case >>> >>> I didn't use cbMaxMessage. Will remove it. >>> >>>> ** new_context minor_status is never written, remove it? >>> >>> It was used by the SEC_SUCCESS macro. Now that I won't call QuerySecurityPackageInfo it's useless. Will remove it. >>> >>>> >>>> * get_full_name()!!!: >>>> ** What is the purpose of this function? It will not work reliably if >>>> you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN >>>> HTTP/travel.siemens.com >>> >>> It's only used by gss_export and gss_canonicalize. A service must have a realm in the output of these 2 functions. The realm is not used in init_sec_context. >>> >>>> ** I don't like the idea using Heimdal-internal identifiers. Shouldn't >>>> we define JGSS specific ones? At least create a define for. >>> >>> Well MIT krb5 is already using it (I see it in the exported byte array) so I think it's fine. I don't want to invent a new one. However I cannot use it now because of the permission check. I would think about supporting realm-less name in ServicePermission. >>> >>>> ** your concat fails if USERDNSDOMAIN is empty, you end up ith >>>> service/instance@ >>> >>> That's sad, but I think it should never be empty if the client machine is in a domain and that's what this library wants to support. >>> >>>> ** Why do you check for '\\' what can be escaped here? Requires a better >>>> comment >>> >>> I think Nico answered this in full detail. >>> >>>> * gss_import_name(): >>>> ** BOOLEAN isNegotiate isn't really readable code >>>> ** " value[len] = 0;" rather '\0'? This idiom repeats over and over >>> >>> Sometimes it's '\0' and sometimes it could even be L'\0'. I really don't want to make it too precise here. >>> >>>> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function >>> >>> Yes. >>> >>>> ** "if (value[len-1] == '@') {" you should comment this block and >>>> explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? >>> >>> I suspect there will be empty/ignorable realms. >>> >>>> ** SPN conversion, why do you replace the '@' with '/' explicitly for >>>> SSPI? A non-mech specific hostbased service is always neutral with '@' >>> >>> I just want to support Kerberos, and I don't want to replace it before calling InitSecContext. >>> >>>> >>>> * gss_canonicalize_name(): something is fishy consider the following case: >>>> gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to >>>> receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but >>>> get_full_name() doesn't do this >>> >>> The realm part is a problem because I cannot get the real one. The '@' should not be changed to '/' if name type is not HOSTBASED-SERVICE. >>> >>>> * gss_export_name(): probably the same issues as with gss_import_name() >>>> >>>> >>>> * gss_init_sec_context(): >>>> ** Line 909, wrong case for package name >>> >>> The one in PackageList? Fixed. It did work. >>> >>>> >>>> I will try to setup a compile env after the next webrev and see how far >>>> I get. I have enough cross-realm stuff around here. >>> >>> Great. If an app calls canonicalize/export and feed back the result into InitSecContext then there might be a problem. Maybe I should always strip the realm part before calling it? That sound like a part of the information is lost. Or maybe it's really useless for Windows? I know giving a wrong realm will fail. >>> >>> Or maybe I should use "WELLKNOWN:ORG.H5L.REFERALS-REALM". I'll do some experiment. >>> >>> Thanks, >>> Max >>> >>>> >>>> Michael >>> >> >> > From sean.mullan at oracle.com Tue May 28 13:18:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 May 2019 09:18:24 -0400 Subject: RFR(S): Cleanups in sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java In-Reply-To: References: Message-ID: <6342a935-73e0-3e0d-4437-9d4c8a0a40e2@oracle.com> Hi Christoph, This is not really a bug, so I would change it to an Enhancement. 73 // private static final String DELTA_CRL = "deltaRevocationList;binary"; I would just remove this line. Looks good otherwise. --Sean On 5/25/19 5:51 AM, Langer, Christoph wrote: > Hi, > > please review this small cleanup which started off under a different > subject [0] but turned out to be the wrong thing to do. Still the > cleanup parts seem to be valuable, so requesting a review for that here. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224729 > > Thanks > > Christoph > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019967.html > From sean.mullan at oracle.com Tue May 28 14:12:11 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 May 2019 10:12:11 -0400 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> Message-ID: <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> On 5/24/19 8:37 PM, Weijun Wang wrote: > The CSR is approved. Are you OK with the schema definition referencing "ECParametersType" but not defining it. Yes, but could you add something like: "See section 4.5.2.3.1 of the W3C Recommendation for XML-Signature Syntax and Processing for the definition of ECParametersType." (This is a docs-only change, so you don't need to re-submit the CSR). Also, in the Release Note, can you mention that the JDK implementation does not support ECParametersType. Thanks, Sean > > If yes, I'll push the change. > > Thanks, > Nax > >> On May 14, 2019, at 8:50 AM, Weijun Wang wrote: >> >> >> >>> On May 13, 2019, at 10:51 PM, Sean Mullan wrote: >>> >>> On 5/10/19 8:07 PM, Weijun Wang wrote: >>>>> On May 11, 2019, at 4:44 AM, Sean Mullan wrote: >>>>> >>>>> On 5/10/19 5:04 AM, Weijun Wang wrote: >>>>>> Please take a review at the CSR at >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223682 >> >> Updated with @since 13 and no more @implNote. >> >> Thanks, >> Max >> >>>>> >>>>> Add an "@since 13" to the new constant. >>>>> >>>>>> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >>>>>> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. >>>>> >>>>> I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? >>>> Maybe a little complicated? >>>> https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 >>> >>> Yes, perhaps, or more likely because it is optional to support ECParameters. >>> >>> Section 4.5.2.3 of the XML Signature Recommendation says: >>> >>> "Conformant applications must support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7." >>> >>> --Sean >>> >>>> --Max >>>>> >>>>> --Sean >>>>> >>>>>> The code change is exactly the same as the specification, so no webrev. >>>>>> Thanks, >>>>>> Max >> > From sean.coffey at oracle.com Tue May 28 14:45:26 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 28 May 2019 15:45:26 +0100 Subject: RFR (XS) : 8042904: apple.security.KeychainStore.getSalt() calling generateSeed() Message-ID: <23e54b41-65ae-1989-67e7-f0ee5d78b8f8@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8042904 Looking to correct this issue. SecureRandom.nextBytes looks like the method which should be in use rather than generateSeed(int) --- a/src/java.base/macosx/classes/apple/security/KeychainStore.java +++ b/src/java.base/macosx/classes/apple/security/KeychainStore.java @@ -1050,7 +1050,7 @@ ???????? if (random == null) { ???????????? random = new SecureRandom(); ???????? } -??????? salt = random.generateSeed(SALT_LEN); +??????? random.nextBytes(salt); ???????? return salt; ???? } regards, Sean. From jamil.j.nimeh at oracle.com Tue May 28 14:52:54 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 28 May 2019 07:52:54 -0700 Subject: RFR (XS) : 8042904: apple.security.KeychainStore.getSalt() calling generateSeed() In-Reply-To: <23e54b41-65ae-1989-67e7-f0ee5d78b8f8@oracle.com> References: <23e54b41-65ae-1989-67e7-f0ee5d78b8f8@oracle.com> Message-ID: <55b50083-c072-fec1-9ac9-349477645ec2@oracle.com> This looks fine to me. --Jamil On 5/28/2019 7:45 AM, Se?n Coffey wrote: > https://bugs.openjdk.java.net/browse/JDK-8042904 > > Looking to correct this issue. SecureRandom.nextBytes looks like the > method > which should be in use rather than generateSeed(int) > > --- a/src/java.base/macosx/classes/apple/security/KeychainStore.java > +++ b/src/java.base/macosx/classes/apple/security/KeychainStore.java > @@ -1050,7 +1050,7 @@ > ???????? if (random == null) { > ???????????? random = new SecureRandom(); > ???????? } > -??????? salt = random.generateSeed(SALT_LEN); > +??????? random.nextBytes(salt); > ???????? return salt; > ???? } > > regards, > Sean. > > From sean.mullan at oracle.com Tue May 28 17:11:23 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 May 2019 13:11:23 -0400 Subject: RFR: 8224885: ProblemList sun/security/tools/keytool/KeyToolTest.java and WeakAlgTest.java on Solaris Message-ID: <4bd15dac-acbd-2eb8-6fdf-383e5dbb8d40@oracle.com> Please review this addition of two tests to the ProblemList which are causing intermittent tier4 failures on Solaris. bug: https://bugs.openjdk.java.net/browse/JDK-8224885 diffs: diff -r 0422b4b5cb8e test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Tue May 28 10:20:05 2019 -0400 +++ b/test/jdk/ProblemList.txt Tue May 28 13:09:14 2019 -0400 @@ -654,6 +654,8 @@ sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all +sun/security/tools/keytool/KeyToolTest.java 8224644 solaris-all +sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all Thanks, Sean From xuelei.fan at oracle.com Tue May 28 17:57:09 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 May 2019 10:57:09 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <9dff0eec-aaa1-f371-3535-da08af6d8ab1@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> <444a8dbe-aafb-ff21-a0de-8c35b7bc4551@oracle.com> <9dff0eec-aaa1-f371-3535-da08af6d8ab1@redhat.com> Message-ID: Hi Martin, Thank you for considering to make the improvement in this update. The use of synchronizedMap may hurt the performance. I may prefer to use ConcurrentHashMap and its computeIfAbsent?() method. (Read more, this map may be not necessary) 621 interface CipherGenerator { Could this interface be private? (Read more, this interface may be not necessary) 592 if (rcg != null && wcg != null) { Per the current implementation, checking read or write cipher generator is sufficient. If you want to check the read one only, there is no need to declare the CipherGenerator any more (line 621). It could be placed in ReadCipherGenerator. (Read more, may not need to update ReadCipherGenerator) 589-597 boolean supports(ProtocolVersion protocolVersion) { Together with the CipherGenerator interface, the logic of this block is actually about the transformation, not really about the cipher generator. Is it simpler to check the transformation directly? If we could check the transformation directly, it might be better to have the check in the SSLCipher constructors, using immutable enum field. Putting them together: SSLCipher.java: private SSLCipher(String transformation, ... this.isAvailable = - allowed && isUnlimited(keySize, transformation); + allowed && isUnlimited(keySize, transformation) && + isAvailable(transformation); } + private static boolean isAvailable(String transformation) { + if (!transformation.equals("NULL")) { + ... // check the instance + } else { + ... + } + } SSLContextImpl.java: 382 if (!suite.supports(protocol) || -383 !suite.bulkCipher.supports(protocol)) { +383 !suite.isAvailable()) { BTW, the coding style looks a little bit uncommon to me (May not need this block, anyway just for your consideration). 631 } catch (NoSuchAlgorithmException | NoSuchPaddingException e) { 632 } 633 cipherAlgorithms.put(algorithm, false); Would you mind if not using blank catch block? 631 } catch (NoSuchAlgorithmException | NoSuchPaddingException e) { + cipherAlgorithms.put(algorithm, false); + if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { + ... + } 632 } -633 cipherAlgorithms.put(algorithm, false); Thanks & Regards, Xuelei On 5/27/2019 2:00 PM, Martin Balao wrote: > Hi Xuelei, > > Thanks to you for raising these concerns and providing your feedback. > > On 5/24/19 7:47 PM, Xuelei Fan wrote: >> Good, I have no further comment for this update.? Please go ahead. >> >> I think there is a possible improvement by calling >> Cipher.getInstance(algorithm) only one time for each transformation >> algorithm.? But may not worthy as the duplicated transformation >> algorithm number is still small.? I'm fine if you want to leave it as it >> is. > > Yes, I agree on both statements: there can be an improvement there but > it won't be significant. Here it's Webrev.02: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.02/ > > At Webrev.02, Cipher.getInstance results are cached so we don't need to > create instances unnecessary. > > Benchmarks do not show any significant performance increase nor decrease > compared to Webrev.01: > > Benchmark (testMode) Mode Cnt > Score Error Units > SupportedCiphersuites.test_TLS12Communication FIPS thrpt 10 > 167.393 ? 35.659 ops/s > SupportedCiphersuites.test_TLS12Communication NON_FIPS thrpt 10 > 593.441 ? 110.044 ops/s > > FIPS_with_8223482_webrev02.txt average: 396.86 > NON_FIPS_with_8223482_webrev02.txt average: 888.05 > > Are you okay to go with Webrev.02? > > Kind regards, > Martin.- > From xuelei.fan at oracle.com Tue May 28 17:58:22 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 May 2019 10:58:22 -0700 Subject: RFR: 8224885: ProblemList sun/security/tools/keytool/KeyToolTest.java and WeakAlgTest.java on Solaris In-Reply-To: <4bd15dac-acbd-2eb8-6fdf-383e5dbb8d40@oracle.com> References: <4bd15dac-acbd-2eb8-6fdf-383e5dbb8d40@oracle.com> Message-ID: Looks good to me. Xuelei On 5/28/2019 10:11 AM, Sean Mullan wrote: > Please review this addition of two tests to the ProblemList which are > causing intermittent tier4 failures on Solaris. > > bug: https://bugs.openjdk.java.net/browse/JDK-8224885 > diffs: > > diff -r 0422b4b5cb8e test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Tue May 28 10:20:05 2019 -0400 > +++ b/test/jdk/ProblemList.txt? Tue May 28 13:09:14 2019 -0400 > @@ -654,6 +654,8 @@ > ?sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all > > ?sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all > +sun/security/tools/keytool/KeyToolTest.java???????????????????? 8224644 > solaris-all > +sun/security/tools/keytool/WeakAlg.java???????????????????????? 8224644 > solaris-all > > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 > generic-all > > > Thanks, > Sean From mbalao at redhat.com Tue May 28 18:20:54 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 28 May 2019 15:20:54 -0300 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> <03a0db21-865d-0ad4-b2b8-32d42ce2c38c@redhat.com> Message-ID: <2fd17eb0-3cde-a869-bcb3-c47c148a5fb2@redhat.com> Hi Max, Thanks for your feedback. Here it's Webrev.03: * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.03/ Changes: * msgType is now private * Check in CredentialsUtil.java removed (always true) * "PrincipalName cSname = (PrincipalName) sname.clone();" not necessary * In CredentialsUtils.java, I added comments to methods "serviceCreds", "serviceCredsReferrals" and "serviceCredsSingle". I'll keep the "single" suffix but if there is a better one, we can change it. Hopefully this is clearer with the comments now and removing the unnecessary "if". * "new PrincipalName(oldName.getNameString().replace..., newRealm)" replaced Regression testing in "jdk/sun/security/krb5" passed. On 5/24/19 9:23 PM, Weijun Wang wrote: >> 1) >> src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java: >> >> * When NT-ENTERPRISE names are used, a "@" char can be part of the name >> and we should not interpret it as a realm separator. If we don't escape, >> we may be missing part of the name when building a new PrincipalName. >> The exact place where this happens is in PrincipalName.parseName function. > > Is the character already escaped in the oldName? How about just changing > > new PrincipalName(oldName.getNameString().replace..., newRealm) > > to > > new PrincipalName(oldName.getNameStrings(), newRealm) > > Yes, this should be fine. Addressed in Webrev.03. > > It is also called by getTGTforRealm(). Is this for RFC 6806 "9. Cross-Realm Routing"? > No, getTGTforRealm is part of the cross-realm operation described by RFC 4120. If we need to get a TGS for a service which is in a different realm than the TGT we have, we first ask for a TGT on the service's realm (using the original TGT) and then we ask for the TGS. The service realm is determined by previous configurations and heuristics. My understanding is that getTGTforRealm is never needed when following RFC 6806 cross-realm referrals because the referral TGT we use for the next query is always for the next realm we are going to ask (the "service's realm"). That's how I see both things working together. A comment was added to "serviceCredsSingle" method explaining this. Kind regards, Martin.- From anthony.scarpino at oracle.com Tue May 28 18:55:52 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 28 May 2019 11:55:52 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: The CSR has been updated with what I believe address the mentioned issues. Tony On 5/21/19 4:24 PM, Anthony Scarpino wrote: > Hi All, > > Please review the CSR for the stateless Server Side > https://bugs.openjdk.java.net/browse/JDK-8223922 > > thanks > > Tony From anthony.scarpino at oracle.com Tue May 28 19:02:43 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 28 May 2019 12:02:43 -0700 Subject: RFR 8211018: Session Resumption without Server-Side State In-Reply-To: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> References: <681e7e7e-1fdb-0c10-6ca6-f8494d80c45d@oracle.com> Message-ID: <12ff1dcd-e9c2-7817-1a2f-5c18e2971565@oracle.com> An updated webrev has been added for the previous comments: http://cr.openjdk.java.net/~ascarpino/stateless/webrev.01 Tony On 5/16/19 2:30 PM, Anthony Scarpino wrote: > I'm asking for a review of this rather large change to add support > stateless tickets in the TLS 1.3 5077 RFC. > https://bugs.openjdk.java.net/browse/JDK-8211018 > > http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00 From sean.mullan at oracle.com Tue May 28 20:51:45 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 May 2019 16:51:45 -0400 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <06fc7210-c090-d82c-3462-0f50fa8afc29@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> <06fc7210-c090-d82c-3462-0f50fa8afc29@oracle.com> Message-ID: Hi Valerie, On 5/24/19 6:37 PM, Valerie Peng wrote: > Hi Sean, > > Thanks much for the suggestion. I have added the info on newly supported > algorithms to both the CSR and the bug record. Please let me know if you > have more comments. - In the Summary section, add a hyperlink to the PKCS#11 v2.40 standard and the errata - In general, I would put more information in the Specification section. I think attaching a patch of all the implementation changes is a bit too raw and not that useful as it is hard to discern what is specification and what is not (also the patch is not currently attached and pointing to a webrev is not acceptable per CSR rules since it may go away). Instead, I would avoid attaching a patch and instead include descriptions of the new attributes and algorithms in the Specification section in a format similar to that what is documented in https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html. Basically, I think this CSR should include the information that is exposed or configurable to users outside of the implementation, which I think can be described in 2 types of use cases: 1. configuring a PKCS#11 provider (need to know what attributes are supported and their defaults) 2. using it as a provider in an application (need to know what algorithms are supported and what is disabled/enabled by default) - Are there new attributes that are now supported than what are currently listed in Table 5.1 of the PKCS#11 Reference Guide?: https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9 If so, I think we should list them in the Specification section with the same details as in the Reference Guide. - For the new algorithms, I would include those in the Specification section, in a format like table 5.3 in the PKCS#11 Reference Guide: https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-D3EF9023-7DDC-435D-9186-D2FD05674777 - I would include any new or changed defaults for attributes, etc. --Sean > > All, > > RFEs need to be integrated by 6/13. Can someone help reviewing this > soon? Mach5 run is clean. I up'ed the version of webrev to webrev.01 due > to the additional support for RSASSA-PSS signatures. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 > CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 > Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ > > Thanks, > Valerie > > On 5/22/2019 7:55 AM, Sean Mullan wrote: >> On 5/21/19 7:19 PM, Valerie Peng wrote: >>> >>> I thought we always file CSR when updating the version of external >>> standard, e.g. documenting the import aspect of JDK. >> >> Good point though I think that was primarily based on whether the >> external standard was referenced in the javadocs of the standard APIs >> or influenced the behavior of existing APIs in some way. I don't think >> PKCS#11 is referenced from any of our standard APIs, but since this >> new version does add support for additional crypto algorithms via the >> standard APIs that weren't previously available, that sounds like a >> good enough reason for filing the CSR. >> >> I would recommend adding some additional details to the CSR to list >> what new features/algorithms PKCS#11 v2.40 provides and which standard >> APIs those features are applicable to. It would also be helpful to add >> similar details to the main issue and the release note as there aren't >> many details about what features are in the new version. >> >> Thanks, >> Sean >> >>> >>> I'd love to close/withdraw the CSR if it's not needed. >>> >>> Thanks, >>> Valerie >>> On 5/20/2019 12:11 PM, Sean Mullan wrote: >>>> On 5/17/19 3:56 PM, Valerie Peng wrote: >>>>> >>>>> Thanks Martin for helping me troubleshoot NSS side, I added PSS >>>>> support into PKCS11 provider and added PSS-specific regression >>>>> tests. Please find webrev updated as below: >>>>> >>>>> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>>>> >>>>> Can someone help review the CSR first as the approval may take a >>>>> week or so. >>>> >>>> I am curious why a CSR is needed? This seems to be strictly an >>>> implementation change with no compatibility effects. >>>> >>>> --Sean >>>> >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>>>>> >>>>>> Anyone has time to review this? Besides the header files update, I >>>>>> added support for AES/GCM/NoPadding support. Ran into some strange >>>>>> NSS error with RSASSA-PSS signature mechanism, so I have not >>>>>> included the PSS signature impl here. >>>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>>>>> >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> From mbalao at redhat.com Tue May 28 22:14:55 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 28 May 2019 19:14:55 -0300 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> <444a8dbe-aafb-ff21-a0de-8c35b7bc4551@oracle.com> <9dff0eec-aaa1-f371-3535-da08af6d8ab1@redhat.com> Message-ID: <714f14cf-321d-f4b7-d5a8-c9ec63a702c7@redhat.com> Hi Xuelei, Thanks for your feedback. On 5/28/19 2:57 PM, Xuelei Fan wrote: > > The use of synchronizedMap may hurt the performance.? I may prefer to > use ConcurrentHashMap and its computeIfAbsent?() method. (Read more, > this map may be not necessary) I've not seen any performance degradation with current benchmarks but this is always good to know. Thanks. > > ?621???? interface CipherGenerator { > Could this interface be private?? (Read more, this interface may be not > necessary) Yes, I guess we can. > > ?592???????? if (rcg != null && wcg != null) { > Per the current implementation, checking read or write cipher generator > is sufficient.? If you want to check the read one only, there is no need > to declare the CipherGenerator any more (line 621).? It could be placed > in ReadCipherGenerator.? (Read more, may not need to update > ReadCipherGenerator) > Yes, it's sufficient now because of the current implementation. However, the existence of ReadCipherGenerator and WriteCipherGenerator as separate classes suggests to me that there may be a difference. I have a similar comment below. > ?589-597???? boolean supports(ProtocolVersion protocolVersion) { > Together with the CipherGenerator interface, the logic of this block is > actually about the transformation, not really about the cipher > generator.? Is it simpler to check the transformation directly? > > > If we could check the transformation directly, it might be better to > have the check in the SSLCipher constructors, using immutable enum field. > > Putting them together: > > SSLCipher.java: > ??? private SSLCipher(String transformation, > ????? ... > ????? this.isAvailable = > -???????? allowed && isUnlimited(keySize, transformation); > +???????? allowed && isUnlimited(keySize, transformation) && > +???????? isAvailable(transformation); > ??? } > > +?? private static boolean isAvailable(String transformation) { > +????? if (!transformation.equals("NULL")) { > +????????? ...? // check the instance > +????? } else { > +????????? ... > +????? } > +?? } > SSLContextImpl.java: > ?382??? if (!suite.supports(protocol) || > -383??????????? !suite.bulkCipher.supports(protocol)) { > +383??????????? !suite.isAvailable()) { > * I guess you meant suite.bulkCipher.isAvailable(). Yes, this was something I considered at the beginning but had some design concerns. The Read/WriteCipherGenerator is chosen according to the protocol, and is the one that may have problems with the transformation when creating an instance. This generic design gives me the idea that there may be different cipher implementations (per protocol) and even per write or read operation. We can simplify based on the current implementation but, at some point, I believe we are going against the generic design. Anyways, I'll take it. It's still possible to have the "available transformations" cache but I guess, per your first comment, that you prefer not to have it. > BTW, the coding style looks a little bit uncommon to me (May not need > this block, anyway just for your consideration). > > ?631?? } catch (NoSuchAlgorithmException | NoSuchPaddingException e) { > ?632?? } > ?633?? cipherAlgorithms.put(algorithm, false); > > Would you mind if not using blank catch block? > ?631?? } catch (NoSuchAlgorithmException | NoSuchPaddingException e) { > +????????? cipherAlgorithms.put(algorithm, false); > +????????? if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { > +????????????? ... > +????????? } > ?632?? } > -633?? cipherAlgorithms.put(algorithm, false); > Yes, sure. Here it's Webrev.03 with all the previous changes: * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.03/ Thanks, Martin.- From xuelei.fan at oracle.com Tue May 28 22:47:16 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 May 2019 15:47:16 -0700 Subject: RFR 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <714f14cf-321d-f4b7-d5a8-c9ec63a702c7@redhat.com> References: <677f6a1b-7065-aab3-d90b-7a7c72a8807c@oracle.com> <24db024c-0dcc-b5c5-8968-176dd1ecfb08@redhat.com> <8fa4e987-23a1-16f5-c5ac-fe7ac0e74845@oracle.com> <8730fb14-9fd2-77ef-232f-da4503f6f271@redhat.com> <5b5668bc-ba3d-6f9d-8482-7b974eabd135@oracle.com> <84ed404e-326c-ba4c-72e3-084de3284632@redhat.com> <90742225-b418-0965-1a1a-35c42f90cb13@oracle.com> <2185f32c-873e-b7ac-6c96-20c4e024e1f8@redhat.com> <65225d92-f365-c6a1-9b77-d0cb669f648b@oracle.com> <29c9f7c1-979a-5278-69c1-f1d499db721c@oracle.com> <4ef30e78-04df-e40e-2701-40b3ada8bf46@redhat.com> <444a8dbe-aafb-ff21-a0de-8c35b7bc4551@oracle.com> <9dff0eec-aaa1-f371-3535-da08af6d8ab1@redhat.com> <714f14cf-321d-f4b7-d5a8-c9ec63a702c7@redhat.com> Message-ID: <6e5191f5-da1f-945b-1da3-d3083342f546@oracle.com> On 5/28/2019 3:14 PM, Martin Balao wrote: >> If we could check the transformation directly, it might be better to >> have the check in the SSLCipher constructors, using immutable enum field. >> >> Putting them together: >> >> SSLCipher.java: >> ??? private SSLCipher(String transformation, >> ????? ... >> ????? this.isAvailable = >> -???????? allowed && isUnlimited(keySize, transformation); >> +???????? allowed && isUnlimited(keySize, transformation) && >> +???????? isAvailable(transformation); >> ??? } >> >> +?? private static boolean isAvailable(String transformation) { >> +????? if (!transformation.equals("NULL")) { >> +????????? ...? // check the instance >> +????? } else { >> +????????? ... >> +????? } >> +?? } > >> SSLContextImpl.java: >> ?382??? if (!suite.supports(protocol) || >> -383??????????? !suite.bulkCipher.supports(protocol)) { >> +383??????????? !suite.isAvailable()) { >> > * I guess you meant suite.bulkCipher.isAvailable(). > No, I meant suite.isAvailable(), but suite.bulkCipher.isAvailable() also works for the update. I will leave it to you for the final decision, not more code review required to me. > Yes, this was something I considered at the beginning but had some > design concerns. The Read/WriteCipherGenerator is chosen according to > the protocol, and is the one that may have problems with the > transformation when creating an instance. This generic design gives me > the idea that there may be different cipher implementations (per > protocol) and even per write or read operation. We can simplify based on > the current implementation but, at some point, I believe we are going > against the generic design. Anyways, I'll take it. > With "!suite.supports(protocol) || !suite.isAvailable()", the protocol specific is checked with suite.supports(protocol), while the availability is checked with suite.isAvailable(). I think the design should be fine. > It's still possible to have the "available transformations" cache but I > guess, per your first comment, that you prefer not to have it. > I'm about 50% to 50% to use cache in enum constructor: a balance of memory or CPU. Once the enum get constructed, the cache is useless. So I prefer your current update unless the duplicated transformations is not a few. > > Here it's Webrev.03 with all the previous changes: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.03/ > It looks good to me. Thank you very much for taking my comments! Regards, Xuelei From sean.mullan at oracle.com Tue May 28 22:59:05 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 28 May 2019 18:59:05 -0400 Subject: RFR: 8224767: Add String constants for Canonical XML 1.1 URIs In-Reply-To: References: Message-ID: <1486d789-c3ba-59a0-fc0d-3772209e5cfd@oracle.com> I have updated the CSR to also include the new algorithm URIs in the TransformService section of the Standard Algorithm Names specification. I need a Reviewer for the CSR so I can finalize it soon and get it approved before the JDK 13 RDP1 deadline. CSR: https://bugs.openjdk.java.net/browse/JDK-8224773 I have also updated TransformService.getInstance and added links to the Standard Algorithm Names spec for the mechanism and algorithm parameters. This seemed to be something we previously missed (an oversight). webrev: http://cr.openjdk.java.net/~mullan/webrevs/8224767/webrev.01/ Thanks, Sean On 5/24/19 3:31 PM, Sean Mullan wrote: > Please review this fix to add two new String constants to the XML > Signature API for the Canonical XML 1.1 Algorithm URIs: > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8224767/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8224773 > > Thanks, > Sean From xuelei.fan at oracle.com Tue May 28 23:23:57 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 May 2019 16:23:57 -0700 Subject: RFR: 8224767: Add String constants for Canonical XML 1.1 URIs In-Reply-To: <1486d789-c3ba-59a0-fc0d-3772209e5cfd@oracle.com> References: <1486d789-c3ba-59a0-fc0d-3772209e5cfd@oracle.com> Message-ID: <884cf47d-c849-36ad-0459-9c288c4d043b@oracle.com> It looks good to me. I added myself as reviewer. Xuelei On 5/28/2019 3:59 PM, Sean Mullan wrote: > I have updated the CSR to also include the new algorithm URIs in the > TransformService section of the Standard Algorithm Names specification. > I need a Reviewer for the CSR so I can finalize it soon and get it > approved before the JDK 13 RDP1 deadline. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224773 > > I have also updated TransformService.getInstance and added links to the > Standard Algorithm Names spec for the mechanism and algorithm > parameters. This seemed to be something we previously missed (an > oversight). > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8224767/webrev.01/ > > Thanks, > Sean > > On 5/24/19 3:31 PM, Sean Mullan wrote: >> Please review this fix to add two new String constants to the XML >> Signature API for the Canonical XML 1.1 Algorithm URIs: >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8224767/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8224773 >> >> Thanks, >> Sean From weijun.wang at oracle.com Wed May 29 03:29:28 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 May 2019 11:29:28 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> Message-ID: <48001BB0-9110-4AA0-9916-9F690D48C6DD@oracle.com> Please take a look at the change at http://cr.openjdk.java.net/~weijun/8223053/webrev.00/ I didn't spell out the full "W3C Recommendation for XML-Signature Syntax and Processing" title because it appears right before the XML block. I had thought about changing the "R" to "r" but seems the capital R is used everywhere even when it's just a noun. For example [1]: What does "Web standard" mean? What is a "Recommendation"? W3C publishes documents that define Web technologies. These documents follow a process designed to promote consensus, fairness, public accountability, and quality. At the end of this process, W3C publishes Recommendations, which are considered Web standards. Thanks, Max [1] https://www.w3.org/standards/faq.html > On May 28, 2019, at 10:12 PM, Sean Mullan wrote: > > On 5/24/19 8:37 PM, Weijun Wang wrote: >> The CSR is approved. Are you OK with the schema definition referencing "ECParametersType" but not defining it. > > Yes, but could you add something like: "See section 4.5.2.3.1 of the W3C Recommendation for XML-Signature Syntax and Processing for the definition of ECParametersType." (This is a docs-only change, so you don't need to re-submit the CSR). > > Also, in the Release Note, can you mention that the JDK implementation does not support ECParametersType. > > Thanks, > Sean > >> If yes, I'll push the change. >> Thanks, >> Nax >>> On May 14, 2019, at 8:50 AM, Weijun Wang wrote: >>> >>> >>> >>>> On May 13, 2019, at 10:51 PM, Sean Mullan wrote: >>>> >>>> On 5/10/19 8:07 PM, Weijun Wang wrote: >>>>>> On May 11, 2019, at 4:44 AM, Sean Mullan wrote: >>>>>> >>>>>> On 5/10/19 5:04 AM, Weijun Wang wrote: >>>>>>> Please take a review at the CSR at >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223682 >>> >>> Updated with @since 13 and no more @implNote. >>> >>> Thanks, >>> Max >>> >>>>>> >>>>>> Add an "@since 13" to the new constant. >>>>>> >>>>>>> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >>>>>>> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. >>>>>> >>>>>> I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? >>>>> Maybe a little complicated? >>>>> https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 >>>> >>>> Yes, perhaps, or more likely because it is optional to support ECParameters. >>>> >>>> Section 4.5.2.3 of the XML Signature Recommendation says: >>>> >>>> "Conformant applications must support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7." >>>> >>>> --Sean >>>> >>>>> --Max >>>>>> >>>>>> --Sean >>>>>> >>>>>>> The code change is exactly the same as the specification, so no webrev. >>>>>>> Thanks, >>>>>>> Max >>> From weijun.wang at oracle.com Wed May 29 04:28:16 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 May 2019 12:28:16 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> Message-ID: <1DD8E68B-A997-4DA2-A16C-69A999B98A12@oracle.com> > On May 28, 2019, at 10:12 PM, Sean Mullan wrote: > > Also, in the Release Note, can you mention that the JDK implementation does not support ECParametersType. Please review it at https://bugs.openjdk.java.net/browse/JDK-8224943. Thanks, Max From xuelei.fan at oracle.com Wed May 29 13:25:10 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 May 2019 06:25:10 -0700 Subject: RFR[13] JDK-8224981, Problemlist test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java Message-ID: <4fb662fb-b5ee-59e7-a1cc-00d22b6fa0ea@oracle.com> Hi, Could I have a quick review of the update? There is a regression test failure. I would like to problem list the test before the fix is ready. Thanks, Xuelei $ hg diff test/jdk/ProblemList.txt diff -r b27f33bef884 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Fri May 10 12:33:40 2019 -0700 +++ b/test/jdk/ProblemList.txt Wed May 29 06:24:34 2019 -0700 @@ -657,6 +657,8 @@ sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all +sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all +sun/security/pkcs11/tls/tls12/FipsModeTLS12.java 8224954 generic-all sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all From sean.mullan at oracle.com Wed May 29 13:36:50 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 09:36:50 -0400 Subject: RFR[13] JDK-8224981, Problemlist test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java In-Reply-To: <4fb662fb-b5ee-59e7-a1cc-00d22b6fa0ea@oracle.com> References: <4fb662fb-b5ee-59e7-a1cc-00d22b6fa0ea@oracle.com> Message-ID: <0fcdd2da-f762-15d9-eb2b-00cb96004634@oracle.com> 8224954 says it only fails on Windows so should it be "windows-all"? Otherwise, looks fine. --Sean On 5/29/19 9:25 AM, Xuelei Fan wrote: > Hi, > > Could I have a quick review of the update?? There is a regression test > failure.? I would like to problem list the test before the fix is ready. > > Thanks, > Xuelei > > $ hg diff test/jdk/ProblemList.txt > diff -r b27f33bef884 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Fri May 10 12:33:40 2019 -0700 > +++ b/test/jdk/ProblemList.txt? Wed May 29 06:24:34 2019 -0700 > @@ -657,6 +657,8 @@ > ?sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all > ?sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all > ?sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all > +sun/security/pkcs11/tls/TestKeyMaterial.java??????????????????? 8180837 > generic-all > +sun/security/pkcs11/tls/tls12/FipsModeTLS12.java??????????????? 8224954 > generic-all > > ?sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all From xuelei.fan at oracle.com Wed May 29 13:40:11 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 May 2019 06:40:11 -0700 Subject: RFR[13] JDK-8224981, Problemlist test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java In-Reply-To: <0fcdd2da-f762-15d9-eb2b-00cb96004634@oracle.com> References: <4fb662fb-b5ee-59e7-a1cc-00d22b6fa0ea@oracle.com> <0fcdd2da-f762-15d9-eb2b-00cb96004634@oracle.com> Message-ID: <1976f4d8-53de-13fc-4aac-102ece3702bb@oracle.com> Thanks. I will update to use windows-all. Xuelei On 5/29/2019 6:36 AM, Sean Mullan wrote: > 8224954 says it only fails on Windows so should it be "windows-all"? > Otherwise, looks fine. > > --Sean > > On 5/29/19 9:25 AM, Xuelei Fan wrote: >> Hi, >> >> Could I have a quick review of the update?? There is a regression test >> failure.? I would like to problem list the test before the fix is ready. >> >> Thanks, >> Xuelei >> >> $ hg diff test/jdk/ProblemList.txt >> diff -r b27f33bef884 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt? Fri May 10 12:33:40 2019 -0700 >> +++ b/test/jdk/ProblemList.txt? Wed May 29 06:24:34 2019 -0700 >> @@ -657,6 +657,8 @@ >> ??sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all >> ??sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all >> ??sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all >> +sun/security/pkcs11/tls/TestKeyMaterial.java >> 8180837 generic-all >> +sun/security/pkcs11/tls/tls12/FipsModeTLS12.java >> 8224954 generic-all >> >> ??sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all From xuelei.fan at oracle.com Wed May 29 14:27:37 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 May 2019 07:27:37 -0700 Subject: RFR[13] JDK-8224984: Problemlist javax/net/ssl/SSLSocket/Tls13PacketSize.java Message-ID: <05d4df91-4b3f-acd8-9cbb-878f32689649@oracle.com> Hi, Could I get the following update reviewed? In the test case, test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java, the socket cannot be closed gracefully. I'm not very sure of the right place to fix the issue right now. Request to problem list before I get an idea. Thanks, Xuelei $ hg diff test/jdk/ProblemList.txt diff -r bda9984d8ee4 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Wed May 29 06:56:19 2019 -0700 +++ b/test/jdk/ProblemList.txt Wed May 29 07:24:01 2019 -0700 @@ -660,6 +660,7 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all +javax/net/ssl/SSLSocket/Tls13PacketSize.java 8224718 generic-all javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 javax/net/ssl/DTLS/CipherSuite.java 8202059 macosx-x64 From sean.mullan at oracle.com Wed May 29 14:40:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 10:40:24 -0400 Subject: RFR[13] JDK-8224984: Problemlist javax/net/ssl/SSLSocket/Tls13PacketSize.java In-Reply-To: <05d4df91-4b3f-acd8-9cbb-878f32689649@oracle.com> References: <05d4df91-4b3f-acd8-9cbb-878f32689649@oracle.com> Message-ID: Looks fine, but maybe you want to just exclude "windows-all" if it has only been seen on Windows so far. --Sean On 5/29/19 10:27 AM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > In the test case, test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java, > the socket cannot be closed gracefully.? I'm not very sure of the right > place to fix the issue right now.? Request to problem list before I get > an idea. > > Thanks, > Xuelei > > $ hg diff test/jdk/ProblemList.txt > diff -r bda9984d8ee4 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Wed May 29 06:56:19 2019 -0700 > +++ b/test/jdk/ProblemList.txt? Wed May 29 07:24:01 2019 -0700 > @@ -660,6 +660,7 @@ > > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 > generic-all > > +javax/net/ssl/SSLSocket/Tls13PacketSize.java??????????????????? 8224718 > generic-all > ?javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 > ?javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 > ?javax/net/ssl/DTLS/CipherSuite.java 8202059 macosx-x64 From xuelei.fan at oracle.com Wed May 29 14:45:49 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 May 2019 07:45:49 -0700 Subject: RFR[13] JDK-8224984: Problemlist javax/net/ssl/SSLSocket/Tls13PacketSize.java In-Reply-To: References: <05d4df91-4b3f-acd8-9cbb-878f32689649@oracle.com> Message-ID: I'm not very sure if it happens on windows only. In theory, it could fail on other platforms as well. I would like to use general-all for now. Thanks, Xuelei On 5/29/2019 7:40 AM, Sean Mullan wrote: > Looks fine, but maybe you want to just exclude "windows-all" if it has > only been seen on Windows so far. > > --Sean > > On 5/29/19 10:27 AM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> In the test case, >> test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java, the socket >> cannot be closed gracefully.? I'm not very sure of the right place to >> fix the issue right now.? Request to problem list before I get an idea. >> >> Thanks, >> Xuelei >> >> $ hg diff test/jdk/ProblemList.txt >> diff -r bda9984d8ee4 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt? Wed May 29 06:56:19 2019 -0700 >> +++ b/test/jdk/ProblemList.txt? Wed May 29 07:24:01 2019 -0700 >> @@ -660,6 +660,7 @@ >> >> ??sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 >> generic-all >> >> +javax/net/ssl/SSLSocket/Tls13PacketSize.java >> 8224718 generic-all >> ??javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 >> ??javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 >> ??javax/net/ssl/DTLS/CipherSuite.java 8202059 macosx-x64 From sean.mullan at oracle.com Wed May 29 14:46:22 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 10:46:22 -0400 Subject: RFR[13] JDK-8224984: Problemlist javax/net/ssl/SSLSocket/Tls13PacketSize.java In-Reply-To: References: <05d4df91-4b3f-acd8-9cbb-878f32689649@oracle.com> Message-ID: On 5/29/19 10:45 AM, Xuelei Fan wrote: > I'm not very sure if it happens on windows only.? In theory, it could > fail on other platforms as well.? I would like to use general-all for now. Sure, that's fine. --Sean > > Thanks, > Xuelei > > On 5/29/2019 7:40 AM, Sean Mullan wrote: >> Looks fine, but maybe you want to just exclude "windows-all" if it has >> only been seen on Windows so far. >> >> --Sean >> >> On 5/29/19 10:27 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed? >>> >>> In the test case, >>> test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java, the socket >>> cannot be closed gracefully.? I'm not very sure of the right place to >>> fix the issue right now.? Request to problem list before I get an idea. >>> >>> Thanks, >>> Xuelei >>> >>> $ hg diff test/jdk/ProblemList.txt >>> diff -r bda9984d8ee4 test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt? Wed May 29 06:56:19 2019 -0700 >>> +++ b/test/jdk/ProblemList.txt? Wed May 29 07:24:01 2019 -0700 >>> @@ -660,6 +660,7 @@ >>> >>> ??sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 >>> generic-all >>> >>> +javax/net/ssl/SSLSocket/Tls13PacketSize.java 8224718 generic-all >>> ??javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 >>> ??javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 >>> ??javax/net/ssl/DTLS/CipherSuite.java 8202059 macosx-x64 From sean.mullan at oracle.com Wed May 29 15:24:53 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 11:24:53 -0400 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <48001BB0-9110-4AA0-9916-9F690D48C6DD@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> <48001BB0-9110-4AA0-9916-9F690D48C6DD@oracle.com> Message-ID: <0144af71-7423-4c0a-6398-053465c06651@oracle.com> Looks good. --Sean On 5/28/19 11:29 PM, Weijun Wang wrote: > Please take a look at the change at > > http://cr.openjdk.java.net/~weijun/8223053/webrev.00/ > > I didn't spell out the full "W3C Recommendation for XML-Signature Syntax and Processing" title because it appears right before the XML block. I had thought about changing the "R" to "r" but seems the capital R is used everywhere even when it's just a noun. For example [1]: > > What does "Web standard" mean? What is a "Recommendation"? > > W3C publishes documents that define Web technologies. These documents follow a process > designed to promote consensus, fairness, public accountability, and quality. At the end > of this process, W3C publishes Recommendations, which are considered Web standards. > > Thanks, > Max > > [1] https://www.w3.org/standards/faq.html > >> On May 28, 2019, at 10:12 PM, Sean Mullan wrote: >> >> On 5/24/19 8:37 PM, Weijun Wang wrote: >>> The CSR is approved. Are you OK with the schema definition referencing "ECParametersType" but not defining it. >> >> Yes, but could you add something like: "See section 4.5.2.3.1 of the W3C Recommendation for XML-Signature Syntax and Processing for the definition of ECParametersType." (This is a docs-only change, so you don't need to re-submit the CSR). >> >> Also, in the Release Note, can you mention that the JDK implementation does not support ECParametersType. >> >> Thanks, >> Sean >> >>> If yes, I'll push the change. >>> Thanks, >>> Nax >>>> On May 14, 2019, at 8:50 AM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On May 13, 2019, at 10:51 PM, Sean Mullan wrote: >>>>> >>>>> On 5/10/19 8:07 PM, Weijun Wang wrote: >>>>>>> On May 11, 2019, at 4:44 AM, Sean Mullan wrote: >>>>>>> >>>>>>> On 5/10/19 5:04 AM, Weijun Wang wrote: >>>>>>>> Please take a review at the CSR at >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223682 >>>> >>>> Updated with @since 13 and no more @implNote. >>>> >>>> Thanks, >>>> Max >>>> >>>>>>> >>>>>>> Add an "@since 13" to the new constant. >>>>>>> >>>>>>>> The text is copied from 4.5.2 and 4.5.2.3 of https://www.w3.org/TR/xmldsig-core/. >>>>>>>> One thing I am not sure is that I haven't include the definition of ECParameters in 4.5.2.3.1 which is quite long. While I added an @implNote saying ECParameters is not supported in this implementation, I understand @implNote is not really a part of the spec and it's not the reason I omit the definition of ECParameters. If you believe it should be included, I'll add it, or add a link. >>>>>>> >>>>>>> I would leave out the implNote completely. It doesn't seem the right place to put it, since this is an interface. What is the reason ECParameters is not supported? >>>>>> Maybe a little complicated? >>>>>> https://github.com/apache/santuario-java/blob/fa12dc57a16fbcd637c2aac6f3af3db19fe4b187/src/main/java/org/apache/xml/security/keys/content/keyvalues/ECKeyValue.java#L171 >>>>> >>>>> Yes, perhaps, or more likely because it is optional to support ECParameters. >>>>> >>>>> Section 4.5.2.3 of the XML Signature Recommendation says: >>>>> >>>>> "Conformant applications must support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7." >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>>> The code change is exactly the same as the specification, so no webrev. >>>>>>>> Thanks, >>>>>>>> Max >>>> > From sean.mullan at oracle.com Wed May 29 15:39:20 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 11:39:20 -0400 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: <1DD8E68B-A997-4DA2-A16C-69A999B98A12@oracle.com> References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> <1DD8E68B-A997-4DA2-A16C-69A999B98A12@oracle.com> Message-ID: On 5/29/19 12:28 AM, Weijun Wang wrote: > > >> On May 28, 2019, at 10:12 PM, Sean Mullan wrote: >> >> Also, in the Release Note, can you mention that the JDK implementation does not support ECParametersType. I realize now that this is the wrong place to document this. The JDK implementation has supported EC keys for a while now. The release note should be just about what is new. We will need to find a different place to document this but I don't know the exact place so let's table it for now. > Please review it at https://bugs.openjdk.java.net/browse/JDK-8224943. I would reword this based on the above. Suggest simply: A new `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface, which represents the `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue). --Sean From christoph.langer at sap.com Wed May 29 15:44:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 29 May 2019 15:44:42 +0000 Subject: RFR(S): Cleanups in sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java In-Reply-To: <6342a935-73e0-3e0d-4437-9d4c8a0a40e2@oracle.com> References: <6342a935-73e0-3e0d-4437-9d4c8a0a40e2@oracle.com> Message-ID: Hi Sean, thanks for the review. I've addressed your points: http://cr.openjdk.java.net/~clanger/webrevs/8224729.2/ Thanks Christoph > -----Original Message----- > From: Sean Mullan > Sent: Dienstag, 28. Mai 2019 15:18 > To: Langer, Christoph ; security-dev dev at openjdk.java.net> > Subject: Re: RFR(S): Cleanups in > sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java > > Hi Christoph, > > This is not really a bug, so I would change it to an Enhancement. > > 73 // private static final String DELTA_CRL = > "deltaRevocationList;binary"; > > I would just remove this line. > > Looks good otherwise. > > --Sean > > On 5/25/19 5:51 AM, Langer, Christoph wrote: > > Hi, > > > > please review this small cleanup which started off under a different > > subject [0] but turned out to be the wrong thing to do. Still the > > cleanup parts seem to be valuable, so requesting a review for that here. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.1/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224729 > > > > Thanks > > > > Christoph > > > > [0] > > https://mail.openjdk.java.net/pipermail/security-dev/2019- > May/019967.html > > From weijun.wang at oracle.com Wed May 29 15:45:36 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 May 2019 23:45:36 +0800 Subject: RFR 8223053: [xmldsig] Add KeyValue::EC_TYPE In-Reply-To: References: <260C9947-5250-4CBF-A21A-E630DC723075@oracle.com> <3F502E39-41A4-4BBE-B688-070C3CEE0C21@oracle.com> <5e687133-8d0a-7907-a374-a91277c204d2@oracle.com> <80D486EC-B9E6-452C-B1F8-274531D21C3C@oracle.com> <23B71A9D-1FA2-4C88-B420-D7D46F4B601B@oracle.com> <5ed8c0f8-83d6-3eec-d949-83846e6df463@oracle.com> <1DD8E68B-A997-4DA2-A16C-69A999B98A12@oracle.com> Message-ID: But the support is in JDK 13 and not too long ago. I understand the "The `ECKeyValue` type ... is supported" does not match this RFE exactly, but the words on `NamedCurve` and `ECParameters` can still be written here. Or, shall we add a release note for JDK-8219013 (Update Apache Santuario to version 2.1.3) describing "what's new"? --Max > On May 29, 2019, at 11:39 PM, Sean Mullan wrote: > > On 5/29/19 12:28 AM, Weijun Wang wrote: >>> On May 28, 2019, at 10:12 PM, Sean Mullan wrote: >>> >>> Also, in the Release Note, can you mention that the JDK implementation does not support ECParametersType. > > I realize now that this is the wrong place to document this. The JDK implementation has supported EC keys for a while now. The release note should be just about what is new. We will need to find a different place to document this but I don't know the exact place so let's table it for now. > >> Please review it at https://bugs.openjdk.java.net/browse/JDK-8224943. > > I would reword this based on the above. Suggest simply: > > A new `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface, which represents the `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue). > > --Sean From sean.mullan at oracle.com Wed May 29 15:51:16 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 11:51:16 -0400 Subject: RFR(S): Cleanups in sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java In-Reply-To: References: <6342a935-73e0-3e0d-4437-9d4c8a0a40e2@oracle.com> Message-ID: On 5/29/19 11:44 AM, Langer, Christoph wrote: > Hi Sean, > > thanks for the review. I've addressed your points:http://cr.openjdk.java.net/~clanger/webrevs/8224729.2/ Looks good. --Sean From xuelei.fan at oracle.com Wed May 29 16:04:50 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 May 2019 09:04:50 -0700 Subject: RFR[13] JDK-8224991: Problemlist javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java Message-ID: <76461e2d-ca4d-1ae5-0134-466fd34d0f32@oracle.com> Hi, Could I get the following update reviewed? The test case, javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java, fails intermittently. It may caused by buffer management in the test code. Need more time for the fix, problem list it for now. See the following bugs for the test failure information: https://bugs.openjdk.java.net/browse/JDK-8208606 https://bugs.openjdk.java.net/browse/JDK-8224990 Thanks, Xuelei $ hg diff test/jdk/ProblemList.txt diff -r dcda4663a926 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Wed May 29 07:48:27 2019 -0700 +++ b/test/jdk/ProblemList.txt Wed May 29 09:04:00 2019 -0700 @@ -660,6 +660,7 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all +javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8224990 generic-all javax/net/ssl/SSLSocket/Tls13PacketSize.java 8224718 generic-all javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 From Nico.Williams at twosigma.com Wed May 29 17:23:54 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 29 May 2019 17:23:54 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> References: <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> Message-ID: <20190529172354.GH7457@twosigma.com> On Tue, May 28, 2019 at 08:55:22AM +0800, Weijun Wang wrote: > Do you have any new comments? I should take one more look. > My major concern now is the canonicalization of service/host.dev.example.com > to service/host.example.com at DEV.EXAMPLE.COM now. As Michael pointed out, it > could well be service/host.example.com at EXAMPLE.COM. > > My suggestion now is to strip the realm part when InitSecurityContext > is called. But when? If always, some information is lost if the realm > is provided by the caller. So, how about we add > "@WELLKNOWN:ORG.H5L.REFERALS-REALM" when it's a host-based service > name? If a name was imported as GSS_C_NT_HOSTBASED_SERVICE, then there is no realm. If it was imported as GSS_KRB5_NT_PRINCIPAL and there was no realm, then there is no realm. If it was imported as GSS_KRB5_NT_PRINCIPAL and there was a realm, then you should respect it -- I say "should" because some applications will set it incorrectly, notably the MSSQL JDBC driver. Now, as to SSPI, I don't know exactly how to tell it a realm to start at (this would be the client principal's realm in the general case) or to tell it to start at whatever realm Windows wants to (same thing), but that's what you want. Nico -- From sean.mullan at oracle.com Wed May 29 18:28:17 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 14:28:17 -0400 Subject: RFR[13] JDK-8224991: Problemlist javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java In-Reply-To: <76461e2d-ca4d-1ae5-0134-466fd34d0f32@oracle.com> References: <76461e2d-ca4d-1ae5-0134-466fd34d0f32@oracle.com> Message-ID: The ProblemList should reference 8212096 instead, since 8224990 is closed as a duplicate of 8212096. Looks ok otherwise. --Sean On 5/29/19 12:04 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > The test case, > javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java, fails > intermittently. It may caused by buffer management in the test code. > Need more time for the fix, problem list it for now. > > See the following bugs for the test failure information: > ? https://bugs.openjdk.java.net/browse/JDK-8208606 > ? https://bugs.openjdk.java.net/browse/JDK-8224990 > > Thanks, > Xuelei > > > $ hg diff test/jdk/ProblemList.txt > diff -r dcda4663a926 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Wed May 29 07:48:27 2019 -0700 > +++ b/test/jdk/ProblemList.txt? Wed May 29 09:04:00 2019 -0700 > @@ -660,6 +660,7 @@ > > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 > generic-all > > +javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java?????? 8224990 > generic-all > ?javax/net/ssl/SSLSocket/Tls13PacketSize.java 8224718 generic-all > ?javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 > ?javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 From valerie.peng at oracle.com Wed May 29 19:00:29 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 29 May 2019 12:00:29 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> <06fc7210-c090-d82c-3462-0f50fa8afc29@oracle.com> Message-ID: <3ce843bd-2f9a-4eee-4810-b2fb00857c60@oracle.com> Hi Sean, Much thanks for the feedbacks. They are very helpful... I have updated the CSR per your feedbacks. https://bugs.openjdk.java.net/browse/JDK-8221442 Please find more replies inline below. On 5/28/2019 1:51 PM, Sean Mullan wrote: > Hi Valerie, > > On 5/24/19 6:37 PM, Valerie Peng wrote: >> Hi Sean, >> >> Thanks much for the suggestion. I have added the info on newly >> supported algorithms to both the CSR and the bug record. Please let >> me know if you have more comments. > > - In the Summary section, add a hyperlink to the PKCS#11 v2.40 > standard and the errata Done. > - In general, I would put more information in the Specification > section. I think attaching a patch of all the implementation changes > is a bit too raw and not that useful as it is hard to discern what is > specification and what is not (also the patch is not currently > attached and pointing to a webrev is not acceptable per CSR rules > since it may go away). Instead, I would avoid attaching a patch and > instead include descriptions of the new attributes and algorithms in > the Specification section in a format similar to that what is > documented in > https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html. > > Basically, I think this CSR should include the information that is > exposed or configurable to users outside of the implementation, which > I think can be described in 2 types of use cases: Yes, I think this is better. I was focusing on header file updates in original CSR. Agree that it'd be useful to list changes exposed by this RFE. > 1. configuring a PKCS#11 provider (need to know what attributes are > supported and their defaults) Well, PKCS11 reference guide uses the term "attribute" to refer to provider configuration options. This RFE did not add new provider configuration options. However, there is also attributes defined in PKCS#11 whose name starts with CKA_xxx. This RFE enhances SunPKCS11 provider to recognize new PKCS#11 attributes and won't error out with exceptions when specified inside the configuration file entries as attribute values, e.g. |attributes(*,CKO_PRIVATE_KEY,CKK_RSA) = { *CKA_DECRYPT* = true }| These newly recognized PKCS#11 attributes (CKA_xxx), mechanisms (CKM_xxx), key types (CKK_xxx), etc., are defined in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java. > 2. using it as a provider in an application (need to know what > algorithms are supported and what is disabled/enabled by default) Yes, these are the list of newly supported algorithms which I have added to the CSR to address your earlier comment. None of them are disabled by default. However, only when the underlying PKCS11 library also support these, they will show up as available. > - Are there new attributes that are now supported than what are > currently listed in Table 5.1 of the PKCS#11 Reference Guide?: > https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9 If you are referring to attributes per the convention of PKCS#11 reference guide, no new provider configuration attributes added. However, new PKCS#11 attributes are recognized. We don't list recognized PKCS#11 attributes in the reference guide as they are quite extensive. PKCS11 header files define a long list of constants and depending on what they are for, it may or may not lead to an error. For example, unrecognized mechanisms and error codes will be accepted and their long values are used instead. However, unrecognized PKCS#11 attributes specified in the PKCS#11 provider configuration file will lead to exception. > If so, I think we should list them in the Specification section with > the same details as in the Reference Guide. Given the above, I suppose that we don't need to list out all newly supported PKCS#11 attributes? They do impact the user in some way, but not sure if it's too much details. Perhaps we can just state that whatever supported in the PKCS#11 v2.40 headers are now recognized by SunPKCS11 provider. > - For the new algorithms, I would include those in the Specification > section, in a format like table 5.3 in the PKCS#11 Reference Guide: > https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-D3EF9023-7DDC-435D-9186-D2FD05674777 Sure, will do. > > - I would include any new or changed defaults for attributes, etc. No new defaults or new attributes for PKCS11 provider configurations. Regards, Valerie > > --Sean > >> >> All, >> >> RFEs need to be integrated by 6/13. Can someone help reviewing this >> soon? Mach5 run is clean. I up'ed the version of webrev to webrev.01 >> due to the additional support for RSASSA-PSS signatures. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >> >> Thanks, >> Valerie >> >> On 5/22/2019 7:55 AM, Sean Mullan wrote: >>> On 5/21/19 7:19 PM, Valerie Peng wrote: >>>> >>>> I thought we always file CSR when updating the version of external >>>> standard, e.g. documenting the import aspect of JDK. >>> >>> Good point though I think that was primarily based on whether the >>> external standard was referenced in the javadocs of the standard >>> APIs or influenced the behavior of existing APIs in some way. I >>> don't think PKCS#11 is referenced from any of our standard APIs, but >>> since this new version does add support for additional crypto >>> algorithms via the standard APIs that weren't previously available, >>> that sounds like a good enough reason for filing the CSR. >>> >>> I would recommend adding some additional details to the CSR to list >>> what new features/algorithms PKCS#11 v2.40 provides and which >>> standard APIs those features are applicable to. It would also be >>> helpful to add similar details to the main issue and the release >>> note as there aren't many details about what features are in the new >>> version. >>> >>> Thanks, >>> Sean >>> >>>> >>>> I'd love to close/withdraw the CSR if it's not needed. >>>> >>>> Thanks, >>>> Valerie >>>> On 5/20/2019 12:11 PM, Sean Mullan wrote: >>>>> On 5/17/19 3:56 PM, Valerie Peng wrote: >>>>>> >>>>>> Thanks Martin for helping me troubleshoot NSS side, I added PSS >>>>>> support into PKCS11 provider and added PSS-specific regression >>>>>> tests. Please find webrev updated as below: >>>>>> >>>>>> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>>>>> >>>>>> Can someone help review the CSR first as the approval may take a >>>>>> week or so. >>>>> >>>>> I am curious why a CSR is needed? This seems to be strictly an >>>>> implementation change with no compatibility effects. >>>>> >>>>> --Sean >>>>> >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>>>>>> >>>>>>> Anyone has time to review this? Besides the header files update, >>>>>>> I added support for AES/GCM/NoPadding support. Ran into some >>>>>>> strange NSS error with RSASSA-PSS signature mechanism, so I have >>>>>>> not included the PSS signature impl here. >>>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>>>>>> >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed May 29 19:30:52 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 29 May 2019 16:30:52 -0300 Subject: RFR[13] JDK-8224981, Problemlist test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java In-Reply-To: <1976f4d8-53de-13fc-4aac-102ece3702bb@oracle.com> References: <4fb662fb-b5ee-59e7-a1cc-00d22b6fa0ea@oracle.com> <0fcdd2da-f762-15d9-eb2b-00cb96004634@oracle.com> <1976f4d8-53de-13fc-4aac-102ece3702bb@oracle.com> Message-ID: Hi Xuelei, Thanks for blacklisting this test. I've been trying to reproduce this failure in my local Windows environment without success. Thus, I'm not sure of what's going on. My hypothesis is that SSLCipher class may be initialized, for some reason, before the Security providers are dynamically set during the "initialize" function (FipsModeTLS12.java). If I had access to the environment where the failure reproduces, I would set security providers in java.security to confirm or discard. Kind regards, Martin.- From sean.mullan at oracle.com Wed May 29 20:12:36 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 May 2019 16:12:36 -0400 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <3ce843bd-2f9a-4eee-4810-b2fb00857c60@oracle.com> References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> <06fc7210-c090-d82c-3462-0f50fa8afc29@oracle.com> <3ce843bd-2f9a-4eee-4810-b2fb00857c60@oracle.com> Message-ID: I agree with your comments below and the current CSR looks good so I've added my name as Reviewer. One main comment is that I don't think you should check the "Source" compatibility box. That would mean this would be a source-incompatible change [1], which I don't think is right. I don't think you should check any of the Compatibility boxes as according to the "Compatibility Risk Description" box, you said there is no compatibility risk. --Sean [1] https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility On 5/29/19 3:00 PM, Valerie Peng wrote: > Hi Sean, > > Much thanks for the feedbacks. They are very helpful... I have updated > the CSR per your feedbacks. > > https://bugs.openjdk.java.net/browse/JDK-8221442 > > Please find more replies inline below. > > On 5/28/2019 1:51 PM, Sean Mullan wrote: > >> Hi Valerie, >> >> On 5/24/19 6:37 PM, Valerie Peng wrote: >>> Hi Sean, >>> >>> Thanks much for the suggestion. I have added the info on newly >>> supported algorithms to both the CSR and the bug record. Please let >>> me know if you have more comments. >> >> - In the Summary section, add a hyperlink to the PKCS#11 v2.40 >> standard and the errata > > Done. > >> - In general, I would put more information in the Specification >> section. I think attaching a patch of all the implementation changes >> is a bit too raw and not that useful as it is hard to discern what is >> specification and what is not (also the patch is not currently >> attached and pointing to a webrev is not acceptable per CSR rules >> since it may go away). Instead, I would avoid attaching a patch and >> instead include descriptions of the new attributes and algorithms in >> the Specification section in a format similar to that what is >> documented in >> https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html. >> >> Basically, I think this CSR should include the information that is >> exposed or configurable to users outside of the implementation, which >> I think can be described in 2 types of use cases: > > Yes, I think this is better. I was focusing on header file updates in > original CSR. Agree that it'd be useful to list changes exposed by this > RFE. > >> 1. configuring a PKCS#11 provider (need to know what attributes are >> supported and their defaults) > > Well, PKCS11 reference guide uses the term "attribute" to refer to > provider configuration options. This RFE did not add new provider > configuration options. However, there is also attributes defined in > PKCS#11 whose name starts with CKA_xxx. This RFE enhances SunPKCS11 > provider to recognize new PKCS#11 attributes and won't error out with > exceptions when specified inside the configuration file entries as > attribute values, e.g. > > |attributes(*,CKO_PRIVATE_KEY,CKK_RSA) = { *CKA_DECRYPT* = true }| > > These newly recognized PKCS#11 attributes (CKA_xxx), mechanisms > (CKM_xxx), key types (CKK_xxx), etc., are defined in > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java. > >> 2. using it as a provider in an application (need to know what >> algorithms are supported and what is disabled/enabled by default) > > Yes, these are the list of newly supported algorithms which I have added > to the CSR to address your earlier comment. None of them are disabled by > default. However, only when the underlying PKCS11 library also support > these, they will show up as available. > >> - Are there new attributes that are now supported than what are >> currently listed in Table 5.1 of the PKCS#11 Reference Guide?: >> https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9 > > If you are referring to attributes per the convention of PKCS#11 > reference guide, no new provider configuration attributes added. > However, new PKCS#11 attributes are recognized. We don't list recognized > PKCS#11 attributes in the reference guide as they are quite extensive. > PKCS11 header files define a long list of constants and depending on > what they are for, it may or may not lead to an error. For example, > unrecognized mechanisms and error codes will be accepted and their long > values are used instead. However, unrecognized PKCS#11 attributes > specified in the PKCS#11 provider configuration file will lead to exception. > >> If so, I think we should list them in the Specification section with >> the same details as in the Reference Guide. > > Given the above, I suppose that we don't need to list out all newly > supported PKCS#11 attributes? They do impact the user in some way, but > not sure if it's too much details. Perhaps we can just state that > whatever supported in the PKCS#11 v2.40 headers are now recognized by > SunPKCS11 provider. > >> - For the new algorithms, I would include those in the Specification >> section, in a format like table 5.3 in the PKCS#11 Reference Guide: >> https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-D3EF9023-7DDC-435D-9186-D2FD05674777 > > Sure, will do. > >> >> - I would include any new or changed defaults for attributes, etc. > > No new defaults or new attributes for PKCS11 provider configurations. > > Regards, > Valerie >> >> --Sean >> >>> >>> All, >>> >>> RFEs need to be integrated by 6/13. Can someone help reviewing this >>> soon? Mach5 run is clean. I up'ed the version of webrev to webrev.01 >>> due to the additional support for RSASSA-PSS signatures. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>> >>> Thanks, >>> Valerie >>> >>> On 5/22/2019 7:55 AM, Sean Mullan wrote: >>>> On 5/21/19 7:19 PM, Valerie Peng wrote: >>>>> >>>>> I thought we always file CSR when updating the version of external >>>>> standard, e.g. documenting the import aspect of JDK. >>>> >>>> Good point though I think that was primarily based on whether the >>>> external standard was referenced in the javadocs of the standard >>>> APIs or influenced the behavior of existing APIs in some way. I >>>> don't think PKCS#11 is referenced from any of our standard APIs, but >>>> since this new version does add support for additional crypto >>>> algorithms via the standard APIs that weren't previously available, >>>> that sounds like a good enough reason for filing the CSR. >>>> >>>> I would recommend adding some additional details to the CSR to list >>>> what new features/algorithms PKCS#11 v2.40 provides and which >>>> standard APIs those features are applicable to. It would also be >>>> helpful to add similar details to the main issue and the release >>>> note as there aren't many details about what features are in the new >>>> version. >>>> >>>> Thanks, >>>> Sean >>>> >>>>> >>>>> I'd love to close/withdraw the CSR if it's not needed. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 5/20/2019 12:11 PM, Sean Mullan wrote: >>>>>> On 5/17/19 3:56 PM, Valerie Peng wrote: >>>>>>> >>>>>>> Thanks Martin for helping me troubleshoot NSS side, I added PSS >>>>>>> support into PKCS11 provider and added PSS-specific regression >>>>>>> tests. Please find webrev updated as below: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>>>>>> >>>>>>> Can someone help review the CSR first as the approval may take a >>>>>>> week or so. >>>>>> >>>>>> I am curious why a CSR is needed? This seems to be strictly an >>>>>> implementation change with no compatibility effects. >>>>>> >>>>>> --Sean >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Anyone has time to review this? Besides the header files update, >>>>>>>> I added support for AES/GCM/NoPadding support. Ran into some >>>>>>>> strange NSS error with RSASSA-PSS signature mechanism, so I have >>>>>>>> not included the PSS signature impl here. >>>>>>>> >>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>>>>>>> >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> From valerie.peng at oracle.com Wed May 29 21:01:57 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 29 May 2019 14:01:57 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: References: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> <20ab970a-b262-7809-b04f-99af38a034a7@oracle.com> <3a4ec965-ccaf-4b15-2307-045f31f61c2e@oracle.com> <0a41b878-991c-47ec-6230-7dd45c8a7b7c@oracle.com> <6b9cd672-a87c-c88d-4cfa-e55dd3b207b3@oracle.com> <06fc7210-c090-d82c-3462-0f50fa8afc29@oracle.com> <3ce843bd-2f9a-4eee-4810-b2fb00857c60@oracle.com> Message-ID: <58f57209-2ebe-f9e6-76a2-4f178c0797a0@oracle.com> Thanks, I have unchecked the "Source" compatibility box. Will finalize the CSR and wait for Joe's comments if any. Valerie On 5/29/2019 1:12 PM, Sean Mullan wrote: > I agree with your comments below and the current CSR looks good so > I've added my name as Reviewer. One main comment is that I don't think > you should check the "Source" compatibility box. That would mean this > would be a source-incompatible change [1], which I don't think is > right. I don't think you should check any of the Compatibility boxes > as according to the "Compatibility Risk Description" box, you said > there is no compatibility risk. > > --Sean > > [1] https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility > > On 5/29/19 3:00 PM, Valerie Peng wrote: >> Hi Sean, >> >> Much thanks for the feedbacks. They are very helpful... I have >> updated the CSR per your feedbacks. >> >> https://bugs.openjdk.java.net/browse/JDK-8221442 >> >> Please find more replies inline below. >> >> On 5/28/2019 1:51 PM, Sean Mullan wrote: >> >>> Hi Valerie, >>> >>> On 5/24/19 6:37 PM, Valerie Peng wrote: >>>> Hi Sean, >>>> >>>> Thanks much for the suggestion. I have added the info on newly >>>> supported algorithms to both the CSR and the bug record. Please let >>>> me know if you have more comments. >>> >>> - In the Summary section, add a hyperlink to the PKCS#11 v2.40 >>> standard and the errata >> >> Done. >> >>> - In general, I would put more information in the Specification >>> section. I think attaching a patch of all the implementation changes >>> is a bit too raw and not that useful as it is hard to discern what >>> is specification and what is not (also the patch is not currently >>> attached and pointing to a webrev is not acceptable per CSR rules >>> since it may go away). Instead, I would avoid attaching a patch and >>> instead include descriptions of the new attributes and algorithms in >>> the Specification section in a format similar to that what is >>> documented in >>> https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html. >>> >>> Basically, I think this CSR should include the information that is >>> exposed or configurable to users outside of the implementation, >>> which I think can be described in 2 types of use cases: >> >> Yes, I think this is better. I was focusing on header file updates in >> original CSR. Agree that it'd be useful to list changes exposed by >> this RFE. >> >>> 1. configuring a PKCS#11 provider (need to know what attributes are >>> supported and their defaults) >> >> Well, PKCS11 reference guide uses the term "attribute" to refer to >> provider configuration options. This RFE did not add new provider >> configuration options. However, there is also attributes defined in >> PKCS#11 whose name starts with CKA_xxx. This RFE enhances SunPKCS11 >> provider to recognize new PKCS#11 attributes and won't error out with >> exceptions when specified inside the configuration file entries as >> attribute values, e.g. >> >> ??? |attributes(*,CKO_PRIVATE_KEY,CKK_RSA) = { *CKA_DECRYPT* = true }| >> >> These newly recognized PKCS#11 attributes (CKA_xxx), mechanisms >> (CKM_xxx), key types (CKK_xxx), etc., are defined in >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java. >> >>> 2. using it as a provider in an application (need to know what >>> algorithms are supported and what is disabled/enabled by default) >> >> Yes, these are the list of newly supported algorithms which I have >> added to the CSR to address your earlier comment. None of them are >> disabled by default. However, only when the underlying PKCS11 library >> also support these, they will show up as available. >> >>> - Are there new attributes that are now supported than what are >>> currently listed in Table 5.1 of the PKCS#11 Reference Guide?: >>> https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9 >> >> If you are referring to attributes per the convention of PKCS#11 >> reference guide, no new provider configuration attributes added. >> However, new PKCS#11 attributes are recognized. We don't list >> recognized PKCS#11 attributes in the reference guide as they are >> quite extensive. PKCS11 header files define a long list of constants >> and depending on what they are for, it may or may not lead to an >> error. For example, unrecognized mechanisms and error codes will be >> accepted and their long values are used instead. However, >> unrecognized PKCS#11 attributes specified in the PKCS#11 provider >> configuration file will lead to exception. >> >>> If so, I think we should list them in the Specification section with >>> the same details as in the Reference Guide. >> >> Given the above, I suppose that we don't need to list out all newly >> supported PKCS#11 attributes? They do impact the user in some way, >> but not sure if it's too much details. Perhaps we can just state that >> whatever supported in the PKCS#11 v2.40 headers are now recognized by >> SunPKCS11 provider. >> >>> - For the new algorithms, I would include those in the Specification >>> section, in a format like table 5.3 in the PKCS#11 Reference Guide: >>> https://docs.oracle.com/en/java/javase/12/security/pkcs11-reference-guide1.html#GUID-D3EF9023-7DDC-435D-9186-D2FD05674777 >> >> Sure, will do. >> >>> >>> - I would include any new or changed defaults for attributes, etc. >> >> No new defaults or new attributes for PKCS11 provider configurations. >> >> Regards, >> Valerie >>> >>> --Sean >>> >>>> >>>> All, >>>> >>>> RFEs need to be integrated by 6/13. Can someone help reviewing this >>>> soon? Mach5 run is clean. I up'ed the version of webrev to >>>> webrev.01 due to the additional support for RSASSA-PSS signatures. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 5/22/2019 7:55 AM, Sean Mullan wrote: >>>>> On 5/21/19 7:19 PM, Valerie Peng wrote: >>>>>> >>>>>> I thought we always file CSR when updating the version of >>>>>> external standard, e.g. documenting the import aspect of JDK. >>>>> >>>>> Good point though I think that was primarily based on whether the >>>>> external standard was referenced in the javadocs of the standard >>>>> APIs or influenced the behavior of existing APIs in some way. I >>>>> don't think PKCS#11 is referenced from any of our standard APIs, >>>>> but since this new version does add support for additional crypto >>>>> algorithms via the standard APIs that weren't previously >>>>> available, that sounds like a good enough reason for filing the CSR. >>>>> >>>>> I would recommend adding some additional details to the CSR to >>>>> list what new features/algorithms PKCS#11 v2.40 provides and which >>>>> standard APIs those features are applicable to. It would also be >>>>> helpful to add similar details to the main issue and the release >>>>> note as there aren't many details about what features are in the >>>>> new version. >>>>> >>>>> Thanks, >>>>> Sean >>>>> >>>>>> >>>>>> I'd love to close/withdraw the CSR if it's not needed. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> On 5/20/2019 12:11 PM, Sean Mullan wrote: >>>>>>> On 5/17/19 3:56 PM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Thanks Martin for helping me troubleshoot NSS side, I added PSS >>>>>>>> support into PKCS11 provider and added PSS-specific regression >>>>>>>> tests. Please find webrev updated as below: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~valeriep/8080462/webrev.01/ >>>>>>>> >>>>>>>> Can someone help review the CSR first as the approval may take >>>>>>>> a week or so. >>>>>>> >>>>>>> I am curious why a CSR is needed? This seems to be strictly an >>>>>>> implementation change with no compatibility effects. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> On 4/12/2019 5:05 PM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Anyone has time to review this? Besides the header files >>>>>>>>> update, I added support for AES/GCM/NoPadding support. Ran >>>>>>>>> into some strange NSS error with RSASSA-PSS signature >>>>>>>>> mechanism, so I have not included the PSS signature impl here. >>>>>>>>> >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ >>>>>>>>> >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> From weijun.wang at oracle.com Thu May 30 03:18:00 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 11:18:00 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190529172354.GH7457@twosigma.com> References: <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> Message-ID: Practically, if I always add the current realm to a name without a realm, and then always remove the realm if it's the current realm when calling InitiateSecurityContext, there should be no harm. If the realm was added by me, then removing it loses no info. If it was added by the user and it's the current realm, I hope when there is no realm InitiateSecurityContext will always try the local realm first. In fact, as I have observed, even if I don't remove the current realm from a name, InitiateSecurityContext is still doing the correct thing. I think the reason is that service/host@ and service/host at CURRENT.REALM are the same in a KDC-REQ, and even if there is a realm it still sets CANONICALIZE and accepts referrals. Here is the latest webrev http://cr.openjdk.java.net/~weijun/6722928/webrev.07/ Comparing to the last version (you can see in the interdiff.patch): 1. Rename KRB5_TRACE to SSPI_TRACE and always write to stderr. 2. No more guessing realm in get_full_name(). 3. Some cleanup. You can see that since I haven't retain the name type, I translate service at host to service/host right at the importing, and treat any name as KRB5 name later on. Thanks, Max > On May 30, 2019, at 1:23 AM, Nico Williams wrote: > > On Tue, May 28, 2019 at 08:55:22AM +0800, Weijun Wang wrote: >> Do you have any new comments? > > I should take one more look. > >> My major concern now is the canonicalization of service/host.dev.example.com >> to service/host.example.com at DEV.EXAMPLE.COM now. As Michael pointed out, it >> could well be service/host.example.com at EXAMPLE.COM. >> >> My suggestion now is to strip the realm part when InitSecurityContext >> is called. But when? If always, some information is lost if the realm >> is provided by the caller. So, how about we add >> "@WELLKNOWN:ORG.H5L.REFERALS-REALM" when it's a host-based service >> name? > > If a name was imported as GSS_C_NT_HOSTBASED_SERVICE, then there is no > realm. If it was imported as GSS_KRB5_NT_PRINCIPAL and there was no > realm, then there is no realm. If it was imported as > GSS_KRB5_NT_PRINCIPAL and there was a realm, then you should respect it > -- I say "should" because some applications will set it incorrectly, > notably the MSSQL JDBC driver. > > Now, as to SSPI, I don't know exactly how to tell it a realm to start at > (this would be the client principal's realm in the general case) or to > tell it to start at whatever realm Windows wants to (same thing), but > that's what you want. > > Nico > -- From weijun.wang at oracle.com Thu May 30 13:01:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 21:01:02 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) means when when the tool is changed, GENDATA_CACERTS will be called. Thanks, Max From david.holmes at oracle.com Thu May 30 13:11:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 23:11:16 +1000 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: Message-ID: Hi Max, Not a review :) On 30/05/2019 11:01 pm, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ > > Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. > > There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line > > $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) > > means when when the tool is changed, GENDATA_CACERTS will be called. I think you have set a dependency on the directory, not the files within it. If you look at make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk for example you'll see this rule: $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) but PROC_SRCS is defined as PROC_SRCS := $(filter %.java, $(call FindFiles, $(PROC_SRC_DIRS))) which is all the .java files in the src directory. David > Thanks, > Max > From weijun.wang at oracle.com Thu May 30 13:34:07 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 21:34:07 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: Message-ID: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Since I need to track all added, removed, updated files in that directory, I thought depending on the directory itself is more correct. If I use the FindFiles function, then if some files are removed the cacerts will not be rebuilt. --Max > On May 30, 2019, at 9:11 PM, David Holmes wrote: > > Hi Max, > > Not a review :) > > On 30/05/2019 11:01 pm, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >> means when when the tool is changed, GENDATA_CACERTS will be called. > > I think you have set a dependency on the directory, not the files within it. If you look at make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk for example you'll see this rule: > > $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) > > but PROC_SRCS is defined as > > PROC_SRCS := $(filter %.java, $(call FindFiles, $(PROC_SRC_DIRS))) > > which is all the .java files in the src directory. > > David > >> Thanks, >> Max From erik.joelsson at oracle.com Thu May 30 14:01:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 07:01:30 -0700 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: Hello Max, Looking in ToolsJdk.gmk, I realize that the BUILD_TOOLS variable was renamed back when we unified the repositories and is now called BUILD_TOOLS_JDK. It seems like I missed updating the references to this variable in the gendata dir. If you use the new variable name in the prerequisites list, you get a rebuild. Feel free to update the other references in make/gendata if you want to. In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: $(wildcard $(GENDATA_CACERTS_SRC)/*) This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. Some minor notes. The current recommended macro for creating the target directory in a recipe is $(call MakeTargetDir). For logical indent (Gendata-java.base.gmk:75 and Copy-java.base.gmk:173) please use 2 spaces [1]. I also think it would be good with a comment in Copy-java.base.gmk explaining that CACERTS_FILE is optionally set in configure to override the default cacerts which is otherwise generated in Gendata-java.base.gmk. Thanks, /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2019-05-30 06:34, Weijun Wang wrote: > Since I need to track all added, removed, updated files in that directory, I thought depending on the directory itself is more correct. If I use the FindFiles function, then if some files are removed the cacerts will not be rebuilt. > > --Max > >> On May 30, 2019, at 9:11 PM, David Holmes wrote: >> >> Hi Max, >> >> Not a review :) >> >> On 30/05/2019 11:01 pm, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >>> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >>> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >>> means when when the tool is changed, GENDATA_CACERTS will be called. >> I think you have set a dependency on the directory, not the files within it. If you look at make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk for example you'll see this rule: >> >> $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) >> >> but PROC_SRCS is defined as >> >> PROC_SRCS := $(filter %.java, $(call FindFiles, $(PROC_SRC_DIRS))) >> >> which is all the .java files in the src directory. >> >> David >> >>> Thanks, >>> Max From weijun.wang at oracle.com Thu May 30 15:32:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 May 2019 23:32:24 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: > On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: > > In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: > > $(wildcard $(GENDATA_CACERTS_SRC)/*) > > This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. But in my experiment, using the directory name does detect the file removal. Or, can I list *both* the files and the directory to get maximum awareness? --Max From erik.joelsson at oracle.com Thu May 30 17:34:32 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2019 10:34:32 -0700 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> On 2019-05-30 08:32, Weijun Wang wrote: > >> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: >> >> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: >> >> $(wildcard $(GENDATA_CACERTS_SRC)/*) >> >> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. > But in my experiment, using the directory name does detect the file removal. It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried. > Or, can I list *both* the files and the directory to get maximum awareness? The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives. /Erik From Nico.Williams at twosigma.com Thu May 30 19:09:31 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 30 May 2019 19:09:31 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> Message-ID: <20190530190931.GI7457@twosigma.com> On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote: > Practically, if I always add the current realm to a name without a realm, and > then always remove the realm if it's the current realm when calling > InitiateSecurityContext, there should be no harm. If the realm was added by > me, then removing it loses no info. If it was added by the user and it's the > current realm, I hope when there is no realm InitiateSecurityContext will > always try the local realm first. But then you have to keep track of whether you added it or not. Can you just use the empty realm like Heimdal and MIT do? > In fact, as I have observed, even if I don't remove the current realm > from a name, InitiateSecurityContext is still doing the correct thing. > I think the reason is that service/host@ and > service/host at CURRENT.REALM are the same in a KDC-REQ, and even if > there is a realm it still sets CANONICALIZE and accepts referrals. Ah, but if it's not the "current" realm? (What do you mean by "current" anyways?) > Here is the latest webrev > > http://cr.openjdk.java.net/~weijun/6722928/webrev.07/ > > Comparing to the last version (you can see in the interdiff.patch): > > 1. Rename KRB5_TRACE to SSPI_TRACE and always write to stderr. I would think JDK_SSPI_TRACE would be a better name... > 2. No more guessing realm in get_full_name(). Good. > 3. Some cleanup. > > You can see that since I haven't retain the name type, I translate > service at host to service/host right at the importing, and treat any > name as KRB5 name later on. Sure, because that's how SSPI works :) I'll probably not get to review till next week. Nico -- From christoph.langer at sap.com Thu May 30 21:31:36 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 30 May 2019 21:31:36 +0000 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> Message-ID: Hi Max, first of all, thanks for doing this enhancement. That'll really help in the future when downstream vendors merge in additional certificates (or remove some) like we do with SapMachine. Currently we have to resolve manually everytime cacerts is modified. As for the dependencies: if you want to handle removals of certificates you might want to consider having a target that counts files in make/data/cacerts and stores the count in an intermediate file. You can do the counting every time (e.g. phony target) but only update the count file if the number has changed. And the actual cacerts target would need to depend on the count file as well. However, I guess it would also be ok to just depend on all the files in make/data/cacerts. Looking forward to see your update with Erik's suggestions worked in. Some copyright years need to be updated as well. Thanks & Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of > Weijun Wang > Sent: Donnerstag, 30. Mai 2019 17:32 > To: Erik Joelsson > Cc: security-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: Re: RFR 8193255: Root Certificates should be stored in text format > and assembled at build time > > > > > On May 30, 2019, at 10:01 PM, Erik Joelsson > wrote: > > > > In my experience, using directories for dependencies in make does not > work well. Since all the files in make/data/cacerts are in a flat structure, I > would recommend expressing the prerequisites as: > > > > $(wildcard $(GENDATA_CACERTS_SRC)/*) > > > > This will not cover the case where a file is removed, but that case is rarely > handled well in make based build systems. > > But in my experiment, using the directory name does detect the file removal. > > Or, can I list *both* the files and the directory to get maximum awareness? > > --Max From sean.mullan at oracle.com Thu May 30 22:51:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 30 May 2019 18:51:54 -0400 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: Message-ID: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. --Sean On 5/30/19 9:01 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ > > Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. > > There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line > > $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) > > means when when the tool is changed, GENDATA_CACERTS will be called. > > Thanks, > Max > From xuelei.fan at oracle.com Thu May 30 23:15:58 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 30 May 2019 16:15:58 -0700 Subject: RFR: CSR for 8211018 Session Resumption without Server-Side State In-Reply-To: References: <5cb5543c-7003-479d-4b5f-c9c7aeb73d6a@oracle.com> Message-ID: <63d9962e-44c1-644e-ae8b-90363728cb4b@oracle.com> The latest CSR looks good to me. Thanks, Xuelei On 5/28/2019 11:55 AM, Anthony Scarpino wrote: > The CSR has been updated with what I believe address the mentioned issues. > > Tony > > On 5/21/19 4:24 PM, Anthony Scarpino wrote: >> Hi All, >> >> Please review the CSR for the stateless Server Side >> https://bugs.openjdk.java.net/browse/JDK-8223922 >> >> thanks >> >> Tony > From weijun.wang at oracle.com Fri May 31 00:49:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 08:49:24 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> References: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> Message-ID: <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> Sure. How many info do you want to see? I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert itself. So, I'm thinking of Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US Serial number: 50946cec18ead59c4dd597ef758fa0ad Valid from: 1 Nov 2004 17:14:04 GMT until: 1 Jan 2035 05:37:19 GMT Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Is that OK? Thanks, Max p.s. `keytool -printcert` shows validity in local timezone. Does not look good to me. > On May 31, 2019, at 6:51 AM, Sean Mullan wrote: > > One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. > > --Sean > > On 5/30/19 9:01 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >> means when when the tool is changed, GENDATA_CACERTS will be called. >> Thanks, >> Max From weijun.wang at oracle.com Fri May 31 03:00:36 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 11:00:36 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> Message-ID: New webrev at https://cr.openjdk.java.net/~weijun/8193255/webrev.01 Changes: 1. Textual info at the beginning of each cert 2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir Thanks, Max > On May 31, 2019, at 1:34 AM, Erik Joelsson wrote: > > On 2019-05-30 08:32, Weijun Wang wrote: >> >>> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: >>> >>> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: >>> >>> $(wildcard $(GENDATA_CACERTS_SRC)/*) >>> >>> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. >> But in my experiment, using the directory name does detect the file removal. > > It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried. > >> Or, can I list *both* the files and the directory to get maximum awareness? > > The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives. > > /Erik > From weijun.wang at oracle.com Fri May 31 03:32:49 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 11:32:49 +0800 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format Message-ID: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Please review the CSR at https://bugs.openjdk.java.net/browse/JDK-8224891 (Oh, I hate the CSR having a different bug id.) Basically, with this change, the cacerts file can be loaded with KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or KeyStore.getInstance(new File("cacerts"), null or anything) so hopefully all your old code should still work. I've also opened another RFE [1] that intends to find a different way to tag jdkCA entries in cacerts other than appending "[jdk]" to the alias. Thanks, Max [1] https://bugs.openjdk.java.net/browse/JDK-8225099 From christoph.langer at sap.com Fri May 31 08:23:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 08:23:19 +0000 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> Message-ID: Hi Max, this looks all good to me now :) Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of > Weijun Wang > Sent: Freitag, 31. Mai 2019 05:01 > To: Erik Joelsson > Cc: security-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: Re: RFR 8193255: Root Certificates should be stored in text format > and assembled at build time > > New webrev at > > https://cr.openjdk.java.net/~weijun/8193255/webrev.01 > > Changes: > > 1. Textual info at the beginning of each cert > > 2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of > dir > > Thanks, > Max > > > On May 31, 2019, at 1:34 AM, Erik Joelsson > wrote: > > > > On 2019-05-30 08:32, Weijun Wang wrote: > >> > >>> On May 30, 2019, at 10:01 PM, Erik Joelsson > wrote: > >>> > >>> In my experience, using directories for dependencies in make does not > work well. Since all the files in make/data/cacerts are in a flat structure, I > would recommend expressing the prerequisites as: > >>> > >>> $(wildcard $(GENDATA_CACERTS_SRC)/*) > >>> > >>> This will not cover the case where a file is removed, but that case is > rarely handled well in make based build systems. > >> But in my experiment, using the directory name does detect the file > removal. > > > > It believe that worked well on your machine, but directory timestamp > updates are file system dependent. I'm not sure we can count on all > filesystems to accurately reflect time stamps based on file modification. It's > also possible that an OS would touch directory timestamps for other reasons, > which should not affect the build. I haven't tried having source directories as > prerequisites before, so I simply don't know how reliable it is. My experience > is rather with directories as targets, which certainly doesn't work. If you > verified that it worked as expected on all supported OSes, I would be less > worried. > > > >> Or, can I list *both* the files and the directory to get maximum > awareness? > > > > The directory modification time will usually not change when a file in it is > modified, only when adding or removing files (and possibly some other > operations), so adding the files is certainly a must. If you go with both, then I > would just be worried about potential false positives. > > > > /Erik > > From christoph.langer at sap.com Fri May 31 08:27:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 08:27:35 +0000 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: Hi Max, I've already made some updates to the wording in the CSR. In the specification section, it should probably also not mention the source location src/java.base/share/lib/security/cacerts as it is about to be eliminated by JDK-8193255. It should rather refer to /lib/security/cacerts, I think. Best regards Christoph > -----Original Message----- > From: security-dev On Behalf Of > Weijun Wang > Sent: Freitag, 31. Mai 2019 05:33 > To: security-dev at openjdk.java.net > Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less > PKCS12 format > > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8224891 > > (Oh, I hate the CSR having a different bug id.) > > Basically, with this change, the cacerts file can be loaded with > > KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or > KeyStore.getInstance(new File("cacerts"), null or anything) > > so hopefully all your old code should still work. > > I've also opened another RFE [1] that intends to find a different way to tag > jdkCA entries in cacerts other than appending "[jdk]" to the alias. > > Thanks, > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8225099 From weijun.wang at oracle.com Fri May 31 09:43:06 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 17:43:06 +0800 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: <60BF319C-BDA5-4C22-B36C-B86894042A6C@oracle.com> It's not easy to find out the word difference after a CSR edit. But you changed everyone (yes, everyone) has been loading cacerts with a null password and they are able to read all certificate inside. to everyone (yes, everyone) who loads cacerts with a null password is able to read all certificates inside. I *did* mean that *everyone* is using the null password. Did you not? --Max > On May 31, 2019, at 4:27 PM, Langer, Christoph wrote: > > Hi Max, > > I've already made some updates to the wording in the CSR. > > In the specification section, it should probably also not mention the source location src/java.base/share/lib/security/cacerts as it is about to be eliminated by JDK-8193255. It should rather refer to /lib/security/cacerts, I think. > > Best regards > Christoph > >> -----Original Message----- >> From: security-dev On Behalf Of >> Weijun Wang >> Sent: Freitag, 31. Mai 2019 05:33 >> To: security-dev at openjdk.java.net >> Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less >> PKCS12 format >> >> Please review the CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8224891 >> >> (Oh, I hate the CSR having a different bug id.) >> >> Basically, with this change, the cacerts file can be loaded with >> >> KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or >> KeyStore.getInstance(new File("cacerts"), null or anything) >> >> so hopefully all your old code should still work. >> >> I've also opened another RFE [1] that intends to find a different way to tag >> jdkCA entries in cacerts other than appending "[jdk]" to the alias. >> >> Thanks, >> Max >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8225099 > From weijun.wang at oracle.com Fri May 31 14:24:40 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 22:24:40 +0800 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: <60BF319C-BDA5-4C22-B36C-B86894042A6C@oracle.com> References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> <60BF319C-BDA5-4C22-B36C-B86894042A6C@oracle.com> Message-ID: <5CE65825-B6A5-4414-B82E-5A718415FD23@oracle.com> Well, at least "almost everyone". The "everyone" sounds contradict with those "existing applications that uses the hardcoded password". --Max > On May 31, 2019, at 5:43 PM, Weijun Wang wrote: > > It's not easy to find out the word difference after a CSR edit. > > But you changed > > everyone (yes, everyone) has been loading cacerts with a null password and they are able to read all certificate inside. > > to > > everyone (yes, everyone) who loads cacerts with a null password is able to read all certificates inside. > > I *did* mean that *everyone* is using the null password. Did you not? > > --Max > > >> On May 31, 2019, at 4:27 PM, Langer, Christoph wrote: >> >> Hi Max, >> >> I've already made some updates to the wording in the CSR. >> >> In the specification section, it should probably also not mention the source location src/java.base/share/lib/security/cacerts as it is about to be eliminated by JDK-8193255. It should rather refer to /lib/security/cacerts, I think. >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: security-dev On Behalf Of >>> Weijun Wang >>> Sent: Freitag, 31. Mai 2019 05:33 >>> To: security-dev at openjdk.java.net >>> Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less >>> PKCS12 format >>> >>> Please review the CSR at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224891 >>> >>> (Oh, I hate the CSR having a different bug id.) >>> >>> Basically, with this change, the cacerts file can be loaded with >>> >>> KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or >>> KeyStore.getInstance(new File("cacerts"), null or anything) >>> >>> so hopefully all your old code should still work. >>> >>> I've also opened another RFE [1] that intends to find a different way to tag >>> jdkCA entries in cacerts other than appending "[jdk]" to the alias. >>> >>> Thanks, >>> Max >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8225099 >> > From christoph.langer at sap.com Fri May 31 14:48:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 14:48:21 +0000 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: <60BF319C-BDA5-4C22-B36C-B86894042A6C@oracle.com> References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> <60BF319C-BDA5-4C22-B36C-B86894042A6C@oracle.com> Message-ID: Hi Max, > But you changed > > everyone (yes, everyone) has been loading cacerts with a null password > and they are able to read all certificate inside. > > to > > everyone (yes, everyone) who loads cacerts with a null password is able to > read all certificates inside. > > I *did* mean that *everyone* is using the null password. Did you not? > Well, I wanted to phrase that everyone who's currently using a null password is still able to read all the certificates. If that's not what you're meaning, please change it back. Best, Christoph From weijun.wang at oracle.com Fri May 31 14:48:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 May 2019 22:48:19 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190530190931.GI7457@twosigma.com> References: <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190530190931.GI7457@twosigma.com> Message-ID: > On May 31, 2019, at 3:09 AM, Nico Williams wrote: > > On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote: >> Practically, if I always add the current realm to a name without a realm, and >> then always remove the realm if it's the current realm when calling >> InitiateSecurityContext, there should be no harm. If the realm was added by >> me, then removing it loses no info. If it was added by the user and it's the >> current realm, I hope when there is no realm InitiateSecurityContext will >> always try the local realm first. > > But then you have to keep track of whether you added it or not. No I don't. I meant to always remove the realm part if it's the default realm when passing to InitiateSecurityContext. > Can you > just use the empty realm like Heimdal and MIT do? This is for export(), where they use "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I hesitate to introduce it. > >> In fact, as I have observed, even if I don't remove the current realm >> from a name, InitiateSecurityContext is still doing the correct thing. >> I think the reason is that service/host@ and >> service/host at CURRENT.REALM are the same in a KDC-REQ, and even if >> there is a realm it still sets CANONICALIZE and accepts referrals. > > Ah, but if it's not the "current" realm? (What do you mean by "current" > anyways?) Current is default, or USERDNSDOMAIN. Then I won't remove it and InitiateSecurityContext will use it. > >> Here is the latest webrev >> >> http://cr.openjdk.java.net/~weijun/6722928/webrev.07/ >> >> Comparing to the last version (you can see in the interdiff.patch): >> >> 1. Rename KRB5_TRACE to SSPI_TRACE and always write to stderr. > > I would think JDK_SSPI_TRACE would be a better name... Yes, I can. > >> 2. No more guessing realm in get_full_name(). > > Good. > >> 3. Some cleanup. >> >> You can see that since I haven't retain the name type, I translate >> service at host to service/host right at the importing, and treat any >> name as KRB5 name later on. > > Sure, because that's how SSPI works :) > > I'll probably not get to review till next week. Thanks, Max > > Nico > -- From christoph.langer at sap.com Fri May 31 15:09:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 15:09:29 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: Hi Martin, thanks for the review. Makes sense to take the fix regarding the overflow check along. I requested approval for JDK-8217344, too, and will push both patches together. Best regards Christoph > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 31. Mai 2019 14:40 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: security-dev > Subject: RE: [11u] RFR: 8208698: Improved ECC Implementation > > Hi Christoph, > > looks like quite some manual resolution just because of a small conflicting > change in one file. > Backport looks good, but please backport it together with JDK-8217344. > After that, ECDHKeyAgreement.java should be identical to the jdk13 version. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Dienstag, 28. Mai 2019 09:21 > > To: jdk-updates-dev at openjdk.java.net > > Cc: security-dev > > Subject: [11u] RFR: 8208698: Improved ECC Implementation > > > > Hi, > > > > please review this backport of JDK-8208698: Improved ECC > Implementation. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ > > > > The patch did not apply cleanly because there were conflicts in > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java > > due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. > > Unfortunately, JDK-8205476 can not be downported as prerequisite > because > > it brings a behavioral change and is associated with a CSR. So I resolved the > > rejects manually. I add the rejects below. > > > > Thanks > > Christoph > > > > > > --- ECDHKeyAgreement.java > > +++ ECDHKeyAgreement.java > > @@ -99,42 +104,74 @@ > > ("Key must be a PublicKey with algorithm EC"); > > } > > - ECPublicKey ecKey = (ECPublicKey)key; > > - ECParameterSpec params = ecKey.getParams(); > > + this.publicKey = (ECPublicKey) key; > > - if (ecKey instanceof ECPublicKeyImpl) { > > - publicValue = ((ECPublicKeyImpl)ecKey).getEncodedPublicValue(); > > - } else { // instanceof ECPublicKey > > - publicValue = > > - ECUtil.encodePoint(ecKey.getW(), params.getCurve()); > > - } > > + ECParameterSpec params = publicKey.getParams(); > > int keyLenBits = params.getCurve().getField().getFieldSize(); > > secretLen = (keyLenBits + 7) >> 3; > > return null; > > } > > + private static void validateCoordinate(BigInteger c, BigInteger mod) { > > + if (c.compareTo(BigInteger.ZERO) < 0) { > > + throw new ProviderException("invalid coordinate"); > > + } > > + > > + if (c.compareTo(mod) >= 0) { > > + throw new ProviderException("invalid coordinate"); > > + } > > + } > > + > > + /* > > + * Check whether a public key is valid. Throw ProviderException > > + * if it is not valid or could not be validated. > > + */ > > + private static void validate(ECOperations ops, ECPublicKey key) { > > + > > + // ensure that integers are in proper range > > + BigInteger x = key.getW().getAffineX(); > > + BigInteger y = key.getW().getAffineY(); > > + > > + BigInteger p = ops.getField().getSize(); > > + validateCoordinate(x, p); > > + validateCoordinate(y, p); > > + > > + // ensure the point is on the curve > > + EllipticCurve curve = key.getParams().getCurve(); > > + BigInteger rhs = x.modPow(BigInteger.valueOf(3), > p).add(curve.getA() > > + .multiply(x)).add(curve.getB()).mod(p); > > + BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); > > + if (!rhs.equals(lhs)) { > > + throw new ProviderException("point is not on curve"); > > + } > > + > > + // check the order of the point > > + ImmutableIntegerModuloP xElem = ops.getField().getElement(x); > > + ImmutableIntegerModuloP yElem = ops.getField().getElement(y); > > + AffinePoint affP = new AffinePoint(xElem, yElem); > > + byte[] order = key.getParams().getOrder().toByteArray(); > > + ArrayUtil.reverse(order); > > + Point product = ops.multiply(affP, order); > > + if (!ops.isNeutral(product)) { > > + throw new ProviderException("point has incorrect order"); > > + } > > + > > + } > > + > > // see JCE spec > > @Override > > protected byte[] engineGenerateSecret() throws IllegalStateException { > > - if ((privateKey == null) || (publicValue == null)) { > > + if ((privateKey == null) || (publicKey == null)) { > > throw new IllegalStateException("Not initialized correctly"); > > } > > - byte[] s = privateKey.getS().toByteArray(); > > - byte[] encodedParams = // DER OID > > - ECUtil.encodeECParameterSpec(null, privateKey.getParams()); > > - > > - try { > > - > > - byte[] result = deriveKey(s, publicValue, encodedParams); > > - publicValue = null; > > - return result; > > - > > - } catch (GeneralSecurityException e) { > > - throw new ProviderException("Could not derive key", e); > > - } > > - > > + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); > > + byte[] result = resultOpt.orElseGet( > > + () -> deriveKeyNative(privateKey, publicKey) > > + ); > > + publicKey = null; > > + return result; > > } > > // see JCE spec From sean.mullan at oracle.com Fri May 31 15:15:07 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 May 2019 11:15:07 -0400 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> References: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> Message-ID: <7ac9538f-664a-7e14-4bd6-513749339f8f@oracle.com> On 5/30/19 8:49 PM, Weijun Wang wrote: > Sure. How many info do you want to see? > > I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert itself. > > So, I'm thinking of > > Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US > Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US > Serial number: 50946cec18ead59c4dd597ef758fa0ad > Valid from: 1 Nov 2004 17:14:04 GMT until: 1 Jan 2035 05:37:19 GMT > Signature algorithm name: SHA1withRSA > Subject Public Key Algorithm: 2048-bit RSA key > Version: 3 > > Is that OK? This is good. Did you use keytool to emit those fields? It might make sense to add a brief README in this directory with instructions or a code snippet so that the next time we add a cert we know what to include at the top for consistency. Thanks, Sean > > Thanks, > Max > > p.s. `keytool -printcert` shows validity in local timezone. Does not look good to me. > >> On May 31, 2019, at 6:51 AM, Sean Mullan wrote: >> >> One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. >> >> --Sean >> >> On 5/30/19 9:01 AM, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >>> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >>> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >>> means when when the tool is changed, GENDATA_CACERTS will be called. >>> Thanks, >>> Max > From Nico.Williams at twosigma.com Fri May 31 15:42:09 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 31 May 2019 15:42:09 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190530190931.GI7457@twosigma.com> Message-ID: <20190531154209.GJ7457@twosigma.com> On Fri, May 31, 2019 at 10:48:19PM +0800, Weijun Wang wrote: > > On May 31, 2019, at 3:09 AM, Nico Williams wrote: > > Can you > > just use the empty realm like Heimdal and MIT do? > > This is for export(), where they use "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I > hesitate to introduce it. Heimdal defines that, but doesn't use it. MIT doesn't even define it. > > Ah, but if it's not the "current" realm? (What do you mean by "current" > > anyways?) > > Current is default, or USERDNSDOMAIN. > > Then I won't remove it and InitiateSecurityContext will use it. Hmm, ok. > > I would think JDK_SSPI_TRACE would be a better name... > > Yes, I can. OK. Nico -- From erik.joelsson at oracle.com Fri May 31 16:17:42 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2019 09:17:42 -0700 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: References: <485BBE8F-35F2-4D5E-A6D3-BAC073737967@oracle.com> <3b57c56c-8b00-f9d0-aecc-4877fb3de97a@oracle.com> Message-ID: <7cf607f6-cbfa-ed74-a02b-b780d65d7d30@oracle.com> This looks good to me, and thanks for fixing the other instances of BUILD_TOOLS_JDK! /Erik On 2019-05-30 20:00, Weijun Wang wrote: > New webrev at > > https://cr.openjdk.java.net/~weijun/8193255/webrev.01 > > Changes: > > 1. Textual info at the beginning of each cert > > 2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir > > Thanks, > Max > >> On May 31, 2019, at 1:34 AM, Erik Joelsson wrote: >> >> On 2019-05-30 08:32, Weijun Wang wrote: >>>> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote: >>>> >>>> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as: >>>> >>>> $(wildcard $(GENDATA_CACERTS_SRC)/*) >>>> >>>> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems. >>> But in my experiment, using the directory name does detect the file removal. >> It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried. >> >>> Or, can I list *both* the files and the directory to get maximum awareness? >> The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives. >> >> /Erik >> From sean.mullan at oracle.com Fri May 31 18:41:52 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 May 2019 14:41:52 -0400 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: <0801f9ba-c6ff-7ee9-9838-9afa809ee465@oracle.com> Rename it to "Migrate cacerts keystore to password-less PKCS12 format". In the Problem section, you may also want to add something like: - the certificates are public - The integrity protection is not really necessary since the cacerts file is part of the installed JDK, which should be installed using a secure mechanism and protected appropriately on-disk from modification. In the Solution section, you should probably mention that if the "keystore.type.compat" security property is set to false, then the risk of breakage would be high, but we do not believe that this property is changed very often. --Sean On 5/30/19 11:32 PM, Weijun Wang wrote: > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8224891 > > (Oh, I hate the CSR having a different bug id.) > > Basically, with this change, the cacerts file can be loaded with > > KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or > KeyStore.getInstance(new File("cacerts"), null or anything) > > so hopefully all your old code should still work. > > I've also opened another RFE [1] that intends to find a different way to tag jdkCA entries in cacerts other than appending "[jdk]" to the alias. > > Thanks, > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8225099 > From weijun.wang at oracle.com Fri May 31 23:43:42 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 1 Jun 2019 07:43:42 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190531154209.GJ7457@twosigma.com> References: <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190530190931.GI7457@twosigma.com> <20190531154209.GJ7457@twosigma.com> Message-ID: > On May 31, 2019, at 11:42 PM, Nico Williams wrote: > > On Fri, May 31, 2019 at 10:48:19PM +0800, Weijun Wang wrote: >>> On May 31, 2019, at 3:09 AM, Nico Williams wrote: >>> Can you >>> just use the empty realm like Heimdal and MIT do? >> >> This is for export(), where they use "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I >> hesitate to introduce it. > > Heimdal defines that, but doesn't use it. MIT doesn't even define it. I thought I saw it with MIT but maybe I got the library setting wrong. Anyway, using macOS's builtin krb5 (is that a Heimdal fork?), export() returns 0000: 04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 00 ......*.H....... 0010: 00 00 31 73 65 72 76 69 63 65 2F 68 6F 73 74 2E ..1service/host. 0020: 6B 33 78 40 57 45 4C 4C 4B 4E 4F 57 4E 3A 4F 52 k3x at WELLKNOWN:OR 0030: 47 2E 48 35 4C 2E 52 45 46 45 52 41 4C 53 2D 52 G.H5L.REFERALS-R 0040: 45 41 4C 4D EALM --Max > >>> Ah, but if it's not the "current" realm? (What do you mean by "current" >>> anyways?) >> >> Current is default, or USERDNSDOMAIN. >> >> Then I won't remove it and InitiateSecurityContext will use it. > > Hmm, ok. > >>> I would think JDK_SSPI_TRACE would be a better name... >> >> Yes, I can. > > OK. > > Nico > -- From weijun.wang at oracle.com Fri May 31 23:47:14 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 1 Jun 2019 07:47:14 +0800 Subject: RFR 8193255: Root Certificates should be stored in text format and assembled at build time In-Reply-To: <7ac9538f-664a-7e14-4bd6-513749339f8f@oracle.com> References: <60fb9ad0-19f3-52d0-b5b4-7b5808a1b4e2@oracle.com> <85D686DF-0C04-4666-922D-50D41DFB0621@oracle.com> <7ac9538f-664a-7e14-4bd6-513749339f8f@oracle.com> Message-ID: > On May 31, 2019, at 11:15 PM, Sean Mullan wrote: > > On 5/30/19 8:49 PM, Weijun Wang wrote: >> Sure. How many info do you want to see? >> I can prepend `keytool -printcert` but that's too much. At least I think the extensions part is not needed. Also, I don't wish people reading the fingerprint inside as genuine and does not calculate it from the cert itself. >> So, I'm thinking of >> Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US >> Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US >> Serial number: 50946cec18ead59c4dd597ef758fa0ad >> Valid from: 1 Nov 2004 17:14:04 GMT until: 1 Jan 2035 05:37:19 GMT >> Signature algorithm name: SHA1withRSA >> Subject Public Key Algorithm: 2048-bit RSA key >> Version: 3 >> Is that OK? > > This is good. Did you use keytool to emit those fields? Yes. > It might make sense to add a brief README in this directory with instructions or a code snippet so that the next time we add a cert we know what to include at the top for consistency. OK, so it might contain: -----START----- Each file in this directory (except for this README) contains a CA certificate in PEM format. It can be generated with keytool -J-Duser.timezone=GMT -printcert -file ca.cert | sed -n '1,4p;8,10p' keytool -printcert -file ca.cert -rfc Please note the textual comment is just a suggestion and not arbitrary. After any change in this directory, please remember to update the content of `test/jdk/sun/security/lib/cacerts/VerifyCACerts.java` as well. -----END----- And I'll need to skip this README file in the build tool. --Max > > Thanks, > Sean > >> Thanks, >> Max >> p.s. `keytool -printcert` shows validity in local timezone. Does not look good to me. >>> On May 31, 2019, at 6:51 AM, Sean Mullan wrote: >>> >>> One suggestion is to put a printable form of the contents of the certificate at the top of each of the PEM files. It would be nice as a quick-look to see what is in the certificate. Of course, you can also use keytool -printcert to do that, but if I am just perusing the source code via a browser or something like that, it would be nice to not have to do that. >>> >>> --Sean >>> >>> On 5/30/19 9:01 AM, Weijun Wang wrote: >>>> Please take a review at >>>> http://cr.openjdk.java.net/~weijun/8193255/webrev.00/ >>>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files for all certs inside the original cacerts. >>>> There is one thing I cannot get correct. If I update the GenerateCacerts.java file and rerun make, the cacerts file is unchanged. I thought the following line >>>> $(GENDATA_CACERTS): $(BUILD_TOOLS) $(GENDATA_CACERTS_SRC) >>>> means when when the tool is changed, GENDATA_CACERTS will be called. >>>> Thanks, >>>> Max From hohensee at amazon.com Fri May 24 16:41:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 16:41:52 +0000 Subject: [11u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 Message-ID: <1D2BF80D-85BF-4A16-B5C4-01984B48CCB9@amazon.com> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224765 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224766 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 11u. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri May 24 17:04:44 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 17:04:44 +0000 Subject: [11u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: <1D2BF80D-85BF-4A16-B5C4-01984B48CCB9@amazon.com> References: <1D2BF80D-85BF-4A16-B5C4-01984B48CCB9@amazon.com> Message-ID: <44A82E47-193D-4DD9-90AE-5A13DC9E9BF6@amazon.com> Add Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 ?On 5/24/19, 9:42 AM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224765 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224766 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 11u. Thanks, Paul From hohensee at amazon.com Fri May 24 17:09:00 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 17:09:00 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 Message-ID: Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224769 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224770 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 8u net of line numbers and file locations. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Fri May 31 12:39:34 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 31 May 2019 12:39:34 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: Hi Christoph, looks like quite some manual resolution just because of a small conflicting change in one file. Backport looks good, but please backport it together with JDK-8217344. After that, ECDHKeyAgreement.java should be identical to the jdk13 version. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Dienstag, 28. Mai 2019 09:21 > To: jdk-updates-dev at openjdk.java.net > Cc: security-dev > Subject: [11u] RFR: 8208698: Improved ECC Implementation > > Hi, > > please review this backport of JDK-8208698: Improved ECC Implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ > > The patch did not apply cleanly because there were conflicts in > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java > due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. > Unfortunately, JDK-8205476 can not be downported as prerequisite because > it brings a behavioral change and is associated with a CSR. So I resolved the > rejects manually. I add the rejects below. > > Thanks > Christoph > > > --- ECDHKeyAgreement.java > +++ ECDHKeyAgreement.java > @@ -99,42 +104,74 @@ > ("Key must be a PublicKey with algorithm EC"); > } > - ECPublicKey ecKey = (ECPublicKey)key; > - ECParameterSpec params = ecKey.getParams(); > + this.publicKey = (ECPublicKey) key; > - if (ecKey instanceof ECPublicKeyImpl) { > - publicValue = ((ECPublicKeyImpl)ecKey).getEncodedPublicValue(); > - } else { // instanceof ECPublicKey > - publicValue = > - ECUtil.encodePoint(ecKey.getW(), params.getCurve()); > - } > + ECParameterSpec params = publicKey.getParams(); > int keyLenBits = params.getCurve().getField().getFieldSize(); > secretLen = (keyLenBits + 7) >> 3; > return null; > } > + private static void validateCoordinate(BigInteger c, BigInteger mod) { > + if (c.compareTo(BigInteger.ZERO) < 0) { > + throw new ProviderException("invalid coordinate"); > + } > + > + if (c.compareTo(mod) >= 0) { > + throw new ProviderException("invalid coordinate"); > + } > + } > + > + /* > + * Check whether a public key is valid. Throw ProviderException > + * if it is not valid or could not be validated. > + */ > + private static void validate(ECOperations ops, ECPublicKey key) { > + > + // ensure that integers are in proper range > + BigInteger x = key.getW().getAffineX(); > + BigInteger y = key.getW().getAffineY(); > + > + BigInteger p = ops.getField().getSize(); > + validateCoordinate(x, p); > + validateCoordinate(y, p); > + > + // ensure the point is on the curve > + EllipticCurve curve = key.getParams().getCurve(); > + BigInteger rhs = x.modPow(BigInteger.valueOf(3), p).add(curve.getA() > + .multiply(x)).add(curve.getB()).mod(p); > + BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); > + if (!rhs.equals(lhs)) { > + throw new ProviderException("point is not on curve"); > + } > + > + // check the order of the point > + ImmutableIntegerModuloP xElem = ops.getField().getElement(x); > + ImmutableIntegerModuloP yElem = ops.getField().getElement(y); > + AffinePoint affP = new AffinePoint(xElem, yElem); > + byte[] order = key.getParams().getOrder().toByteArray(); > + ArrayUtil.reverse(order); > + Point product = ops.multiply(affP, order); > + if (!ops.isNeutral(product)) { > + throw new ProviderException("point has incorrect order"); > + } > + > + } > + > // see JCE spec > @Override > protected byte[] engineGenerateSecret() throws IllegalStateException { > - if ((privateKey == null) || (publicValue == null)) { > + if ((privateKey == null) || (publicKey == null)) { > throw new IllegalStateException("Not initialized correctly"); > } > - byte[] s = privateKey.getS().toByteArray(); > - byte[] encodedParams = // DER OID > - ECUtil.encodeECParameterSpec(null, privateKey.getParams()); > - > - try { > - > - byte[] result = deriveKey(s, publicValue, encodedParams); > - publicValue = null; > - return result; > - > - } catch (GeneralSecurityException e) { > - throw new ProviderException("Could not derive key", e); > - } > - > + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); > + byte[] result = resultOpt.orElseGet( > + () -> deriveKeyNative(privateKey, publicKey) > + ); > + publicKey = null; > + return result; > } > // see JCE spec