From weijun.wang at oracle.com Tue Dec 1 01:32:29 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 1 Dec 2015 09:32:29 +0800 Subject: S4U2Self and OpenJDK 8 In-Reply-To: References: Message-ID: Hi Marc Looks like the problem is below: >> KrbKdcRep.check: at #1. request for true, received false We've already fixed this in jdk9 at https://bugs.openjdk.java.net/browse/JDK-8022582 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ae6449bc523f you can see the check now starts at #2. Can you try out the latest jdk9 at https://jdk9.java.net/download/? Meanwhile, I'll file a backport request to jdk8u. Thanks Max From bradford.wetmore at oracle.com Tue Dec 1 01:32:47 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 30 Nov 2015 17:32:47 -0800 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> Message-ID: <565CF8BF.50200@oracle.com> On 11/29/2015 4:08 PM, Vincent Ryan wrote: > Following on from Brad?s recent email, here is the full webrev of the > API and the implementation classes for ALPN: > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ > > In adds the implementation classes (sun/security/ssl) to the public API > classes (javax/net/ssl) which have already been agreed. > Some basic tests (test/javax/net/ssl) are also included. SSLEngineAlpnTest.java ====================== 333: A minor comment here. I think you should test NONE like this: if (ap == null) { throw new Exception( "Handshake was completed but null was received"); } if (expectedAP.equals("NONE")) { if (!ap.isEmpty()) { throw new Exception(); } else { System.out.println("No ALPN value negotiated, as expected"); } } else if (!expectedAP.equals(ap)) { throw new Exception(expectedAP + " ALPN value not available on negotiated connection"); } BTW, the indentions here at 331/332/334 are off. The rest are all ok. We had also talked privately about testing getHandshakeApplicationProtocol(), but I don't see it here. Let me know if you didn't understand my comments about adding a X509ExtendedKeyManager (or X509ExtendedTrustManager), or else please file a RFE for it if it won't be ready for the initial integration. 298: This test is not actually calling into checkResult on the server side. Ooops! You need to check the output of the wrap() before calling unwrap() as it overwrites the serverResult. You need to put in a similar checkResult() before doing the flip()s. SSLSocketAlpnTest.java ====================== Same concern here as above. On 11/29/2015 10:30 PM, Xuelei Fan wrote: > line 538-546 > ------------ > String negotiatedValue = null; > List protocols = clientHelloALPN.getPeerAPs(); > > for (String ap : localApl) { > if (protocols.contains(ap)) { > negotiatedValue = ap; > break; > } > } > > I think the above order prefer the server preference order of > application protocols. It's OK per Section 3.2 of RFC 7301. Correct: In that case, the server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client. > However RFC 7301 also defines the client preference order. Looks like > the client preference order is not necessary. It's a little bit > confusing, and may result in different behaviors for different TLS vendors. > > Maybe, we can add an option to honor server preference order in the future. That was the plan if needed. Vincent wrote: > If necessary I think we can add support for controlling this via a > property, later. Or a new API (when possible): a new "preferPeerOrder" method and an update to the setApplicationProtocols() text: Unless configured by the preferPeerOrder() method, the first matched value becomes the negotiated value. On 11/30/2015 3:08 PM, Vincent Ryan wrote: >> SSLEngineImpl.java >> >================== >> > >> >line 1411-1412: >> >private Ciphertext writeRecord(ByteBuffer[] appData, >> > int offset, int length, ByteBuffer netData) throws IOException { >> > ... >> > if (...) { >> > ... >> > // set connection ALPN value >> > applicationProtocol = >> > handshaker.getHandshakeApplicationProtocol(); >> > ... >> > } >> >} >> > >> >Is it redundant to set applicationProtocol here. I was wondering, the >> >value should set in the processInputRecord() method. > > My understanding is the the wrapping is performed here and the unwrapping > performed in processInputRecord(). Isn?t the assignment required in both places? Apparently it's not, I thought it was. When unwrapping the final inbound Finished message around line 1069, it advances the internal state and writes its own Finished message into the outbound queue, but doesn't actually return hs=FINISHED until the outbound queue is drained. I had to step through it to confirm. So you can remove it. Thanks, Vinnie, looks good. Brad From xuelei.fan at oracle.com Tue Dec 1 01:53:23 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 1 Dec 2015 09:53:23 +0800 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565BED18.70202@oracle.com> Message-ID: <565CFD93.6030807@oracle.com> Looks fine to me. Thanks for the update. Xuelei On 12/1/2015 7:08 AM, Vincent Ryan wrote: > Thanks for your review. Comments in-line. > >> On 30 Nov 2015, at 06:30, Xuelei Fan wrote: >> >> Looks fine to me. Just a few minor comments. >> >> ServerHandshaker.java >> ===================== >> There is a typo of the first line. >> - /* Copyright (c) 1996, 2015, ... >> + /* >> + * Copyright (c) 1996, 2015 ? >> > Done. > >> >> line 538-546 >> ------------ >> String negotiatedValue = null; >> List protocols = clientHelloALPN.getPeerAPs(); >> >> for (String ap : localApl) { >> if (protocols.contains(ap)) { >> negotiatedValue = ap; >> break; >> } >> } >> >> I think the above order prefer the server preference order of >> application protocols. It's OK per Section 3.2 of RFC 7301. >> >> However RFC 7301 also defines the client preference order. Looks like >> the client preference order is not necessary. It's a little bit >> confusing, and may result in different behaviors for different TLS vendors. >> >> Maybe, we can add an option to honor server preference order in the future. > > I added a comment to show that server-preference is used. > If necessary I think we can add support for controlling this via a property, later. > > >> >> ALPNExtension.java >> ================== >> 96 listLength = s.getInt16(); // list length >> >> The code would throws SSLException if the remaining input is not >> sufficient. I was wondering, SSLProtocolException may be more suitable >> here. May be nice to check the "len" argument value if sufficient for >> the list length. Otherwise, a SSLProtocolException would be thrown. >> >> if (len >= 2) { >> listLength = s.getInt16(); // list length >> ... >> } else { >> throw new SSLProtocolException(...); >> } > > I added the exception and more detailed message. > >> >> ----------- >> 104 byte[] bytes = s.getBytes8(); >> 105 String p = >> 106 new String(bytes, StandardCharsets.UTF_8); // app protocol >> >> Do you want to check that the app protocol cannot be empty? >> >> // opaque ProtocolName<1..2^8-1>; // RFC 7301 >> byte[] bytes = s.getBytes8(); >> + if (bytes.length == 0) { >> + throw new SSLProtocolException("Empty ..."); >> + } > > Done. > > >> >> --------- >> Personally, I would prefer to use unmodifiableList for the protocolNames >> variable. > > It is accessible only to classes in this package. > > >> >> >> HelloExtensions.java >> ==================== >> line 34-37: >> * This file contains all the classes relevant to TLS Extensions for the >> * ClientHello and ServerHello messages. The extension mechanism and >> * several extensions are defined in RFC 3546. Additional extensions are >> * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301. >> >> I may put the "Additional extensions ..." at the end. BTW, as you are >> here already, would you mind update RFC 3546 to RFC 6066? RFC 6066 is >> the newest revision of RFC 3546. > > I concatenated the final sentence. > > >> >> * This file contains all the classes relevant to TLS Extensions for the >> * ClientHello and ServerHello messages. The extension mechanism and >> * several extensions are defined in RFC 6066. The ALPN extension is >> * defined in RFC 7301. Additional extensions are defined in the ECC >> * RFC 4492. >> >> SSLEngineImpl.java >> ================== >> >> line 1411-1412: >> private Ciphertext writeRecord(ByteBuffer[] appData, >> int offset, int length, ByteBuffer netData) throws IOException { >> ... >> if (...) { >> ... >> // set connection ALPN value >> applicationProtocol = >> handshaker.getHandshakeApplicationProtocol(); >> ... >> } >> } >> >> Is it redundant to set applicationProtocol here. I was wondering, the >> value should set in the processInputRecord() method. > > My understanding is the the wrapping is performed here and the unwrapping > performed in processInputRecord(). Isn?t the assignment required in both places? > > > >> >> Cheers, >> Xuelei >> >> On 11/30/2015 8:08 AM, Vincent Ryan wrote: >>> Hello, >>> >>> Following on from Brad?s recent email, here is the full webrev of the >>> API and the implementation classes for ALPN: >>> http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ >>> >>> In adds the implementation classes (sun/security/ssl) to the public API >>> classes (javax/net/ssl) which have already been agreed. >>> Some basic tests (test/javax/net/ssl) are also included. >>> >>> Please send any code review comments by close-of-business on Tuesday 1 >>> December. >>> Thanks. >> > From marc.boorshtein at tremolosecurity.com Tue Dec 1 02:38:27 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 30 Nov 2015 21:38:27 -0500 Subject: S4U2Self and OpenJDK 8 In-Reply-To: References: Message-ID: Thank Max. On OSX with the latest 1.9 I get the following: >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 83; type: 18 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 67; type: 17 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 75; type: 16 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 67; type: 23 Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Java config name: null Native config name: /etc/krb5.conf Loading krb5 profile at /etc/krb5.conf Loaded from native config Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN >>> KdcAccessibility: reset Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN default etypes for default_tkt_enctypes: 17 23 16. >>> KrbAsReq creating message >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=175 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=175 >>> KrbKdcReq send: #bytes read=327 >>>Pre-Authentication Data: PA-DATA type = 136 >>>Pre-Authentication Data: PA-DATA type = 19 PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB9)&A{.`Y;1k, s2kparams = null >>>Pre-Authentication Data: PA-DATA type = 2 PA-ENC-TIMESTAMP >>>Pre-Authentication Data: PA-DATA type = 133 >>> KdcAccessibility: remove freeipa.rhelent.lan >>> KDCRep: init() encoding tag is 126 req type is 11 >>>KRBError: cTime is Sat Jan 20 19:00:57 EST 1996 822182457000 sTime is Mon Nov 30 21:35:51 EST 2015 1448937351000 suSec is 558140 error code is 25 error Message is Additional pre-authentication required cname is HTTP/s4u.rhelent.lan at RHELENT.LAN sname is krbtgt/RHELENT.LAN at RHELENT.LAN eData provided. msgType is 30 >>>Pre-Authentication Data: PA-DATA type = 136 >>>Pre-Authentication Data: PA-DATA type = 19 PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB9)&A{.`Y;1k, s2kparams = null >>>Pre-Authentication Data: PA-DATA type = 2 PA-ENC-TIMESTAMP >>>Pre-Authentication Data: PA-DATA type = 133 KRBError received: NEEDED_PREAUTH KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ default etypes for default_tkt_enctypes: 17 23 16. Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN default etypes for default_tkt_enctypes: 17 23 16. >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbAsReq creating message >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=264 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=264 >>> KrbKdcReq send: #bytes read=691 >>> KdcAccessibility: remove freeipa.rhelent.lan Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbAsRep cons in KrbAsReq.getReply HTTP/s4u.rhelent.lan Service subject: Subject: Principal: HTTP/s4u.rhelent.lan at RHELENT.LAN Private Credential: Ticket (hex) = 0000: 61 82 01 51 30 82 01 4D A0 03 02 01 05 A1 0D 1B a..Q0..M........ 0010: 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A2 20 30 1E .RHELENT.LAN. 0. 0020: A0 03 02 01 02 A1 17 30 15 1B 06 6B 72 62 74 67 .......0...krbtg 0030: 74 1B 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A3 82 t..RHELENT.LAN.. 0040: 01 13 30 82 01 0F A0 03 02 01 12 A1 03 02 01 01 ..0............. 0050: A2 82 01 01 04 81 FE 04 0B 24 5B A6 36 2A 4B C7 .........$[.6*K. 0060: 0D 58 1A EB 79 20 62 BE 16 44 28 93 5D 87 5B FD .X..y b..D(.].[. 0070: DE 20 7D CF 79 4C 0E CC 77 90 40 06 10 11 9F 70 . ..yL..w. at ....p 0080: 9E B4 7E B5 CA 14 27 23 DD CD D6 6E 31 1F FC CA ......'#...n1... 0090: 65 CB 98 47 2B F0 C8 3B 96 C3 D6 AF EB DB 91 2F e..G+..;......./ 00A0: 1D 88 66 53 4F 03 7B 47 3C 32 E8 F2 CE 3E B1 E7 ..fSO..G<2...>.. 00B0: 78 80 B3 37 6F 5E 18 76 68 F4 AE C6 C7 C2 B8 99 x..7o^.vh....... 00C0: 61 A3 42 A1 5D 32 69 BB 0D 42 C5 98 46 B8 8A C6 a.B.]2i..B..F... 00D0: 4A 68 88 E3 79 D0 E2 F7 DD 62 0F DD E6 6A 97 7B Jh..y....b...j.. 00E0: 4B A1 A0 1C 45 17 97 E4 CC 71 D2 86 61 52 40 34 K...E....q..aR at 4 00F0: DE EF 45 5E 21 94 AB 5C 76 91 CE 68 DB A1 94 5F ..E^!..\v..h..._ 0100: 14 CC 54 BB 35 85 EB 56 F0 FC 83 B5 CB 41 48 A1 ..T.5..V.....AH. 0110: AE C8 2F 22 C6 48 B9 14 CD 5F 9B B5 14 2B CC D5 ../".H..._...+.. 0120: B7 DC C3 74 4C 98 19 10 72 83 5D F6 BC A0 A1 9F ...tL...r.]..... 0130: 19 1F 63 07 AF C1 35 EE 1A 82 FE A5 88 CE 7A DF ..c...5.......z. 0140: 0F 43 E4 55 EC CC 0C 34 47 B4 B8 E1 C2 90 AC 63 .C.U...4G......c 0150: 19 01 A1 87 A5 ..... Client Principal = HTTP/s4u.rhelent.lan at RHELENT.LAN Server Principal = krbtgt/RHELENT.LAN at RHELENT.LAN Session Key = EncryptionKey: keyType=17 keyBytes (hex dump)= 0000: D9 D2 7F 9D 3F 5F 32 1A 41 10 4D 9F 0C 7D C5 D8 ....?_2.A.M..... Forwardable Ticket true Forwarded Ticket false Proxiable Ticket false Proxy Ticket false Postdated Ticket false Renewable Ticket true Initial Ticket true Auth Time = Mon Nov 30 21:35:51 EST 2015 Start Time = Mon Nov 30 21:35:51 EST 2015 End Time = Tue Dec 01 21:35:51 EST 2015 Renew Till = Mon Dec 07 21:35:51 EST 2015 Client Addresses Null Private Credential: /Users/mlb/Documents/localdev.keytab for HTTP/s4u.rhelent.lan at RHELENT.LAN Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST 2015 Search Subject for SPNEGO INIT cred (<>, sun.security.jgss.spnego.SpNegoCredElement) Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST 2015 >>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType default etypes for default_tgs_enctypes: 17 23 16. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=772 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=772 >>> KrbKdcReq send: #bytes read=582 >>> KdcAccessibility: remove freeipa.rhelent.lan >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:92) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:153) at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) at test24u2.KerberosDemo.main(KerberosDemo.java:215) Caused by: KrbException: S4U2self ticket must be FORWARDABLE at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:75) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 9 more Seems it looks like its still doing the check for forwardable. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Mon, Nov 30, 2015 at 8:32 PM, Wang Weijun wrote: > Hi Marc > > Looks like the problem is below: > >>> KrbKdcRep.check: at #1. request for true, received false > > We've already fixed this in jdk9 at > > https://bugs.openjdk.java.net/browse/JDK-8022582 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ae6449bc523f > > you can see the check now starts at #2. > > Can you try out the latest jdk9 at https://jdk9.java.net/download/? > > Meanwhile, I'll file a backport request to jdk8u. > > Thanks > Max > From weijun.wang at oracle.com Tue Dec 1 03:01:37 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 1 Dec 2015 11:01:37 +0800 Subject: S4U2Self and OpenJDK 8 In-Reply-To: References: Message-ID: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com> It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way? --Max From weijun.wang at oracle.com Tue Dec 1 06:17:37 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 1 Dec 2015 14:17:37 +0800 Subject: RFR 8144294: jdk/security/jarsigner/Function.java failed to clean up files after test on Windows Message-ID: <565D3B81.7040802@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8144294/webrev.00/ A file was not closed. Thanks Max From xuelei.fan at oracle.com Tue Dec 1 07:04:57 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 1 Dec 2015 15:04:57 +0800 Subject: RFR 8144294: jdk/security/jarsigner/Function.java failed to clean up files after test on Windows In-Reply-To: <565D3B81.7040802@oracle.com> References: <565D3B81.7040802@oracle.com> Message-ID: <565D4699.9030500@oracle.com> Looks fine to me. Xuelei On 12/1/2015 2:17 PM, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8144294/webrev.00/ > > A file was not closed. > > Thanks > Max From simone.bordet at gmail.com Tue Dec 1 09:53:47 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 1 Dec 2015 10:53:47 +0100 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> Message-ID: Hi, On Mon, Nov 30, 2015 at 1:08 AM, Vincent Ryan wrote: > Hello, > > Following on from Brad?s recent email, here is the full webrev of the API > and the implementation classes for ALPN: > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ > > In adds the implementation classes (sun/security/ssl) to the public API > classes (javax/net/ssl) which have already been agreed. > Some basic tests (test/javax/net/ssl) are also included. I just would like to remind that session resumption is a very important use case to support for ALPN. I have not seen anything related to this review for session resumption. Has it been tested ? It is still not clear to me what a client and a server have to do to support ALPN. >From my understanding a server has to: * read encrypted bytes into a ByteBuffer * parse the TLS ClientHello frame on its own * extract from the ClientHello the TLS Protocol version, the ALPN extension, and the ciphers * run some logic to determine the AP ** if no AP can be chosen, generate a TLS Alert frame on its own to close the connection and bail out * otherwise, an AP/cipher combo has been chosen * sslParameters.setApplicationProtocols(AP) // just one protocol * sslParameters.setCipherSuites(cipher) // just one cipher * sslEngine.setSSLParameters(sslParameters) * reset the ByteBuffer position to the beginning * pass the ByteBuffer to sslEngine.unwrap() * JDK implementation will re-parse the ClientHello, and use the sslParameters data during handshake and when generating the ServerHello A client has to: * read encrypted bytes into a ByteBuffer * parse a ServerHello frame on its own * extract the ALPN extension and the cipher * run some logic to verify that the AP and the cipher can be used together ** if AP and cipher don't match, generate a TLS Alert frame on its own to close the connection and bail out * otherwise the AP/cipher combo is ok * reset the ByteBuffer position to the beginning * pass the ByteBuffer to sslEngine.unwrap() * JDK implementation will re-parse the ServerHello and complete the TLS handshake Is that right ? In that scenario, what is the use of SSLEngine.getHandshakeApplicationProtocol() ? Also, I don't understand how the above could work for SSLSocket ? Can someone write down the steps a client and a server should do to actually use ALPN with SSLSocket ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Tue Dec 1 10:48:21 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 1 Dec 2015 18:48:21 +0800 Subject: Code Review Request, 8144313, Test SessionTimeOutTests can be timeout Message-ID: <565D7AF5.3000904@oracle.com> Hi, Please review this test update: http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/ In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of "serverReady" variable was not synchronized when performing multiple operations, as may result that the variable cannot be calculated correctly, and result in timeout accordingly. Update to use AtomicInteger for the atomic update. Thanks, Xuelei From sean.mullan at oracle.com Tue Dec 1 12:36:28 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Dec 2015 07:36:28 -0500 Subject: Code Review Request, 8144313, Test SessionTimeOutTests can be timeout In-Reply-To: <565D7AF5.3000904@oracle.com> References: <565D7AF5.3000904@oracle.com> Message-ID: <565D944C.1@oracle.com> serverReady doesn't need to be volatile anymore. Looks good otherwise. --Sean On 12/01/2015 05:48 AM, Xuelei Fan wrote: > Hi, > > Please review this test update: > > http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/ > > In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of > "serverReady" variable was not synchronized when performing multiple > operations, as may result that the variable cannot be calculated > correctly, and result in timeout accordingly. > > Update to use AtomicInteger for the atomic update. > > Thanks, > Xuelei > From xuelei.fan at oracle.com Tue Dec 1 12:49:56 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 1 Dec 2015 20:49:56 +0800 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable Message-ID: <565D9774.9000304@oracle.com> Hi, Please review the fix for JDK-8133070: http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ In (Open)JDK 6, EC cipher suites get supported by Java. However, there is no default EC provider in JDK 6 at that time. In order to support third part's EC algorithm JCE provider dynamically, it is hard-coded to check the cipher suite availability dynamically for EC algorithms in SunJSSE provider. Here is an example update in CipherSuite.java for the checking: - static final boolean DYNAMIC_AVAILABILITY = false; + static final boolean DYNAMIC_AVAILABILITY = true; The dynamically checking impacts the performance significantly as: 1. the check of the availability is expensive as it involves crypto operations. 2. a cache is used to maintain the availability of bulk ciphers in order to mitigate the #1 performance impact. However, access and update to the cache need to be synchronized. 3. in order to support dynamically checking, the cache may be cleared if a particular cipher is not found or a new SSLContext is generated. As bring the performance impact of #1 back again. Later, AEAD algorithm is defined by Java. The same mechanism is used to support AEAD ciphers. Now, EC and GCM algorithms are supported in JDK crypto providers. The hard-coded checking can get improved. This fix updates: 1. remove the dynamically checking of cipher suite availability. 2. remove the cipher suite availability cache accordingly (need no synchronization accordingly) 3. other updates that impact by the availability checking. The performance improvement is tested with the following simple case. Run the following code 1000, 2000, 3000 times in single thread mode and measure the millisecond for each: --------- String[] cipherSuites = {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 SSLEngine engine = SSLContext.getDefault().createSSLEngine(); engine.getEnabledCipherSuites(); engine.getSupportedCipherSuites(); } --------- The milliseconds for each test case (less is better) look like: loops | old | fixed ---------+---------+---------- 1000 | 2736 | 735 ---------+---------+---------- 2000 | 3718 | 746 ---------+---------+---------- 3000 | 4750 | 765 ---------+---------+---------- This fix improves the performance. The existing regression testing get passed. No new regression test is planned as this is a performance enhancement fix. Thanks, Xuelei From sean.coffey at oracle.com Tue Dec 1 13:53:42 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 1 Dec 2015 13:53:42 +0000 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <565CFD93.6030807@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565BED18.70202@oracle.com> <565CFD93.6030807@oracle.com> Message-ID: <565DA666.6040005@oracle.com> Hey Vinnie, question on SSLParameters.setApplicationProtocols(String[] protocols) method What happens if you pass an empty array into this method. Shouldn't it throw an IllegalArgumentException ? ==== In ALPNExtension.java : > + if (listLength < 2 || listLength + 2 != len) { > + throw new SSLProtocolException( > + "Invalid " + type + " extension: incorrect list length"); Can you print the listLength value in exception message ? > + throw new SSLProtocolException( > + "Invalid " + type + " extension: too short"); Can you print the len value here ? > + if (remaining != 0) { > + throw new SSLProtocolException( > + "Invalid " + type + " extension: extra data"); Can you print remaining value here ? Regards, Sean. On 01/12/2015 01:53, Xuelei Fan wrote: > Looks fine to me. Thanks for the update. > > Xuelei > > On 12/1/2015 7:08 AM, Vincent Ryan wrote: >> Thanks for your review. Comments in-line. >> >>> On 30 Nov 2015, at 06:30, Xuelei Fan wrote: >>> >>> Looks fine to me. Just a few minor comments. >>> >>> ServerHandshaker.java >>> ===================== >>> There is a typo of the first line. >>> - /* Copyright (c) 1996, 2015, ... >>> + /* >>> + * Copyright (c) 1996, 2015 ? >>> >> Done. >> >>> line 538-546 >>> ------------ >>> String negotiatedValue = null; >>> List protocols = clientHelloALPN.getPeerAPs(); >>> >>> for (String ap : localApl) { >>> if (protocols.contains(ap)) { >>> negotiatedValue = ap; >>> break; >>> } >>> } >>> >>> I think the above order prefer the server preference order of >>> application protocols. It's OK per Section 3.2 of RFC 7301. >>> >>> However RFC 7301 also defines the client preference order. Looks like >>> the client preference order is not necessary. It's a little bit >>> confusing, and may result in different behaviors for different TLS vendors. >>> >>> Maybe, we can add an option to honor server preference order in the future. >> I added a comment to show that server-preference is used. >> If necessary I think we can add support for controlling this via a property, later. >> >> >>> ALPNExtension.java >>> ================== >>> 96 listLength = s.getInt16(); // list length >>> >>> The code would throws SSLException if the remaining input is not >>> sufficient. I was wondering, SSLProtocolException may be more suitable >>> here. May be nice to check the "len" argument value if sufficient for >>> the list length. Otherwise, a SSLProtocolException would be thrown. >>> >>> if (len >= 2) { >>> listLength = s.getInt16(); // list length >>> ... >>> } else { >>> throw new SSLProtocolException(...); >>> } >> I added the exception and more detailed message. >> >>> ----------- >>> 104 byte[] bytes = s.getBytes8(); >>> 105 String p = >>> 106 new String(bytes, StandardCharsets.UTF_8); // app protocol >>> >>> Do you want to check that the app protocol cannot be empty? >>> >>> // opaque ProtocolName<1..2^8-1>; // RFC 7301 >>> byte[] bytes = s.getBytes8(); >>> + if (bytes.length == 0) { >>> + throw new SSLProtocolException("Empty ..."); >>> + } >> Done. >> >> >>> --------- >>> Personally, I would prefer to use unmodifiableList for the protocolNames >>> variable. >> It is accessible only to classes in this package. >> >> >>> >>> HelloExtensions.java >>> ==================== >>> line 34-37: >>> * This file contains all the classes relevant to TLS Extensions for the >>> * ClientHello and ServerHello messages. The extension mechanism and >>> * several extensions are defined in RFC 3546. Additional extensions are >>> * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301. >>> >>> I may put the "Additional extensions ..." at the end. BTW, as you are >>> here already, would you mind update RFC 3546 to RFC 6066? RFC 6066 is >>> the newest revision of RFC 3546. >> I concatenated the final sentence. >> >> >>> * This file contains all the classes relevant to TLS Extensions for the >>> * ClientHello and ServerHello messages. The extension mechanism and >>> * several extensions are defined in RFC 6066. The ALPN extension is >>> * defined in RFC 7301. Additional extensions are defined in the ECC >>> * RFC 4492. >>> >>> SSLEngineImpl.java >>> ================== >>> >>> line 1411-1412: >>> private Ciphertext writeRecord(ByteBuffer[] appData, >>> int offset, int length, ByteBuffer netData) throws IOException { >>> ... >>> if (...) { >>> ... >>> // set connection ALPN value >>> applicationProtocol = >>> handshaker.getHandshakeApplicationProtocol(); >>> ... >>> } >>> } >>> >>> Is it redundant to set applicationProtocol here. I was wondering, the >>> value should set in the processInputRecord() method. >> My understanding is the the wrapping is performed here and the unwrapping >> performed in processInputRecord(). Isn?t the assignment required in both places? >> >> >> >>> Cheers, >>> Xuelei >>> >>> On 11/30/2015 8:08 AM, Vincent Ryan wrote: >>>> Hello, >>>> >>>> Following on from Brad?s recent email, here is the full webrev of the >>>> API and the implementation classes for ALPN: >>>> http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ >>>> >>>> In adds the implementation classes (sun/security/ssl) to the public API >>>> classes (javax/net/ssl) which have already been agreed. >>>> Some basic tests (test/javax/net/ssl) are also included. >>>> >>>> Please send any code review comments by close-of-business on Tuesday 1 >>>> December. >>>> Thanks. From sean.mullan at oracle.com Tue Dec 1 14:06:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Dec 2015 09:06:16 -0500 Subject: RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256 In-Reply-To: References: <565454D3.4050007@oracle.com> Message-ID: <565DA958.9020506@oracle.com> On 11/25/2015 09:39 PM, Wang Weijun wrote: > Updated at http://cr.openjdk.java.net/~weijun/8141457/webrev.01/. > > I was lazy last time. Looks good. --Sean > > --Max > >> On Nov 24, 2015, at 8:15 PM, Sean Mullan wrote: >> >> Looks good - although you could replace the MD5 fingerprints with the SHA256 fingerprints in the test files for some additional testing. >> >> --Sean >> >> On 11/23/2015 08:00 PM, Wang Weijun wrote: >>> Hi All >>> >>> Please review a code change at >>> >>> http://cr.openjdk.java.net/~weijun/8141457/webrev.00/ >>> >>> SHA-256 is now the default fingerprint algorithm, and MD5 is removed in the full list. >>> >>> No new regression test, I consider the change trivial. If you think one is better, I'll add it. >>> >>> Thanks >>> Max >>> > From sean.mullan at oracle.com Tue Dec 1 14:34:21 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Dec 2015 09:34:21 -0500 Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete In-Reply-To: <4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com> References: <58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com> <5654458D.1080705@oracle.com> <5655CE04.2000004@oracle.com> <4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com> Message-ID: <565DAFED.90408@oracle.com> Looks good, although the location of the new test (test/sun/security) doesn't seem right. A new directory named test/conf/security would probably make the most sense, but I think putting it in the new test/jdk/security directory is also a better option. --Sean On 11/25/2015 09:36 PM, Wang Weijun wrote: > >> On Nov 25, 2015, at 11:04 PM, Sean Mullan wrote: >> >> The fix looks fine to me. For testing, can you create a test that uses a custom java.security file with "#ifndef solaris-sparc" in it, and check whether the property is used or not depending on what system is being tested? > > The tool is inside another repo. I can still write one though. > > Please take a look at the updated webrev: > > http://cr.openjdk.java.net/~weijun/8141690/webrev.01/ > > I also fixed a bug inside MakeJavaSecurity.java. If package.access or package.definition happens to be the last property, an NPE will be thrown. > > Thanks > Max > >> >> --Sean >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ >>>>> > From marc.boorshtein at tremolosecurity.com Tue Dec 1 16:23:56 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 11:23:56 -0500 Subject: S4U2Self and OpenJDK 8 In-Reply-To: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com> References: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com> Message-ID: Hmm, I think you are right. Here's what the Microsoft docs say "The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set (see Service 1 in the figure specifying Kerberos delegation with forwarded TGT, section 1.3.3). This ticket can be obtained through an S4U2self protocol exchange.". I'll followup with the folks at RedHat and FreeIPA. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Mon, Nov 30, 2015 at 10:01 PM, Wang Weijun wrote: > It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way? > > --Max > From sean.mullan at oracle.com Tue Dec 1 17:03:22 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Dec 2015 12:03:22 -0500 Subject: openjdk 8 & 2048 bit DSA xml signing In-Reply-To: References: Message-ID: <565DD2DA.4020503@oracle.com> I opened a backport for this issue for a JDK 8 update release, see: https://bugs.openjdk.java.net/browse/JDK-8143905 The backport should be relatively straightforward, but I am not sure yet when or what release the fix will appear in. --Sean On 11/19/2015 04:53 AM, Basabendra Misra wrote: > Hi, > > It seems there is a fix to support 2048 bit DSA signing in upcoming > openjdk 9 release. However , could anyone please guide me what would be > the safest way to incorporate the same in openjdk 8? > Would really appreciate any help. We're stuck because some CA not > offering 1024 bit DSA keys anymore. > > Thanks & regards, > Basabendra Misra > +91-9830527802 From marc.boorshtein at tremolosecurity.com Tue Dec 1 17:59:04 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 12:59:04 -0500 Subject: S4U2Self and OpenJDK 8 In-Reply-To: References: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com> Message-ID: Max, Closing the loop on this. It turns out that there was an extra step needed to get the user in freeipa setup as a delegate (the documentation was written for S4U2Proxy, not S4U2Self). Once I set that flag delegation started working for BOTH Java 8 and Java 9. Thanks again. Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Tue, Dec 1, 2015 at 11:23 AM, Marc Boorshtein wrote: > Hmm, I think you are right. Here's what the Microsoft docs say "The > S4U2proxy extension requires that the service ticket to the first > service has the forwardable flag set (see Service 1 in the figure > specifying Kerberos delegation with forwarded TGT, section 1.3.3). > This ticket can be obtained through an S4U2self protocol exchange.". > I'll followup with the folks at RedHat and FreeIPA. > > Thanks > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > > > On Mon, Nov 30, 2015 at 10:01 PM, Wang Weijun wrote: >> It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way? >> >> --Max >> From vincent.x.ryan at oracle.com Tue Dec 1 21:20:59 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 1 Dec 2015 21:20:59 +0000 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <565CF8BF.50200@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565CF8BF.50200@oracle.com> Message-ID: <0DD900B1-69CC-4463-8DBD-D6CB88FFB2A8@oracle.com> Thanks for the additional review comments. Responses in-line below. Updated webrev: http://cr.openjdk.java.net/~vinnie/8144093/webrev.02/ > On 1 Dec 2015, at 01:32, Bradford Wetmore wrote: > > > On 11/29/2015 4:08 PM, Vincent Ryan wrote: > > > Following on from Brad?s recent email, here is the full webrev of the > > API and the implementation classes for ALPN: > > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ > > > > In adds the implementation classes (sun/security/ssl) to the public API > > classes (javax/net/ssl) which have already been agreed. > > Some basic tests (test/javax/net/ssl) are also included. > > SSLEngineAlpnTest.java > ====================== > > 333: A minor comment here. I think you should test NONE like this: > > if (ap == null) { > throw new Exception( > "Handshake was completed but null was received"); > } > if (expectedAP.equals("NONE")) { > if (!ap.isEmpty()) { > throw new Exception(); > } else { > System.out.println("No ALPN value negotiated, as expected"); > } > } else if (!expectedAP.equals(ap)) { > throw new Exception(expectedAP + > " ALPN value not available on negotiated connection"); > } Done. > > BTW, the indentions here at 331/332/334 are off. The rest are all ok. Corrected. > > We had also talked privately about testing getHandshakeApplicationProtocol(), but I don't see it here. Let me know if you didn't understand my comments about adding a X509ExtendedKeyManager (or X509ExtendedTrustManager), or else please file a RFE for it if it won't be ready for the initial integration. I?ll file an RFE for that. > > 298: This test is not actually calling into checkResult on the server side. Ooops! You need to check the output of the wrap() before calling unwrap() as it overwrites the serverResult. You need to put in a similar checkResult() before doing the flip()s. So checks are required before and after the buffer flips, right? > > > SSLSocketAlpnTest.java > ====================== > > Same concern here as above. Done. > > > On 11/29/2015 10:30 PM, Xuelei Fan wrote: > > line 538-546 > > ------------ > > String negotiatedValue = null; > > List protocols = clientHelloALPN.getPeerAPs(); > > > > for (String ap : localApl) { > > if (protocols.contains(ap)) { > > negotiatedValue = ap; > > break; > > } > > } > > > > I think the above order prefer the server preference order of > > application protocols. It's OK per Section 3.2 of RFC 7301. > > Correct: > > In that case, the server SHOULD select the most > highly preferred protocol that it supports and that is also > advertised by the client. > > > However RFC 7301 also defines the client preference order. Looks like > > the client preference order is not necessary. It's a little bit > > confusing, and may result in different behaviors for different TLS vendors. > > > > Maybe, we can add an option to honor server preference order in the future. > > That was the plan if needed. > > Vincent wrote: > > If necessary I think we can add support for controlling this via a > > property, later. > > Or a new API (when possible): a new "preferPeerOrder" method and an update to the setApplicationProtocols() text: > > Unless configured by the preferPeerOrder() method, the first > matched value becomes the negotiated value. > > On 11/30/2015 3:08 PM, Vincent Ryan wrote: > >> SSLEngineImpl.java > >> >================== > >> > > >> >line 1411-1412: > >> >private Ciphertext writeRecord(ByteBuffer[] appData, > >> > int offset, int length, ByteBuffer netData) throws IOException { > >> > ... > >> > if (...) { > >> > ... > >> > // set connection ALPN value > >> > applicationProtocol = > >> > handshaker.getHandshakeApplicationProtocol(); > >> > ... > >> > } > >> >} > >> > > >> >Is it redundant to set applicationProtocol here. I was wondering, the > >> >value should set in the processInputRecord() method. > > > > My understanding is the the wrapping is performed here and the unwrapping > > performed in processInputRecord(). Isn?t the assignment required in both places? > > Apparently it's not, I thought it was. When unwrapping the final inbound Finished message around line 1069, it advances the internal state and writes its own Finished message into the outbound queue, but doesn't actually return hs=FINISHED until the outbound queue is drained. > > I had to step through it to confirm. So you can remove it. Done. > > Thanks, Vinnie, looks good. > > Brad > From vincent.x.ryan at oracle.com Tue Dec 1 21:21:11 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 1 Dec 2015 21:21:11 +0000 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <565DA666.6040005@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565BED18.70202@oracle.com> <565CFD93.6030807@oracle.com> <565DA666.6040005@oracle.com> Message-ID: Hello Sean, An empty array is allowed: it means do not use ALPN. I?ve updated the exception messages to display the offending length in each case. --- ALPNExtension.java Tue Dec 1 15:22:02 2015 +++ ALPNExtension.java Tue Dec 1 14:56:12 2015 @@ -97,11 +97,13 @@ listLength = s.getInt16(); // list length if (listLength < 2 || listLength + 2 != len) { throw new SSLProtocolException( - "Invalid " + type + " extension: incorrect list length"); + "Invalid " + type + " extension: incorrect list length " + + "(length=" + listLength + ")"); } } else { throw new SSLProtocolException( - "Invalid " + type + " extension: too short"); + "Invalid " + type + " extension: insufficient data " + + "(length=" + len + ")"); } int remaining = listLength; @@ -121,7 +123,8 @@ if (remaining != 0) { throw new SSLProtocolException( - "Invalid " + type + " extension: extra data"); + "Invalid " + type + " extension: extra data " + + "(length=" + remaining + ")"); } } > On 1 Dec 2015, at 13:53, Se?n Coffey wrote: > > Hey Vinnie, > > question on SSLParameters.setApplicationProtocols(String[] protocols) method > > What happens if you pass an empty array into this method. Shouldn't it throw an IllegalArgumentException ? > > ==== > > In ALPNExtension.java : >> + if (listLength < 2 || listLength + 2 != len) { >> + throw new SSLProtocolException( >> + "Invalid " + type + " extension: incorrect list length"); > Can you print the listLength value in exception message ? > >> + throw new SSLProtocolException( >> + "Invalid " + type + " extension: too short"); > Can you print the len value here ? > >> + if (remaining != 0) { >> + throw new SSLProtocolException( >> + "Invalid " + type + " extension: extra data"); > Can you print remaining value here ? > > Regards, > Sean. > > On 01/12/2015 01:53, Xuelei Fan wrote: >> Looks fine to me. Thanks for the update. >> >> Xuelei >> >> On 12/1/2015 7:08 AM, Vincent Ryan wrote: >>> Thanks for your review. Comments in-line. >>> >>>> On 30 Nov 2015, at 06:30, Xuelei Fan wrote: >>>> >>>> Looks fine to me. Just a few minor comments. >>>> >>>> ServerHandshaker.java >>>> ===================== >>>> There is a typo of the first line. >>>> - /* Copyright (c) 1996, 2015, ... >>>> + /* >>>> + * Copyright (c) 1996, 2015 ? >>>> >>> Done. >>> >>>> line 538-546 >>>> ------------ >>>> String negotiatedValue = null; >>>> List protocols = clientHelloALPN.getPeerAPs(); >>>> >>>> for (String ap : localApl) { >>>> if (protocols.contains(ap)) { >>>> negotiatedValue = ap; >>>> break; >>>> } >>>> } >>>> >>>> I think the above order prefer the server preference order of >>>> application protocols. It's OK per Section 3.2 of RFC 7301. >>>> >>>> However RFC 7301 also defines the client preference order. Looks like >>>> the client preference order is not necessary. It's a little bit >>>> confusing, and may result in different behaviors for different TLS vendors. >>>> >>>> Maybe, we can add an option to honor server preference order in the future. >>> I added a comment to show that server-preference is used. >>> If necessary I think we can add support for controlling this via a property, later. >>> >>> >>>> ALPNExtension.java >>>> ================== >>>> 96 listLength = s.getInt16(); // list length >>>> >>>> The code would throws SSLException if the remaining input is not >>>> sufficient. I was wondering, SSLProtocolException may be more suitable >>>> here. May be nice to check the "len" argument value if sufficient for >>>> the list length. Otherwise, a SSLProtocolException would be thrown. >>>> >>>> if (len >= 2) { >>>> listLength = s.getInt16(); // list length >>>> ... >>>> } else { >>>> throw new SSLProtocolException(...); >>>> } >>> I added the exception and more detailed message. >>> >>>> ----------- >>>> 104 byte[] bytes = s.getBytes8(); >>>> 105 String p = >>>> 106 new String(bytes, StandardCharsets.UTF_8); // app protocol >>>> >>>> Do you want to check that the app protocol cannot be empty? >>>> >>>> // opaque ProtocolName<1..2^8-1>; // RFC 7301 >>>> byte[] bytes = s.getBytes8(); >>>> + if (bytes.length == 0) { >>>> + throw new SSLProtocolException("Empty ..."); >>>> + } >>> Done. >>> >>> >>>> --------- >>>> Personally, I would prefer to use unmodifiableList for the protocolNames >>>> variable. >>> It is accessible only to classes in this package. >>> >>> >>>> >>>> HelloExtensions.java >>>> ==================== >>>> line 34-37: >>>> * This file contains all the classes relevant to TLS Extensions for the >>>> * ClientHello and ServerHello messages. The extension mechanism and >>>> * several extensions are defined in RFC 3546. Additional extensions are >>>> * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301. >>>> >>>> I may put the "Additional extensions ..." at the end. BTW, as you are >>>> here already, would you mind update RFC 3546 to RFC 6066? RFC 6066 is >>>> the newest revision of RFC 3546. >>> I concatenated the final sentence. >>> >>> >>>> * This file contains all the classes relevant to TLS Extensions for the >>>> * ClientHello and ServerHello messages. The extension mechanism and >>>> * several extensions are defined in RFC 6066. The ALPN extension is >>>> * defined in RFC 7301. Additional extensions are defined in the ECC >>>> * RFC 4492. >>>> >>>> SSLEngineImpl.java >>>> ================== >>>> >>>> line 1411-1412: >>>> private Ciphertext writeRecord(ByteBuffer[] appData, >>>> int offset, int length, ByteBuffer netData) throws IOException { >>>> ... >>>> if (...) { >>>> ... >>>> // set connection ALPN value >>>> applicationProtocol = >>>> handshaker.getHandshakeApplicationProtocol(); >>>> ... >>>> } >>>> } >>>> >>>> Is it redundant to set applicationProtocol here. I was wondering, the >>>> value should set in the processInputRecord() method. >>> My understanding is the the wrapping is performed here and the unwrapping >>> performed in processInputRecord(). Isn?t the assignment required in both places? >>> >>> >>> >>>> Cheers, >>>> Xuelei >>>> >>>> On 11/30/2015 8:08 AM, Vincent Ryan wrote: >>>>> Hello, >>>>> >>>>> Following on from Brad?s recent email, here is the full webrev of the >>>>> API and the implementation classes for ALPN: >>>>> http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ >>>>> >>>>> In adds the implementation classes (sun/security/ssl) to the public API >>>>> classes (javax/net/ssl) which have already been agreed. >>>>> Some basic tests (test/javax/net/ssl) are also included. >>>>> >>>>> Please send any code review comments by close-of-business on Tuesday 1 >>>>> December. >>>>> Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Dec 1 23:44:55 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 1 Dec 2015 15:44:55 -0800 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests Message-ID: <565E30F7.5060307@oracle.com> Hi all, I'd like a review of this change. It improves nextBytes() performance by allowing the random buffer to grow and shrink as random data is needed and remove the high level synchronization. Also disable SecureRandom for Solaris PKCS11 as it's not as fast as native. http://cr.openjdk.java.net/~ascarpino/8098581/webrev/ Thanks Tony From bradford.wetmore at oracle.com Tue Dec 1 23:58:01 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 1 Dec 2015 15:58:01 -0800 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <0DD900B1-69CC-4463-8DBD-D6CB88FFB2A8@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565CF8BF.50200@oracle.com> <0DD900B1-69CC-4463-8DBD-D6CB88FFB2A8@oracle.com> Message-ID: <565E3409.7040503@oracle.com> >> 298: This test is not actually calling into checkResult on the server side. Ooops! You need to check the output of the wrap() before calling unwrap() as it overwrites the serverResult. You need to put in a similar checkResult() before doing the flip()s. > > So checks are required before and after the buffer flips, right? Yes. In a full handshake, the Handshake complete message could be the result of an unwrap (client) or wrap (server). Brad From bradford.wetmore at oracle.com Wed Dec 2 00:04:41 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 1 Dec 2015 16:04:41 -0800 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> Message-ID: <565E3599.3060201@oracle.com> > I just would like to remind that session resumption is a very > important use case to support for ALPN. Understood. The ALPN value is tied to a handshake, either already completed and active (getApplicationProtocol()) or still in progress (getHandshakeApplicationProtocol()). Each handshake results in a complete ALPN negotiation. So a session resumption will always do a ALPN negotiation from scratch. > I have not seen anything related to this review for session resumption. > Has it been tested ? The current unit tests don't have resumption, but there should be a RFE (if not already) for resumption testing along with some other cases. Vinnie is working on these. > It is still not clear to me what a client and a server have to do to > support ALPN. If you want to use the default behavior (server-prioritized list looking for a common element), just call SSLParameters.setApplicationProtocols() on both sides. If you want to do very specific protocol/ciphersuite/alpn configuration before handshaking, then do the configuration before starting the handshake (more details and similar to what you suggested below). This is what was decided back in October when we pulled out the Matcher mechanism in v6/v7. [1] > From my understanding a server has to: > > * read encrypted bytes into a ByteBuffer BTW, during the initial handshake on a connection, these are not encrypted. > * parse the TLS ClientHello frame on its own > * extract from the ClientHello the TLS Protocol version, the ALPN > extension, and the ciphers > * run some logic to determine the AP > ** if no AP can be chosen, generate a TLS Alert frame on its own to > close the connection and bail out I would create a regular SSLContext/SSLEngine/configureALPN and start the handshake as usual. The JSSE implementation will create the TLS ALPN Alert when it realizes it doesn't have any ALPN values in common. The server then should obtain those bytes from the wrap() and send to the peer, as usual. > * otherwise, an AP/cipher combo has been chosen Filling in a few more details: SSLContext.getInstance("protocol"); // returns a context with // "protocol" and possibly // other protocols enabled. SSLEngine ssle = SSLContext.createSSLEngine(...); Read ClientHello from Socket/SocketChannel/AsynchronousSocketChannel/etc. Parse ClientHello for requested protocol/alpn/ciphersuites choose protocol/alpn/ciphersuite value(s) SSLParameters sslParameters = ssle.getSSLParameters(); sslParameters.setProtocols(protocols); // possibly just one // You could use some non-matching value like // "no_application_protocol" if you want to generate the // no_application_protocol alert. sslParameters.setApplicationProtocols(APs); // possibly just one sslParameters.setCipherSuites(ciphers) // possibly just one sslEngine.setSSLParameters(sslParameters) reset the ByteBuffer position to the beginning sslEngine.unwrap() JDK implementation will re-parse the ClientHello, and use the sslParameters data during handshake and when generating the ServerHello. Any error alerts will be output by the SSLEngine as usual. sslEngine.wrap()/unwrap() as usual. > A client has to: > > * read encrypted bytes into a ByteBuffer > * parse a ServerHello frame on its own > * extract the ALPN extension and the cipher You could parse this if you want, but wasn't expecting client apps would. See below. > * run some logic to verify that the AP and the cipher can be used together > ** if AP and cipher don't match, generate a TLS Alert frame on its own > to close the connection and bail out. There is nothing in the ALPN RFC about this situation. In the HTTP spec, if such a situation is negotiated, the application layer waits for the handshake completion, examines the state, sends a HTTP2 connection error of type INADEQUATE_SECURITY, then closes. BTW, we would lose the ability to parse plaintext ServerHellos in TLSv1.3, as ServerHello is now encrypted. > * otherwise the AP/cipher combo is ok > * reset the ByteBuffer position to the beginning > * pass the ByteBuffer to sslEngine.unwrap() > * JDK implementation will re-parse the ServerHello and complete the > TLS handshake > > Is that right ? If you really want to parse it, yes. > In that scenario, what is the use of > SSLEngine.getHandshakeApplicationProtocol() ? When either side needs to determine the selected ALPN value before the completion of the handshake, say during X509KeyManager selection or X509TrustManager verification. On the server side, let's say we have two possible keys/certs, and we receive a ClientHello. ClientHello -> JSSE chooses protocol/ALPN JSSE iterates on ciphersuite iter calls X509KeyManager to find a key X509KM calls setHandshakeApplicationProtocol() to see which protocol/ALPN value was negotiated, uses that for selecting which key to use. <- ServerHello > Also, I don't understand how the above could work for SSLSocket ? > Can someone write down the steps a client and a server should do to > actually use ALPN with SSLSocket ? Server ====== Filing in a few more extra details so it's hopefully clear. Open a plaintext ServerSocket Socket socket = serverSocket.accept(); InputStream is = socket.getInputStream(); byte[] ba = is.readFully(); // extract from the ClientHello the TLS Protocol version, the ALPN // extension, and the ciphers parseTLSClientHello(ba); determineProtocolALPNCiphersuites(); SSLContext ctx = \ SSLContext.getInstance("protocol") // returns a context with // "protocol" and possibly // other protocols enabled. SSLParameters sslParameters = ctx.getDefaultSSLParameters(); SSLParameters sslParameters = sslParameters.setProtocols(protocol); sslParameters.setApplicationProtocols(AP) // just one protocol sslParameters.setCipherSuites(cipher) // just one cipher // Overlay the partially consumed InputStream ByteArrayInputStream bais = new ByteArrayInputStream(ba); SSLSocket sslSocket = \ ctx.createSocketFactory(...).createSocket(socket, bais, ...); sslSocket.setSSLParameters(sslParameters) sslSocket.startHandshake(); Brad [1] http://mail.openjdk.java.net/pipermail/security-dev/2015-October/012912.html From weijun.wang at oracle.com Wed Dec 2 00:51:38 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 08:51:38 +0800 Subject: S4U2Self and OpenJDK 8 In-Reply-To: References: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com> Message-ID: <8B5F8DCA-9550-4AA2-BB87-0BF8837DCB18@oracle.com> > On Dec 2, 2015, at 1:59 AM, Marc Boorshtein wrote: > > Max, > > Closing the loop on this. It turns out that there was an extra step > needed to get the user in freeipa setup as a delegate (the > documentation was written for S4U2Proxy, not S4U2Self). Once I set > that flag delegation started working for BOTH Java 8 and Java 9. Nice to hear this. I'll lower the priority of https://bugs.openjdk.java.net/browse/JDK-8144288 then. --Max > > Thanks again. > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 From xuelei.fan at oracle.com Wed Dec 2 00:55:00 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Dec 2015 08:55:00 +0800 Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently Message-ID: <565E4164.5040103@oracle.com> Hi, Please review the test fix for JDK-8143298: http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/ The root cause of the intermittent test failure is still unclear to me. I updated the test with more output messages, and clear the resources in finally blocks. Hope the update can expose the real cause if it fails again in the future. Thanks, Xuelei From weijun.wang at oracle.com Wed Dec 2 01:05:08 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 09:05:08 +0800 Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently In-Reply-To: <565E4164.5040103@oracle.com> References: <565E4164.5040103@oracle.com> Message-ID: <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com> Socket is a Closeable, so you can try (Socket sock = ....) { ... } If you want more debug messages, why not e.printStackTrace()? Message is enough? Thanks Max > On Dec 2, 2015, at 8:55 AM, Xuelei Fan wrote: > > Hi, > > Please review the test fix for JDK-8143298: > > http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/ > > The root cause of the intermittent test failure is still unclear to me. > I updated the test with more output messages, and clear the resources > in finally blocks. Hope the update can expose the real cause if it > fails again in the future. > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Dec 2 01:12:33 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Dec 2015 09:12:33 +0800 Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently In-Reply-To: <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com> References: <565E4164.5040103@oracle.com> <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com> Message-ID: <565E4581.3050909@oracle.com> On 12/2/2015 9:05 AM, Wang Weijun wrote: > Socket is a Closeable, so you can > > try (Socket sock = ....) { ... } > Yes. Better coding. Updated in the same webrev. > If you want more debug messages, why not e.printStackTrace()? Message is enough? > I was wondering, the cached connection (which may be closed by server thread after the client call) may be the cause. Resource cleanup and message may be enough. Thanks, Xuelei > Thanks > Max > >> On Dec 2, 2015, at 8:55 AM, Xuelei Fan wrote: >> >> Hi, >> >> Please review the test fix for JDK-8143298: >> >> http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/ >> >> The root cause of the intermittent test failure is still unclear to me. >> I updated the test with more output messages, and clear the resources >> in finally blocks. Hope the update can expose the real cause if it >> fails again in the future. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Wed Dec 2 02:20:02 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 10:20:02 +0800 Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently In-Reply-To: <565E4581.3050909@oracle.com> References: <565E4164.5040103@oracle.com> <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com> <565E4581.3050909@oracle.com> Message-ID: <2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com> > On Dec 2, 2015, at 9:12 AM, Xuelei Fan wrote: > > On 12/2/2015 9:05 AM, Wang Weijun wrote: >> Socket is a Closeable, so you can >> >> try (Socket sock = ....) { ... } >> > Yes. Better coding. Updated in the same webrev. Same sslSocket declared twice. Have you compiled the test? You can also do the same with sslServerSocket if you like. > >> If you want more debug messages, why not e.printStackTrace()? Message is enough? >> > I was wondering, the cached connection (which may be closed by server > thread after the client call) may be the cause. Resource cleanup and > message may be enough. Good. Thanks Max > > Thanks, > Xuelei > >> Thanks >> Max >> >>> On Dec 2, 2015, at 8:55 AM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Please review the test fix for JDK-8143298: >>> >>> http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/ >>> >>> The root cause of the intermittent test failure is still unclear to me. >>> I updated the test with more output messages, and clear the resources >>> in finally blocks. Hope the update can expose the real cause if it >>> fails again in the future. >>> >>> Thanks, >>> Xuelei >> > From xuelei.fan at oracle.com Wed Dec 2 02:48:09 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Dec 2015 10:48:09 +0800 Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently In-Reply-To: <2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com> References: <565E4164.5040103@oracle.com> <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com> <565E4581.3050909@oracle.com> <2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com> Message-ID: <565E5BE9.5000205@oracle.com> On 12/2/2015 10:20 AM, Wang Weijun wrote: > >> On Dec 2, 2015, at 9:12 AM, Xuelei Fan wrote: >> >> On 12/2/2015 9:05 AM, Wang Weijun wrote: >>> Socket is a Closeable, so you can >>> >>> try (Socket sock = ....) { ... } >>> >> Yes. Better coding. Updated in the same webrev. > > Same sslSocket declared twice. Have you compiled the test? > Updated. > You can also do the same with sslServerSocket if you like. > I'll leave it as it is. Thanks, Xuelei >> >>> If you want more debug messages, why not e.printStackTrace()? Message is enough? >>> >> I was wondering, the cached connection (which may be closed by server >> thread after the client call) may be the cause. Resource cleanup and >> message may be enough. > > Good. > > Thanks > Max > >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>>> On Dec 2, 2015, at 8:55 AM, Xuelei Fan wrote: >>>> >>>> Hi, >>>> >>>> Please review the test fix for JDK-8143298: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/ >>>> >>>> The root cause of the intermittent test failure is still unclear to me. >>>> I updated the test with more output messages, and clear the resources >>>> in finally blocks. Hope the update can expose the real cause if it >>>> fails again in the future. >>>> >>>> Thanks, >>>> Xuelei >>> >> > From weijun.wang at oracle.com Wed Dec 2 03:04:40 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 11:04:40 +0800 Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently In-Reply-To: <565E5BE9.5000205@oracle.com> References: <565E4164.5040103@oracle.com> <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com> <565E4581.3050909@oracle.com> <2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com> <565E5BE9.5000205@oracle.com> Message-ID: <0613C25A-575D-491A-82C5-9742096A262D@oracle.com> Everything looks fine now. Thanks Max > On Dec 2, 2015, at 10:48 AM, Xuelei Fan wrote: > > On 12/2/2015 10:20 AM, Wang Weijun wrote: >> >>> On Dec 2, 2015, at 9:12 AM, Xuelei Fan wrote: >>> >>> On 12/2/2015 9:05 AM, Wang Weijun wrote: >>>> Socket is a Closeable, so you can >>>> >>>> try (Socket sock = ....) { ... } >>>> >>> Yes. Better coding. Updated in the same webrev. >> >> Same sslSocket declared twice. Have you compiled the test? >> > Updated. > >> You can also do the same with sslServerSocket if you like. >> > I'll leave it as it is. > > Thanks, > Xuelei From chris.hegarty at oracle.com Wed Dec 2 12:08:38 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 12:08:38 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder Message-ID: <565EDF46.2080602@oracle.com> The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ -Chris. From paul.sandoz at oracle.com Wed Dec 2 13:42:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 14:42:14 +0100 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EDF46.2080602@oracle.com> References: <565EDF46.2080602@oracle.com> Message-ID: > On 2 Dec 2015, at 13:08, Chris Hegarty wrote: > > The regression tests in the jdk should be updated, where possible, to use java.util.Base64. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ > +1 Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Wed Dec 2 14:03:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Dec 2015 14:03:01 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EDF46.2080602@oracle.com> References: <565EDF46.2080602@oracle.com> Message-ID: <565EFA15.3050504@oracle.com> On 02/12/2015 12:08, Chris Hegarty wrote: > The regression tests in the jdk should be updated, where possible, to > use java.util.Base64. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ Should S11N be updated to serialize with JDK 8 so that the core reflection code isn't needed? -Alan From chris.hegarty at oracle.com Wed Dec 2 14:15:10 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 14:15:10 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EFA15.3050504@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> Message-ID: <565EFCEE.6010501@oracle.com> On 02/12/15 14:03, Alan Bateman wrote: > > On 02/12/2015 12:08, Chris Hegarty wrote: >> The regression tests in the jdk should be updated, where possible, to >> use java.util.Base64. >> >> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ > Should S11N be updated to serialize with JDK 8 so that the core > reflection code isn't needed? This is certainly possible and would make the test simpler, but I followed the comments in the test ( it needs to be runnable on older JDKs ). I think this is a reasonable requirement since the test contains bytes array that were generated on older JDKs. Of course, the test could contain the older JDK code commented out. If someone really wants to run it with 1.6, then they just make the simple edits. I'm ok with any of these solutions, or just removing the possibility of running on older JDKs. -Chris. From weijun.wang at oracle.com Wed Dec 2 14:36:59 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 22:36:59 +0800 Subject: RFR 8058778: New APIs for some keytool functions Message-ID: Hi All This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do. code changes: http://cr.openjdk.java.net/~weijun/8058778/webrev.04 http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ spec: http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html You will be able to KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); kpg.initialize(2048); KeyPair ca = kpg.generateKeyPair(); KeyPair user = kpg.generateKeyPair(); X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca) .subject(new X500Principal("CN=ca")) .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650))) .addExtension("BasicConstraints", "", true) .signatureAlgorithm("SHA256withRSA") .selfSign(); byte[] request = X509CertificateBuilder.fromKeyPair(user) .subject(new X500Principal("CN=user")) .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true) .request(); X509Certificate userCert = X509CertificateBuilder.asCA( ca.getPrivate(), caCert) .signatureAlgorithm("SHA256withRSA") .honorExtensions("all") .sign(request); Thanks Max From weijun.wang at oracle.com Wed Dec 2 14:52:32 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 22:52:32 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EFCEE.6010501@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> Message-ID: My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. Thanks Max > On Dec 2, 2015, at 10:15 PM, Chris Hegarty wrote: > > On 02/12/15 14:03, Alan Bateman wrote: >> >> On 02/12/2015 12:08, Chris Hegarty wrote: >>> The regression tests in the jdk should be updated, where possible, to >>> use java.util.Base64. >>> >>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >> Should S11N be updated to serialize with JDK 8 so that the core >> reflection code isn't needed? > > This is certainly possible and would make the test simpler, but > I followed the comments in the test ( it needs to be runnable on > older JDKs ). I think this is a reasonable requirement since the > test contains bytes array that were generated on older JDKs. Of > course, the test could contain the older JDK code commented out. > If someone really wants to run it with 1.6, then they just make > the simple edits. > > I'm ok with any of these solutions, or just removing the possibility > of running on older JDKs. > > -Chris. From chris.hegarty at oracle.com Wed Dec 2 15:03:42 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 15:03:42 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EFCEE.6010501@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> Message-ID: <565F084E.505@oracle.com> Updated to remove all use of reflection. If someone really wants to run S11N on an older JDK, then it is a simple edit to uncomment/comment 3 lines. http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ -Chris. On 02/12/15 14:15, Chris Hegarty wrote: > On 02/12/15 14:03, Alan Bateman wrote: >> >> On 02/12/2015 12:08, Chris Hegarty wrote: >>> The regression tests in the jdk should be updated, where possible, to >>> use java.util.Base64. >>> >>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >> Should S11N be updated to serialize with JDK 8 so that the core >> reflection code isn't needed? > > This is certainly possible and would make the test simpler, but > I followed the comments in the test ( it needs to be runnable on > older JDKs ). I think this is a reasonable requirement since the > test contains bytes array that were generated on older JDKs. Of > course, the test could contain the older JDK code commented out. > If someone really wants to run it with 1.6, then they just make > the simple edits. > > I'm ok with any of these solutions, or just removing the possibility > of running on older JDKs. > > -Chris. From weijun.wang at oracle.com Wed Dec 2 15:13:47 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 23:13:47 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> Message-ID: <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> > On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: > > My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. > > Thanks > Max -------------- next part -------------- A non-text attachment was scrubbed... Name: S11N.java Type: application/octet-stream Size: 14102 bytes Desc: not available URL: From chris.hegarty at oracle.com Wed Dec 2 15:26:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 15:26:07 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> Message-ID: <565F0D8F.2070103@oracle.com> Thanks Max, I'm ok with this version, if you are. I'll include it in the final push. -Chris. On 02/12/15 15:13, Wang Weijun wrote: > >> On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: >> >> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. >> >> Thanks >> Max From weijun.wang at oracle.com Wed Dec 2 15:34:02 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 23:34:02 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565F0D8F.2070103@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> <565F0D8F.2070103@oracle.com> Message-ID: > On Dec 2, 2015, at 11:26 PM, Chris Hegarty wrote: > > Thanks Max, > > I'm ok with this version, if you are. I'll include it in the final push. Please. --Max > > -Chris. > > On 02/12/15 15:13, Wang Weijun wrote: >> >>> On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: >>> >>> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. >>> >>> Thanks >>> Max From Alan.Bateman at oracle.com Wed Dec 2 17:04:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Dec 2015 17:04:58 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565F0D8F.2070103@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> <565F0D8F.2070103@oracle.com> Message-ID: <565F24BA.3000905@oracle.com> On 02/12/2015 15:26, Chris Hegarty wrote: > Thanks Max, > > I'm ok with this version, if you are. I'll include it in the final push. > This version looks okay to me too. -Alan. From mandy.chung at oracle.com Wed Dec 2 18:38:11 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Dec 2015 10:38:11 -0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: Message-ID: Hi Max, Is there any reason why this X509CertificateBuilder can?t be Java SE API? Have you considered defining this builder API in java.security.cert.X509Certificate.Builder? Mandy > On Dec 2, 2015, at 6:36 AM, Wang Weijun wrote: > > Hi All > > This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do. > > code changes: > > http://cr.openjdk.java.net/~weijun/8058778/webrev.04 > http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ > > spec: > > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html > > You will be able to > > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); > kpg.initialize(2048); > KeyPair ca = kpg.generateKeyPair(); > KeyPair user = kpg.generateKeyPair(); > > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca) > .subject(new X500Principal("CN=ca")) > .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650))) > .addExtension("BasicConstraints", "", true) > .signatureAlgorithm("SHA256withRSA") > .selfSign(); > > byte[] request = X509CertificateBuilder.fromKeyPair(user) > .subject(new X500Principal("CN=user")) > .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true) > .request(); > > X509Certificate userCert = X509CertificateBuilder.asCA( > ca.getPrivate(), caCert) > .signatureAlgorithm("SHA256withRSA") > .honorExtensions("all") > .sign(request); > > Thanks > Max > From larry.mccay at gmail.com Wed Dec 2 20:11:54 2015 From: larry.mccay at gmail.com (larry mccay) Date: Wed, 2 Dec 2015 15:11:54 -0500 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: Message-ID: Hi Max - Happy to see this enhancement - it would be great if it made its way into SE and other JVM implementations as a result! If not, what would the added dependency be for consuming applications? thanks, --larry On Wed, Dec 2, 2015 at 1:38 PM, Mandy Chung wrote: > Hi Max, > > Is there any reason why this X509CertificateBuilder can?t be Java SE API? > Have you considered defining this builder API in > java.security.cert.X509Certificate.Builder? > > Mandy > > > On Dec 2, 2015, at 6:36 AM, Wang Weijun wrote: > > > > Hi All > > > > This enhancement creates a new jdk.security.cert.X509CertificateBuilder > API that does what keytool -genkeypair/-certreq/-gencert can do. > > > > code changes: > > > > http://cr.openjdk.java.net/~weijun/8058778/webrev.04 > > http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ > > > > spec: > > > > > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html > > > > You will be able to > > > > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); > > kpg.initialize(2048); > > KeyPair ca = kpg.generateKeyPair(); > > KeyPair user = kpg.generateKeyPair(); > > > > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca) > > .subject(new X500Principal("CN=ca")) > > .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650))) > > .addExtension("BasicConstraints", "", true) > > .signatureAlgorithm("SHA256withRSA") > > .selfSign(); > > > > byte[] request = X509CertificateBuilder.fromKeyPair(user) > > .subject(new X500Principal("CN=user")) > > .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true) > > .request(); > > > > X509Certificate userCert = X509CertificateBuilder.asCA( > > ca.getPrivate(), caCert) > > .signatureAlgorithm("SHA256withRSA") > > .honorExtensions("all") > > .sign(request); > > > > Thanks > > Max > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Dec 3 01:25:07 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 3 Dec 2015 09:25:07 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: Message-ID: > On Dec 3, 2015, at 2:38 AM, Mandy Chung wrote: > > Hi Max, > > Is there any reason why this X509CertificateBuilder can?t be Java SE API? Well, not much. When we first design the new API, it was meant to be a quick alternative to sun.security.tools.keytool.Main since that class will be invisible after jigsaw. So it's just a simple utility class and not fine polished. One unpolished is the certificate request. It's now just a byte[]. We might need a base class CertificateRequest and a child X509CertificateRequest and some getters. Another is the addExtension() method [1] that takes string values. Although I've tried my best to specify the precise format [1] I still think it's not mature enough as a Java SE API. Maybe I should just keep the addExtension(Extension) one [3] and create static methods in Extension (or shall I create a child named X509Extension) that generates known/unknown extension objects. Maybe my understanding is biased, but when I am thinking of a Java SE API, it contains multiple classes and a clean structure. On the other hand, a JDK-specific tool can be a huge single class with every method inside (just like keytool itself). > Have you considered defining this builder API in java.security.cert.X509Certificate.Builder? That sounds like a good place. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.lang.String-java.lang.String-boolean- [2] http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#extensions [3] http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.security.cert.Extension- > > Mandy > >> On Dec 2, 2015, at 6:36 AM, Wang Weijun wrote: >> >> Hi All >> >> This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do. >> >> code changes: >> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.04 >> http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ >> >> spec: >> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html >> >> You will be able to >> >> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); >> kpg.initialize(2048); >> KeyPair ca = kpg.generateKeyPair(); >> KeyPair user = kpg.generateKeyPair(); >> >> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca) >> .subject(new X500Principal("CN=ca")) >> .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650))) >> .addExtension("BasicConstraints", "", true) >> .signatureAlgorithm("SHA256withRSA") >> .selfSign(); >> >> byte[] request = X509CertificateBuilder.fromKeyPair(user) >> .subject(new X500Principal("CN=user")) >> .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true) >> .request(); >> >> X509Certificate userCert = X509CertificateBuilder.asCA( >> ca.getPrivate(), caCert) >> .signatureAlgorithm("SHA256withRSA") >> .honorExtensions("all") >> .sign(request); >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Dec 3 01:27:49 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 3 Dec 2015 09:27:49 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: Message-ID: <6CC644EB-E5EE-48CA-9748-38449B5D48AF@oracle.com> > On Dec 3, 2015, at 4:11 AM, larry mccay wrote: > > Hi Max - > > Happy to see this enhancement - it would be great if it made its way into SE and other JVM implementations as a result! I replied to Mandy's mail. > > If not, what would the added dependency be for consuming applications? They will need the jdk.security.cert module. It will be in JRE (I added it into boot.modules) but if you want to create your own runtime you will need to add it using jimage or jlink things. (I am not a module expert but you know it). Thanks Max > > thanks, > > --larry > > On Wed, Dec 2, 2015 at 1:38 PM, Mandy Chung wrote: > Hi Max, > > Is there any reason why this X509CertificateBuilder can?t be Java SE API? Have you considered defining this builder API in java.security.cert.X509Certificate.Builder? > > Mandy > > > On Dec 2, 2015, at 6:36 AM, Wang Weijun wrote: > > > > Hi All > > > > This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do. > > > > code changes: > > > > http://cr.openjdk.java.net/~weijun/8058778/webrev.04 > > http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ > > > > spec: > > > > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html > > > > You will be able to > > > > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); > > kpg.initialize(2048); > > KeyPair ca = kpg.generateKeyPair(); > > KeyPair user = kpg.generateKeyPair(); > > > > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca) > > .subject(new X500Principal("CN=ca")) > > .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650))) > > .addExtension("BasicConstraints", "", true) > > .signatureAlgorithm("SHA256withRSA") > > .selfSign(); > > > > byte[] request = X509CertificateBuilder.fromKeyPair(user) > > .subject(new X500Principal("CN=user")) > > .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true) > > .request(); > > > > X509Certificate userCert = X509CertificateBuilder.asCA( > > ca.getPrivate(), caCert) > > .signatureAlgorithm("SHA256withRSA") > > .honorExtensions("all") > > .sign(request); > > > > Thanks > > Max > > > > From larry.mccay at gmail.com Thu Dec 3 02:43:10 2015 From: larry.mccay at gmail.com (larry mccay) Date: Wed, 2 Dec 2015 21:43:10 -0500 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: Message-ID: Applications that depend on such APIs are currently jumping through hoops to provide the same functionality on multiple JVMs. We have some nasty reflection based code in order to deal with build-time dependencies. It really should be formalized and made part of the SE API. It will be great that I can not worry about the new API going away in openJDK and oracle - but I'll need to continue to use the reflection because of IBM. Baby steps, maybe? On Wed, Dec 2, 2015 at 8:25 PM, Wang Weijun wrote: > > > On Dec 3, 2015, at 2:38 AM, Mandy Chung wrote: > > > > Hi Max, > > > > Is there any reason why this X509CertificateBuilder can?t be Java SE API? > > Well, not much. > > When we first design the new API, it was meant to be a quick alternative > to sun.security.tools.keytool.Main since that class will be invisible after > jigsaw. So it's just a simple utility class and not fine polished. > > One unpolished is the certificate request. It's now just a byte[]. We > might need a base class CertificateRequest and a child > X509CertificateRequest and some getters. > > Another is the addExtension() method [1] that takes string values. > Although I've tried my best to specify the precise format [1] I still think > it's not mature enough as a Java SE API. Maybe I should just keep the > addExtension(Extension) one [3] and create static methods in Extension (or > shall I create a child named X509Extension) that generates known/unknown > extension objects. > > Maybe my understanding is biased, but when I am thinking of a Java SE API, > it contains multiple classes and a clean structure. On the other hand, a > JDK-specific tool can be a huge single class with every method inside (just > like keytool itself). > > > Have you considered defining this builder API in > java.security.cert.X509Certificate.Builder? > > That sounds like a good place. > > Thanks > Max > > [1] > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.lang.String-java.lang.String-boolean- > > [2] > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#extensions > > [3] > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.security.cert.Extension- > > > > > Mandy > > > >> On Dec 2, 2015, at 6:36 AM, Wang Weijun wrote: > >> > >> Hi All > >> > >> This enhancement creates a new jdk.security.cert.X509CertificateBuilder > API that does what keytool -genkeypair/-certreq/-gencert can do. > >> > >> code changes: > >> > >> http://cr.openjdk.java.net/~weijun/8058778/webrev.04 > >> http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ > >> > >> spec: > >> > >> > http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html > >> > >> You will be able to > >> > >> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); > >> kpg.initialize(2048); > >> KeyPair ca = kpg.generateKeyPair(); > >> KeyPair user = kpg.generateKeyPair(); > >> > >> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca) > >> .subject(new X500Principal("CN=ca")) > >> .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650))) > >> .addExtension("BasicConstraints", "", true) > >> .signatureAlgorithm("SHA256withRSA") > >> .selfSign(); > >> > >> byte[] request = X509CertificateBuilder.fromKeyPair(user) > >> .subject(new X500Principal("CN=user")) > >> .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true) > >> .request(); > >> > >> X509Certificate userCert = X509CertificateBuilder.asCA( > >> ca.getPrivate(), caCert) > >> .signatureAlgorithm("SHA256withRSA") > >> .honorExtensions("all") > >> .sign(request); > >> > >> Thanks > >> Max > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Thu Dec 3 05:24:34 2015 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Dec 2015 13:24:34 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565F084E.505@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <565F084E.505@oracle.com> Message-ID: <565FD212.5070505@oracle.com> (I'm not a reviewer) Just a minor question. jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. Missed? or justbecause this test will be totally removed soon in a separate bugid? Thanks, Amy On 12/2/15 11:03 PM, Chris Hegarty wrote: > Updated to remove all use of reflection. If someone really > wants to run S11N on an older JDK, then it is a simple > edit to uncomment/comment 3 lines. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ > > -Chris. > > On 02/12/15 14:15, Chris Hegarty wrote: >> On 02/12/15 14:03, Alan Bateman wrote: >>> >>> On 02/12/2015 12:08, Chris Hegarty wrote: >>>> The regression tests in the jdk should be updated, where possible, to >>>> use java.util.Base64. >>>> >>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >>> Should S11N be updated to serialize with JDK 8 so that the core >>> reflection code isn't needed? >> >> This is certainly possible and would make the test simpler, but >> I followed the comments in the test ( it needs to be runnable on >> older JDKs ). I think this is a reasonable requirement since the >> test contains bytes array that were generated on older JDKs. Of >> course, the test could contain the older JDK code commented out. >> If someone really wants to run it with 1.6, then they just make >> the simple edits. >> >> I'm ok with any of these solutions, or just removing the possibility >> of running on older JDKs. >> >> -Chris. From weijun.wang at oracle.com Thu Dec 3 08:31:00 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 3 Dec 2015 16:31:00 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: Message-ID: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> I tried. It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better. Extension --------- Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension: static Extension newExtension(String oid, byte[] content, boolean isCritical); static Extension newExtension(String oid, String value, boolean isCritical); The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say, static final String KEYUSAGE = "2.5.29.16". The "for example" comment of getExtensionValue() will be gone. CertificateRequest ------------------ A new CertificateRequest will be added which looks a lot like Certificate, it will have String getType(); byte[] getEncoded(); PublicKey getPublicKey(); and serialization but no verify(). It is always self-signed so the constructor can verify. It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have byte[] getCertificationRequestInfo; X500Principal getSubjectX500Principal(); byte[] getSignature(); String getSigAlgName(); String getSigAlgOID(); byte[] getSigAlgParams(); int getVersion(); (Or maybe not all getSigXXX() methods?) CertificateFactory should have a new method CertificateRequest generateCertificateRequest(InputStream) and CertificateFactorySpi needs a corresponding engine method throwing UOE. The X509Factory implementation will read it. All these sound straightforward, worth doing? Thanks Max From larry.mccay at gmail.com Thu Dec 3 12:21:21 2015 From: larry.mccay at gmail.com (larry mccay) Date: Thu, 3 Dec 2015 07:21:21 -0500 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> Message-ID: +1 :) On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun wrote: > I tried. > > It's quite easy to move the new X509CertificateBuilder class into > java.security.cert.X509Certificate as an inner class, but I still want to > make Extension and CertificateRequest better. > > Extension > --------- > > Turns out java.security.cert.Extension is already defined for X.509, and > there exists an X509Extension class in the same package (which should have > been named SomethingHasX509Extensions). In case one day we want to define > an extension for non-X.509 certs, I would still like to add static methods > into X509Extension that returns an Extension: > > static Extension newExtension(String oid, byte[] content, boolean > isCritical); > static Extension newExtension(String oid, String value, boolean > isCritical); > > The string-value version will also use oid as name since OID is the only > language used in methods of Extension and X509Extension. Constants will be > defined in X509Extension for known OIDs, say, > > static final String KEYUSAGE = "2.5.29.16". > > The "for example" comment of getExtensionValue() will be gone. > > CertificateRequest > ------------------ > > A new CertificateRequest will be added which looks a lot like Certificate, > it will have > > String getType(); > byte[] getEncoded(); > PublicKey getPublicKey(); > > and serialization but no verify(). It is always self-signed so the > constructor can verify. > > It will have a child X509CertificateRequest which looks a lot like > X509Certificate which even implements X509Extension. It will have > > byte[] getCertificationRequestInfo; > X500Principal getSubjectX500Principal(); > byte[] getSignature(); > String getSigAlgName(); > String getSigAlgOID(); > byte[] getSigAlgParams(); > int getVersion(); > > (Or maybe not all getSigXXX() methods?) > > CertificateFactory should have a new method > > CertificateRequest generateCertificateRequest(InputStream) > > and CertificateFactorySpi needs a corresponding engine method throwing UOE. > > The X509Factory implementation will read it. > > > All these sound straightforward, worth doing? > > Thanks > Max > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Thu Dec 3 14:10:46 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 3 Dec 2015 17:10:46 +0300 Subject: [9] RFR: 8140470: javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed with java.security.AccessControlException Message-ID: <56604D66.5050603@oracle.com> Hello, Please review this small fix which updates XMLDSigWithSecMgr.java test to extend the default security policy instead of override. Please see details here: https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873347 The test could use "@run main/othervm/java.security.policy" action, but sometimes it may be better to enable a security manager during test execution to avoid granting many additional permissions if a test requires some setup. I tried to set "java.security.policy" system property just before enabling a security manager, and it seems to work fine. Bug: https://bugs.openjdk.java.net/browse/JDK-8140470 Webrev: http://cr.openjdk.java.net/~asmotrak/8140470/webrev.00/ Artem From artem.smotrakov at oracle.com Thu Dec 3 14:18:20 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 3 Dec 2015 17:18:20 +0300 Subject: [9] RFR: 8140470: javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed with java.security.AccessControlException In-Reply-To: <56604D66.5050603@oracle.com> References: <56604D66.5050603@oracle.com> Message-ID: <56604F2C.6000401@oracle.com> I sent a wrong version of webrev, please use the following one http://cr.openjdk.java.net/~asmotrak/8140470/webrev.01/ Artem On 12/03/2015 05:10 PM, Artem Smotrakov wrote: > Hello, > > Please review this small fix which updates XMLDSigWithSecMgr.java test > to extend the default security policy instead of override. Please see > details here: > > https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873347 > > > The test could use "@run main/othervm/java.security.policy" action, > but sometimes it may be better to enable a security manager during > test execution to avoid granting many additional permissions if a test > requires some setup. I tried to set "java.security.policy" system > property just before enabling a security manager, and it seems to work > fine. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140470 > Webrev: http://cr.openjdk.java.net/~asmotrak/8140470/webrev.00/ > > Artem From sean.coffey at oracle.com Thu Dec 3 18:38:55 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 3 Dec 2015 18:38:55 +0000 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests In-Reply-To: <565E30F7.5060307@oracle.com> References: <565E30F7.5060307@oracle.com> Message-ID: <56608C3F.20600@oracle.com> Hey Tony, looks like a fix that could come back to jdk8u-dev at some stage. Thanks for taking this one on. Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. Would you agree that JDK-8058455 could be closed out as a duplicate ? Regards, Sean. On 01/12/2015 23:44, Anthony Scarpino wrote: > Hi all, > > I'd like a review of this change. It improves nextBytes() performance > by allowing the random buffer to grow and shrink as random data is > needed and remove the high level synchronization. Also disable > SecureRandom for Solaris PKCS11 as it's not as fast as native. > > http://cr.openjdk.java.net/~ascarpino/8098581/webrev/ > > Thanks > > Tony From anthony.scarpino at oracle.com Thu Dec 3 19:04:37 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 3 Dec 2015 11:04:37 -0800 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests In-Reply-To: <56608C3F.20600@oracle.com> References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com> Message-ID: <972A41CE-5541-4980-AC7F-25A126AD53D1@oracle.com> Hi Sean, Yes on both counts. There should be no problem backporting and 8058455 can be a duplicate. Tony > On Dec 3, 2015, at 10:38 AM, Se?n Coffey wrote: > > Hey Tony, > > looks like a fix that could come back to jdk8u-dev at some stage. Thanks for taking this one on. > > Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. Would you agree that JDK-8058455 could be closed out as a duplicate ? > > Regards, > Sean. > >> On 01/12/2015 23:44, Anthony Scarpino wrote: >> Hi all, >> >> I'd like a review of this change. It improves nextBytes() performance by allowing the random buffer to grow and shrink as random data is needed and remove the high level synchronization. Also disable SecureRandom for Solaris PKCS11 as it's not as fast as native. >> >> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/ >> >> Thanks >> >> Tony > From mstjohns at comcast.net Thu Dec 3 19:10:50 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Thu, 3 Dec 2015 14:10:50 -0500 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests In-Reply-To: <56608C3F.20600@oracle.com> References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com> Message-ID: <566093BA.5020802@comcast.net> The more I look at this the less I'm comfortable with the change to non-synchronized. In general, there shouldn't be a need for a large amount of random data, especially not between multiple threads, so I'm not too sure the performance argument holds. What I do worry about is a provider that's not particularly smart about how it does things offering up data and not updating internal pointers in a synchronized manner resulting in the possibility of the same "random" data being served to multiple requestors. I think placing the synchronization at the glue class may be a better choice than depending on each and every provider doing the right thing. Just a thought - Mike On 12/3/2015 1:38 PM, Se?n Coffey wrote: > Hey Tony, > > looks like a fix that could come back to jdk8u-dev at some stage. > Thanks for taking this one on. > > Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. > Would you agree that JDK-8058455 could be closed out as a duplicate ? > > Regards, > Sean. > > On 01/12/2015 23:44, Anthony Scarpino wrote: >> Hi all, >> >> I'd like a review of this change. It improves nextBytes() >> performance by allowing the random buffer to grow and shrink as >> random data is needed and remove the high level synchronization. Also >> disable SecureRandom for Solaris PKCS11 as it's not as fast as native. >> >> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/ >> >> Thanks >> >> Tony > > From ecki at zusammenkunft.net Thu Dec 3 22:40:17 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 3 Dec 2015 23:40:17 +0100 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests In-Reply-To: <566093BA.5020802@comcast.net> References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com> <566093BA.5020802@comcast.net> Message-ID: <86984dc4-d32e-4f02-8878-66086cb4bf88.maildroid@localhost> Hello, That buffer sizing/expiring is a bit strange (the dynmic version stranger than the old one), I do not understand the need for it. The requests should not varry so much in size. Just reading something like 64bytes at a time (possibly nonblocking) should be fine. No need to look at the age of that buffer... A cool implementation would be an actual single periodic refresher thread which does not block reading (until buffer is empty)... but that might change the semantic a bit (and could be better used with the new DRNG api for block-free reseeding). Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Mike StJohns To: security-dev at openjdk.java.net Sent: Do., 03 Dez. 2015 21:22 Subject: Re: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests The more I look at this the less I'm comfortable with the change to non-synchronized. In general, there shouldn't be a need for a large amount of random data, especially not between multiple threads, so I'm not too sure the performance argument holds. What I do worry about is a provider that's not particularly smart about how it does things offering up data and not updating internal pointers in a synchronized manner resulting in the possibility of the same "random" data being served to multiple requestors. I think placing the synchronization at the glue class may be a better choice than depending on each and every provider doing the right thing. Just a thought - Mike On 12/3/2015 1:38 PM, Se?n Coffey wrote: > Hey Tony, > > looks like a fix that could come back to jdk8u-dev at some stage. > Thanks for taking this one on. > > Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. > Would you agree that JDK-8058455 could be closed out as a duplicate ? > > Regards, > Sean. > > On 01/12/2015 23:44, Anthony Scarpino wrote: >> Hi all, >> >> I'd like a review of this change. It improves nextBytes() >> performance by allowing the random buffer to grow and shrink as >> random data is needed and remove the high level synchronization. Also >> disable SecureRandom for Solaris PKCS11 as it's not as fast as native. >> >> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/ >> >> Thanks >> >> Tony > > From weijun.wang at oracle.com Fri Dec 4 02:07:41 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 4 Dec 2015 10:07:41 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> Message-ID: <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com> Or if this is too much, we can at least do the X509Extension part. If CertificateRequest is needed one day, we can create a new method Builder.certificateRequest() that returns it and deprecate the current request() method. Or use certificateRequest() to return byte[] and save request() for the future. :-) --Max > On Dec 3, 2015, at 8:21 PM, larry mccay wrote: > > +1 :) > > On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun wrote: > I tried. > > It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better. ... > > All these sound straightforward, worth doing? > > Thanks > Max > > > From xuelei.fan at oracle.com Fri Dec 4 14:41:53 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 4 Dec 2015 22:41:53 +0800 Subject: Code Review Request 8141703, Test B6216082.java failed with operation timed out exception Message-ID: <5661A631.4000300@oracle.com> Hi, Please review the test update for JDK-8141703: http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/ The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java, need to start a server and proxy, and then make https connection over them. It is noticed that the test fails intermittent. The cause may be that in rush platform, the target proxy and server may be not ready before the client call. Maybe not worthy a fix, as the update need to re-org a lot of code and related classes. I plan to add the intermittent keyword to the test case, as the code in the webrev. Thanks, Xuelei From anthony.scarpino at oracle.com Fri Dec 4 19:14:53 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 4 Dec 2015 11:14:53 -0800 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests In-Reply-To: <566093BA.5020802@comcast.net> References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com> <566093BA.5020802@comcast.net> Message-ID: <5661E62D.2070303@oracle.com> On 12/03/2015 11:10 AM, Mike StJohns wrote: > The more I look at this the less I'm comfortable with the change to > non-synchronized. > > In general, there shouldn't be a need for a large amount of random data, > especially not between multiple threads, so I'm not too sure the > performance argument holds. End to End testing on Solaris using WebLogic showed up ~20% faster page response times with this fix. Profiling using JFR showed nextBytes() is a hot lock as the threads queued up wait to get random data. A microbenchmark showed 3x better performance after the change. It makes sense to have locking in the provider to protect against duplicate random data. Synchronizing at the public API level of nextBytes(), is like having a synchronized Cipher.init(), it is way to high and impractical. > What I do worry about is a provider that's not particularly smart about > how it does things offering up data and not updating internal pointers > in a synchronized manner resulting in the possibility of the same > "random" data being served to multiple requestors. I had that about that concern too. There is no mention of a threaded guarantee by nextBytes() or SecureRandom in the documentation and I don't believe 'synchronized' is part of the public API that we are held to. If we don't do this change because of the possibility someone's poor design, the only remedy I see is deprecating nextBytes() and replacing it with a new method. To me, while that may be the safest move, that seems like a drastic step for the possibility of a poorly design. > I think placing the > synchronization at the glue class may be a better choice than depending > on each and every provider doing the right thing. I don't see how inserting a new class into this resolves the problem? The lock encompasses the whole getting of random numbers. Tony > > Just a thought - Mike > > > > On 12/3/2015 1:38 PM, Se?n Coffey wrote: >> Hey Tony, >> >> looks like a fix that could come back to jdk8u-dev at some stage. >> Thanks for taking this one on. >> >> Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. >> Would you agree that JDK-8058455 could be closed out as a duplicate ? >> >> Regards, >> Sean. >> >> On 01/12/2015 23:44, Anthony Scarpino wrote: >>> Hi all, >>> >>> I'd like a review of this change. It improves nextBytes() >>> performance by allowing the random buffer to grow and shrink as >>> random data is needed and remove the high level synchronization. Also >>> disable SecureRandom for Solaris PKCS11 as it's not as fast as native. >>> >>> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/ >>> >>> Thanks >>> >>> Tony >> >> > From anthony.scarpino at oracle.com Fri Dec 4 20:12:31 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 4 Dec 2015 12:12:31 -0800 Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests In-Reply-To: <86984dc4-d32e-4f02-8878-66086cb4bf88.maildroid@localhost> References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com> <566093BA.5020802@comcast.net> <86984dc4-d32e-4f02-8878-66086cb4bf88.maildroid@localhost> Message-ID: <5661F3AF.5040809@oracle.com> On 12/03/2015 02:40 PM, ecki at zusammenkunft.net wrote: > Hello, > > That buffer sizing/expiring is a bit strange (the dynmic version > stranger than the old one), I do not understand the need for it. The > requests should not varry so much in size. Just reading something > like 64bytes at a time (possibly nonblocking) should be fine. No need > to look at the age of that buffer... Admittedly I'm keeping the buffer expiring only for the possibility someone could watch the array to predict what an application could receive in random data. I have no proof this can happen, but I have to assume that was a concern given it was its original designed. If I could be sure that was not a concern, I'd eliminate it. In cases where a large amount of random data was needed from many threads, like the end to end TLS perf testing, the larger buffer size eliminated the overheads of reading the device. The dynamic nature of the buffer size was that I didn't feel it was best for java to consume so many random bytes, like 64K worth, if the application only consumed a few at intervals that were just beyond the expiration time. Therefore I ended up with this, a dynamic buffer that could grow and shrink as needed. > > A cool implementation would be an actual single periodic refresher > thread which does not block reading (until buffer is empty)... but > that might change the semantic a bit (and could be better used with > the new DRNG api for block-free reseeding). The locking was a big thing here. For example, in NativePRNG.implNextBytes() the cost of copying the array and doing the xor outside the the synchronized block was quicker for multithreaded performance than not doing the copy and xor'ing inside the synchronized block. I had thought about a refresher thread, but I felt the more threads competing for the buffer would make it worse. > > Bernd > From mstjohns at comcast.net Sat Dec 5 20:43:23 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Sat, 5 Dec 2015 15:43:23 -0500 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> Message-ID: <56634C6B.4000106@comcast.net> Hi Max - This comes under the heading of meta issues. There are at least two forms of certificate request - PKCS10 (RFC2986) and CRMF (RFC4211). There may be others (not sure that SCEP is a request per se vs a protocol). Both generate requests for X509 certificates so you can't differentiate on that basis. So how do you wire this together to allow either/both to be provided by providers? For the "getSigXXX" methods - maybe define a "PKISignature" class with those methods instead? Have it package: signature value, signature algorithm, params and ideally "keyid" (to identify the public key necessary to verify this signature). Lastly, there are a number of certificates that use only the SubjectAltName extension as their name. You can end up with an empty X500Principal in the request in that case. And you probably want a way of getting any request attributes: Collection getRequestAttributes(); Mike On 12/3/2015 3:31 AM, Wang Weijun wrote: > I tried. > > It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better. > > Extension > --------- > > Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension: > > static Extension newExtension(String oid, byte[] content, boolean isCritical); > static Extension newExtension(String oid, String value, boolean isCritical); > > The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say, > > static final String KEYUSAGE = "2.5.29.16". > > The "for example" comment of getExtensionValue() will be gone. > > CertificateRequest > ------------------ > > A new CertificateRequest will be added which looks a lot like Certificate, it will have > > String getType(); > byte[] getEncoded(); > PublicKey getPublicKey(); > > and serialization but no verify(). It is always self-signed so the constructor can verify. > > It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have > > byte[] getCertificationRequestInfo; > X500Principal getSubjectX500Principal(); > byte[] getSignature(); > String getSigAlgName(); > String getSigAlgOID(); > byte[] getSigAlgParams(); > int getVersion(); > > (Or maybe not all getSigXXX() methods?) > > CertificateFactory should have a new method > > CertificateRequest generateCertificateRequest(InputStream) > > and CertificateFactorySpi needs a corresponding engine method throwing UOE. > > The X509Factory implementation will read it. > > > All these sound straightforward, worth doing? > > Thanks > Max > > > From xuelei.fan at oracle.com Sun Dec 6 00:03:50 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 6 Dec 2015 08:03:50 +0800 Subject: Code Review Request, 8141651 Deadlock in sun.security.ssl.SSLSocketImpl Message-ID: <56637B66.10705@oracle.com> Hi, Please review the fix for JDK-8141651: http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/ In JDK 9, there is a deadlock introduced. One thread can lock SSLSocketImpl instance, and try to lock SSLSocketImpl.writeLock; Another thread may lock SSLSocketImpl.writeLock, and then try to lock SSLSocketImpl instance. A deadlock happens. This fix is trying to remove the latter lock sequence. No new regression test as it is hard to re-produce the issue. Thanks, Xuelei From xuelei.fan at oracle.com Sun Dec 6 12:32:19 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 6 Dec 2015 20:32:19 +0800 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension Message-ID: <56642AD3.6010904@oracle.com> Hi, Please review the update for JDK-8144566: http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ For HttpsURLConnection, the server name may be set after the TLS connection and handshake has been initialized. As may result in that the server name does not present at TLS ClientHello messages. This fix resets the server name for the initialized handshake for above cases. Thanks, Xuelei From xuelei.fan at oracle.com Mon Dec 7 02:52:50 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Dec 2015 10:52:50 +0800 Subject: Code Review Request 8141593 Test RetryHttps timed out intermittently Message-ID: <5664F482.7010600@oracle.com> Hi Weijun, Are you available review this patch for JDK-8141593? http://cr.openjdk.java.net/~xuelei/8141593/webrev.00/ Test RetryHttps.java timed out intermittently, and the exception looks weird to me: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message Looks like there is something wrong of the underlying SSL/TLS handshaking. But I'm not sure of the root cause yet. As this issue happens intermittently, I cannot reproduce it and make further evaluation. This is not a fix actually. I just enable the JSSE debug in the test. Hope next failure, the debug log can be helpful. Thanks, Xuelei From weijun.wang at oracle.com Mon Dec 7 03:31:24 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Dec 2015 11:31:24 +0800 Subject: Code Review Request 8141593 Test RetryHttps timed out intermittently In-Reply-To: <5664F482.7010600@oracle.com> References: <5664F482.7010600@oracle.com> Message-ID: Change looks fine. Best luck. Thanks Max > On Dec 7, 2015, at 10:52 AM, Xuelei Fan wrote: > > Hi Weijun, > > Are you available review this patch for JDK-8141593? > > http://cr.openjdk.java.net/~xuelei/8141593/webrev.00/ > > Test RetryHttps.java timed out intermittently, and the exception looks > weird to me: > > javax.net.ssl.SSLException: Unsupported or unrecognized SSL message > > Looks like there is something wrong of the underlying SSL/TLS > handshaking. But I'm not sure of the root cause yet. As this issue > happens intermittently, I cannot reproduce it and make further evaluation. > > This is not a fix actually. I just enable the JSSE debug in the test. > Hope next failure, the debug log can be helpful. > > Thanks, > Xuelei From weijun.wang at oracle.com Mon Dec 7 03:51:21 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Dec 2015 11:51:21 +0800 Subject: RFR 8138638: Security tests using jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with OutOfMemoryError Message-ID: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8138638/webrev.00/ It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request. Thanks Max From weijun.wang at oracle.com Mon Dec 7 03:56:48 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Dec 2015 11:56:48 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: <56634C6B.4000106@comcast.net> References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> <56634C6B.4000106@comcast.net> Message-ID: > On Dec 6, 2015, at 4:43 AM, Mike StJohns wrote: > > Hi Max - > > This comes under the heading of meta issues. There are at least two forms of certificate request - PKCS10 (RFC2986) and CRMF (RFC4211). There may be others (not sure that SCEP is a request per se vs a protocol). I can change to request(type). Or we can keep the one without an argument which means always-pkcs10. > > Both generate requests for X509 certificates so you can't differentiate on that basis. So how do you wire this together to allow either/both to be provided by providers? This Builder class is not a JCA engine, i.e. no Builder.getInstance(). > > For the "getSigXXX" methods - maybe define a "PKISignature" class with those methods instead? Have it package: signature value, signature algorithm, params and ideally "keyid" (to identify the public key necessary to verify this signature). Can we add these methods later? > > Lastly, there are a number of certificates that use only the SubjectAltName extension as their name. You can end up with an empty X500Principal in the request in that case. And you probably want a way of getting any request attributes: Collection getRequestAttributes(); The sign() method blindly signs the request (should the method also include a requestType parameter or can it detect the type? maybe do not worry about it at the moment. we can add an overloaded method later) without looking at the content. If a real CA decides to use the API, it will need to call some other 3rd party tools to inspect the content. Thanks Max > > Mike > > > On 12/3/2015 3:31 AM, Wang Weijun wrote: >> I tried. >> >> It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better. >> >> Extension >> --------- >> >> Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension: >> >> static Extension newExtension(String oid, byte[] content, boolean isCritical); >> static Extension newExtension(String oid, String value, boolean isCritical); >> >> The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say, >> >> static final String KEYUSAGE = "2.5.29.16". >> >> The "for example" comment of getExtensionValue() will be gone. >> >> CertificateRequest >> ------------------ >> >> A new CertificateRequest will be added which looks a lot like Certificate, it will have >> >> String getType(); >> byte[] getEncoded(); >> PublicKey getPublicKey(); >> >> and serialization but no verify(). It is always self-signed so the constructor can verify. >> >> It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have >> >> byte[] getCertificationRequestInfo; >> X500Principal getSubjectX500Principal(); >> byte[] getSignature(); >> String getSigAlgName(); >> String getSigAlgOID(); >> byte[] getSigAlgParams(); >> int getVersion(); >> >> (Or maybe not all getSigXXX() methods?) >> >> CertificateFactory should have a new method >> >> CertificateRequest generateCertificateRequest(InputStream) >> >> and CertificateFactorySpi needs a corresponding engine method throwing UOE. >> >> The X509Factory implementation will read it. >> >> >> All these sound straightforward, worth doing? >> >> Thanks >> Max >> >> >> > From xuelei.fan at oracle.com Mon Dec 7 04:02:29 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Dec 2015 12:02:29 +0800 Subject: RFR 8138638: Security tests using jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with OutOfMemoryError In-Reply-To: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com> References: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com> Message-ID: <566504D5.4090508@oracle.com> On 12/7/2015 11:51 AM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8138638/webrev.00/ > > It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request. > Ignore by throwing exception? If I did not miss something, the test may still fail with the new added exception if there is a huge request. Xuelei From weijun.wang at oracle.com Mon Dec 7 04:35:44 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 7 Dec 2015 12:35:44 +0800 Subject: RFR 8138638: Security tests using jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with OutOfMemoryError In-Reply-To: <566504D5.4090508@oracle.com> References: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com> <566504D5.4090508@oracle.com> Message-ID: <04073B68-D892-4C18-9641-F376D2219843@oracle.com> Its caught 5 lines below and then ignored. --Max > ? 2015?12?7??12:02?Xuelei Fan ??? > >> On 12/7/2015 11:51 AM, Wang Weijun wrote: >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8138638/webrev.00/ >> >> It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request. > Ignore by throwing exception? If I did not miss something, the test may > still fail with the new added exception if there is a huge request. > > Xuelei > From xuelei.fan at oracle.com Mon Dec 7 04:50:39 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Dec 2015 12:50:39 +0800 Subject: RFR 8138638: Security tests using jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with OutOfMemoryError In-Reply-To: <04073B68-D892-4C18-9641-F376D2219843@oracle.com> References: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com> <566504D5.4090508@oracle.com> <04073B68-D892-4C18-9641-F376D2219843@oracle.com> Message-ID: <5665101F.4090208@oracle.com> OK. Looks fine now. Xuelei On 12/7/2015 12:35 PM, Wang Weijun wrote: > Its caught 5 lines below and then ignored. > > --Max > >> ? 2015?12?7??12:02?Xuelei Fan ??? >> >>> On 12/7/2015 11:51 AM, Wang Weijun wrote: >>> Please review the fix at >>> >>> http://cr.openjdk.java.net/~weijun/8138638/webrev.00/ >>> >>> It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request. >> Ignore by throwing exception? If I did not miss something, the test may >> still fail with the new added exception if there is a huge request. >> >> Xuelei >> From xuelei.fan at oracle.com Mon Dec 7 11:08:02 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Dec 2015 19:08:02 +0800 Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly Message-ID: <56656892.3060904@oracle.com> Hi Brad, Please review this fix for JDK-8136410: http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/ AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is used as a String split separator. "NoPadding" was incorrectly split as "NoPadd" and "g". This update update the slit String split pattern, and "Padding" get specially handled. Thanks, Xuelei From amy.lu at oracle.com Mon Dec 7 12:23:53 2015 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 7 Dec 2015 20:23:53 +0800 Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly In-Reply-To: <56656892.3060904@oracle.com> References: <56656892.3060904@oracle.com> Message-ID: <56657A59.8000906@oracle.com> Hi, Xuelei test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java line36 private final static String PATH = System.getProperty("test.src", "."); It seems that this line could be removed. Thanks, Amy On 12/7/15 7:08 PM, Xuelei Fan wrote: > Hi Brad, > > Please review this fix for JDK-8136410: > > http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/ > > AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is > used as a String split separator. "NoPadding" was incorrectly split as > "NoPadd" and "g". > > This update update the slit String split pattern, and "Padding" get > specially handled. > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Dec 7 12:35:13 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Dec 2015 20:35:13 +0800 Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly In-Reply-To: <56657A59.8000906@oracle.com> References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com> Message-ID: <56657D01.7030505@oracle.com> On 12/7/2015 8:23 PM, Amy Lu wrote: > Hi, Xuelei > > test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java > > line36 private final static String PATH = > System.getProperty("test.src", "."); > > It seems that this line could be removed. > Oops, bad copy and past. Updated. Thanks, Xuelei > Thanks, > Amy > > On 12/7/15 7:08 PM, Xuelei Fan wrote: >> Hi Brad, >> >> Please review this fix for JDK-8136410: >> >> http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/ >> >> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is >> used as a String split separator. "NoPadding" was incorrectly split as >> "NoPadd" and "g". >> >> This update update the slit String split pattern, and "Padding" get >> specially handled. >> >> Thanks, >> Xuelei > From amy.lu at oracle.com Mon Dec 7 12:53:18 2015 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 7 Dec 2015 20:53:18 +0800 Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly In-Reply-To: <56657D01.7030505@oracle.com> References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com> <56657D01.7030505@oracle.com> Message-ID: <5665813E.9040707@oracle.com> On 12/7/15 8:35 PM, Xuelei Fan wrote: > On 12/7/2015 8:23 PM, Amy Lu wrote: >> Hi, Xuelei >> >> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java >> >> line36 private final static String PATH = >> System.getProperty("test.src", "."); >> >> It seems that this line could be removed. >> > Oops, bad copy and past. Updated. Thank you for the quick update. I'm not openjdk reviewer and will leave the review to official reviewers. Thanks, Amy > > Thanks, > Xuelei > >> Thanks, >> Amy >> >> On 12/7/15 7:08 PM, Xuelei Fan wrote: >>> Hi Brad, >>> >>> Please review this fix for JDK-8136410: >>> >>> http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/ >>> >>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is >>> used as a String split separator. "NoPadding" was incorrectly split as >>> "NoPadd" and "g". >>> >>> This update update the slit String split pattern, and "Padding" get >>> specially handled. >>> >>> Thanks, >>> Xuelei From sean.mullan at oracle.com Mon Dec 7 20:15:00 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Dec 2015 15:15:00 -0500 Subject: Code Review Request 8141703, Test B6216082.java failed with operation timed out exception In-Reply-To: <5661A631.4000300@oracle.com> References: <5661A631.4000300@oracle.com> Message-ID: <5665E8C4.7070502@oracle.com> On 12/04/2015 09:41 AM, Xuelei Fan wrote: > Hi, > > Please review the test update for JDK-8141703: > http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/ > > The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java, > need to start a server and proxy, and then make https connection over > them. It is noticed that the test fails intermittent. > > The cause may be that in rush platform, the target proxy and server may > be not ready before the client call. Maybe not worthy a fix, as the > update need to re-org a lot of code and related classes. > > I plan to add the intermittent keyword to the test case, as the code in > the webrev. That seems fine to me, but that doesn't actually fix the failure, it just allows the test to be marked and grouped as one that fails intermittently. So, I think JDK-8141703 should remain open and you should file a different bug to add the intermittent keyword. --Sean From sean.mullan at oracle.com Mon Dec 7 21:29:34 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 7 Dec 2015 16:29:34 -0500 Subject: [9] RFR: 8140470: javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed with java.security.AccessControlException In-Reply-To: <56604F2C.6000401@oracle.com> References: <56604D66.5050603@oracle.com> <56604F2C.6000401@oracle.com> Message-ID: <5665FA3E.2090407@oracle.com> Looks fine to me. --Sean On 12/03/2015 09:18 AM, Artem Smotrakov wrote: > I sent a wrong version of webrev, please use the following one > > http://cr.openjdk.java.net/~asmotrak/8140470/webrev.01/ > > Artem > > On 12/03/2015 05:10 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review this small fix which updates XMLDSigWithSecMgr.java test >> to extend the default security policy instead of override. Please see >> details here: >> >> https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873347 >> >> >> The test could use "@run main/othervm/java.security.policy" action, >> but sometimes it may be better to enable a security manager during >> test execution to avoid granting many additional permissions if a test >> requires some setup. I tried to set "java.security.policy" system >> property just before enabling a security manager, and it seems to work >> fine. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140470 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8140470/webrev.00/ >> >> Artem > From valerie.peng at oracle.com Mon Dec 7 23:15:33 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 07 Dec 2015 15:15:33 -0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> Message-ID: <56661315.2070701@oracle.com> Siba, I have just started to review this webrev and not done yet. As for your question, the java.security file in OpenJDK9 still uses the provider class names instead of provider names. Are you talking about the java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have you tested against. I am pretty sure that I tested the 3rd party provider on classpath setting when I worked on the 7191662 changes. Supposedly, if the jar files are available on class path, then you should specify its full *class name* in the java.security file for it to be instantiated. Otherwise, how would it find the class? Only the classes discovered by ServiceLoader can be identified using the provider name (which is different from the class name referred above). So, in your scenario, that would be "provider.TestJCEProvider" instead of "TEST". If you still run into problems, try enable the java security debug flag and u should get a good idea why it isn't loaded. Let me know if you still have questions. Thanks, Valerie On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: > I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back? > > Thanks, > Siba > > -----Original Message----- > From: Alan Bateman > Sent: Monday, November 30, 2015 4:54 PM > To: Sibabrata Sahoo; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > On 30/11/2015 11:13, Sibabrata Sahoo wrote: >> Here is the updated webrev: >> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >> >> I have one question: >> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*"& working with<= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider? >> >> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH. >> > The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider. properties in the java.security file. I'm sure Valerie can say more about this. > > -Alan From xuelei.fan at oracle.com Tue Dec 8 00:11:06 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 8 Dec 2015 08:11:06 +0800 Subject: Code Review Request 8141703, Test B6216082.java failed with operation timed out exception In-Reply-To: <5665E8C4.7070502@oracle.com> References: <5661A631.4000300@oracle.com> <5665E8C4.7070502@oracle.com> Message-ID: <5666201A.8090106@oracle.com> On 12/8/2015 4:15 AM, Sean Mullan wrote: > On 12/04/2015 09:41 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the test update for JDK-8141703: >> http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/ >> >> The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java, >> need to start a server and proxy, and then make https connection over >> them. It is noticed that the test fails intermittent. >> >> The cause may be that in rush platform, the target proxy and server may >> be not ready before the client call. Maybe not worthy a fix, as the >> update need to re-org a lot of code and related classes. >> >> I plan to add the intermittent keyword to the test case, as the code in >> the webrev. > > That seems fine to me, but that doesn't actually fix the failure, it > just allows the test to be marked and grouped as one that fails > intermittently. So, I think JDK-8141703 should remain open and you > should file a different bug to add the intermittent keyword. > Yes. I will keep this open and file a new bug. Xuelei From xuelei.fan at oracle.com Tue Dec 8 00:15:28 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 7 Dec 2015 16:15:28 -0800 (PST) Subject: Code Review Request 8141703, Test B6216082.java failed with operation timed out exception In-Reply-To: <5666201A.8090106@oracle.com> References: <5661A631.4000300@oracle.com> <5665E8C4.7070502@oracle.com> <5666201A.8090106@oracle.com> Message-ID: <56662120.4050405@oracle.com> On 12/8/2015 8:11 AM, Xuelei Fan wrote: > On 12/8/2015 4:15 AM, Sean Mullan wrote: >> On 12/04/2015 09:41 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the test update for JDK-8141703: >>> http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/ >>> >>> The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java, >>> need to start a server and proxy, and then make https connection over >>> them. It is noticed that the test fails intermittent. >>> >>> The cause may be that in rush platform, the target proxy and server may >>> be not ready before the client call. Maybe not worthy a fix, as the >>> update need to re-org a lot of code and related classes. >>> >>> I plan to add the intermittent keyword to the test case, as the code in >>> the webrev. >> >> That seems fine to me, but that doesn't actually fix the failure, it >> just allows the test to be marked and grouped as one that fails >> intermittently. So, I think JDK-8141703 should remain open and you >> should file a different bug to add the intermittent keyword. >> > Yes. I will keep this open and file a new bug. > New bug: https://bugs.openjdk.java.net/browse/JDK-8144890 Xuelei From bradford.wetmore at oracle.com Tue Dec 8 00:21:09 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 7 Dec 2015 16:21:09 -0800 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <56642AD3.6010904@oracle.com> References: <56642AD3.6010904@oracle.com> Message-ID: <56662275.5000007@oracle.com> Please see my comment in the bug. I haven't verified this, but it seems the problem might be generic to the codepath through SSLSocket, not just Https. Brad On 12/6/2015 4:32 AM, Xuelei Fan wrote: > Hi, > > Please review the update for JDK-8144566: > > http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ > > For HttpsURLConnection, the server name may be set after the TLS > connection and handshake has been initialized. As may result in that > the server name does not present at TLS ClientHello messages. > > This fix resets the server name for the initialized handshake for above > cases. > > Thanks, > Xuelei > From ecki at zusammenkunft.net Tue Dec 8 03:27:13 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Tue, 8 Dec 2015 04:27:13 +0100 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <56662275.5000007@oracle.com> References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com> Message-ID: <830ac455-ed81-4427-84f8-5da3601f2f43.maildroid@localhost> Isnt this codepath used as a workaround for dynamically disabling SNI? Using connect(host..) instead of SSLSocket(host) was at least a common, well known workaround. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Bradford Wetmore To: Xuelei Fan , OpenJDK Sent: Di., 08 Dez. 2015 2:51 Subject: Re: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension Please see my comment in the bug. I haven't verified this, but it seems the problem might be generic to the codepath through SSLSocket, not just Https. Brad On 12/6/2015 4:32 AM, Xuelei Fan wrote: > Hi, > > Please review the update for JDK-8144566: > > http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ > > For HttpsURLConnection, the server name may be set after the TLS > connection and handshake has been initialized. As may result in that > the server name does not present at TLS ClientHello messages. > > This fix resets the server name for the initialized handshake for above > cases. > > Thanks, > Xuelei > From xuelei.fan at oracle.com Tue Dec 8 12:12:46 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 8 Dec 2015 20:12:46 +0800 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <56662275.5000007@oracle.com> References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com> Message-ID: <5666C93E.6010306@oracle.com> Good catch! I copied the comment here: ---------- SocketFactory sslsf = SSLSocketFactory.getDefault(); SSLSocket ssls = (SSLSocket) sslsf.createSocket(); ssls.connect(new InetSocketAddress( "bugs.openjdk.java.net", 443), 0); ssls.startHandshake(); No SNI is sent in this case. ---------- Although this is not a regression, but this is a very good catch. However, I don't think the code path is a best practice, as the actual behavior depends on providers behaviors and platform behaviors too much. I would recommend to use SSLParameters.setServerNames() to specify the server names explicitly. But, best effort should be made for the default server names for such code paths. Here is the webrev that also fixes this code path issue: http://cr.openjdk.java.net/~xuelei/8144566/webrev.01/ The fix gets a little bit complicated because of the need to consider the SSLParameters.setServerNames() impact in the code path: SSLSocket ssls = (SSLSocket) sslsf.createSocket(); // before the connection, need to consider the impact: // Get the SSLParameters from the socket, or create on the fly? // Call ssls.setSSLParameters(params) or not? ssls.connect(socketAddress); // after the connection, need to consider the impact: // Call ssls.setSSLParameters(params) or not? Basically, the implementation honors the server name set by SSLParameters.setServerNames(). Bernd's comment: > Isnt this codepath used as a workaround for dynamically disabling > SNI? Using connect(host..) instead of SSLSocket(host) was at > least a common, well known workaround. If the code path is really used in practice, the SSLParameters.setServerNames() would better be called actually to disable SNI explicitly. SocketFactory sslsf = SSLSocketFactory.getDefault(); SSLSocket ssls = (SSLSocket) sslsf.createSocket(); ssls.connect(new InetSocketAddress( "bugs.openjdk.java.net", 443), 0); sslParameters.setServerNames(emptyList); ssls.setSSLParameters(sslParameters); ssls.startHandshake(); Thank you, Bernd and Brad, for the feedback. Thanks, Xuelei On 12/8/2015 8:21 AM, Bradford Wetmore wrote: > > Please see my comment in the bug. I haven't verified this, but it seems > the problem might be generic to the codepath through SSLSocket, not just > Https. > > Brad > > > > > > On 12/6/2015 4:32 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the update for JDK-8144566: >> >> http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ >> >> For HttpsURLConnection, the server name may be set after the TLS >> connection and handshake has been initialized. As may result in that >> the server name does not present at TLS ClientHello messages. >> >> This fix resets the server name for the initialized handshake for above >> cases. >> >> Thanks, >> Xuelei >> From xuelei.fan at oracle.com Tue Dec 8 12:28:39 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 8 Dec 2015 20:28:39 +0800 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable In-Reply-To: <565D9774.9000304@oracle.com> References: <565D9774.9000304@oracle.com> Message-ID: <5666CCF7.8080405@oracle.com> Ping ... On 12/1/2015 8:49 PM, Xuelei Fan wrote: > Hi, > > Please review the fix for JDK-8133070: > > http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ > > In (Open)JDK 6, EC cipher suites get supported by Java. However, there > is no default EC provider in JDK 6 at that time. In order to support > third part's EC algorithm JCE provider dynamically, it is hard-coded to > check the cipher suite availability dynamically for EC algorithms in > SunJSSE provider. > > Here is an example update in CipherSuite.java for the checking: > > - static final boolean DYNAMIC_AVAILABILITY = false; > + static final boolean DYNAMIC_AVAILABILITY = true; > > The dynamically checking impacts the performance significantly as: > 1. the check of the availability is expensive as it involves crypto > operations. > 2. a cache is used to maintain the availability of bulk ciphers in order > to mitigate the #1 performance impact. However, access and update to > the cache need to be synchronized. > 3. in order to support dynamically checking, the cache may be cleared if > a particular cipher is not found or a new SSLContext is generated. As > bring the performance impact of #1 back again. > > Later, AEAD algorithm is defined by Java. The same mechanism is used to > support AEAD ciphers. > > Now, EC and GCM algorithms are supported in JDK crypto providers. The > hard-coded checking can get improved. This fix updates: > 1. remove the dynamically checking of cipher suite availability. > 2. remove the cipher suite availability cache accordingly (need no > synchronization accordingly) > 3. other updates that impact by the availability checking. > > The performance improvement is tested with the following simple case. > Run the following code 1000, 2000, 3000 times in single thread mode and > measure the millisecond for each: > > --------- > String[] cipherSuites = > {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; > for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 > SSLEngine engine = SSLContext.getDefault().createSSLEngine(); > engine.getEnabledCipherSuites(); > engine.getSupportedCipherSuites(); > } > --------- > > The milliseconds for each test case (less is better) look like: > > loops | old | fixed > ---------+---------+---------- > 1000 | 2736 | 735 > ---------+---------+---------- > 2000 | 3718 | 746 > ---------+---------+---------- > 3000 | 4750 | 765 > ---------+---------+---------- > > This fix improves the performance. > > The existing regression testing get passed. No new regression test is > planned as this is a performance enhancement fix. > > Thanks, > Xuelei > From sibabrata.sahoo at oracle.com Tue Dec 8 14:09:01 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 8 Dec 2015 06:09:01 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <56661315.2070701@oracle.com> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> Message-ID: <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> Hi Valerie, Here is the updated webrev: http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ Now the modular behavior for the test works as per expectation through JAKE build with the following condition. If the provider jar is available under ModulePath then the "java.security" file should have the provider configuration entry as ProviderName while in case of ClassPath the entry should hold the full class name. Thanks, Siba -----Original Message----- From: Valerie Peng Sent: Tuesday, December 08, 2015 4:46 AM To: Sibabrata Sahoo Cc: Alan Bateman; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Siba, I have just started to review this webrev and not done yet. As for your question, the java.security file in OpenJDK9 still uses the provider class names instead of provider names. Are you talking about the java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have you tested against. I am pretty sure that I tested the 3rd party provider on classpath setting when I worked on the 7191662 changes. Supposedly, if the jar files are available on class path, then you should specify its full *class name* in the java.security file for it to be instantiated. Otherwise, how would it find the class? Only the classes discovered by ServiceLoader can be identified using the provider name (which is different from the class name referred above). So, in your scenario, that would be "provider.TestJCEProvider" instead of "TEST". If you still run into problems, try enable the java security debug flag and u should get a good idea why it isn't loaded. Let me know if you still have questions. Thanks, Valerie On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: > I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back? > > Thanks, > Siba > > -----Original Message----- > From: Alan Bateman > Sent: Monday, November 30, 2015 4:54 PM > To: Sibabrata Sahoo; security-dev at openjdk.java.net; > jigsaw-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security > providers if they are in signed/unsigned modular JARs > > On 30/11/2015 11:13, Sibabrata Sahoo wrote: >> Here is the updated webrev: >> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >> >> I have one question: >> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*"& working with<= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider? >> >> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH. >> > The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider. properties in the java.security file. I'm sure Valerie can say more about this. > > -Alan From valerie.peng at oracle.com Tue Dec 8 22:04:45 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 08 Dec 2015 14:04:45 -0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> Message-ID: <566753FD.5020106@oracle.com> Right, that'd be my expectation as well. Sounds like everything works. I will change to look at your latest webrev. Valerie On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: > Hi Valerie, > > Here is the updated webrev: http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ > > Now the modular behavior for the test works as per expectation through JAKE build with the following condition. > If the provider jar is available under ModulePath then the "java.security" file should have the provider configuration entry as ProviderName while in case of ClassPath the entry should hold the full class name. > > Thanks, > Siba > > -----Original Message----- > From: Valerie Peng > Sent: Tuesday, December 08, 2015 4:46 AM > To: Sibabrata Sahoo > Cc: Alan Bateman; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > Siba, > > I have just started to review this webrev and not done yet. > As for your question, the java.security file in OpenJDK9 still uses the provider class names instead of provider names. Are you talking about the java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have you tested against. I am pretty sure that I tested the 3rd party provider on classpath setting when I worked on the 7191662 changes. > > Supposedly, if the jar files are available on class path, then you should specify its full *class name* in the java.security file for it to be instantiated. Otherwise, how would it find the class? Only the classes discovered by ServiceLoader can be identified using the provider name (which is different from the class name referred above). So, in your scenario, that would be "provider.TestJCEProvider" instead of "TEST". > > If you still run into problems, try enable the java security debug flag and u should get a good idea why it isn't loaded. Let me know if you still have questions. > > Thanks, > Valerie > > On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >> I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back? >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Alan Bateman >> Sent: Monday, November 30, 2015 4:54 PM >> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >> jigsaw-dev at openjdk.java.net >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>> >>> I have one question: >>> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*"& working with<= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider? >>> >>> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH. >>> >> The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider. properties in the java.security file. I'm sure Valerie can say more about this. >> >> -Alan From valerie.peng at oracle.com Wed Dec 9 00:06:39 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 08 Dec 2015 16:06:39 -0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <566753FD.5020106@oracle.com> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> Message-ID: <5667708F.9000706@oracle.com> Hi Siba, Here are some nits: I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). You can remove a lot of code as a result. Also, your directory seems a bit deep, e.g. modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? Thanks, Valerie On 12/8/2015 2:04 PM, Valerie Peng wrote: > Right, that'd be my expectation as well. Sounds like everything works. > I will change to look at your latest webrev. > Valerie > > On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >> Hi Valerie, >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >> >> Now the modular behavior for the test works as per expectation >> through JAKE build with the following condition. >> If the provider jar is available under ModulePath then the >> "java.security" file should have the provider configuration entry as >> ProviderName while in case of ClassPath the entry should hold the >> full class name. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Valerie Peng >> Sent: Tuesday, December 08, 2015 4:46 AM >> To: Sibabrata Sahoo >> Cc: Alan Bateman; security-dev at openjdk.java.net; >> jigsaw-dev at openjdk.java.net >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Siba, >> >> I have just started to review this webrev and not done yet. >> As for your question, the java.security file in OpenJDK9 still uses >> the provider class names instead of provider names. Are you talking >> about the java.security file in Jigsaw? Which build (OpenJDK or >> Jigsaw) have you tested against. I am pretty sure that I tested the >> 3rd party provider on classpath setting when I worked on the 7191662 >> changes. >> >> Supposedly, if the jar files are available on class path, then you >> should specify its full *class name* in the java.security file for it >> to be instantiated. Otherwise, how would it find the class? Only the >> classes discovered by ServiceLoader can be identified using the >> provider name (which is different from the class name referred >> above). So, in your scenario, that would be >> "provider.TestJCEProvider" instead of "TEST". >> >> If you still run into problems, try enable the java security debug >> flag and u should get a good idea why it isn't loaded. Let me know >> if you still have questions. >> >> Thanks, >> Valerie >> >> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>> I would like to know more about this. As far, I can see the >>> "java.security" provider configuration available with JDK9, it holds >>> provider names instead of provider class names. In that case how it >>> resolve the fall back? >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Alan Bateman >>> Sent: Monday, November 30, 2015 4:54 PM >>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>> jigsaw-dev at openjdk.java.net >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>> >>>> I have one question: >>>> What should be the behavior when the older version of 3rd party JCE >>>> provider jar file(without service descriptor >>>> "META-INF/services/*"& working with<= JDK8) configured by >>>> "java.security" file, will be place in CLASS_PATH, running through >>>> JDK9 and the client is using Security.getProvider() to look for the >>>> provider? >>>> >>>> Currently the scenario fails to find the JCE provider. Is this >>>> right behavior? If it is, then jdk9 is not backward compatible to >>>> find the security provider provided through older jar files from >>>> CLASS_PATH. >>>> >>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>> point by falling back and attempting to load the class name >>> specified via the security.provider. properties in the >>> java.security file. I'm sure Valerie can say more about this. >>> >>> -Alan From sibabrata.sahoo at oracle.com Wed Dec 9 18:02:31 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 9 Dec 2015 10:02:31 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <5667708F.9000706@oracle.com> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> Message-ID: <62346504-1078-4ccd-9188-29dcd288f269@default> Hi Valerie, Here is the updated webrev: http://cr.openjdk.java.net/~ntv/siba/webrev.00/ Changes applied as per previous comments. - File names are modified and do not include the term JCE. - Source folder structure is flat now and all belongs to "java/security/Provider" folder. - Sign jar functionality removed. Thanks, Siba -----Original Message----- From: Valerie Peng Sent: Wednesday, December 09, 2015 5:37 AM To: Sibabrata Sahoo Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan Bateman Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Hi Siba, Here are some nits: I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). You can remove a lot of code as a result. Also, your directory seems a bit deep, e.g. modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? Thanks, Valerie On 12/8/2015 2:04 PM, Valerie Peng wrote: > Right, that'd be my expectation as well. Sounds like everything works. > I will change to look at your latest webrev. > Valerie > > On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >> Hi Valerie, >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >> >> Now the modular behavior for the test works as per expectation >> through JAKE build with the following condition. >> If the provider jar is available under ModulePath then the >> "java.security" file should have the provider configuration entry as >> ProviderName while in case of ClassPath the entry should hold the >> full class name. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Valerie Peng >> Sent: Tuesday, December 08, 2015 4:46 AM >> To: Sibabrata Sahoo >> Cc: Alan Bateman; security-dev at openjdk.java.net; >> jigsaw-dev at openjdk.java.net >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Siba, >> >> I have just started to review this webrev and not done yet. >> As for your question, the java.security file in OpenJDK9 still uses >> the provider class names instead of provider names. Are you talking >> about the java.security file in Jigsaw? Which build (OpenJDK or >> Jigsaw) have you tested against. I am pretty sure that I tested the >> 3rd party provider on classpath setting when I worked on the 7191662 >> changes. >> >> Supposedly, if the jar files are available on class path, then you >> should specify its full *class name* in the java.security file for it >> to be instantiated. Otherwise, how would it find the class? Only the >> classes discovered by ServiceLoader can be identified using the >> provider name (which is different from the class name referred >> above). So, in your scenario, that would be >> "provider.TestJCEProvider" instead of "TEST". >> >> If you still run into problems, try enable the java security debug >> flag and u should get a good idea why it isn't loaded. Let me know >> if you still have questions. >> >> Thanks, >> Valerie >> >> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>> I would like to know more about this. As far, I can see the >>> "java.security" provider configuration available with JDK9, it holds >>> provider names instead of provider class names. In that case how it >>> resolve the fall back? >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Alan Bateman >>> Sent: Monday, November 30, 2015 4:54 PM >>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>> jigsaw-dev at openjdk.java.net >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>> >>>> I have one question: >>>> What should be the behavior when the older version of 3rd party JCE >>>> provider jar file(without service descriptor >>>> "META-INF/services/*"& working with<= JDK8) configured by >>>> "java.security" file, will be place in CLASS_PATH, running through >>>> JDK9 and the client is using Security.getProvider() to look for the >>>> provider? >>>> >>>> Currently the scenario fails to find the JCE provider. Is this >>>> right behavior? If it is, then jdk9 is not backward compatible to >>>> find the security provider provided through older jar files from >>>> CLASS_PATH. >>>> >>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>> point by falling back and attempting to load the class name >>> specified via the security.provider. properties in the >>> java.security file. I'm sure Valerie can say more about this. >>> >>> -Alan From mandy.chung at oracle.com Wed Dec 9 18:25:03 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Dec 2015 10:25:03 -0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <62346504-1078-4ccd-9188-29dcd288f269@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> Message-ID: Some high-level comment: 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. Some comments on JigsawSecurityUtils.java: 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); this can be replaced with Arrays.stream(options).collect(Collectors.joining(SPACE)); 111 System.out.println(String.format( You can do: System.out.format(?.) instead; Mandy [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java > On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: > > Hi Valerie, > > Here is the updated webrev: http://cr.openjdk.java.net/~ntv/siba/webrev.00/ > > Changes applied as per previous comments. > - File names are modified and do not include the term JCE. > - Source folder structure is flat now and all belongs to "java/security/Provider" folder. > - Sign jar functionality removed. > > Thanks, > Siba > > -----Original Message----- > From: Valerie Peng > Sent: Wednesday, December 09, 2015 5:37 AM > To: Sibabrata Sahoo > Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan Bateman > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > Hi Siba, > > Here are some nits: > > I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. > Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). > You can remove a lot of code as a result. > Also, your directory seems a bit deep, e.g. > modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. > > Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? > > Thanks, > Valerie > > On 12/8/2015 2:04 PM, Valerie Peng wrote: >> Right, that'd be my expectation as well. Sounds like everything works. >> I will change to look at your latest webrev. >> Valerie >> >> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>> Hi Valerie, >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>> >>> Now the modular behavior for the test works as per expectation >>> through JAKE build with the following condition. >>> If the provider jar is available under ModulePath then the >>> "java.security" file should have the provider configuration entry as >>> ProviderName while in case of ClassPath the entry should hold the >>> full class name. >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Tuesday, December 08, 2015 4:46 AM >>> To: Sibabrata Sahoo >>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>> jigsaw-dev at openjdk.java.net >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> Siba, >>> >>> I have just started to review this webrev and not done yet. >>> As for your question, the java.security file in OpenJDK9 still uses >>> the provider class names instead of provider names. Are you talking >>> about the java.security file in Jigsaw? Which build (OpenJDK or >>> Jigsaw) have you tested against. I am pretty sure that I tested the >>> 3rd party provider on classpath setting when I worked on the 7191662 >>> changes. >>> >>> Supposedly, if the jar files are available on class path, then you >>> should specify its full *class name* in the java.security file for it >>> to be instantiated. Otherwise, how would it find the class? Only the >>> classes discovered by ServiceLoader can be identified using the >>> provider name (which is different from the class name referred >>> above). So, in your scenario, that would be >>> "provider.TestJCEProvider" instead of "TEST". >>> >>> If you still run into problems, try enable the java security debug >>> flag and u should get a good idea why it isn't loaded. Let me know >>> if you still have questions. >>> >>> Thanks, >>> Valerie >>> >>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>> I would like to know more about this. As far, I can see the >>>> "java.security" provider configuration available with JDK9, it holds >>>> provider names instead of provider class names. In that case how it >>>> resolve the fall back? >>>> >>>> Thanks, >>>> Siba >>>> >>>> -----Original Message----- >>>> From: Alan Bateman >>>> Sent: Monday, November 30, 2015 4:54 PM >>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>> jigsaw-dev at openjdk.java.net >>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>>> providers if they are in signed/unsigned modular JARs >>>> >>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>> >>>>> I have one question: >>>>> What should be the behavior when the older version of 3rd party JCE >>>>> provider jar file(without service descriptor >>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>> "java.security" file, will be place in CLASS_PATH, running through >>>>> JDK9 and the client is using Security.getProvider() to look for the >>>>> provider? >>>>> >>>>> Currently the scenario fails to find the JCE provider. Is this >>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>> find the security provider provided through older jar files from >>>>> CLASS_PATH. >>>>> >>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>> point by falling back and attempting to load the class name >>>> specified via the security.provider. properties in the >>>> java.security file. I'm sure Valerie can say more about this. >>>> >>>> -Alan From sean.mullan at oracle.com Wed Dec 9 19:40:21 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Dec 2015 14:40:21 -0500 Subject: Code Review Request, 8141651 Deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <56637B66.10705@oracle.com> References: <56637B66.10705@oracle.com> Message-ID: <566883A5.2040805@oracle.com> Fix looks good, interesting issue, though I wonder if there is a better locking scheme, but probably a question for another time. --Sean On 12/05/2015 07:03 PM, Xuelei Fan wrote: > Hi, > > Please review the fix for JDK-8141651: > > http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/ > > In JDK 9, there is a deadlock introduced. One thread can lock > SSLSocketImpl instance, and try to lock SSLSocketImpl.writeLock; Another > thread may lock SSLSocketImpl.writeLock, and then try to lock > SSLSocketImpl instance. A deadlock happens. > > This fix is trying to remove the latter lock sequence. > > No new regression test as it is hard to re-produce the issue. > > Thanks, > Xuelei > From sean.mullan at oracle.com Wed Dec 9 21:43:23 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Dec 2015 16:43:23 -0500 Subject: RFR: Remove @Deprecated annotation from java.security.acl and javax.security.cert packages Message-ID: <5668A07B.2070202@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8144784 The @Deprecated annotation on a package is a no-op in terms of affecting the set of deprecation warnings the compiler produces. This has been clarified in the JLS and specification for java.lang.Deprecated in 9. Thus, we should remove the @Deprecated annotations from the packages since they are not providing any value. No webrev, since the diffs are trivial: diff --git a/src/java.base/share/classes/java/security/acl/package-info.java b/src/java.base/share/classes/java/security/acl/package-info.java --- a/src/java.base/share/classes/java/security/acl/package-info.java +++ b/src/java.base/share/classes/java/security/acl/package-info.java @@ -32,4 +32,3 @@ * @since 1.1 */ - at Deprecated package java.security.acl; diff --git a/src/java.base/share/classes/javax/security/cert/package-info.java b/src/java.base/share/classes/javax/security/cert/package-info.java --- a/src/java.base/share/classes/javax/security/cert/package-info.java +++ b/src/java.base/share/classes/javax/security/cert/package-info.java @@ -38,4 +38,3 @@ * @since 1.4 */ - at Deprecated package javax.security.cert; Thanks, Sean From mandy.chung at oracle.com Wed Dec 9 21:51:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 9 Dec 2015 13:51:02 -0800 Subject: RFR: Remove @Deprecated annotation from java.security.acl and javax.security.cert packages In-Reply-To: <5668A07B.2070202@oracle.com> References: <5668A07B.2070202@oracle.com> Message-ID: <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com> > On Dec 9, 2015, at 1:43 PM, Sean Mullan wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144784 > > The @Deprecated annotation on a package is a no-op in terms of affecting the set of deprecation warnings the compiler produces. This has been clarified in the JLS and specification for java.lang.Deprecated in 9. > > Thus, we should remove the @Deprecated annotations from the packages since they are not providing any value. All classes in these two packages have @Deprecated. Removing @Deprecated from package-info.java is okay. Mandy From valerie.peng at oracle.com Thu Dec 10 02:22:11 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 09 Dec 2015 18:22:11 -0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> Message-ID: <5668E1D3.1070805@oracle.com> I am leaving for vacation tonight and probably can't review the updates for Mandy's comments. Existing changes are good enough for me, and what Mandy suggested sounds fine with me. As long as the tests run as expected, I have no further comments. Thanks, Valerie On 12/9/2015 10:25 AM, Mandy Chung wrote: > Some high-level comment: > 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. > 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. > > Some comments on JigsawSecurityUtils.java: > 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); > > this can be replaced with > Arrays.stream(options).collect(Collectors.joining(SPACE)); > > 111 System.out.println(String.format( > > You can do: System.out.format(?.) instead; > > Mandy > [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java > >> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: >> >> Hi Valerie, >> >> Here is the updated webrev: http://cr.openjdk.java.net/~ntv/siba/webrev.00/ >> >> Changes applied as per previous comments. >> - File names are modified and do not include the term JCE. >> - Source folder structure is flat now and all belongs to "java/security/Provider" folder. >> - Sign jar functionality removed. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Valerie Peng >> Sent: Wednesday, December 09, 2015 5:37 AM >> To: Sibabrata Sahoo >> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan Bateman >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs >> >> Hi Siba, >> >> Here are some nits: >> >> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. >> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). >> You can remove a lot of code as a result. >> Also, your directory seems a bit deep, e.g. >> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. >> >> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? >> >> Thanks, >> Valerie >> >> On 12/8/2015 2:04 PM, Valerie Peng wrote: >>> Right, that'd be my expectation as well. Sounds like everything works. >>> I will change to look at your latest webrev. >>> Valerie >>> >>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>>> Hi Valerie, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>>> >>>> Now the modular behavior for the test works as per expectation >>>> through JAKE build with the following condition. >>>> If the provider jar is available under ModulePath then the >>>> "java.security" file should have the provider configuration entry as >>>> ProviderName while in case of ClassPath the entry should hold the >>>> full class name. >>>> >>>> Thanks, >>>> Siba >>>> >>>> -----Original Message----- >>>> From: Valerie Peng >>>> Sent: Tuesday, December 08, 2015 4:46 AM >>>> To: Sibabrata Sahoo >>>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>>> jigsaw-dev at openjdk.java.net >>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>>> providers if they are in signed/unsigned modular JARs >>>> >>>> Siba, >>>> >>>> I have just started to review this webrev and not done yet. >>>> As for your question, the java.security file in OpenJDK9 still uses >>>> the provider class names instead of provider names. Are you talking >>>> about the java.security file in Jigsaw? Which build (OpenJDK or >>>> Jigsaw) have you tested against. I am pretty sure that I tested the >>>> 3rd party provider on classpath setting when I worked on the 7191662 >>>> changes. >>>> >>>> Supposedly, if the jar files are available on class path, then you >>>> should specify its full *class name* in the java.security file for it >>>> to be instantiated. Otherwise, how would it find the class? Only the >>>> classes discovered by ServiceLoader can be identified using the >>>> provider name (which is different from the class name referred >>>> above). So, in your scenario, that would be >>>> "provider.TestJCEProvider" instead of "TEST". >>>> >>>> If you still run into problems, try enable the java security debug >>>> flag and u should get a good idea why it isn't loaded. Let me know >>>> if you still have questions. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>>> I would like to know more about this. As far, I can see the >>>>> "java.security" provider configuration available with JDK9, it holds >>>>> provider names instead of provider class names. In that case how it >>>>> resolve the fall back? >>>>> >>>>> Thanks, >>>>> Siba >>>>> >>>>> -----Original Message----- >>>>> From: Alan Bateman >>>>> Sent: Monday, November 30, 2015 4:54 PM >>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>>> jigsaw-dev at openjdk.java.net >>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>>>> providers if they are in signed/unsigned modular JARs >>>>> >>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>>> >>>>>> I have one question: >>>>>> What should be the behavior when the older version of 3rd party JCE >>>>>> provider jar file(without service descriptor >>>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>>> "java.security" file, will be place in CLASS_PATH, running through >>>>>> JDK9 and the client is using Security.getProvider() to look for the >>>>>> provider? >>>>>> >>>>>> Currently the scenario fails to find the JCE provider. Is this >>>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>>> find the security provider provided through older jar files from >>>>>> CLASS_PATH. >>>>>> >>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>>> point by falling back and attempting to load the class name >>>>> specified via the security.provider. properties in the >>>>> java.security file. I'm sure Valerie can say more about this. >>>>> >>>>> -Alan From weijun.wang at oracle.com Thu Dec 10 05:36:49 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 10 Dec 2015 13:36:49 +0800 Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly In-Reply-To: <56657D01.7030505@oracle.com> References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com> <56657D01.7030505@oracle.com> Message-ID: The code change looks ok. You might want to rename the test from Decomposealgorithms to DecomposeAlgorithms. However, I am not sure if this is the ultimate solution. IMHO, it will be nice to provide several patterns, say, within etc and provide a supported list for each category (hash, kp, format). --Max > On Dec 7, 2015, at 8:35 PM, Xuelei Fan wrote: > > On 12/7/2015 8:23 PM, Amy Lu wrote: >> Hi, Xuelei >> >> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java >> >> line36 private final static String PATH = >> System.getProperty("test.src", "."); >> >> It seems that this line could be removed. >> > Oops, bad copy and past. Updated. > > Thanks, > Xuelei > >> Thanks, >> Amy >> >> On 12/7/15 7:08 PM, Xuelei Fan wrote: >>> Hi Brad, >>> >>> Please review this fix for JDK-8136410: >>> >>> http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/ >>> >>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is >>> used as a String split separator. "NoPadding" was incorrectly split as >>> "NoPadd" and "g". >>> >>> This update update the slit String split pattern, and "Padding" get >>> specially handled. >>> >>> Thanks, >>> Xuelei >> > From xuelei.fan at oracle.com Thu Dec 10 05:58:56 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Dec 2015 13:58:56 +0800 Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly In-Reply-To: References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com> <56657D01.7030505@oracle.com> Message-ID: <566914A0.8080907@oracle.com> On 12/10/2015 1:36 PM, Wang Weijun wrote: > The code change looks ok. You might want to rename the test from Decomposealgorithms to DecomposeAlgorithms. > OK. Will do it. > However, I am not sure if this is the ultimate solution. No at present. The current decomposing only consider certpath and tls algorithms. May need improvement if extends the scope in the future. > IMHO, it will be nice to provide several patterns, say, within etc and provide a supported list for each category (hash, kp, format). > Maybe. But add extra workload to maintain the supported list. Will consider the proposal in the future if need to extends the scope. Thanks, Xuelei > --Max > >> On Dec 7, 2015, at 8:35 PM, Xuelei Fan wrote: >> >> On 12/7/2015 8:23 PM, Amy Lu wrote: >>> Hi, Xuelei >>> >>> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java >>> >>> line36 private final static String PATH = >>> System.getProperty("test.src", "."); >>> >>> It seems that this line could be removed. >>> >> Oops, bad copy and past. Updated. >> >> Thanks, >> Xuelei >> >>> Thanks, >>> Amy >>> >>> On 12/7/15 7:08 PM, Xuelei Fan wrote: >>>> Hi Brad, >>>> >>>> Please review this fix for JDK-8136410: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/ >>>> >>>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is >>>> used as a String split separator. "NoPadding" was incorrectly split as >>>> "NoPadd" and "g". >>>> >>>> This update update the slit String split pattern, and "Padding" get >>>> specially handled. >>>> >>>> Thanks, >>>> Xuelei >>> >> > From sean.mullan at oracle.com Thu Dec 10 15:53:38 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 10 Dec 2015 10:53:38 -0500 Subject: RFR: Remove @Deprecated annotation from java.security.acl and javax.security.cert packages In-Reply-To: <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com> References: <5668A07B.2070202@oracle.com> <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com> Message-ID: <5669A002.8090209@oracle.com> On 12/09/2015 04:51 PM, Mandy Chung wrote: > >> On Dec 9, 2015, at 1:43 PM, Sean Mullan wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8144784 >> >> The @Deprecated annotation on a package is a no-op in terms of affecting the set of deprecation warnings the compiler produces. This has been clarified in the JLS and specification for java.lang.Deprecated in 9. >> >> Thus, we should remove the @Deprecated annotations from the packages since they are not providing any value. > > > All classes in these two packages have @Deprecated. Removing @Deprecated from package-info.java is okay. Max asked me to add the com.sun.jarsigner package to this bug, which also has an unnecessary @Deprecated annotation. I also made a few tweaks to the deprecation wording here and there, so a webrev is probably easier to review than diffs now: http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/ --Sean From chris.hegarty at oracle.com Thu Dec 10 15:56:33 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Dec 2015 15:56:33 +0000 Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util Message-ID: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> sun.misc.HexDumpEncoder is an internal private API that is used almost exclusively by the security library code. It should be moved out of sun.misc and into a package more appropriate to its use, sun.security.util. HexDumpEncoder extends CharacterEncoder, which is slated for later removal, so the minimal implementation was copied in-place ( no new code ). http://cr.openjdk.java.net/~chegar/8144995/00/webrev/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8144995 From paul.sandoz at oracle.com Thu Dec 10 16:03:47 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Dec 2015 17:03:47 +0100 Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util In-Reply-To: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> References: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> Message-ID: <6AF2B0FA-3AC4-4B39-9718-405BC0443889@oracle.com> Looks ok to me, Paul. > On 10 Dec 2015, at 16:56, Chris Hegarty wrote: > > sun.misc.HexDumpEncoder is an internal private API that is used almost > exclusively by the security library code. It should be moved out of sun.misc > and into a package more appropriate to its use, sun.security.util. > > HexDumpEncoder extends CharacterEncoder, which is slated for later > removal, so the minimal implementation was copied in-place ( no new > code ). > > http://cr.openjdk.java.net/~chegar/8144995/00/webrev/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8144995 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mandy.chung at oracle.com Thu Dec 10 18:14:18 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Dec 2015 10:14:18 -0800 Subject: RFR: Remove @Deprecated annotation from java.security.acl and javax.security.cert packages In-Reply-To: <5669A002.8090209@oracle.com> References: <5668A07B.2070202@oracle.com> <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com> <5669A002.8090209@oracle.com> Message-ID: <7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com> > On Dec 10, 2015, at 7:53 AM, Sean Mullan wrote: > > Max asked me to add the com.sun.jarsigner package to this bug, which also has an unnecessary @Deprecated annotation. I also made a few tweaks to the deprecation wording here and there, so a webrev is probably easier to review than diffs now: > > http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/ Is there any other package-info.java beside these three packages? It worths to have a quick scan on the source. To me, it?s fine to keep the existing @deprecated comment in com.sun.jarsigner.* classes since I assume you want to discourage new classes to be added in that package. Mandy From bradford.wetmore at oracle.com Thu Dec 10 21:09:06 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 10 Dec 2015 13:09:06 -0800 Subject: Code Review Request, 8141651 Deadlock in sun.security.ssl.SSLSocketImpl In-Reply-To: <566883A5.2040805@oracle.com> References: <56637B66.10705@oracle.com> <566883A5.2040805@oracle.com> Message-ID: <5669E9F2.6030409@oracle.com> Looks good. Brad On 12/9/2015 11:40 AM, Sean Mullan wrote: > Fix looks good, interesting issue, though I wonder if there is a better > locking scheme, but probably a question for another time. > > --Sean > > On 12/05/2015 07:03 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the fix for JDK-8141651: >> >> http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/ >> >> In JDK 9, there is a deadlock introduced. One thread can lock >> SSLSocketImpl instance, and try to lock SSLSocketImpl.writeLock; Another >> thread may lock SSLSocketImpl.writeLock, and then try to lock >> SSLSocketImpl instance. A deadlock happens. >> >> This fix is trying to remove the latter lock sequence. >> >> No new regression test as it is hard to re-produce the issue. >> >> Thanks, >> Xuelei >> From sean.mullan at oracle.com Thu Dec 10 21:18:36 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 10 Dec 2015 16:18:36 -0500 Subject: RFR: Remove @Deprecated annotation from java.security.acl and javax.security.cert packages In-Reply-To: <7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com> References: <5668A07B.2070202@oracle.com> <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com> <5669A002.8090209@oracle.com> <7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com> Message-ID: <5669EC2C.40109@oracle.com> On 12/10/2015 01:14 PM, Mandy Chung wrote: > >> On Dec 10, 2015, at 7:53 AM, Sean Mullan >> wrote: >> >> Max asked me to add the com.sun.jarsigner package to this bug, >> which also has an unnecessary @Deprecated annotation. I also made a >> few tweaks to the deprecation wording here and there, so a webrev >> is probably easier to review than diffs now: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/ > > Is there any other package-info.java beside these three packages? It > worths to have a quick scan on the source. > > To me, it?s fine to keep the existing @deprecated comment in > com.sun.jarsigner.* classes since I assume you want to discourage new > classes to be added in that package. Well, we are trying to "deprecate" use of the @Deprecated annotation on packages, so I would prefer not to leave this in (also, I heard there will eventually be a javac warning for this). Instead I will add a sentence or comment that says new classes should not be added to the package. Is that ok? --Sean From mandy.chung at oracle.com Thu Dec 10 22:12:52 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Dec 2015 14:12:52 -0800 Subject: RFR: Remove @Deprecated annotation from java.security.acl and javax.security.cert packages In-Reply-To: <5669EC2C.40109@oracle.com> References: <5668A07B.2070202@oracle.com> <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com> <5669A002.8090209@oracle.com> <7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com> <5669EC2C.40109@oracle.com> Message-ID: <5669F8E4.4070403@oracle.com> On 12/10/2015 01:18 PM, Sean Mullan wrote: > On 12/10/2015 01:14 PM, Mandy Chung wrote: >> >>> On Dec 10, 2015, at 7:53 AM, Sean Mullan >>> wrote: >>> >>> Max asked me to add the com.sun.jarsigner package to this bug, >>> which also has an unnecessary @Deprecated annotation. I also made a >>> few tweaks to the deprecation wording here and there, so a webrev >>> is probably easier to review than diffs now: >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/ >> >> Is there any other package-info.java beside these three packages? It >> worths to have a quick scan on the source. >> >> To me, it?s fine to keep the existing @deprecated comment in >> com.sun.jarsigner.* classes since I assume you want to discourage new >> classes to be added in that package. > > Well, we are trying to "deprecate" use of the @Deprecated annotation > on packages, so I would prefer not to leave this in (also, I heard > there will eventually be a javac warning for this). Instead I will add > a sentence or comment that says new classes should not be added to the > package. Is that ok? To clarify: I meant the original comment in these two files seems fine and cound be reverted: src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameter.java Your suggestion to add a sentence in package-info.java is a fine idea. Mandy From mandy.chung at oracle.com Fri Dec 11 07:18:10 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Dec 2015 23:18:10 -0800 Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util In-Reply-To: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> References: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> Message-ID: <9F8FBD74-9FC7-4C54-950E-73E663E898FB@oracle.com> > On Dec 10, 2015, at 7:56 AM, Chris Hegarty wrote: > > sun.misc.HexDumpEncoder is an internal private API that is used almost > exclusively by the security library code. It should be moved out of sun.misc > and into a package more appropriate to its use, sun.security.util. > > HexDumpEncoder extends CharacterEncoder, which is slated for later > removal, so the minimal implementation was copied in-place ( no new > code ). > > http://cr.openjdk.java.net/~chegar/8144995/00/webrev/ Looks okay. Mandy From bhanu.prakash.gopularam at oracle.com Fri Dec 11 10:50:29 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Fri, 11 Dec 2015 02:50:29 -0800 (PST) Subject: RFR: 8129567 - the GCM mode parameter which is used as the initialization vector ("IV") is set to all zeros Message-ID: Hi all, Please review a fix for following bug: Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129567 Issue - Few tests are using all zero IV for GCM parameter spec which gives CRYPTO_MECHANISM_PARAM_INVALID error On certain platforms Solution - Use a random IV in GCMParameterSpec in the tests webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129567/webrev.00/ Thanks, Bhanu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Dec 14 16:05:21 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Dec 2015 11:05:21 -0500 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> Message-ID: <566EE8C1.90700@oracle.com> The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters: DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null); That seems awkward, and you have be overly careful to map the right value to each parameter. I think this is a case where a DrbgParameters.Builder would be very useful. --Sean I think this is an ideal use case for the On 11/30/2015 01:30 AM, Wang Weijun wrote: > Minor updates: > > spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/specdiff/java/security/package-summary.html > impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/ > http://javaweb.us.oracle.com/~weijwan/webrev/8051408/webrev/ <<- test/closed > > Mostly spec. reseed() has no default implementation now (aka throws UnsupportedOperationException). > > Integration date is now Dec 4. Won't catch it. > > --Max > >> On Nov 23, 2015, at 3:03 PM, Wang Weijun wrote: >> >> spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdiff/java/security/package-summary.html >> impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/ >> >> - No more configure(), it's getInstance(alg, SecureRandomParameters) now. >> >> - The *Spec class names are now *Parameters. >> >> - Overloaded reseed() and reseed(additionalInput). >> >> TBD: Should nextBytes(bytes,additionalInput) throw an UnsupportedOperationException for old implementations? >> >> Thanks >> Max >> > From sean.mullan at oracle.com Mon Dec 14 20:24:36 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Dec 2015 15:24:36 -0500 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable In-Reply-To: <565D9774.9000304@oracle.com> References: <565D9774.9000304@oracle.com> Message-ID: <566F2584.5070502@oracle.com> Hi Xuelei, For JDK 9, the EC impl is defined to be in its own module (jdk.crypto.ec). How does it affect this fix if that module is not available/installed? --Sean On 12/01/2015 07:49 AM, Xuelei Fan wrote: > Hi, > > Please review the fix for JDK-8133070: > > http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ > > In (Open)JDK 6, EC cipher suites get supported by Java. However, there > is no default EC provider in JDK 6 at that time. In order to support > third part's EC algorithm JCE provider dynamically, it is hard-coded to > check the cipher suite availability dynamically for EC algorithms in > SunJSSE provider. > > Here is an example update in CipherSuite.java for the checking: > > - static final boolean DYNAMIC_AVAILABILITY = false; > + static final boolean DYNAMIC_AVAILABILITY = true; > > The dynamically checking impacts the performance significantly as: > 1. the check of the availability is expensive as it involves crypto > operations. > 2. a cache is used to maintain the availability of bulk ciphers in order > to mitigate the #1 performance impact. However, access and update to > the cache need to be synchronized. > 3. in order to support dynamically checking, the cache may be cleared if > a particular cipher is not found or a new SSLContext is generated. As > bring the performance impact of #1 back again. > > Later, AEAD algorithm is defined by Java. The same mechanism is used to > support AEAD ciphers. > > Now, EC and GCM algorithms are supported in JDK crypto providers. The > hard-coded checking can get improved. This fix updates: > 1. remove the dynamically checking of cipher suite availability. > 2. remove the cipher suite availability cache accordingly (need no > synchronization accordingly) > 3. other updates that impact by the availability checking. > > The performance improvement is tested with the following simple case. > Run the following code 1000, 2000, 3000 times in single thread mode and > measure the millisecond for each: > > --------- > String[] cipherSuites = > {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; > for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 > SSLEngine engine = SSLContext.getDefault().createSSLEngine(); > engine.getEnabledCipherSuites(); > engine.getSupportedCipherSuites(); > } > --------- > > The milliseconds for each test case (less is better) look like: > > loops | old | fixed > ---------+---------+---------- > 1000 | 2736 | 735 > ---------+---------+---------- > 2000 | 3718 | 746 > ---------+---------+---------- > 3000 | 4750 | 765 > ---------+---------+---------- > > This fix improves the performance. > > The existing regression testing get passed. No new regression test is > planned as this is a performance enhancement fix. > > Thanks, > Xuelei > From xuelei.fan at oracle.com Tue Dec 15 03:08:43 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Dec 2015 11:08:43 +0800 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable In-Reply-To: <566F2584.5070502@oracle.com> References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com> Message-ID: <566F843B.4090605@oracle.com> On 12/15/2015 4:24 AM, Sean Mullan wrote: > Hi Xuelei, > > For JDK 9, the EC impl is defined to be in its own module > (jdk.crypto.ec). How does it affect this fix if that module is not > available/installed? > The SunJSSE provider would not support dynamically loading of crypto providers/modules. At present, there are two providers that supports EC implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11). If no EC provider, EC cipher suites would not be available to use. That's to say, EC cipher suites would not be enabled by default, and cannot be used for handshaking. In the fix, JsseJce#EcAvailability.isAvailable is used to check the availability of EC crypto impl. Xuelei > --Sean > > On 12/01/2015 07:49 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the fix for JDK-8133070: >> >> http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ >> >> In (Open)JDK 6, EC cipher suites get supported by Java. However, there >> is no default EC provider in JDK 6 at that time. In order to support >> third part's EC algorithm JCE provider dynamically, it is hard-coded to >> check the cipher suite availability dynamically for EC algorithms in >> SunJSSE provider. >> >> Here is an example update in CipherSuite.java for the checking: >> >> - static final boolean DYNAMIC_AVAILABILITY = false; >> + static final boolean DYNAMIC_AVAILABILITY = true; >> >> The dynamically checking impacts the performance significantly as: >> 1. the check of the availability is expensive as it involves crypto >> operations. >> 2. a cache is used to maintain the availability of bulk ciphers in order >> to mitigate the #1 performance impact. However, access and update to >> the cache need to be synchronized. >> 3. in order to support dynamically checking, the cache may be cleared if >> a particular cipher is not found or a new SSLContext is generated. As >> bring the performance impact of #1 back again. >> >> Later, AEAD algorithm is defined by Java. The same mechanism is used to >> support AEAD ciphers. >> >> Now, EC and GCM algorithms are supported in JDK crypto providers. The >> hard-coded checking can get improved. This fix updates: >> 1. remove the dynamically checking of cipher suite availability. >> 2. remove the cipher suite availability cache accordingly (need no >> synchronization accordingly) >> 3. other updates that impact by the availability checking. >> >> The performance improvement is tested with the following simple case. >> Run the following code 1000, 2000, 3000 times in single thread mode and >> measure the millisecond for each: >> >> --------- >> String[] cipherSuites = >> {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; >> for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 >> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >> engine.getEnabledCipherSuites(); >> engine.getSupportedCipherSuites(); >> } >> --------- >> >> The milliseconds for each test case (less is better) look like: >> >> loops | old | fixed >> ---------+---------+---------- >> 1000 | 2736 | 735 >> ---------+---------+---------- >> 2000 | 3718 | 746 >> ---------+---------+---------- >> 3000 | 4750 | 765 >> ---------+---------+---------- >> >> This fix improves the performance. >> >> The existing regression testing get passed. No new regression test is >> planned as this is a performance enhancement fix. >> >> Thanks, >> Xuelei >> From xuelei.fan at oracle.com Tue Dec 15 05:40:24 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Dec 2015 13:40:24 +0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE Message-ID: <566FA7C8.9050009@oracle.com> Hi, Please this enhancement to the JSSE implementation: http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ This change will add support for the SHA224withDSA and SHA256withDSA algorithms in the TLS "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. Thanks, Xuelei From xuelei.fan at oracle.com Tue Dec 15 05:47:20 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Dec 2015 13:47:20 +0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <566FA7C8.9050009@oracle.com> References: <566FA7C8.9050009@oracle.com> Message-ID: <566FA968.4000609@oracle.com> On 12/15/2015 1:40 PM, Xuelei Fan wrote: > Hi, > > Please this enhancement to the JSSE implementation: > Please review this enhancement to the JSSE implementation: > http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ > > This change will add support for the SHA224withDSA and SHA256withDSA > algorithms in the TLS "signature_algorithms" extension in the SunJSSE > provider. Note that this extension does not apply to TLS 1.1 and > previous versions. > > Thanks, > Xuelei > From weijun.wang at oracle.com Tue Dec 15 08:09:51 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 15 Dec 2015 16:09:51 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <566EE8C1.90700@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> <566EE8C1.90700@oracle.com> Message-ID: <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> Good. But the builder will not provide default values so you will see new DrbgParameters.Builder().build().getAlgorithm() == null which means the getters still return requested values. In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG. --Max > On Dec 15, 2015, at 12:05 AM, Sean Mullan wrote: > > The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters: > > DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null); > > That seems awkward, and you have be overly careful to map the right value to each parameter. > > I think this is a case where a DrbgParameters.Builder would be very useful. > > --Sean From sean.mullan at oracle.com Tue Dec 15 15:53:45 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Dec 2015 10:53:45 -0500 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com> References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com> Message-ID: <56703789.7060908@oracle.com> On 12/03/2015 09:07 PM, Wang Weijun wrote: > Or if this is too much, we can at least do the X509Extension part. If > CertificateRequest is needed one day, we can create a new method > Builder.certificateRequest() that returns it and deprecate the > current request() method. > > Or use certificateRequest() to return byte[] and save request() for > the future. :-) I agree with this approach. I like the idea of moving the creation of Extensions to X509Extension so that they could be used independently of the X509Certificate.Builder API. Let's defer a CertificateRequest API for later. --Sean > > --Max > >> On Dec 3, 2015, at 8:21 PM, larry mccay >> wrote: >> >> +1 :) >> >> On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun >> wrote: I tried. >> >> It's quite easy to move the new X509CertificateBuilder class into >> java.security.cert.X509Certificate as an inner class, but I still >> want to make Extension and CertificateRequest better. > > ... > >> >> All these sound straightforward, worth doing? >> >> Thanks Max >> >> >> > From sean.mullan at oracle.com Tue Dec 15 21:43:14 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Dec 2015 16:43:14 -0500 Subject: RFR: 8129567 - the GCM mode parameter which is used as the initialization vector ("IV") is set to all zeros In-Reply-To: References: Message-ID: <56708972.6030306@oracle.com> This fix looks fine to me. Please add a "noreg-self" label to the bug. --Sean On 12/11/2015 05:50 AM, Bhanu Gopularam wrote: > Hi all, > > Please review a fix for following bug: > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129567 > > Issue ? Few tests are using all zero IV for GCM parameter spec which > gives CRYPTO_MECHANISM_PARAM_INVALID error > > On certain platforms > > Solution ? Use a random IV in GCMParameterSpec in the tests > > webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129567/webrev.00/ > > Thanks, > > Bhanu > From sean.mullan at oracle.com Tue Dec 15 22:19:31 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Dec 2015 17:19:31 -0500 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> <566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> Message-ID: <567091F3.7000200@oracle.com> On 12/15/2015 03:09 AM, Wang Weijun wrote: > Good. > > But the builder will not provide default values so you will see > > new DrbgParameters.Builder().build().getAlgorithm() == null > > which means the getters still return requested values. That's fine, this is no different than what the current class does. --Sean > In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG. > > --Max > >> On Dec 15, 2015, at 12:05 AM, Sean Mullan wrote: >> >> The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters: >> >> DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null); >> >> That seems awkward, and you have be overly careful to map the right value to each parameter. >> >> I think this is a case where a DrbgParameters.Builder would be very useful. >> >> --Sean > From weijun.wang at oracle.com Wed Dec 16 02:26:19 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Dec 2015 10:26:19 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: <56703789.7060908@oracle.com> References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com> <56703789.7060908@oracle.com> Message-ID: Hi All Here is an updated webrev http://cr.openjdk.java.net/~weijun/8058778/webrev.05/ Spec change is at http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html These changes are made: 1. The Builder is moved into java.security.cert.X509Certificate as an inner class 2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment. 3. keytool directly calls X509Certificate.Builder now. No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded. Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed. --Max > On Dec 15, 2015, at 11:53 PM, Sean Mullan wrote: > > On 12/03/2015 09:07 PM, Wang Weijun wrote: >> Or if this is too much, we can at least do the X509Extension part. If >> CertificateRequest is needed one day, we can create a new method >> Builder.certificateRequest() that returns it and deprecate the >> current request() method. >> >> Or use certificateRequest() to return byte[] and save request() for >> the future. :-) > > I agree with this approach. I like the idea of moving the creation of Extensions to X509Extension so that they could be used independently of the X509Certificate.Builder API. Let's defer a CertificateRequest API for later. > > --Sean From weijun.wang at oracle.com Wed Dec 16 07:20:41 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 16 Dec 2015 15:20:41 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <567091F3.7000200@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> <566EE8C1.90700@oracle.com> <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com> <567091F3.7000200@oracle.com> Message-ID: <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com> Webrev updated: http://cr.openjdk.java.net/~weijun/8051408/webrev.02/ http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html Changes: 1. DrbgParameters has a Builder now 2. No more default implementation for reseed() 3. Synchronization is now inside implementation, on engineXXX() methods 4. engineConfigure() now throws InvalidAlgorithmParameterException instead of IllegalArgumentException 5. CtrDRBG uses up all input in engineSetSeed() Thanks Max > On Dec 16, 2015, at 6:19 AM, Sean Mullan wrote: > > On 12/15/2015 03:09 AM, Wang Weijun wrote: >> Good. >> >> But the builder will not provide default values so you will see >> >> new DrbgParameters.Builder().build().getAlgorithm() == null >> >> which means the getters still return requested values. > > That's fine, this is no different than what the current class does. > > --Sean > >> In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG. >> >> --Max >> >>> On Dec 15, 2015, at 12:05 AM, Sean Mullan wrote: >>> >>> The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters: >>> >>> DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null); >>> >>> That seems awkward, and you have be overly careful to map the right value to each parameter. >>> >>> I think this is a case where a DrbgParameters.Builder would be very useful. >>> >>> --Sean >> From bradford.wetmore at oracle.com Wed Dec 16 19:14:08 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Dec 2015 11:14:08 -0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <566FA968.4000609@oracle.com> References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com> Message-ID: <5671B800.3080203@oracle.com> The change itself looks ok, but a question on the previous code. 420: Why is SHA224 disabled when SunMSCAPI is present? Or alternatively, why is SHA224 enabled when SunMSCAPI not present? Shouldn't this be based on whether there is a SHA224 implementation available? And if so, why are we not verifying that an implementation exists (getInstance("SHA256") doesn't throw exception) for the other algorithms also (SHA1/RSA/etc)? The synopsis should probably be: Support SHA224withDSA/SHA256withDSA in TLSv1.2 \ signature_algorithms extension Also, note the case of the "W" in "SHA256WithDSA". Brad On 12/14/2015 9:47 PM, Xuelei Fan wrote: > On 12/15/2015 1:40 PM, Xuelei Fan wrote: >> Hi, >> >> Please this enhancement to the JSSE implementation: >> > Please review this enhancement to the JSSE implementation: > >> http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ >> >> This change will add support for the SHA224withDSA and SHA256withDSA >> algorithms in the TLS "signature_algorithms" extension in the SunJSSE >> provider. Note that this extension does not apply to TLS 1.1 and >> previous versions. >> >> Thanks, >> Xuelei >> > From bradford.wetmore at oracle.com Wed Dec 16 19:19:01 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Dec 2015 11:19:01 -0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <5671B800.3080203@oracle.com> References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com> <5671B800.3080203@oracle.com> Message-ID: <5671B925.3030204@oracle.com> On 12/16/2015 11:14 AM, Bradford Wetmore wrote: > The synopsis should probably be: > > Support SHA224withDSA/SHA256withDSA in TLSv1.2 \ > signature_algorithms extension > > Also, note the case of the "W" in "SHA256WithDSA". Ignore these last two points, they've already been updated in the bug. Brad > Brad > > > On 12/14/2015 9:47 PM, Xuelei Fan wrote: >> On 12/15/2015 1:40 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Please this enhancement to the JSSE implementation: >>> >> Please review this enhancement to the JSSE implementation: >> >>> http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ >>> >>> This change will add support for the SHA224withDSA and SHA256withDSA >>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE >>> provider. Note that this extension does not apply to TLS 1.1 and >>> previous versions. >>> >>> Thanks, >>> Xuelei >>> >> From xuelei.fan at oracle.com Wed Dec 16 23:22:00 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Dec 2015 07:22:00 +0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <5671B800.3080203@oracle.com> References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com> <5671B800.3080203@oracle.com> Message-ID: <5671F218.6080608@oracle.com> On 12/17/2015 3:14 AM, Bradford Wetmore wrote: > The change itself looks ok, but a question on the previous code. > > 420: Why is SHA224 disabled when SunMSCAPI is present? Or > alternatively, why is SHA224 enabled when SunMSCAPI not present? SunMSCAPI does not support SHA-224 yet. > Shouldn't this be based on whether there is a SHA224 implementation > available? The SHA-224 is always available with JDK providers. But SHA224withRSA and SHA224withDSA does not work for SunMSCAPI. So we need to filter out SHA-224 for SunMSCAPI. > And if so, why are we not verifying that an implementation > exists (getInstance("SHA256") doesn't throw exception) for the other > algorithms also (SHA1/RSA/etc)? > Need to check the full signature name. But no checking at present as these algorithms are supported by JDK providers except the SHA-224 based ones. May make improvement later. Thanks, Xuelei > The synopsis should probably be: > > Support SHA224withDSA/SHA256withDSA in TLSv1.2 \ > signature_algorithms extension > > Also, note the case of the "W" in "SHA256WithDSA". > > Brad > > > On 12/14/2015 9:47 PM, Xuelei Fan wrote: >> On 12/15/2015 1:40 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Please this enhancement to the JSSE implementation: >>> >> Please review this enhancement to the JSSE implementation: >> >>> http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ >>> >>> This change will add support for the SHA224withDSA and SHA256withDSA >>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE >>> provider. Note that this extension does not apply to TLS 1.1 and >>> previous versions. >>> >>> Thanks, >>> Xuelei >>> >> From bradford.wetmore at oracle.com Wed Dec 16 23:52:39 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Dec 2015 15:52:39 -0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <5671F218.6080608@oracle.com> References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com> <5671B800.3080203@oracle.com> <5671F218.6080608@oracle.com> Message-ID: <5671F947.7000500@oracle.com> On 12/16/2015 3:22 PM, Xuelei Fan wrote: > On 12/17/2015 3:14 AM, Bradford Wetmore wrote: >> The change itself looks ok, but a question on the previous code. >> >> 420: Why is SHA224 disabled when SunMSCAPI is present? Or >> alternatively, why is SHA224 enabled when SunMSCAPI not present? > SunMSCAPI does not support SHA-224 yet. That was my guess, however... >> Shouldn't this be based on whether there is a SHA224 implementation >> available? > The SHA-224 is always available with JDK providers. But SHA224withRSA > and SHA224withDSA does not work for SunMSCAPI. So we need to filter out > SHA-224 for SunMSCAPI. if (Security.getProvider("SunMSCAPI") == null) { supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, "SHA224withDSA", --p); Those two algs are always being filtered out regardless of whether other providers might support it. For all platforms, the Sun provider is available for SHA224withDSA/SHA256withDSA, right? map.put("Signature.SHA224withDSA", "sun.security.provider.DSA$SHA224withDSA"); map.put("Signature.SHA256withDSA", "sun.security.provider.DSA$SHA256withDSA"); So if SunMSCAPI is registered as an active provider (on a Windows platform), SHA224/SHA256 will be disabled. This doesn't seem right. >> And if so, why are we not verifying that an implementation >> exists (getInstance("SHA256") doesn't throw exception) for the other >> algorithms also (SHA1/RSA/etc)? >> > Need to check the full signature name. But no checking at present as > these algorithms are supported by JDK providers except the SHA-224 based > ones. May make improvement later. This does require that at least the Sun provider always be available then. Brad > > Thanks, > Xuelei > >> The synopsis should probably be: >> >> Support SHA224withDSA/SHA256withDSA in TLSv1.2 \ >> signature_algorithms extension >> >> Also, note the case of the "W" in "SHA256WithDSA". >> >> Brad >> >> >> On 12/14/2015 9:47 PM, Xuelei Fan wrote: >>> On 12/15/2015 1:40 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please this enhancement to the JSSE implementation: >>>> >>> Please review this enhancement to the JSSE implementation: >>> >>>> http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ >>>> >>>> This change will add support for the SHA224withDSA and SHA256withDSA >>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE >>>> provider. Note that this extension does not apply to TLS 1.1 and >>>> previous versions. >>>> >>>> Thanks, >>>> Xuelei >>>> >>> > From xuelei.fan at oracle.com Thu Dec 17 06:51:43 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Dec 2015 14:51:43 +0800 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <5671F947.7000500@oracle.com> References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com> <5671B800.3080203@oracle.com> <5671F218.6080608@oracle.com> <5671F947.7000500@oracle.com> Message-ID: <56725B7F.6090806@oracle.com> On 12/17/2015 7:52 AM, Bradford Wetmore wrote: > > > On 12/16/2015 3:22 PM, Xuelei Fan wrote: >> On 12/17/2015 3:14 AM, Bradford Wetmore wrote: >>> The change itself looks ok, but a question on the previous code. >>> >>> 420: Why is SHA224 disabled when SunMSCAPI is present? Or >>> alternatively, why is SHA224 enabled when SunMSCAPI not present? >> SunMSCAPI does not support SHA-224 yet. > > That was my guess, however... > >>> Shouldn't this be based on whether there is a SHA224 implementation >>> available? >> The SHA-224 is always available with JDK providers. But SHA224withRSA >> and SHA224withDSA does not work for SunMSCAPI. So we need to filter out >> SHA-224 for SunMSCAPI. > > if (Security.getProvider("SunMSCAPI") == null) { > supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, > "SHA224withDSA", --p); > > Those two algs are always being filtered out regardless of whether other > providers might support it. For all platforms, the Sun provider is > available for SHA224withDSA/SHA256withDSA, right? > > map.put("Signature.SHA224withDSA", > "sun.security.provider.DSA$SHA224withDSA"); > map.put("Signature.SHA256withDSA", > "sun.security.provider.DSA$SHA256withDSA"); > > So if SunMSCAPI is registered as an active provider (on a Windows > platform), SHA224/SHA256 will be disabled. This doesn't seem right. > Right. It is a compromise solution to remove SHA224 completely, even other providers support it. If SHA224withRSA is enabled, and SunMSCAPI is preferred at the same time, there is a problem per current implementation. During TLS handshaking process, RSA private will be used in SunMSCAPI provider at first (for example, for server authentication cert), and then SHA224withRSA in other providers (Say SunJCE) will be used for signature. However, as the RSA private key is in MSCAPI, no way to use SHA224withRSA in providers other than SunMSCAP. Problem happens, see JDK-8064330. We might want to take SHA224withRSA back later if required. >>> And if so, why are we not verifying that an implementation >>> exists (getInstance("SHA256") doesn't throw exception) for the other >>> algorithms also (SHA1/RSA/etc)? >>> >> Need to check the full signature name. But no checking at present as >> these algorithms are supported by JDK providers except the SHA-224 based >> ones. May make improvement later. > > This does require that at least the Sun provider always be available then. > May be, if SunJCE is used. Thanks, Xuelei > Brad > > > >> >> Thanks, >> Xuelei >> >>> The synopsis should probably be: >>> >>> Support SHA224withDSA/SHA256withDSA in TLSv1.2 \ >>> signature_algorithms extension >>> >>> Also, note the case of the "W" in "SHA256WithDSA". >>> >>> Brad >>> >>> >>> On 12/14/2015 9:47 PM, Xuelei Fan wrote: >>>> On 12/15/2015 1:40 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please this enhancement to the JSSE implementation: >>>>> >>>> Please review this enhancement to the JSSE implementation: >>>> >>>>> http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ >>>>> >>>>> This change will add support for the SHA224withDSA and SHA256withDSA >>>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE >>>>> provider. Note that this extension does not apply to TLS 1.1 and >>>>> previous versions. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>> >> From mandy.chung at oracle.com Thu Dec 17 07:26:08 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Dec 2015 23:26:08 -0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com> <56703789.7060908@oracle.com> Message-ID: <15164C87-44AC-4422-9427-4B7EB1A7093D@oracle.com> Hi Max, Very high level comments: - Builder::selfSign and Builder::sign are the two methods building the X509Certificate. Both @throws java.lang.IllegalStateException - if the builder is initialized with one of the asCA methods It reads to me that there is no other method to generate a certificate from a builder created from Builder::fromKeyPair factory method. - is clearExtensions needed only for reusing the Builder? Would it be reasonable to require it to create a Builder that I suppose it?s not too expensive? In that case, the clearExtensions is not needed. Extension::newSubjectAlternativeNameExtension(boolean isCritical, List... names) Extension::newIssuerAlternativeNameExtension(boolean isCritical, List... names) Extension::newSubjectInformationAccessExtension(List... accessDescriptions) Extension::newAuthorityInformationAccessExtension(List... accessDescriptions) - this takes List with 3 entries, each of which is of a specified type. There may be other better alternatives to define this API. A builder may fit well that can take 3 parameters for each name/accessDescription such that it can be statically checked. Have you considered other options? Mandy > On Dec 15, 2015, at 6:26 PM, Wang Weijun wrote: > > Hi All > > Here is an updated webrev > > http://cr.openjdk.java.net/~weijun/8058778/webrev.05/ > > Spec change is at > > http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html > > These changes are made: > > 1. The Builder is moved into java.security.cert.X509Certificate as an inner class > > 2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment. > > 3. keytool directly calls X509Certificate.Builder now. > > No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded. > > Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed. > > --Max > From weijun.wang at oracle.com Thu Dec 17 07:48:30 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Dec 2015 15:48:30 +0800 Subject: RFR 8058778: New APIs for some keytool functions In-Reply-To: <15164C87-44AC-4422-9427-4B7EB1A7093D@oracle.com> References: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com> <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com> <56703789.7060908@oracle.com> <15164C87-44AC-4422-9427-4B7EB1A7093D@oracle.com> Message-ID: > On Dec 17, 2015, at 3:26 PM, Mandy Chung wrote: > > Hi Max, > > Very high level comments: > - Builder::selfSign and Builder::sign are the two methods building the X509Certificate. > > Both @throws java.lang.IllegalStateException - if the builder is initialized with one of the asCA methods > > It reads to me that there is no other method to generate a certificate from a builder created from Builder::fromKeyPair factory method. Not sure what you are asking about. selfSign() returns a self-signed certificate. If you want to get a CA-signed one, you run certificateRequest() and send the output byte[] to an asCA Builder and that builder can sign() it. > > - is clearExtensions needed only for reusing the Builder? Yes. > Would it be reasonable to require it to create a Builder that I suppose it?s not too expensive? In that case, the clearExtensions is not needed. Sounds correct. > > Extension::newSubjectAlternativeNameExtension(boolean isCritical, List... names) > Extension::newIssuerAlternativeNameExtension(boolean isCritical, List... names) > Extension::newSubjectInformationAccessExtension(List... accessDescriptions) > Extension::newAuthorityInformationAccessExtension(List... accessDescriptions) > - this takes List with 3 entries, each of which is of a specified type. > > There may be other better alternatives to define this API. A builder may fit well that can take 3 parameters for each name/accessDescription such that it can be statically checked. Have you considered other options? I designed the methods to be consistent with X509Certificate methods, like Collection> getSubjectAlternativeNames() and secretly hoped that if people can live with these methods they can also live with my new ones. I know it's ugly but if enhanced I am not sure how far I should go. Should it be these? interface GeneralName {} static GeneralName newURIName(URI); static GeneralName newDnsName(String host); ... static newSubjectAlternativeNameExtension(boolean isCritical, GenralName... names); class AccessDescription { String oidMethods, GeneralName location); static newAuthorityInformationAccessExtension(AccessDescription... accessDescriptions); I tried it but I don't like inventing too many new classes. Thanks Max > > Mandy > > >> On Dec 15, 2015, at 6:26 PM, Wang Weijun wrote: >> >> Hi All >> >> Here is an updated webrev >> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.05/ >> >> Spec change is at >> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html >> >> These changes are made: >> >> 1. The Builder is moved into java.security.cert.X509Certificate as an inner class >> >> 2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment. >> >> 3. keytool directly calls X509Certificate.Builder now. >> >> No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded. >> >> Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed. >> >> --Max >> > From bhanu.prakash.gopularam at oracle.com Fri Dec 18 05:41:11 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Thu, 17 Dec 2015 21:41:11 -0800 (PST) Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 In-Reply-To: References: Message-ID: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default> Hi all, Please review a fix for following bug: Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560 Issue - Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is failing because RSAKeyGenParameterSpec public exponent is not accordance with FIPS 186-4 guidance Solution - Used proper value for exponent based on reference from FIPS 186-4, section B-2. webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/ Thanks, Bhanu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Dec 18 15:35:04 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Dec 2015 10:35:04 -0500 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable In-Reply-To: <566F843B.4090605@oracle.com> References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com> <566F843B.4090605@oracle.com> Message-ID: <567427A8.5000105@oracle.com> Here are a few other other comments on the code: SSLContextImpl: - I noticed that SSLContext.init does not specify how it handles empty arrays, and you have changed the code so that an empty TrustManager array is treated like they are null - is this change in behavior a compatibility issue at all? Could you file a follow-on issue to clarify the behavior of SSLContext.init as to how it should handle empty arrays? - are there any race conditions that you need to worry about now that you have removed the synchronized blocks from getSupportedCipherSuiteList and getDefaultCipherSuite? - on lines 781 and 789, an empty array is created and discarded if there is not an exception thrown. It would be better to only create the empty array when an exception is thrown (move it into the catch block). --Sean On 12/14/2015 10:08 PM, Xuelei Fan wrote: > On 12/15/2015 4:24 AM, Sean Mullan wrote: >> Hi Xuelei, >> >> For JDK 9, the EC impl is defined to be in its own module >> (jdk.crypto.ec). How does it affect this fix if that module is not >> available/installed? >> > The SunJSSE provider would not support dynamically loading of crypto > providers/modules. At present, there are two providers that supports EC > implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11). > If no EC provider, EC cipher suites would not be available to use. > That's to say, EC cipher suites would not be enabled by default, and > cannot be used for handshaking. In the fix, > JsseJce#EcAvailability.isAvailable is used to check the availability of > EC crypto impl. > > Xuelei > >> --Sean >> >> On 12/01/2015 07:49 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the fix for JDK-8133070: >>> >>> http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ >>> >>> In (Open)JDK 6, EC cipher suites get supported by Java. However, there >>> is no default EC provider in JDK 6 at that time. In order to support >>> third part's EC algorithm JCE provider dynamically, it is hard-coded to >>> check the cipher suite availability dynamically for EC algorithms in >>> SunJSSE provider. >>> >>> Here is an example update in CipherSuite.java for the checking: >>> >>> - static final boolean DYNAMIC_AVAILABILITY = false; >>> + static final boolean DYNAMIC_AVAILABILITY = true; >>> >>> The dynamically checking impacts the performance significantly as: >>> 1. the check of the availability is expensive as it involves crypto >>> operations. >>> 2. a cache is used to maintain the availability of bulk ciphers in order >>> to mitigate the #1 performance impact. However, access and update to >>> the cache need to be synchronized. >>> 3. in order to support dynamically checking, the cache may be cleared if >>> a particular cipher is not found or a new SSLContext is generated. As >>> bring the performance impact of #1 back again. >>> >>> Later, AEAD algorithm is defined by Java. The same mechanism is used to >>> support AEAD ciphers. >>> >>> Now, EC and GCM algorithms are supported in JDK crypto providers. The >>> hard-coded checking can get improved. This fix updates: >>> 1. remove the dynamically checking of cipher suite availability. >>> 2. remove the cipher suite availability cache accordingly (need no >>> synchronization accordingly) >>> 3. other updates that impact by the availability checking. >>> >>> The performance improvement is tested with the following simple case. >>> Run the following code 1000, 2000, 3000 times in single thread mode and >>> measure the millisecond for each: >>> >>> --------- >>> String[] cipherSuites = >>> {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; >>> for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 >>> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>> engine.getEnabledCipherSuites(); >>> engine.getSupportedCipherSuites(); >>> } >>> --------- >>> >>> The milliseconds for each test case (less is better) look like: >>> >>> loops | old | fixed >>> ---------+---------+---------- >>> 1000 | 2736 | 735 >>> ---------+---------+---------- >>> 2000 | 3718 | 746 >>> ---------+---------+---------- >>> 3000 | 4750 | 765 >>> ---------+---------+---------- >>> >>> This fix improves the performance. >>> >>> The existing regression testing get passed. No new regression test is >>> planned as this is a performance enhancement fix. >>> >>> Thanks, >>> Xuelei >>> > From sean.mullan at oracle.com Fri Dec 18 20:20:20 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Dec 2015 15:20:20 -0500 Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 In-Reply-To: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default> References: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default> Message-ID: <56746A84.60106@oracle.com> The fix looks good, although this test is already on the ProblemList due to JDK-8074580. Do you know if that bug is caused by the same issue? The underlying PKCS11 error is different (maybe due to a different Solaris version?), but it looks like an identical stack trace. It would be good to also remove it from the ProblemList and close the other bug if it is a duplicate issue. --Sean On 12/18/2015 12:41 AM, Bhanu Gopularam wrote: > Hi all, > > Please review a fix for following bug: > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560 > > Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is > failing because RSAKeyGenParameterSpec > > public exponent is not accordance with FIPS 186-4 guidance > > Solution ? Used proper value for exponent based on reference from FIPS > 186-4, section B-2. > > webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/ > > Thanks, > > Bhanu > From sean.mullan at oracle.com Fri Dec 18 21:04:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Dec 2015 16:04:16 -0500 Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE In-Reply-To: <56725B7F.6090806@oracle.com> References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com> <5671B800.3080203@oracle.com> <5671F218.6080608@oracle.com> <5671F947.7000500@oracle.com> <56725B7F.6090806@oracle.com> Message-ID: <567474D0.5060207@oracle.com> This explanation makes sense to me and the fix looks fine. --Sean On 12/17/2015 01:51 AM, Xuelei Fan wrote: > On 12/17/2015 7:52 AM, Bradford Wetmore wrote: >> >> >> On 12/16/2015 3:22 PM, Xuelei Fan wrote: >>> On 12/17/2015 3:14 AM, Bradford Wetmore wrote: >>>> The change itself looks ok, but a question on the previous code. >>>> >>>> 420: Why is SHA224 disabled when SunMSCAPI is present? Or >>>> alternatively, why is SHA224 enabled when SunMSCAPI not present? >>> SunMSCAPI does not support SHA-224 yet. >> >> That was my guess, however... >> >>>> Shouldn't this be based on whether there is a SHA224 implementation >>>> available? >>> The SHA-224 is always available with JDK providers. But SHA224withRSA >>> and SHA224withDSA does not work for SunMSCAPI. So we need to filter out >>> SHA-224 for SunMSCAPI. >> >> if (Security.getProvider("SunMSCAPI") == null) { >> supports(HashAlgorithm.SHA224, SignatureAlgorithm.DSA, >> "SHA224withDSA", --p); >> >> Those two algs are always being filtered out regardless of whether other >> providers might support it. For all platforms, the Sun provider is >> available for SHA224withDSA/SHA256withDSA, right? >> >> map.put("Signature.SHA224withDSA", >> "sun.security.provider.DSA$SHA224withDSA"); >> map.put("Signature.SHA256withDSA", >> "sun.security.provider.DSA$SHA256withDSA"); >> >> So if SunMSCAPI is registered as an active provider (on a Windows >> platform), SHA224/SHA256 will be disabled. This doesn't seem right. >> > Right. It is a compromise solution to remove SHA224 completely, even > other providers support it. If SHA224withRSA is enabled, and SunMSCAPI > is preferred at the same time, there is a problem per current > implementation. During TLS handshaking process, RSA private will be > used in SunMSCAPI provider at first (for example, for server > authentication cert), and then SHA224withRSA in other providers (Say > SunJCE) will be used for signature. However, as the RSA private key is > in MSCAPI, no way to use SHA224withRSA in providers other than SunMSCAP. > Problem happens, see JDK-8064330. > > We might want to take SHA224withRSA back later if required. > >>>> And if so, why are we not verifying that an implementation >>>> exists (getInstance("SHA256") doesn't throw exception) for the other >>>> algorithms also (SHA1/RSA/etc)? >>>> >>> Need to check the full signature name. But no checking at present as >>> these algorithms are supported by JDK providers except the SHA-224 based >>> ones. May make improvement later. >> >> This does require that at least the Sun provider always be available then. >> > May be, if SunJCE is used. > > Thanks, > Xuelei > >> Brad >> >> >> >>> >>> Thanks, >>> Xuelei >>> >>>> The synopsis should probably be: >>>> >>>> Support SHA224withDSA/SHA256withDSA in TLSv1.2 \ >>>> signature_algorithms extension >>>> >>>> Also, note the case of the "W" in "SHA256WithDSA". >>>> >>>> Brad >>>> >>>> >>>> On 12/14/2015 9:47 PM, Xuelei Fan wrote: >>>>> On 12/15/2015 1:40 PM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Please this enhancement to the JSSE implementation: >>>>>> >>>>> Please review this enhancement to the JSSE implementation: >>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ >>>>>> >>>>>> This change will add support for the SHA224withDSA and SHA256withDSA >>>>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE >>>>>> provider. Note that this extension does not apply to TLS 1.1 and >>>>>> previous versions. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>> >>> > From anthony.scarpino at oracle.com Fri Dec 18 22:03:34 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 18 Dec 2015 14:03:34 -0800 Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 In-Reply-To: <56746A84.60106@oracle.com> References: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default> <56746A84.60106@oracle.com> Message-ID: The problems are different. The PKCS11 error means everything in this case. Tony > On Dec 18, 2015, at 12:20 PM, Sean Mullan wrote: > > The fix looks good, although this test is already on the ProblemList due to JDK-8074580. Do you know if that bug is caused by the same issue? The underlying PKCS11 error is different (maybe due to a different Solaris version?), but it looks like an identical stack trace. It would be good to also remove it from the ProblemList and close the other bug if it is a duplicate issue. > > --Sean > >> On 12/18/2015 12:41 AM, Bhanu Gopularam wrote: >> Hi all, >> >> Please review a fix for following bug: >> >> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560 >> >> Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is >> failing because RSAKeyGenParameterSpec >> >> public exponent is not accordance with FIPS 186-4 guidance >> >> Solution ? Used proper value for exponent based on reference from FIPS >> 186-4, section B-2. >> >> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/ >> >> Thanks, >> >> Bhanu >> From xuelei.fan at oracle.com Sat Dec 19 16:06:24 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 20 Dec 2015 00:06:24 +0800 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable In-Reply-To: <567427A8.5000105@oracle.com> References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com> <566F843B.4090605@oracle.com> <567427A8.5000105@oracle.com> Message-ID: <56758080.1000703@oracle.com> new webrev: http://cr.openjdk.java.net/~xuelei/8133070/webrev.01/ Updates to webrev.00: Re-org the get methods of SSLContextImpl so as to avoid repeated initialization of instance fields. On 12/18/2015 11:35 PM, Sean Mullan wrote: > Here are a few other other comments on the code: > > SSLContextImpl: > - I noticed that SSLContext.init does not specify how it handles empty > arrays, and you have changed the code so that an empty TrustManager > array is treated like they are null - is this change in behavior a > compatibility issue at all? Could you file a follow-on issue to clarify > the behavior of SSLContext.init as to how it should handle empty arrays? > It's a bug of my update. Empty means no trust manager, which is different from using the default trust manager. I removed this update. > - are there any race conditions that you need to worry about now that > you have removed the synchronized blocks from > getSupportedCipherSuiteList and getDefaultCipherSuite? > May be initialized repeatedly. Should be OK as there is only one instance for the to-be-assigned value. The code can be more straightforward and effective. I moved the impls into sub-classes. > - on lines 781 and 789, an empty array is created and discarded if > there is not an exception thrown. It would be better to only create the > empty array when an exception is thrown (move it into the catch block). > Updated. Thanks, Xuelei > --Sean > > > On 12/14/2015 10:08 PM, Xuelei Fan wrote: >> On 12/15/2015 4:24 AM, Sean Mullan wrote: >>> Hi Xuelei, >>> >>> For JDK 9, the EC impl is defined to be in its own module >>> (jdk.crypto.ec). How does it affect this fix if that module is not >>> available/installed? >>> >> The SunJSSE provider would not support dynamically loading of crypto >> providers/modules. At present, there are two providers that supports EC >> implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11). >> If no EC provider, EC cipher suites would not be available to use. >> That's to say, EC cipher suites would not be enabled by default, and >> cannot be used for handshaking. In the fix, >> JsseJce#EcAvailability.isAvailable is used to check the availability of >> EC crypto impl. >> >> Xuelei >> >>> --Sean >>> >>> On 12/01/2015 07:49 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the fix for JDK-8133070: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ >>>> >>>> In (Open)JDK 6, EC cipher suites get supported by Java. However, there >>>> is no default EC provider in JDK 6 at that time. In order to support >>>> third part's EC algorithm JCE provider dynamically, it is hard-coded to >>>> check the cipher suite availability dynamically for EC algorithms in >>>> SunJSSE provider. >>>> >>>> Here is an example update in CipherSuite.java for the checking: >>>> >>>> - static final boolean DYNAMIC_AVAILABILITY = false; >>>> + static final boolean DYNAMIC_AVAILABILITY = true; >>>> >>>> The dynamically checking impacts the performance significantly as: >>>> 1. the check of the availability is expensive as it involves crypto >>>> operations. >>>> 2. a cache is used to maintain the availability of bulk ciphers in >>>> order >>>> to mitigate the #1 performance impact. However, access and update to >>>> the cache need to be synchronized. >>>> 3. in order to support dynamically checking, the cache may be >>>> cleared if >>>> a particular cipher is not found or a new SSLContext is generated. As >>>> bring the performance impact of #1 back again. >>>> >>>> Later, AEAD algorithm is defined by Java. The same mechanism is >>>> used to >>>> support AEAD ciphers. >>>> >>>> Now, EC and GCM algorithms are supported in JDK crypto providers. The >>>> hard-coded checking can get improved. This fix updates: >>>> 1. remove the dynamically checking of cipher suite availability. >>>> 2. remove the cipher suite availability cache accordingly (need no >>>> synchronization accordingly) >>>> 3. other updates that impact by the availability checking. >>>> >>>> The performance improvement is tested with the following simple case. >>>> Run the following code 1000, 2000, 3000 times in single thread mode and >>>> measure the millisecond for each: >>>> >>>> --------- >>>> String[] cipherSuites = >>>> {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; >>>> for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 >>>> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>>> engine.getEnabledCipherSuites(); >>>> engine.getSupportedCipherSuites(); >>>> } >>>> --------- >>>> >>>> The milliseconds for each test case (less is better) look like: >>>> >>>> loops | old | fixed >>>> ---------+---------+---------- >>>> 1000 | 2736 | 735 >>>> ---------+---------+---------- >>>> 2000 | 3718 | 746 >>>> ---------+---------+---------- >>>> 3000 | 4750 | 765 >>>> ---------+---------+---------- >>>> >>>> This fix improves the performance. >>>> >>>> The existing regression testing get passed. No new regression test is >>>> planned as this is a performance enhancement fix. >>>> >>>> Thanks, >>>> Xuelei >>>> >> From sibabrata.sahoo at oracle.com Sat Dec 19 20:04:26 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Sat, 19 Dec 2015 12:04:26 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> Message-ID: <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> Hi Mandy/Max, Please review the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/ "3rd party security providers" Test change includes: - Test are converted to use TestNG framework. - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository. - Common reusable operations moved to "SecurityUtils.java" - All the following comments associated. Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes: - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed. - Test converted to use TestNG framework. Thanks, Siba -----Original Message----- From: Mandy Chung Sent: Wednesday, December 09, 2015 11:55 PM To: Sibabrata Sahoo Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Some high-level comment: 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. Some comments on JigsawSecurityUtils.java: 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); this can be replaced with Arrays.stream(options).collect(Collectors.joining(SPACE)); 111 System.out.println(String.format( You can do: System.out.format(?.) instead; Mandy [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java > On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: > > Hi Valerie, > > Here is the updated webrev: > http://cr.openjdk.java.net/~ntv/siba/webrev.00/ > > Changes applied as per previous comments. > - File names are modified and do not include the term JCE. > - Source folder structure is flat now and all belongs to "java/security/Provider" folder. > - Sign jar functionality removed. > > Thanks, > Siba > > -----Original Message----- > From: Valerie Peng > Sent: Wednesday, December 09, 2015 5:37 AM > To: Sibabrata Sahoo > Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan > Bateman > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security > providers if they are in signed/unsigned modular JARs > > Hi Siba, > > Here are some nits: > > I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. > Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). > You can remove a lot of code as a result. > Also, your directory seems a bit deep, e.g. > modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. > > Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? > > Thanks, > Valerie > > On 12/8/2015 2:04 PM, Valerie Peng wrote: >> Right, that'd be my expectation as well. Sounds like everything works. >> I will change to look at your latest webrev. >> Valerie >> >> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>> Hi Valerie, >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>> >>> Now the modular behavior for the test works as per expectation >>> through JAKE build with the following condition. >>> If the provider jar is available under ModulePath then the >>> "java.security" file should have the provider configuration entry as >>> ProviderName while in case of ClassPath the entry should hold the >>> full class name. >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Tuesday, December 08, 2015 4:46 AM >>> To: Sibabrata Sahoo >>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>> jigsaw-dev at openjdk.java.net >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> Siba, >>> >>> I have just started to review this webrev and not done yet. >>> As for your question, the java.security file in OpenJDK9 still uses >>> the provider class names instead of provider names. Are you talking >>> about the java.security file in Jigsaw? Which build (OpenJDK or >>> Jigsaw) have you tested against. I am pretty sure that I tested the >>> 3rd party provider on classpath setting when I worked on the 7191662 >>> changes. >>> >>> Supposedly, if the jar files are available on class path, then you >>> should specify its full *class name* in the java.security file for >>> it to be instantiated. Otherwise, how would it find the class? Only >>> the classes discovered by ServiceLoader can be identified using the >>> provider name (which is different from the class name referred >>> above). So, in your scenario, that would be >>> "provider.TestJCEProvider" instead of "TEST". >>> >>> If you still run into problems, try enable the java security debug >>> flag and u should get a good idea why it isn't loaded. Let me know >>> if you still have questions. >>> >>> Thanks, >>> Valerie >>> >>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>> I would like to know more about this. As far, I can see the >>>> "java.security" provider configuration available with JDK9, it >>>> holds provider names instead of provider class names. In that case >>>> how it resolve the fall back? >>>> >>>> Thanks, >>>> Siba >>>> >>>> -----Original Message----- >>>> From: Alan Bateman >>>> Sent: Monday, November 30, 2015 4:54 PM >>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>> jigsaw-dev at openjdk.java.net >>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>> security providers if they are in signed/unsigned modular JARs >>>> >>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>> >>>>> I have one question: >>>>> What should be the behavior when the older version of 3rd party >>>>> JCE provider jar file(without service descriptor >>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>> "java.security" file, will be place in CLASS_PATH, running through >>>>> JDK9 and the client is using Security.getProvider() to look for >>>>> the provider? >>>>> >>>>> Currently the scenario fails to find the JCE provider. Is this >>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>> find the security provider provided through older jar files from >>>>> CLASS_PATH. >>>>> >>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>> point by falling back and attempting to load the class name >>>> specified via the security.provider. properties in the >>>> java.security file. I'm sure Valerie can say more about this. >>>> >>>> -Alan From sibabrata.sahoo at oracle.com Sun Dec 20 06:10:51 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Sat, 19 Dec 2015 22:10:51 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> Message-ID: Hi Mandy/Max, Here is the updated webrev with very minor change over previous: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/ Thanks Siba -----Original Message----- From: Sibabrata Sahoo Sent: Sunday, December 20, 2015 1:34 AM To: Mandy Chung; Weijun Wang Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Hi Mandy/Max, Please review the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/ "3rd party security providers" Test change includes: - Test are converted to use TestNG framework. - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository. - Common reusable operations moved to "SecurityUtils.java" - All the following comments associated. Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes: - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed. - Test converted to use TestNG framework. Thanks, Siba -----Original Message----- From: Mandy Chung Sent: Wednesday, December 09, 2015 11:55 PM To: Sibabrata Sahoo Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Some high-level comment: 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. Some comments on JigsawSecurityUtils.java: 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); this can be replaced with Arrays.stream(options).collect(Collectors.joining(SPACE)); 111 System.out.println(String.format( You can do: System.out.format(?.) instead; Mandy [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java > On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: > > Hi Valerie, > > Here is the updated webrev: > http://cr.openjdk.java.net/~ntv/siba/webrev.00/ > > Changes applied as per previous comments. > - File names are modified and do not include the term JCE. > - Source folder structure is flat now and all belongs to "java/security/Provider" folder. > - Sign jar functionality removed. > > Thanks, > Siba > > -----Original Message----- > From: Valerie Peng > Sent: Wednesday, December 09, 2015 5:37 AM > To: Sibabrata Sahoo > Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan > Bateman > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security > providers if they are in signed/unsigned modular JARs > > Hi Siba, > > Here are some nits: > > I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. > Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). > You can remove a lot of code as a result. > Also, your directory seems a bit deep, e.g. > modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. > > Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? > > Thanks, > Valerie > > On 12/8/2015 2:04 PM, Valerie Peng wrote: >> Right, that'd be my expectation as well. Sounds like everything works. >> I will change to look at your latest webrev. >> Valerie >> >> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>> Hi Valerie, >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>> >>> Now the modular behavior for the test works as per expectation >>> through JAKE build with the following condition. >>> If the provider jar is available under ModulePath then the >>> "java.security" file should have the provider configuration entry as >>> ProviderName while in case of ClassPath the entry should hold the >>> full class name. >>> >>> Thanks, >>> Siba >>> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Tuesday, December 08, 2015 4:46 AM >>> To: Sibabrata Sahoo >>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>> jigsaw-dev at openjdk.java.net >>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>> providers if they are in signed/unsigned modular JARs >>> >>> Siba, >>> >>> I have just started to review this webrev and not done yet. >>> As for your question, the java.security file in OpenJDK9 still uses >>> the provider class names instead of provider names. Are you talking >>> about the java.security file in Jigsaw? Which build (OpenJDK or >>> Jigsaw) have you tested against. I am pretty sure that I tested the >>> 3rd party provider on classpath setting when I worked on the 7191662 >>> changes. >>> >>> Supposedly, if the jar files are available on class path, then you >>> should specify its full *class name* in the java.security file for >>> it to be instantiated. Otherwise, how would it find the class? Only >>> the classes discovered by ServiceLoader can be identified using the >>> provider name (which is different from the class name referred >>> above). So, in your scenario, that would be >>> "provider.TestJCEProvider" instead of "TEST". >>> >>> If you still run into problems, try enable the java security debug >>> flag and u should get a good idea why it isn't loaded. Let me know >>> if you still have questions. >>> >>> Thanks, >>> Valerie >>> >>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>> I would like to know more about this. As far, I can see the >>>> "java.security" provider configuration available with JDK9, it >>>> holds provider names instead of provider class names. In that case >>>> how it resolve the fall back? >>>> >>>> Thanks, >>>> Siba >>>> >>>> -----Original Message----- >>>> From: Alan Bateman >>>> Sent: Monday, November 30, 2015 4:54 PM >>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>> jigsaw-dev at openjdk.java.net >>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>> security providers if they are in signed/unsigned modular JARs >>>> >>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>> >>>>> I have one question: >>>>> What should be the behavior when the older version of 3rd party >>>>> JCE provider jar file(without service descriptor >>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>> "java.security" file, will be place in CLASS_PATH, running through >>>>> JDK9 and the client is using Security.getProvider() to look for >>>>> the provider? >>>>> >>>>> Currently the scenario fails to find the JCE provider. Is this >>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>> find the security provider provided through older jar files from >>>>> CLASS_PATH. >>>>> >>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>> point by falling back and attempting to load the class name >>>> specified via the security.provider. properties in the >>>> java.security file. I'm sure Valerie can say more about this. >>>> >>>> -Alan From weijun.wang at oracle.com Mon Dec 21 01:50:07 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Dec 2015 09:50:07 +0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> Message-ID: <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com> Tests are good. Several comments: 1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this. 2. It's not a good practice extending a class just to use its static fields/methods. Instead, make the util class final. public class JaasModularClientTest extends SecurityUtils public class SecurityProviderModularTest extends SecurityUtils In fact, if you do find similarities between SecurityProviderModularTest and JaasModularClientTest, try abstract them into a ModularTest class. 3. Please add enough comments to SecurityUtils since it will be reused. For example, move the descriptions of EXPLICIT, AUTO and UNNAMED from test @summary to definition of enum MODULE_TYPE. Thanks Max > On Dec 20, 2015, at 2:10 PM, Sibabrata Sahoo wrote: > > Hi Mandy/Max, > > Here is the updated webrev with very minor change over previous: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/ > > Thanks > Siba > > -----Original Message----- > From: Sibabrata Sahoo > Sent: Sunday, December 20, 2015 1:34 AM > To: Mandy Chung; Weijun Wang > Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > Hi Mandy/Max, > > Please review the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/ > > "3rd party security providers" Test change includes: > - Test are converted to use TestNG framework. > - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository. > - Common reusable operations moved to "SecurityUtils.java" > - All the following comments associated. > > > Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes: > - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed. > - Test converted to use TestNG framework. > > Thanks, > Siba > > -----Original Message----- > From: Mandy Chung > Sent: Wednesday, December 09, 2015 11:55 PM > To: Sibabrata Sahoo > Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > Some high-level comment: > 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. > 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. > > Some comments on JigsawSecurityUtils.java: > 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); > > this can be replaced with > Arrays.stream(options).collect(Collectors.joining(SPACE)); > > 111 System.out.println(String.format( > > You can do: System.out.format(?.) instead; > > Mandy > [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java > >> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: >> >> Hi Valerie, >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~ntv/siba/webrev.00/ >> >> Changes applied as per previous comments. >> - File names are modified and do not include the term JCE. >> - Source folder structure is flat now and all belongs to "java/security/Provider" folder. >> - Sign jar functionality removed. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Valerie Peng >> Sent: Wednesday, December 09, 2015 5:37 AM >> To: Sibabrata Sahoo >> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan >> Bateman >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Hi Siba, >> >> Here are some nits: >> >> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. >> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). >> You can remove a lot of code as a result. >> Also, your directory seems a bit deep, e.g. >> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. >> >> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? >> >> Thanks, >> Valerie >> >> On 12/8/2015 2:04 PM, Valerie Peng wrote: >>> Right, that'd be my expectation as well. Sounds like everything works. >>> I will change to look at your latest webrev. >>> Valerie >>> >>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>>> Hi Valerie, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>>> >>>> Now the modular behavior for the test works as per expectation >>>> through JAKE build with the following condition. >>>> If the provider jar is available under ModulePath then the >>>> "java.security" file should have the provider configuration entry as >>>> ProviderName while in case of ClassPath the entry should hold the >>>> full class name. >>>> >>>> Thanks, >>>> Siba >>>> >>>> -----Original Message----- >>>> From: Valerie Peng >>>> Sent: Tuesday, December 08, 2015 4:46 AM >>>> To: Sibabrata Sahoo >>>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>>> jigsaw-dev at openjdk.java.net >>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >>>> providers if they are in signed/unsigned modular JARs >>>> >>>> Siba, >>>> >>>> I have just started to review this webrev and not done yet. >>>> As for your question, the java.security file in OpenJDK9 still uses >>>> the provider class names instead of provider names. Are you talking >>>> about the java.security file in Jigsaw? Which build (OpenJDK or >>>> Jigsaw) have you tested against. I am pretty sure that I tested the >>>> 3rd party provider on classpath setting when I worked on the 7191662 >>>> changes. >>>> >>>> Supposedly, if the jar files are available on class path, then you >>>> should specify its full *class name* in the java.security file for >>>> it to be instantiated. Otherwise, how would it find the class? Only >>>> the classes discovered by ServiceLoader can be identified using the >>>> provider name (which is different from the class name referred >>>> above). So, in your scenario, that would be >>>> "provider.TestJCEProvider" instead of "TEST". >>>> >>>> If you still run into problems, try enable the java security debug >>>> flag and u should get a good idea why it isn't loaded. Let me know >>>> if you still have questions. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>>> I would like to know more about this. As far, I can see the >>>>> "java.security" provider configuration available with JDK9, it >>>>> holds provider names instead of provider class names. In that case >>>>> how it resolve the fall back? >>>>> >>>>> Thanks, >>>>> Siba >>>>> >>>>> -----Original Message----- >>>>> From: Alan Bateman >>>>> Sent: Monday, November 30, 2015 4:54 PM >>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>>> jigsaw-dev at openjdk.java.net >>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>>> security providers if they are in signed/unsigned modular JARs >>>>> >>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>>> >>>>>> I have one question: >>>>>> What should be the behavior when the older version of 3rd party >>>>>> JCE provider jar file(without service descriptor >>>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>>> "java.security" file, will be place in CLASS_PATH, running through >>>>>> JDK9 and the client is using Security.getProvider() to look for >>>>>> the provider? >>>>>> >>>>>> Currently the scenario fails to find the JCE provider. Is this >>>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>>> find the security provider provided through older jar files from >>>>>> CLASS_PATH. >>>>>> >>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>>> point by falling back and attempting to load the class name >>>>> specified via the security.provider. properties in the >>>>> java.security file. I'm sure Valerie can say more about this. >>>>> >>>>> -Alan > From bhanu.prakash.gopularam at oracle.com Mon Dec 21 04:42:26 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Sun, 20 Dec 2015 20:42:26 -0800 (PST) Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 In-Reply-To: References: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default> <56746A84.60106@oracle.com> Message-ID: <95db8a25-2e09-4290-9cb5-7212627d53f8@default> Hi Sean, The present fix solves the test issue which is happening in newer Solaris version viz., 11.3/12 which has FIPS guidelines as a prerequisite. With your permission I shall leave the JDK-8074580 (test stabilization issue) in current state, and would like to continue with fix for public exponent issue as reported in JDK-8129560. Please let me know. Thank you, Bhanu -----Original Message----- From: Anthony Scarpino Sent: Saturday, December 19, 2015 3:34 AM To: Sean Mullan Cc: Bhanu Gopularam; security-dev at openjdk.java.net Subject: Re: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4 The problems are different. The PKCS11 error means everything in this case. Tony > On Dec 18, 2015, at 12:20 PM, Sean Mullan wrote: > > The fix looks good, although this test is already on the ProblemList due to JDK-8074580. Do you know if that bug is caused by the same issue? The underlying PKCS11 error is different (maybe due to a different Solaris version?), but it looks like an identical stack trace. It would be good to also remove it from the ProblemList and close the other bug if it is a duplicate issue. > > --Sean > >> On 12/18/2015 12:41 AM, Bhanu Gopularam wrote: >> Hi all, >> >> Please review a fix for following bug: >> >> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560 >> >> Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is >> failing because RSAKeyGenParameterSpec >> >> public exponent is not accordance with FIPS 186-4 guidance >> >> Solution ? Used proper value for exponent based on reference from >> FIPS 186-4, section B-2. >> >> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/ >> >> Thanks, >> >> Bhanu >> From usha.seshadri at lmco.com Mon Dec 21 16:02:39 2015 From: usha.seshadri at lmco.com (Seshadri, Usha) Date: Mon, 21 Dec 2015 16:02:39 +0000 Subject: error compiling openJDK9 - commandLineFlagRangeList.cpp Message-ID: <0F6322F01158F94EBDA664939D5EA15504F44315@HVXDSP25.us.lmco.com> Hello, I just downloaded OpenJDK9, and am trying to build it on RHEL 5.11 with g++ 4.2.1, and I am getting this error from commandLineFlagRangeList.cpp: hotspot/src/share/vm/runtime/commandLineFlagRangeList.cpp:293: error: integer constant is too large for 'long' type commandLineFlagRangeList.cpp:293 points to: emit_range_no(NULL RUNTIME_FLAGS(EMIT_RANGE_DEVELOPER_FLAG, EMIT_RANGE_PD_DEVELOPER_FLAG, EMIT_RANGE_PRODUCT_FLAG, EMIT_RANGE_PD_PRODUCT_FLAG, EMIT_RANGE_DIAGNOSTIC_FLAG, EMIT_RANGE_EXPERIMENTAL_FLAG, EMIT_RANGE_NOTPRODUCT_FLAG, EMIT_RANGE_MANAGEABLE_FLAG, EMIT_RANGE_PRODUCT_RW_FLAG, EMIT_RANGE_LP64_PRODUCT_FLAG, EMIT_RANGE_CHECK, IGNORE_CONSTRAINT) ); Has anyone seen this error before? How can I go about fixing this error? Any help is greatly appreciated. Thanks, Usha Seshadri Lockheed Martin, IS&GS 301-240-7496 [LM-logo] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3531 bytes Desc: image002.jpg URL: From sibabrata.sahoo at oracle.com Tue Dec 22 06:17:06 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 21 Dec 2015 22:17:06 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> <56661315.2070701@oracle.com> <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default> <566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com> <62346504-1078-4ccd-9188-29dcd288f269@default> <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default> <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com> Message-ID: Hi Max/Mandy, Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.05/ I tried to address all the comments bellow. The major change includes abstracting the common behavior to ModularTest.java and extend the rest by each specific test. i.e. SecurityProviderModularTest and JaasModularClientTest. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Monday, December 21, 2015 7:20 AM To: Sibabrata Sahoo Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Tests are good. Several comments: 1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this. 2. It's not a good practice extending a class just to use its static fields/methods. Instead, make the util class final. public class JaasModularClientTest extends SecurityUtils public class SecurityProviderModularTest extends SecurityUtils In fact, if you do find similarities between SecurityProviderModularTest and JaasModularClientTest, try abstract them into a ModularTest class. 3. Please add enough comments to SecurityUtils since it will be reused. For example, move the descriptions of EXPLICIT, AUTO and UNNAMED from test @summary to definition of enum MODULE_TYPE. Thanks Max > On Dec 20, 2015, at 2:10 PM, Sibabrata Sahoo wrote: > > Hi Mandy/Max, > > Here is the updated webrev with very minor change over previous: > http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/ > > Thanks > Siba > > -----Original Message----- > From: Sibabrata Sahoo > Sent: Sunday, December 20, 2015 1:34 AM > To: Mandy Chung; Weijun Wang > Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; > security-dev at openjdk.java.net > Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security > providers if they are in signed/unsigned modular JARs > > Hi Mandy/Max, > > Please review the updated webrev: > http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/ > > "3rd party security providers" Test change includes: > - Test are converted to use TestNG framework. > - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository. > - Common reusable operations moved to "SecurityUtils.java" > - All the following comments associated. > > > Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes: > - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed. > - Test converted to use TestNG framework. > > Thanks, > Siba > > -----Original Message----- > From: Mandy Chung > Sent: Wednesday, December 09, 2015 11:55 PM > To: Sibabrata Sahoo > Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; > security-dev at openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security > providers if they are in signed/unsigned modular JARs > > Some high-level comment: > 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java. The Jigsaw prefix is not needed. > 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider. [1] is a simple test for you to get started. > > Some comments on JigsawSecurityUtils.java: > 71 Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o)); > > this can be replaced with > Arrays.stream(options).collect(Collectors.joining(SPACE)); > > 111 System.out.println(String.format( > > You can do: System.out.format(?.) instead; > > Mandy > [1] > http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/ > jigsaw/reflect/Proxy/ProxyTest.java > >> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo wrote: >> >> Hi Valerie, >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~ntv/siba/webrev.00/ >> >> Changes applied as per previous comments. >> - File names are modified and do not include the term JCE. >> - Source folder structure is flat now and all belongs to "java/security/Provider" folder. >> - Sign jar functionality removed. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Valerie Peng >> Sent: Wednesday, December 09, 2015 5:37 AM >> To: Sibabrata Sahoo >> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan >> Bateman >> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security >> providers if they are in signed/unsigned modular JARs >> >> Hi Siba, >> >> Here are some nits: >> >> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms. >> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers). >> You can remove a lot of code as a result. >> Also, your directory seems a bit deep, e.g. >> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way. >> >> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible? >> >> Thanks, >> Valerie >> >> On 12/8/2015 2:04 PM, Valerie Peng wrote: >>> Right, that'd be my expectation as well. Sounds like everything works. >>> I will change to look at your latest webrev. >>> Valerie >>> >>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote: >>>> Hi Valerie, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/ >>>> >>>> Now the modular behavior for the test works as per expectation >>>> through JAKE build with the following condition. >>>> If the provider jar is available under ModulePath then the >>>> "java.security" file should have the provider configuration entry >>>> as ProviderName while in case of ClassPath the entry should hold >>>> the full class name. >>>> >>>> Thanks, >>>> Siba >>>> >>>> -----Original Message----- >>>> From: Valerie Peng >>>> Sent: Tuesday, December 08, 2015 4:46 AM >>>> To: Sibabrata Sahoo >>>> Cc: Alan Bateman; security-dev at openjdk.java.net; >>>> jigsaw-dev at openjdk.java.net >>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>> security providers if they are in signed/unsigned modular JARs >>>> >>>> Siba, >>>> >>>> I have just started to review this webrev and not done yet. >>>> As for your question, the java.security file in OpenJDK9 still uses >>>> the provider class names instead of provider names. Are you talking >>>> about the java.security file in Jigsaw? Which build (OpenJDK or >>>> Jigsaw) have you tested against. I am pretty sure that I tested the >>>> 3rd party provider on classpath setting when I worked on the >>>> 7191662 changes. >>>> >>>> Supposedly, if the jar files are available on class path, then you >>>> should specify its full *class name* in the java.security file for >>>> it to be instantiated. Otherwise, how would it find the class? Only >>>> the classes discovered by ServiceLoader can be identified using the >>>> provider name (which is different from the class name referred >>>> above). So, in your scenario, that would be >>>> "provider.TestJCEProvider" instead of "TEST". >>>> >>>> If you still run into problems, try enable the java security debug >>>> flag and u should get a good idea why it isn't loaded. Let me know >>>> if you still have questions. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote: >>>>> I would like to know more about this. As far, I can see the >>>>> "java.security" provider configuration available with JDK9, it >>>>> holds provider names instead of provider class names. In that case >>>>> how it resolve the fall back? >>>>> >>>>> Thanks, >>>>> Siba >>>>> >>>>> -----Original Message----- >>>>> From: Alan Bateman >>>>> Sent: Monday, November 30, 2015 4:54 PM >>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; >>>>> jigsaw-dev at openjdk.java.net >>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party >>>>> security providers if they are in signed/unsigned modular JARs >>>>> >>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote: >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ >>>>>> >>>>>> I have one question: >>>>>> What should be the behavior when the older version of 3rd party >>>>>> JCE provider jar file(without service descriptor >>>>>> "META-INF/services/*"& working with<= JDK8) configured by >>>>>> "java.security" file, will be place in CLASS_PATH, running >>>>>> through >>>>>> JDK9 and the client is using Security.getProvider() to look for >>>>>> the provider? >>>>>> >>>>>> Currently the scenario fails to find the JCE provider. Is this >>>>>> right behavior? If it is, then jdk9 is not backward compatible to >>>>>> find the security provider provided through older jar files from >>>>>> CLASS_PATH. >>>>>> >>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this >>>>> point by falling back and attempting to load the class name >>>>> specified via the security.provider. properties in the >>>>> java.security file. I'm sure Valerie can say more about this. >>>>> >>>>> -Alan > From sean.mullan at oracle.com Tue Dec 22 16:36:30 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Dec 2015 11:36:30 -0500 Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable In-Reply-To: <56758080.1000703@oracle.com> References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com> <566F843B.4090605@oracle.com> <567427A8.5000105@oracle.com> <56758080.1000703@oracle.com> Message-ID: <56797C0E.1010609@oracle.com> The updated webrev looks good. --Sean On 12/19/2015 11:06 AM, Xuelei Fan wrote: > new webrev: http://cr.openjdk.java.net/~xuelei/8133070/webrev.01/ > > Updates to webrev.00: > Re-org the get methods of SSLContextImpl so as to avoid repeated > initialization of instance fields. > > On 12/18/2015 11:35 PM, Sean Mullan wrote: >> Here are a few other other comments on the code: >> >> SSLContextImpl: >> - I noticed that SSLContext.init does not specify how it handles empty >> arrays, and you have changed the code so that an empty TrustManager >> array is treated like they are null - is this change in behavior a >> compatibility issue at all? Could you file a follow-on issue to clarify >> the behavior of SSLContext.init as to how it should handle empty arrays? >> > It's a bug of my update. Empty means no trust manager, which is > different from using the default trust manager. > > I removed this update. > >> - are there any race conditions that you need to worry about now that >> you have removed the synchronized blocks from >> getSupportedCipherSuiteList and getDefaultCipherSuite? >> > May be initialized repeatedly. Should be OK as there is only one > instance for the to-be-assigned value. > > The code can be more straightforward and effective. I moved the impls > into sub-classes. > >> - on lines 781 and 789, an empty array is created and discarded if >> there is not an exception thrown. It would be better to only create the >> empty array when an exception is thrown (move it into the catch block). >> > Updated. > > Thanks, > Xuelei > >> --Sean >> >> >> On 12/14/2015 10:08 PM, Xuelei Fan wrote: >>> On 12/15/2015 4:24 AM, Sean Mullan wrote: >>>> Hi Xuelei, >>>> >>>> For JDK 9, the EC impl is defined to be in its own module >>>> (jdk.crypto.ec). How does it affect this fix if that module is not >>>> available/installed? >>>> >>> The SunJSSE provider would not support dynamically loading of crypto >>> providers/modules. At present, there are two providers that supports EC >>> implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11). >>> If no EC provider, EC cipher suites would not be available to use. >>> That's to say, EC cipher suites would not be enabled by default, and >>> cannot be used for handshaking. In the fix, >>> JsseJce#EcAvailability.isAvailable is used to check the availability of >>> EC crypto impl. >>> >>> Xuelei >>> >>>> --Sean >>>> >>>> On 12/01/2015 07:49 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for JDK-8133070: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ >>>>> >>>>> In (Open)JDK 6, EC cipher suites get supported by Java. However, there >>>>> is no default EC provider in JDK 6 at that time. In order to support >>>>> third part's EC algorithm JCE provider dynamically, it is hard-coded to >>>>> check the cipher suite availability dynamically for EC algorithms in >>>>> SunJSSE provider. >>>>> >>>>> Here is an example update in CipherSuite.java for the checking: >>>>> >>>>> - static final boolean DYNAMIC_AVAILABILITY = false; >>>>> + static final boolean DYNAMIC_AVAILABILITY = true; >>>>> >>>>> The dynamically checking impacts the performance significantly as: >>>>> 1. the check of the availability is expensive as it involves crypto >>>>> operations. >>>>> 2. a cache is used to maintain the availability of bulk ciphers in >>>>> order >>>>> to mitigate the #1 performance impact. However, access and update to >>>>> the cache need to be synchronized. >>>>> 3. in order to support dynamically checking, the cache may be >>>>> cleared if >>>>> a particular cipher is not found or a new SSLContext is generated. As >>>>> bring the performance impact of #1 back again. >>>>> >>>>> Later, AEAD algorithm is defined by Java. The same mechanism is >>>>> used to >>>>> support AEAD ciphers. >>>>> >>>>> Now, EC and GCM algorithms are supported in JDK crypto providers. The >>>>> hard-coded checking can get improved. This fix updates: >>>>> 1. remove the dynamically checking of cipher suite availability. >>>>> 2. remove the cipher suite availability cache accordingly (need no >>>>> synchronization accordingly) >>>>> 3. other updates that impact by the availability checking. >>>>> >>>>> The performance improvement is tested with the following simple case. >>>>> Run the following code 1000, 2000, 3000 times in single thread mode and >>>>> measure the millisecond for each: >>>>> >>>>> --------- >>>>> String[] cipherSuites = >>>>> {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"}; >>>>> for (int i = 0; i < loops; i++) { // loops: 1000, 2000, 3000 >>>>> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>>>> engine.getEnabledCipherSuites(); >>>>> engine.getSupportedCipherSuites(); >>>>> } >>>>> --------- >>>>> >>>>> The milliseconds for each test case (less is better) look like: >>>>> >>>>> loops | old | fixed >>>>> ---------+---------+---------- >>>>> 1000 | 2736 | 735 >>>>> ---------+---------+---------- >>>>> 2000 | 3718 | 746 >>>>> ---------+---------+---------- >>>>> 3000 | 4750 | 765 >>>>> ---------+---------+---------- >>>>> >>>>> This fix improves the performance. >>>>> >>>>> The existing regression testing get passed. No new regression test is >>>>> planned as this is a performance enhancement fix. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>> > From rob.mckenna at oracle.com Wed Dec 23 16:03:46 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 23 Dec 2015 16:03:46 +0000 Subject: RFR: 8146105 - Undo accidential changes to sun/security/ssl/SignatureAndHashAlgorithm.java Message-ID: <567AC5E2.4060700@oracle.com> Apologies folks, I managed to push a change for https://bugs.openjdk.java.net/browse/JDK-8064330 along with https://bugs.openjdk.java.net/browse/JDK-7130985 I'd like to revert that particular portion of the change: http://cr.openjdk.java.net/~robm/8146105/webrev.01/ -Rob From xuelei.fan at oracle.com Thu Dec 24 15:25:02 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 24 Dec 2015 23:25:02 +0800 Subject: FYI, 8146192 Add test for JDK-8049321 Message-ID: <567C0E4E.9020605@oracle.com> FYI. I missed the test code while push the changeset for JDK-8049321. This update will push the changeset. Please refer to the webrev for JDK-8049321: http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/ Thanks, Xuelei From xuelei.fan at oracle.com Thu Dec 24 15:51:57 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 24 Dec 2015 23:51:57 +0800 Subject: RFR: 8146105 - Undo accidential changes to sun/security/ssl/SignatureAndHashAlgorithm.java In-Reply-To: <567AC5E2.4060700@oracle.com> References: <567AC5E2.4060700@oracle.com> Message-ID: <567C149D.5090609@oracle.com> Looks fine to me. Thanks, Xuelei On 12/24/2015 12:03 AM, Rob McKenna wrote: > Apologies folks, > > I managed to push a change for > https://bugs.openjdk.java.net/browse/JDK-8064330 along with > https://bugs.openjdk.java.net/browse/JDK-7130985 > > I'd like to revert that particular portion of the change: > > http://cr.openjdk.java.net/~robm/8146105/webrev.01/ > > -Rob From xuelei.fan at oracle.com Fri Dec 25 15:53:42 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 25 Dec 2015 23:53:42 +0800 Subject: Code Review Request, 8146197 SignatureAlgorithms.java after push of JDK-8146192 Message-ID: <567D6686.2050302@oracle.com> Hi, Anyone available for a quick review? http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/ A test failure caused by the removal of BASE64Decoder. Updated to use java.util.Base64. Thanks, Xuelei From henry.jen at oracle.com Fri Dec 25 18:29:35 2015 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 25 Dec 2015 10:29:35 -0800 Subject: Code Review Request, 8146197 SignatureAlgorithms.java after push of JDK-8146192 In-Reply-To: <567D6686.2050302@oracle.com> References: <567D6686.2050302@oracle.com> Message-ID: Not an official reviewer, but the change look good to me. Cheers, Henry > On Dec 25, 2015, at 7:53 AM, Xuelei Fan wrote: > > Hi, > > Anyone available for a quick review? > > http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/ > > A test failure caused by the removal of BASE64Decoder. Updated to use > java.util.Base64. > > Thanks, > Xuelei From sean.mullan at oracle.com Sun Dec 27 15:53:08 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 27 Dec 2015 10:53:08 -0500 Subject: Code Review Request, 8146197 SignatureAlgorithms.java after push of JDK-8146192 In-Reply-To: <567D6686.2050302@oracle.com> References: <567D6686.2050302@oracle.com> Message-ID: Looks fine to me. > On Dec 25, 2015, at 10:53 AM, Xuelei Fan wrote: > > Hi, > > Anyone available for a quick review? > > http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/ > > A test failure caused by the removal of BASE64Decoder. Updated to use > java.util.Base64. > > Thanks, > Xuelei From mark.sheppard at oracle.com Thu Dec 31 14:30:05 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 31 Dec 2015 14:30:05 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <5645DB41.8000704@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> Message-ID: <56853BED.2070007@oracle.com> Hi please oblige and review the current version of the fix for https://bugs.openjdk.java.net/browse/JDK-8134577 at http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ which is based on feedback from the second review. In summary the following changes have been made * hosts file mapping structure has been changed to align with /etc/hosts, that is, rather than * elementary comment handling added, skip lines starting with # * lookupAllHostAddr returns an array of InetAddresses, rather than a single element array containing the first host address mapping * the illegal_state_exception token handling has been removed, and a corresponding test deadlock/Hang.java removed * transient key word added to member variables useLocalHostsFileLookup and hostsFileName * added an explicit test to exercise the internal NameService regards Mark On 13/11/2015 12:44, Mark Sheppard wrote: > Hi, > to summarize the amendments below: > > ServiceConfigurationError removed - the code no longer reads the > nameservice provider property, it silently ignored > > try-with-resources statement added in getHostByAddr and > lookupAllHostAddr methods of NameService, and duplicate statements removed > > hosts file name in tests changed to TestHosts to avoid any potential > confusion with /etc/hosts > > regards > Mark > > > > On 12/11/2015 16:46, Mark Sheppard wrote: >> Hi, >> based on feedback from first review the updates have been amended >> please oblige and review the current set of changes as per >> >> http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/ >> >> regards >> Mark >> >> On 25/10/2015 23:32, Mark Sheppard wrote: >>> Hi, >>> please oblige and review the following changes >>> http://cr.openjdk.java.net/~msheppar/8134577/webrev/ >>> >>> which address the issue raised in >>> https://bugs.openjdk.java.net/browse/JDK-8134577 >>> >>> the operative word has been "eliminate". >>> As such, the interface and service descriptor >>> sun.net.spi.nameservice.NameService >>> sun.net.spi.nameservice.NameServiceDescriptor* >>> *together with its implementation >>> (sun.net.nameservice.dns.DNSNameService) >>> has been remove from the JDK libraries. >>> >>> The immediate impact is seen in the JDK testing framework. >>> >>> To facilitate testing activity, and provide a replacement for the >>> customized NameService implementations in the >>> JDK tests, the default NameService has been extended to support >>> the retrieval of host to IP address mappings from a file. >>> The file path is specified with a system property " jdk.internal.hosts". >>> >>> Previously a nameservice provider was specified by setting the >>> system property >>> "sun.net.spi.nameservice.provider.", as per the documentation >>> http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html >>> >>> InetAddress now tests to determine if this property is set and will >>> throw a ServiceConfigurationError >>> indicating that this functionality is no longer supported. The >>> choice of ServideConfigurationError may cause >>> some debate, or disagreement. The rationale was that InternalError, >>> is documented to relate to a JVM error, >>> and javax.naming.NamingException has a context of DirContext. >>> A possible alternative candidate could be >>> javax.naming.ServiceUnavailableException. >>> As such, the setting of the property >>> "sun.net.spi.nameservice.provider." was used, previously, as a >>> configuration >>> parameter for the loading of a NamerService service provider, and as >>> this is now (considered) an error, ServiceConfigurationError, >>> seemed a best fit! >>> >>> These changes impacted a number of jdk security tests, also. The >>> affected tetsts have been amended to adopt the >>> changes, with the exception of >>> test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java >>> which will require some rewrite. >>> >>> regards >>> Mark >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Dec 31 17:26:16 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jan 2016 01:26:16 +0800 Subject: RFR 8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh failing Message-ID: <6FD46EB9-0806-4CD6-AE33-5B875391A0F9@oracle.com> Hi Please review the fix of https://bugs.openjdk.java.net/browse/JDK-8146377. Some years have more days than 365 and the test fails. The fix is simply diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh --- a/test/sun/security/tools/jarsigner/concise_jarsigner.sh +++ b/test/sun/security/tools/jarsigner/concise_jarsigner.sh @@ -69,8 +69,8 @@ # First part: output format # ========================================================== -$KT -genkeypair -alias a1 -dname CN=a1 -validity 365 -$KT -genkeypair -alias a2 -dname CN=a2 -validity 365 +$KT -genkeypair -alias a1 -dname CN=a1 -validity 366 +$KT -genkeypair -alias a2 -dname CN=a2 -validity 366 # a.jar includes 8 unsigned, 2 signed by a1 and a2, 2 signed by a3 $JAR cvf a.jar A1.class A2.class Thanks Max