From xuelei.fan at oracle.com Sun Mar 1 16:16:49 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 1 Mar 2020 08:16:49 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> Message-ID: On 2/28/2020 4:24 PM, Xuelei Fan wrote: > SSLSocketInputRecord: > ? 52???? private byte[] inputBuffer = new byte[maxRecordSize]; > > Would you mind consider an improvement to use less memory? I think more about it. You previous idea may be better, which uses an additional buffer for caching. Maybe, you can improve it by using the cache only on timeout, and clear it once the connection get to normal. Thanks, Xuelei From RAJAN.HALADE at ORACLE.COM Mon Mar 2 06:45:12 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Sun, 1 Mar 2020 22:45:12 -0800 Subject: RFR: 8225130: Add exception for expiring Comodo roots to VerifyCACerts test Message-ID: <92677BAA-049C-44BB-8ABA-0391A7CBDBA6@ORACLE.COM> May I request you to review this fix to test VerifyCACerts. diff -r 4a5a7dc9d05c test/jdk/sun/security/lib/cacerts/VerifyCACerts.java --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Sun Mar 01 17:36:03 2020 -0800 +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Sun Mar 01 22:42:59 2020 -0800 @@ -261,6 +261,12 @@ add("utnuserfirstobjectca [jdk]"); // Valid until: Tue May 26 00:00:00 GMT 2020 add("keynectisrootca [jdk]"); + // Valid until: Sat May 30 10:38:31 GMT 2020 + add("addtrustexternalca [jdk]"); + // Valid until: Sat May 30 10:48:38 GMT 2020 + add("addtrustclass1ca [jdk]"); + // Valid until: Sat May 30 10:44:50 GMT 2020 + add("addtrustqualifiedca [jdk]"); } }; Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 2 06:59:09 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 2 Mar 2020 14:59:09 +0800 Subject: RFR: 8225130: Add exception for expiring Comodo roots to VerifyCACerts test In-Reply-To: <92677BAA-049C-44BB-8ABA-0391A7CBDBA6@ORACLE.COM> References: <92677BAA-049C-44BB-8ABA-0391A7CBDBA6@ORACLE.COM> Message-ID: This looks fine to me. Thanks, Max > On Mar 2, 2020, at 2:45 PM, Rajan Halade wrote: > > May I request you to review this fix to test VerifyCACerts. > > diff -r 4a5a7dc9d05c test/jdk/sun/security/lib/cacerts/VerifyCACerts.java > --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Sun Mar 01 17:36:03 2020 -0800 > +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Sun Mar 01 22:42:59 2020 -0800 > @@ -261,6 +261,12 @@ > add("utnuserfirstobjectca [jdk]"); > // Valid until: Tue May 26 00:00:00 GMT 2020 > add("keynectisrootca [jdk]"); > + // Valid until: Sat May 30 10:38:31 GMT 2020 > + add("addtrustexternalca [jdk]"); > + // Valid until: Sat May 30 10:48:38 GMT 2020 > + add("addtrustclass1ca [jdk]"); > + // Valid until: Sat May 30 10:44:50 GMT 2020 > + add("addtrustqualifiedca [jdk]"); > } > }; > > Thanks, > Rajan > From erik.joelsson at oracle.com Mon Mar 2 15:04:39 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 2 Mar 2020 07:04:39 -0800 Subject: RFR 8240261: Use make/templates/gpl-cp-header in FieldGen.java In-Reply-To: <7931F3D4-6382-46B1-AFF0-12F12AC38587@oracle.com> References: <7931F3D4-6382-46B1-AFF0-12F12AC38587@oracle.com> Message-ID: Build changes look ok. /Erik On 2020-02-29 05:02, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8240261/webrev.00 > > Thanks, > Max > From alexey at azul.com Mon Mar 2 15:17:04 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 2 Mar 2020 15:17:04 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> Message-ID: <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> Hello Xuelei, Could you please review new version of the patch : http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ I did not find any reasons for such getSession() behaviour. This code seems exists since initial TLSv1.2 implementation. As you suggested, I?ve changed getSession() to throw InterruptedIOException. It makes changes in SSLSocketImpl.java and SSLTransport.java much simple. I also updated inputBuffer implementation to use ByteBuffer. It stores incoming data to handle socket timeouts and cleared after record is processed. Thank you Alexey > On 29 Feb 2020, at 03:24, Xuelei Fan wrote: > > > Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ > > > getSession() method is implemented identically to JDK8, so it's > > behaviour is backward compatible to JDK8 > I know, but I would like to see if there is really a compatibility impact if the getSession() is consistent with other IO operations. We could fix the problem later if there is a need. > > > I may try to catch the InterruptedIOException, rather than handle it > > in the IOException catching block or the Exception catching block. > > try { > ... > } catch (Exception e) { > if (e instanceof ... ) { > ... > } else (e instanceof ...) { > ... > } > } > > vs > try { > } catch (AException e) { > ... > } catch (IOException e) { > ... > } catch (Exception e) { > ... > } > > the later is the common coding style > > SSLSocketInputRecord: > 52 private byte[] inputBuffer = new byte[maxRecordSize]; > > Would you mind consider an improvement to use less memory? > > If you have webrev for JDK 15, I could help to run more testing for you. > > Thanks, > Xuelei > > > On 2/27/2020 9:05 AM, Alexey Bakhtin wrote: >> Hello Xuelei, >> You are right, SSLSocketInputRecord.read() method could be interrupted before all requested data is received. >> I have updated SSLSocketInputRecord class to use single buffer for incoming data. Also I?ve updated read() method to take into account every chunk of incoming data. It should prevent possible loss of data if socket timed out. >> Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ >> Tested with sun/security/ssl and javax/net/ssl jtreg tests >> Thank you >> Alexey >>> On 27 Feb 2020, at 01:04, Xuelei Fan > wrote: >>> >>> > Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >>> For the SSLSocketInputRecord.java update, is it possible that the read() implementation interrupted before reading the exact specified bytes of data? The received data may be lost if it is interrupted. >>> >>> BTW, it might not be effective to use three fields to store the data, temporary, header and inputBuffer. Is it possible to use just one buffer (temporary, for example) and one integer to remember the received data length? >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 2/26/2020 4:22 AM, Alexey Bakhtin wrote: >>>> Hello Xuelei, >>>> Thank you for review. >>>> getSession() method is implemented identically to JDK8, so it's behaviour is backward compatible to JDK8 >>>> I have updated review with some modifications: >>>> 1) Enabled sun/security/ssl/SSLSocketImpl/ClientTimeout.java jtreg test. This test emulates socket timeout during handshake and app data transfer. >>>> 2) I have added cache for incoming data received from socket (sun.security.ssl.SSLSocketInputRecord class). Socket timeout could happen while reading single handshake message by small chunks. It is implemented similarly to JDK8 and allows to pass sun/security/ssl/SSLSocketImpl/ClientTimeout test >>>> 3) I have added SocketTimeoutException handling into sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java jtreg test. This test also verifies SocketExceptions during handshake. >>>> Webrev for JDK11 : http://cr.openjdk.java.net/~yan/8239788/webrev.1/ >>>> Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >>>> Tested with sun/security/ssl and javax/net/ssl jtreg tests >>>> Thank you >>>> Alexey >>>>> On 25 Feb 2020, at 19:42, Xuelei Fan > wrote: >>>>> >>>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>> Maybe, the getSession() could throw InterruptedIOException as well. >>>>> >>>>> I may try to catch the InterruptedIOException, rather than handle it in the IOException catching block. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: >>>>>> Hi Xuelei, >>>>>> Thank you. It would be glad if you can review this fix. >>>>>> The patch almost cleanly applied to JDK15. >>>>>> Also, As Kumar mentioned, the patch does not include regression test. >>>>>> I?m going to add regression test and patch for JDK15 tomorrow. >>>>>> Thank you. >>>>>> Alexey >>>>>>> On 24 Feb 2020, at 21:41, Xuelei Fan > wrote: >>>>>>> >>>>>>> Hi Alexey, >>>>>>> >>>>>>> Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty? >>>>>>> >>>>>>> I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession(). >>>>>>> >>>>>>> Regards, >>>>>>> Xuelei >>>>>>> >>>>>>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>>>>>>> Hello, >>>>>>>> I have been working on this issue for some time already. >>>>>>>> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>>>>>>> Tested with JDK11 and higher. >>>>>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788 >>>>>>>> Thank you, >>>>>>>> Alexey >>>>>>>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net wrote: >>>>>>>>> >>>>>>>>> I will look into the issue. >>>>>>>>> >>>>>>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>>>>>>> Hi security-folk, >>>>>>>>>> >>>>>>>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>>>>>>> encountered what seems to be a serious behavior issue. >>>>>>>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and >>>>>>>>>> JDK-8196584 . >>>>>>>>>> >>>>>>>>>> Overview: >>>>>>>>>> With OpenJDK11 the end-points are closed immediately with TLS alerts >>>>>>>>>> raised when an exception is received. >>>>>>>>>> This is not the case with JDK8 the socket is not closed allowing retries. >>>>>>>>>> >>>>>>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also >>>>>>>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>>>>>>> >>>>>>>>>> Can you please evaluate this at the earliest, this is a serious show >>>>>>>>>> stopper for VMware. >>>>>>>>>> >>>>>>>>>> Thank >>>>>>>>>> Kumar Srinivasan >>>>>>>>>> VMware >>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.mullan at oracle.com Mon Mar 2 16:20:35 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 2 Mar 2020 11:20:35 -0500 Subject: RFR 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB In-Reply-To: <5ac36839-f7d1-ba5c-e515-2579d6dc7777@oracle.com> References: <16482275-856f-1411-34ab-034605541866@oracle.com> <7fe474f9-ece2-3f70-cdbd-94355e56dfb3@oracle.com> <8db50200-8938-6622-f03d-6f420552fa8b@redhat.com> <5ac36839-f7d1-ba5c-e515-2579d6dc7777@oracle.com> Message-ID: <624a9168-1e91-ff93-4ff1-e81922fe60b1@oracle.com> On 2/27/20 9:48 PM, Valerie Peng wrote: > Hi Martin, > > I have looked over the release note subtask and made some minor changes > on wordings and added RN-Change label. > > Sean may have additional comments to add though. Also, when you mark it > as delivered, the tech writer will also make their edit. Just FYI. I made a couple of minor wording changes, but otherwise it looks fine. I marked the Release Note as "Delivered", which will trigger that the note is now ready to be incorporated into the release notes by our tech writer. --Sean From xuelei.fan at oracle.com Mon Mar 2 22:19:06 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 2 Mar 2020 14:19:06 -0800 Subject: RFR JDK-8233619: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: <3c88d9b8-5a94-1038-5433-afc0d3d403f9@oracle.com> References: <3c88d9b8-5a94-1038-5433-afc0d3d403f9@oracle.com> Message-ID: <3302e68f-4864-e66a-1216-ee6f2c2d41cf@oracle.com> ping ... On 2/22/2020 11:20 AM, Xuelei Fan wrote: > Hi, > > Could I have the following update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8233619/webrev.01/ > > For TLS 1.2 and previous versions, the ChangeCipherSpec message is > always delivered before the Finished handshake message. ChangeCipherSpec > is not a handshake message,and cannot be wrapped in one TLS record.? The > processing of Finished handshake message is unlikely to be delegated. > > However, for TLS 1.3 there it no non-handshake messages delivered > immediately before Finished message.? Then, the delegated task could > happen before consuming the Finished message, and then the Finished > message is handled in the delegated action, together with other > handshake message in the flight. The FINISHED does not present in such > situation. > > It would be complicated to consume the Finished message separately after > the delegated tasks.? Luckily, currently the post-handshake > NewSessionTicket message is always used, immediately after the handshake > message.? The FINISHED status could present for producing and consuming > the NewSessionTicket post-handshake message. > > Thanks, > Xuelei From anthony.scarpino at oracle.com Tue Mar 3 00:40:45 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 2 Mar 2020 16:40:45 -0800 Subject: 8237219: Disabling the native SunEC implementation Message-ID: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Hi I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ The curves affected are: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Tony From weijun.wang at oracle.com Tue Mar 3 02:35:52 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 3 Mar 2020 10:35:52 +0800 Subject: RFR 8239928: ec/ECDSAJavaVerify.java failed due to timeout Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8239928/webrev.01/ Looks like on windows-x64 there is a small probability (~.1%) that VMDisconnectEvent will not be caught (and thus no VMDisconnectedException). Fortunately, in the 2 failure cases I observed, the VMDeathEvent is still seen. Thanks, Max From weijun.wang at oracle.com Tue Mar 3 03:09:32 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 3 Mar 2020 11:09:32 +0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: <5173D66E-AE3F-4939-8162-CA75A0DC6F77@oracle.com> When the native impl is disabled, and an unsupported curve is used in key pair generation, ECDSA, or ECDH, when will the exception be thrown? Is it at the same place when native impl is enabled? I mean, do we need some sort of java isSupported()? SecurityTools.java: If native is disabled, will many tests fail? Is it possible to modify the tests? This is a helper method used by many tests and I'd rather it uses the default setting. Thanks, Max > On Mar 3, 2020, at 8:40 AM, Anthony Scarpino wrote: > > Hi > > I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 > webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ > > The curves affected are: > secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Tony From sean.mullan at oracle.com Tue Mar 3 16:34:34 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Mar 2020 11:34:34 -0500 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> Wouldn't it be better to throw an Exception when you call Signature.initSign/Verify() and KeyAgreement.init() rather than waiting until you sign/verify or generateSecret? This way you bail out early before you start processing data. Also, throwing a ProviderException (a RuntimeException) could be a behavioral change that an application may not be prepared for. We have never done a very good job of documenting when ProviderException can be thrown by the JCE APIs, however. But we should think about this and whether maybe you want to throw InvalidKeyException instead which is already specified in the throws clause of the init methods. In any case it should be documented as a potential compatibility issue in the CSR. Did you consider documenting the system property in the API javadocs for Signature, KeyPairGenerator, KeyAgreement? I realize this is specific to the SunEC provider, but this would help users know how to enable the system property (on the hopefully rare case) they get an exception and still want to use one of these curves. It could be something like: @implNote By default, the SunEC provider throws ...Exception if the key is using a legacy curve. Set the {@systemProperty jdk.sunec.disableNative} to {@code false} to disable this behavior. --Sean On 3/2/20 7:40 PM, Anthony Scarpino wrote: > Hi > > I need a review of the CSR and webrev for disabling by default the > native SunEC curves from the API.? With the recent verification changes > in JDK-8237218, SunJCE is long dependent on the native code for > verifying the constant-time curves.? This disabling can be undone with > setting a? system property, jdk.sunec.disableNative.? I'm doing a > simultaneous review as changes for one? will likely affect the other. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 > webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ > > The curves affected are: > secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, > sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, > sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, > sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 > c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 > c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 > prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, > brainpoolP512r1 > > Tony From xuelei.fan at oracle.com Tue Mar 3 16:55:32 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Mar 2020 08:55:32 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: <27c57a2f-0b9c-ff4a-d4b2-cf0572384605@oracle.com> SunEC.java: 59 String s = System.getProperty("jdk.sunec.disableNative"); 60 if (s != null && s.equalsIgnoreCase("false")) { 61 disableNative = false; 62 } Do you want to get the property value in the privileged block so that it works if security manager enabled? Per line 60, native is disabled if the property is set to value other than "false'. It would be nice to describe the behavior in the CSR. Xuelei On 3/2/2020 4:40 PM, Anthony Scarpino wrote: > Hi > > I need a review of the CSR and webrev for disabling by default the > native SunEC curves from the API.? With the recent verification changes > in JDK-8237218, SunJCE is long dependent on the native code for > verifying the constant-time curves.? This disabling can be undone with > setting a? system property, jdk.sunec.disableNative.? I'm doing a > simultaneous review as changes for one? will likely affect the other. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 > webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ > > The curves affected are: > secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, > sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, > sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, > sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 > c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 > c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 > prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, > brainpoolP512r1 > > Tony From anthony.scarpino at oracle.com Tue Mar 3 18:42:50 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 3 Mar 2020 10:42:50 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <5173D66E-AE3F-4939-8162-CA75A0DC6F77@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <5173D66E-AE3F-4939-8162-CA75A0DC6F77@oracle.com> Message-ID: Yes, the exceptions are thrown in the same location because we need the init() and setParameters() set before we can decide if the curve is supported. The current java implementation falls through to the native code if the java code does not support there curve. I don't think we need any further methods. Tony On 3/2/20 7:09 PM, Weijun Wang wrote: > When the native impl is disabled, and an unsupported curve is used in key pair generation, ECDSA, or ECDH, when will the exception be thrown? Is it at the same place when native impl is enabled? I mean, do we need some sort of java isSupported()? > > SecurityTools.java: > > If native is disabled, will many tests fail? Is it possible to modify the tests? This is a helper method used by many tests and I'd rather it uses the default setting. > > Thanks, > Max > >> On Mar 3, 2020, at 8:40 AM, Anthony Scarpino wrote: >> >> Hi >> >> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >> >> The curves affected are: >> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >> >> Tony > From anthony.scarpino at oracle.com Tue Mar 3 18:42:53 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 3 Mar 2020 10:42:53 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> Message-ID: <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> On 3/3/20 8:34 AM, Sean Mullan wrote: > Wouldn't it be better to throw an Exception when you call > Signature.initSign/Verify() and KeyAgreement.init() rather than waiting > until you sign/verify or generateSecret? This way you bail out early > before you start processing data. > > Also, throwing a ProviderException (a RuntimeException) could be a > behavioral change that an application may not be prepared for. We have > never done a very good job of documenting when ProviderException can be > thrown by the JCE APIs, however. But we should think about this and > whether maybe you want to throw InvalidKeyException instead which is > already specified in the throws clause of the init methods. In any case > it should be documented as a potential compatibility issue in the CSR. Unfortunately curve support decisions are not made until the library is accessed. You will notice the checks that call native are not until the operation is starting, like engineSign(). If an unsupported curve is used in the existing code, this is where the error is generated from. The native code does generate an InvalidAlgorithmParameterException. I had chose ProviderException because it was a provider support change. I had thought about IAPE, but choose a bit more drastic action. That said, I'm fine with using IAPE. If one was to remove libsunec, the existing code disables algorithms like SHA256withECDSA which makes it easier to separate native from java implementations. But that is not true anymore with the java implementation supporting the NIST curves. Some of these same decisions affect both property disabling and library removal. In the past we have had similar Signature discussions before about when Signature.setParameter() being called before or after init(). I have to wonder if the original provider design followed the same logic where errors are generated later in the process. Also there are some decisions in this provider that look similar to SunPKCS11 as both wait until the last moment to ask the native library. > > Did you consider documenting the system property in the API javadocs for > Signature, KeyPairGenerator, KeyAgreement? I realize this is specific to > the SunEC provider, but this would help users know how to enable the > system property (on the hopefully rare case) they get an exception and > still want to use one of these curves. It could be something like: > > @implNote By default, the SunEC provider throws ...Exception if the key > is using a legacy curve. Set the {@systemProperty > jdk.sunec.disableNative} to {@code false} to disable this behavior. > I don't think putting in the API about one particular provider implementation detail is a proper place. I think this belongs in release notes, and maybe the provider doc. > > --Sean > > On 3/2/20 7:40 PM, Anthony Scarpino wrote: >> Hi >> >> I need a review of the CSR and webrev for disabling by default the >> native SunEC curves from the API.? With the recent verification >> changes in JDK-8237218, SunJCE is long dependent on the native code >> for verifying the constant-time curves.? This disabling can be undone >> with setting a? system property, jdk.sunec.disableNative.? I'm doing a >> simultaneous review as changes for one? will likely affect the other. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >> >> The curves affected are: >> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >> >> Tony From anthony.scarpino at oracle.com Tue Mar 3 18:42:58 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 3 Mar 2020 10:42:58 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <27c57a2f-0b9c-ff4a-d4b2-cf0572384605@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <27c57a2f-0b9c-ff4a-d4b2-cf0572384605@oracle.com> Message-ID: On 3/3/20 8:55 AM, Xuelei Fan wrote: > SunEC.java: > > ? 59???????? String s = System.getProperty("jdk.sunec.disableNative"); > ? 60???????? if (s != null && s.equalsIgnoreCase("false")) { > ? 61???????????? disableNative = false; > ? 62???????? } > > Do you want to get the property value in the privileged block so that it > works if security manager enabled? Sean? > > Per line 60, native is disabled if the property is set to value other > than "false'.? It would be nice to describe the behavior in the CSR. ok > > > Xuelei > > On 3/2/2020 4:40 PM, Anthony Scarpino wrote: >> Hi >> >> I need a review of the CSR and webrev for disabling by default the >> native SunEC curves from the API.? With the recent verification >> changes in JDK-8237218, SunJCE is long dependent on the native code >> for verifying the constant-time curves.? This disabling can be undone >> with setting a? system property, jdk.sunec.disableNative.? I'm doing a >> simultaneous review as changes for one? will likely affect the other. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >> >> The curves affected are: >> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >> >> Tony From sean.mullan at oracle.com Tue Mar 3 18:54:28 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Mar 2020 13:54:28 -0500 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <27c57a2f-0b9c-ff4a-d4b2-cf0572384605@oracle.com> Message-ID: On 3/3/20 1:42 PM, Anthony Scarpino wrote: > On 3/3/20 8:55 AM, Xuelei Fan wrote: >> SunEC.java: >> >> ?? 59???????? String s = System.getProperty("jdk.sunec.disableNative"); >> ?? 60???????? if (s != null && s.equalsIgnoreCase("false")) { >> ?? 61???????????? disableNative = false; >> ?? 62???????? } >> >> Do you want to get the property value in the privileged block so that >> it works if security manager enabled? > > Sean? Yes, you can just use sun.security.action.GetPropertyAction.privilegedGetProperty(). --Sean > >> >> Per line 60, native is disabled if the property is set to value other >> than "false'.? It would be nice to describe the behavior in the CSR. > > ok > >> >> >> Xuelei >> >> On 3/2/2020 4:40 PM, Anthony Scarpino wrote: >>> Hi >>> >>> I need a review of the CSR and webrev for disabling by default the >>> native SunEC curves from the API.? With the recent verification >>> changes in JDK-8237218, SunJCE is long dependent on the native code >>> for verifying the constant-time curves.? This disabling can be undone >>> with setting a? system property, jdk.sunec.disableNative.? I'm doing >>> a simultaneous review as changes for one? will likely affect the other. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>> >>> The curves affected are: >>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >>> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >>> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >>> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >>> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >>> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >>> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>> >>> Tony > From sean.mullan at oracle.com Tue Mar 3 19:18:53 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Mar 2020 14:18:53 -0500 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> Message-ID: On 3/3/20 1:42 PM, Anthony Scarpino wrote: > On 3/3/20 8:34 AM, Sean Mullan wrote: >> Wouldn't it be better to throw an Exception when you call >> Signature.initSign/Verify() and KeyAgreement.init() rather than >> waiting until you sign/verify or generateSecret? This way you bail out >> early before you start processing data. >> >> Also, throwing a ProviderException (a RuntimeException) could be a >> behavioral change that an application may not be prepared for. We have >> never done a very good job of documenting when ProviderException can >> be thrown by the JCE APIs, however. But we should think about this and >> whether maybe you want to throw InvalidKeyException instead which is >> already specified in the throws clause of the init methods. In any >> case it should be documented as a potential compatibility issue in the >> CSR. > > > Unfortunately curve support decisions are not made until the library is > accessed. You will notice the checks that call native are not until the > operation is starting, like engineSign().? If an unsupported curve is > used in the existing code, this is where the error is generated from. > The native code does generate an InvalidAlgorithmParameterException.? I > had chose ProviderException because it was a provider support change. I > had thought about IAPE, but choose a bit more drastic action. That said, > I'm fine with using IAPE. Hmm, but engineSign, engineVerify, engineGenerateSecret don't throw IAPE. I think it should probably be the same behavior as if the library did not exist. What do we throw now if the library has been removed? > If one was to remove libsunec, the existing code disables algorithms > like SHA256withECDSA which makes it easier to separate native from java > implementations.? But that is not true anymore with the java > implementation supporting the NIST curves.? Some of these same decisions > affect both property disabling and library removal. > > In the past we have had similar Signature discussions before about when > Signature.setParameter() being called before or after init().? I have to > wonder if the original provider design followed the same logic where > errors are generated later in the process.? Also there are some > decisions in this provider that look similar to SunPKCS11 as both wait > until the last moment to ask the native library. > >> >> Did you consider documenting the system property in the API javadocs >> for Signature, KeyPairGenerator, KeyAgreement? I realize this is >> specific to the SunEC provider, but this would help users know how to >> enable the system property (on the hopefully rare case) they get an >> exception and still want to use one of these curves. It could be >> something like: >> >> @implNote By default, the SunEC provider throws ...Exception if the >> key is using a legacy curve. Set the {@systemProperty >> jdk.sunec.disableNative} to {@code false} to disable this behavior. >> > > I don't think putting in the API about one particular provider > implementation detail is a proper place.? I think this belongs in > release notes, and maybe the provider doc. Yeah, I am kind of on the fence about that myself as I don't necessarily want to clutter the APIs with provider-specific stuff, but OTOH, most of the security-related system properties *are* provider-specific, so we lose the nice feature of seeing how different system properties affect existing APIs while you are reading the javadoc. But, I think we probably need to decide on a more general policy for documenting provider-specific system properties first. So I guess we can hold off on this for now. --Sean >> --Sean >> >> On 3/2/20 7:40 PM, Anthony Scarpino wrote: >>> Hi >>> >>> I need a review of the CSR and webrev for disabling by default the >>> native SunEC curves from the API.? With the recent verification >>> changes in JDK-8237218, SunJCE is long dependent on the native code >>> for verifying the constant-time curves.? This disabling can be undone >>> with setting a? system property, jdk.sunec.disableNative.? I'm doing >>> a simultaneous review as changes for one? will likely affect the other. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>> >>> The curves affected are: >>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >>> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >>> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >>> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >>> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >>> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >>> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>> >>> Tony > From anthony.scarpino at oracle.com Tue Mar 3 19:42:19 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 3 Mar 2020 11:42:19 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> Message-ID: <124bf6a8-41e4-64d6-98b9-ffb4c1ee8ce0@oracle.com> On 3/3/20 11:18 AM, Sean Mullan wrote: > On 3/3/20 1:42 PM, Anthony Scarpino wrote: >> On 3/3/20 8:34 AM, Sean Mullan wrote: >>> Wouldn't it be better to throw an Exception when you call >>> Signature.initSign/Verify() and KeyAgreement.init() rather than >>> waiting until you sign/verify or generateSecret? This way you bail >>> out early before you start processing data. >>> >>> Also, throwing a ProviderException (a RuntimeException) could be a >>> behavioral change that an application may not be prepared for. We >>> have never done a very good job of documenting when ProviderException >>> can be thrown by the JCE APIs, however. But we should think about >>> this and whether maybe you want to throw InvalidKeyException instead >>> which is already specified in the throws clause of the init methods. >>> In any case it should be documented as a potential compatibility >>> issue in the CSR. >> >> >> Unfortunately curve support decisions are not made until the library >> is accessed. You will notice the checks that call native are not until >> the operation is starting, like engineSign().? If an unsupported curve >> is used in the existing code, this is where the error is generated >> from. The native code does generate an >> InvalidAlgorithmParameterException.? I had chose ProviderException >> because it was a provider support change. I had thought about IAPE, >> but choose a bit more drastic action. That said, I'm fine with using >> IAPE. > > Hmm, but engineSign, engineVerify, engineGenerateSecret don't throw IAPE. The native code throws it and it's wrapped in a SignatureException. For generateKeyPair() the existing code threw a ProviderException because the method doesn't specify any exceptions. That probably pushed me toward ProviderException in other cases too. > > I think it should probably be the same behavior as if the library did > not exist. What do we throw now if the library has been removed? Maybe you missed one paragraph below? Without the library in the existing code we never got past getInstance() because those algorithms like SHA256withECDSA were not available. After Max's verify change, they are now. > >> If one was to remove libsunec, the existing code disables algorithms >> like SHA256withECDSA which makes it easier to separate native from >> java implementations.? But that is not true anymore with the java >> implementation supporting the NIST curves.? Some of these same >> decisions affect both property disabling and library removal. >> >> In the past we have had similar Signature discussions before about >> when Signature.setParameter() being called before or after init().? I >> have to wonder if the original provider design followed the same logic >> where errors are generated later in the process.? Also there are some >> decisions in this provider that look similar to SunPKCS11 as both wait >> until the last moment to ask the native library. >> >>> >>> Did you consider documenting the system property in the API javadocs >>> for Signature, KeyPairGenerator, KeyAgreement? I realize this is >>> specific to the SunEC provider, but this would help users know how to >>> enable the system property (on the hopefully rare case) they get an >>> exception and still want to use one of these curves. It could be >>> something like: >>> >>> @implNote By default, the SunEC provider throws ...Exception if the >>> key is using a legacy curve. Set the {@systemProperty >>> jdk.sunec.disableNative} to {@code false} to disable this behavior. >>> >> >> I don't think putting in the API about one particular provider >> implementation detail is a proper place.? I think this belongs in >> release notes, and maybe the provider doc. > > Yeah, I am kind of on the fence about that myself as I don't necessarily > want to clutter the APIs with provider-specific stuff, but OTOH, most of > the security-related system properties *are* provider-specific, so we > lose the nice feature of seeing how different system properties affect > existing APIs while you are reading the javadoc. But, I think we > probably need to decide on a more general policy for documenting > provider-specific system properties first. So I guess we can hold off on > this for now. > > --Sean > >>> --Sean >>> >>> On 3/2/20 7:40 PM, Anthony Scarpino wrote: >>>> Hi >>>> >>>> I need a review of the CSR and webrev for disabling by default the >>>> native SunEC curves from the API.? With the recent verification >>>> changes in JDK-8237218, SunJCE is long dependent on the native code >>>> for verifying the constant-time curves.? This disabling can be >>>> undone with setting a? system property, jdk.sunec.disableNative. >>>> I'm doing a simultaneous review as changes for one? will likely >>>> affect the other. >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>> >>>> The curves affected are: >>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >>>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >>>> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >>>> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >>>> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >>>> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >>>> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >>>> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >>>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >>>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>> >>>> Tony >> From jamil.j.nimeh at oracle.com Tue Mar 3 20:35:56 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 3 Mar 2020 12:35:56 -0800 Subject: RFR JDK-8233619: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: <3302e68f-4864-e66a-1216-ee6f2c2d41cf@oracle.com> References: <3c88d9b8-5a94-1038-5433-afc0d3d403f9@oracle.com> <3302e68f-4864-e66a-1216-ee6f2c2d41cf@oracle.com> Message-ID: <56abb863-06ea-d01b-dc94-4d6728ea2e7f@oracle.com> Looks good to me.? Sorry for the delay in getting you a review. --Jamil On 3/2/2020 2:19 PM, Xuelei Fan wrote: > ping ... > > On 2/22/2020 11:20 AM, Xuelei Fan wrote: >> Hi, >> >> Could I have the following update reviewed? >> ???? http://cr.openjdk.java.net/~xuelei/8233619/webrev.01/ >> >> For TLS 1.2 and previous versions, the ChangeCipherSpec message is >> always delivered before the Finished handshake message. >> ChangeCipherSpec is not a handshake message,and cannot be wrapped in >> one TLS record.? The processing of Finished handshake message is >> unlikely to be delegated. >> >> However, for TLS 1.3 there it no non-handshake messages delivered >> immediately before Finished message.? Then, the delegated task could >> happen before consuming the Finished message, and then the Finished >> message is handled in the delegated action, together with other >> handshake message in the flight. The FINISHED does not present in >> such situation. >> >> It would be complicated to consume the Finished message separately >> after the delegated tasks.? Luckily, currently the post-handshake >> NewSessionTicket message is always used, immediately after the >> handshake message.? The FINISHED status could present for producing >> and consuming the NewSessionTicket post-handshake message. >> >> Thanks, >> Xuelei From anthony.scarpino at oracle.com Wed Mar 4 02:49:11 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 3 Mar 2020 18:49:11 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <5173D66E-AE3F-4939-8162-CA75A0DC6F77@oracle.com> Message-ID: I think you are right for key generation that some addition to the supported curve method will needed. With changing some of the exceptions types I'm realizing that the native library was being used more than I thought. Tony On 3/3/20 10:42 AM, Anthony Scarpino wrote: > Yes, the exceptions are thrown in the same location because we need the > init() and setParameters() set before we can decide if the curve is > supported. > > The current java implementation falls through to the native code if the > java code does not support there curve.? I don't think we need any > further methods. > > Tony > > On 3/2/20 7:09 PM, Weijun Wang wrote: >> When the native impl is disabled, and an unsupported curve is used in >> key pair generation, ECDSA, or ECDH, when will the exception be >> thrown? Is it at the same place when native impl is enabled? I mean, >> do we need some sort of java isSupported()? >> >> SecurityTools.java: >> >> If native is disabled, will many tests fail? Is it possible to modify >> the tests? This is a helper method used by many tests and I'd rather >> it uses the default setting. >> >> Thanks, >> Max >> >>> On Mar 3, 2020, at 8:40 AM, Anthony Scarpino >>> wrote: >>> >>> Hi >>> >>> I need a review of the CSR and webrev for disabling by default the >>> native SunEC curves from the API.? With the recent verification >>> changes in JDK-8237218, SunJCE is long dependent on the native code >>> for verifying the constant-time curves.? This disabling can be undone >>> with setting a? system property, jdk.sunec.disableNative.? I'm doing >>> a simultaneous review as changes for one? will likely affect the other. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>> >>> The curves affected are: >>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >>> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >>> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >>> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >>> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >>> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >>> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>> >>> Tony >> > From weijun.wang at oracle.com Wed Mar 4 02:57:08 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 Mar 2020 10:57:08 +0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <124bf6a8-41e4-64d6-98b9-ffb4c1ee8ce0@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> <124bf6a8-41e4-64d6-98b9-ffb4c1ee8ce0@oracle.com> Message-ID: <6AE068D0-8CEE-4C9E-9034-C760FE33C39D@oracle.com> We have 3 places checking for an algorithm now: 1. If CurveDB does not know a curve, you won't be able to create parameters. 2. There is a ECKeyPairGenerator::isSupported 3. The native lib For a curve name rejected on each place, is there any behavior change? Another thing: Even after the native lib is disabled, I think we can still create AlgorithmParameters and use KeyFactory to load a key when the curve is not supported, right? If the user has BouncyCastle in the provider list, I hope the Signature provider choosing fallback still works and a BC Signature object will be used when initialized with such a key. Thanks, Max > On Mar 4, 2020, at 3:42 AM, Anthony Scarpino wrote: > > On 3/3/20 11:18 AM, Sean Mullan wrote: >> On 3/3/20 1:42 PM, Anthony Scarpino wrote: >>> On 3/3/20 8:34 AM, Sean Mullan wrote: >>>> Wouldn't it be better to throw an Exception when you call Signature.initSign/Verify() and KeyAgreement.init() rather than waiting until you sign/verify or generateSecret? This way you bail out early before you start processing data. >>>> >>>> Also, throwing a ProviderException (a RuntimeException) could be a behavioral change that an application may not be prepared for. We have never done a very good job of documenting when ProviderException can be thrown by the JCE APIs, however. But we should think about this and whether maybe you want to throw InvalidKeyException instead which is already specified in the throws clause of the init methods. In any case it should be documented as a potential compatibility issue in the CSR. >>> >>> >>> Unfortunately curve support decisions are not made until the library is accessed. You will notice the checks that call native are not until the operation is starting, like engineSign(). If an unsupported curve is used in the existing code, this is where the error is generated from. The native code does generate an InvalidAlgorithmParameterException. I had chose ProviderException because it was a provider support change. I had thought about IAPE, but choose a bit more drastic action. That said, I'm fine with using IAPE. >> Hmm, but engineSign, engineVerify, engineGenerateSecret don't throw IAPE. > > The native code throws it and it's wrapped in a SignatureException. > > For generateKeyPair() the existing code threw a ProviderException because the method doesn't specify any exceptions. That probably pushed me toward ProviderException in other cases too. > >> I think it should probably be the same behavior as if the library did not exist. What do we throw now if the library has been removed? > > Maybe you missed one paragraph below? Without the library in the existing code we never got past getInstance() because those algorithms like SHA256withECDSA were not available. After Max's verify change, they are now. > >>> If one was to remove libsunec, the existing code disables algorithms like SHA256withECDSA which makes it easier to separate native from java implementations. But that is not true anymore with the java implementation supporting the NIST curves. Some of these same decisions affect both property disabling and library removal. >>> >>> In the past we have had similar Signature discussions before about when Signature.setParameter() being called before or after init(). I have to wonder if the original provider design followed the same logic where errors are generated later in the process. Also there are some decisions in this provider that look similar to SunPKCS11 as both wait until the last moment to ask the native library. >>> >>>> >>>> Did you consider documenting the system property in the API javadocs for Signature, KeyPairGenerator, KeyAgreement? I realize this is specific to the SunEC provider, but this would help users know how to enable the system property (on the hopefully rare case) they get an exception and still want to use one of these curves. It could be something like: >>>> >>>> @implNote By default, the SunEC provider throws ...Exception if the key is using a legacy curve. Set the {@systemProperty jdk.sunec.disableNative} to {@code false} to disable this behavior. >>>> >>> >>> I don't think putting in the API about one particular provider implementation detail is a proper place. I think this belongs in release notes, and maybe the provider doc. >> Yeah, I am kind of on the fence about that myself as I don't necessarily want to clutter the APIs with provider-specific stuff, but OTOH, most of the security-related system properties *are* provider-specific, so we lose the nice feature of seeing how different system properties affect existing APIs while you are reading the javadoc. But, I think we probably need to decide on a more general policy for documenting provider-specific system properties first. So I guess we can hold off on this for now. >> --Sean >>>> --Sean >>>> >>>> On 3/2/20 7:40 PM, Anthony Scarpino wrote: >>>>> Hi >>>>> >>>>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>>>> >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>>> >>>>> The curves affected are: >>>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>>> >>>>> Tony From xuelei.fan at oracle.com Wed Mar 4 18:23:24 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 4 Mar 2020 10:23:24 -0800 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> Message-ID: <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> > http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ SSLSocketInputRecord: 54 // Cache for incomplete input record. 55 private ByteBuffer inputBuffer = null; This variable is used for record body, I may use a instinctive name, for example recordBody. Otherwise, looks good to me. I think, for performance, it may be possible to reuse this buffer for multiple records. I'd appreciate if you want to make an improvement in this update as well. Thanks, Xuelei On 3/2/2020 7:17 AM, Alexey Bakhtin wrote: > Hello Xuelei, > > Could you please review new version of the patch : > http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ > > I did not find any reasons for such getSession() behaviour. This code > seems exists since initial TLSv1.2 implementation. As you suggested, > I?ve changed getSession() to throw InterruptedIOException. It makes > changes in SSLSocketImpl.java and SSLTransport.java much simple. > > I also updated inputBuffer implementation to use ByteBuffer. It stores > incoming data to handle socket timeouts and cleared after record is > processed. > > Thank you > Alexey > > >> On 29 Feb 2020, at 03:24, Xuelei Fan > > wrote: >> >> > Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ >> >> > getSession() method is implemented identically to JDK8, so it's >> > behaviour is backward compatible to JDK8 >> I know, but I would like to see if there is really a compatibility >> impact if the getSession() is consistent with other IO operations. ?We >> could fix the problem later if there is a need. >> >> > I may try to catch the InterruptedIOException, rather than handle it >> > in the IOException catching block or the Exception catching block. >> >> try { >> ??... >> } catch (Exception e) { >> ??if (e instanceof ... ) { >> ??????... >> ??} else (e instanceof ...) { >> ??????... >> ??} >> } >> >> vs >> try { >> } catch (AException e) { >> ??... >> } catch (IOException e) { >> ??... >> } catch (Exception e) { >> ??... >> } >> >> the later is the common coding style >> >> SSLSocketInputRecord: >> ?52 ????private byte[] inputBuffer = new byte[maxRecordSize]; >> >> Would you mind consider an improvement to use less memory? >> >> If you have webrev for JDK 15, I could help to run more testing for you. >> >> Thanks, >> Xuelei >> >> >> On 2/27/2020 9:05 AM, Alexey Bakhtin wrote: >>> Hello Xuelei, >>> You are right, SSLSocketInputRecord.read() method could be >>> interrupted before all requested data is received. >>> I have updated ?SSLSocketInputRecord class to use single buffer for >>> incoming data. Also I?ve updated read() method to take into account >>> every chunk of incoming data. It should prevent possible loss of data >>> if socket timed out. >>> Webrev JDK11: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ >>> Tested with sun/security/ssl and javax/net/ssl jtreg tests >>> Thank you >>> Alexey >>>> On 27 Feb 2020, at 01:04, Xuelei Fan >>> > wrote: >>>> >>>> > Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >>>> For the SSLSocketInputRecord.java update, is it possible that the >>>> read() implementation interrupted before reading the exact specified >>>> bytes of data? ?The received data may be lost if it is interrupted. >>>> >>>> BTW, it might not be effective to use three fields to store the >>>> data, temporary, header and inputBuffer. ?Is it possible to use just >>>> one buffer (temporary, for example) and one integer to remember the >>>> received data length? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 2/26/2020 4:22 AM, Alexey Bakhtin wrote: >>>>> Hello Xuelei, >>>>> Thank you for review. >>>>> getSession() method is implemented identically to JDK8, so it's >>>>> behaviour is backward compatible to JDK8 >>>>> I have updated review with some modifications: >>>>> 1) Enabled sun/security/ssl/SSLSocketImpl/ClientTimeout.java jtreg >>>>> test. This test emulates socket timeout during handshake and app >>>>> data transfer. >>>>> 2) I have added cache for incoming data received from socket >>>>> (sun.security.ssl.SSLSocketInputRecord class). Socket timeout could >>>>> happen while reading single handshake message by small chunks. It >>>>> is implemented similarly to JDK8 and allows to pass >>>>> sun/security/ssl/SSLSocketImpl/ClientTimeout test >>>>> 3) I have added SocketTimeoutException handling into >>>>> sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java jtreg >>>>> test. This test also verifies SocketExceptions during handshake. >>>>> Webrev for JDK11 : http://cr.openjdk.java.net/~yan/8239788/webrev.1/ >>>>> Webrev for JDK15 : http://cr.openjdk.java.net/~yan/8239788/webrev.2/ >>>>> Tested with sun/security/ssl and javax/net/ssl jtreg tests >>>>> Thank you >>>>> Alexey >>>>>> On 25 Feb 2020, at 19:42, Xuelei Fan >>>>> > wrote: >>>>>> >>>>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>>> Maybe, the getSession() could throw InterruptedIOException as well. >>>>>> >>>>>> I may try to catch the InterruptedIOException, rather than handle >>>>>> it in the IOException catching block. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 2/24/2020 11:04 AM, Alexey Bakhtin wrote: >>>>>>> Hi Xuelei, >>>>>>> Thank you. It would be glad if you can review this fix. >>>>>>> The patch almost cleanly applied to JDK15. >>>>>>> Also, As Kumar mentioned, the patch does not include regression test. >>>>>>> I?m going to add regression test and patch for JDK15 tomorrow. >>>>>>> Thank you. >>>>>>> Alexey >>>>>>>> On 24 Feb 2020, at 21:41, Xuelei Fan >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Thanks for working on this issue. ?Do you plan to fix it for JDK >>>>>>>> 15, the current JDK reposiroty? >>>>>>>> >>>>>>>> I need more time for evaluate the fix. ?For example, I'm not >>>>>>>> sure if we could always throw InterruptedIOException to >>>>>>>> applications, even for getSession(). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote: >>>>>>>>> Hello, >>>>>>>>> I have been working on this issue for some time already. >>>>>>>>> The patch below adds ?java.net.SocketTimeoutException handling >>>>>>>>> during TLS handshake negotiation. This functionality seems to >>>>>>>>> have been missed during the TLSv1.3 implementation ( JDK-8196584 ) >>>>>>>>> Tested with JDK11 and higher. >>>>>>>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ >>>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8239788 >>>>>>>>> Thank you, >>>>>>>>> Alexey >>>>>>>>>> On 22 Feb 2020, at 15:00, >>>>>>>>>> security-dev-request at openjdk.java.net >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I will look into the issue. >>>>>>>>>> >>>>>>>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote: >>>>>>>>>>> Hi security-folk, >>>>>>>>>>> >>>>>>>>>>> At VMware while upgrading our application to OpenJDK11u, we have >>>>>>>>>>> encountered what seems to be a serious behavior issue. >>>>>>>>>>> The issue AFAICT seems to have stemmed from the work for >>>>>>>>>>> TLS1.3 and >>>>>>>>>>> JDK-8196584 . >>>>>>>>>>> >>>>>>>>>>> Overview: >>>>>>>>>>> With OpenJDK11 the end-points are closed immediately with TLS >>>>>>>>>>> alerts >>>>>>>>>>> raised when an exception is received. >>>>>>>>>>> This is not the case with JDK8 the socket is not closed >>>>>>>>>>> allowing retries. >>>>>>>>>>> >>>>>>>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was >>>>>>>>>>> also >>>>>>>>>>> reported ?to Azul and they have filed: JDK-8239788. >>>>>>>>>>> >>>>>>>>>>> Can you please evaluate this at the earliest, this is a >>>>>>>>>>> serious show >>>>>>>>>>> stopper for VMware. >>>>>>>>>>> >>>>>>>>>>> Thank >>>>>>>>>>> Kumar Srinivasan >>>>>>>>>>> VMware >>>>>>>>>> > From anthony.scarpino at oracle.com Thu Mar 5 03:14:53 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 4 Mar 2020 19:14:53 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <6AE068D0-8CEE-4C9E-9034-C760FE33C39D@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> <124bf6a8-41e4-64d6-98b9-ffb4c1ee8ce0@oracle.com> <6AE068D0-8CEE-4C9E-9034-C760FE33C39D@oracle.com> Message-ID: <7a3c39af-b2e9-f35f-3a24-9c3721986f54@oracle.com> On 3/3/20 6:57 PM, Weijun Wang wrote: > We have 3 places checking for an algorithm now: > > 1. If CurveDB does not know a curve, you won't be able to create parameters. Currently the CurveDB is unchanged. But when the library is removed, maybe it should be trimmed to only the 3 NIST curves? > > 2. There is a ECKeyPairGenerator::isSupported I've changed this to support only 3 NIST curves when the library is disabled > > 3. The native lib Similar to isSupported, if the property is false, it uses the native library > > For a curve name rejected on each place, is there any behavior change? There should not be any with my latest changes that I have not put onto a webrev yet. > > Another thing: Even after the native lib is disabled, I think we can still create AlgorithmParameters and use KeyFactory to load a key when the curve is not supported, right? If the user has BouncyCastle in the provider list, I hope the Signature provider choosing fallback still works and a BC Signature object will be used when initialized with such a key. I don't know how much BC depends on SunEC. Right now the SunEC provider is returning AlgorithmsParameters supportedCurves property with the 3 NIST curves instead of all the curves in CurveDB that are disabled`. > > Thanks, > Max > >> On Mar 4, 2020, at 3:42 AM, Anthony Scarpino wrote: >> >> On 3/3/20 11:18 AM, Sean Mullan wrote: >>> On 3/3/20 1:42 PM, Anthony Scarpino wrote: >>>> On 3/3/20 8:34 AM, Sean Mullan wrote: >>>>> Wouldn't it be better to throw an Exception when you call Signature.initSign/Verify() and KeyAgreement.init() rather than waiting until you sign/verify or generateSecret? This way you bail out early before you start processing data. >>>>> >>>>> Also, throwing a ProviderException (a RuntimeException) could be a behavioral change that an application may not be prepared for. We have never done a very good job of documenting when ProviderException can be thrown by the JCE APIs, however. But we should think about this and whether maybe you want to throw InvalidKeyException instead which is already specified in the throws clause of the init methods. In any case it should be documented as a potential compatibility issue in the CSR. >>>> >>>> >>>> Unfortunately curve support decisions are not made until the library is accessed. You will notice the checks that call native are not until the operation is starting, like engineSign(). If an unsupported curve is used in the existing code, this is where the error is generated from. The native code does generate an InvalidAlgorithmParameterException. I had chose ProviderException because it was a provider support change. I had thought about IAPE, but choose a bit more drastic action. That said, I'm fine with using IAPE. >>> Hmm, but engineSign, engineVerify, engineGenerateSecret don't throw IAPE. >> >> The native code throws it and it's wrapped in a SignatureException. >> >> For generateKeyPair() the existing code threw a ProviderException because the method doesn't specify any exceptions. That probably pushed me toward ProviderException in other cases too. >> >>> I think it should probably be the same behavior as if the library did not exist. What do we throw now if the library has been removed? >> >> Maybe you missed one paragraph below? Without the library in the existing code we never got past getInstance() because those algorithms like SHA256withECDSA were not available. After Max's verify change, they are now. >> >>>> If one was to remove libsunec, the existing code disables algorithms like SHA256withECDSA which makes it easier to separate native from java implementations. But that is not true anymore with the java implementation supporting the NIST curves. Some of these same decisions affect both property disabling and library removal. >>>> >>>> In the past we have had similar Signature discussions before about when Signature.setParameter() being called before or after init(). I have to wonder if the original provider design followed the same logic where errors are generated later in the process. Also there are some decisions in this provider that look similar to SunPKCS11 as both wait until the last moment to ask the native library. >>>> >>>>> >>>>> Did you consider documenting the system property in the API javadocs for Signature, KeyPairGenerator, KeyAgreement? I realize this is specific to the SunEC provider, but this would help users know how to enable the system property (on the hopefully rare case) they get an exception and still want to use one of these curves. It could be something like: >>>>> >>>>> @implNote By default, the SunEC provider throws ...Exception if the key is using a legacy curve. Set the {@systemProperty jdk.sunec.disableNative} to {@code false} to disable this behavior. >>>>> >>>> >>>> I don't think putting in the API about one particular provider implementation detail is a proper place. I think this belongs in release notes, and maybe the provider doc. >>> Yeah, I am kind of on the fence about that myself as I don't necessarily want to clutter the APIs with provider-specific stuff, but OTOH, most of the security-related system properties *are* provider-specific, so we lose the nice feature of seeing how different system properties affect existing APIs while you are reading the javadoc. But, I think we probably need to decide on a more general policy for documenting provider-specific system properties first. So I guess we can hold off on this for now. >>> --Sean >>>>> --Sean >>>>> >>>>> On 3/2/20 7:40 PM, Anthony Scarpino wrote: >>>>>> Hi >>>>>> >>>>>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>>>>> >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>>>> >>>>>> The curves affected are: >>>>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>>>> >>>>>> Tony > From weijun.wang at oracle.com Thu Mar 5 06:59:19 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 5 Mar 2020 14:59:19 +0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <7a3c39af-b2e9-f35f-3a24-9c3721986f54@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> <124bf6a8-41e4-64d6-98b9-ffb4c1ee8ce0@oracle.com> <6AE068D0-8CEE-4C9E-9034-C760FE33C39D@oracle.com> <7a3c39af-b2e9-f35f-3a24-9c3721986f54@oracle.com> Message-ID: > On Mar 5, 2020, at 11:14 AM, Anthony Scarpino wrote: > > On 3/3/20 6:57 PM, Weijun Wang wrote: >> We have 3 places checking for an algorithm now: >> 1. If CurveDB does not know a curve, you won't be able to create parameters. > > Currently the CurveDB is unchanged. But when the library is removed, maybe it should be trimmed to only the 3 NIST curves? Maybe not. TLS uses it to find out the curve name for a ciphersuite name. if SunEC does not support the curve name it can still find it in BC. So there are 2 kinds of curves now: known curves, and SunEC supported curves. Or does this mean we can move CurveDB inside TLS, and only keep the name part (without the BigIntegers)? > >> 2. There is a ECKeyPairGenerator::isSupported > > I've changed this to support only 3 NIST curves when the library is disabled > >> 3. The native lib > > Similar to isSupported, if the property is false, it uses the native library > >> For a curve name rejected on each place, is there any behavior change? > > There should not be any with my latest changes that I have not put onto a webrev yet. Great. > >> Another thing: Even after the native lib is disabled, I think we can still create AlgorithmParameters and use KeyFactory to load a key when the curve is not supported, right? If the user has BouncyCastle in the provider list, I hope the Signature provider choosing fallback still works and a BC Signature object will be used when initialized with such a key. > > I don't know how much BC depends on SunEC. Right now the SunEC provider is returning AlgorithmsParameters supportedCurves property with the 3 NIST curves instead of all the curves in CurveDB that are disabled`. I think BC should not depend on SunEC, but CurveDB is in java.base. Thanks, Max > >> Thanks, >> Max >>> On Mar 4, 2020, at 3:42 AM, Anthony Scarpino wrote: >>> >>> On 3/3/20 11:18 AM, Sean Mullan wrote: >>>> On 3/3/20 1:42 PM, Anthony Scarpino wrote: >>>>> On 3/3/20 8:34 AM, Sean Mullan wrote: >>>>>> Wouldn't it be better to throw an Exception when you call Signature.initSign/Verify() and KeyAgreement.init() rather than waiting until you sign/verify or generateSecret? This way you bail out early before you start processing data. >>>>>> >>>>>> Also, throwing a ProviderException (a RuntimeException) could be a behavioral change that an application may not be prepared for. We have never done a very good job of documenting when ProviderException can be thrown by the JCE APIs, however. But we should think about this and whether maybe you want to throw InvalidKeyException instead which is already specified in the throws clause of the init methods. In any case it should be documented as a potential compatibility issue in the CSR. >>>>> >>>>> >>>>> Unfortunately curve support decisions are not made until the library is accessed. You will notice the checks that call native are not until the operation is starting, like engineSign(). If an unsupported curve is used in the existing code, this is where the error is generated from. The native code does generate an InvalidAlgorithmParameterException. I had chose ProviderException because it was a provider support change. I had thought about IAPE, but choose a bit more drastic action. That said, I'm fine with using IAPE. >>>> Hmm, but engineSign, engineVerify, engineGenerateSecret don't throw IAPE. >>> >>> The native code throws it and it's wrapped in a SignatureException. >>> >>> For generateKeyPair() the existing code threw a ProviderException because the method doesn't specify any exceptions. That probably pushed me toward ProviderException in other cases too. >>> >>>> I think it should probably be the same behavior as if the library did not exist. What do we throw now if the library has been removed? >>> >>> Maybe you missed one paragraph below? Without the library in the existing code we never got past getInstance() because those algorithms like SHA256withECDSA were not available. After Max's verify change, they are now. >>> >>>>> If one was to remove libsunec, the existing code disables algorithms like SHA256withECDSA which makes it easier to separate native from java implementations. But that is not true anymore with the java implementation supporting the NIST curves. Some of these same decisions affect both property disabling and library removal. >>>>> >>>>> In the past we have had similar Signature discussions before about when Signature.setParameter() being called before or after init(). I have to wonder if the original provider design followed the same logic where errors are generated later in the process. Also there are some decisions in this provider that look similar to SunPKCS11 as both wait until the last moment to ask the native library. >>>>> >>>>>> >>>>>> Did you consider documenting the system property in the API javadocs for Signature, KeyPairGenerator, KeyAgreement? I realize this is specific to the SunEC provider, but this would help users know how to enable the system property (on the hopefully rare case) they get an exception and still want to use one of these curves. It could be something like: >>>>>> >>>>>> @implNote By default, the SunEC provider throws ...Exception if the key is using a legacy curve. Set the {@systemProperty jdk.sunec.disableNative} to {@code false} to disable this behavior. >>>>>> >>>>> >>>>> I don't think putting in the API about one particular provider implementation detail is a proper place. I think this belongs in release notes, and maybe the provider doc. >>>> Yeah, I am kind of on the fence about that myself as I don't necessarily want to clutter the APIs with provider-specific stuff, but OTOH, most of the security-related system properties *are* provider-specific, so we lose the nice feature of seeing how different system properties affect existing APIs while you are reading the javadoc. But, I think we probably need to decide on a more general policy for documenting provider-specific system properties first. So I guess we can hold off on this for now. >>>> --Sean >>>>>> --Sean >>>>>> >>>>>> On 3/2/20 7:40 PM, Anthony Scarpino wrote: >>>>>>> Hi >>>>>>> >>>>>>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>>>>>> >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>>>>> >>>>>>> The curves affected are: >>>>>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>>>>> >>>>>>> Tony > From 1983-01-06 at gmx.net Thu Mar 5 07:49:07 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 5 Mar 2020 08:49:07 +0100 Subject: Confused by JDK-8200468 (Port the native GSS-API bridge to Windows) Message-ID: <815800b9-4a3c-d11f-39df-de424ffd8a53@gmx.net> Max, this ticket says: "Fix Version: 11". I can't see sspi_bridge.dll in any OpenJDK distribution for Windows with OpenJDK 11.0.6. Can you please clarify? Especially because there is: JDK-8234694 Michael From weijun.wang at oracle.com Thu Mar 5 08:42:21 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 5 Mar 2020 16:42:21 +0800 Subject: Confused by JDK-8200468 (Port the native GSS-API bridge to Windows) In-Reply-To: <815800b9-4a3c-d11f-39df-de424ffd8a53@gmx.net> References: <815800b9-4a3c-d11f-39df-de424ffd8a53@gmx.net> Message-ID: <4219B92A-CC50-4298-BA33-C56EE3815D58@oracle.com> Hi Michael, JDK-8200468 is for j2gss.dll. sspi_bridge.dll is JDK-6722928. Yes, JDK-8234694 is backport of JDK-6722928, but it seems the assignee has not started working on it. --Max > On Mar 5, 2020, at 3:49 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Max, > > this ticket says: "Fix Version: 11". I can't see sspi_bridge.dll in any > OpenJDK distribution for Windows with OpenJDK 11.0.6. > > Can you please clarify? Especially because there is: JDK-8234694 > > Michael From 1983-01-06 at gmx.net Thu Mar 5 08:48:56 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 5 Mar 2020 09:48:56 +0100 Subject: Confused by JDK-8200468 (Port the native GSS-API bridge to Windows) In-Reply-To: <4219B92A-CC50-4298-BA33-C56EE3815D58@oracle.com> References: <815800b9-4a3c-d11f-39df-de424ffd8a53@gmx.net> <4219B92A-CC50-4298-BA33-C56EE3815D58@oracle.com> Message-ID: Thanks, I completely missed that. So if sspi_bridge.dll will be 8u, this must be pulled first right? Michael PS: I have started testing sspi_bridge.dll at work at will provide a elaborated test result tomorrow or Monday. Am 2020-03-05 um 09:42 schrieb Weijun Wang: > Hi Michael, > > JDK-8200468 is for j2gss.dll. sspi_bridge.dll is JDK-6722928. > > Yes, JDK-8234694 is backport of JDK-6722928, but it seems the assignee has not started working on it. > > --Max > >> On Mar 5, 2020, at 3:49 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Max, >> >> this ticket says: "Fix Version: 11". I can't see sspi_bridge.dll in any >> OpenJDK distribution for Windows with OpenJDK 11.0.6. >> >> Can you please clarify? Especially because there is: JDK-8234694 >> >> Michael > From weijun.wang at oracle.com Thu Mar 5 09:03:33 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 5 Mar 2020 17:03:33 +0800 Subject: Confused by JDK-8200468 (Port the native GSS-API bridge to Windows) In-Reply-To: References: <815800b9-4a3c-d11f-39df-de424ffd8a53@gmx.net> <4219B92A-CC50-4298-BA33-C56EE3815D58@oracle.com> Message-ID: <8BA68B90-487D-4E59-AB5A-F510CEE7AB56@oracle.com> > On Mar 5, 2020, at 4:48 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Thanks, I completely missed that. So if sspi_bridge.dll will be 8u, this > must be pulled first right? Yes, sspi_bridge.dll is implemented as a native GSS library, it needs the native GSS bridge. The bridge has been in *nix for a long time and JDK-8200468 ported it to Windows. --Max > > Michael > > PS: I have started testing sspi_bridge.dll at work at will provide a > elaborated test result tomorrow or Monday. > > Am 2020-03-05 um 09:42 schrieb Weijun Wang: >> Hi Michael, >> >> JDK-8200468 is for j2gss.dll. sspi_bridge.dll is JDK-6722928. >> >> Yes, JDK-8234694 is backport of JDK-6722928, but it seems the assignee has not started working on it. >> >> --Max >> >>> On Mar 5, 2020, at 3:49 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>> >>> Max, >>> >>> this ticket says: "Fix Version: 11". I can't see sspi_bridge.dll in any >>> OpenJDK distribution for Windows with OpenJDK 11.0.6. >>> >>> Can you please clarify? Especially because there is: JDK-8234694 >>> >>> Michael >> > From anthony.scarpino at oracle.com Thu Mar 5 16:06:37 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 5 Mar 2020 08:06:37 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <0123288c-7865-c634-2a8d-ce6701fa6dba@oracle.com> <63988676-4410-980b-5788-a6d55d0a43d4@oracle.com> <124bf6a8-41e4-64d6-98b9-ffb4c1ee8ce0@oracle.com> <6AE068D0-8CEE-4C9E-9034-C760FE33C39D@oracle.com> <7a3c39af-b2e9-f35f-3a24-9c3721986f54@oracle.com> Message-ID: <8fb2aac7-b710-b656-9ab1-80d338ae172e@oracle.com> On 3/4/20 10:59 PM, Weijun Wang wrote: > >> On Mar 5, 2020, at 11:14 AM, Anthony Scarpino wrote: >> >> On 3/3/20 6:57 PM, Weijun Wang wrote: >>> We have 3 places checking for an algorithm now: >>> 1. If CurveDB does not know a curve, you won't be able to create parameters. >> >> Currently the CurveDB is unchanged. But when the library is removed, maybe it should be trimmed to only the 3 NIST curves? > > Maybe not. TLS uses it to find out the curve name for a ciphersuite name. if SunEC does not support the curve name it can still find it in BC. > > So there are 2 kinds of curves now: known curves, and SunEC supported curves. > > Or does this mean we can move CurveDB inside TLS, and only keep the name part (without the BigIntegers)? I'm thinking same. Name and OID may only be needed. > >> >>> 2. There is a ECKeyPairGenerator::isSupported >> >> I've changed this to support only 3 NIST curves when the library is disabled >> >>> 3. The native lib >> >> Similar to isSupported, if the property is false, it uses the native library >> >>> For a curve name rejected on each place, is there any behavior change? >> >> There should not be any with my latest changes that I have not put onto a webrev yet. > > Great. > >> >>> Another thing: Even after the native lib is disabled, I think we can still create AlgorithmParameters and use KeyFactory to load a key when the curve is not supported, right? If the user has BouncyCastle in the provider list, I hope the Signature provider choosing fallback still works and a BC Signature object will be used when initialized with such a key. >> >> I don't know how much BC depends on SunEC. Right now the SunEC provider is returning AlgorithmsParameters supportedCurves property with the 3 NIST curves instead of all the curves in CurveDB that are disabled`. > > I think BC should not depend on SunEC, but CurveDB is in java.base. > > Thanks, > Max > >> >>> Thanks, >>> Max >>>> On Mar 4, 2020, at 3:42 AM, Anthony Scarpino wrote: >>>> >>>> On 3/3/20 11:18 AM, Sean Mullan wrote: >>>>> On 3/3/20 1:42 PM, Anthony Scarpino wrote: >>>>>> On 3/3/20 8:34 AM, Sean Mullan wrote: >>>>>>> Wouldn't it be better to throw an Exception when you call Signature.initSign/Verify() and KeyAgreement.init() rather than waiting until you sign/verify or generateSecret? This way you bail out early before you start processing data. >>>>>>> >>>>>>> Also, throwing a ProviderException (a RuntimeException) could be a behavioral change that an application may not be prepared for. We have never done a very good job of documenting when ProviderException can be thrown by the JCE APIs, however. But we should think about this and whether maybe you want to throw InvalidKeyException instead which is already specified in the throws clause of the init methods. In any case it should be documented as a potential compatibility issue in the CSR. >>>>>> >>>>>> >>>>>> Unfortunately curve support decisions are not made until the library is accessed. You will notice the checks that call native are not until the operation is starting, like engineSign(). If an unsupported curve is used in the existing code, this is where the error is generated from. The native code does generate an InvalidAlgorithmParameterException. I had chose ProviderException because it was a provider support change. I had thought about IAPE, but choose a bit more drastic action. That said, I'm fine with using IAPE. >>>>> Hmm, but engineSign, engineVerify, engineGenerateSecret don't throw IAPE. >>>> >>>> The native code throws it and it's wrapped in a SignatureException. >>>> >>>> For generateKeyPair() the existing code threw a ProviderException because the method doesn't specify any exceptions. That probably pushed me toward ProviderException in other cases too. >>>> >>>>> I think it should probably be the same behavior as if the library did not exist. What do we throw now if the library has been removed? >>>> >>>> Maybe you missed one paragraph below? Without the library in the existing code we never got past getInstance() because those algorithms like SHA256withECDSA were not available. After Max's verify change, they are now. >>>> >>>>>> If one was to remove libsunec, the existing code disables algorithms like SHA256withECDSA which makes it easier to separate native from java implementations. But that is not true anymore with the java implementation supporting the NIST curves. Some of these same decisions affect both property disabling and library removal. >>>>>> >>>>>> In the past we have had similar Signature discussions before about when Signature.setParameter() being called before or after init(). I have to wonder if the original provider design followed the same logic where errors are generated later in the process. Also there are some decisions in this provider that look similar to SunPKCS11 as both wait until the last moment to ask the native library. >>>>>> >>>>>>> >>>>>>> Did you consider documenting the system property in the API javadocs for Signature, KeyPairGenerator, KeyAgreement? I realize this is specific to the SunEC provider, but this would help users know how to enable the system property (on the hopefully rare case) they get an exception and still want to use one of these curves. It could be something like: >>>>>>> >>>>>>> @implNote By default, the SunEC provider throws ...Exception if the key is using a legacy curve. Set the {@systemProperty jdk.sunec.disableNative} to {@code false} to disable this behavior. >>>>>>> >>>>>> >>>>>> I don't think putting in the API about one particular provider implementation detail is a proper place. I think this belongs in release notes, and maybe the provider doc. >>>>> Yeah, I am kind of on the fence about that myself as I don't necessarily want to clutter the APIs with provider-specific stuff, but OTOH, most of the security-related system properties *are* provider-specific, so we lose the nice feature of seeing how different system properties affect existing APIs while you are reading the javadoc. But, I think we probably need to decide on a more general policy for documenting provider-specific system properties first. So I guess we can hold off on this for now. >>>>> --Sean >>>>>>> --Sean >>>>>>> >>>>>>> On 3/2/20 7:40 PM, Anthony Scarpino wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>>>>>>> >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>>>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>>>>>> >>>>>>>> The curves affected are: >>>>>>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>>>>>> >>>>>>>> Tony >> > From alexey at azul.com Thu Mar 5 16:50:59 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 5 Mar 2020 16:50:59 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> Message-ID: <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> Hello Xuelei, I have renamed inputBuffer to recordBody. Also, as you suggested, recordBody is not removed but used for multiple records. So, it should be better for performance. JDK15 webrev: http://cr.openjdk.java.net/~dcherepanov/8239788/webrev.v5/ Regards Alexey > On 4 Mar 2020, at 21:23, Xuelei Fan wrote: > > > http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ > > SSLSocketInputRecord: > 54 // Cache for incomplete input record. > 55 private ByteBuffer inputBuffer = null; > This variable is used for record body, I may use a instinctive name, for example recordBody. > > Otherwise, looks good to me. > > I think, for performance, it may be possible to reuse this buffer for multiple records. I'd appreciate if you want to make an improvement in this update as well. > > Thanks, > Xuelei > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.mullan at oracle.com Fri Mar 6 17:31:44 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 6 Mar 2020 12:31:44 -0500 Subject: RFR [15]: 8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed" Message-ID: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> Please review this change to ProblemList 70 security tests while we diagnose the artifactory issues. See https://bugs.openjdk.java.net/browse/JDK-8240684 for more info. diff -r 1c40993361d0 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Mon Feb 24 19:03:34 2020 +0100 +++ b/test/jdk/ProblemList.txt Fri Mar 06 12:25:01 2020 -0500 @@ -722,6 +722,77 @@ sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 generic-all sun/security/provider/PolicyParser/PrincipalExpansionError.java 8039280 generic-all +sun/security/tools/keytool/NssTest.java 8240686 windows-all +sun/security/pkcs11/SampleTest.java 8240686 windows-all +sun/security/pkcs11/tls/TestPRF.java 8240686 windows-all +sun/security/pkcs11/tls/TestPremaster.java 8240686 windows-all +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8240686 windows-all +sun/security/pkcs11/tls/TestMasterSecret.java 8240686 windows-all +sun/security/pkcs11/tls/TestKeyMaterial.java 8240686 windows-all +sun/security/pkcs11/Signature/TestDSAKeyLength.java 8240686 windows-all +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8240686 windows-all +sun/security/pkcs11/Signature/TestDSA2.java 8240686 windows-all +sun/security/pkcs11/Signature/TestDSA.java 8240686 windows-all +sun/security/pkcs11/Signature/SignatureTestPSS.java 8240686 windows-all +sun/security/pkcs11/Signature/SigInteropPSS.java 8240686 windows-all +sun/security/pkcs11/Signature/ReinitSignature.java 8240686 windows-all +sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java 8240686 windows-all +sun/security/pkcs11/Signature/InitAgainPSS.java 8240686 windows-all +sun/security/pkcs11/Signature/ByteBuffers.java 8240686 windows-all +sun/security/pkcs11/Serialize/SerializeProvider.java 8240686 windows-all +sun/security/pkcs11/SecureRandom/TestDeserialization.java 8240686 windows-all +sun/security/pkcs11/SecureRandom/Basic.java 8240686 windows-all +sun/security/pkcs11/Secmod/TrustAnchors.java 8240686 windows-all +sun/security/pkcs11/Secmod/GetPrivateKey.java 8240686 windows-all +sun/security/pkcs11/Secmod/LoadKeystore.java 8240686 windows-all +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8240686 windows-all +sun/security/pkcs11/Secmod/JksSetPrivateKey.java 8240686 windows-all +sun/security/pkcs11/Secmod/Crypto.java 8240686 windows-all +sun/security/pkcs11/Secmod/AddTrustedCert.java 8240686 windows-all +sun/security/pkcs11/Secmod/AddPrivateKey.java 8240686 windows-all +sun/security/pkcs11/rsa/TestSignatures.java 8240686 windows-all +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8240686 windows-all +sun/security/pkcs11/rsa/TestKeyFactory.java 8240686 windows-all +sun/security/pkcs11/rsa/TestCACerts.java 8240686 windows-all +sun/security/pkcs11/rsa/KeyWrap.java 8240686 windows-all +sun/security/pkcs11/Provider/Login.sh 8240686 windows-all +sun/security/pkcs11/Provider/ConfigQuotedString.sh 8240686 windows-all +sun/security/pkcs11/MessageDigest/TestCloning.java 8240686 windows-all +sun/security/pkcs11/MessageDigest/ReinitDigest.java 8240686 windows-all +sun/security/pkcs11/MessageDigest/DigestKAT.java 8240686 windows-all +sun/security/pkcs11/Mac/MacKAT.java 8240686 windows-all +sun/security/pkcs11/Mac/MacSameTest.java 8240686 windows-all +sun/security/pkcs11/Mac/ReinitMac.java 8240686 windows-all +sun/security/pkcs11/MessageDigest/ByteBuffers.java 8240686 windows-all +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8240686 windows-all +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8240686 windows-all +sun/security/pkcs11/KeyGenerator/DESParity.java 8240686 windows-all +sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java 8240686 windows-all +sun/security/pkcs11/KeyAgreement/TestInterop.java 8240686 windows-all +sun/security/pkcs11/KeyAgreement/TestDH.java 8240686 windows-all +sun/security/pkcs11/KeyAgreement/TestShort.java 8240686 windows-all +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8240686 windows-all +sun/security/pkcs11/ec/TestECGenSpec.java 8240686 windows-all +sun/security/pkcs11/ec/TestECDSA2.java 8240686 windows-all +sun/security/pkcs11/ec/TestECDSA.java 8240686 windows-all +sun/security/pkcs11/ec/TestECDH2.java 8240686 windows-all +sun/security/pkcs11/ec/TestECDH.java 8240686 windows-all +sun/security/pkcs11/ec/TestCurves.java 8240686 windows-all +sun/security/pkcs11/ec/ReadPKCS12.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8240686 windows-all +sun/security/pkcs11/ec/ReadCertificates.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestRSACipher.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestKATForGCM.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java 8240686 windows-all +sun/security/pkcs11/Cipher/TestCICOWithGCM.java 8240686 windows-all +sun/security/pkcs11/Cipher/Test4512704.java 8240686 windows-all +sun/security/pkcs11/Cipher/ReinitCipher.java 8240686 windows-all + ############################################################################ # jdk_sound From Xuelei.Fan at Oracle.Com Fri Mar 6 17:51:48 2020 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 6 Mar 2020 09:51:48 -0800 Subject: RFR [15]: 8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed" In-Reply-To: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> References: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> Message-ID: <3DE18C0A-20A5-4D5B-88E3-219338219633@Oracle.Com> Looks fine to me. Xuelei > On Mar 6, 2020, at 9:31 AM, Sean Mullan wrote: > > Please review this change to ProblemList 70 security tests while we diagnose the artifactory issues. > > See https://bugs.openjdk.java.net/browse/JDK-8240684 for more info. > > diff -r 1c40993361d0 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Feb 24 19:03:34 2020 +0100 > +++ b/test/jdk/ProblemList.txt Fri Mar 06 12:25:01 2020 -0500 > @@ -722,6 +722,77 @@ > sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 generic-all > sun/security/provider/PolicyParser/PrincipalExpansionError.java 8039280 generic-all > > +sun/security/tools/keytool/NssTest.java 8240686 windows-all > +sun/security/pkcs11/SampleTest.java 8240686 windows-all > +sun/security/pkcs11/tls/TestPRF.java 8240686 windows-all > +sun/security/pkcs11/tls/TestPremaster.java 8240686 windows-all > +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8240686 windows-all > +sun/security/pkcs11/tls/TestMasterSecret.java 8240686 windows-all > +sun/security/pkcs11/tls/TestKeyMaterial.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSAKeyLength.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSA2.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSA.java 8240686 windows-all > +sun/security/pkcs11/Signature/SignatureTestPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/SigInteropPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/ReinitSignature.java 8240686 windows-all > +sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/InitAgainPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/ByteBuffers.java 8240686 windows-all > +sun/security/pkcs11/Serialize/SerializeProvider.java 8240686 windows-all > +sun/security/pkcs11/SecureRandom/TestDeserialization.java 8240686 windows-all > +sun/security/pkcs11/SecureRandom/Basic.java 8240686 windows-all > +sun/security/pkcs11/Secmod/TrustAnchors.java 8240686 windows-all > +sun/security/pkcs11/Secmod/GetPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/Secmod/LoadKeystore.java 8240686 windows-all > +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8240686 windows-all > +sun/security/pkcs11/Secmod/JksSetPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/Secmod/Crypto.java 8240686 windows-all > +sun/security/pkcs11/Secmod/AddTrustedCert.java 8240686 windows-all > +sun/security/pkcs11/Secmod/AddPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestSignatures.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestKeyFactory.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestCACerts.java 8240686 windows-all > +sun/security/pkcs11/rsa/KeyWrap.java 8240686 windows-all > +sun/security/pkcs11/Provider/Login.sh 8240686 windows-all > +sun/security/pkcs11/Provider/ConfigQuotedString.sh 8240686 windows-all > +sun/security/pkcs11/MessageDigest/TestCloning.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/ReinitDigest.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/DigestKAT.java 8240686 windows-all > +sun/security/pkcs11/Mac/MacKAT.java 8240686 windows-all > +sun/security/pkcs11/Mac/MacSameTest.java 8240686 windows-all > +sun/security/pkcs11/Mac/ReinitMac.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/ByteBuffers.java 8240686 windows-all > +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8240686 windows-all > +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8240686 windows-all > +sun/security/pkcs11/KeyGenerator/DESParity.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestInterop.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestDH.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestShort.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECGenSpec.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDSA2.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDSA.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDH2.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDH.java 8240686 windows-all > +sun/security/pkcs11/ec/TestCurves.java 8240686 windows-all > +sun/security/pkcs11/ec/ReadPKCS12.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8240686 windows-all > +sun/security/pkcs11/ec/ReadCertificates.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRSACipher.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestKATForGCM.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestCICOWithGCM.java 8240686 windows-all > +sun/security/pkcs11/Cipher/Test4512704.java 8240686 windows-all > +sun/security/pkcs11/Cipher/ReinitCipher.java 8240686 windows-all > + > ############################################################################ > > # jdk_sound From daniel.daugherty at oracle.com Fri Mar 6 17:53:30 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 6 Mar 2020 12:53:30 -0500 Subject: RFR [15]: 8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed" In-Reply-To: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> References: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> Message-ID: <555e7a90-bdda-21e5-7fd2-9f1377f928de@oracle.com> Thumbs up! Thanks for handling this. Dan On 3/6/20 12:31 PM, Sean Mullan wrote: > Please review this change to ProblemList 70 security tests while we > diagnose the artifactory issues. > > See https://bugs.openjdk.java.net/browse/JDK-8240684 for more info. > > diff -r 1c40993361d0 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Mon Feb 24 19:03:34 2020 +0100 > +++ b/test/jdk/ProblemList.txt? Fri Mar 06 12:25:01 2020 -0500 > @@ -722,6 +722,77 @@ > ?sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 > generic-all > ?sun/security/provider/PolicyParser/PrincipalExpansionError.java > 8039280 generic-all > > +sun/security/tools/keytool/NssTest.java 8240686 windows-all > +sun/security/pkcs11/SampleTest.java 8240686 windows-all > +sun/security/pkcs11/tls/TestPRF.java 8240686 windows-all > +sun/security/pkcs11/tls/TestPremaster.java 8240686 windows-all > +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8240686 windows-all > +sun/security/pkcs11/tls/TestMasterSecret.java 8240686 windows-all > +sun/security/pkcs11/tls/TestKeyMaterial.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSAKeyLength.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSA2.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSA.java 8240686 windows-all > +sun/security/pkcs11/Signature/SignatureTestPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/SigInteropPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/ReinitSignature.java 8240686 windows-all > +sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java 8240686 > windows-all > +sun/security/pkcs11/Signature/InitAgainPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/ByteBuffers.java 8240686 windows-all > +sun/security/pkcs11/Serialize/SerializeProvider.java 8240686 windows-all > +sun/security/pkcs11/SecureRandom/TestDeserialization.java 8240686 > windows-all > +sun/security/pkcs11/SecureRandom/Basic.java 8240686 windows-all > +sun/security/pkcs11/Secmod/TrustAnchors.java 8240686 windows-all > +sun/security/pkcs11/Secmod/GetPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/Secmod/LoadKeystore.java 8240686 windows-all > +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8240686 windows-all > +sun/security/pkcs11/Secmod/JksSetPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/Secmod/Crypto.java 8240686 windows-all > +sun/security/pkcs11/Secmod/AddTrustedCert.java 8240686 windows-all > +sun/security/pkcs11/Secmod/AddPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestSignatures.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestKeyFactory.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestCACerts.java 8240686 windows-all > +sun/security/pkcs11/rsa/KeyWrap.java 8240686 windows-all > +sun/security/pkcs11/Provider/Login.sh 8240686 windows-all > +sun/security/pkcs11/Provider/ConfigQuotedString.sh 8240686 windows-all > +sun/security/pkcs11/MessageDigest/TestCloning.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/ReinitDigest.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/DigestKAT.java 8240686 windows-all > +sun/security/pkcs11/Mac/MacKAT.java 8240686 windows-all > +sun/security/pkcs11/Mac/MacSameTest.java 8240686 windows-all > +sun/security/pkcs11/Mac/ReinitMac.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/ByteBuffers.java 8240686 windows-all > +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8240686 windows-all > +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8240686 > windows-all > +sun/security/pkcs11/KeyGenerator/DESParity.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java 8240686 > windows-all > +sun/security/pkcs11/KeyAgreement/TestInterop.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestDH.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestShort.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8240686 > windows-all > +sun/security/pkcs11/ec/TestECGenSpec.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDSA2.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDSA.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDH2.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDH.java 8240686 windows-all > +sun/security/pkcs11/ec/TestCurves.java 8240686 windows-all > +sun/security/pkcs11/ec/ReadPKCS12.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8240686 windows-all > +sun/security/pkcs11/ec/ReadCertificates.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRSACipher.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8240686 > windows-all > +sun/security/pkcs11/Cipher/TestKATForGCM.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java 8240686 > windows-all > +sun/security/pkcs11/Cipher/TestCICOWithGCM.java 8240686 windows-all > +sun/security/pkcs11/Cipher/Test4512704.java 8240686 windows-all > +sun/security/pkcs11/Cipher/ReinitCipher.java 8240686 windows-all > + > > ############################################################################ > > > ?# jdk_sound From sean.mullan at oracle.com Fri Mar 6 18:22:54 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 6 Mar 2020 13:22:54 -0500 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: Message-ID: It will take me a few iterations to review all of this, but here are some comments so far, mostly minor things: - src/java.base/share/classes/java/security/spec/NamedParameterSpec.java Need "@since 15" on the two new constants. (Assuming this goes in 15). - src/java.base/share/classes/sun/security/util/ArrayUtil.java 35 * This class holds various utility methods for arrays. The previous comment sounded more specific, why did you change it? - src/java.base/share/classes/sun/security/x509/AlgorithmId.java 906 public static ObjectIdentifier ed25519_oid = 907 ObjectIdentifier.of("1.3.101.112"); 908 public static ObjectIdentifier ed448_oid = 909 ObjectIdentifier.of("1.3.101.113"); Make them final. --Sean On 2/25/20 3:49 PM, Anthony Scarpino wrote: > Hi > > I need a code review for the EdDSA support in JEP 339.? The code builds > on the existing java implemented constant time classes used for XDH and > the NIST curves.? The change also adds classes to the public API to > support EdDSA operations. > > All information about the JEP is located at: > JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 > CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 > > webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ > > thanks > > Tony From anthony.scarpino at oracle.com Fri Mar 6 19:27:28 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 6 Mar 2020 11:27:28 -0800 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: Message-ID: <3ed760f4-4afc-d9a3-fdd8-1f2e067a7751@oracle.com> On 3/6/20 10:22 AM, Sean Mullan wrote: > It will take me a few iterations to review all of this, but here are > some comments so far, mostly minor things: > > - src/java.base/share/classes/java/security/spec/NamedParameterSpec.java > > Need "@since 15" on the two new constants. (Assuming this goes in 15). Ok > > - src/java.base/share/classes/sun/security/util/ArrayUtil.java > > ?35? * This class holds various utility methods for arrays. > > The previous comment sounded more specific, why did you change it? > I don't know why Adam changed that. I'll undo it, seem pointless > - src/java.base/share/classes/sun/security/x509/AlgorithmId.java > > ?906???? public static ObjectIdentifier ed25519_oid = > ?907???????? ObjectIdentifier.of("1.3.101.112"); > ?908???? public static ObjectIdentifier ed448_oid = > ?909???????? ObjectIdentifier.of("1.3.101.113"); > > Make them final. ok > > --Sean > > On 2/25/20 3:49 PM, Anthony Scarpino wrote: >> Hi >> >> I need a code review for the EdDSA support in JEP 339.? The code >> builds on the existing java implemented constant time classes used for >> XDH and the NIST curves.? The change also adds classes to the public >> API to support EdDSA operations. >> >> All information about the JEP is located at: >> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 >> >> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ >> >> thanks >> >> Tony From anthony.scarpino at oracle.com Fri Mar 6 20:04:11 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 6 Mar 2020 12:04:11 -0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: Webrev is updated and the CSR is updated with a comment if the property is false. https://cr.openjdk.java.net/~ascarpino/8237219/webrev.02 thanks Tony On 3/2/20 4:40 PM, Anthony Scarpino wrote: > Hi > > I need a review of the CSR and webrev for disabling by default the > native SunEC curves from the API.? With the recent verification changes > in JDK-8237218, SunJCE is long dependent on the native code for > verifying the constant-time curves.? This disabling can be undone with > setting a? system property, jdk.sunec.disableNative.? I'm doing a > simultaneous review as changes for one? will likely affect the other. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 > webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ > > The curves affected are: > secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, > sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, > sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, > sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 > c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 > c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 > prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, > brainpoolP512r1 > > Tony From RAJAN.HALADE at ORACLE.COM Sat Mar 7 04:00:13 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Fri, 6 Mar 2020 20:00:13 -0800 Subject: RFR: 8240686: 70 security tests are failing on Windows due to "Fetch artifact failed" Message-ID: <709561F1-00CB-4488-AB0E-2779BA45008E@ORACLE.COM> The fetch artifact issue is fixed within infra so these tests can be removed from ProblemList now. Please review this changeset: diff -r 7af6364e1792 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Fri Mar 06 18:03:09 2020 -0800 +++ b/test/jdk/ProblemList.txt Fri Mar 06 19:56:26 2020 -0800 @@ -722,77 +722,6 @@ sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 generic-all sun/security/provider/PolicyParser/PrincipalExpansionError.java 8039280 generic-all -sun/security/tools/keytool/NssTest.java 8240686 windows-all -sun/security/pkcs11/SampleTest.java 8240686 windows-all -sun/security/pkcs11/tls/TestPRF.java 8240686 windows-all -sun/security/pkcs11/tls/TestPremaster.java 8240686 windows-all -sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8240686 windows-all -sun/security/pkcs11/tls/TestMasterSecret.java 8240686 windows-all -sun/security/pkcs11/tls/TestKeyMaterial.java 8240686 windows-all -sun/security/pkcs11/Signature/TestDSAKeyLength.java 8240686 windows-all -sun/security/pkcs11/Signature/TestRSAKeyLength.java 8240686 windows-all -sun/security/pkcs11/Signature/TestDSA2.java 8240686 windows-all -sun/security/pkcs11/Signature/TestDSA.java 8240686 windows-all -sun/security/pkcs11/Signature/SignatureTestPSS.java 8240686 windows-all -sun/security/pkcs11/Signature/SigInteropPSS.java 8240686 windows-all -sun/security/pkcs11/Signature/ReinitSignature.java 8240686 windows-all -sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java 8240686 windows-all -sun/security/pkcs11/Signature/InitAgainPSS.java 8240686 windows-all -sun/security/pkcs11/Signature/ByteBuffers.java 8240686 windows-all -sun/security/pkcs11/Serialize/SerializeProvider.java 8240686 windows-all -sun/security/pkcs11/SecureRandom/TestDeserialization.java 8240686 windows-all -sun/security/pkcs11/SecureRandom/Basic.java 8240686 windows-all -sun/security/pkcs11/Secmod/TrustAnchors.java 8240686 windows-all -sun/security/pkcs11/Secmod/GetPrivateKey.java 8240686 windows-all -sun/security/pkcs11/Secmod/LoadKeystore.java 8240686 windows-all -sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8240686 windows-all -sun/security/pkcs11/Secmod/JksSetPrivateKey.java 8240686 windows-all -sun/security/pkcs11/Secmod/Crypto.java 8240686 windows-all -sun/security/pkcs11/Secmod/AddTrustedCert.java 8240686 windows-all -sun/security/pkcs11/Secmod/AddPrivateKey.java 8240686 windows-all -sun/security/pkcs11/rsa/TestSignatures.java 8240686 windows-all -sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8240686 windows-all -sun/security/pkcs11/rsa/TestKeyFactory.java 8240686 windows-all -sun/security/pkcs11/rsa/TestCACerts.java 8240686 windows-all -sun/security/pkcs11/rsa/KeyWrap.java 8240686 windows-all -sun/security/pkcs11/Provider/Login.sh 8240686 windows-all -sun/security/pkcs11/Provider/ConfigQuotedString.sh 8240686 windows-all -sun/security/pkcs11/MessageDigest/TestCloning.java 8240686 windows-all -sun/security/pkcs11/MessageDigest/ReinitDigest.java 8240686 windows-all -sun/security/pkcs11/MessageDigest/DigestKAT.java 8240686 windows-all -sun/security/pkcs11/Mac/MacKAT.java 8240686 windows-all -sun/security/pkcs11/Mac/MacSameTest.java 8240686 windows-all -sun/security/pkcs11/Mac/ReinitMac.java 8240686 windows-all -sun/security/pkcs11/MessageDigest/ByteBuffers.java 8240686 windows-all -sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8240686 windows-all -sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8240686 windows-all -sun/security/pkcs11/KeyGenerator/DESParity.java 8240686 windows-all -sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java 8240686 windows-all -sun/security/pkcs11/KeyAgreement/TestInterop.java 8240686 windows-all -sun/security/pkcs11/KeyAgreement/TestDH.java 8240686 windows-all -sun/security/pkcs11/KeyAgreement/TestShort.java 8240686 windows-all -sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8240686 windows-all -sun/security/pkcs11/ec/TestECGenSpec.java 8240686 windows-all -sun/security/pkcs11/ec/TestECDSA2.java 8240686 windows-all -sun/security/pkcs11/ec/TestECDSA.java 8240686 windows-all -sun/security/pkcs11/ec/TestECDH2.java 8240686 windows-all -sun/security/pkcs11/ec/TestECDH.java 8240686 windows-all -sun/security/pkcs11/ec/TestCurves.java 8240686 windows-all -sun/security/pkcs11/ec/ReadPKCS12.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestSymmCiphers.java 8240686 windows-all -sun/security/pkcs11/ec/ReadCertificates.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestRSACipher.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestRawRSACipher.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestKATForGCM.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java 8240686 windows-all -sun/security/pkcs11/Cipher/TestCICOWithGCM.java 8240686 windows-all -sun/security/pkcs11/Cipher/Test4512704.java 8240686 windows-all -sun/security/pkcs11/Cipher/ReinitCipher.java 8240686 windows-all - ############################################################################ # jdk_sound Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Mar 7 04:18:55 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 6 Mar 2020 20:18:55 -0800 Subject: RFR: 8240686: 70 security tests are failing on Windows due to "Fetch artifact failed" In-Reply-To: <709561F1-00CB-4488-AB0E-2779BA45008E@ORACLE.COM> References: <709561F1-00CB-4488-AB0E-2779BA45008E@ORACLE.COM> Message-ID: <03e29c19-9046-1bf1-91d6-e25139636603@oracle.com> Quick fix. Thanks for the update, which looks good to me. Xuelei On 3/6/2020 8:00 PM, Rajan Halade wrote: > The fetch artifact issue is fixed within infra so these tests can be > removed from ProblemList now. Please review this changeset: > > diff -r 7af6364e1792 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txtFri Mar 06 18:03:09 2020 -0800 > +++ b/test/jdk/ProblemList.txtFri Mar 06 19:56:26 2020 -0800 > @@ -722,77 +722,6 @@ > ?sun/security/provider/PolicyParser/ExtDirsChange.java > 8039280 generic-all > ?sun/security/provider/PolicyParser/PrincipalExpansionError.java > 8039280 generic-all > -sun/security/tools/keytool/NssTest.java ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/SampleTest.java ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/tls/TestPRF.java ? ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/tls/TestPremaster.java ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/tls/TestLeadingZeroesP11.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/tls/TestMasterSecret.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/tls/TestKeyMaterial.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/TestDSAKeyLength.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/TestRSAKeyLength.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/TestDSA2.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/TestDSA.java ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/SignatureTestPSS.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/SigInteropPSS.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/ReinitSignature.java ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/InitAgainPSS.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/ByteBuffers.java ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Serialize/SerializeProvider.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/SecureRandom/TestDeserialization.java ? ? ? 8240686 > windows-all > -sun/security/pkcs11/SecureRandom/Basic.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Secmod/TrustAnchors.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/GetPrivateKey.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Secmod/LoadKeystore.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/TestNssDbSqlite.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Secmod/JksSetPrivateKey.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/Crypto.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/AddTrustedCert.java ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/AddPrivateKey.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestSignatures.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestKeyPairGenerator.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestKeyFactory.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestCACerts.java ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/rsa/KeyWrap.java ? ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Provider/Login.sh ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Provider/ConfigQuotedString.sh ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/MessageDigest/TestCloning.java ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/MessageDigest/ReinitDigest.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/MessageDigest/DigestKAT.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Mac/MacKAT.java ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Mac/MacSameTest.java ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Mac/ReinitMac.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/MessageDigest/ByteBuffers.java ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyPairGenerator/TestDH2048.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyGenerator/DESParity.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/TestInterop.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/TestDH.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/TestShort.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECGenSpec.java ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECDSA2.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/ec/TestECDSA.java ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECDH2.java ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECDH.java ? ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/ec/TestCurves.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/ec/ReadPKCS12.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestSymmCiphers.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/ReadCertificates.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestRSACipherWrap.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestRSACipher.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestRawRSACipher.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestKATForGCM.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestCICOWithGCM.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/Test4512704.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/ReinitCipher.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > - > ?############################################################################ > ?# jdk_sound > > > > Thanks, > Rajan > From sean.mullan at oracle.com Mon Mar 9 12:05:42 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 9 Mar 2020 08:05:42 -0400 Subject: RFR: 8240686: 70 security tests are failing on Windows due to "Fetch artifact failed" In-Reply-To: <709561F1-00CB-4488-AB0E-2779BA45008E@ORACLE.COM> References: <709561F1-00CB-4488-AB0E-2779BA45008E@ORACLE.COM> Message-ID: <5a7d0f3f-4b5f-2888-a3c2-8a77bb5c9969@oracle.com> Hi Rajan, I see you already pushed the fix, but I was going to ask you to also make this small change to PKCS11Test.java so if this happens next time the cause of the failure won't be swallowed by the test, which made it harder to diagnose: diff -r 90c1d2c1f333 test/jdk/sun/security/pkcs11/PKCS11Test.java --- a/test/jdk/sun/security/pkcs11/PKCS11Test.java Fri Mar 06 13:17:03 2020 -0500 +++ b/test/jdk/sun/security/pkcs11/PKCS11Test.java Mon Mar 09 08:03:47 2020 -0400 @@ -901,7 +901,7 @@ + "please check if JIB jar is present in classpath."); } else { throw new RuntimeException("Fetch artifact failed: " + clazz - + "\nPlease make sure the artifact is available."); + + "\nPlease make sure the artifact is available.", e); } } Policy.setPolicy(null); // Clear the policy created by JIB if any Perhaps you could fix that separately. Thanks, Sean On 3/6/20 11:00 PM, Rajan Halade wrote: > The fetch artifact issue is fixed within infra so these tests can be > removed from ProblemList now. Please review this changeset: > > diff -r 7af6364e1792 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txtFri Mar 06 18:03:09 2020 -0800 > +++ b/test/jdk/ProblemList.txtFri Mar 06 19:56:26 2020 -0800 > @@ -722,77 +722,6 @@ > ?sun/security/provider/PolicyParser/ExtDirsChange.java > 8039280 generic-all > ?sun/security/provider/PolicyParser/PrincipalExpansionError.java > 8039280 generic-all > -sun/security/tools/keytool/NssTest.java ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/SampleTest.java ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/tls/TestPRF.java ? ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/tls/TestPremaster.java ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/tls/TestLeadingZeroesP11.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/tls/TestMasterSecret.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/tls/TestKeyMaterial.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/TestDSAKeyLength.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/TestRSAKeyLength.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/TestDSA2.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/TestDSA.java ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/SignatureTestPSS.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/SigInteropPSS.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/ReinitSignature.java ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/InitAgainPSS.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Signature/ByteBuffers.java ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Serialize/SerializeProvider.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/SecureRandom/TestDeserialization.java ? ? ? 8240686 > windows-all > -sun/security/pkcs11/SecureRandom/Basic.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Secmod/TrustAnchors.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/GetPrivateKey.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Secmod/LoadKeystore.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/TestNssDbSqlite.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Secmod/JksSetPrivateKey.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/Crypto.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/AddTrustedCert.java ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Secmod/AddPrivateKey.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestSignatures.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestKeyPairGenerator.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestKeyFactory.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/rsa/TestCACerts.java ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/rsa/KeyWrap.java ? ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Provider/Login.sh ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Provider/ConfigQuotedString.sh ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/MessageDigest/TestCloning.java ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/MessageDigest/ReinitDigest.java ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/MessageDigest/DigestKAT.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Mac/MacKAT.java ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Mac/MacSameTest.java ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Mac/ReinitMac.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/MessageDigest/ByteBuffers.java ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyPairGenerator/TestDH2048.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyGenerator/DESParity.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/TestInterop.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/TestDH.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/TestShort.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECGenSpec.java ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECDSA2.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/ec/TestECDSA.java ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECDH2.java ? ? ? ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/TestECDH.java ? ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/ec/TestCurves.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/ec/ReadPKCS12.java ? ? ? ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestSymmCiphers.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/ec/ReadCertificates.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestRSACipherWrap.java ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestRSACipher.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestRawRSACipher.java ? ? ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestKATForGCM.java ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java ? ? ? ? ? ?8240686 > windows-all > -sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/TestCICOWithGCM.java ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/Test4512704.java ? ? ? ? ? ? ? ? ? ? 8240686 > windows-all > -sun/security/pkcs11/Cipher/ReinitCipher.java ? ? ? ? ? ? ? ? ? ?8240686 > windows-all > - > ?############################################################################ > ?# jdk_sound > > > > Thanks, > Rajan > From weijun.wang at oracle.com Tue Mar 10 01:48:31 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Mar 2020 09:48:31 +0800 Subject: RFR 8239928: ec/ECDSAJavaVerify.java failed due to timeout In-Reply-To: References: Message-ID: A new webrev at http://cr.openjdk.java.net/~weijun/8239928/webrev.02/ Instead of checking if stderr is empty I now read the exit code. Some developer prints out debugging info in stderr. Finally, I give up fixing the test on Windows. Both dispose() and waitFor() could hang forever. Thanks, Max > On Mar 3, 2020, at 10:35 AM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8239928/webrev.01/ > > Looks like on windows-x64 there is a small probability (~.1%) that VMDisconnectEvent will not be caught (and thus no VMDisconnectedException). Fortunately, in the 2 failure cases I observed, the VMDeathEvent is still seen. > > Thanks, > Max > From weijun.wang at oracle.com Tue Mar 10 03:35:12 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Mar 2020 11:35:12 +0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: <2C1BEA0E-9EA4-484E-B32B-8B2D53050A3B@oracle.com> SunEC.java: - isJavaSupported() has a strange name - Is it better to put the javaSupportedCurves somewhere near fields and orderFields in ECOperations.java? Thus we can update it simultaneously in the future. Or at least add a comment somewhere? ECKeyPairGenerator.java: - Is it possible to implement the Java part of isSupported() based on ECParameterSpec instead of its getEncoded() form? KeySizeTest.java: - Do we need to enable native for the "SunEC EC 256" case? jarsigner/Spec.java: - I would suggest updating "kpg.initialize(192)" to use 256 and "kpg.initialize(571)" to use 521 instead of enabling the native lib SecurityTools.java: - I still don't like always enabling native and would rather only enable it when required (Ex: in test/jdk/sun/security/tools/keytool/GroupName.java). I'm now running a mach5 job to see how much impact it has. Otherwise fine to me. Thanks, Max > On Mar 7, 2020, at 4:04 AM, Anthony Scarpino wrote: > > Webrev is updated and the CSR is updated with a comment if the property is false. > > https://cr.openjdk.java.net/~ascarpino/8237219/webrev.02 > > thanks > > Tony > > On 3/2/20 4:40 PM, Anthony Scarpino wrote: >> Hi >> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >> The curves affected are: >> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >> Tony > From xuelei.fan at oracle.com Tue Mar 10 17:59:59 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Mar 2020 10:59:59 -0700 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> Message-ID: Looks fine to me. Thanks, Xuelei On 3/5/2020 8:50 AM, Alexey Bakhtin wrote: > Hello Xuelei, > > I have renamed inputBuffer to recordBody. > Also, as you suggested, recordBody is not removed but used for multiple records. So, it should be better for performance. > > JDK15 webrev: http://cr.openjdk.java.net/~dcherepanov/8239788/webrev.v5/ > > Regards > Alexey > >> On 4 Mar 2020, at 21:23, Xuelei Fan wrote: >> >>> http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ >> >> SSLSocketInputRecord: >> 54 // Cache for incomplete input record. >> 55 private ByteBuffer inputBuffer = null; >> This variable is used for record body, I may use a instinctive name, for example recordBody. >> >> Otherwise, looks good to me. >> >> I think, for performance, it may be possible to reuse this buffer for multiple records. I'd appreciate if you want to make an improvement in this update as well. >> >> Thanks, >> Xuelei >> > From anthony.scarpino at oracle.com Tue Mar 10 18:44:31 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 10 Mar 2020 11:44:31 -0700 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <2C1BEA0E-9EA4-484E-B32B-8B2D53050A3B@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> <2C1BEA0E-9EA4-484E-B32B-8B2D53050A3B@oracle.com> Message-ID: On 3/9/20 8:35 PM, Weijun Wang wrote: > SunEC.java: > > - isJavaSupported() has a strange name > > - Is it better to put the javaSupportedCurves somewhere near fields and orderFields in ECOperations.java? Thus we can update it simultaneously in the future. Or at least add a comment somewhere? > > ECKeyPairGenerator.java: > > - Is it possible to implement the Java part of isSupported() based on ECParameterSpec instead of its getEncoded() form? I'm going to try to rework it so the isSupported is replaced by ECOperations.forParameters(). This is similar to what is done for XDH and EdDSA. That would remove the isJavaSupported method. > > KeySizeTest.java: > > - Do we need to enable native for the "SunEC EC 256" case? No it shouldn't be necessary > > jarsigner/Spec.java: > > - I would suggest updating "kpg.initialize(192)" to use 256 and "kpg.initialize(571)" to use 521 instead of enabling the native lib I would rather leave them alone. The only reason is that native is still supported even though it's disabled and should still be tested. When the native library is removed, then this can be changed to 256 and 521. > > SecurityTools.java: > > - I still don't like always enabling native and would rather only enable it when required (Ex: in test/jdk/sun/security/tools/keytool/GroupName.java). I'm now running a mach5 job to see how much impact it has. I will look at it to see if it's a quick change, but I hesitant making many native specific changes in the tests because those same changes will be removed when the native library is removed. > > Otherwise fine to me. > > Thanks, > Max > >> On Mar 7, 2020, at 4:04 AM, Anthony Scarpino wrote: >> >> Webrev is updated and the CSR is updated with a comment if the property is false. >> >> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.02 >> >> thanks >> >> Tony >> >> On 3/2/20 4:40 PM, Anthony Scarpino wrote: >>> Hi >>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>> The curves affected are: >>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>> Tony >> > From valerie.peng at oracle.com Tue Mar 10 22:19:06 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 10 Mar 2020 15:19:06 -0700 Subject: RFR 8239928: ec/ECDSAJavaVerify.java failed due to timeout In-Reply-To: References: Message-ID: <2a7c3bd7-ac68-ba88-23a4-adcdc8d5d688@oracle.com> line 141: killme seems redundant? Else looks ok to me. Thanks, Valerie On 3/9/2020 6:48 PM, Weijun Wang wrote: > A new webrev at > > http://cr.openjdk.java.net/~weijun/8239928/webrev.02/ > > Instead of checking if stderr is empty I now read the exit code. Some developer prints out debugging info in stderr. > > Finally, I give up fixing the test on Windows. Both dispose() and waitFor() could hang forever. > > Thanks, > Max > > >> On Mar 3, 2020, at 10:35 AM, Weijun Wang wrote: >> >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/8239928/webrev.01/ >> >> Looks like on windows-x64 there is a small probability (~.1%) that VMDisconnectEvent will not be caught (and thus no VMDisconnectedException). Fortunately, in the 2 failure cases I observed, the VMDeathEvent is still seen. >> >> Thanks, >> Max >> From weijun.wang at oracle.com Wed Mar 11 02:35:25 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Mar 2020 10:35:25 +0800 Subject: RFR 8239928: ec/ECDSAJavaVerify.java failed due to timeout In-Reply-To: <2a7c3bd7-ac68-ba88-23a4-adcdc8d5d688@oracle.com> References: <2a7c3bd7-ac68-ba88-23a4-adcdc8d5d688@oracle.com> Message-ID: > On Mar 11, 2020, at 6:19 AM, Valerie Peng wrote: > > > line 141: killme seems redundant? Ah yes, thanks. --Max > > Else looks ok to me. > > Thanks, > > Valerie > > On 3/9/2020 6:48 PM, Weijun Wang wrote: >> A new webrev at >> >> http://cr.openjdk.java.net/~weijun/8239928/webrev.02/ >> >> Instead of checking if stderr is empty I now read the exit code. Some developer prints out debugging info in stderr. >> >> Finally, I give up fixing the test on Windows. Both dispose() and waitFor() could hang forever. >> >> Thanks, >> Max >> >> >>> On Mar 3, 2020, at 10:35 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> https://cr.openjdk.java.net/~weijun/8239928/webrev.01/ >>> >>> Looks like on windows-x64 there is a small probability (~.1%) that VMDisconnectEvent will not be caught (and thus no VMDisconnectedException). Fortunately, in the 2 failure cases I observed, the VMDeathEvent is still seen. >>> >>> Thanks, >>> Max >>> From alexey at azul.com Wed Mar 11 14:16:52 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 11 Mar 2020 14:16:52 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> Message-ID: Hello Xuelei, Thank you for review. Can I commit it to JDK15 and create backports to JDK 14, 13 and 11 ? Thank you Alexey > On 10 Mar 2020, at 20:59, Xuelei Fan wrote: > > Looks fine to me. > > Thanks, > Xuelei > > On 3/5/2020 8:50 AM, Alexey Bakhtin wrote: >> Hello Xuelei, >> I have renamed inputBuffer to recordBody. >> Also, as you suggested, recordBody is not removed but used for multiple records. So, it should be better for performance. >> JDK15 webrev: http://cr.openjdk.java.net/~dcherepanov/8239788/webrev.v5/ >> Regards >> Alexey >>> On 4 Mar 2020, at 21:23, Xuelei Fan wrote: >>> >>>> http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ >>> >>> SSLSocketInputRecord: >>> 54 // Cache for incomplete input record. >>> 55 private ByteBuffer inputBuffer = null; >>> This variable is used for record body, I may use a instinctive name, for example recordBody. >>> >>> Otherwise, looks good to me. >>> >>> I think, for performance, it may be possible to reuse this buffer for multiple records. I'd appreciate if you want to make an improvement in this update as well. >>> >>> Thanks, >>> Xuelei >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xuelei.fan at oracle.com Wed Mar 11 15:53:33 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Mar 2020 08:53:33 -0700 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> Message-ID: Hi Alexey, I had run the testing for you, no surprise. Please commit to JDK 15, and backport accordingly. Thanks, Xuelei On 3/11/2020 7:16 AM, Alexey Bakhtin wrote: > Hello Xuelei, > > Thank you for review. > Can I commit it to JDK15 and create backports to JDK 14, 13 and 11 ? > > Thank you > Alexey > >> On 10 Mar 2020, at 20:59, Xuelei Fan wrote: >> >> Looks fine to me. >> >> Thanks, >> Xuelei >> >> On 3/5/2020 8:50 AM, Alexey Bakhtin wrote: >>> Hello Xuelei, >>> I have renamed inputBuffer to recordBody. >>> Also, as you suggested, recordBody is not removed but used for multiple records. So, it should be better for performance. >>> JDK15 webrev: http://cr.openjdk.java.net/~dcherepanov/8239788/webrev.v5/ >>> Regards >>> Alexey >>>> On 4 Mar 2020, at 21:23, Xuelei Fan wrote: >>>> >>>>> http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ >>>> >>>> SSLSocketInputRecord: >>>> 54 // Cache for incomplete input record. >>>> 55 private ByteBuffer inputBuffer = null; >>>> This variable is used for record body, I may use a instinctive name, for example recordBody. >>>> >>>> Otherwise, looks good to me. >>>> >>>> I think, for performance, it may be possible to reuse this buffer for multiple records. I'd appreciate if you want to make an improvement in this update as well. >>>> >>>> Thanks, >>>> Xuelei >>>> > From valerie.peng at oracle.com Wed Mar 11 20:31:52 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 11 Mar 2020 13:31:52 -0700 Subject: RFR: 8238566: java.security.Provider$Service.supportsParameter() is racy In-Reply-To: References: Message-ID: Anyone can help reviewing this? I addressed this by applying the double-checked-locking pattern for lazy initialization of instance fields. Existing code already have most of the code structured for the pattern but misses the second check. Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 Webrev: http://cr.openjdk.java.net/~valeriep/8238566/webrev.00/ Thanks, Valerie On 2/5/2020 12:49 PM, Arthur Eubanks wrote: > Webrev: http://cr.openjdk.java.net/~aeubanks/8238566/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 > > Found by TSAN, java.security.Provider$Service.supportsParameter() is > racy. We haven't observed any actual bad behavior, but reasoning > through it seems like bad behavior is possible. > > http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927 > > The synchronized block seems to not have any effect on correctness. > > Example race: > T1 in hasKeyAttributes() writes true to hasKeyAttributes and fills out > supportedFormats/supportedClasses. > > T2 in hasKeyAttributes() racily reads hasKeyAttributes as true, but > then in supportsKeyFormat() racily reads supportedFormats as null. It > can then improperly return false from supportsParameter(). > There is no synchronization between T1 and T2 because T2 never does > any synchronization, so T2 can read what T1 writes in any order. > > Fix is to make all of?hasKeyAttributes() synchronized. From xuelei.fan at oracle.com Wed Mar 11 20:47:13 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Mar 2020 13:47:13 -0700 Subject: RFR: 8238566: java.security.Provider$Service.supportsParameter() is racy In-Reply-To: References: Message-ID: Looks fine to me. Xuelei On 3/11/2020 1:31 PM, Valerie Peng wrote: > > Anyone can help reviewing this? > > I addressed this by applying the double-checked-locking pattern for lazy > initialization of instance fields. > > Existing code already have most of the code structured for the pattern > but misses the second check. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 > > Webrev: http://cr.openjdk.java.net/~valeriep/8238566/webrev.00/ > > Thanks, > > Valerie > > On 2/5/2020 12:49 PM, Arthur Eubanks wrote: >> Webrev: http://cr.openjdk.java.net/~aeubanks/8238566/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 >> >> Found by TSAN, java.security.Provider$Service.supportsParameter() is >> racy. We haven't observed any actual bad behavior, but reasoning >> through it seems like bad behavior is possible. >> >> http://hg.openjdk.java.net/jdk/jdk/file/62b5bfef8d61/src/java.base/share/classes/java/security/Provider.java#l1927 >> >> >> The synchronized block seems to not have any effect on correctness. >> >> Example race: >> T1 in hasKeyAttributes() writes true to hasKeyAttributes and fills out >> supportedFormats/supportedClasses. >> >> T2 in hasKeyAttributes() racily reads hasKeyAttributes as true, but >> then in supportsKeyFormat() racily reads supportedFormats as null. It >> can then improperly return false from supportsParameter(). >> There is no synchronization between T1 and T2 because T2 never does >> any synchronization, so T2 can read what T1 writes in any order. >> >> Fix is to make all of?hasKeyAttributes() synchronized. From anthony.scarpino at oracle.com Thu Mar 12 06:23:29 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 11 Mar 2020 23:23:29 -0700 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: Another webrev update with Max's recent comments. https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 Also I still need a reviewer for the CSR. thanks Tony On 3/2/20 4:40 PM, Anthony Scarpino wrote: > Hi > > I need a review of the CSR and webrev for disabling by default the > native SunEC curves from the API.? With the recent verification changes > in JDK-8237218, SunJCE is long dependent on the native code for > verifying the constant-time curves.? This disabling can be undone with > setting a? system property, jdk.sunec.disableNative.? I'm doing a > simultaneous review as changes for one? will likely affect the other. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 > webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ > > The curves affected are: > secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, > sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, > sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, > sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 > c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 > c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 > prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, > brainpoolP512r1 > > Tony From daniel.fuchs at oracle.com Thu Mar 12 11:35:19 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Mar 2020 11:35:19 +0000 Subject: RFR: 8238566: java.security.Provider$Service.supportsParameter() is racy In-Reply-To: References: Message-ID: <386d5597-b5ae-3789-932a-d36b20dcc0fb@oracle.com> Hi Valerie, Given that hasKeyAttributes is already decelared as volatile, may I suggest the following change that uses double locking? It will avoid synchronizing in the happy case where `hasKeyAttributes` has already been computed. 1924 private boolean hasKeyAttributes() { 1925 Boolean b = hasKeyAttributes; if (b != null) return b; synchronized (this) { b = hasKeyAttributes; 1926 if (b != null) return b; 1927 String s; 1928 s = getAttribute("SupportedKeyFormats"); ... 1948 hasKeyAttributes = b; 1949 } 1950 return b; 1951 } best regards, -- daniel On 11/03/2020 20:31, Valerie Peng wrote: > > Anyone can help reviewing this? > > I addressed this by applying the double-checked-locking pattern for lazy > initialization of instance fields. > > Existing code already have most of the code structured for the pattern > but misses the second check. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 > > Webrev: http://cr.openjdk.java.net/~valeriep/8238566/webrev.00/ > > Thanks, > > Valerie From daniel.fuchs at oracle.com Thu Mar 12 11:42:23 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Mar 2020 11:42:23 +0000 Subject: RFR: 8238566: java.security.Provider$Service.supportsParameter() is racy In-Reply-To: <386d5597-b5ae-3789-932a-d36b20dcc0fb@oracle.com> References: <386d5597-b5ae-3789-932a-d36b20dcc0fb@oracle.com> Message-ID: Hi Valerie, Please ignore my comment. Sorry for the noise. I somehow clicked on the wrong webrev link :-( best regards, -- daniel On 12/03/2020 11:35, Daniel Fuchs wrote: > Hi Valerie, > > Given that hasKeyAttributes is already decelared as volatile, > may I suggest the following change that uses double locking? > It will? avoid synchronizing in the happy case where `hasKeyAttributes` > has already been computed. > > 1924???????? private boolean hasKeyAttributes() { > 1925???????????? Boolean b = hasKeyAttributes; > ???????????????? if (b != null) return b; > ???????????????? synchronized (this) { > ???????????????????? b = hasKeyAttributes; > 1926???????????????? if (b != null) return b; > 1927???????????????? String s; > 1928???????????????? s = getAttribute("SupportedKeyFormats"); > > ???????????????????? ... > > 1948???????????????? hasKeyAttributes = b; > 1949???????????? } > 1950???????????? return b; > 1951???????? } > > > best regards, > > -- daniel > > On 11/03/2020 20:31, Valerie Peng wrote: >> >> Anyone can help reviewing this? >> >> I addressed this by applying the double-checked-locking pattern for >> lazy initialization of instance fields. >> >> Existing code already have most of the code structured for the pattern >> but misses the second check. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8238566/webrev.00/ >> >> Thanks, >> >> Valerie From weijun.wang at oracle.com Thu Mar 12 13:21:26 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Mar 2020 21:21:26 +0800 Subject: RFR 8240848: ArrayIndexOutOfBoundsException buf for TextCallbackHandler Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8240848/webrev.00/ The problem is that selection has a different meaning for a specified optionType (the option value) and an unspecified one (the option index). I also take this chance to make ConfirmationCallback more robust. Thanks, Max From sean.mullan at oracle.com Thu Mar 12 15:10:59 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Mar 2020 11:10:59 -0400 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: Message-ID: Here are some more comments, all minor. I will probably need one more round of review. - src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java 362 /* XDH does not require native implementation */ Looks like a cut-paste error. I think you can remove this line. - src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java - src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java - src/java.base/share/classes/java/security/spec/EdECPoint.java In the class description of these 3 classes, you are missing a

at the start of the 2nd paragraph. Otherwise when you generate javadoc, it won't create a new paragraph. - src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java 71 * @param context the context that is bound to the signature This should probably say that the parameter is copied. Also getContext() should say that it returns a copy (if not null). 92 * Get the context that should be used, if any Missing period at end of sentence. - src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAPublicKeyImpl.java 58 // set the high-order bit of the .. of the ? 73 // construct the EdECPoint representation 74 This comment applies to code after line 74, so I think it would make more sense if you removed line 74 and added a blank line before 73. - src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdECOperations.java It would be useful to have some additional comments in this code. --Sean On 2/25/20 3:49 PM, Anthony Scarpino wrote: > Hi > > I need a code review for the EdDSA support in JEP 339.? The code builds > on the existing java implemented constant time classes used for XDH and > the NIST curves.? The change also adds classes to the public API to > support EdDSA operations. > > All information about the JEP is located at: > JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 > CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 > > webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ > > thanks > > Tony From xuelei.fan at oracle.com Thu Mar 12 16:47:29 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Mar 2020 09:47:29 -0700 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs Message-ID: Hi, Could I get the following update reviewed? CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ The legacy javax.security.cert APIs and the dependent were initially deprecated in Java SE 9 and marked for removal in Java SE 13. Applications should use the java.security.cert APIs for now. This is a request to remove the deprecated javax.security.cert APIs. The use of the legacy APIs should be rare now. But please let me know if you have concerns before March 19, 2019. Thanks & Regards, Xuelei From xuelei.fan at oracle.com Thu Mar 12 17:34:21 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Mar 2020 10:34:21 -0700 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: Message-ID: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> And the release note task: https://bugs.openjdk.java.net/browse/JDK-8240968 Xuelei On 3/12/2020 9:47 AM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 > Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ > > The legacy javax.security.cert APIs and the dependent were initially > deprecated in Java SE 9 and marked for removal in Java SE 13. > Applications should use the java.security.cert APIs for now.? This is a > request to remove the deprecated javax.security.cert APIs. > > The use of the legacy APIs should be rare now.? But please let me know > if you have concerns before March 19, 2019. > > Thanks & Regards, > Xuelei From xuelei.fan at oracle.com Thu Mar 12 17:39:28 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Mar 2020 10:39:28 -0700 Subject: RFR JDK-8219989 : Retire the com.sun.net.ssl.internal.ssl.Provider name Message-ID: <99cdc44f-76b0-93b3-fb99-dddf2c407e8d@oracle.com> Hi, Could I get the following update reviewed? Bug#: https://bugs.openjdk.java.net/browse/JDK-8219989 Webrev: http://cr.openjdk.java.net/~xuelei/8219989/webrev.00/ Release note task: https://bugs.openjdk.java.net/browse/JDK-8240967 This is a request to remove the legacy SunJSSE provider name, "com.sun.net.ssl.internal.ssl.Provider". The "SunJSSE" should be used instead (for example, "SSLContext.getInstance("TLS", "SunJSSE")"). The use of the legacy provider name should be rare now. But please let me know if you have concerns before March 19, 2019. Thanks, Xuelei From hai-may.chao at oracle.com Thu Mar 12 20:04:48 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Thu, 12 Mar 2020 13:04:48 -0700 Subject: RFR JDK-8219989 : Retire the com.sun.net.ssl.internal.ssl.Provider name In-Reply-To: <99cdc44f-76b0-93b3-fb99-dddf2c407e8d@oracle.com> References: <99cdc44f-76b0-93b3-fb99-dddf2c407e8d@oracle.com> Message-ID: Hi Xuelei, Looks good to me. Hai-May > On Mar 12, 2020, at 10:39 AM, Xuelei Fan wrote: > > Hi, > > Could I get the following update reviewed? > > Bug#: https://bugs.openjdk.java.net/browse/JDK-8219989 > Webrev: http://cr.openjdk.java.net/~xuelei/8219989/webrev.00/ > Release note task: https://bugs.openjdk.java.net/browse/JDK-8240967 > > This is a request to remove the legacy SunJSSE provider name, "com.sun.net.ssl.internal.ssl.Provider". The "SunJSSE" should be used instead (for example, "SSLContext.getInstance("TLS", "SunJSSE")"). > > The use of the legacy provider name should be rare now. But please let me know if you have concerns before March 19, 2019. > > Thanks, > Xuelei From hai-may.chao at oracle.com Thu Mar 12 20:07:40 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Thu, 12 Mar 2020 13:07:40 -0700 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> References: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> Message-ID: <343C2374-BA6C-4CFF-AA94-77D6D210D73B@oracle.com> Hi Xuelei, Looks good to me. Hai-May > On Mar 12, 2020, at 10:34 AM, Xuelei Fan wrote: > > And the release note task: > https://bugs.openjdk.java.net/browse/JDK-8240968 > > Xuelei > > On 3/12/2020 9:47 AM, Xuelei Fan wrote: >> Hi, >> Could I get the following update reviewed? >> CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 >> Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ >> The legacy javax.security.cert APIs and the dependent were initially deprecated in Java SE 9 and marked for removal in Java SE 13. Applications should use the java.security.cert APIs for now. This is a request to remove the deprecated javax.security.cert APIs. >> The use of the legacy APIs should be rare now. But please let me know if you have concerns before March 19, 2019. >> Thanks & Regards, >> Xuelei From sean.mullan at oracle.com Thu Mar 12 21:29:19 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Mar 2020 17:29:19 -0400 Subject: RFR JDK-8219989 : Retire the com.sun.net.ssl.internal.ssl.Provider name In-Reply-To: <99cdc44f-76b0-93b3-fb99-dddf2c407e8d@oracle.com> References: <99cdc44f-76b0-93b3-fb99-dddf2c407e8d@oracle.com> Message-ID: The fix looks good, although I think you should also file a CSR since this provider name was at one time documented and supported and you mentioned that it was still supported in the previous CSR when the com.sun.net.ssl package was removed [1]. Thanks, Sean [1] https://bugs.openjdk.java.net/browse/JDK-8218932 On 3/12/20 1:39 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > Bug#:?? https://bugs.openjdk.java.net/browse/JDK-8219989 > Webrev: http://cr.openjdk.java.net/~xuelei/8219989/webrev.00/ > Release note task: https://bugs.openjdk.java.net/browse/JDK-8240967 > > This is a request to remove the legacy SunJSSE provider name, > "com.sun.net.ssl.internal.ssl.Provider".? The "SunJSSE" should be used > instead (for example, "SSLContext.getInstance("TLS", "SunJSSE")"). > > The use of the legacy provider name should be rare now.? But please let > me know if you have concerns before March 19, 2019. > > Thanks, > Xuelei From sean.mullan at oracle.com Thu Mar 12 21:34:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Mar 2020 17:34:57 -0400 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: Message-ID: <19e4e19e-f825-bcf5-39f1-153d366bb575@oracle.com> Looks good to me. --Sean On 3/12/20 12:47 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 > Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ > > The legacy javax.security.cert APIs and the dependent were initially > deprecated in Java SE 9 and marked for removal in Java SE 13. > Applications should use the java.security.cert APIs for now.? This is a > request to remove the deprecated javax.security.cert APIs. > > The use of the legacy APIs should be rare now.? But please let me know > if you have concerns before March 19, 2019. > > Thanks & Regards, > Xuelei From valerie.peng at oracle.com Thu Mar 12 21:42:57 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 Mar 2020 14:42:57 -0700 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: Message-ID: Hi Xuelei, Changes look good. It may be worthwhile for the CSR to mention that there are existing methods which replace the to-be-removed ones so apps have a migration path. Thanks, Valerie On 3/12/2020 9:47 AM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 > Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ > > The legacy javax.security.cert APIs and the dependent were initially > deprecated in Java SE 9 and marked for removal in Java SE 13. > Applications should use the java.security.cert APIs for now.? This is > a request to remove the deprecated javax.security.cert APIs. > > The use of the legacy APIs should be rare now.? But please let me know > if you have concerns before March 19, 2019. > > Thanks & Regards, > Xuelei From valerie.peng at oracle.com Thu Mar 12 21:49:14 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 Mar 2020 14:49:14 -0700 Subject: RFR: 8238566: java.security.Provider$Service.supportsParameter() is racy In-Reply-To: References: <386d5597-b5ae-3789-932a-d36b20dcc0fb@oracle.com> Message-ID: No problem, thanks for double checking. ;) Valerie On 3/12/2020 4:42 AM, Daniel Fuchs wrote: > Hi Valerie, > > Please ignore my comment. Sorry for the noise. > I somehow clicked on the wrong webrev link :-( > > best regards, > > -- daniel > > On 12/03/2020 11:35, Daniel Fuchs wrote: >> Hi Valerie, >> >> Given that hasKeyAttributes is already decelared as volatile, >> may I suggest the following change that uses double locking? >> It will? avoid synchronizing in the happy case where `hasKeyAttributes` >> has already been computed. >> >> 1924???????? private boolean hasKeyAttributes() { >> 1925???????????? Boolean b = hasKeyAttributes; >> ????????????????? if (b != null) return b; >> ????????????????? synchronized (this) { >> ????????????????????? b = hasKeyAttributes; >> 1926???????????????? if (b != null) return b; >> 1927???????????????? String s; >> 1928???????????????? s = getAttribute("SupportedKeyFormats"); >> >> ????????????????????? ... >> >> 1948???????????????? hasKeyAttributes = b; >> 1949???????????? } >> 1950???????????? return b; >> 1951???????? } >> >> >> best regards, >> >> -- daniel >> >> On 11/03/2020 20:31, Valerie Peng wrote: >>> >>> Anyone can help reviewing this? >>> >>> I addressed this by applying the double-checked-locking pattern for >>> lazy initialization of instance fields. >>> >>> Existing code already have most of the code structured for the >>> pattern but misses the second check. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238566 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8238566/webrev.00/ >>> >>> Thanks, >>> >>> Valerie > From xuelei.fan at oracle.com Thu Mar 12 21:50:08 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Mar 2020 14:50:08 -0700 Subject: RFR JDK-8219989 : Retire the com.sun.net.ssl.internal.ssl.Provider name In-Reply-To: References: <99cdc44f-76b0-93b3-fb99-dddf2c407e8d@oracle.com> Message-ID: <53acab02-849a-bd70-0768-a0d2bc64f557@oracle.com> Good to have a CSR. Please review: CSR: https://bugs.openjdk.java.net/browse/JDK-8240974 Thanks, Xuelei On 3/12/2020 2:29 PM, Sean Mullan wrote: > The fix looks good, although I think you should also file a CSR since > this provider name was at one time documented and supported and you > mentioned that it was still supported in the previous CSR when the > com.sun.net.ssl package was removed [1]. > > Thanks, > Sean > > [1] https://bugs.openjdk.java.net/browse/JDK-8218932 > > On 3/12/20 1:39 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> Bug#:?? https://bugs.openjdk.java.net/browse/JDK-8219989 >> Webrev: http://cr.openjdk.java.net/~xuelei/8219989/webrev.00/ >> Release note task: https://bugs.openjdk.java.net/browse/JDK-8240967 >> >> This is a request to remove the legacy SunJSSE provider name, >> "com.sun.net.ssl.internal.ssl.Provider".? The "SunJSSE" should be used >> instead (for example, "SSLContext.getInstance("TLS", "SunJSSE")"). >> >> The use of the legacy provider name should be rare now.? But please >> let me know if you have concerns before March 19, 2019. >> >> Thanks, >> Xuelei From weijun.wang at oracle.com Fri Mar 13 09:44:29 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Mar 2020 17:44:29 +0800 Subject: RFR 8240983: Incorrect copyright header in Apache Santuario files Message-ID: Please review the patch below. Unlike Sun, Oracle has no "Portions" copyright notice for Third Party source file changes, just add the standard Oracle copyright notice if a file has been modified. diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java --- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java +++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java @@ -21,7 +21,7 @@ * under the License. */ /* - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. */ /* * =========================================================================== diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java --- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java +++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java @@ -21,7 +21,7 @@ * under the License. */ /* - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. */ /* * =========================================================================== diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java --- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java +++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java @@ -21,7 +21,7 @@ * under the License. */ /* - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. */ /* * =========================================================================== diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java --- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java +++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java @@ -28,7 +28,7 @@ * =========================================================================== */ /* - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. */ /* * $Id: DOMXPathFilter2Transform.java 1854026 2019-02-21 09:30:01Z coheigea $ diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java --- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java +++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java @@ -28,7 +28,7 @@ * =========================================================================== */ /* - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. */ /* * $Id: XMLDSigRI.java 1833618 2018-06-15 17:36:20Z mullan $ Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Mar 13 12:13:09 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Mar 2020 08:13:09 -0400 Subject: RFR 8240983: Incorrect copyright header in Apache Santuario files In-Reply-To: References: Message-ID: <3cfa03b7-765c-030c-f7e0-003fe216a7a9@oracle.com> Looks fine. --Sean On 3/13/20 5:44 AM, Weijun Wang wrote: > Please review the patch below. Unlike Sun, Oracle has no "Portions" > copyright notice for Third Party source file changes, just add the > standard Oracle copyright notice if a file has been modified. > > *diff --git > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* > *--- > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* > *+++ > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* > @@ -21,7 +21,7 @@ > ? * under the License. > ? */ > ?/* > - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * > =========================================================================== > *diff --git > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* > *--- > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* > *+++ > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* > @@ -21,7 +21,7 @@ > ? * under the License. > ? */ > ?/* > - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * > =========================================================================== > *diff --git > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* > *--- > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* > *+++ > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* > @@ -21,7 +21,7 @@ > ? * under the License. > ? */ > ?/* > - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * > =========================================================================== > *diff --git > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* > *--- > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* > *+++ > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* > @@ -28,7 +28,7 @@ > ? * > =========================================================================== > ? */ > ?/* > - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * $Id: DOMXPathFilter2Transform.java 1854026 2019-02-21 09:30:01Z > coheigea $ > *diff --git > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* > *--- > a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* > *+++ > b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* > @@ -28,7 +28,7 @@ > ? * > =========================================================================== > ? */ > ?/* > - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? */ > ?/* > ? * $Id: XMLDSigRI.java 1833618 2018-06-15 17:36:20Z mullan $ > > Thanks, > Max > From sean.mullan at oracle.com Fri Mar 13 12:17:42 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Mar 2020 08:17:42 -0400 Subject: RFR 8240983: Incorrect copyright header in Apache Santuario files In-Reply-To: <3cfa03b7-765c-030c-f7e0-003fe216a7a9@oracle.com> References: <3cfa03b7-765c-030c-f7e0-003fe216a7a9@oracle.com> Message-ID: <9d34aeff-7850-796c-e484-616cb64f1aa8@oracle.com> One comment actually - you need to add a noreg label to the bug. --Sean On 3/13/20 8:13 AM, Sean Mullan wrote: > Looks fine. > > --Sean > > On 3/13/20 5:44 AM, Weijun Wang wrote: >> Please review the patch below. Unlike Sun, Oracle has no "Portions" >> copyright notice for Third Party source file changes, just add the >> standard Oracle copyright notice if a file has been modified. >> >> *diff --git >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* >> >> *--- >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* >> >> *+++ >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* >> >> @@ -21,7 +21,7 @@ >> ?? * under the License. >> ?? */ >> ??/* >> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. >> All rights reserved. >> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights >> reserved. >> ?? */ >> ??/* >> ?? * >> =========================================================================== >> >> *diff --git >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* >> >> *--- >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* >> >> *+++ >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* >> >> @@ -21,7 +21,7 @@ >> ?? * under the License. >> ?? */ >> ??/* >> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. >> All rights reserved. >> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights >> reserved. >> ?? */ >> ??/* >> ?? * >> =========================================================================== >> >> *diff --git >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* >> >> *--- >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* >> >> *+++ >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* >> >> @@ -21,7 +21,7 @@ >> ?? * under the License. >> ?? */ >> ??/* >> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. >> All rights reserved. >> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights >> reserved. >> ?? */ >> ??/* >> ?? * >> =========================================================================== >> >> *diff --git >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* >> >> *--- >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* >> >> *+++ >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* >> >> @@ -28,7 +28,7 @@ >> ?? * >> =========================================================================== >> >> ?? */ >> ??/* >> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. >> All rights reserved. >> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights >> reserved. >> ?? */ >> ??/* >> ?? * $Id: DOMXPathFilter2Transform.java 1854026 2019-02-21 09:30:01Z >> coheigea $ >> *diff --git >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* >> >> *--- >> a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* >> >> *+++ >> b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* >> >> @@ -28,7 +28,7 @@ >> ?? * >> =========================================================================== >> >> ?? */ >> ??/* >> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. >> All rights reserved. >> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights >> reserved. >> ?? */ >> ??/* >> ?? * $Id: XMLDSigRI.java 1833618 2018-06-15 17:36:20Z mullan $ >> >> Thanks, >> Max >> From weijun.wang at oracle.com Fri Mar 13 13:37:05 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Mar 2020 21:37:05 +0800 Subject: RFR 8240983: Incorrect copyright header in Apache Santuario files In-Reply-To: <9d34aeff-7850-796c-e484-616cb64f1aa8@oracle.com> References: <3cfa03b7-765c-030c-f7e0-003fe216a7a9@oracle.com> <9d34aeff-7850-796c-e484-616cb64f1aa8@oracle.com> Message-ID: <33829435-D4A7-446E-A6FE-F13577685DDC@oracle.com> noreg-doc added. I thought about noreg-cleanup, but this is much safer than a normal cleanup. --Max > On Mar 13, 2020, at 8:17 PM, Sean Mullan wrote: > > One comment actually - you need to add a noreg label to the bug. > > --Sean > > On 3/13/20 8:13 AM, Sean Mullan wrote: >> Looks fine. >> --Sean >> On 3/13/20 5:44 AM, Weijun Wang wrote: >>> Please review the patch below. Unlike Sun, Oracle has no "Portions" copyright notice for Third Party source file changes, just add the standard Oracle copyright notice if a file has been modified. >>> >>> *diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* >>> *--- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* >>> *+++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java* >>> @@ -21,7 +21,7 @@ >>> * under the License. >>> */ >>> /* >>> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> */ >>> /* >>> * =========================================================================== >>> *diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* >>> *--- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* >>> *+++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java* >>> @@ -21,7 +21,7 @@ >>> * under the License. >>> */ >>> /* >>> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> */ >>> /* >>> * =========================================================================== >>> *diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* >>> *--- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* >>> *+++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java* >>> @@ -21,7 +21,7 @@ >>> * under the License. >>> */ >>> /* >>> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> */ >>> /* >>> * =========================================================================== >>> *diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* >>> *--- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* >>> *+++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java* >>> @@ -28,7 +28,7 @@ >>> * =========================================================================== >>> */ >>> /* >>> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> */ >>> /* >>> * $Id: DOMXPathFilter2Transform.java 1854026 2019-02-21 09:30:01Z coheigea $ >>> *diff --git a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* >>> *--- a/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* >>> *+++ b/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java* >>> @@ -28,7 +28,7 @@ >>> * =========================================================================== >>> */ >>> /* >>> - * Portions copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >>> */ >>> /* >>> * $Id: XMLDSigRI.java 1833618 2018-06-15 17:36:20Z mullan $ >>> >>> Thanks, >>> Max >>> From hai-may.chao at oracle.com Fri Mar 13 16:25:33 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 13 Mar 2020 09:25:33 -0700 Subject: =?utf-8?Q?RFR=5B15=5D=3A_8186143=3A_keytool_-ext_option_doesn?= =?utf-8?Q?=E2=80=99t_accept_wildcards_for_DNS_subject_alternatives_names?= Message-ID: <9E9A90E4-42A2-4375-B2CD-9D64A3BEBD07@oracle.com> Hi, I need a code review for - Bug: https://bugs.openjdk.java.net/browse/JDK-8186143 Webrev: http://cr.openjdk.java.net/~weijun/8186143/webrev.00/ The keytool -ext option doesn?t accept wildcards for DNS subject alternatives names in certificates. Certificates with wildcarded domains are useful for allowing domain names under a common subdomain to share the same certificate. The fix involves adding a new DNSName constructor with an additional boolean flag ?allowWildcard?. Thank you, Hai-May From Roger.Riggs at oracle.com Fri Mar 13 18:15:10 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 13 Mar 2020 14:15:10 -0400 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: Looks fine. On 3/13/20 11:42 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Fri Mar 13 19:24:00 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 13 Mar 2020 12:24:00 -0700 Subject: =?UTF-8?Q?Re=3a_RFR=5b15=5d=3a_8186143=3a_keytool_-ext_option_doesn?= =?UTF-8?Q?=e2=80=99t_accept_wildcards_for_DNS_subject_alternatives_names?= In-Reply-To: <9E9A90E4-42A2-4375-B2CD-9D64A3BEBD07@oracle.com> References: <9E9A90E4-42A2-4375-B2CD-9D64A3BEBD07@oracle.com> Message-ID: <22f9dcba-065c-9c42-06ec-3aaf905cab27@oracle.com> Hello Hai-May, The fix overall looks good.? One or two comments about the test: * 103: I think the comment might be more clear saying something like "partial wildcard disallowed" since it's not the "*" in and of itself that's the issue, it's that the next character following it isn't a domain separator ("."). * A similar badSanNames test case (I think) that walks a different code path would be something like "a*.com".? Although the test on line 95 might walk the same codepath...If so then no need to add anything else. --Jamil On 3/13/2020 9:25 AM, Hai-May Chao wrote: > Hi, > > I need a code review for - > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186143 > Webrev: http://cr.openjdk.java.net/~weijun/8186143/webrev.00/ > > The keytool -ext option doesn?t accept wildcards for DNS subject alternatives names in certificates. Certificates with wildcarded domains are useful for allowing domain names under a common subdomain to share the same certificate. > > The fix involves adding a new DNSName constructor with an additional boolean flag ?allowWildcard?. > > Thank you, > Hai-May > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hai-may.chao at oracle.com Fri Mar 13 20:44:31 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 13 Mar 2020 13:44:31 -0700 Subject: =?utf-8?Q?Re=3A_RFR=5B15=5D=3A_8186143=3A_keytool_-ext_option_doe?= =?utf-8?Q?sn=E2=80=99t_accept_wildcards_for_DNS_subject_alternatives_name?= =?utf-8?Q?s?= In-Reply-To: <22f9dcba-065c-9c42-06ec-3aaf905cab27@oracle.com> References: <9E9A90E4-42A2-4375-B2CD-9D64A3BEBD07@oracle.com> <22f9dcba-065c-9c42-06ec-3aaf905cab27@oracle.com> Message-ID: <9EAC46F3-1F7C-4082-80E3-05E13022CBE3@oracle.com> Hi Jamil, Thanks for your review! Reply inline. > On Mar 13, 2020, at 12:24 PM, Jamil Nimeh wrote: > > Hello Hai-May, > > The fix overall looks good. One or two comments about the test: > > 103: I think the comment might be more clear saying something like "partial wildcard disallowed" since it's not the "*" in and of itself that's the issue, it's that the next character following it isn't a domain separator (".?). Agree. Will update the comment. > A similar badSanNames test case (I think) that walks a different code path would be something like "a*.com". Although the test on line 95 might walk the same codepath...If so then no need to add anything else. I?ll add ?a*.com? to badSanNames test case as it will detect the error for ?DNSName components must consist of letters, digits, and hyphens?. Line 95 test case will give us a different error from ?a*.com?. That is, ?DNSName with blank components is not permitted?. The existing badNames test case does not have ?a*.com?, and I will add it too. Thanks, Hai-May > --Jamil > > On 3/13/2020 9:25 AM, Hai-May Chao wrote: >> Hi, >> >> I need a code review for - >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8186143 >> Webrev: http://cr.openjdk.java.net/~weijun/8186143/webrev.00/ >> >> The keytool -ext option doesn?t accept wildcards for DNS subject alternatives names in certificates. Certificates with wildcarded domains are useful for allowing domain names under a common subdomain to share the same certificate. >> >> The fix involves adding a new DNSName constructor with an additional boolean flag ?allowWildcard?. >> >> Thank you, >> Hai-May >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Sat Mar 14 02:03:56 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 13 Mar 2020 19:03:56 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Hi Pavel! Can this please be combined with my collection of typos? http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ Just to save cycles on reviewing :) With kind regards, Ivan On 3/13/20 8:42 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Sat Mar 14 02:16:47 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 14 Mar 2020 10:16:47 +0800 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <45501DDD-B9F4-4C1E-9666-2A1AB1BBFD75@oracle.com> > On Mar 13, 2020, at 11:42 PM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. This is indeed a typo. Other changes (including Ivan's) also look fine to me. Thanks, Max > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From xuelei.fan at oracle.com Mon Mar 16 04:25:41 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 15 Mar 2020 21:25:41 -0700 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method Message-ID: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> Hi, Could I get the following update reviewed? Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ In a preview review thread, https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html I requested to remove the deprecated javax.security.cert APIs in JDK 15. Be part of the removal, the deprecated interface method javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved. As SSLSession.getPeerCertificateChain() is an interface method, third party's implementation must override this method. If it is removed, there are compiler errors unless the override implementation get removed in third party's source code. Maybe, we could retire SSLSession.getPeerCertificateChain() first, and then come back to remove the deprecated javax.security.cert package in a few years. In this update, I'm trying to change SSLSession.getPeerCertificateChain() to default method , throwing exception in the default implementation, and removing the real implementation in the SunJSSE provider and related code (Httpclient). Thanks, Xuelei From xuelei.fan at oracle.com Mon Mar 16 04:31:16 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 15 Mar 2020 21:31:16 -0700 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> References: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> Message-ID: <372451fe-6f7f-f74b-1812-ef4698515e11@oracle.com> Hi, Thank you all for the review. This is a note to cancel this update. During the review, we got concerns about the compatibility impact about the removal of the interface method (SSLSession.getPeerCertificateChain()). Maybe, I should move forward to resolve the concern first, and then come back for the removal in a few years. For more details, please refer to the new code review request: https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021421.html Thanks & Regards, Xuelei On 3/12/2020 10:34 AM, Xuelei Fan wrote: > And the release note task: > ? https://bugs.openjdk.java.net/browse/JDK-8240968 > > Xuelei > > On 3/12/2020 9:47 AM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 >> Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ >> >> The legacy javax.security.cert APIs and the dependent were initially >> deprecated in Java SE 9 and marked for removal in Java SE 13. >> Applications should use the java.security.cert APIs for now.? This is >> a request to remove the deprecated javax.security.cert APIs. >> >> The use of the legacy APIs should be rare now.? But please let me know >> if you have concerns before March 19, 2019. >> >> Thanks & Regards, >> Xuelei From Alan.Bateman at oracle.com Mon Mar 16 07:36:38 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Mar 2020 07:36:38 +0000 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> Message-ID: On 16/03/2020 04:25, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 > webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ > I see you've created a new issue (and sub-tasks), in which JDK-8227024, CSR and other tasks need to be closed to avoid any confusion. SSLSession - the method is already terminally deprecated so there is a big note in the javadoc. No need to duplicate the text in an @implNote. For @implSpec then I think you want "The default method throws ....". HandshakeCompletedEvent - you can drop the @implNote here too. Catching UOE and then re-throwing it with the UOE from SSLSession as the cause is confusing. I think you can leave the implementation as-is. -Alan. From daniel.fuchs at oracle.com Mon Mar 16 10:37:19 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 16 Mar 2020 10:37:19 +0000 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> Message-ID: <4ef74754-f188-b7f9-1d11-0b4f956a68de@oracle.com> Hi Xuelei, HandshakeCompletedEvent.java: typo: 186 "This method has retired, pleaase use the " + Same in SSLSession.java: 303 "This method has retired, pleaase use the " + WRT to the HttpClient code I wonder whether the deprecated method should be kept. On the one hand I'd welcome the removal of the implemenatation of terminally deprecated methods. On the other hand the two classes in HttpClient implement simple delegation over an SSLSession object. Unless we can guarantee that this object is our own implementation, maybe the delegation should be kept - and the throwing of UnsupportedOperationException left up to the delegate object? I am not sure what's the best course here. best regards -- daniel On 16/03/2020 04:25, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 > webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ > > In a preview review thread, > > https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html > > I requested to remove the deprecated javax.security.cert APIs in JDK 15. > ?Be part of the removal, the deprecated interface method > javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved. > > As SSLSession.getPeerCertificateChain() is an interface method, third > party's implementation must override this method.? If it is removed, > there are compiler errors unless the override implementation get removed > in third party's source code. > > Maybe, we could retire SSLSession.getPeerCertificateChain() first, and > then come back to remove the deprecated javax.security.cert package in a > few years. > > In this update, I'm trying to change > SSLSession.getPeerCertificateChain() to default method , throwing > exception in the default implementation, and removing the real > implementation in the SunJSSE provider and related code (Httpclient). > > Thanks, > Xuelei From sean.mullan at oracle.com Mon Mar 16 12:18:38 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Mar 2020 08:18:38 -0400 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> Message-ID: <0388da74-128b-5e0f-2289-1c4632d700f1@oracle.com> 302 throw new UnsupportedOperationException( 303 "This method has retired, pleaase use the " + 304 "getPeerCertificates() method instead."); Not sure the word "retired" is the correct term here. It is unusual to see that term with respect to APIs. I would use the common terms associated with deprecated methods. How about: throw new UnsupportedOperationException( "This method is deprecated and marked for removal. Use the " + "getPeerCertificates() method instead."); --Sean On 3/16/20 12:25 AM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 > webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ > > In a preview review thread, > > https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html > > I requested to remove the deprecated javax.security.cert APIs in JDK 15. > ?Be part of the removal, the deprecated interface method > javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved. > > As SSLSession.getPeerCertificateChain() is an interface method, third > party's implementation must override this method.? If it is removed, > there are compiler errors unless the override implementation get removed > in third party's source code. > > Maybe, we could retire SSLSession.getPeerCertificateChain() first, and > then come back to remove the deprecated javax.security.cert package in a > few years. > > In this update, I'm trying to change > SSLSession.getPeerCertificateChain() to default method , throwing > exception in the default implementation, and removing the real > implementation in the SunJSSE provider and related code (Httpclient). > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Mar 16 16:00:48 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Mar 2020 09:00:48 -0700 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> Message-ID: <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com> Hi Alan, Thanks for the review. All comments look good to me. Here is the update webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/ HandshakeCompletedEvent.java and SSLSession.java are updated. Thanks, Xuelei On 3/16/2020 12:36 AM, Alan Bateman wrote: > On 16/03/2020 04:25, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 >> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ >> > I see you've created a new issue (and sub-tasks), in which JDK-8227024, > CSR and other tasks need to be closed to avoid any confusion. > > SSLSession - the method is already terminally deprecated so there is a > big note in the javadoc. No need to duplicate the text in an @implNote. > For @implSpec then I think you want "The default method throws ....". > > HandshakeCompletedEvent - you can drop the @implNote here too. Catching > UOE and then re-throwing it with the UOE from SSLSession as the cause is > confusing. I think you can leave the implementation as-is. > > -Alan. From xuelei.fan at oracle.com Mon Mar 16 16:31:12 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Mar 2020 09:31:12 -0700 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <4ef74754-f188-b7f9-1d11-0b4f956a68de@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> <4ef74754-f188-b7f9-1d11-0b4f956a68de@oracle.com> Message-ID: <798b2114-3b75-d95e-169b-fb7f6de1381e@oracle.com> On 3/16/2020 3:37 AM, Daniel Fuchs wrote: > Hi Xuelei, > > HandshakeCompletedEvent.java: typo: > > ?186???????????????? "This method has retired, pleaase use the " + > > Same in SSLSession.java: > > ?303???????????? "This method has retired, pleaase use the " + > I removed the sections per Alan's comment. > WRT to the HttpClient code I wonder whether the deprecated method > should be kept. On the one hand I'd welcome the removal of > the implemenatation of terminally deprecated methods. > On the other hand the two classes in HttpClient implement simple > delegation over an SSLSession object. Unless we can guarantee that > this object is our own implementation, maybe the delegation should > be kept - and the throwing of UnsupportedOperationException left > up to the delegate object? > > I am not sure what's the best course here. > There are compiler error if SSLSession.getPeerCertificateChain() get removed, while the implementation override it. As one of the goals, the implementation, especially third party provider that is intended to support multiple releases, should remove override implementation as soon as possible, without waiting for the removal of the SSLSession.getPeerCertificateChain() method. Otherwise, there are still compiler error when we want to remove this interface method in the future. It should be fine to keep the HttpClient implementation as it only ship with the current JDK release. But if you don't mind, I would like to remove it to show an example about how to handle with the method in third party's source code. Thanks, Xuelei > best regards > > -- daniel > > > On 16/03/2020 04:25, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 >> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ >> >> In a preview review thread, >> >> https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html >> >> >> I requested to remove the deprecated javax.security.cert APIs in JDK >> 15. ??Be part of the removal, the deprecated interface method >> javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved. >> >> As SSLSession.getPeerCertificateChain() is an interface method, third >> party's implementation must override this method.? If it is removed, >> there are compiler errors unless the override implementation get >> removed in third party's source code. >> >> Maybe, we could retire SSLSession.getPeerCertificateChain() first, and >> then come back to remove the deprecated javax.security.cert package in >> a few years. >> >> In this update, I'm trying to change >> SSLSession.getPeerCertificateChain() to default method , throwing >> exception in the default implementation, and removing the real >> implementation in the SunJSSE provider and related code (Httpclient). >> >> Thanks, >> Xuelei > From xuelei.fan at oracle.com Mon Mar 16 16:49:09 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Mar 2020 09:49:09 -0700 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <0388da74-128b-5e0f-2289-1c4632d700f1@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> <0388da74-128b-5e0f-2289-1c4632d700f1@oracle.com> Message-ID: Good catch! Updated in the webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/ Xuelei On 3/16/2020 5:18 AM, Sean Mullan wrote: > ?302???????? throw new UnsupportedOperationException( > ?303???????????? "This method has retired, pleaase use the " + > ?304???????????? "getPeerCertificates() method instead."); > > > Not sure the word "retired" is the correct term here. It is unusual to > see that term with respect to APIs. I would use the common terms > associated with deprecated methods. How about: > > ??????? throw new UnsupportedOperationException( > ???????????? "This method is deprecated and marked for removal. Use the > " + > ???????????? "getPeerCertificates() method instead."); > > --Sean > > On 3/16/20 12:25 AM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241039 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8241047 >> webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/ >> >> In a preview review thread, >> >> https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021401.html >> >> >> I requested to remove the deprecated javax.security.cert APIs in JDK >> 15. ??Be part of the removal, the deprecated interface method >> javax.net.ssl.SSLSession.getPeerCertificateChain() is also involved. >> >> As SSLSession.getPeerCertificateChain() is an interface method, third >> party's implementation must override this method.? If it is removed, >> there are compiler errors unless the override implementation get >> removed in third party's source code. >> >> Maybe, we could retire SSLSession.getPeerCertificateChain() first, and >> then come back to remove the deprecated javax.security.cert package in >> a few years. >> >> In this update, I'm trying to change >> SSLSession.getPeerCertificateChain() to default method , throwing >> exception in the default implementation, and removing the real >> implementation in the SunJSSE provider and related code (Httpclient). >> >> Thanks, >> Xuelei From Alan.Bateman at oracle.com Mon Mar 16 17:23:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Mar 2020 17:23:36 +0000 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com> Message-ID: <0e82e1c8-45e1-d12e-baaf-5997ac43e4c8@oracle.com> On 16/03/2020 16:00, Xuelei Fan wrote: > Hi Alan, > > Thanks for the review.? All comments look good to me.? Here is the > update webrev: > ? http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/ > > HandshakeCompletedEvent.java and SSLSession.java are updated. Thanks.? One suggestion is to use "The default implementation ..." rather than "This default method ..." in the @implSpec (no need for a new webrev). -Alan. From xuelei.fan at oracle.com Mon Mar 16 17:30:28 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Mar 2020 10:30:28 -0700 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <0e82e1c8-45e1-d12e-baaf-5997ac43e4c8@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> <10ec4ac2-52c2-f808-9673-f7f4d173f8bb@oracle.com> <0e82e1c8-45e1-d12e-baaf-5997ac43e4c8@oracle.com> Message-ID: <31d2e58b-739a-6a69-b376-69287a3f3acd@oracle.com> I updated the CSR and local code. Thanks, Xuelei On 3/16/2020 10:23 AM, Alan Bateman wrote: > > > On 16/03/2020 16:00, Xuelei Fan wrote: >> Hi Alan, >> >> Thanks for the review.? All comments look good to me.? Here is the >> update webrev: >> ? http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/ >> >> HandshakeCompletedEvent.java and SSLSession.java are updated. > Thanks.? One suggestion is to use "The default implementation ..." > rather than "This default method ..." in the @implSpec (no need for a > new webrev). > > -Alan. From sean.mullan at oracle.com Mon Mar 16 19:19:02 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Mar 2020 15:19:02 -0400 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> <0388da74-128b-5e0f-2289-1c4632d700f1@oracle.com> Message-ID: <2f126dcf-edcf-8f0d-5368-04fb6684c8f1@oracle.com> On 3/16/20 12:49 PM, Xuelei Fan wrote: > Good catch!? Updated in the webrev: > http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/ While you are in there, I was wondering if you can fix the typo in this sentence in HandshakeCompletedEvent: 182 * end-entity certiticate for X509-based cipher suites, and "certificate" and SSLSession: 305 * end-entity certiticate for X509-based cipher suites, and "certificate" Also, in HandshakeCompletedEvent: 164 * @see #getPeerPrincipal() 165 * @see #getPeerPrincipal() duplicate lines, remove one. --Sean From xuelei.fan at oracle.com Mon Mar 16 20:36:57 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Mar 2020 13:36:57 -0700 Subject: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method In-Reply-To: <2f126dcf-edcf-8f0d-5368-04fb6684c8f1@oracle.com> References: <8fcc3dac-ad14-7cfe-ed07-8f3054da382e@oracle.com> <0388da74-128b-5e0f-2289-1c4632d700f1@oracle.com> <2f126dcf-edcf-8f0d-5368-04fb6684c8f1@oracle.com> Message-ID: <36872590-f5c5-6e9c-5661-a5d1205f6541@oracle.com> Updated in my local workspace. I would not update the webrev and CSR unless you want a check. Thanks, Xuelei On 3/16/2020 12:19 PM, Sean Mullan wrote: > On 3/16/20 12:49 PM, Xuelei Fan wrote: >> Good catch!? Updated in the webrev: >> http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/ > > While you are in there, I was wondering if you can fix the typo in this > sentence in HandshakeCompletedEvent: > > 182????? * end-entity certiticate for X509-based cipher suites, and > > "certificate" > > and SSLSession: > > 305????? * end-entity certiticate for X509-based cipher suites, and > > "certificate" > > Also, in HandshakeCompletedEvent: > > 164????? * @see #getPeerPrincipal() > 165????? * @see #getPeerPrincipal() > > duplicate lines, remove one. > > --Sean > > > > From stanislav.smirnov at oracle.com Fri Mar 6 17:52:52 2020 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Fri, 6 Mar 2020 12:52:52 -0500 Subject: RFR [15]: 8240684: ProblemList 70 security tests that are failing on Windows due to "Fetch artifact failed" In-Reply-To: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> References: <4fa32366-8d21-fa99-fa61-c9714774e44d@oracle.com> Message-ID: <0B422057-559D-413B-8B62-C2CD74B40197@oracle.com> Looks good to me, thanks for taking care of this Best regards, Stanislav Smirnov > On Mar 6, 2020, at 12:31 PM, Sean Mullan wrote: > > Please review this change to ProblemList 70 security tests while we diagnose the artifactory issues. > > See https://bugs.openjdk.java.net/browse/JDK-8240684 for more info. > > diff -r 1c40993361d0 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Feb 24 19:03:34 2020 +0100 > +++ b/test/jdk/ProblemList.txt Fri Mar 06 12:25:01 2020 -0500 > @@ -722,6 +722,77 @@ > sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 generic-all > sun/security/provider/PolicyParser/PrincipalExpansionError.java 8039280 generic-all > > +sun/security/tools/keytool/NssTest.java 8240686 windows-all > +sun/security/pkcs11/SampleTest.java 8240686 windows-all > +sun/security/pkcs11/tls/TestPRF.java 8240686 windows-all > +sun/security/pkcs11/tls/TestPremaster.java 8240686 windows-all > +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8240686 windows-all > +sun/security/pkcs11/tls/TestMasterSecret.java 8240686 windows-all > +sun/security/pkcs11/tls/TestKeyMaterial.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSAKeyLength.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSA2.java 8240686 windows-all > +sun/security/pkcs11/Signature/TestDSA.java 8240686 windows-all > +sun/security/pkcs11/Signature/SignatureTestPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/SigInteropPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/ReinitSignature.java 8240686 windows-all > +sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/InitAgainPSS.java 8240686 windows-all > +sun/security/pkcs11/Signature/ByteBuffers.java 8240686 windows-all > +sun/security/pkcs11/Serialize/SerializeProvider.java 8240686 windows-all > +sun/security/pkcs11/SecureRandom/TestDeserialization.java 8240686 windows-all > +sun/security/pkcs11/SecureRandom/Basic.java 8240686 windows-all > +sun/security/pkcs11/Secmod/TrustAnchors.java 8240686 windows-all > +sun/security/pkcs11/Secmod/GetPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/Secmod/LoadKeystore.java 8240686 windows-all > +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8240686 windows-all > +sun/security/pkcs11/Secmod/JksSetPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/Secmod/Crypto.java 8240686 windows-all > +sun/security/pkcs11/Secmod/AddTrustedCert.java 8240686 windows-all > +sun/security/pkcs11/Secmod/AddPrivateKey.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestSignatures.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestKeyFactory.java 8240686 windows-all > +sun/security/pkcs11/rsa/TestCACerts.java 8240686 windows-all > +sun/security/pkcs11/rsa/KeyWrap.java 8240686 windows-all > +sun/security/pkcs11/Provider/Login.sh 8240686 windows-all > +sun/security/pkcs11/Provider/ConfigQuotedString.sh 8240686 windows-all > +sun/security/pkcs11/MessageDigest/TestCloning.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/ReinitDigest.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/DigestKAT.java 8240686 windows-all > +sun/security/pkcs11/Mac/MacKAT.java 8240686 windows-all > +sun/security/pkcs11/Mac/MacSameTest.java 8240686 windows-all > +sun/security/pkcs11/Mac/ReinitMac.java 8240686 windows-all > +sun/security/pkcs11/MessageDigest/ByteBuffers.java 8240686 windows-all > +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8240686 windows-all > +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8240686 windows-all > +sun/security/pkcs11/KeyGenerator/DESParity.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestInterop.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestDH.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/TestShort.java 8240686 windows-all > +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECGenSpec.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDSA2.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDSA.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDH2.java 8240686 windows-all > +sun/security/pkcs11/ec/TestECDH.java 8240686 windows-all > +sun/security/pkcs11/ec/TestCurves.java 8240686 windows-all > +sun/security/pkcs11/ec/ReadPKCS12.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8240686 windows-all > +sun/security/pkcs11/ec/ReadCertificates.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRSACipher.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestKATForGCM.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java 8240686 windows-all > +sun/security/pkcs11/Cipher/TestCICOWithGCM.java 8240686 windows-all > +sun/security/pkcs11/Cipher/Test4512704.java 8240686 windows-all > +sun/security/pkcs11/Cipher/ReinitCipher.java 8240686 windows-all > + > ############################################################################ > > # jdk_sound -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Fri Mar 13 15:42:03 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 Mar 2020 15:42:03 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments Message-ID: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affected: java.lang, java.nio.file, java.nio.file.attribute, java.security, java.time.chrono, java.time.temporal, java.util, java.util.regex, java.util.stream, javax.crypto, javax.security.cert, javax.tools That said, there are two changes that I'd prefer to be carefully reviewed by the experts in the corresponding areas. The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and supported for the sake of backward compatibility. Sadly, we have a number of those in OpenJDK. Even though I performed reasonable checks, the proposed fix should better be verified by the security folk. The second one is for the doc comment for the java.util.stream.Stream.collect method. @apiNote The following will accumulate strings into an ArrayList: List asList = stringStream.collect(Collectors.toList()); Given that the spec for Collectors.toList() clearly says that ...There are no guarantees on the type, mutability, serializability, or thread-safety of the List returned;... I'd assume that @apiNote should be fixed as proposed. -Pavel P.S. Apologies for spamming multiple mailing lists. From pavel.rappo at oracle.com Sat Mar 14 16:19:45 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 14 Mar 2020 16:19:45 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Message-ID: Hi Ivan, Your changes look good to me. Thanks for doing this. I will merge your changes into that patch of mine. 1. One thing that your change highlighted is that use of FQN here: public int read(java.nio.CharBuffer target) throws IOException It's been there for ages, but I believe can now safely go away after $ hg log -v -r 49262 changeset: 49262:1b3ee04e3e54 user: rriggs date: Mon Mar 19 09:58:41 2018 -0400 files: src/java.base/share/classes/java/io/Reader.java src/java.base/share/classes/java/io/Writer.java test/jdk/java/io/Reader/NullReader.java test/jdk/java/io/Writer/NullWriter.java description: 8196298: Add null Reader and Writer Reviewed-by: bpb, forax, smarks, alanb, rriggs Contributed-by: patrick at reini.net as this latter change brought import java.nio.CharBuffer; Unless people want to keep that FQN for some other reasons. For example, to emphasize that CharBuffer does not belong to java.io, or so it does not get confused with unrelated concepts like BufferedReader.defaultCharBufferSize, etc. 2. Typos aside, this MethodType.ConcurrentWeakInternSet.WeakEntry#equals has peculiar semantics! Paul Sandoz might be a good fit for reviewing changes in both java.util.stream (mine) and java.util.Arrays (yours). -Pavel > On 14 Mar 2020, at 02:03, Ivan Gerasimov wrote: > > Hi Pavel! > > Can this please be combined with my collection of typos? > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >> >> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.nio.file, >> java.nio.file.attribute, >> java.security, >> java.time.chrono, >> java.time.temporal, >> java.util, >> java.util.regex, >> java.util.stream, >> javax.crypto, >> javax.security.cert, >> javax.tools >> >> That said, there are two changes that I'd prefer to be carefully reviewed by >> the experts in the corresponding areas. >> >> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >> supported for the sake of backward compatibility. Sadly, we have a number of >> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >> should better be verified by the security folk. >> >> The second one is for the doc comment for the java.util.stream.Stream.collect method. >> >> @apiNote >> The following will accumulate strings into an ArrayList: >> >> List asList = stringStream.collect(Collectors.toList()); >> >> Given that the spec for Collectors.toList() clearly says that >> >> ...There are no guarantees on the type, mutability, serializability, or >> thread-safety of the List returned;... >> >> I'd assume that @apiNote should be fixed as proposed. >> >> -Pavel >> >> P.S. Apologies for spamming multiple mailing lists. >> > -- > With kind regards, > Ivan Gerasimov > From pj.stanley at live.co.uk Mon Mar 16 08:31:27 2020 From: pj.stanley at live.co.uk (Paul Stanley) Date: Mon, 16 Mar 2020 08:31:27 +0000 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: <372451fe-6f7f-f74b-1812-ef4698515e11@oracle.com> References: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> <372451fe-6f7f-f74b-1812-ef4698515e11@oracle.com> Message-ID: Hi. I believe that you should remove deprecated javax api's. By delaying it, you are pushing the problem into 2022. If they are removed now then it will force developers to use the correct crypto api's, rather than using a mixture which is what's currently happening. The compatibility problem for historic code can fixed by an optional 3rd party library/module. Cheers Paul On 16 Mar 2020, at 04:32, Xuelei Fan > wrote: Hi, Thank you all for the review. This is a note to cancel this update. During the review, we got concerns about the compatibility impact about the removal of the interface method (SSLSession.getPeerCertificateChain()). Maybe, I should move forward to resolve the concern first, and then come back for the removal in a few years. For more details, please refer to the new code review request: https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021421.html Thanks & Regards, Xuelei On 3/12/2020 10:34 AM, Xuelei Fan wrote: And the release note task: https://bugs.openjdk.java.net/browse/JDK-8240968 Xuelei On 3/12/2020 9:47 AM, Xuelei Fan wrote: Hi, Could I get the following update reviewed? CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ The legacy javax.security.cert APIs and the dependent were initially deprecated in Java SE 9 and marked for removal in Java SE 13. Applications should use the java.security.cert APIs for now. This is a request to remove the deprecated javax.security.cert APIs. The use of the legacy APIs should be rare now. But please let me know if you have concerns before March 19, 2019. Thanks & Regards, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From kusrinivasan at vmware.com Tue Mar 17 02:44:47 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Tue, 17 Mar 2020 02:44:47 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> Message-ID: <18BFBE3E-9403-4385-8B31-8346AFF642E0@vmware.com> Hi Alexey - I was trying to understand the fix for the "Unexpected number of plaintext bytes? issue. But it appears that the earlier iterations of the webrevs have disappeared, only webrev.5 is available in [1] In the future it would be a good practice, to retain all the webrevs for sometime. Thanks Kumar [1] http://cr.openjdk.java.net/~dcherepanov/8239788/ On Mar 11, 2020, at 8:53 AM, Xuelei Fan > wrote: Hi Alexey, I had run the testing for you, no surprise. Please commit to JDK 15, and backport accordingly. Thanks, Xuelei On 3/11/2020 7:16 AM, Alexey Bakhtin wrote: Hello Xuelei, Thank you for review. Can I commit it to JDK15 and create backports to JDK 14, 13 and 11 ? Thank you Alexey On 10 Mar 2020, at 20:59, Xuelei Fan > wrote: Looks fine to me. Thanks, Xuelei On 3/5/2020 8:50 AM, Alexey Bakhtin wrote: Hello Xuelei, I have renamed inputBuffer to recordBody. Also, as you suggested, recordBody is not removed but used for multiple records. So, it should be better for performance. JDK15 webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~dcherepanov%2F8239788%2Fwebrev.v5%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7C322b64d367df4ad239db08d7c5d4901e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637195389056395429&sdata=y2sJbDyL8DmumCrlY3tF35BVyfs1k7Ikmr2l3ypMXDg%3D&reserved=0 Regards Alexey On 4 Mar 2020, at 21:23, Xuelei Fan > wrote: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~bae%2F8239788%2Fwebrev.v4%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7C322b64d367df4ad239db08d7c5d4901e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637195389056395429&sdata=dAjTwfyW8tbCErqNc2URUVJdou8Aun3m9G%2FQ56N9PwA%3D&reserved=0 SSLSocketInputRecord: 54 // Cache for incomplete input record. 55 private ByteBuffer inputBuffer = null; This variable is used for record body, I may use a instinctive name, for example recordBody. Otherwise, looks good to me. I think, for performance, it may be possible to reuse this buffer for multiple records. I'd appreciate if you want to make an improvement in this update as well. Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Tue Mar 17 07:46:11 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 17 Mar 2020 07:46:11 +0000 Subject: OpenJDK11u: Backward incompatible behavior In-Reply-To: <18BFBE3E-9403-4385-8B31-8346AFF642E0@vmware.com> References: <88E85415-7D0A-48FC-8976-23E8C4A2A55B@azul.com> <48BF00AF-D383-470E-950B-0BED8A650C06@azul.com> <47C94AF4-2537-4293-83BA-D759F5EBAB52@azul.com> <9952932e-1437-01cf-65a5-f9529f04c678@oracle.com> <3F53BE36-B0CD-439C-AF00-2AD10FD63293@azul.com> <95fb46ec-fb58-bbde-6428-327c9168f968@oracle.com> <9C54C761-80A8-478C-BD51-1F8F232823F4@azul.com> <18BFBE3E-9403-4385-8B31-8346AFF642E0@vmware.com> Message-ID: Hi Kumar, I have no OpenJDK Author account yet, so I had to ask another authors to publish my patches. All patches still available, but on different locations: [1] JDK11 patch: http://cr.openjdk.java.net/~yan/8239788/webrev.0/ [2] JDK11 patch: http://cr.openjdk.java.net/~yan/8239788/webrev.1/ [3] JDK15 patch: http://cr.openjdk.java.net/~yan/8239788/webrev.2/ [4] JDK11 patch: http://cr.openjdk.java.net/~yan/8239788/webrev.3/ [5] JDK11 patch: http://cr.openjdk.java.net/~bae/8239788/webrev.v3/ [6] JDK15 patch: http://cr.openjdk.java.net/~bae/8239788/webrev.v4/ [7] JDK15 patch: http://cr.openjdk.java.net/~dcherepanov/8239788/webrev.v5/ Regards Alexey On 17 Mar 2020, at 05:44, Kumar Srinivasan > wrote: Hi Alexey - I was trying to understand the fix for the "Unexpected number of plaintext bytes? issue. But it appears that the earlier iterations of the webrevs have disappeared, only webrev.5 is available in [1] In the future it would be a good practice, to retain all the webrevs for sometime. Thanks Kumar [1] http://cr.openjdk.java.net/~dcherepanov/8239788/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Mar 17 08:55:17 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Mar 2020 08:55:17 +0000 Subject: RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: <459ae35e-d71b-13eb-1d8f-e75480635cb9@oracle.com> <372451fe-6f7f-f74b-1812-ef4698515e11@oracle.com> Message-ID: <95f9577b-0431-1db2-67dc-dbf39d2d962d@oracle.com> On 16/03/2020 08:31, Paul Stanley wrote: > Hi. > > > I believe that you should remove deprecated javax api's. By delaying > it, you are pushing the problem into 2022. > > > If they are removed now then it will force developers to use the > correct crypto api's, rather than using a mixture which is what's > currently happening. > > > The compatibility problem for historic code can fixed by an optional > 3rd party library/module. No, the main issue here isn't the terminally deprecated javax.security.cert package but the methods in the SSLSession interface and HandshakeCompletedEvent class. See the follow-up thread "8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method" for the proposal that provides a migration path for libraries once they get to JDK 15 or newer. -Alan From jamil.j.nimeh at oracle.com Tue Mar 17 23:48:05 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 17 Mar 2020 16:48:05 -0700 Subject: RFR: 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working Message-ID: Hello all, I'm finally getting back around to this after dusting off the cobwebs. Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.03 Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 Valerie, you had some comments from way back (7/9/2019).? Just a short summary of what's been done to address them: * Removed unused imports * Added a default "PBES2" string value for when the toString method is called on a PBES2Parameters object before the init() method. * Tested encoding of PBKDF2 parameters AlgorithmIdentifiers with the optional parameters field not present (as opposed to an ASN.1 NULL).? OpenSSL seems happy with it so that's how we'll encode those. * Switched order on the IV and keysize parsing for RC2 parameters * Using KEYLEN_ANY (changed to KEYLEN_UNSPEC) now in lieu of -1 in the conditionals you cited. * For algorithms where the key length is implicit either due to the algorithm or the specific OID, we no longer assert the key length in the KDF parameters.? This is consistent with other implementations such as OpenSSL. * Regarding the comment from the parsing in engineInit(byte[]) "By calling data.getDerValue(), we are essentially peeling one layer off, right? If you still agree with me at this point, then note that pBES2_params is a local variable and its value should be the same unless explicitly re-assigned (as on line 413). Thus, per my reading of the code, the tag that you are checking on line 419 is not the one for encryption scheme, but rather the outer sequence tag encapsulating kdf and encryption scheme. Its current location is very misleading though, in between kdf and encryption scheme. To really check the tag for kdf and encryption scheme, the tag checking should be in parseKDF(...) and parseES(...) against the DerValue argument." I did add a DerValue check in parseKDF because it is appropriate as you stated.? I also removed the check from line 419 in the old webrev.? With the new code that check is redundant as we are using AlgorithmId.parse() now as the initial operation in parseES, which in turn does the sequence tag check for us. The check itself on 419 though is testing the ASN.1 tag for the Encryption scheme, not the higher level sequence for PBES2-params.? Otherwise neither the KDF nor the encryption scheme would parse properly and none of the tests would pass. With this new code, parseKDF and parseES are testing the outer SEQUENCE tags for each of the AlgorithmIdentifier objects described by keyDerivationFunc and encryptionScheme per RFC 8018. * keysize setting: This one is a bit tricky because key size is specified in multiple ways.? The basic flow is this.? Key size will start as KEYLEN_UNSPEC.? If it is at any point specified, either via the constructor, by KDF params, or by enc params then that is the value that is set.? At near the end of parsing a validation of the encryption parameters occurs and at that point the key length is checked against the algorithm.? If it is an alg that uses a fixed value then keysize has to be consistent with it.? If it is variable length and it is still KEYSIZE_UNSPEC that is also a failure (since something needs to be specified to distinguish RC2_40 from RC2_128, for example). o This approach seems to work and catches the issue you found where certain DER encodings could yield things like PBEWithHmacSHA256AndRC5_-1. * Added some new tests to handle the changes listed above. I'll be updating the CSR shortly to reflect comments there and I'll send a separate review notice for that. Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Mar 18 14:32:48 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Mar 2020 10:32:48 -0400 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: Message-ID: <70b9a00e-92b5-60db-6d70-089272fbf653@oracle.com> I have finished my review. I have no further comments. Thanks, Sean On 3/12/20 11:10 AM, Sean Mullan wrote: > Here are some more comments, all minor. I will probably need one more > round of review. > > - src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java > > ? 362???????? /* XDH does not require native implementation */ > > Looks like a cut-paste error. I think you can remove this line. > > - src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java > - src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java > - src/java.base/share/classes/java/security/spec/EdECPoint.java > > In the class description of these 3 classes, you are missing a

at > the start of the 2nd paragraph. Otherwise when you generate javadoc, it > won't create a new paragraph. > > - src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java > > ? 71????? * @param context the context that is bound to the signature > > This should probably say that the parameter is copied. Also getContext() > should say that it returns a copy (if not null). > > ? 92????? * Get the context that should be used, if any > > Missing period at end of sentence. > > - > src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAPublicKeyImpl.java > > ? 58???????? // set the high-order bit of the > > .. of the ? > > ? 73???????? // construct the EdECPoint representation > ? 74 > > This comment applies to code after line 74, so I think it would make > more sense if you removed line 74 and added a blank line before 73. > > - src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdECOperations.java > > It would be useful to have some additional comments in this code. > > --Sean > > On 2/25/20 3:49 PM, Anthony Scarpino wrote: >> Hi >> >> I need a code review for the EdDSA support in JEP 339.? The code >> builds on the existing java implemented constant time classes used for >> XDH and the NIST curves.? The change also adds classes to the public >> API to support EdDSA operations. >> >> All information about the JEP is located at: >> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 >> >> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ >> >> thanks >> >> Tony From anthony.scarpino at oracle.com Wed Mar 18 15:52:37 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 18 Mar 2020 08:52:37 -0700 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: Message-ID: Max, Are you satisfied with this last update? Thanks Tony > On Mar 11, 2020, at 11:23 PM, Anthony Scarpino wrote: > > ?Another webrev update with Max's recent comments. > https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 > > Also I still need a reviewer for the CSR. > > thanks > > Tony > >> On 3/2/20 4:40 PM, Anthony Scarpino wrote: >> Hi >> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >> The curves affected are: >> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >> Tony > From valerie.peng at oracle.com Wed Mar 18 22:57:37 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Mar 2020 15:57:37 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms Message-ID: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> Anyone has time to help review this straight forward RFE? It's to add SHA-3 support to Hmac. RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ Mach5 run is clean. Thanks, Valerie From valerie.peng at oracle.com Wed Mar 18 22:59:56 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Mar 2020 15:59:56 -0700 Subject: RFR: 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: Message-ID: <06fc3f21-225f-7262-fea3-29a6d803b328@oracle.com> Right, I recall reviewing this and made some comments. Will take a look at the updated webrev. Thanks, Valerie On 3/17/2020 4:48 PM, Jamil Nimeh wrote: > > Hello all, > > I'm finally getting back around to this after dusting off the cobwebs. > > Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.03 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 > > Valerie, you had some comments from way back (7/9/2019).? Just a short > summary of what's been done to address them: > > * Removed unused imports > * Added a default "PBES2" string value for when the toString method > is called on a PBES2Parameters object before the init() method. > * Tested encoding of PBKDF2 parameters AlgorithmIdentifiers with the > optional parameters field not present (as opposed to an ASN.1 > NULL).? OpenSSL seems happy with it so that's how we'll encode those. > * Switched order on the IV and keysize parsing for RC2 parameters > * Using KEYLEN_ANY (changed to KEYLEN_UNSPEC) now in lieu of -1 in > the conditionals you cited. > * For algorithms where the key length is implicit either due to the > algorithm or the specific OID, we no longer assert the key length > in the KDF parameters.? This is consistent with other > implementations such as OpenSSL. > * Regarding the comment from the parsing in engineInit(byte[]) > > "By calling data.getDerValue(), we are essentially peeling one layer > off, right? If you still agree with me at this point, then note that > pBES2_params is a local variable and its value should be the same > unless explicitly re-assigned (as on line 413). Thus, per my reading > of the code, the tag that you are checking on line 419 is not the one > for encryption scheme, but rather the outer sequence tag encapsulating > kdf and encryption scheme. Its current location is very misleading > though, in between kdf and encryption scheme. To really check the tag > for kdf and encryption scheme, the tag checking should be in > parseKDF(...) and parseES(...) against the DerValue argument." > > I did add a DerValue check in parseKDF because it is appropriate as > you stated.? I also removed the check from line 419 in the old > webrev.? With the new code that check is redundant as we are using > AlgorithmId.parse() now as the initial operation in parseES, which in > turn does the sequence tag check for us. > > The check itself on 419 though is testing the ASN.1 tag for the > Encryption scheme, not the higher level sequence for PBES2-params.? > Otherwise neither the KDF nor the encryption scheme would parse > properly and none of the tests would pass. > > With this new code, parseKDF and parseES are testing the outer > SEQUENCE tags for each of the AlgorithmIdentifier objects described by > keyDerivationFunc and encryptionScheme per RFC 8018. > > * keysize setting: This one is a bit tricky because key size is > specified in multiple ways.? The basic flow is this.? Key size > will start as KEYLEN_UNSPEC.? If it is at any point specified, > either via the constructor, by KDF params, or by enc params then > that is the value that is set.? At near the end of parsing a > validation of the encryption parameters occurs and at that point > the key length is checked against the algorithm.? If it is an alg > that uses a fixed value then keysize has to be consistent with > it.? If it is variable length and it is still KEYSIZE_UNSPEC that > is also a failure (since something needs to be specified to > distinguish RC2_40 from RC2_128, for example). > o This approach seems to work and catches the issue you found > where certain DER encodings could yield things like > PBEWithHmacSHA256AndRC5_-1. > * Added some new tests to handle the changes listed above. > > I'll be updating the CSR shortly to reflect comments there and I'll > send a separate review notice for that. > > Thanks, > > --Jamil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Wed Mar 18 23:06:45 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 18 Mar 2020 23:06:45 +0000 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> Message-ID: Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. hTH Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Valerie Peng Gesendet: Wednesday, March 18, 2020 11:57:37 PM An: OpenJDK Dev list Betreff: [15] RFR 8172680: Support SHA-3 based Hmac algorithms Anyone has time to help review this straight forward RFE? It's to add SHA-3 support to Hmac. RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ Mach5 run is clean. Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Wed Mar 18 23:07:49 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 18 Mar 2020 19:07:49 -0400 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> Message-ID: <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net> On 3/18/2020 6:57 PM, Valerie Peng wrote: > > Anyone has time to help review this straight forward RFE? It's to add > SHA-3 support to Hmac. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 > > Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie Valerie - I know the RFE says no PKCS11 because 2.40 doesn't include those items, but OASIS PKCS11 has proposed? SHA3 identifiers at https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result - maybe reach out and ask if these have been allocated pending the next release? Mike #define CKM_SHA3_256????????????? 0x000002b0UL ?#define CKM_SHA3_256_HMAC???????? 0x000002b1UL ?#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL ?#define CKM_SHA3_224????????????? 0x000002b5UL ?#define CKM_SHA3_224_HMAC???????? 0x000002b6UL ?#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL ?#define CKM_SHA3_384????????????? 0x000002c0UL ?#define CKM_SHA3_384_HMAC???????? 0x000002c1UL ?#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL ?#define CKM_SHA3_512????????????? 0x000002d0UL ?#define CKM_SHA3_512_HMAC???????? 0x000002d1UL ?#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL From weijun.wang at oracle.com Thu Mar 19 02:32:36 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Mar 2020 10:32:36 +0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: Message-ID: <3C74BA25-8003-48AF-916C-77FFEF236700@oracle.com> ECKeyPairGenerator.java: You can move the following lines to the beginning of the method: 132 // Check if the java implementation supports this curve 133 if (ECOperations.forParameters(ecSpec).isPresent()) { 134 return; 135 } Everything else looks fine. In the CSR, how about explicitly spell out the curve names we support in Java? You also need a release note: Talk about the system property, when it should be enabled, and why enabling it is probably not a good idea. Thanks, Max > On Mar 18, 2020, at 11:52 PM, Anthony Scarpino wrote: > > Max, > > Are you satisfied with this last update? > > Thanks > > Tony > >> On Mar 11, 2020, at 11:23 PM, Anthony Scarpino wrote: >> >> ?Another webrev update with Max's recent comments. >> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 >> >> Also I still need a reviewer for the CSR. >> >> thanks >> >> Tony >> >>> On 3/2/20 4:40 PM, Anthony Scarpino wrote: >>> Hi >>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>> The curves affected are: >>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>> Tony >> > From anthony.scarpino at oracle.com Thu Mar 19 03:09:06 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 18 Mar 2020 20:09:06 -0700 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: <3C74BA25-8003-48AF-916C-77FFEF236700@oracle.com> References: <3C74BA25-8003-48AF-916C-77FFEF236700@oracle.com> Message-ID: On 3/18/20 7:32 PM, Weijun Wang wrote: > ECKeyPairGenerator.java: > > You can move the following lines to the beginning of the method: > > 132 // Check if the java implementation supports this curve > 133 if (ECOperations.forParameters(ecSpec).isPresent()) { > 134 return; > 135 } I left it after the eparams.init() as this checks CurveDB.lookup, if the curve not found it returns an InvalidParameterSpecException which is wrapped into a InvalidAlgorithmParameterSpec. If I move the above check, now it only returns an InvalidAlgorithmParameterSpec. Going forward when this native library is removed, I think changing the exception wrapping is less of a concern, but since the purpose of this change is more for older releases, I thought keeping this consistent was more important, does that make sense and do you agree? > > Everything else looks fine. > > In the CSR, how about explicitly spell out the curve names we support in Java? ok > > You also need a release note: Talk about the system property, when it should be enabled, and why enabling it is probably not a good idea. Yes, when the CSR is reviewed I'll have a basis to write the Release Note from. > > Thanks, > Max > > > >> On Mar 18, 2020, at 11:52 PM, Anthony Scarpino wrote: >> >> Max, >> >> Are you satisfied with this last update? >> >> Thanks >> >> Tony >> >>> On Mar 11, 2020, at 11:23 PM, Anthony Scarpino wrote: >>> >>> ?Another webrev update with Max's recent comments. >>> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 >>> >>> Also I still need a reviewer for the CSR. >>> >>> thanks >>> >>> Tony >>> >>>> On 3/2/20 4:40 PM, Anthony Scarpino wrote: >>>> Hi >>>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>> The curves affected are: >>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>> Tony >>> >> > From weijun.wang at oracle.com Thu Mar 19 04:51:38 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Mar 2020 12:51:38 +0800 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <3C74BA25-8003-48AF-916C-77FFEF236700@oracle.com> Message-ID: <1656BA2C-E67D-4801-AE0B-41A7BC9A88DC@oracle.com> > On Mar 19, 2020, at 11:09 AM, Anthony Scarpino wrote: > > On 3/18/20 7:32 PM, Weijun Wang wrote: >> ECKeyPairGenerator.java: >> You can move the following lines to the beginning of the method: >> 132 // Check if the java implementation supports this curve >> 133 if (ECOperations.forParameters(ecSpec).isPresent()) { >> 134 return; >> 135 } > > I left it after the eparams.init() as this checks CurveDB.lookup, if the curve not found it returns an InvalidParameterSpecException which is wrapped into a InvalidAlgorithmParameterSpec. If I move the above check, now it only returns an InvalidAlgorithmParameterSpec. > > Going forward when this native library is removed, I think changing the exception wrapping is less of a concern, but since the purpose of this change is more for older releases, I thought keeping this consistent was more important, does that make sense and do you agree? Sounds reasonable. Thanks, Max > >> Everything else looks fine. >> In the CSR, how about explicitly spell out the curve names we support in Java? > > ok > >> You also need a release note: Talk about the system property, when it should be enabled, and why enabling it is probably not a good idea. > > Yes, when the CSR is reviewed I'll have a basis to write the Release Note from. > >> Thanks, >> Max >>> On Mar 18, 2020, at 11:52 PM, Anthony Scarpino wrote: >>> >>> Max, >>> >>> Are you satisfied with this last update? >>> >>> Thanks >>> >>> Tony >>> >>>> On Mar 11, 2020, at 11:23 PM, Anthony Scarpino wrote: >>>> >>>> ?Another webrev update with Max's recent comments. >>>> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 >>>> >>>> Also I still need a reviewer for the CSR. >>>> >>>> thanks >>>> >>>> Tony >>>> >>>>> On 3/2/20 4:40 PM, Anthony Scarpino wrote: >>>>> Hi >>>>> I need a review of the CSR and webrev for disabling by default the native SunEC curves from the API. With the recent verification changes in JDK-8237218, SunJCE is long dependent on the native code for verifying the constant-time curves. This disabling can be undone with setting a system property, jdk.sunec.disableNative. I'm doing a simultaneous review as changes for one will likely affect the other. >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>>>> The curves affected are: >>>>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>>>> Tony >>>> >>> > From matthias.baesken at sap.com Thu Mar 19 11:23:30 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 19 Mar 2020 11:23:30 +0000 Subject: security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java jtreg test errors Message-ID: Hello, for a few days we see the test security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java failing sometimes. The failures are seen not only in jdk/jdk but also in jdk11, that's why we suppose it might be some issue with the infrastructure and/or certificate authority ? The errors are like this one (shows up on different OS platforms) : ... Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Subject: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status at ValidatePathWithParams.validate(ValidatePathWithParams.java:177) at GlobalSignR6CA.main(GlobalSignR6CA.java:192) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: java.security.cert.CertPathValidatorException: OCSP response error: INTERNAL_ERROR at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:237) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84) at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) at ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288) at ValidatePathWithParams.validate(ValidatePathWithParams.java:142) ... 7 more Caused by: java.security.cert.CertPathValidatorException: OCSP response error: INTERNAL_ERROR at java.base/sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:386) at java.base/sun.security.provider.certpath.OCSP.check(OCSP.java:195) at java.base/sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:742) at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:362) at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336) at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) ... 13 more Do you notice the issue in your jtreg tests as well ? Any hints about this ? Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Mar 19 15:08:17 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Mar 2020 11:08:17 -0400 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> Message-ID: Hi Valerie, You should also file a CSR since these would be newly supported algorithms in the JDK. Please also add a release note and file a docs issue to update the JDK Providers doc with the new algorithms. --Sean On 3/18/20 6:57 PM, Valerie Peng wrote: > > Anyone has time to help review this straight forward RFE? It's to add > SHA-3 support to Hmac. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 > > Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie From sean.mullan at oracle.com Thu Mar 19 19:23:16 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Mar 2020 15:23:16 -0400 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: On 3/12/20 2:23 AM, Anthony Scarpino wrote: > Another webrev update with Max's recent comments. > https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 > > Also I still need a reviewer for the CSR. For the CSR, I think the Compatibility Kind should be "Behavioral" and the Scope "JDK". Can you list in the Specification section the APIs that will now throw an Exception when the native library is disabled and what that Exception is? The code diffs, while fine to leave in, seem a bit too raw to understand exactly what the behavior change is. Also, I think the specification section should provide a description of the system property, what the default value is and how the implementation handles case sensitivity and syntax errors (does it throw an Exception, ignore invalid values, etc). --Sean > > thanks > > Tony > > On 3/2/20 4:40 PM, Anthony Scarpino wrote: >> Hi >> >> I need a review of the CSR and webrev for disabling by default the >> native SunEC curves from the API.? With the recent verification >> changes in JDK-8237218, SunJCE is long dependent on the native code >> for verifying the constant-time curves.? This disabling can be undone >> with setting a? system property, jdk.sunec.disableNative.? I'm doing a >> simultaneous review as changes for one? will likely affect the other. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >> >> The curves affected are: >> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >> >> Tony > From valerie.peng at oracle.com Thu Mar 19 19:53:19 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Mar 2020 12:53:19 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> Message-ID: <357f0698-fdca-e543-30f3-1f9bef407204@oracle.com> Hi Sean, Yes, thanks for the reminder. I will file the release note and provider doc issue for this. Valerie On 3/19/2020 8:08 AM, Sean Mullan wrote: > Hi Valerie, > > You should also file a CSR since these would be newly supported > algorithms in the JDK. Please also add a release note and file a docs > issue to update the JDK Providers doc with the new algorithms. > > --Sean > > On 3/18/20 6:57 PM, Valerie Peng wrote: >> >> Anyone has time to help review this straight forward RFE? It's to add >> SHA-3 support to Hmac. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie From valerie.peng at oracle.com Thu Mar 19 19:54:46 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Mar 2020 12:54:46 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <357f0698-fdca-e543-30f3-1f9bef407204@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <357f0698-fdca-e543-30f3-1f9bef407204@oracle.com> Message-ID: And CSR also. On 3/19/2020 12:53 PM, Valerie Peng wrote: > Hi Sean, > > Yes, thanks for the reminder. I will file the release note and > provider doc issue for this. > > Valerie > > On 3/19/2020 8:08 AM, Sean Mullan wrote: >> Hi Valerie, >> >> You should also file a CSR since these would be newly supported >> algorithms in the JDK. Please also add a release note and file a docs >> issue to update the JDK Providers doc with the new algorithms. >> >> --Sean >> >> On 3/18/20 6:57 PM, Valerie Peng wrote: >>> >>> Anyone has time to help review this straight forward RFE? It's to >>> add SHA-3 support to Hmac. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie From valerie.peng at oracle.com Thu Mar 19 20:33:17 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Mar 2020 13:33:17 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> Message-ID: <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com> Hi Bernd, Thanks for the comments~ Please find additional reply inline. On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: > Hello Valerie. > > In MacKAT 121 you would get a NPE if the catch prints the skip > message, probably needs an additional return; guard? Good catch, will add a return. > > The BAOS default length change in parse() was not immediately clear to > me? (Maybe next s. Base64?) Some of the test values use ":" as a separator. When such separator is present, it takes a longer string to represent the same number of bytes. So, depending on whether the separator is used, the default number of bytes is calculated differently. > > BTW It is good to see that you also add truncated SHA512 variants. > It's not mentioned in commit message or RFE. Support for the truncated SHA512 variants is mainly done in a separate/earlier RFE, i.e. JDK-8051408 (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a comment to the RFE to make this clear. Regards, Valerie > > hTH > Bernd > > > > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Valerie Peng > *Gesendet:* Wednesday, March 18, 2020 11:57:37 PM > *An:* OpenJDK Dev list > *Betreff:* [15] RFR 8172680: Support SHA-3 based Hmac algorithms > > Anyone has time to help review this straight forward RFE? It's to add > SHA-3 support to Hmac. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 > > Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Mar 19 21:27:51 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Mar 2020 14:27:51 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net> Message-ID: <44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com> Hi Mike, Thanks for heads up. From what I can gather, SHA3 inclusion is part of PKCS#11 v3. Is this the next release which you are referring to? Or will there be an update to v2.40? Is there any schedule info for these update/release do you know? Following the convention, we normally don't add something which the underlying library has no support yet. With the new 6-month JDK release cycle, it's much faster for the added functionality to be available. So, I'd still prefer to update SunPKCS11 provider with SHA-3 once they are officially included. Valerie On 3/18/2020 4:07 PM, Michael StJohns wrote: > On 3/18/2020 6:57 PM, Valerie Peng wrote: >> >> Anyone has time to help review this straight forward RFE? It's to add >> SHA-3 support to Hmac. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie > > Valerie - > > I know the RFE says no PKCS11 because 2.40 doesn't include those > items, but OASIS PKCS11 has proposed? SHA3 identifiers at > https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result > - maybe reach out and ask if these have been allocated pending the > next release? > > Mike > > > #define CKM_SHA3_256????????????? 0x000002b0UL > ?#define CKM_SHA3_256_HMAC???????? 0x000002b1UL > ?#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL > ?#define CKM_SHA3_224????????????? 0x000002b5UL > ?#define CKM_SHA3_224_HMAC???????? 0x000002b6UL > ?#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL > ?#define CKM_SHA3_384????????????? 0x000002c0UL > ?#define CKM_SHA3_384_HMAC???????? 0x000002c1UL > ?#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL > ?#define CKM_SHA3_512????????????? 0x000002d0UL > ?#define CKM_SHA3_512_HMAC???????? 0x000002d1UL > ?#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL > > From anthony.scarpino at oracle.com Thu Mar 19 21:46:11 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 19 Mar 2020 14:46:11 -0700 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: On 3/19/20 12:23 PM, Sean Mullan wrote: > On 3/12/20 2:23 AM, Anthony Scarpino wrote: >> Another webrev update with Max's recent comments. >> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 >> >> Also I still need a reviewer for the CSR. > > For the CSR, I think the Compatibility Kind should be "Behavioral" and > the Scope "JDK". > > Can you list in the Specification section the APIs that will now throw > an Exception when the native library is disabled and what that Exception > is? The code diffs, while fine to leave in, seem a bit too raw to > understand exactly what the behavior change is. > > Also, I think the specification section should provide a description of > the system property, what the default value is and how the > implementation handles case sensitivity and syntax errors (does it throw > an Exception, ignore invalid values, etc). > > --Sean Updated > >> >> thanks >> >> Tony >> >> On 3/2/20 4:40 PM, Anthony Scarpino wrote: >>> Hi >>> >>> I need a review of the CSR and webrev for disabling by default the >>> native SunEC curves from the API.? With the recent verification >>> changes in JDK-8237218, SunJCE is long dependent on the native code >>> for verifying the constant-time curves.? This disabling can be undone >>> with setting a? system property, jdk.sunec.disableNative.? I'm doing >>> a simultaneous review as changes for one? will likely affect the other. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238911 >>> webrev: https://cr.openjdk.java.net/~ascarpino/8237219/ >>> >>> The curves affected are: >>> secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >>> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, >>> sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, >>> sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, >>> sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, >>> X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 >>> c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, >>> X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >>> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >>> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 >>> >>> Tony >> From valerie.peng at oracle.com Thu Mar 19 22:50:19 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Mar 2020 15:50:19 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <357f0698-fdca-e543-30f3-1f9bef407204@oracle.com> Message-ID: <2d6207cb-0ff0-cb86-1591-48bcbe3f1c3c@oracle.com> CSR: https://bugs.openjdk.java.net/browse/JDK-8241325 Please review~ Thanks! Valerie On 3/19/2020 12:54 PM, Valerie Peng wrote: > And CSR also. > > On 3/19/2020 12:53 PM, Valerie Peng wrote: >> Hi Sean, >> >> Yes, thanks for the reminder. I will file the release note and >> provider doc issue for this. >> >> Valerie >> >> On 3/19/2020 8:08 AM, Sean Mullan wrote: >>> Hi Valerie, >>> >>> You should also file a CSR since these would be newly supported >>> algorithms in the JDK. Please also add a release note and file a >>> docs issue to update the JDK Providers doc with the new algorithms. >>> >>> --Sean >>> >>> On 3/18/20 6:57 PM, Valerie Peng wrote: >>>> >>>> Anyone has time to help review this straight forward RFE? It's to >>>> add SHA-3 support to Hmac. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>>> >>>> Mach5 run is clean. >>>> >>>> Thanks, >>>> Valerie From valerie.peng at oracle.com Fri Mar 20 00:07:55 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Mar 2020 17:07:55 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com> Message-ID: <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com> Webrev updated: http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/ Thanks, Valerie On 3/19/2020 1:33 PM, Valerie Peng wrote: > > Hi Bernd, > > Thanks for the comments~ Please find additional reply inline. > > On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: >> Hello Valerie. >> >> In MacKAT 121 you would get a NPE if the catch prints the skip >> message, probably needs an additional return; guard? > > Good catch, will add a return. > >> >> The BAOS default length change in parse() was not immediately clear >> to me? (Maybe next s. Base64?) > > Some of the test values use ":" as a separator. When such separator is > present, it takes a longer string to represent the same number of > bytes. So, depending on whether the separator is used, the default > number of bytes is calculated differently. > >> >> BTW It is good to see that you also add truncated SHA512 variants. >> It's not mentioned in commit message or RFE. > > Support for the truncated SHA512 variants is mainly done in a > separate/earlier RFE, i.e. JDK-8051408 > (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the > missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ > truncated SHA512 variants. I can add a comment to the RFE to make this > clear. > > Regards, > > Valerie > >> >> hTH >> Bernd >> >> >> >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *Von:* security-dev im >> Auftrag von Valerie Peng >> *Gesendet:* Wednesday, March 18, 2020 11:57:37 PM >> *An:* OpenJDK Dev list >> *Betreff:* [15] RFR 8172680: Support SHA-3 based Hmac algorithms >> >> Anyone has time to help review this straight forward RFE? It's to add >> SHA-3 support to Hmac. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Mar 20 00:57:44 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Mar 2020 08:57:44 +0800 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com> <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com> Message-ID: Are we going to add the new OIDs/names to AlgorithmId.java? There are quite some duplicated info everywhere. Thanks, Max > On Mar 20, 2020, at 8:07 AM, Valerie Peng wrote: > > Webrev updated: http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/ > > Thanks, > Valerie > On 3/19/2020 1:33 PM, Valerie Peng wrote: >> Hi Bernd, >> >> Thanks for the comments~ Please find additional reply inline. >> >> On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: >>> Hello Valerie. >>> >>> In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? >> Good catch, will add a return. >> >>> >>> The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) >> Some of the test values use ":" as a separator. When such separator is present, it takes a longer string to represent the same number of bytes. So, depending on whether the separator is used, the default number of bytes is calculated differently. >> >>> >>> BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. >> Support for the truncated SHA512 variants is mainly done in a separate/earlier RFE, i.e. JDK-8051408 (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a comment to the RFE to make this clear. >> >> Regards, >> >> Valerie >> >>> >>> hTH >>> Bernd >>> >>> >>> >>> -- >>> http://bernd.eckenfels.net >>> Von: security-dev im Auftrag von Valerie Peng >>> Gesendet: Wednesday, March 18, 2020 11:57:37 PM >>> An: OpenJDK Dev list >>> Betreff: [15] RFR 8172680: Support SHA-3 based Hmac algorithms >>> >>> >>> Anyone has time to help review this straight forward RFE? It's to add >>> SHA-3 support to Hmac. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie From jamil.j.nimeh at oracle.com Fri Mar 20 06:08:42 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 19 Mar 2020 23:08:42 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <2d6207cb-0ff0-cb86-1591-48bcbe3f1c3c@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <357f0698-fdca-e543-30f3-1f9bef407204@oracle.com> <2d6207cb-0ff0-cb86-1591-48bcbe3f1c3c@oracle.com> Message-ID: The CSR looks straightforward to me.? You might mention that these algorithms are Standard Names in the specification section, but it's just a nit. --Jamil On 3/19/2020 3:50 PM, Valerie Peng wrote: > > CSR: https://bugs.openjdk.java.net/browse/JDK-8241325 > > Please review~ > > Thanks! > Valerie > On 3/19/2020 12:54 PM, Valerie Peng wrote: >> And CSR also. >> >> On 3/19/2020 12:53 PM, Valerie Peng wrote: >>> Hi Sean, >>> >>> Yes, thanks for the reminder. I will file the release note and >>> provider doc issue for this. >>> >>> Valerie >>> >>> On 3/19/2020 8:08 AM, Sean Mullan wrote: >>>> Hi Valerie, >>>> >>>> You should also file a CSR since these would be newly supported >>>> algorithms in the JDK. Please also add a release note and file a >>>> docs issue to update the JDK Providers doc with the new algorithms. >>>> >>>> --Sean >>>> >>>> On 3/18/20 6:57 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has time to help review this straight forward RFE? It's to >>>>> add SHA-3 support to Hmac. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>>>> >>>>> Mach5 run is clean. >>>>> >>>>> Thanks, >>>>> Valerie From sean.mullan at oracle.com Fri Mar 20 13:16:39 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Mar 2020 09:16:39 -0400 Subject: 8237219: Disabling the native SunEC implementation In-Reply-To: References: <9487361e-4e3d-b349-45b7-11d80905df86@oracle.com> Message-ID: <10fb8581-6a04-b3df-b8bb-0b59dc32cfcb@oracle.com> On 3/19/20 5:46 PM, Anthony Scarpino wrote: > On 3/19/20 12:23 PM, Sean Mullan wrote: >> On 3/12/20 2:23 AM, Anthony Scarpino wrote: >>> Another webrev update with Max's recent comments. >>> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03 >>> >>> Also I still need a reviewer for the CSR. >> >> For the CSR, I think the Compatibility Kind should be "Behavioral" and >> the Scope "JDK". >> >> Can you list in the Specification section the APIs that will now throw >> an Exception when the native library is disabled and what that >> Exception is? The code diffs, while fine to leave in, seem a bit too >> raw to understand exactly what the behavior change is. >> >> Also, I think the specification section should provide a description >> of the system property, what the default value is and how the >> implementation handles case sensitivity and syntax errors (does it >> throw an Exception, ignore invalid values, etc). >> >> --Sean > > Updated Thanks. I added my name as Reviewer. --Sean From RAJAN.HALADE at ORACLE.COM Fri Mar 20 16:45:25 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Fri, 20 Mar 2020 09:45:25 -0700 Subject: security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java jtreg test errors In-Reply-To: References: Message-ID: Hi Matthias, I tried several runs of this test but am not able to reproduce the issue. May be requests from my tests are routed to different OCSP instance. OCSP responder instance can return internalError for inconsistent internal state. How frequent is the failure for you if you are still seeing it? Thanks, Rajan > On Mar 19, 2020, at 4:23 AM, Baesken, Matthias wrote: > > Hello, for a few days we see the test security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java > failing sometimes. The failures are seen not only in jdk/jdk but also in jdk11, that's why we suppose it might be > some issue with the infrastructure and/or certificate authority ? > > The errors are like this one (shows up on different OS platforms) : > ... > > Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US > Subject: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) > certpath: X509CertSelector.match: subject DNs don't match > java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status > at ValidatePathWithParams.validate(ValidatePathWithParams.java:177) > at GlobalSignR6CA.main(GlobalSignR6CA.java:192) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.security.cert.CertPathValidatorException: OCSP response error: INTERNAL_ERROR > at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) > at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:237) > at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145) > at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84) > at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) > at ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288) > at ValidatePathWithParams.validate(ValidatePathWithParams.java:142) > ... 7 more > Caused by: java.security.cert.CertPathValidatorException: OCSP response error: INTERNAL_ERROR > at java.base/sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:386) > at java.base/sun.security.provider.certpath.OCSP.check(OCSP.java:195) > at java.base/sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:742) > at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:362) > at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336) > at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) > ... 13 more > > Do you notice the issue in your jtreg tests as well ? > > Any hints about this ? > > Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Mar 20 17:15:26 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Mar 2020 13:15:26 -0400 Subject: security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java jtreg test errors In-Reply-To: References: Message-ID: <0defa213-c5b2-2ce4-5176-59404fa61986@oracle.com> See also the March 20 issue at https://www.globalsign.com/en/status. It could be related. I would monitor it going forward and see if you have any more issues, and if so we can report it to GlobalSign. --Sean On 3/20/20 12:45 PM, Rajan Halade wrote: > Hi Matthias, > > I tried several runs of this test but am not able to reproduce the > issue. May be requests from my tests are routed to different OCSP > instance. OCSP responder instance can return internalError for > inconsistent internal state. > > How frequent is the failure for you if you are still seeing it? > > Thanks, > Rajan > >> On Mar 19, 2020, at 4:23 AM, Baesken, Matthias >> > wrote: >> >> Hello, for a few days we see the test >> security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java >> failing sometimes. The failures are seen not only in jdk/jdk but also >> in jdk11, that's why we suppose it might be >> some issue with the infrastructure and/or certificate authority ? >> The errors ?are like this one ?(shows up on different OS platforms) : >> ... >> ? Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - >> G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", >> OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US >> ? Subject: CN=VeriSign Class 3 Public Primary Certification Authority >> - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", >> OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) >> certpath: X509CertSelector.match: subject DNs don't match >> java.lang.RuntimeException: TEST FAILED: couldn't determine EE >> certificate status >> ?????????????? at >> ValidatePathWithParams.validate(ValidatePathWithParams.java:177) >> ?????????????? at GlobalSignR6CA.main(GlobalSignR6CA.java:192) >> ?????????????? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> ?????????????? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> ?????????????? at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ?????????????? at >> java.base/java.lang.reflect.Method.invoke(Method.java:566) >> ?????????????? at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> ?????????????? at java.base/java.lang.Thread.run(Thread.java:834) >> Caused by: java.security.cert.CertPathValidatorException: OCSP >> response error: INTERNAL_ERROR >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:237) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84) >> ?????????????? at >> java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) >> ?????????????? at >> ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288) >> ?????????????? at >> ValidatePathWithParams.validate(ValidatePathWithParams.java:142) >> ?????????????? ... 7 more >> Caused by: java.security.cert.CertPathValidatorException: OCSP >> response error: INTERNAL_ERROR >> ?????????????? at >> java.base/sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:386) >> ?????????????? at >> java.base/sun.security.provider.certpath.OCSP.check(OCSP.java:195) >> ?????????????? at >> java.base/sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:742) >> ?????????????? at >> java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:362) >> ?????????????? at >> java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) >> ?????????????? ... 13 more >> Do you notice the issue in your jtreg tests as well ? >> Any hints about this ? >> Thanks, Matthias > From paul.sandoz at oracle.com Fri Mar 20 17:16:30 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Mar 2020 10:16:30 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Message-ID: <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java @@ -1379,12 +1379,12 @@ /** * This implementation returns {@code true} if {@code obj} is another - * {@code WeakEntry} whose referent is equals to this referent, or - * if {@code obj} is equals to the referent of this. This allows + * {@code WeakEntry} whose referent equals to this referent, or + * if {@code obj} equals to the referent of this. This allows * lookups to be made without wrapping in a {@code WeakEntry}. * * @param obj the object to compare - * @return true if {@code obj} is equals to this or the referent of this + * @return true if {@code obj} equals to this or the referent of this * @see MethodType#equals(Object) * @see Object#equals(Object) Use either: whose referent is equal to this referent, or whose referent equals this referent, The former is easier just delete the ?s?. Other bits look good. Paul. > On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: > > Hi Pavel! > > Can this please be combined with my collection of typos? > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >> >> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.nio.file, >> java.nio.file.attribute, >> java.security, >> java.time.chrono, >> java.time.temporal, >> java.util, >> java.util.regex, >> java.util.stream, >> javax.crypto, >> javax.security.cert, >> javax.tools >> >> That said, there are two changes that I'd prefer to be carefully reviewed by >> the experts in the corresponding areas. >> >> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >> supported for the sake of backward compatibility. Sadly, we have a number of >> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >> should better be verified by the security folk. >> >> The second one is for the doc comment for the java.util.stream.Stream.collect method. >> >> @apiNote >> The following will accumulate strings into an ArrayList: >> >> List asList = stringStream.collect(Collectors.toList()); >> >> Given that the spec for Collectors.toList() clearly says that >> >> ...There are no guarantees on the type, mutability, serializability, or >> thread-safety of the List returned;... >> >> I'd assume that @apiNote should be fixed as proposed. >> >> -Pavel >> >> P.S. Apologies for spamming multiple mailing lists. >> > -- > With kind regards, > Ivan Gerasimov > From paul.sandoz at oracle.com Fri Mar 20 17:22:12 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Mar 2020 10:22:12 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <4278B6CA-34D5-4857-A5A7-D885C69CDB9E@oracle.com> +1 Paul. > On Mar 13, 2020, at 8:42 AM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From sean.mullan at oracle.com Fri Mar 20 17:30:08 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Mar 2020 13:30:08 -0400 Subject: security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java jtreg test errors In-Reply-To: <0defa213-c5b2-2ce4-5176-59404fa61986@oracle.com> References: <0defa213-c5b2-2ce4-5176-59404fa61986@oracle.com> Message-ID: <1f25600d-2bc6-6e62-7ff4-717769497ba6@oracle.com> On 3/20/20 1:15 PM, Sean Mullan wrote: > See also the March 20 issue at https://www.globalsign.com/en/status. I meant to say the March *2020* issue, where it says "Load-based issues in Singapore Data Centre", Updated on 18 March 2020. --Sean > It > could be related. I would monitor it going forward and see if you have > any more issues, and if so we can report it to GlobalSign. > > --Sean > > On 3/20/20 12:45 PM, Rajan Halade wrote: >> Hi Matthias, >> >> I tried several runs of this test but am not able to reproduce the >> issue. May be requests from my tests are routed to different OCSP >> instance. OCSP responder instance can return internalError for >> inconsistent internal state. >> >> How frequent is the failure for you if you are still seeing it? >> >> Thanks, >> Rajan >> >>> On Mar 19, 2020, at 4:23 AM, Baesken, Matthias >>> > wrote: >>> >>> Hello, for a few days we see the test >>> security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java >>> >>> failing sometimes. The failures are seen not only in jdk/jdk but also >>> in jdk11, that's why we suppose it might be >>> some issue with the infrastructure and/or certificate authority ? >>> The errors ?are like this one ?(shows up on different OS platforms) : >>> ... >>> ? Issuer: CN=VeriSign Class 3 Public Primary Certification Authority >>> - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", >>> OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US >>> ? Subject: CN=VeriSign Class 3 Public Primary Certification Authority >>> - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", >>> OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) >>> certpath: X509CertSelector.match: subject DNs don't match >>> java.lang.RuntimeException: TEST FAILED: couldn't determine EE >>> certificate status >>> ?????????????? at >>> ValidatePathWithParams.validate(ValidatePathWithParams.java:177) >>> ?????????????? at GlobalSignR6CA.main(GlobalSignR6CA.java:192) >>> ?????????????? at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> ?????????????? at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> ?????????????? at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> ?????????????? at >>> java.base/java.lang.reflect.Method.invoke(Method.java:566) >>> ?????????????? at >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >>> >>> ?????????????? at java.base/java.lang.Thread.run(Thread.java:834) >>> Caused by: java.security.cert.CertPathValidatorException: OCSP >>> response error: INTERNAL_ERROR >>> ?????????????? at >>> java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:237) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84) >>> >>> ?????????????? at >>> java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) >>> >>> ?????????????? at >>> ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288) >>> >>> ?????????????? at >>> ValidatePathWithParams.validate(ValidatePathWithParams.java:142) >>> ?????????????? ... 7 more >>> Caused by: java.security.cert.CertPathValidatorException: OCSP >>> response error: INTERNAL_ERROR >>> ?????????????? at >>> java.base/sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:386) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.OCSP.check(OCSP.java:195) >>> ?????????????? at >>> java.base/sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:742) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:362) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336) >>> >>> ?????????????? at >>> java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) >>> >>> ?????????????? ... 13 more >>> Do you notice the issue in your jtreg tests as well ? >>> Any hints about this ? >>> Thanks, Matthias >> From valerie.peng at oracle.com Fri Mar 20 18:39:57 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 20 Mar 2020 11:39:57 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com> <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com> Message-ID: <16f323d4-52eb-5bd3-90b7-426a4ce5379f@oracle.com> Hi Max, I didn't touch AlgorithmId.java class in this RFE as these provider-defined HmacSHA3-xxx oids alias mapping are picked up by AlgorithmId.java inside its computeOidTable() method. AlgorithmId class should be still be able to find the String->oid string mapping from its oidTable field. But the constructed AlgorithmId object will return the oid string instead of the use-friendly name when its getName() is called. As I have started prototyping changes for minimizing the current duplication of oids in various providers and sun.security.x509.AlgorithmId class, I choose to leave AlgorithmId class out for now. I am on the fence about this and if you saw value for returning the friendly name for Hmac SHA3, I could add another 4 oid constants for Hmac SHA3 and add their name mapping to the AlgorithmId.nameTable. Majority of these will be changed during the oid duplication cleanup which I will file an RFE to track once this prototyping is somewhat done. Thanks, Valerie On 3/19/2020 5:57 PM, Weijun Wang wrote: > Are we going to add the new OIDs/names to AlgorithmId.java? There are quite some duplicated info everywhere. > > Thanks, > Max > >> On Mar 20, 2020, at 8:07 AM, Valerie Peng wrote: >> >> Webrev updated: http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/ >> >> Thanks, >> Valerie >> On 3/19/2020 1:33 PM, Valerie Peng wrote: >>> Hi Bernd, >>> >>> Thanks for the comments~ Please find additional reply inline. >>> >>> On 3/18/2020 4:06 PM, Bernd Eckenfels wrote: >>>> Hello Valerie. >>>> >>>> In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? >>> Good catch, will add a return. >>> >>>> The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) >>> Some of the test values use ":" as a separator. When such separator is present, it takes a longer string to represent the same number of bytes. So, depending on whether the separator is used, the default number of bytes is calculated differently. >>> >>>> BTW It is good to see that you also add truncated SHA512 variants. It's not mentioned in commit message or RFE. >>> Support for the truncated SHA512 variants is mainly done in a separate/earlier RFE, i.e. JDK-8051408 (https://bugs.openjdk.java.net/browse/JDK-8051408). I only added the missing OIDs and the supporting classes, i.e. KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a comment to the RFE to make this clear. >>> >>> Regards, >>> >>> Valerie >>> >>>> hTH >>>> Bernd >>>> >>>> >>>> >>>> -- >>>> http://bernd.eckenfels.net >>>> Von: security-dev im Auftrag von Valerie Peng >>>> Gesendet: Wednesday, March 18, 2020 11:57:37 PM >>>> An: OpenJDK Dev list >>>> Betreff: [15] RFR 8172680: Support SHA-3 based Hmac algorithms >>>> >>>> >>>> Anyone has time to help review this straight forward RFE? It's to add >>>> SHA-3 support to Hmac. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>>> >>>> Mach5 run is clean. >>>> >>>> Thanks, >>>> Valerie From valerie.peng at oracle.com Fri Mar 20 20:04:52 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 20 Mar 2020 13:04:52 -0700 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <357f0698-fdca-e543-30f3-1f9bef407204@oracle.com> <2d6207cb-0ff0-cb86-1591-48bcbe3f1c3c@oracle.com> Message-ID: <169924db-cbcc-74b6-99ff-1057a86df4a1@oracle.com> Sure, I will do that. Thanks for the review~ Valerie On 3/19/2020 11:08 PM, Jamil Nimeh wrote: > The CSR looks straightforward to me.? You might mention that these > algorithms are Standard Names in the specification section, but it's > just a nit. > > --Jamil > > On 3/19/2020 3:50 PM, Valerie Peng wrote: >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8241325 >> >> Please review~ >> >> Thanks! >> Valerie >> On 3/19/2020 12:54 PM, Valerie Peng wrote: >>> And CSR also. >>> >>> On 3/19/2020 12:53 PM, Valerie Peng wrote: >>>> Hi Sean, >>>> >>>> Yes, thanks for the reminder. I will file the release note and >>>> provider doc issue for this. >>>> >>>> Valerie >>>> >>>> On 3/19/2020 8:08 AM, Sean Mullan wrote: >>>>> Hi Valerie, >>>>> >>>>> You should also file a CSR since these would be newly supported >>>>> algorithms in the JDK. Please also add a release note and file a >>>>> docs issue to update the JDK Providers doc with the new algorithms. >>>>> >>>>> --Sean >>>>> >>>>> On 3/18/20 6:57 PM, Valerie Peng wrote: >>>>>> >>>>>> Anyone has time to help review this straight forward RFE? It's to >>>>>> add SHA-3 support to Hmac. >>>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>>>>> >>>>>> Mach5 run is clean. >>>>>> >>>>>> Thanks, >>>>>> Valerie From ivan.gerasimov at oracle.com Fri Mar 20 20:11:57 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Mar 2020 13:11:57 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> Message-ID: Thank you Paul! grep found a few more occurrences of? 'equals to'? across java.base, so I fixed them as well. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/01/webrev/ Pavel, I checked your portion of correction, everything looks good to me! One minor nit:? In src/java.base/share/classes/java/util/StringJoiner.java can you please wrap the modified line, so it won't be that long? With kind regards, Ivan On 3/20/20 10:16 AM, Paul Sandoz wrote: > --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java > @@ -1379,12 +1379,12 @@ > > /** > * This implementation returns {@code true} if {@code obj} is another > - * {@code WeakEntry} whose referent is equals to this referent, or > - * if {@code obj} is equals to the referent of this. This allows > + * {@code WeakEntry} whose referent equals to this referent, or > + * if {@code obj} equals to the referent of this. This allows > * lookups to be made without wrapping in a {@code WeakEntry}. > * > * @param obj the object to compare > - * @return true if {@code obj} is equals to this or the referent of this > + * @return true if {@code obj} equals to this or the referent of this > * @see MethodType#equals(Object) > * @see Object#equals(Object) > > Use either: > > whose referent is equal to this referent, > > or > > whose referent equals this referent, > > The former is easier just delete the ?s?. > > Other bits look good. > > Paul. > >> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: >> >> Hi Pavel! >> >> Can this please be combined with my collection of typos? >> >> http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ >> >> Just to save cycles on reviewing :) >> >> With kind regards, >> >> Ivan >> >> >> On 3/13/20 8:42 AM, Pavel Rappo wrote: >>> Hello, >>> >>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >>> >>> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >>> >>> This is a documentation cleanup. There are no code changes involved, >>> and the changes in documentation are mostly trivial. >>> >>> The following packages are affected: >>> >>> java.lang, >>> java.nio.file, >>> java.nio.file.attribute, >>> java.security, >>> java.time.chrono, >>> java.time.temporal, >>> java.util, >>> java.util.regex, >>> java.util.stream, >>> javax.crypto, >>> javax.security.cert, >>> javax.tools >>> >>> That said, there are two changes that I'd prefer to be carefully reviewed by >>> the experts in the corresponding areas. >>> >>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >>> supported for the sake of backward compatibility. Sadly, we have a number of >>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >>> should better be verified by the security folk. >>> >>> The second one is for the doc comment for the java.util.stream.Stream.collect method. >>> >>> @apiNote >>> The following will accumulate strings into an ArrayList: >>> >>> List asList = stringStream.collect(Collectors.toList()); >>> >>> Given that the spec for Collectors.toList() clearly says that >>> >>> ...There are no guarantees on the type, mutability, serializability, or >>> thread-safety of the List returned;... >>> >>> I'd assume that @apiNote should be fixed as proposed. >>> >>> -Pavel >>> >>> P.S. Apologies for spamming multiple mailing lists. >>> >> -- >> With kind regards, >> Ivan Gerasimov >> -- With kind regards, Ivan Gerasimov From pavel.rappo at oracle.com Fri Mar 20 21:00:29 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 20 Mar 2020 21:00:29 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> Message-ID: <1EE3B1EB-15AA-4BCC-9A60-37CAC906E244@oracle.com> Thanks Ivan, I merged your changes with mine and pushed the resulting changeset. > On 20 Mar 2020, at 20:11, Ivan Gerasimov wrote: > > Thank you Paul! > > grep found a few more occurrences of 'equals to' across java.base, so I fixed them as well. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/01/webrev/ > > > Pavel, I checked your portion of correction, everything looks good to me! > > One minor nit: In src/java.base/share/classes/java/util/StringJoiner.java can you please wrap the modified line, so it won't be that long? > > > With kind regards, > > Ivan > > > On 3/20/20 10:16 AM, Paul Sandoz wrote: >> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java >> @@ -1379,12 +1379,12 @@ >> /** >> * This implementation returns {@code true} if {@code obj} is another >> - * {@code WeakEntry} whose referent is equals to this referent, or >> - * if {@code obj} is equals to the referent of this. This allows >> + * {@code WeakEntry} whose referent equals to this referent, or >> + * if {@code obj} equals to the referent of this. This allows >> * lookups to be made without wrapping in a {@code WeakEntry}. >> * >> * @param obj the object to compare >> - * @return true if {@code obj} is equals to this or the referent of this >> + * @return true if {@code obj} equals to this or the referent of this >> * @see MethodType#equals(Object) >> * @see Object#equals(Object) >> Use either: >> >> whose referent is equal to this referent, >> >> or >> >> whose referent equals this referent, >> >> The former is easier just delete the ?s?. >> >> Other bits look good. >> >> Paul. >> >>> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: >>> >>> Hi Pavel! >>> >>> Can this please be combined with my collection of typos? >>> >>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ >>> >>> Just to save cycles on reviewing :) >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 3/13/20 8:42 AM, Pavel Rappo wrote: >>>> Hello, >>>> >>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >>>> >>>> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >>>> >>>> This is a documentation cleanup. There are no code changes involved, >>>> and the changes in documentation are mostly trivial. >>>> >>>> The following packages are affected: >>>> >>>> java.lang, >>>> java.nio.file, >>>> java.nio.file.attribute, >>>> java.security, >>>> java.time.chrono, >>>> java.time.temporal, >>>> java.util, >>>> java.util.regex, >>>> java.util.stream, >>>> javax.crypto, >>>> javax.security.cert, >>>> javax.tools >>>> >>>> That said, there are two changes that I'd prefer to be carefully reviewed by >>>> the experts in the corresponding areas. >>>> >>>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >>>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >>>> supported for the sake of backward compatibility. Sadly, we have a number of >>>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >>>> should better be verified by the security folk. >>>> >>>> The second one is for the doc comment for the java.util.stream.Stream.collect method. >>>> >>>> @apiNote >>>> The following will accumulate strings into an ArrayList: >>>> >>>> List asList = stringStream.collect(Collectors.toList()); >>>> >>>> Given that the spec for Collectors.toList() clearly says that >>>> >>>> ...There are no guarantees on the type, mutability, serializability, or >>>> thread-safety of the List returned;... >>>> >>>> I'd assume that @apiNote should be fixed as proposed. >>>> >>>> -Pavel >>>> >>>> P.S. Apologies for spamming multiple mailing lists. >>>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> > -- > With kind regards, > Ivan Gerasimov > From weijun.wang at oracle.com Sat Mar 21 09:48:16 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 21 Mar 2020 17:48:16 +0800 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <16f323d4-52eb-5bd3-90b7-426a4ce5379f@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com> <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com> <16f323d4-52eb-5bd3-90b7-426a4ce5379f@oracle.com> Message-ID: > On Mar 21, 2020, at 2:39 AM, Valerie Peng wrote: > > As I have started prototyping changes for minimizing the current duplication of oids in various providers and sun.security.x509.AlgorithmId class, I choose to leave AlgorithmId class out for now. Very glad to hear this. No need to touch more on AlgorithmId.java then. Thanks, Max From xuelei.fan at oracle.com Sun Mar 22 01:35:10 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 21 Mar 2020 18:35:10 -0700 Subject: [15] RFR JDK-8215712,,Parsing extension failure may alert decode_error Message-ID: Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8215712/webrev.00/ While parsing the extensions, the alter used in the implementation may no comply to the specification. With this fix, an improvement is made by passing the HandshakeContext to the constructor of SSLExtensionSpec implementations. For example: - private AlpnSpec(ByteBuffer buffer) throws IOException { + private AlpnSpec(HandshakeContext context, ByteBuffer buffer) throws IOException { And then the 'context.fatal()' could be used for the specific alert. John, thanks for the testing with fuzzing! No new regression test added, and I added a noreg-external tag in JBS. Thanks, Xuelei From jamil.j.nimeh at oracle.com Sun Mar 22 16:06:57 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 22 Mar 2020 09:06:57 -0700 Subject: [15] RFR JDK-8215712,,Parsing extension failure may alert decode_error In-Reply-To: References: Message-ID: <51aa69b1-2a46-b21c-c50f-64993cf7e59d@oracle.com> Looks good to me. --Jamil On 3/21/2020 6:35 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8215712/webrev.00/ > > While parsing the extensions, the alter used in the implementation may > no comply to the specification.? With this fix, an improvement is made > by passing the HandshakeContext to the constructor of SSLExtensionSpec > implementations. For example: > - private AlpnSpec(ByteBuffer buffer) throws IOException { > + private AlpnSpec(HandshakeContext context, ByteBuffer buffer) throws > IOException { > > And then the 'context.fatal()' could be used for the specific alert. > > John, thanks for the testing with fuzzing!? No new regression test > added, and I added a noreg-external tag in JBS. > > Thanks, > Xuelei From matthias.baesken at sap.com Mon Mar 23 07:23:56 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Mar 2020 07:23:56 +0000 Subject: security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java jtreg test errors In-Reply-To: <0defa213-c5b2-2ce4-5176-59404fa61986@oracle.com> References: <0defa213-c5b2-2ce4-5176-59404fa61986@oracle.com> Message-ID: Hi Sean and Rajan, thanks for the info . >See also the March 20 issue at https://www.globalsign.com/en/status. It >could be related. We noticed the errors from 10. March - 19. March (no errors afterwards) in our test infrastructure , so the time windows matches to the time window Described here https://www.globalsign-media.com/en/incident-report/2020-03-18-singapore-dc . Most likely it is the issue described in the incident report . Best regards, Matthias -----Original Message----- From: Sean Mullan Sent: Freitag, 20. M?rz 2020 18:15 To: Rajan Halade ; Baesken, Matthias Cc: security-dev at openjdk.java.net Subject: Re: security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java jtreg test errors See also the March 20 issue at https://www.globalsign.com/en/status. It could be related. I would monitor it going forward and see if you have any more issues, and if so we can report it to GlobalSign. --Sean On 3/20/20 12:45 PM, Rajan Halade wrote: > Hi Matthias, > > I tried several runs of this test but am not able to reproduce the > issue. May be requests from my tests are routed to different OCSP > instance. OCSP responder instance can return internalError for > inconsistent internal state. > > How frequent is the failure for you if you are still seeing it? > > Thanks, > Rajan > >> On Mar 19, 2020, at 4:23 AM, Baesken, Matthias >> > wrote: >> >> Hello, for a few days we see the test >> security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java >> failing sometimes. The failures are seen not only in jdk/jdk but also >> in jdk11, that's why we suppose it might be >> some issue with the infrastructure and/or certificate authority ? >> The errors ?are like this one ?(shows up on different OS platforms) : >> ... >> ? Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - >> G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", >> OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US >> ? Subject: CN=VeriSign Class 3 Public Primary Certification Authority >> - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", >> OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) >> certpath: X509CertSelector.match: subject DNs don't match >> java.lang.RuntimeException: TEST FAILED: couldn't determine EE >> certificate status >> ?????????????? at >> ValidatePathWithParams.validate(ValidatePathWithParams.java:177) >> ?????????????? at GlobalSignR6CA.main(GlobalSignR6CA.java:192) >> ?????????????? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> ?????????????? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> ?????????????? at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ?????????????? at >> java.base/java.lang.reflect.Method.invoke(Method.java:566) >> ?????????????? at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> ?????????????? at java.base/java.lang.Thread.run(Thread.java:834) >> Caused by: java.security.cert.CertPathValidatorException: OCSP >> response error: INTERNAL_ERROR >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:237) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84) >> ?????????????? at >> java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) >> ?????????????? at >> ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288) >> ?????????????? at >> ValidatePathWithParams.validate(ValidatePathWithParams.java:142) >> ?????????????? ... 7 more >> Caused by: java.security.cert.CertPathValidatorException: OCSP >> response error: INTERNAL_ERROR >> ?????????????? at >> java.base/sun.security.provider.certpath.OCSPResponse.verify(OCSPResponse.java:386) >> ?????????????? at >> java.base/sun.security.provider.certpath.OCSP.check(OCSP.java:195) >> ?????????????? at >> java.base/sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:742) >> ?????????????? at >> java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:362) >> ?????????????? at >> java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336) >> ?????????????? at >> java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) >> ?????????????? ... 13 more >> Do you notice the issue in your jtreg tests as well ? >> Any hints about this ? >> Thanks, Matthias > From anthony.scarpino at oracle.com Mon Mar 23 18:53:22 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 23 Mar 2020 11:53:22 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: Message-ID: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> On 2/25/20 12:49 PM, Anthony Scarpino wrote: > Hi > > I need a code review for the EdDSA support in JEP 339.? The code builds > on the existing java implemented constant time classes used for XDH and > the NIST curves.? The change also adds classes to the public API to > support EdDSA operations. > > All information about the JEP is located at: > JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 > CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 > > webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ > > thanks > > Tony I updated the webrev with some minor updates that were commented previously. https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ Tony From sha.jiang at oracle.com Wed Mar 25 01:50:13 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 25 Mar 2020 09:50:13 +0800 Subject: RFR[15] JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java Message-ID: <8fd00f2d-7e00-3a6b-cbbe-3e8ccc6de6c9@oracle.com> Hi, This patch updates the manual test javax/net/ssl/compatibility/Compatibility.java on the following points: 1. Covers SSLv3 2. The server side doesn't limit/specify protocols and cipher suites anymore. Only the client side specifies these parameters. 3. Only focus on the testing JDK specified by jtreg option "-jdk", and not run the cases between the JDKs builds in jdkList. This would save much execution time. 4. The report has a new column that clarifying why a case is a negative case. Issue: https://bugs.openjdk.java.net/browse/JDK-8237977 Webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.00/ Best regards, John Jiang From RAJAN.HALADE at ORACLE.COM Wed Mar 25 03:08:51 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Tue, 24 Mar 2020 20:08:51 -0700 Subject: RFR[15] JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java In-Reply-To: <8fd00f2d-7e00-3a6b-cbbe-3e8ccc6de6c9@oracle.com> References: <8fd00f2d-7e00-3a6b-cbbe-3e8ccc6de6c9@oracle.com> Message-ID: <71507D8F-FA7D-4FB3-A171-1FD9810B41EF@ORACLE.COM> Hi John, Thanks for taking care of this fix. Your changes look good me. I have couple of suggestions: - consider changing header for last column from ?Why negative case? to ?Reason? - for a failed test case (a testcase that succeeds when expected to fail or a testcase that fails when expected to succeed) code will not have any reason listed and we will need to click hyperlink in the report to find out root cause. May I suggest to pass in status to TestCase.negativeCaseReason() method call and use reason as ?Refer to log at test hyperlink for details?? for such cases. Thanks, Rajan > On Mar 24, 2020, at 6:50 PM, sha.jiang at oracle.com wrote: > > Hi, > This patch updates the manual test javax/net/ssl/compatibility/Compatibility.java on the following points: > 1. Covers SSLv3 > 2. The server side doesn't limit/specify protocols and cipher suites anymore. Only the client side specifies these parameters. > 3. Only focus on the testing JDK specified by jtreg option "-jdk", and not run the cases between the JDKs builds in jdkList. This would save much execution time. > 4. The report has a new column that clarifying why a case is a negative case. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8237977 > Webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.00/ > > Best regards, > John Jiang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Wed Mar 25 08:48:36 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 25 Mar 2020 16:48:36 +0800 Subject: RFR[15] JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java In-Reply-To: <71507D8F-FA7D-4FB3-A171-1FD9810B41EF@ORACLE.COM> References: <8fd00f2d-7e00-3a6b-cbbe-3e8ccc6de6c9@oracle.com> <71507D8F-FA7D-4FB3-A171-1FD9810B41EF@ORACLE.COM> Message-ID: <75b7cdfc-bc43-df20-1a9c-cb68885b8590@oracle.com> Hi Rajan, Thanks for your suggestions. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.01/ On 2020/3/25 11:08, Rajan Halade wrote: > Hi John, > > Thanks for taking care of this fix. Your changes look good me. > > I have couple of suggestions: > > - consider changing header for last column from ?Why negative case? to > ?Reason? > - for a failed test case (a testcase that succeeds when expected to > fail or a testcase that fails when expected to succeed) code will not > have any reason listed and we will need to click hyperlink in the > report to find out root cause. May I suggest to pass in status to > TestCase.negativeCaseReason() method call and use reason as ?Refer to > log at test hyperlink for details?? for such cases. A new method TestCase::reason is introduced for the reasons. Best regards, John Jiang > > Thanks, > Rajan > >> On Mar 24, 2020, at 6:50 PM, sha.jiang at oracle.com >> wrote: >> >> Hi, >> This patch updates the manual test >> javax/net/ssl/compatibility/Compatibility.java on the following points: >> 1. Covers SSLv3 >> 2. The server side doesn't limit/specify protocols and cipher suites >> anymore. Only the client side specifies these parameters. >> 3. Only focus on the testing JDK specified by jtreg option "-jdk", >> and not run the cases between the JDKs builds in jdkList. This would >> save much execution time. >> 4. The report has a new column that clarifying why a case is a >> negative case. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8237977 >> Webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.00/ >> >> Best regards, >> John Jiang >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From RAJAN.HALADE at ORACLE.COM Wed Mar 25 16:57:23 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Wed, 25 Mar 2020 09:57:23 -0700 Subject: RFR[15] JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java In-Reply-To: <75b7cdfc-bc43-df20-1a9c-cb68885b8590@oracle.com> References: <8fd00f2d-7e00-3a6b-cbbe-3e8ccc6de6c9@oracle.com> <71507D8F-FA7D-4FB3-A171-1FD9810B41EF@ORACLE.COM> <75b7cdfc-bc43-df20-1a9c-cb68885b8590@oracle.com> Message-ID: Thanks for the update. Changes look good to me. - Rajan > On Mar 25, 2020, at 1:48 AM, sha.jiang at oracle.com wrote: > > Hi Rajan, > Thanks for your suggestions. > Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.01/ > On 2020/3/25 11:08, Rajan Halade wrote: >> Hi John, >> >> Thanks for taking care of this fix. Your changes look good me. >> >> I have couple of suggestions: >> >> - consider changing header for last column from ?Why negative case? to ?Reason? >> - for a failed test case (a testcase that succeeds when expected to fail or a testcase that fails when expected to succeed) code will not have any reason listed and we will need to click hyperlink in the report to find out root cause. May I suggest to pass in status to TestCase.negativeCaseReason() method call and use reason as ?Refer to log at test hyperlink for details?? for such cases. > A new method TestCase::reason is introduced for the reasons. > > Best regards, > John Jiang >> >> >> Thanks, >> Rajan >> >>> On Mar 24, 2020, at 6:50 PM, sha.jiang at oracle.com wrote: >>> >>> Hi, >>> This patch updates the manual test javax/net/ssl/compatibility/Compatibility.java on the following points: >>> 1. Covers SSLv3 >>> 2. The server side doesn't limit/specify protocols and cipher suites anymore. Only the client side specifies these parameters. >>> 3. Only focus on the testing JDK specified by jtreg option "-jdk", and not run the cases between the JDKs builds in jdkList. This would save much execution time. >>> 4. The report has a new column that clarifying why a case is a negative case. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8237977 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Wed Mar 25 23:44:49 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 25 Mar 2020 16:44:49 -0700 Subject: [RFR:15] Release Note: Disable native SunEC implementation by default Message-ID: <28156dd9-081f-4ced-1296-6996e9d9ea48@oracle.com> Please review the proposed release note for JDK-8237219, the change to disable the native curves in SunEC. https://bugs.openjdk.java.net/browse/JDK-8241386 Thanks Tony From jamil.j.nimeh at oracle.com Thu Mar 26 00:42:30 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 25 Mar 2020 17:42:30 -0700 Subject: [RFR:15] Release Note: Disable native SunEC implementation by default In-Reply-To: <28156dd9-081f-4ced-1296-6996e9d9ea48@oracle.com> References: <28156dd9-081f-4ced-1296-6996e9d9ea48@oracle.com> Message-ID: <5739e343-9099-896b-2cca-70568ec85668@oracle.com> Hi Tony, * "Commonly used and time-constantly implemented curves, secp256r1, secp384r1, secp521r1, x25519, and x448, remain supported by SunEC" - time-constantly implemented sounds a bit awkward to my ear. o May I suggest an alternative: "The secp256r1, secp384r1, secp521r1, x25519, and x448 curve implementations are time-constant and remain supported by SunEC."? (I'm sure the wording could be better still). * Why are there asterisks around -Djdk.sunec.disableNative=false?? Were you trying to do some kind of markdown notation there? Otherwise it looks good to me. --Jamil On 3/25/2020 4:44 PM, Anthony Scarpino wrote: > Please review the proposed release note for JDK-8237219, the change to > disable the native curves in SunEC. > > https://bugs.openjdk.java.net/browse/JDK-8241386 > > Thanks > > Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Thu Mar 26 03:17:15 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 25 Mar 2020 20:17:15 -0700 Subject: [RFR:15] Release Note: Disable native SunEC implementation by default In-Reply-To: <5739e343-9099-896b-2cca-70568ec85668@oracle.com> References: <28156dd9-081f-4ced-1296-6996e9d9ea48@oracle.com> <5739e343-9099-896b-2cca-70568ec85668@oracle.com> Message-ID: <38fdffec-5ac9-1db0-4e82-15202c2d3a40@oracle.com> On 3/25/20 5:42 PM, Jamil Nimeh wrote: > Hi Tony, > > * "Commonly used and time-constantly implemented curves, secp256r1, > secp384r1, secp521r1, x25519, and x448, remain supported by SunEC" - > time-constantly implemented sounds a bit awkward to my ear. > o May I suggest an alternative: "The secp256r1, secp384r1, > secp521r1, x25519, and x448 curve implementations are > time-constant and remain supported by SunEC."? (I'm sure the > wording could be better still). Yeah, I've been fighting that too. I changed it up by just saying commonly used as that's more relevant. > * Why are there asterisks around -Djdk.sunec.disableNative=false? > Were you trying to do some kind of markdown notation there? I was trying to get italics. I thought it worked before but I'm probably forgotten the proper syntax. > > Otherwise it looks good to me. > > --Jamil > > On 3/25/2020 4:44 PM, Anthony Scarpino wrote: >> Please review the proposed release note for JDK-8237219, the change to >> disable the native curves in SunEC. >> >> https://bugs.openjdk.java.net/browse/JDK-8241386 >> >> Thanks >> >> Tony From sean.mullan at oracle.com Thu Mar 26 16:28:05 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Mar 2020 12:28:05 -0400 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> Message-ID: <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> Cross-posting to security-dev as this involves TLS/SSL configuration. --Sean On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote: > Hello, > > Request to have my fix reviewed for issues: > > ??? JDK-8239595 : ssl context version is not respected > ??? JDK-8239594 : jdk.tls.client.protocols is not respected > > The fix updates > jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx) > to use ctx.getDefaultSSLParameters()instead of > ctx.getSupportedSSLParameters(), > as the latter does not respect the context parameters set by the user. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8239595 > Issue: https://bugs.openjdk.java.net/browse/JDK-8239594 > > Webrev: > http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/ > > -- Rahul From sean.mullan at oracle.com Thu Mar 26 16:29:50 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Mar 2020 12:29:50 -0400 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> Message-ID: I think you should mark one of the two bugs a duplicate. Typically I mark the more recent one as a duplicate, unless there is a good reason to do otherwise. --Sean On 3/26/20 12:28 PM, Sean Mullan wrote: > Cross-posting to security-dev as this involves TLS/SSL configuration. > > --Sean > > On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote: >> Hello, >> >> Request to have my fix reviewed for issues: >> >> ???? JDK-8239595 : ssl context version is not respected >> ???? JDK-8239594 : jdk.tls.client.protocols is not respected >> >> The fix updates >> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx) >> to use ctx.getDefaultSSLParameters()instead of >> ctx.getSupportedSSLParameters(), >> as the latter does not respect the context parameters set by the user. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594 >> >> Webrev: >> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/ >> >> -- Rahul From xuelei.fan at oracle.com Thu Mar 26 16:58:49 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 26 Mar 2020 09:58:49 -0700 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> Message-ID: <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead; Otherwise, use TLSv1.3 and TLSv1.2. There may be a couple of issues: 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled. For example: System.setProperty("jdk.tls.client.protocols", "TLSv1.3") System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") 2. TLSv1.2 may be not supported in the SSLContext. For example: SSLContext context = SSLContext.getInstance("DTLS"); HttpClient.newBuilder().sslContext(context)... 3. The application may not want to use TLS 1.2. For example: System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") The System property may be shared by code other than httpclient. So the setting may not consider the impact on httpclient. I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack. Xuelei On 3/26/2020 9:28 AM, Sean Mullan wrote: > Cross-posting to security-dev as this involves TLS/SSL configuration. > > --Sean > > On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote: >> Hello, >> >> Request to have my fix reviewed for issues: >> >> ???? JDK-8239595 : ssl context version is not respected >> ???? JDK-8239594 : jdk.tls.client.protocols is not respected >> >> The fix updates >> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx) >> to use ctx.getDefaultSSLParameters()instead of >> ctx.getSupportedSSLParameters(), >> as the latter does not respect the context parameters set by the user. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594 >> >> Webrev: >> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/ >> >> -- Rahul From michael.x.mcmahon at oracle.com Fri Mar 27 10:50:18 2020 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Mar 2020 10:50:18 +0000 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> Message-ID: <56e188c6-725a-e3db-ca39-f5cffb4cca01@oracle.com> Hi Xuelei, I have some concerns about these bugs also, though not exactly the same as yours: The "jdk.tls.client.protocols" system property is not part of the HTTP client API. So, it's not clear to me why the HTTP client is expected to enforce it. It is equally possible for any code using SSLContext and SSLParameters to select protocols that appear to contradict the protocols set in the property. Same goes for the protocol used to initialize the SSLContext itself (bug 8239595). If it is an error to initialize the context with TLSv1.2, but then try to set TLSv1.3 in the SSLParameters, then why doesn't the TLS layer enforce that constraint? Is it even specified anywhere? That said, I think there is an issue that needs to be fixed. If a user wants to use TLS1.2, we certainly should not force them to use 1.3. I am beginning to think that the HTTP client should behave in a way that is more clear/transparent to its users as follows: 1) If the user specifies neither an SSLContext nor an SSLParameters, then the HTTP library should ??? choose a TLS version that is most likely to work for HTTP (maybe choose highest version that is available) 2) If the user specifies an SSLContext then we use the default SSLParameters without adding any protocol versions 3) If the user does not specify an SSLContext but does specify an SSLParameters then we create a default context ?? and apply the given SSLParameters (with no additional protocol versions added) So, for 2) and 3) it is up to the caller to ensure that the resulting SSL configuration "works".? It may fail of course with a handshake error (or runtime error presumably if you try to select DTLS for example). Maybe it would make more sense to fix that behavior through another bug id, because in my view these two issues are more of a spec/impl issue for the TLS layer itself. What do you think? Michael. On 26/03/2020 16:58, Xuelei Fan wrote: > With this update, the logic looks like: if TLSv1.3 is not enabled in > the SSLContext, use TLSv1.2 instead;? Otherwise, use TLSv1.3 and TLSv1.2. > > There may be a couple of issues: > 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled. > For example: > ?? System.setProperty("jdk.tls.client.protocols", "TLSv1.3") > ?? System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") > > 2. TLSv1.2 may be not supported in the SSLContext. > For example: > ?? SSLContext context = SSLContext.getInstance("DTLS"); > ?? HttpClient.newBuilder().sslContext(context)... > > 3. The application may not want to use TLS 1.2. > For example: > ?? System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") > > The System property may be shared by code other than httpclient. So > the setting may not consider the impact on httpclient. > > I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an > empty protocol array, and test to see what happens in the httpclient > implementation stack. > > Xuelei > > On 3/26/2020 9:28 AM, Sean Mullan wrote: >> Cross-posting to security-dev as this involves TLS/SSL configuration. >> >> --Sean >> >> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote: >>> Hello, >>> >>> Request to have my fix reviewed for issues: >>> >>> ???? JDK-8239595 : ssl context version is not respected >>> ???? JDK-8239594 : jdk.tls.client.protocols is not respected >>> >>> The fix updates >>> jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx) >>> to use ctx.getDefaultSSLParameters()instead of >>> ctx.getSupportedSSLParameters(), >>> as the latter does not respect the context parameters set by the user. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/ >>> >>> -- Rahul From norman.maurer at googlemail.com Fri Mar 27 12:48:15 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 27 Mar 2020 13:48:15 +0100 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side Message-ID: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> Hi there, I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not. Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn?t show the same result. Does this sounds like a regression and if so should I provide a standalone reproducer here ? Bye Norman From chris.hegarty at oracle.com Fri Mar 27 12:52:40 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 27 Mar 2020 12:52:40 +0000 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> Message-ID: <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> Xuelei, Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. Is there a specification or other documentation describing `jdk.tls.client.protocols` ? It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`, and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do? -Chris. > On 26 Mar 2020, at 16:58, Xuelei Fan wrote: > > With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead; Otherwise, use TLSv1.3 and TLSv1.2. > > There may be a couple of issues: > 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled. > For example: > System.setProperty("jdk.tls.client.protocols", "TLSv1.3") > System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") > > 2. TLSv1.2 may be not supported in the SSLContext. > For example: > SSLContext context = SSLContext.getInstance("DTLS"); > HttpClient.newBuilder().sslContext(context)... > > 3. The application may not want to use TLS 1.2. > For example: > System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") > > The System property may be shared by code other than httpclient. So the setting may not consider the impact on httpclient. > > I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack. > > Xuelei > > On 3/26/2020 9:28 AM, Sean Mullan wrote: >> Cross-posting to security-dev as this involves TLS/SSL configuration. >> --Sean >> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote: >>> Hello, >>> >>> Request to have my fix reviewed for issues: >>> >>> JDK-8239595 : ssl context version is not respected >>> JDK-8239594 : jdk.tls.client.protocols is not respected >>> >>> The fix updates jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx) >>> to use ctx.getDefaultSSLParameters()instead of ctx.getSupportedSSLParameters(), >>> as the latter does not respect the context parameters set by the user. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594 >>> >>> Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/ >>> >>> -- Rahul From xuelei.fan at oracle.com Fri Mar 27 16:23:30 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 27 Mar 2020 09:23:30 -0700 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> Message-ID: <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com> On 3/27/2020 5:52 AM, Chris Hegarty wrote: > Xuelei, > > Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. > > Is there a specification or other documentation describing `jdk.tls.client.protocols` ? > See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides: "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9 For your quick reference, I copied the note here: --------------- Customized Item: Default handshaking protocols for TLS/DTLS clients. Notes: To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client For example, If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled --------------- > It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`, It is correct that the property impact the default SSLContext only. The default SSLContext instance could get from: SSLContext.getInstance("Default"); SSLContext.getInstance("TLS"); SSLContext.getInstance("DTLS"); > and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do? Yes. Xuelei > -Chris. > >> On 26 Mar 2020, at 16:58, Xuelei Fan wrote: >> >> With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead; Otherwise, use TLSv1.3 and TLSv1.2. >> >> There may be a couple of issues: >> 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled. >> For example: >> System.setProperty("jdk.tls.client.protocols", "TLSv1.3") >> System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") >> >> 2. TLSv1.2 may be not supported in the SSLContext. >> For example: >> SSLContext context = SSLContext.getInstance("DTLS"); >> HttpClient.newBuilder().sslContext(context)... >> >> 3. The application may not want to use TLS 1.2. >> For example: >> System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0") >> >> The System property may be shared by code other than httpclient. So the setting may not consider the impact on httpclient. >> >> I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack. >> >> Xuelei >> >> On 3/26/2020 9:28 AM, Sean Mullan wrote: >>> Cross-posting to security-dev as this involves TLS/SSL configuration. >>> --Sean >>> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote: >>>> Hello, >>>> >>>> Request to have my fix reviewed for issues: >>>> >>>> JDK-8239595 : ssl context version is not respected >>>> JDK-8239594 : jdk.tls.client.protocols is not respected >>>> >>>> The fix updates jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx) >>>> to use ctx.getDefaultSSLParameters()instead of ctx.getSupportedSSLParameters(), >>>> as the latter does not respect the context parameters set by the user. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/ >>>> >>>> -- Rahul > From chris.hegarty at oracle.com Fri Mar 27 17:36:46 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 27 Mar 2020 17:36:46 +0000 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com> References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com> Message-ID: Thank you Xuelei, this very helpful. Sorry, but I am going to ask just a few more clarifying questions to make sure that we?re on the same page. > On 27 Mar 2020, at 16:23, Xuelei Fan wrote: > > On 3/27/2020 5:52 AM, Chris Hegarty wrote: >> Xuelei, >> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. >> Is there a specification or other documentation describing `jdk.tls.client.protocols` ? > See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides: > > "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9 > > For your quick reference, I copied the note here: > > --------------- > Customized Item: > Default handshaking protocols for TLS/DTLS clients. > > Notes: > To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client ?supported? here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right? getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right? The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols() only getDefaultSSLParameters().getProtocols(), right? In which case, getDefaultSSLParameters().getProtocols() returns the value of `jdk.tls.client.protocols`. > For example, > > If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled > > If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled > --------------- Seems that the term ?client? here is referring to client-initiated exchanges, rather than any specific technology. The assumption, which is reasonable, is that ?clients? will use the default context. Again, this is reasonable default out-of-the-box behavior. >> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`, > It is correct that the property impact the default SSLContext only. The default SSLContext instance could get from: > SSLContext.getInstance("Default"); > SSLContext.getInstance("TLS"); > SSLContext.getInstance("DTLS?); Thanks for this clarification. > >> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do? > Yes. Thanks, -Chris. From xuelei.fan at oracle.com Fri Mar 27 17:47:37 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 27 Mar 2020 10:47:37 -0700 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com> Message-ID: On 3/27/2020 10:36 AM, Chris Hegarty wrote: > Thank you Xuelei, this very helpful. > > Sorry, but I am going to ask just a few more clarifying questions to make sure that we?re on the same page. > >> On 27 Mar 2020, at 16:23, Xuelei Fan wrote: >> >> On 3/27/2020 5:52 AM, Chris Hegarty wrote: >>> Xuelei, >>> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. >>> Is there a specification or other documentation describing `jdk.tls.client.protocols` ? >> See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides: >> >> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9 >> >> For your quick reference, I copied the note here: >> >> --------------- >> Customized Item: >> Default handshaking protocols for TLS/DTLS clients. >> >> Notes: >> To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client > > ?supported? here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right? > Yes. > getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right? > Yes. > The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols() only getDefaultSSLParameters().getProtocols(), right? Yes. > In which case, getDefaultSSLParameters().getProtocols() returns the value of `jdk.tls.client.protocols`. > >> For example, >> >> If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled >> >> If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled >> --------------- > > Seems that the term ?client? here is referring to client-initiated exchanges, rather than any specific technology. > > The assumption, which is reasonable, is that ?clients? will use the default context. Again, this is reasonable default out-of-the-box behavior. > The client refer to the client side SSLSocket or SSLEngine created with the default SSLContext. or example: SSLContext sslContext = SSLContext.getInstance("TLS"); SSLEngine sslEngine = sslContext.createSSLEngine(); sslEngine.setUseClientMode(true); The sslEngine object is a client that impacted by the property. While if sslEngine.setUseClientMode(false); then the object should not be impacted by the property. Xuelei >>> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`, >> It is correct that the property impact the default SSLContext only. The default SSLContext instance could get from: >> SSLContext.getInstance("Default"); >> SSLContext.getInstance("TLS"); >> SSLContext.getInstance("DTLS?); > > Thanks for this clarification. > >> >>> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do? >> Yes. > > Thanks, > -Chris. > > > From chris.hegarty at oracle.com Fri Mar 27 17:50:38 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 27 Mar 2020 17:50:38 +0000 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com> Message-ID: Thank you for these clarifications. We will now consider how these affect, if at all, the HTTP Client. -Chris. > On 27 Mar 2020, at 17:47, Xuelei Fan wrote: > > On 3/27/2020 10:36 AM, Chris Hegarty wrote: >> Thank you Xuelei, this very helpful. >> Sorry, but I am going to ask just a few more clarifying questions to make sure that we?re on the same page. >>> On 27 Mar 2020, at 16:23, Xuelei Fan wrote: >>> >>> On 3/27/2020 5:52 AM, Chris Hegarty wrote: >>>> Xuelei, >>>> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. >>>> Is there a specification or other documentation describing `jdk.tls.client.protocols` ? >>> See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides: >>> >>> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9 >>> >>> For your quick reference, I copied the note here: >>> >>> --------------- >>> Customized Item: >>> Default handshaking protocols for TLS/DTLS clients. >>> >>> Notes: >>> To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client >> ?supported? here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right? > Yes. > >> getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right? > Yes. > >> The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols() only getDefaultSSLParameters().getProtocols(), right? > Yes. > >> In which case, getDefaultSSLParameters().getProtocols() returns the value of `jdk.tls.client.protocols`. >>> For example, >>> >>> If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled >>> >>> If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled >>> --------------- >> Seems that the term ?client? here is referring to client-initiated exchanges, rather than any specific technology. >> The assumption, which is reasonable, is that ?clients? will use the default context. Again, this is reasonable default out-of-the-box behavior. > The client refer to the client side SSLSocket or SSLEngine created with the default SSLContext. or example: > SSLContext sslContext = SSLContext.getInstance("TLS"); > SSLEngine sslEngine = sslContext.createSSLEngine(); > sslEngine.setUseClientMode(true); > > The sslEngine object is a client that impacted by the property. > > While if > sslEngine.setUseClientMode(false); > > then the object should not be impacted by the property. > > Xuelei > >>>> It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`, >>> It is correct that the property impact the default SSLContext only. The default SSLContext instance could get from: >>> SSLContext.getInstance("Default"); >>> SSLContext.getInstance("TLS"); >>> SSLContext.getInstance("DTLS?); >> Thanks for this clarification. >>> >>>> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do? >>> Yes. >> Thanks, >> -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Sun Mar 29 00:12:11 2020 From: mbalao at redhat.com (Martin Balao) Date: Sat, 28 Mar 2020 21:12:11 -0300 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD Message-ID: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> Hi Max, I'd like to propose a fix for 8239385 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8239385/8239385.webrev.00/ The goal behind these changes is to align the Kerberos client default 'canonicalize' behavior to the MIT's one -an analysis of the latter is available at the end of this email for reference-. There are a couple of reasons for that: 1) many applications are not ready to deal with cname changes in their authorization schemes, so the previous default behavior may be too disruptive; and, 2) old KDCs -such as Windows AD 2008- may change the cname when 'canonicalize' is sent from the client but do not include a ENC-PA-REP flag (nor the associated data structure) in the response. Note: cname changes without proper authentication should not be allowed. This change set us apart from a strict interpretation of the RFC 6806 [2], but will enhance compatibility and should not pose a security risk. Changes per file: * src/java.security.jgss/share/classes/sun/security/krb5/Config.java * When a krb5 configuration refresh happens, we need to update the cached 'canonicalize' value stored in ReferralsState class. Same pattern than for other krb5 configurations. * src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java * Read and cache-store of krb5 'canonicalize' configuration value. * 'canonicalize' flag will be sent in AS-REQs only if set to true in the krb5 configuration. false by default. * AS referrals allowed only if 'canonicalize' was sent or an NT-ENTERPRISE cname was used * Usage of NT-ENTERPRISE implies 'canonicalize' (despite the actual flag may not be set). This mimics the MIT client behavior. * Note: OpenJDK will bring APIs for using NT-ENTERPRISE clients on a separate enhancement. * If there is an unexpected KDC failure, the number of max referrals has not been exceeded and 'canonicalize' was set, retry without it. Given that we are not tightening 'canonicalize' to NT-ENTERPRISE (as we would do in a strict interpretation of RFC 6806), we no longer need to check that the cname type is different than NT-ENTERPRISE to retry. * Improved debug output and comments * src/java.security.jgss/share/classes/sun/security/krb5/KrbKdcRep.java * When checking the AS-REP, the usage of an NT-ENTERPRISE cname is considered equal to sending 'canonicalize' (same as in KrbAsReqBuilder.java). * When checking ENC-PA-REP in line 141, 'canonicalize' is not relevant: whether or not ENC-PA-REP is required in the KDC response has been already checked before. In fact, 'canonicalize' may be not sent but we require a ENC-PA-REP in the AS-REP because an NT-ENTERPRISE cname was used and the cname was changed by the KDC. * Note: from a client side, sending an NT-ENTERPRISE cname means that the cname can change in the response. Windows AD 2016, however, does not change it unless 'canonicalize' flag is explicitly set in the request. * Improved comments * test/jdk/sun/security/krb5/auto/ReferralsTest.java * Test for the use-case in which 'canonicalize' is not set, and a referral must fail. Contributed by Max (@weijun), with enhanced comments and cleanup function. Testing: * No regressions observed in jdk/sun/security/krb5 * ReferralsTest extended to cover the new use case * No regressions found in my internal Windows AD 2016 environment In parallel to this RFR, I'll initiate a CSR process to introduce the "canonicalize" krb5 configuration (whose default value is 'false'). Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8239385 [2] - https://tools.ietf.org/html/rfc6806 -- MIT Kerberos client analysis AS-REQs analysis ........................................ When requesting a TGT (through the AS protocol), CANONICALIZE flag is set in the AS-REQ only if 'canonicalize' parameter or configuration options are set [2] (false is the default value). When receiving a KDC_ERR_WRONG_REALM referral response from a KDC, the referral will be followed only if CANONICALIZE was set in the corresponding AS-REQ or if the cname principal was of NT-ENTERPRISE type [3] [4]. When analyzing the final AS-REP (after all referrals), there is a check to enforce that either CANONICALIZE was set in the AS-REQ or the client is a NT-ENTERPRISE principal (among other checks) [5]. kinit's documentation states that -E (for NT-ENTERPRISE principals) implies CANONICALIZE. "Implies" does not mean that the CANONICALIZE flag is set; only that referrals will be followed and cname changes are accepted as if CANONICALIZE were set. In my observations, the Windows 2016 AD does not change the cname unless CANONICALIZE flag is explicitly set in the AS-REQ. In conclusion, referrals are followed only if 'canonicalize' is set or if the cname is an NT-ENTERPRISE principal. Given that OpenJDK does not currently support NT-ENTERPRISE principals in its user interface, the MIT equivalent behavior would be to disable AS-REQ referrals by default (when CANONICALIZE is not set). AP-REQs analysis ........................................ When requesting a TGS, the MIT kvno client tries with referrals first [6] [7]. If there is an error -there are some checks to deal with old Active Directories-, a fallback without referrals is tried [8]. Depending on whether referrals are enabled (STATE_REFERRALS) or not (STATE_NON_REFERRAL), the CANONICALIZE flag may be set in the request here [9]. It's worth noticing that: 1) referrals processing requires to be in STATE_REFERRALS state and that means that CANONICALIZE was set in the AP-REQ; 2) CANONICALIZE value for TGSs does not seem to come from a user-configurable option (as it was for AS-REQs) and is set by default; and 3) there is a fallback mechanism as we already have in OpenJDK. -- [1] - https://github.com/krb5/krb5/tree/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5 [2] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_in_tkt.c#L969 [3] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_in_tkt.c#L1536 [4] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_in_tkt.c#L1587 [5] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_in_tkt.c#L227 [6] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_creds.c#L1072 [7] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_creds.c#L620 [8] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_creds.c#L479 [9] - https://github.com/krb5/krb5/blob/97e3c42b2a89a2ec60eb93d3f974769e3e3cbdc5/src/lib/krb5/krb/get_creds.c#L338 From weijun.wang at oracle.com Sun Mar 29 04:10:47 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 29 Mar 2020 12:10:47 +0800 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> Message-ID: <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> The change looks good to me. > On Mar 29, 2020, at 8:12 AM, Martin Balao wrote: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8239385/8239385.webrev.00/ > ... > * Note: from a client side, sending an NT-ENTERPRISE cname means that > the cname can change in the response. Windows AD 2016, however, does not > change it unless 'canonicalize' flag is explicitly set in the request. Sounds quite reasonable to me. This means "You might find info associated with my other names, but please always call me by my original name". Thanks, Max From ravi.k.reddy at oracle.com Mon Mar 30 11:14:46 2020 From: ravi.k.reddy at oracle.com (Ravi Reddy) Date: Mon, 30 Mar 2020 16:44:46 +0530 Subject: RFR JDK-8240988 : Incorrect copyright header in CertificateValidation.java Message-ID: <11dcf595-f33b-01d7-6680-c016ca6c646b@oracle.com> Hello All, Could you please review this attached patch. This patch fixes the "Incorrect copyright header in CertificateValidation.java". Issue :https://bugs.openjdk.java.net/browse/JDK-8240988 Thanks, Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff --git a/test/jdk/sun/security/x509/X509CertImpl/CertificateValidation.java b/test/jdk/sun/security/x509/X509CertImpl/CertificateValidation.java --- a/test/jdk/sun/security/x509/X509CertImpl/CertificateValidation.java +++ b/test/jdk/sun/security/x509/X509CertImpl/CertificateValidation.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it From sean.coffey at oracle.com Mon Mar 30 11:20:57 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 30 Mar 2020 12:20:57 +0100 Subject: RFR JDK-8240988 : Incorrect copyright header in CertificateValidation.java In-Reply-To: <11dcf595-f33b-01d7-6680-c016ca6c646b@oracle.com> References: <11dcf595-f33b-01d7-6680-c016ca6c646b@oracle.com> Message-ID: <55055a3c-04b5-9acb-178b-e9cb28ef4fb9@oracle.com> Looks fine to me Ravi. regards, Sean. On 30/03/2020 12:14, Ravi Reddy wrote: > Hello All, > > Could you please review this attached patch. This patch fixes the "Incorrect copyright header in CertificateValidation.java". > > > > Issue :https://bugs.openjdk.java.net/browse/JDK-8240988 > > > > Thanks, > Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Mon Mar 30 11:22:53 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 30 Mar 2020 12:22:53 +0100 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side In-Reply-To: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> Message-ID: Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ? regards, Sean. On 27/03/2020 12:48, Norman Maurer wrote: > Hi there, > > I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not. > Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn?t show the same result. > > Does this sounds like a regression and if so should I provide a standalone reproducer here ? > > Bye > Norman > From norman.maurer at googlemail.com Mon Mar 30 12:31:54 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 30 Mar 2020 14:31:54 +0200 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side In-Reply-To: References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> Message-ID: <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> Hey Sean, There is not much to share as its just a simple handshake :) Anyway here is a reproducer: https://github.com/normanmaurer/jdk_ssl_session_context_reproducer It basically does nothing more then complete the handshake and then calling engine.getSession().getSessionContext() which will return null on the server side since JDK 14 (earlier versions work). I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on JDK 14. Bye Norman > On 30. Mar 2020, at 13:22, Se?n Coffey wrote: > > Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ? > > regards, > Sean. > > On 27/03/2020 12:48, Norman Maurer wrote: >> Hi there, >> >> I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not. >> Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn?t show the same result. >> >> Does this sounds like a regression and if so should I provide a standalone reproducer here ? >> >> Bye >> Norman >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 30 13:21:39 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 30 Mar 2020 21:21:39 +0800 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> Message-ID: I was playing with keytool with your patch and noticed sun.security.util.KeyUtil.getKeySize(Key) does not support an EdECKey. While we use curve name instead of key size in EC to describe the parameters, the size is still useful in determining the strength. There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm not involved with previous discussions on EdDSA design, but why does EdDSASignature.engineGetParameters() throw an UOE? Another small problem: You reverted the copyright year from 2020 to an earlier year in module-info.java, keytool/Main.java. Thanks, Max > On Mar 24, 2020, at 2:53 AM, Anthony Scarpino wrote: > > On 2/25/20 12:49 PM, Anthony Scarpino wrote: >> Hi >> I need a code review for the EdDSA support in JEP 339. The code builds on the existing java implemented constant time classes used for XDH and the NIST curves. The change also adds classes to the public API to support EdDSA operations. >> All information about the JEP is located at: >> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 >> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ >> thanks >> Tony > > > I updated the webrev with some minor updates that were commented previously. > > https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ > > Tony From prasadarao.koppula at oracle.com Mon Mar 30 13:50:57 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Mon, 30 Mar 2020 06:50:57 -0700 (PDT) Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role In-Reply-To: <939a2142-60b6-49e8-873f-3f3888293342@default> References: <939a2142-60b6-49e8-873f-3f3888293342@default> Message-ID: <1788edc0-97f3-48cf-8b04-fd6520e1df16@default> Hi, Added @implnote and updated test changes, here is the new webrev, please review it. Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K From: Prasadrao Koppula Sent: Friday, February 7, 2020 5:03 PM To: security-dev at openjdk.java.net Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Mon Mar 30 14:48:06 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 30 Mar 2020 11:48:06 -0300 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> Message-ID: <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com> Hi Max, Thanks for having a look at this. On 3/29/20 1:10 AM, Weijun Wang wrote: >> * Note: from a client side, sending an NT-ENTERPRISE cname means that >> the cname can change in the response. Windows AD 2016, however, does not >> change it unless 'canonicalize' flag is explicitly set in the request. > > Sounds quite reasonable to me. This means "You might find info associated with my other names, but please always call me by my original name". > Yes, correct. In fact, Windows AD seems not to change the cname when an NT-ENTERPRISE cname is sent and 'canonicalize' is false. AS referrals keep working in this case. However, it's more of a suggestion: if any other KDC decides to change an NT-ENTERPRISE cname even when 'canonicalize' was false in the request, we will handle that and move on (this is a bit off RFC 6806 as 'canonicalize' should have been true when sending an NT-ENTERPRISE). That's what we -and the MIT client- mean with "NT-ENTERPRISE" implies 'canonicalize'. Thanks, Martin.- From rahul.r.yadav at oracle.com Mon Mar 30 14:32:03 2020 From: rahul.r.yadav at oracle.com (rahul.r.yadav at oracle.com) Date: Mon, 30 Mar 2020 15:32:03 +0100 Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected In-Reply-To: References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com> <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com> <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com> <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com> <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com> <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com> Message-ID: <4a9ef2b6-f5d1-2b0b-709e-c6a45a22d5be@oracle.com> The current fix does not affect the scenarios discussed earlier(that is a broader discussion,may be a different bug/enhancement). The scenarios would be vaild even if the fix would not have been in place. -Rahul On 27/03/2020 17:50, Chris Hegarty wrote: > Thank you for these clarifications. We will now consider how these > affect, if at all, the HTTP Client. > > -Chris. > >> On 27 Mar 2020, at 17:47, Xuelei Fan > > wrote: >> >> On 3/27/2020 10:36 AM, Chris Hegarty wrote: >>> Thank you Xuelei, this very helpful. >>> Sorry, but I am going to ask just a few more clarifying questions to >>> make sure that we?re on the same page. >>>> On 27 Mar 2020, at 16:23, Xuelei Fan >>> > wrote: >>>> >>>> On 3/27/2020 5:52 AM, Chris Hegarty wrote: >>>>> Xuelei, >>>>> Before commenting further on the interaction of the HTTP Client >>>>> with various contorted configurations, I would like to get a >>>>> better understanding of the `jdk.tls.client.protocols` property. >>>>> Is there a specification or other documentation describing >>>>> `jdk.tls.client.protocols` ? >>>> See the jdk.tls.client.protocols line in table 'Table 8-3 System >>>> Properties and Customized Items" in JSSE Reference Guides: >>>> >>>> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9 >>>> >>>> For your quick reference, I copied the note here: >>>> >>>> --------------- >>>> Customized Item: >>>> Default handshaking protocols for TLS/DTLS clients. >>>> >>>> Notes: >>>> To enable specific SunJSSE protocols on the client, specify them in >>>> a comma-separated list within quotation marks; all other supported >>>> protocols are not enabled on the client >>> ?supported? here means protocols that are supported by the provider, >>> and may be used within a specific context. This translates, for the >>> default SSLContext, to the API call >>> getSupportedSSLParameters().getProtocols(), right? >> Yes. >> >>> getSupportedSSLParameters().getProtocols() returns a superset of >>> getDefaultSSLParameters().getProtocols(). Conversely, >>> getDefaultSSLParameters().getProtocols() is a strict subset of >>> getSupportedSSLParameters().getProtocols(), right? >> Yes. >> >>> The `jdk.tls.client.protocols` property has no affect on >>> getSupportedSSLParameters().getProtocols() ?only >>> getDefaultSSLParameters().getProtocols(), right? >> Yes. >> >>> In which case, getDefaultSSLParameters().getProtocols() returns the >>> value of ?`jdk.tls.client.protocols`. >>>> For example, >>>> >>>> ???If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default >>>> protocol settings on the client for TLSv1 and TLSv1.1 are enabled, >>>> while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled >>>> >>>> ???If jdk.tls.client.protocols="DTLSv1.2" , then the protocol >>>> setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not >>>> enabled >>>> --------------- >>> Seems that the term ?client? here is referring to client-initiated >>> exchanges, rather than any specific technology. >>> The assumption, which is reasonable, is that ?clients? will use the >>> default context. Again, this is reasonable default out-of-the-box >>> behavior. >> The client refer to the client side SSLSocket or SSLEngine created >> with the default SSLContext. ?or example: >> ???SSLContext sslContext = SSLContext.getInstance("TLS"); >> ???SSLEngine sslEngine = sslContext.createSSLEngine(); >> ???sslEngine.setUseClientMode(true); >> >> The sslEngine object is a client that impacted by the property. >> >> While if >> ???sslEngine.setUseClientMode(false); >> >> then the object should not be impacted by the property. >> >> Xuelei >> >>>>> It is my understanding that the property only affects the >>>>> *default* protocol?s ( not the supported protocols ) of the >>>>> *default* context. That is, the context returned by >>>>> `SSLContext.getInstance("Default?)`, >>>> It is correct that the property impact the default SSLContext only. >>>> ?The default SSLContext instance could get from: >>>> ???SSLContext.getInstance("Default"); >>>> ???SSLContext.getInstance("TLS"); >>>> ???SSLContext.getInstance("DTLS?); >>> Thanks for this clarification. >>>> >>>>> and the protocol values returned by the following invocation on >>>>> that context `getDefaultSSLParameters().getProtocols()`. Is this >>>>> correct? If not, what does it do? >>>> Yes. >>> Thanks, >>> -Chris. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Mar 30 15:58:25 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 30 Mar 2020 08:58:25 -0700 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side In-Reply-To: <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> Message-ID: For what it's worth, I tried with the latest JDK using SSLSockets on the server side and I'm (so far) not able to reproduce it with my local test utilities.? Unfortunately I don't have an engine-based simple server handy so I'll give Norman's reproducer a spin and see what happens. --Jamil On 3/30/2020 5:31 AM, Norman Maurer wrote: > Hey Sean, > > There is not much to share as its just a simple handshake :) > > Anyway here is a reproducer: > > https://github.com/normanmaurer/jdk_ssl_session_context_reproducer > > It basically does nothing more then complete the handshake and then > calling engine.getSession().getSessionContext() which will return null > on the server side since JDK 14 (earlier versions work). > I tested it with TLSv1.2 and TLSv1.3 and both times it produced the > error on JDK 14. > > > Bye > Norman > > >> On 30. Mar 2020, at 13:22, Se?n Coffey > > wrote: >> >> Looks interesting Norman. Do you want to share some more details >> about the peculiarities of this handshake before considering a fully >> fledged testcase ? >> >> regards, >> Sean. >> >> On 27/03/2020 12:48, Norman Maurer wrote: >>> Hi there, >>> >>> I am just about to add JDK14 to the test matrix for netty and think >>> I found a regression. Before I will invest time to write a >>> standalone reproducer please let me know if you think this is a >>> regression or not. >>> Basically after the handshake is complete >>> SSLEngine.getSession().getSessionContext() returns null on the >>> serverside when using JDK14. Running the same test with any previous >>> version (JDK13 and earlier) doesn?t show the same result. >>> >>> Does this sounds like a regression and if so should I provide a >>> standalone reproducer here ? >>> >>> Bye >>> Norman >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Mar 30 18:52:11 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 30 Mar 2020 11:52:11 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> Message-ID: <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com> On 3/30/20 6:21 AM, Weijun Wang wrote: > I was playing with keytool with your patch and noticed > sun.security.util.KeyUtil.getKeySize(Key) does not support an > EdECKey. While we use curve name instead of key size in EC to > describe the parameters, the size is still useful in determining the > strength. I think I should be able to access the parameter with the key's NamedParameterSpec to return the size. > > There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm > not involved with previous discussions on EdDSA design, but why does > EdDSASignature.engineGetParameters() throw an UOE? Because the public API for engineGetParameter(String param) is deprecated would be my suspicion. > Another small problem: > > You reverted the copyright year from 2020 to an earlier year in > module-info.java, keytool/Main.java. The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset. > > Thanks, Max > >> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino >> wrote: >> >> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>> Hi I need a code review for the EdDSA support in JEP 339. The >>> code builds on the existing java implemented constant time >>> classes used for XDH and the NIST curves. The change also adds >>> classes to the public API to support EdDSA operations. All >>> information about the JEP is located at: JEP 339: >>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev: >>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks >>> Tony >> >> >> I updated the webrev with some minor updates that were commented >> previously. >> >> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ >> >> Tony > From mbalao at redhat.com Mon Mar 30 20:24:59 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 30 Mar 2020 17:24:59 -0300 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com> References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com> Message-ID: <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com> Hi Max, CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 Look forward to your comments or approval there. Thanks, Martin.- From ivan.gerasimov at oracle.com Mon Mar 30 21:39:49 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 30 Mar 2020 14:39:49 -0700 Subject: [15] RFR 8241761 : Typos: empty lines in javadoc, inconsistent indents, etc. (security-libs only) Message-ID: <590603c4-d9b9-ac16-b0a7-c3be927efbe7@oracle.com> Hello! The fix follows up on JDK-8241727 [1]. This is a javadoc/comments only fix in the security-libs area. The changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony. Would you please help review this rather technical fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241761 WEBREV: http://cr.openjdk.java.net/~igerasim/8241761/00/webrev/ Thank in advance! [1] https://bugs.openjdk.java.net/browse/JDK-8241727 -- With kind regards, Ivan Gerasimov From jamil.j.nimeh at oracle.com Mon Mar 30 23:50:27 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 30 Mar 2020 16:50:27 -0700 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side In-Reply-To: <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> Message-ID: Hi Norman, I've been able to run your test code and I can reproduce it. Interestingly enough, it appears to happen when -Djdk.tls.server.enableSessionTicketExtension=true, which is the default position.? With session tickets enabled, I would see the issue in TLS 1.3 and 1.2 connections just as you did.? Setting the above property to false however allowed me to make successful connections.? Would you mind setting that property to false, just to make sure you and I see the same thing? I did go back and run SSLServerSocket-based connections just to see if the session ticket settings had any impact on things, but they don't.? I can make connections to a socket based SSL server regardless of the property value on the server side. Thanks, --Jamil On 3/30/2020 5:31 AM, Norman Maurer wrote: > Hey Sean, > > There is not much to share as its just a simple handshake :) > > Anyway here is a reproducer: > > https://github.com/normanmaurer/jdk_ssl_session_context_reproducer > > It basically does nothing more then complete the handshake and then > calling engine.getSession().getSessionContext() which will return null > on the server side since JDK 14 (earlier versions work). > I tested it with TLSv1.2 and TLSv1.3 and both times it produced the > error on JDK 14. > > > Bye > Norman > > >> On 30. Mar 2020, at 13:22, Se?n Coffey > > wrote: >> >> Looks interesting Norman. Do you want to share some more details >> about the peculiarities of this handshake before considering a fully >> fledged testcase ? >> >> regards, >> Sean. >> >> On 27/03/2020 12:48, Norman Maurer wrote: >>> Hi there, >>> >>> I am just about to add JDK14 to the test matrix for netty and think >>> I found a regression. Before I will invest time to write a >>> standalone reproducer please let me know if you think this is a >>> regression or not. >>> Basically after the handshake is complete >>> SSLEngine.getSession().getSessionContext() returns null on the >>> serverside when using JDK14. Running the same test with any previous >>> version (JDK13 and earlier) doesn?t show the same result. >>> >>> Does this sounds like a regression and if so should I provide a >>> standalone reproducer here ? >>> >>> Bye >>> Norman >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Mon Mar 30 23:58:01 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 30 Mar 2020 20:58:01 -0300 Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one Message-ID: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com> Hi, I'd like to request a review for 8241888 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.00/ CSR (waiting for review): https://bugs.openjdk.java.net/browse/JDK-8241893 I've not included my regression test as it's a trivial change and my test is actually testing SecurityProperties -which has already been tested-. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8241888 From weijun.wang at oracle.com Tue Mar 31 02:39:24 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 31 Mar 2020 10:39:24 +0800 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com> References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com> <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com> Message-ID: <42935589-9E1B-4E2A-BD45-EFCD7C0127C3@oracle.com> 1. I don't think there is a need to talk about the java.security.krb5.conf system property, the krb5.conf file name is more popular. 2. I'd rather always say "TGS requests" instead of "AP requests". Thanks, Max > On Mar 31, 2020, at 4:24 AM, Martin Balao wrote: > > Hi Max, > > CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 > > Look forward to your comments or approval there. > > Thanks, > Martin.- > From anthony.scarpino at oracle.com Tue Mar 31 02:50:23 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 30 Mar 2020 19:50:23 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com> Message-ID: <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com> On 3/30/20 11:52 AM, Anthony Scarpino wrote: > > On 3/30/20 6:21 AM, Weijun Wang wrote: >> I was playing with keytool with your patch and noticed >> sun.security.util.KeyUtil.getKeySize(Key) does not support an >> EdECKey. While we use curve name instead of key size in EC to >> describe the parameters, the size is still useful in determining the >> strength. > > I think I should be able to access the parameter with the key's > NamedParameterSpec to return the size. I was wrong about this. The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class. The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc. Tony > >> >> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm >> not involved with previous discussions on EdDSA design, but why does >> EdDSASignature.engineGetParameters() throw an UOE? > > Because the public API for engineGetParameter(String param) is > deprecated would be my suspicion. > >> Another small problem: >> >> You reverted the copyright year from 2020 to an earlier year in >> module-info.java, keytool/Main.java. > > The copyright has not been reverted, the jdk repo was updated to 2020 > from another changeset. > >> >> Thanks, Max >> >>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino >>> wrote: >>> >>> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>>> Hi I need a code review for the EdDSA support in JEP 339.? The >>>> code builds on the existing java implemented constant time >>>> classes used for XDH and the NIST curves.? The change also adds >>>> classes to the public API to support EdDSA operations. All >>>> information about the JEP is located at: JEP 339: >>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev: >>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony >>> >>> >>> I updated the webrev with some minor updates that were commented >>> previously. >>> >>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ >>> >>> Tony >> > From weijun.wang at oracle.com Tue Mar 31 02:54:18 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 31 Mar 2020 10:54:18 +0800 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com> <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com> Message-ID: <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com> > On Mar 31, 2020, at 10:50 AM, Anthony Scarpino wrote: > > On 3/30/20 11:52 AM, Anthony Scarpino wrote: >> On 3/30/20 6:21 AM, Weijun Wang wrote: >>> I was playing with keytool with your patch and noticed >>> sun.security.util.KeyUtil.getKeySize(Key) does not support an >>> EdECKey. While we use curve name instead of key size in EC to >>> describe the parameters, the size is still useful in determining the >>> strength. >> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size. > > I was wrong about this. The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class. > > The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc. Yes. > > Tony > >>> >>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm >>> not involved with previous discussions on EdDSA design, but why does >>> EdDSASignature.engineGetParameters() throw an UOE? >> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion. engineGetParameter() is deprecated, engineGetParameters() is not. >>> Another small problem: >>> >>> You reverted the copyright year from 2020 to an earlier year in >>> module-info.java, keytool/Main.java. >> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset. Ah yes, I applied your patch to my old repo. --Max >>> >>> Thanks, Max >>> >>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino >>>> wrote: >>>> >>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>>>> Hi I need a code review for the EdDSA support in JEP 339. The >>>>> code builds on the existing java implemented constant time >>>>> classes used for XDH and the NIST curves. The change also adds >>>>> classes to the public API to support EdDSA operations. All >>>>> information about the JEP is located at: JEP 339: >>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev: >>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony >>>> >>>> >>>> I updated the webrev with some minor updates that were commented >>>> previously. >>>> >>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ >>>> >>>> Tony >>> > From valerie.peng at oracle.com Tue Mar 31 03:25:23 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Mar 2020 20:25:23 -0700 Subject: RFR: 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: <06fc3f21-225f-7262-fea3-29a6d803b328@oracle.com> References: <06fc3f21-225f-7262-fea3-29a6d803b328@oracle.com> Message-ID: <15e3ec7a-b85b-dd36-2bc3-d86dcee57b2d@oracle.com> Hi Jamil, Thanks for being so patient. It take me sometime to play around with the changes and think about various scenarios... Here are some comments: - Line 38 has RFC 2268 which is for RC2, RC5 is in RFC 2040. - Line 48-51 comments can be simplified further, essentially, IV (provided or not) shall have the same length as the block size. If not provided explicitly, then its values are all 0s. Just some nit. - line 187: variable name 'pbeSpec' should probably be named as 'rc5Spec' as it has nothing to do with PBE. - The test is very extensive... May I ask how are the test vectors generated? Are they from some RFCs or external website like NIST or internally generated using these new impl? In particular, I wonder about the test "HmacSHA256 and AES-256-CBC [No Enc parameters]", this is expected to pass, but AES CBC requires IV and if no parameters are explicitly specified, how do things work for decryption where IV is required and cannot generate random values as default IV? I am also not sure about the InitByDERAndEncodeTest, I think we should not alter the given encoding based on our own assumptions/defaults. If given a DER encoding bytes, the same (minor difference such as an absent null params is ok) encoding should be returned when getEncoded() is called. - Line 143 expVals[4] should be expVals[3]? - Current changes are a bit too complicated and I am not sure if it's worthwhile to support RC2, RC5, DESede and DES and do their algorithm-specific checking. PBES2 AlgorithmParameters parsing is already complicated due we support the original name (PBES2) and also the "friendly"? JCA naming convention of including the cipher name and KDF name. On top of it, the current webrev seem to trying to support parsing of all possible algorithms stated in PKCS#5 even when SunJCE provider only support the AES_xxx variants. If only parsing is done, the overhead may be acceptable, but then when there is also algorithm specific checking, I feel this is a bit much as I doubt that they will ever be used. - There are a lot of String parsing inside the String-arg constructor which can be avoided if we replace this String-arg constructor with a 2-arg constructor with PrfType and EncType. This should simplify the constructor code greatly and make it more robust. Then we probably can remove the getByName() method for both enum types. No need for the constructor to throw NoSuchAlgorithmException as all inputs are provided by provider and unsupported algorithm should be detected before calling this constructor. - Line 259, add "," after the word "key"? - The ordering of things under engineInit(AlgorithmParameterSpec paramSpec) seems a bit un-intuitive. User-supplied values should only be stored after pass validation. The assignment (line 324-326) should be done after the various checks. The check at line 338 should be moved up before assigning the default kdf type. - Missing PBE subclasses for AES_192? - Some of the static oid constants seems unnecessary as they are only used inside the enum and can be moved there. - By convention, each init() is a fresh start and wipes out the effect previous init() calls. But in the current webrev, they seems to apply changes on top of each other. This may not be the right model of how things should be handled. In addition, with the existing code handles both PBES2 and PBEwithAnd, we may need extra logic to restore the fields back to when they are first constructed at the beginning of every engineInit(...). - I am not too sure about the usefulness of "pbes2AlgorithmName" field. In the current impl, it is set in various places. If it is meant to reflect the latest KDF and CIPHER algorithm used, it's more robust to construct its value when needed. Otherwise, we need to remember updating this value whenever one of these 3 values, i.e. KDF, CIPHER, and keysize, changed. - Consider grouping the fields of salt, iteration count, keysize, prfType into separate class and move the PBKDF2 parsing/encoding code there. This simplifies the validation and setting of these 4 fields. - Avoid algorithm-specific checking in this class as it is not scalable and duplicates the checking in the algorithm-specific classes. If you feel they must be done, delegate to the algorithm-specific classes as much as possible. Instead of explicitly checking the parameter spec, use the sequence of AlgorithmParameters.getInstance(String), and its init(...) call and see if the call passes. - There are also code which sets the keysize for RC2 and RC5 key sizes based on the PBKDF2 and cipher parameters. I think it's reasonable to derive the value from the PBKDF2 params, but not cipher parameters. In the case of RC5, it even assigns a default value (line 760) when all else is failed. Given the purpose of this class is for PBES2 algorithm parameters and we don't support PBES2 cipher with RC2 or RC5, I think we should not go this far. Is there anything that I missed for requiring to set the keysize in this class? If "PBES2" AlgorithmParameters are requested and initialized with DER encoding, we should return the same encoding (unless it's mistakenly encoded as stated in line )? when getEncoded() is called. It's also somewhat strange that the toString() method returns only the "friendly" expanded name without other info. This is different from other AlgorithmParameters impl. But this is just nit comparing to other things. I adapted your changes with most of my feedback above (except the one on each engineInit() call being independent) and you can find the changes here: http://cr.openjdk.java.net/~valeriep/pbes2Exp/webrev/ (The regression test PBES2ParametersTest.java has to be updated a little in order to pass). Hope this can help you understand my comments. Thanks! Valerie On 3/18/2020 3:59 PM, Valerie Peng wrote: > > > Right, I recall reviewing this and made some comments. Will take a > look at the updated webrev. > > Thanks, > Valerie > On 3/17/2020 4:48 PM, Jamil Nimeh wrote: >> >> Hello all, >> >> I'm finally getting back around to this after dusting off the cobwebs. >> >> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.03 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >> >> Valerie, you had some comments from way back (7/9/2019). Just a short >> summary of what's been done to address them: >> >> * Removed unused imports >> * Added a default "PBES2" string value for when the toString method >> is called on a PBES2Parameters object before the init() method. >> * Tested encoding of PBKDF2 parameters AlgorithmIdentifiers with >> the optional parameters field not present (as opposed to an ASN.1 >> NULL).? OpenSSL seems happy with it so that's how we'll encode those. >> * Switched order on the IV and keysize parsing for RC2 parameters >> * Using KEYLEN_ANY (changed to KEYLEN_UNSPEC) now in lieu of -1 in >> the conditionals you cited. >> * For algorithms where the key length is implicit either due to the >> algorithm or the specific OID, we no longer assert the key length >> in the KDF parameters.? This is consistent with other >> implementations such as OpenSSL. >> * Regarding the comment from the parsing in engineInit(byte[]) >> >> "By calling data.getDerValue(), we are essentially peeling one layer >> off, right? If you still agree with me at this point, then note that >> pBES2_params is a local variable and its value should be the same >> unless explicitly re-assigned (as on line 413). Thus, per my reading >> of the code, the tag that you are checking on line 419 is not the one >> for encryption scheme, but rather the outer sequence tag >> encapsulating kdf and encryption scheme. Its current location is very >> misleading though, in between kdf and encryption scheme. To really >> check the tag for kdf and encryption scheme, the tag checking should >> be in parseKDF(...) and parseES(...) against the DerValue argument." >> >> I did add a DerValue check in parseKDF because it is appropriate as >> you stated.? I also removed the check from line 419 in the old >> webrev.? With the new code that check is redundant as we are using >> AlgorithmId.parse() now as the initial operation in parseES, which in >> turn does the sequence tag check for us. >> >> The check itself on 419 though is testing the ASN.1 tag for the >> Encryption scheme, not the higher level sequence for PBES2-params.? >> Otherwise neither the KDF nor the encryption scheme would parse >> properly and none of the tests would pass. >> >> With this new code, parseKDF and parseES are testing the outer >> SEQUENCE tags for each of the AlgorithmIdentifier objects described >> by keyDerivationFunc and encryptionScheme per RFC 8018. >> >> * keysize setting: This one is a bit tricky because key size is >> specified in multiple ways.? The basic flow is this.? Key size >> will start as KEYLEN_UNSPEC.? If it is at any point specified, >> either via the constructor, by KDF params, or by enc params then >> that is the value that is set.? At near the end of parsing a >> validation of the encryption parameters occurs and at that point >> the key length is checked against the algorithm.? If it is an alg >> that uses a fixed value then keysize has to be consistent with >> it.? If it is variable length and it is still KEYSIZE_UNSPEC that >> is also a failure (since something needs to be specified to >> distinguish RC2_40 from RC2_128, for example). >> o This approach seems to work and catches the issue you found >> where certain DER encodings could yield things like >> PBEWithHmacSHA256AndRC5_-1. >> * Added some new tests to handle the changes listed above. >> >> I'll be updating the CSR shortly to reflect comments there and I'll >> send a separate review notice for that. >> >> Thanks, >> >> --Jamil >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Mar 31 03:52:26 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 30 Mar 2020 20:52:26 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com> <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com> <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com> Message-ID: <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com> On 3/30/20 7:54 PM, Weijun Wang wrote: > > >> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino wrote: >> >> On 3/30/20 11:52 AM, Anthony Scarpino wrote: >>> On 3/30/20 6:21 AM, Weijun Wang wrote: >>>> I was playing with keytool with your patch and noticed >>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an >>>> EdECKey. While we use curve name instead of key size in EC to >>>> describe the parameters, the size is still useful in determining the >>>> strength. >>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size. >> >> I was wrong about this. The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class. >> >> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc. > > Yes. > >> >> Tony >> >>>> >>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm >>>> not involved with previous discussions on EdDSA design, but why does >>>> EdDSASignature.engineGetParameters() throw an UOE? >>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion. > > engineGetParameter() is deprecated, engineGetParameters() is not. Oh sorry. I'm not sure why, but I have to ask the question what is the point of this method? If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set? Are the parameters returned changed from the initial setting? In the EdDSA case they are not. I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this. Tony > >>>> Another small problem: >>>> >>>> You reverted the copyright year from 2020 to an earlier year in >>>> module-info.java, keytool/Main.java. >>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset. > > Ah yes, I applied your patch to my old repo. > > --Max > >>>> >>>> Thanks, Max >>>> >>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino >>>>> wrote: >>>>> >>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>>>>> Hi I need a code review for the EdDSA support in JEP 339. The >>>>>> code builds on the existing java implemented constant time >>>>>> classes used for XDH and the NIST curves. The change also adds >>>>>> classes to the public API to support EdDSA operations. All >>>>>> information about the JEP is located at: JEP 339: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev: >>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony >>>>> >>>>> >>>>> I updated the webrev with some minor updates that were commented >>>>> previously. >>>>> >>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ >>>>> >>>>> Tony >>>> >> > From anthony.scarpino at oracle.com Tue Mar 31 04:25:18 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 30 Mar 2020 21:25:18 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com> <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com> <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com> <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com> Message-ID: <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com> On 3/30/20 8:52 PM, Anthony Scarpino wrote: > On 3/30/20 7:54 PM, Weijun Wang wrote: >> >> >>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino >>> wrote: >>> >>> On 3/30/20 11:52 AM, Anthony Scarpino wrote: >>>> On 3/30/20 6:21 AM, Weijun Wang wrote: >>>>> I was playing with keytool with your patch and noticed >>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an >>>>> EdECKey. While we use curve name instead of key size in EC to >>>>> describe the parameters, the size is still useful in determining the >>>>> strength. >>>> I think I should be able to access the parameter with the key's >>>> NamedParameterSpec to return the size. >>> >>> I was wrong about this.? The parameters are part of jdk.crypto.ec >>> while KeyUtil is part of java.base, so I cannot access the internal >>> EdDSAParameters class. >>> >>> The easiest way would be to look at the NamedParameterSpec and return >>> a hardcoded length based on the curve used. It's not ideal, but all >>> these curves don't change lengths unlike for RSA, AES, etc. >> >> Yes. >> >>> >>> Tony >>> >>>>> >>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm >>>>> not involved with previous discussions on EdDSA design, but why does >>>>> EdDSASignature.engineGetParameters() throw an UOE? >>>> Because the public API for engineGetParameter(String param) is >>>> deprecated would be my suspicion. >> >> engineGetParameter() is deprecated, engineGetParameters() is not. > > Oh sorry.? I'm not sure why, but I have to ask the question what is the > point of this method?? If the user needs to set the parameters to do the > a signature of verify, what is the need for a method that gets the > parameter from Signature that should have just set?? Are the parameters > returned changed from the initial setting?? In the EdDSA case they are not. > > I don't have an immediate problem in having EdDSA return the same > parameters back, I'm just not sure why it's necessary and I haven't see > anything in the JEP as to why Adam decided against this. > > Tony Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter. That confused me. So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly. The NamedParameterSpec tells the internals of EdDSA what parameters to use. I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves. Tony > >> >>>>> Another small problem: >>>>> >>>>> You reverted the copyright year from 2020 to an earlier year in >>>>> module-info.java, keytool/Main.java. >>>> The copyright has not been reverted, the jdk repo was updated to >>>> 2020 from another changeset. >> >> Ah yes, I applied your patch to my old repo. >> >> --Max >> >>>>> >>>>> Thanks, Max >>>>> >>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino >>>>>> wrote: >>>>>> >>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>>>>>> Hi I need a code review for the EdDSA support in JEP 339.? The >>>>>>> code builds on the existing java implemented constant time >>>>>>> classes used for XDH and the NIST curves.? The change also adds >>>>>>> classes to the public API to support EdDSA operations. All >>>>>>> information about the JEP is located at: JEP 339: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev: >>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony >>>>>> >>>>>> >>>>>> I updated the webrev with some minor updates that were commented >>>>>> previously. >>>>>> >>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ >>>>>> >>>>>> Tony >>>>> >>> >> > From norman.maurer at googlemail.com Tue Mar 31 14:11:02 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 31 Mar 2020 16:11:02 +0200 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side In-Reply-To: References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> Message-ID: Yes thats about right? if setting to false it works as expected. Bye Norman > On 31. Mar 2020, at 01:50, Jamil Nimeh wrote: > > Hi Norman, > > I've been able to run your test code and I can reproduce it. Interestingly enough, it appears to happen when -Djdk.tls.server.enableSessionTicketExtension=true, which is the default position. With session tickets enabled, I would see the issue in TLS 1.3 and 1.2 connections just as you did. Setting the above property to false however allowed me to make successful connections. Would you mind setting that property to false, just to make sure you and I see the same thing? > > I did go back and run SSLServerSocket-based connections just to see if the session ticket settings had any impact on things, but they don't. I can make connections to a socket based SSL server regardless of the property value on the server side. > > Thanks, > > --Jamil > > On 3/30/2020 5:31 AM, Norman Maurer wrote: >> Hey Sean, >> >> There is not much to share as its just a simple handshake :) >> >> Anyway here is a reproducer: >> >> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer >> >> It basically does nothing more then complete the handshake and then calling engine.getSession().getSessionContext() which will return null on the server side since JDK 14 (earlier versions work). >> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on JDK 14. >> >> >> Bye >> Norman >> >> >>> On 30. Mar 2020, at 13:22, Se?n Coffey > wrote: >>> >>> Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ? >>> >>> regards, >>> Sean. >>> >>> On 27/03/2020 12:48, Norman Maurer wrote: >>>> Hi there, >>>> >>>> I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not. >>>> Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn?t show the same result. >>>> >>>> Does this sounds like a regression and if so should I provide a standalone reproducer here ? >>>> >>>> Bye >>>> Norman >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Mar 31 15:35:53 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 31 Mar 2020 08:35:53 -0700 Subject: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side In-Reply-To: References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com> <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com> Message-ID: Thanks Norman, I'm going to file a bug on this one.? After playing with it a bit more I found cases where even SSLServerSockets do run into the issue but it doesn't always happen.? Still working on characterizing it. --Jamil On 3/31/2020 7:11 AM, Norman Maurer wrote: > Yes thats about right? if setting to false it works as expected. > > > Bye > Norman > > >> On 31. Mar 2020, at 01:50, Jamil Nimeh > > wrote: >> >> Hi Norman, >> >> I've been able to run your test code and I can reproduce it.? >> Interestingly enough, it appears to happen when >> -Djdk.tls.server.enableSessionTicketExtension=true, which is the >> default position.? With session tickets enabled, I would see the >> issue in TLS 1.3 and 1.2 connections just as you did.? Setting the >> above property to false however allowed me to make successful >> connections.? Would you mind setting that property to false, just to >> make sure you and I see the same thing? >> >> I did go back and run SSLServerSocket-based connections just to see >> if the session ticket settings had any impact on things, but they >> don't.? I can make connections to a socket based SSL server >> regardless of the property value on the server side. >> >> Thanks, >> >> --Jamil >> >> On 3/30/2020 5:31 AM, Norman Maurer wrote: >>> Hey Sean, >>> >>> There is not much to share as its just a simple handshake :) >>> >>> Anyway here is a reproducer: >>> >>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer >>> >>> It basically does nothing more then complete the handshake and then >>> calling engine.getSession().getSessionContext() which will return >>> null on the server side since JDK 14 (earlier versions work). >>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the >>> error on JDK 14. >>> >>> >>> Bye >>> Norman >>> >>> >>>> On 30. Mar 2020, at 13:22, Se?n Coffey >>> > wrote: >>>> >>>> Looks interesting Norman. Do you want to share some more details >>>> about the peculiarities of this handshake before considering a >>>> fully fledged testcase ? >>>> >>>> regards, >>>> Sean. >>>> >>>> On 27/03/2020 12:48, Norman Maurer wrote: >>>>> Hi there, >>>>> >>>>> I am just about to add JDK14 to the test matrix for netty and >>>>> think I found a regression. Before I will invest time to write a >>>>> standalone reproducer please let me know if you think this is a >>>>> regression or not. >>>>> Basically after the handshake is complete >>>>> SSLEngine.getSession().getSessionContext() returns null on the >>>>> serverside when using JDK14. Running the same test with any >>>>> previous version (JDK13 and earlier) doesn?t show the same result. >>>>> >>>>> Does this sounds like a regression and if so should I provide a >>>>> standalone reproducer here ? >>>>> >>>>> Bye >>>>> Norman >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Tue Mar 31 17:15:51 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 31 Mar 2020 13:15:51 -0400 Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms In-Reply-To: <44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com> References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com> <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net> <44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com> Message-ID: <492f53ff-8f79-2a16-20a4-445b655f94a1@comcast.net> Sorry - this one got past me. For PKCS11 - the assignment of mechanism numbers can happen at any time and doesn't necessarily result in a new version of the specification.? In this case, the API won't change, so there's no reason - since the mechanism numbers have been assigned since last May at least - to wait for V3.? Among other things, I would expect that various vendors have already implemented these in their 2.xx implementations. One of the reasons I ended up using the SunPKCS11 wrapper classes directly quite a while ago was that the PKCS11 spec hadn't been updated, but that my PKCS11 provider was supplying various EC mechanisms that I needed.?? Ideally, the JCA and SunPKCS11 provider support should *precede* any given underlying PKCS11 device support, not trail it by 6-12 months. The assignment of mechanism numbers is exactly equivalent to the assignment of TLS cipher suite numbers - the underlying protocol doesn't change, so this is mostly a change to the mapping tables and enclosed classes. In any event, any given PKCS11 implementation may or may not support any given set of mechanisms - the provider really ought to be calling C_GetMechanismList() and using that as the list of supported JNA mechanisms. Sorry - I'm dealing with a bit of lack of sleep here so I may be babbling, but I'm wondering if it might not be a bad idea to add some sort of PKCS11 specific mechanism naming convention to allow for the lag/lead problem??? E.g PKCS11_DIGEST_000002B0 would be PKCS11's CKM_SHA3_256 hashing function given > #define CKM_SHA3_2560x000002B0 > Just a thought. Thanks - Mike On 3/19/2020 5:27 PM, Valerie Peng wrote: > Hi Mike, > > Thanks for heads up. From what I can gather, SHA3 inclusion is part of > PKCS#11 v3. Is this the next release which you are referring to? Or > will there be an update to v2.40? Is there any schedule info for these > update/release do you know? > > Following the convention, we normally don't add something which the > underlying library has no support yet. With the new 6-month JDK > release cycle, it's much faster for the added functionality to be > available. So, I'd still prefer to update SunPKCS11 provider with > SHA-3 once they are officially included. > > Valerie > > On 3/18/2020 4:07 PM, Michael StJohns wrote: >> On 3/18/2020 6:57 PM, Valerie Peng wrote: >>> >>> Anyone has time to help review this straight forward RFE? It's to >>> add SHA-3 support to Hmac. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie >> >> Valerie - >> >> I know the RFE says no PKCS11 because 2.40 doesn't include those >> items, but OASIS PKCS11 has proposed? SHA3 identifiers at >> https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result >> - maybe reach out and ask if these have been allocated pending the >> next release? >> >> Mike >> >> >> #define CKM_SHA3_256????????????? 0x000002b0UL >> ?#define CKM_SHA3_256_HMAC???????? 0x000002b1UL >> ?#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL >> ?#define CKM_SHA3_224????????????? 0x000002b5UL >> ?#define CKM_SHA3_224_HMAC???????? 0x000002b6UL >> ?#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL >> ?#define CKM_SHA3_384????????????? 0x000002c0UL >> ?#define CKM_SHA3_384_HMAC???????? 0x000002c1UL >> ?#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL >> ?#define CKM_SHA3_512????????????? 0x000002d0UL >> ?#define CKM_SHA3_512_HMAC???????? 0x000002d1UL >> ?#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Tue Mar 31 18:27:04 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 31 Mar 2020 18:27:04 +0000 Subject: RFR 8241960: The SHA3 message digests are not thread safe when cloned Message-ID: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com> Hi All, Please review fix for SHA3 message digests thread safety. Issue reproduced on the JDK11, JDK13 and JDK14 JTREG test is provided in the patch JBS: https://bugs.openjdk.java.net/browse/JDK-8241960 Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/ Regards Alexey From valerie.peng at oracle.com Tue Mar 31 19:15:57 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 31 Mar 2020 12:15:57 -0700 Subject: RFR: 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: <15e3ec7a-b85b-dd36-2bc3-d86dcee57b2d@oracle.com> References: <06fc3f21-225f-7262-fea3-29a6d803b328@oracle.com> <15e3ec7a-b85b-dd36-2bc3-d86dcee57b2d@oracle.com> Message-ID: <96acb180-f71b-c792-4dd4-2c2f9750ffdd@oracle.com> Hi Jamil, I looked at java.security.AlgorithmParameters and need to update my earlier comment below > - By convention, each init() is a fresh start and wipes out the effect > previous init() calls. But in the current webrev, they seems to apply > changes on top of each other. This may not be the right model of how > things should be handled. In addition, with the existing code handles > both PBES2 and PBEwithAnd, we may need extra logic to > restore the fields back to when they are first constructed at the > beginning of every engineInit(...). It turns out that AlgorithmParameters have an "initialized" flag which would only accept one successful init() call. Subsequent call would be rejected by throwing either IOException or InvalidParameterSpecException. So, I guess we don't need to worry about multiple init() calls. Just that the supplied data is legit and is not conflicting with the assumed algorithm values if the object is requested under the "friendly" name. Thanks, Valerie On 3/30/2020 8:25 PM, Valerie Peng wrote: > > Hi Jamil, > > Thanks for being so patient. It take me sometime to play around with > the changes and think about various scenarios... > > Here are some comments: > > > > - Line 38 has RFC 2268 which is for RC2, RC5 is in RFC 2040. > > - Line 48-51 comments can be simplified further, essentially, IV > (provided or not) shall have the same length as the block size. If not > provided explicitly, then its values are all 0s. Just some nit. > > > > - line 187: variable name 'pbeSpec' should probably be named as > 'rc5Spec' as it has nothing to do with PBE. > > > > - The test is very extensive... May I ask how are the test vectors > generated? Are they from some RFCs or external website like NIST or > internally generated using these new impl? In particular, I wonder > about the test "HmacSHA256 and AES-256-CBC [No Enc parameters]", this > is expected to pass, but AES CBC requires IV and if no parameters are > explicitly specified, how do things work for decryption where IV is > required and cannot generate random values as default IV? I am also > not sure about the InitByDERAndEncodeTest, I think we should not alter > the given encoding based on our own assumptions/defaults. If given a > DER encoding bytes, the same (minor difference such as an absent null > params is ok) encoding should be returned when getEncoded() is called. > > - Line 143 expVals[4] should be expVals[3]? > > > > - Current changes are a bit too complicated and I am not sure if it's > worthwhile to support RC2, RC5, DESede and DES and do their > algorithm-specific checking. PBES2 AlgorithmParameters parsing is > already complicated due we support the original name (PBES2) and also > the "friendly"? JCA naming convention of including the cipher name and > KDF name. On top of it, the current webrev seem to trying to support > parsing of all possible algorithms stated in PKCS#5 even when SunJCE > provider only support the AES_xxx variants. If only parsing is done, > the overhead may be acceptable, but then when there is also algorithm > specific checking, I feel this is a bit much as I doubt that they will > ever be used. > > - There are a lot of String parsing inside the String-arg constructor > which can be avoided if we replace this String-arg constructor with a > 2-arg constructor with PrfType and EncType. This should simplify the > constructor code greatly and make it more robust. Then we probably can > remove the getByName() method for both enum types. No need for the > constructor to throw NoSuchAlgorithmException as all inputs are > provided by provider and unsupported algorithm should be detected > before calling this constructor. > > - Line 259, add "," after the word "key"? > > - The ordering of things under engineInit(AlgorithmParameterSpec > paramSpec) seems a bit un-intuitive. User-supplied values should only > be stored after pass validation. The assignment (line 324-326) should > be done after the various checks. The check at line 338 should be > moved up before assigning the default kdf type. > > - Missing PBE subclasses for AES_192? > > - Some of the static oid constants seems unnecessary as they are only > used inside the enum and can be moved there. > > - By convention, each init() is a fresh start and wipes out the effect > previous init() calls. But in the current webrev, they seems to apply > changes on top of each other. This may not be the right model of how > things should be handled. In addition, with the existing code handles > both PBES2 and PBEwithAnd, we may need extra logic to > restore the fields back to when they are first constructed at the > beginning of every engineInit(...). > > - I am not too sure about the usefulness of "pbes2AlgorithmName" > field. In the current impl, it is set in various places. If it is > meant to reflect the latest KDF and CIPHER algorithm used, it's more > robust to construct its value when needed. Otherwise, we need to > remember updating this value whenever one of these 3 values, i.e. KDF, > CIPHER, and keysize, changed. > > - Consider grouping the fields of salt, iteration count, keysize, > prfType into separate class and move the PBKDF2 parsing/encoding code > there. This simplifies the validation and setting of these 4 fields. > > - Avoid algorithm-specific checking in this class as it is not > scalable and duplicates the checking in the algorithm-specific > classes. If you feel they must be done, delegate to the > algorithm-specific classes as much as possible. Instead of explicitly > checking the parameter spec, use the sequence of > AlgorithmParameters.getInstance(String), and its init(...) call and > see if the call passes. > > - There are also code which sets the keysize for RC2 and RC5 key sizes > based on the PBKDF2 and cipher parameters. I think it's reasonable to > derive the value from the PBKDF2 params, but not cipher parameters. In > the case of RC5, it even assigns a default value (line 760) when all > else is failed. Given the purpose of this class is for PBES2 algorithm > parameters and we don't support PBES2 cipher with RC2 or RC5, I think > we should not go this far. Is there anything that I missed for > requiring to set the keysize in this class? If "PBES2" > AlgorithmParameters are requested and initialized with DER encoding, > we should return the same encoding (unless it's mistakenly encoded as > stated in line )? when getEncoded() is called. It's also somewhat > strange that the toString() method returns only the "friendly" > expanded name without other info. This is different from other > AlgorithmParameters impl. But this is just nit comparing to other things. > > I adapted your changes with most of my feedback above (except the one > on each engineInit() call being independent) and you can find the > changes here: http://cr.openjdk.java.net/~valeriep/pbes2Exp/webrev/ > (The regression test PBES2ParametersTest.java has to be updated a > little in order to pass). Hope this can help you understand my comments. > > Thanks! > Valerie > > > On 3/18/2020 3:59 PM, Valerie Peng wrote: >> >> >> Right, I recall reviewing this and made some comments. Will take a >> look at the updated webrev. >> >> Thanks, >> Valerie >> On 3/17/2020 4:48 PM, Jamil Nimeh wrote: >>> >>> Hello all, >>> >>> I'm finally getting back around to this after dusting off the cobwebs. >>> >>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.03 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>> >>> Valerie, you had some comments from way back (7/9/2019). Just a >>> short summary of what's been done to address them: >>> >>> * Removed unused imports >>> * Added a default "PBES2" string value for when the toString >>> method is called on a PBES2Parameters object before the init() >>> method. >>> * Tested encoding of PBKDF2 parameters AlgorithmIdentifiers with >>> the optional parameters field not present (as opposed to an >>> ASN.1 NULL).? OpenSSL seems happy with it so that's how we'll >>> encode those. >>> * Switched order on the IV and keysize parsing for RC2 parameters >>> * Using KEYLEN_ANY (changed to KEYLEN_UNSPEC) now in lieu of -1 in >>> the conditionals you cited. >>> * For algorithms where the key length is implicit either due to >>> the algorithm or the specific OID, we no longer assert the key >>> length in the KDF parameters.? This is consistent with other >>> implementations such as OpenSSL. >>> * Regarding the comment from the parsing in engineInit(byte[]) >>> >>> "By calling data.getDerValue(), we are essentially peeling one layer >>> off, right? If you still agree with me at this point, then note that >>> pBES2_params is a local variable and its value should be the same >>> unless explicitly re-assigned (as on line 413). Thus, per my reading >>> of the code, the tag that you are checking on line 419 is not the >>> one for encryption scheme, but rather the outer sequence tag >>> encapsulating kdf and encryption scheme. Its current location is >>> very misleading though, in between kdf and encryption scheme. To >>> really check the tag for kdf and encryption scheme, the tag checking >>> should be in parseKDF(...) and parseES(...) against the DerValue >>> argument." >>> >>> I did add a DerValue check in parseKDF because it is appropriate as >>> you stated.? I also removed the check from line 419 in the old >>> webrev.? With the new code that check is redundant as we are using >>> AlgorithmId.parse() now as the initial operation in parseES, which >>> in turn does the sequence tag check for us. >>> >>> The check itself on 419 though is testing the ASN.1 tag for the >>> Encryption scheme, not the higher level sequence for PBES2-params.? >>> Otherwise neither the KDF nor the encryption scheme would parse >>> properly and none of the tests would pass. >>> >>> With this new code, parseKDF and parseES are testing the outer >>> SEQUENCE tags for each of the AlgorithmIdentifier objects described >>> by keyDerivationFunc and encryptionScheme per RFC 8018. >>> >>> * keysize setting: This one is a bit tricky because key size is >>> specified in multiple ways.? The basic flow is this.? Key size >>> will start as KEYLEN_UNSPEC.? If it is at any point specified, >>> either via the constructor, by KDF params, or by enc params then >>> that is the value that is set.? At near the end of parsing a >>> validation of the encryption parameters occurs and at that point >>> the key length is checked against the algorithm.? If it is an >>> alg that uses a fixed value then keysize has to be consistent >>> with it.? If it is variable length and it is still >>> KEYSIZE_UNSPEC that is also a failure (since something needs to >>> be specified to distinguish RC2_40 from RC2_128, for example). >>> o This approach seems to work and catches the issue you found >>> where certain DER encodings could yield things like >>> PBEWithHmacSHA256AndRC5_-1. >>> * Added some new tests to handle the changes listed above. >>> >>> I'll be updating the CSR shortly to reflect comments there and I'll >>> send a separate review notice for that. >>> >>> Thanks, >>> >>> --Jamil >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Mar 31 20:01:18 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 31 Mar 2020 13:01:18 -0700 Subject: RFR 8241960: The SHA3 message digests are not thread safe when cloned In-Reply-To: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com> References: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com> Message-ID: <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com> Hi Alexey, Good catch, thanks for the report, I will review it. On a first look, it seems that this is more about the clone() method of the SHA-3 impl missed copying/cloning an internal field. Given that this is about SUN provider, I've modified the synopsis accordingly and move the priority up to P3. It may not take multi-thread to reproduce this? If so, we can simplify the regression test. Regards, Valerie On 3/31/2020 11:27 AM, Alexey Bakhtin wrote: > Hi All, > > Please review fix for SHA3 message digests thread safety. > Issue reproduced on the JDK11, JDK13 and JDK14 > JTREG test is provided in the patch > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241960 > Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/ > > Regards > Alexey >