From ecki at zusammenkunft.net Sun Nov 2 23:15:28 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 3 Nov 2014 00:15:28 +0100 Subject: TLS hostname verifier: reverse resolves peer addresses? Message-ID: <20141103001528.00004786.ecki@zusammenkunft.net> Hello, while playing around(*) with JSSE and howismyssl.com I noticed, that the Java 8 hostname verifier (algorithm https configured) will reverse resolve hostnames and use them. This has two problems, for one it is a performance problem, but for two, it will verify the cert against an untrusted (DNS response) parameter. I dont think it is speced that way (at least I could not find it). So it could fall back to IP literal instead. This is not a problem if I generate the InetAddr with a ip literal: destination = InetAddr.getByName("54.245.228.141"); but it is a problem if I construct an unresolved address: destination = InetAddress.getByAddress( new byte[] {54,(byte)245,(byte)228,(byte)141}); In the first case, it will result in (expected): Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address 54.245.228.141 found In the second case, however it will result in: Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching ec2-54-245-228-141.us-west-2.compute.amazonaws.com found. I typically use the getByAddress form as it allows me to control resolving. It is enough to use this form: destination = InetAddress.getByAddress("54.245.228.141", new byte[] {54,(byte)245,(byte)228,(byte)141}); However I noticed in the code there are some conditionals for unresolved peer addresses. I just wonder if they should catch this and avoid the reverse lookup, or not? (I actually wanted to make sure hostname verification is not skipped, no matter how I configure it). Gruss Bernd (*) https://github.com/ecki/JavaCryptoTest/blob/master/src/main/java/net/eckenfels/test/howsmyssl/Client.java#L31 From sean.mullan at oracle.com Mon Nov 3 17:28:58 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 03 Nov 2014 12:28:58 -0500 Subject: CFV: New Security Group Member: Anthony Scarpino Message-ID: <5457BB5A.8040401@oracle.com> I hereby nominate Anthony Scarpino to Membership in the Security Group. Anthony is a member of the Java Security Libraries team at Oracle and has been an active contributor to the OpenJDK Security Group for approximately two years. Anthony was voted in as a JDK 8 committer in November, 2013, and has continued to play an active role in the JDK 8 update releases and JDK 9. Anthony has integrated many significant bug fixes and enhancements especially in the crypto area. He is also the owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently been submitted for further evaluation. Votes are due by November 17, 2014, 10:00 AM PST. Only current Members of the Security Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Sean Mullan [1] http://openjdk.java.net/census#security [2] http://openjdk.java.net/groups/#member-vote From bradford.wetmore at oracle.com Mon Nov 3 20:15:31 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 03 Nov 2014 12:15:31 -0800 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <5457BB5A.8040401@oracle.com> References: <5457BB5A.8040401@oracle.com> Message-ID: <5457E263.1030601@oracle.com> Vote: Yes Brad On 11/3/2014 9:28 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to Membership in the Security Group. > > Anthony is a member of the Java Security Libraries team at Oracle and > has been an active contributor to the OpenJDK Security Group for > approximately two years. Anthony was voted in as a JDK 8 committer in > November, 2013, and has continued to play an active role in the JDK 8 > update releases and JDK 9. Anthony has integrated many significant bug > fixes and enhancements especially in the crypto area. He is also the > owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently > been submitted for further evaluation. > > Votes are due by November 17, 2014, 10:00 AM PST. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From weijun.wang at oracle.com Tue Nov 4 02:09:47 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 4 Nov 2014 10:09:47 +0800 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <5457E263.1030601@oracle.com> References: <5457BB5A.8040401@oracle.com> <5457E263.1030601@oracle.com> Message-ID: <56C63380-F33F-4841-8A27-A1CECD541C1C@oracle.com> Vote: Yes --Weijun From Xuelei.Fan at Oracle.COM Tue Nov 4 02:15:54 2014 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Tue, 04 Nov 2014 10:15:54 +0800 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <5457BB5A.8040401@oracle.com> References: <5457BB5A.8040401@oracle.com> Message-ID: <545836DA.2020804@Oracle.COM> vote: yes. Xuelei On 11/4/2014 1:28 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to Membership in the Security Group. > > Anthony is a member of the Java Security Libraries team at Oracle and > has been an active contributor to the OpenJDK Security Group for > approximately two years. Anthony was voted in as a JDK 8 committer in > November, 2013, and has continued to play an active role in the JDK 8 > update releases and JDK 9. Anthony has integrated many significant bug > fixes and enhancements especially in the crypto area. He is also the > owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently > been submitted for further evaluation. > > Votes are due by November 17, 2014, 10:00 AM PST. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From weijun.wang at oracle.com Tue Nov 4 10:00:57 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 4 Nov 2014 18:00:57 +0800 Subject: RFR 8057810: New defaults for DSA keys in jarsigner and keytool Message-ID: <7CBBE6B6-D802-4496-B2FA-2768D1C3CB07@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8057810/webrev.00/ Now DSA keys use 2048 bit key size and SHA256withDSA as defaults for keytool and jarsigner. A new test added. Several existing tests updated since the new defaults are not supported by NSS. Thanks Max From sean.mullan at oracle.com Tue Nov 4 12:51:33 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 04 Nov 2014 07:51:33 -0500 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <5457BB5A.8040401@oracle.com> References: <5457BB5A.8040401@oracle.com> Message-ID: <5458CBD5.7040505@oracle.com> Vote: yes --Sean On 11/03/2014 12:28 PM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to Membership in the Security Group. > > Anthony is a member of the Java Security Libraries team at Oracle and > has been an active contributor to the OpenJDK Security Group for > approximately two years. Anthony was voted in as a JDK 8 committer in > November, 2013, and has continued to play an active role in the JDK 8 > update releases and JDK 9. Anthony has integrated many significant bug > fixes and enhancements especially in the crypto area. He is also the > owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently > been submitted for further evaluation. > > Votes are due by November 17, 2014, 10:00 AM PST. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From vincent.x.ryan at oracle.com Tue Nov 4 14:14:36 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 4 Nov 2014 14:14:36 +0000 Subject: RFR 8057810: New defaults for DSA keys in jarsigner and keytool In-Reply-To: <7CBBE6B6-D802-4496-B2FA-2768D1C3CB07@oracle.com> References: <7CBBE6B6-D802-4496-B2FA-2768D1C3CB07@oracle.com> Message-ID: <6AB08280-1D58-4185-8021-649636A80934@oracle.com> Your fix looks fine. Thanks. On 4 Nov 2014, at 10:00, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8057810/webrev.00/ > > Now DSA keys use 2048 bit key size and SHA256withDSA as defaults for keytool and jarsigner. > > A new test added. Several existing tests updated since the new defaults are not supported by NSS. > > Thanks > Max > From vincent.x.ryan at oracle.com Tue Nov 4 14:15:19 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 4 Nov 2014 14:15:19 +0000 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <5457BB5A.8040401@oracle.com> References: <5457BB5A.8040401@oracle.com> Message-ID: <2BA72071-34C8-4A31-A18D-CB905C5E3E4E@oracle.com> Vote: yes On 3 Nov 2014, at 17:28, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to Membership in the Security Group. > > Anthony is a member of the Java Security Libraries team at Oracle and has been an active contributor to the OpenJDK Security Group for approximately two years. Anthony was voted in as a JDK 8 committer in November, 2013, and has continued to play an active role in the JDK 8 update releases and JDK 9. Anthony has integrated many significant bug fixes and enhancements especially in the crypto area. He is also the owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently been submitted for further evaluation. > > Votes are due by November 17, 2014, 10:00 AM PST. > > Only current Members of the Security Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From jason.uh at oracle.com Tue Nov 4 19:44:03 2014 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 04 Nov 2014 11:44:03 -0800 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <5457BB5A.8040401@oracle.com> References: <5457BB5A.8040401@oracle.com> Message-ID: <54592C83.9070705@oracle.com> Vote: Yes Jason On 11/03/2014 09:28 AM, Sean Mullan wrote: > I hereby nominate Anthony Scarpino to Membership in the Security Group. > > Anthony is a member of the Java Security Libraries team at Oracle and > has been an active contributor to the OpenJDK Security Group for > approximately two years. Anthony was voted in as a JDK 8 committer in > November, 2013, and has continued to play an active role in the JDK 8 > update releases and JDK 9. Anthony has integrated many significant bug > fixes and enhancements especially in the crypto area. He is also the > owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently > been submitted for further evaluation. > > Votes are due by November 17, 2014, 10:00 AM PST. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From valerie.peng at oracle.com Tue Nov 4 21:43:31 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 04 Nov 2014 13:43:31 -0800 Subject: CFV: New Security Group Member: Anthony Scarpino In-Reply-To: <54592C83.9070705@oracle.com> References: <5457BB5A.8040401@oracle.com> <54592C83.9070705@oracle.com> Message-ID: <54594883.8010408@oracle.com> Vote: Yes On 11/4/2014 11:44 AM, Jason Uh wrote: > Vote: Yes > > Jason > > On 11/03/2014 09:28 AM, Sean Mullan wrote: >> I hereby nominate Anthony Scarpino to Membership in the Security Group. >> >> Anthony is a member of the Java Security Libraries team at Oracle and >> has been an active contributor to the OpenJDK Security Group for >> approximately two years. Anthony was voted in as a JDK 8 committer in >> November, 2013, and has continued to play an active role in the JDK 8 >> update releases and JDK 9. Anthony has integrated many significant bug >> fixes and enhancements especially in the crypto area. He is also the >> owner of the "JVM Hardware Crypto Acceleration" JEP, which has recently >> been submitted for further evaluation. >> >> Votes are due by November 17, 2014, 10:00 AM PST. >> >> Only current Members of the Security Group [1] are eligible to vote on >> this nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Sean Mullan >> >> [1] http://openjdk.java.net/census#security >> [2] http://openjdk.java.net/groups/#member-vote From weijun.wang at oracle.com Thu Nov 6 06:04:02 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 6 Nov 2014 14:04:02 +0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: References: Message-ID: Ping ping... > On Oct 20, 2014, at 13:22, Wang Weijun wrote: > > Anyone can take a look? > >> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >> >> Hi All >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >> >> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >> >> Thanks >> Max >> > From valerie.peng at oracle.com Thu Nov 6 18:31:38 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 06 Nov 2014 10:31:38 -0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: References: Message-ID: <545BBE8A.6060306@oracle.com> OK, I will take a look. Thanks, Valerie On 11/5/2014 10:04 PM, Wang Weijun wrote: > Ping ping... > >> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >> >> Anyone can take a look? >> >>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>> >>> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >>> >>> Thanks >>> Max >>> From anthony.scarpino at oracle.com Thu Nov 6 22:14:26 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 06 Nov 2014 14:14:26 -0800 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 Message-ID: <545BF2C2.6030002@oracle.com> Hi, I need a review of this change to the pkcs11 wrapper code. The changes allow encryption to work properly when -Xcheck:jni is called. A recent change to -Xcheck:jni caused the failures to occur. http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ thanks Tony From sean.mullan at oracle.com Thu Nov 6 22:37:54 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 06 Nov 2014 17:37:54 -0500 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 In-Reply-To: <545BF2C2.6030002@oracle.com> References: <545BF2C2.6030002@oracle.com> Message-ID: <545BF842.6040006@oracle.com> It looks ok to me although I think Valerie should also review it. Is it possible to add a simple regression test for this and not be dependent on the JCK tests? --Sean On 11/06/2014 05:14 PM, Anthony Scarpino wrote: > Hi, > > I need a review of this change to the pkcs11 wrapper code. The changes > allow encryption to work properly when -Xcheck:jni is called. A recent > change to -Xcheck:jni caused the failures to occur. > > http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ > > thanks > > Tony From anthony.scarpino at oracle.com Fri Nov 7 00:06:26 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 06 Nov 2014 16:06:26 -0800 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 In-Reply-To: <545BF842.6040006@oracle.com> References: <545BF2C2.6030002@oracle.com> <545BF842.6040006@oracle.com> Message-ID: <545C0D02.7070801@oracle.com> It's completely dependent on Xcheck:jni. I figured that was an option part of the testing process. Not something that one put into a test. Is that wrong? Tony On 11/06/2014 02:37 PM, Sean Mullan wrote: > It looks ok to me although I think Valerie should also review it. Is it > possible to add a simple regression test for this and not be dependent > on the JCK tests? > > --Sean > > On 11/06/2014 05:14 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this change to the pkcs11 wrapper code. The changes >> allow encryption to work properly when -Xcheck:jni is called. A recent >> change to -Xcheck:jni caused the failures to occur. >> >> http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ >> >> thanks >> >> Tony From valerie.peng at oracle.com Fri Nov 7 03:23:06 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 06 Nov 2014 19:23:06 -0800 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 In-Reply-To: <545C0D02.7070801@oracle.com> References: <545BF2C2.6030002@oracle.com> <545BF842.6040006@oracle.com> <545C0D02.7070801@oracle.com> Message-ID: <545C3B1A.9040804@oracle.com> The changes look fine. Valerie On 11/6/2014 4:06 PM, Anthony Scarpino wrote: > It's completely dependent on Xcheck:jni. I figured that was an option > part of the testing process. Not something that one put into a test. > Is that wrong? > > Tony > > On 11/06/2014 02:37 PM, Sean Mullan wrote: >> It looks ok to me although I think Valerie should also review it. Is it >> possible to add a simple regression test for this and not be dependent >> on the JCK tests? >> >> --Sean >> >> On 11/06/2014 05:14 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a review of this change to the pkcs11 wrapper code. The changes >>> allow encryption to work properly when -Xcheck:jni is called. A >>> recent >>> change to -Xcheck:jni caused the failures to occur. >>> >>> http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ >>> >>> thanks >>> >>> Tony > From artem.smotrakov at oracle.com Fri Nov 7 10:07:18 2014 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 07 Nov 2014 13:07:18 +0300 Subject: RFR: 8048603: Additional tests for MAC algorithms Message-ID: <545C99D6.2090200@oracle.com> Please review a couple of new test cases for MAC algorithms. https://bugs.openjdk.java.net/browse/JDK-8048603 http://cr.openjdk.java.net/~asmotrak/8048603/webrev.00/ Artem From sean.mullan at oracle.com Fri Nov 7 12:44:52 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 07 Nov 2014 07:44:52 -0500 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 In-Reply-To: <545C0D02.7070801@oracle.com> References: <545BF2C2.6030002@oracle.com> <545BF842.6040006@oracle.com> <545C0D02.7070801@oracle.com> Message-ID: <545CBEC4.1030206@oracle.com> On 11/06/2014 07:06 PM, Anthony Scarpino wrote: > It's completely dependent on Xcheck:jni. I figured that was an option > part of the testing process. Not something that one put into a test. Is > that wrong? You could put it as an option in the @run tag, ex: @run main/othervm -Xcheck:jni ... There are a handful of tests that do that. Is there an existing test you could add that run tag to to reproduce the issue? --Sean > > Tony > > On 11/06/2014 02:37 PM, Sean Mullan wrote: >> It looks ok to me although I think Valerie should also review it. Is it >> possible to add a simple regression test for this and not be dependent >> on the JCK tests? >> >> --Sean >> >> On 11/06/2014 05:14 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a review of this change to the pkcs11 wrapper code. The changes >>> allow encryption to work properly when -Xcheck:jni is called. A recent >>> change to -Xcheck:jni caused the failures to occur. >>> >>> http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ >>> >>> thanks >>> >>> Tony > From simone.bordet at gmail.com Fri Nov 7 13:06:39 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 7 Nov 2014 14:06:39 +0100 Subject: A fully fledged TLS Extensions API ? Message-ID: Hi, I was writing the email about the ALPN API proposal when I realized that it would have been better to split the arguments in different emails. This email is about the idea to introduce in JDK 9 a fully fledged TLS Extensions API. Adding ALPN [0] support to JDK 9 requires, differently from other TLS extensions, to provide application code that will be run in the context of the TLS implementation, rather than just values such as booleans or strings. IMHO this chance can be lifted to provide a full TLS Extensions API. Alternative providers such as IAIK offer a private API such as [1]: SSLSocket.getActiveExtensions() SSLSocket.getPeerExtensions() Similarly, BouncyCastle offers [2]: DefaultTlsClient.getClientExtensions() In the JDK there is a class named SSLParameters that contains some of the configuration values for TLS. Some of those are duplicated in SSLSocket and SSLEngine (e.g. wantClientAuth, needClientAuth, etc), with some temporal dependency (call this before the other, if I have to trust the comments of SSLSocketImpl.setHost()). Eventually all values get forwarded to the handshaker, but from the API point of view it's not very clear what API one should call (the one on SSLEngine or the one on SSLParameters), nor where the ALPN setup should be done. The idea would then be to introduce a fully fledged TLS extensions API to handle all the TLS extensions related things, such as renegotiation, SNI, elliptic curves, NPN, ALPN, session tickets etc. Both applications and the JDK implementation would be able to leverage this new API. Note that the bulk of this API already exists in sun.security.ssl. My question is really whether JDK 9 could take in consideration such TLS Extension API be exposed publicly for applications to use it. See the other emails about ALPN and the interaction between ALPN and HTTP 2 for further examples of where this TLS Extension API would come handy. Thanks ! [0] http://tools.ietf.org/html/rfc7301 [1] http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/SSLSocket.html [2] https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/DefaultTlsClient.html -- 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 simone.bordet at gmail.com Fri Nov 7 13:10:44 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 7 Nov 2014 14:10:44 +0100 Subject: ALPN API Proposal Message-ID: Hi, The ALPN (RFC 7301) [0] API that the Jetty project has implemented, and used for a while, to support SPDY and HTTP2 (h2), is here [1]. It consists of 2 provider interfaces, one for the client and one for the server, with methods that are called by the JDK implementation at the right times to let the application decide what protocol should be negotiated. However, I believe they can be greatly simplified (to a lambda) for JDK 9. The providers needs these moments of interaction. For the client: C1) providing the list of protocols (before the ClientHello is sent) C2) knowing whether the server support ALPN, and if so, what was the protocol chosen (upon receiving the ServerHello) For the server: S1) knowing if the client supports ALPN, and if so what is the list of protocols, and returning the chosen protocol (upon receiving the ClientHello). While C1 is a value that may be provided easily, C2 and S1 require application code to be called by the TLS implementation. The API that I would like to propose is something along these lines. For the client: SSLEngine engine = ...; TLSExtension alpn = new ALPNClientExtension(protocol -> { ... }, "h2", "spdy/3", "http/1.1"); engine.getLocalExtensions().add(alpn); engine.beginHandshake(); For the server: SSLEngine engine = ...; TLSExtension alpn = new ALPNServerExtension(protocols -> { ... }); engine.getLocalExtensions().add(alpn); The two lambdas will be called "as soon as possible", that is for the client just after having received the ServerHello, and for the server just after having received the ClientHello. I say "as soon as possible" this because the h2 specification is still in flux for what regards the constraints that needs to be put in place to accept the negotiation of the h2 protocol (but see the other email about). It may well be that the connection must be closed before the end of the TLS handshake. Alternatively, lacking a full fledged TLS Extensions API, something similar may be put into SSLParameters, although it would require two "container" classes akin to ALPNClientExtension and ALPNServerExtension (in particular for the client, to "link" the lambda with the list of protocols offered). The lambdas would be, for the client: void selected(String protocol) with the semantic that: * a null parameter would mean the server does not support ALPN. If the server cannot negotiate the protocol, it shall (per RFC 7301) close the connection. This leaves open a case where an uncompliant server sends down an empty/null protocol, but I guess this can be treated by the client as if the server does not support ALPN (in fact, it does not support it correctly). * an exception thrown would mean the client is not happy with the protocol chosen (for any reason), and the TLS implementation must close the connection with alert code 120 (per 7301). The lambda for the server would be: String select(List protocols) with the semantic that: * a null list would mean the client does not support (correctly) ALPN. * a null return value or an exception thrown would mean the server could not negotiate the protocol and the connection must be closed with alert code 120 (per 7301). I'd be happy to contribute code and experience about this, but I need guidance on where to start and how to proceed. In particular, if a larger effort for a TLS Extension API is considered useful, then the ALPN implementation is trivial; the bulk of the work would be to design this new TLS Extension API. For a more complete picture about why I think a TLS Extension API would be beneficial, see also the other emails. Thanks ! [0] http://tools.ietf.org/html/rfc7301 [1] https://github.com/eclipse/jetty.alpn/blob/master/src/main/java/org/eclipse/jetty/alpn/ALPN.java -- 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 simone.bordet at gmail.com Fri Nov 7 13:19:48 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 7 Nov 2014 14:19:48 +0100 Subject: ALPN & HTTP2 Message-ID: Hi, below you can find few considerations about the interaction between HTTP 2.0 (from now onwards just "h2") and ALPN. The h2 group at the IETF is having a big debate about section 9.2.2 of draft-14 [0]. This section basically put a very strong requirement on the ciphers that can be used to talk h2. However, clients are entitled to offer weak ciphers and strong ciphers, but only the strong ones can be used to talk h2. With this, there is a dependency between the ALPN protocol chosen and cipher selection; note that cipher selection should happen before the ALPN server lambda invocation (as I proposed in the other email). The algorihtm proposed by the h2 editors would be that h2 could only be chosen by the ALPN server lambda IFF: !cipher.isStream() && !cipher.isBlock() && cipher.supportsForwardSecrecy() There is a big resistance among the h2 experts to have this algorithm defined in the h2 spec, for many reasons. However, the h2 editors are very resistant to changes (I have to say, backed by the TLS editor). The fact that almost all TLS implementations out there don't have at least one (or all) of the methods above (so basically the algorithm above is not implementable) is not seen as a good enough reason to remove section 9.2.2. Furthermore, there is not direct correlation, in the TLS handshake, between ciphers and protocols. Speaking of the server side that I know better, the case is that I take Jetty and run it in the shiny just released JDK 9. The TLS implementation of JDK 9 adds new ciphers, one of which is named XYZ. Jetty receives a TLS connection request, with cipher XYZ and ALPN listing h2. The JDK Jetty runs on has XYZ, but Jetty has no idea whether this cipher is good for h2 or not. Jetty may pick XYZ and h2, thus succeeding at both cipher negotiation (both client and server can use that cipher) and at protocol negotiation (both client and server can speak h2), but when the client receives the ServerHello, the client may say "oh, no, XYZ is not good for h2, I offered it for HTTP/1.1", but now it's too late and the only possible solution is to close the connection, and reopen another one excluding h2 from the protocols sent to the server (or excluding the cipher XYZ - but how the client knows if a different cipher will succeed ?). Ironically, 9.2.2 may hamper h2 adoption. Hopefully the h2 group will come to a better decision about section 9.2.2, perhaps without entangling protocol negotiation with cipher negotiation, but we don't know yet. In any case, I would suggest that the OpenJDK security-dev leaders consider to add the capabilities to query a cipher for its properties to OpenJDK. There already exist a javax.crypto.Cipher class that perhaps may be enhanced to expose those methods, along with a way to obtain the selected Cipher instance from SSLSocket/SSLEngine. On the same theme, it would not be too far fetched to think that a server may want to provide h2.domain.com over h2, and h1.domain.com over HTTP/1.1 for the same certificate *.domain.com. For this to happen, the server ALPN lambda would need to extract the SNI extension name, compare it with some virtual host configuration, and then take a decision about the protocol to speak. Again, a full fledged TLS Extension API would simplify this: String sni = SSLEngine.getRemoteExtensions().find(SNIExtension.class).getName(); SNIMatcher won't be able, for example, to match regexp'ed virtual hosts. In conclusion I'd like to point out the fact that a ALPN API into JDK 9 is a mandatory requisite to implement h2, but may not be sufficient, since additional methods on Cipher and other TLS classes may be needed. Thanks ! [0] http://tools.ietf.org/html/draft-ietf-httpbis-http2-14 -- 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 anthony.scarpino at oracle.com Fri Nov 7 17:08:54 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 07 Nov 2014 09:08:54 -0800 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 In-Reply-To: <545CBEC4.1030206@oracle.com> References: <545BF2C2.6030002@oracle.com> <545BF842.6040006@oracle.com> <545C0D02.7070801@oracle.com> <545CBEC4.1030206@oracle.com> Message-ID: <545CFCA6.7070305@oracle.com> On 11/07/2014 04:44 AM, Sean Mullan wrote: > On 11/06/2014 07:06 PM, Anthony Scarpino wrote: >> It's completely dependent on Xcheck:jni. I figured that was an option >> part of the testing process. Not something that one put into a test. Is >> that wrong? > > You could put it as an option in the @run tag, ex: > > @run main/othervm -Xcheck:jni ... > > There are a handful of tests that do that. Is there an existing test you > could add that run tag to to reproduce the issue? > > --Sean I made a similar test to the one that failed in the JCK. Finding an example wasn't hard. I updated the webrev in place, so hit refresh on the link again and you'll see the test Tony > >> >> Tony >> >> On 11/06/2014 02:37 PM, Sean Mullan wrote: >>> It looks ok to me although I think Valerie should also review it. Is it >>> possible to add a simple regression test for this and not be dependent >>> on the JCK tests? >>> >>> --Sean >>> >>> On 11/06/2014 05:14 PM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I need a review of this change to the pkcs11 wrapper code. The changes >>>> allow encryption to work properly when -Xcheck:jni is called. A >>>> recent >>>> change to -Xcheck:jni caused the failures to occur. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ >>>> >>>> thanks >>>> >>>> Tony >> From sean.mullan at oracle.com Fri Nov 7 18:42:46 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 07 Nov 2014 13:42:46 -0500 Subject: Code Review Request: 8063700 -Xcheck:jni changes cause many JCK failures in api/javax_crypto tests with SunPKCS11 In-Reply-To: <545CFCA6.7070305@oracle.com> References: <545BF2C2.6030002@oracle.com> <545BF842.6040006@oracle.com> <545C0D02.7070801@oracle.com> <545CBEC4.1030206@oracle.com> <545CFCA6.7070305@oracle.com> Message-ID: <545D12A6.9040902@oracle.com> Updated webrev looks good. --Sean On 11/07/2014 12:08 PM, Anthony Scarpino wrote: > On 11/07/2014 04:44 AM, Sean Mullan wrote: >> On 11/06/2014 07:06 PM, Anthony Scarpino wrote: >>> It's completely dependent on Xcheck:jni. I figured that was an option >>> part of the testing process. Not something that one put into a test. Is >>> that wrong? >> >> You could put it as an option in the @run tag, ex: >> >> @run main/othervm -Xcheck:jni ... >> >> There are a handful of tests that do that. Is there an existing test you >> could add that run tag to to reproduce the issue? >> >> --Sean > > I made a similar test to the one that failed in the JCK. Finding an > example wasn't hard. > > I updated the webrev in place, so hit refresh on the link again and > you'll see the test > > Tony > >> >>> >>> Tony >>> >>> On 11/06/2014 02:37 PM, Sean Mullan wrote: >>>> It looks ok to me although I think Valerie should also review it. Is it >>>> possible to add a simple regression test for this and not be dependent >>>> on the JCK tests? >>>> >>>> --Sean >>>> >>>> On 11/06/2014 05:14 PM, Anthony Scarpino wrote: >>>>> Hi, >>>>> >>>>> I need a review of this change to the pkcs11 wrapper code. The >>>>> changes >>>>> allow encryption to work properly when -Xcheck:jni is called. A >>>>> recent >>>>> change to -Xcheck:jni caused the failures to occur. >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8063700/webrev/ >>>>> >>>>> thanks >>>>> >>>>> Tony >>> > From fweimer at redhat.com Mon Nov 10 13:07:41 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 10 Nov 2014 14:07:41 +0100 Subject: A fully fledged TLS Extensions API ? In-Reply-To: References: Message-ID: <5460B89D.5020203@redhat.com> On 11/07/2014 02:06 PM, Simone Bordet wrote: > This email is about the idea to introduce in JDK 9 a fully fledged TLS > Extensions API. > > Adding ALPN [0] support to JDK 9 requires, differently from other TLS > extensions, to provide application code that will be run in the > context of the TLS implementation, rather than just values such as > booleans or strings. That's going to be interesting if you need to support non-blocking operation for use with SSLEngine. > IMHO this chance can be lifted to provide a full TLS Extensions API. I don't think this is possible because TLS extensions can alter the TLS handshake, result in additional messages being exchanged, and generally alter the protocol in unforeseeable ways. On top of that, the concrete TLS implementation is not fixed, it can be swapped out, so tying the extension API to the existing OpenJDK internals will not work for everyone. -- Florian Weimer / Red Hat Product Security From simone.bordet at gmail.com Mon Nov 10 13:28:44 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 10 Nov 2014 14:28:44 +0100 Subject: A fully fledged TLS Extensions API ? In-Reply-To: <5460B89D.5020203@redhat.com> References: <5460B89D.5020203@redhat.com> Message-ID: Hi, On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer wrote: > On 11/07/2014 02:06 PM, Simone Bordet wrote: > >> This email is about the idea to introduce in JDK 9 a fully fledged TLS >> Extensions API. >> >> Adding ALPN [0] support to JDK 9 requires, differently from other TLS >> extensions, to provide application code that will be run in the >> context of the TLS implementation, rather than just values such as >> booleans or strings. > > > That's going to be interesting if you need to support non-blocking operation > for use with SSLEngine. In the case where you have to load the configuration from a place where it may take a lot of time, you can easily change the ALPN API to something like: For the client: void selected(String protocol, CompletableFuture callback) For the server: void select(List protocols, CompletableFuture callback) and when you're done call callback.complete() or callback.completeExceptionally(). This would mean that the TLS implementation has to wait for those callbacks to be completed before proceeding. On one side, having application code to complete the callbacks is, in our experience, error prone (i.e. applications forget it) On the other side, applications that make use of this API are typically on the implementer side rather than on the developer side (here I mean people that implement a server, rather than a developer of a webapp), so I guess a callback, albeit more complex, may give implementers more room for different implementations. >> IMHO this chance can be lifted to provide a full TLS Extensions API. > > I don't think this is possible because TLS extensions can alter the TLS > handshake, result in additional messages being exchanged, and generally > alter the protocol in unforeseeable ways. On top of that, the concrete TLS > implementation is not fixed, it can be swapped out, so tying the extension > API to the existing OpenJDK internals will not work for everyone. Can you expand what you mean here ? If a TLS extensions API is provided by JDK 9, would it not be implemented by providers like they do with the other APIs they have to implement to be a compliant provider ? It's a little more effort for providers, but with a public API should be implementable by any provider and an application would be portable across providers. 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 david.lloyd at redhat.com Mon Nov 10 14:12:31 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 10 Nov 2014 08:12:31 -0600 Subject: A fully fledged TLS Extensions API ? In-Reply-To: References: <5460B89D.5020203@redhat.com> Message-ID: <5460C7CF.9070909@redhat.com> On 11/10/2014 07:28 AM, Simone Bordet wrote: > Hi, > > On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer wrote: >> On 11/07/2014 02:06 PM, Simone Bordet wrote: >> >>> This email is about the idea to introduce in JDK 9 a fully fledged TLS >>> Extensions API. >>> >>> Adding ALPN [0] support to JDK 9 requires, differently from other TLS >>> extensions, to provide application code that will be run in the >>> context of the TLS implementation, rather than just values such as >>> booleans or strings. >> >> >> That's going to be interesting if you need to support non-blocking operation >> for use with SSLEngine. > > In the case where you have to load the configuration from a place > where it may take a lot of time, you can easily change the ALPN API to > something like: > > For the client: > void selected(String protocol, CompletableFuture callback) > > For the server: > void select(List protocols, CompletableFuture callback) > > and when you're done call callback.complete() or > callback.completeExceptionally(). Note that SSLEngine already has an opaque "runnable tasks" mechanism that non-blocking implementations have to deal with. Implementations already cannot assume that these tasks do not block, so any blocking work can just be wrapped in one of these. Not that I'm specifically endorsing this idea (or not); I just wanted to clarify that fact. -- - DML From sean.mullan at oracle.com Mon Nov 10 16:50:02 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Nov 2014 11:50:02 -0500 Subject: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities In-Reply-To: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> References: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> Message-ID: <5460ECBA.9010204@oracle.com> A few comments: * KeystoreImpl.m - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? - update copyright year * KeychainStore.java 297-304 I think it would be cleaner to write these lines as: } else { KeyEntry ke = (KeyEntry)entry; if (ke.chain == null || ke.chain.length == 0) { return null; } return ke.chain[0]; } 623-629 similar comment as above * ListKeychainStore.sh # See JDK-8046777 123,166: No need to add this comment, @bug label and source code history is sufficient. 156 if [ $RECOUNT -lt `expr $COUNT + 3 + 1` ]; then change to $COUNT + 4 157 echo "Error: expected >=4 private key entries in the Keychain keystores" $COUNT is the number of private keys in the keystore before testing, so original code is still correct: "expected >$COUNT" --Sean On 10/29/2014 07:48 PM, Vincent Ryan wrote: > Please review this fix contributed by David Kocher. > > It corrects an issue in the Keychain keystore implementation for Mac OS where private keys > configured with a key usage other than ?any? are not retrieved. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8046777 > Webrev: http://cr.openjdk.java.net/~vinnie/8046777/webrev.00/ > > Thanks. > From vincent.x.ryan at oracle.com Mon Nov 10 18:05:37 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 10 Nov 2014 18:05:37 +0000 Subject: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities In-Reply-To: <5460ECBA.9010204@oracle.com> References: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> <5460ECBA.9010204@oracle.com> Message-ID: Thanks Sean. I?ve generated a new webrev that addresses your comments: http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/ On 10 Nov 2014, at 16:50, Sean Mullan wrote: > A few comments: > > * KeystoreImpl.m > > - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? > > - update copyright year > > * KeychainStore.java > > 297-304 I think it would be cleaner to write these lines as: > > } else { > KeyEntry ke = (KeyEntry)entry; > if (ke.chain == null || ke.chain.length == 0) { > return null; > } > return ke.chain[0]; > } > > 623-629 similar comment as above > > * ListKeychainStore.sh > > # See JDK-8046777 > > 123,166: No need to add this comment, @bug label and source code history is sufficient. > > 156 if [ $RECOUNT -lt `expr $COUNT + 3 + 1` ]; then > > change to $COUNT + 4 > > 157 echo "Error: expected >=4 private key entries in the Keychain keystores" > > $COUNT is the number of private keys in the keystore before testing, so original code is still correct: "expected >$COUNT" > > --Sean > > On 10/29/2014 07:48 PM, Vincent Ryan wrote: >> Please review this fix contributed by David Kocher. >> >> It corrects an issue in the Keychain keystore implementation for Mac OS where private keys >> configured with a key usage other than ?any? are not retrieved. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046777 >> Webrev: http://cr.openjdk.java.net/~vinnie/8046777/webrev.00/ >> >> Thanks. >> From sean.mullan at oracle.com Mon Nov 10 18:13:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Nov 2014 13:13:18 -0500 Subject: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities In-Reply-To: References: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> <5460ECBA.9010204@oracle.com> Message-ID: <5461003E.9090406@oracle.com> You missed one of my comments: >> 623-629 similar comment as above Otherwise looks fine. --Sean On 11/10/2014 01:05 PM, Vincent Ryan wrote: > Thanks Sean. I?ve generated a new webrev that addresses your comments: > http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/ > > On 10 Nov 2014, at 16:50, Sean Mullan wrote: > >> A few comments: >> >> * KeystoreImpl.m >> >> - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? >> >> - update copyright year >> >> * KeychainStore.java >> >> 297-304 I think it would be cleaner to write these lines as: >> >> } else { >> KeyEntry ke = (KeyEntry)entry; >> if (ke.chain == null || ke.chain.length == 0) { >> return null; >> } >> return ke.chain[0]; >> } >> >> 623-629 similar comment as above >> >> * ListKeychainStore.sh >> >> # See JDK-8046777 >> >> 123,166: No need to add this comment, @bug label and source code history is sufficient. >> >> 156 if [ $RECOUNT -lt `expr $COUNT + 3 + 1` ]; then >> >> change to $COUNT + 4 >> >> 157 echo "Error: expected >=4 private key entries in the Keychain keystores" >> >> $COUNT is the number of private keys in the keystore before testing, so original code is still correct: "expected >$COUNT" >> >> --Sean >> >> On 10/29/2014 07:48 PM, Vincent Ryan wrote: >>> Please review this fix contributed by David Kocher. >>> >>> It corrects an issue in the Keychain keystore implementation for Mac OS where private keys >>> configured with a key usage other than ?any? are not retrieved. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046777 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8046777/webrev.00/ >>> >>> Thanks. >>> > From vincent.x.ryan at oracle.com Mon Nov 10 18:48:34 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 10 Nov 2014 18:48:34 +0000 Subject: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities In-Reply-To: <5461003E.9090406@oracle.com> References: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> <5460ECBA.9010204@oracle.com> <5461003E.9090406@oracle.com> Message-ID: <4B3BDB69-69EE-48AB-8D40-F6CA4E390C1B@oracle.com> On 10 Nov 2014, at 18:13, Sean Mullan wrote: > You missed one of my comments: > > >> 623-629 similar comment as above I made the change to join the two if statements into a single one. Did you want me to use a local variable instead of casts? > > Otherwise looks fine. > > --Sean > > On 11/10/2014 01:05 PM, Vincent Ryan wrote: >> Thanks Sean. I?ve generated a new webrev that addresses your comments: >> http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/ >> >> On 10 Nov 2014, at 16:50, Sean Mullan wrote: >> >>> A few comments: >>> >>> * KeystoreImpl.m >>> >>> - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? >>> >>> - update copyright year >>> >>> * KeychainStore.java >>> >>> 297-304 I think it would be cleaner to write these lines as: >>> >>> } else { >>> KeyEntry ke = (KeyEntry)entry; >>> if (ke.chain == null || ke.chain.length == 0) { >>> return null; >>> } >>> return ke.chain[0]; >>> } >>> >>> 623-629 similar comment as above >>> >>> * ListKeychainStore.sh >>> >>> # See JDK-8046777 >>> >>> 123,166: No need to add this comment, @bug label and source code history is sufficient. >>> >>> 156 if [ $RECOUNT -lt `expr $COUNT + 3 + 1` ]; then >>> >>> change to $COUNT + 4 >>> >>> 157 echo "Error: expected >=4 private key entries in the Keychain keystores" >>> >>> $COUNT is the number of private keys in the keystore before testing, so original code is still correct: "expected >$COUNT" >>> >>> --Sean >>> >>> On 10/29/2014 07:48 PM, Vincent Ryan wrote: >>>> Please review this fix contributed by David Kocher. >>>> >>>> It corrects an issue in the Keychain keystore implementation for Mac OS where private keys >>>> configured with a key usage other than ?any? are not retrieved. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046777 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8046777/webrev.00/ >>>> >>>> Thanks. >>>> >> From ecki at zusammenkunft.net Mon Nov 10 21:36:30 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 10 Nov 2014 22:36:30 +0100 Subject: A fully fledged TLS Extensions API ? In-Reply-To: References: <5460B89D.5020203@redhat.com> Message-ID: <20141110223630.00005edb.ecki@zusammenkunft.net> Hello, the question is, what is a extension API actually helping with: the JSSE implementation is slow to adopt to typical advances in TLS browser "wars". While this is not so bad as nobody implements a Web Browser in Java anyway, it does make it harder for server vendors to offer a full stack (without native libraries or reverse proxies). Having an API to handle extensions could help with this a bit, however a lot of the extensions cannot be bolted on, they alter the handshake sequence, introduce new messages or alter interpretatrion of existing enums. So while ALPN can be handled pretty easily, it would be harder for things like eliptic_curves or supported_signatures or SRP (or Poly authenticator) - or TLS_FALLBACK_SCSV (or simple things like rate limiting the renegotiations). The other question is, if advances in SSL/TLS protocol really need to be bound with major java versions. It would do the world a favor to have a backport of a system property allowing TLS1.2 to be used by default. Having the JSSE implementation beeing its own sub project under the openjdk could help with that. Especially if providers become more plugable. And optimizations like intrinsic are not bound to the providers, but to the actual primitive needed (like AES GCM). Gruss Bernd Am Mon, 10 Nov 2014 14:28:44 +0100 schrieb Simone Bordet : > Hi, > > On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer > wrote: > > On 11/07/2014 02:06 PM, Simone Bordet wrote: > > > >> This email is about the idea to introduce in JDK 9 a fully fledged > >> TLS Extensions API. > >> > >> Adding ALPN [0] support to JDK 9 requires, differently from other > >> TLS extensions, to provide application code that will be run in the > >> context of the TLS implementation, rather than just values such as > >> booleans or strings. > > > > > > That's going to be interesting if you need to support non-blocking > > operation for use with SSLEngine. > > In the case where you have to load the configuration from a place > where it may take a lot of time, you can easily change the ALPN API to > something like: > > For the client: > void selected(String protocol, CompletableFuture callback) > > For the server: > void select(List protocols, CompletableFuture > callback) > > and when you're done call callback.complete() or > callback.completeExceptionally(). > > This would mean that the TLS implementation has to wait for those > callbacks to be completed before proceeding. > > On one side, having application code to complete the callbacks is, in > our experience, error prone (i.e. applications forget it) > On the other side, applications that make use of this API are > typically on the implementer side rather than on the developer side > (here I mean people that implement a server, rather than a developer > of a webapp), so I guess a callback, albeit more complex, may give > implementers more room for different implementations. > > >> IMHO this chance can be lifted to provide a full TLS Extensions > >> API. > > > > I don't think this is possible because TLS extensions can alter the > > TLS handshake, result in additional messages being exchanged, and > > generally alter the protocol in unforeseeable ways. On top of > > that, the concrete TLS implementation is not fixed, it can be > > swapped out, so tying the extension API to the existing OpenJDK > > internals will not work for everyone. > > Can you expand what you mean here ? > If a TLS extensions API is provided by JDK 9, would it not be > implemented by providers like they do with the other APIs they have to > implement to be a compliant provider ? > It's a little more effort for providers, but with a public API should > be implementable by any provider and an application would be portable > across providers. > > Thanks ! > From vincent.x.ryan at oracle.com Mon Nov 10 21:53:15 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 10 Nov 2014 21:53:15 +0000 Subject: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities In-Reply-To: <4B3BDB69-69EE-48AB-8D40-F6CA4E390C1B@oracle.com> References: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> <5460ECBA.9010204@oracle.com> <5461003E.9090406@oracle.com> <4B3BDB69-69EE-48AB-8D40-F6CA4E390C1B@oracle.com> Message-ID: <1BB3AB6A-31AC-4456-837F-22A5D77026DA@oracle.com> I?ve updated the fix to reduce the casts to KeyEntry: http://cr.openjdk.java.net/~vinnie/8046777/webrev.02/ On 10 Nov 2014, at 18:48, Vincent Ryan wrote: > > On 10 Nov 2014, at 18:13, Sean Mullan wrote: > >> You missed one of my comments: >> >>>> 623-629 similar comment as above > > I made the change to join the two if statements into a single one. > Did you want me to use a local variable instead of casts? > >> >> Otherwise looks fine. >> >> --Sean >> >> On 11/10/2014 01:05 PM, Vincent Ryan wrote: >>> Thanks Sean. I?ve generated a new webrev that addresses your comments: >>> http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/ >>> >>> On 10 Nov 2014, at 16:50, Sean Mullan wrote: >>> >>>> A few comments: >>>> >>>> * KeystoreImpl.m >>>> >>>> - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? >>>> >>>> - update copyright year >>>> >>>> * KeychainStore.java >>>> >>>> 297-304 I think it would be cleaner to write these lines as: >>>> >>>> } else { >>>> KeyEntry ke = (KeyEntry)entry; >>>> if (ke.chain == null || ke.chain.length == 0) { >>>> return null; >>>> } >>>> return ke.chain[0]; >>>> } >>>> >>>> 623-629 similar comment as above >>>> >>>> * ListKeychainStore.sh >>>> >>>> # See JDK-8046777 >>>> >>>> 123,166: No need to add this comment, @bug label and source code history is sufficient. >>>> >>>> 156 if [ $RECOUNT -lt `expr $COUNT + 3 + 1` ]; then >>>> >>>> change to $COUNT + 4 >>>> >>>> 157 echo "Error: expected >=4 private key entries in the Keychain keystores" >>>> >>>> $COUNT is the number of private keys in the keystore before testing, so original code is still correct: "expected >$COUNT" >>>> >>>> --Sean >>>> >>>> On 10/29/2014 07:48 PM, Vincent Ryan wrote: >>>>> Please review this fix contributed by David Kocher. >>>>> >>>>> It corrects an issue in the Keychain keystore implementation for Mac OS where private keys >>>>> configured with a key usage other than ?any? are not retrieved. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046777 >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8046777/webrev.00/ >>>>> >>>>> Thanks. >>>>> >>> > From david.lloyd at redhat.com Mon Nov 10 22:13:31 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 10 Nov 2014 16:13:31 -0600 Subject: A fully fledged TLS Extensions API ? In-Reply-To: <20141110223630.00005edb.ecki@zusammenkunft.net> References: <5460B89D.5020203@redhat.com> <20141110223630.00005edb.ecki@zusammenkunft.net> Message-ID: <5461388B.8070102@redhat.com> Another area of applicability is inner authentication mechanisms which make use of channel binding; these mechanisms need to actually acquire chunks of data from the handshake exchange. http://tools.ietf.org/html/rfc5929 for more info On 11/10/2014 03:36 PM, Bernd Eckenfels wrote: > Hello, > > the question is, what is a extension API actually helping with: the JSSE > implementation is slow to adopt to typical advances in TLS browser > "wars". While this is not so bad as nobody implements a Web Browser in > Java anyway, it does make it harder for server vendors to offer a full > stack (without native libraries or reverse proxies). > > Having an API to handle extensions could help with this a bit, however > a lot of the extensions cannot be bolted on, they alter the handshake > sequence, introduce new messages or alter interpretatrion of existing > enums. So while ALPN can be handled pretty easily, it would be harder > for things like eliptic_curves or supported_signatures or SRP (or Poly > authenticator) - or TLS_FALLBACK_SCSV (or simple things like rate > limiting the renegotiations). > > The other question is, if advances in SSL/TLS protocol really need to > be bound with major java versions. It would do the world a favor to > have a backport of a system property allowing TLS1.2 to be used by > default. Having the JSSE implementation beeing its own sub project > under the openjdk could help with that. Especially if providers become > more plugable. And optimizations like intrinsic are not bound to the > providers, but to the actual primitive needed (like AES GCM). > > Gruss > Bernd > > Am Mon, 10 Nov 2014 14:28:44 +0100 > schrieb Simone Bordet : > >> Hi, >> >> On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer >> wrote: >>> On 11/07/2014 02:06 PM, Simone Bordet wrote: >>> >>>> This email is about the idea to introduce in JDK 9 a fully fledged >>>> TLS Extensions API. >>>> >>>> Adding ALPN [0] support to JDK 9 requires, differently from other >>>> TLS extensions, to provide application code that will be run in the >>>> context of the TLS implementation, rather than just values such as >>>> booleans or strings. >>> >>> >>> That's going to be interesting if you need to support non-blocking >>> operation for use with SSLEngine. >> >> In the case where you have to load the configuration from a place >> where it may take a lot of time, you can easily change the ALPN API to >> something like: >> >> For the client: >> void selected(String protocol, CompletableFuture callback) >> >> For the server: >> void select(List protocols, CompletableFuture >> callback) >> >> and when you're done call callback.complete() or >> callback.completeExceptionally(). >> >> This would mean that the TLS implementation has to wait for those >> callbacks to be completed before proceeding. >> >> On one side, having application code to complete the callbacks is, in >> our experience, error prone (i.e. applications forget it) >> On the other side, applications that make use of this API are >> typically on the implementer side rather than on the developer side >> (here I mean people that implement a server, rather than a developer >> of a webapp), so I guess a callback, albeit more complex, may give >> implementers more room for different implementations. >> >>>> IMHO this chance can be lifted to provide a full TLS Extensions >>>> API. >>> >>> I don't think this is possible because TLS extensions can alter the >>> TLS handshake, result in additional messages being exchanged, and >>> generally alter the protocol in unforeseeable ways. On top of >>> that, the concrete TLS implementation is not fixed, it can be >>> swapped out, so tying the extension API to the existing OpenJDK >>> internals will not work for everyone. >> >> Can you expand what you mean here ? >> If a TLS extensions API is provided by JDK 9, would it not be >> implemented by providers like they do with the other APIs they have to >> implement to be a compliant provider ? >> It's a little more effort for providers, but with a public API should >> be implementable by any provider and an application would be portable >> across providers. >> >> Thanks ! >> > -- - DML From simone.bordet at gmail.com Mon Nov 10 22:50:24 2014 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 10 Nov 2014 23:50:24 +0100 Subject: A fully fledged TLS Extensions API ? In-Reply-To: <20141110223630.00005edb.ecki@zusammenkunft.net> References: <5460B89D.5020203@redhat.com> <20141110223630.00005edb.ecki@zusammenkunft.net> Message-ID: Hi, On Mon, Nov 10, 2014 at 10:36 PM, Bernd Eckenfels wrote: > Hello, > > the question is, what is a extension API actually helping with: the JSSE > implementation is slow to adopt to typical advances in TLS browser > "wars". While this is not so bad as nobody implements a Web Browser in > Java anyway, it does make it harder for server vendors to offer a full > stack (without native libraries or reverse proxies). Well, JEP 110 (http://openjdk.java.net/jeps/110) is about a HTTP client that supports h2. I think it's not too far-fetched to expect jfx/swing widgets, JAX-RS clients, etc. to support h2 in a close future, so I would not rule out h2 support for clients. ALPN would be a prerequisite for h2, since unlikely servers will implement h2 in the clear. > Having an API to handle extensions could help with this a bit, however > a lot of the extensions cannot be bolted on, they alter the handshake > sequence, introduce new messages or alter interpretatrion of existing > enums. So while ALPN can be handled pretty easily, it would be harder > for things like eliptic_curves or supported_signatures or SRP (or Poly > authenticator) - or TLS_FALLBACK_SCSV (or simple things like rate > limiting the renegotiations). For example for the NPN extension to work, it requires collaboration with the TLS implementation to send a new TLS message at the right moment. A JDK 9 client application would be able to add the NPN extension via the API, but then the JDK would not be able to send the new message at the right time because NPN won't be implemented in JDK 9. There are several ways to handle these cases, but I agree that they may expose an overspecification of the API similar to that of the collections API: throw UnsupportedOperationException if you can't handle it (e.g. Iterator.remove()). Whether there is more advantage for applications to have the API and risk an UOE, or not having the API and be stuck, I don't know (and it's the reason for this email, to discuss it :) A declaration of the impact of an extension on the TLS protocol, akin to Spliterator.characteristics() may help. Some extensions have no impact and may be freely added, others require the TLS implementation cooperation. A couple more callbacks for [Client|Server]Hello received, for applications to interact with the extensions for SSLSocket (similar to HandshakeCompletedListener) would be needed too. 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 weijun.wang at oracle.com Tue Nov 11 02:58:07 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Nov 2014 10:58:07 +0800 Subject: RFR 8063087: policytool reports error message with prefix of "java.lang.Exception" Message-ID: Please review the fix at http://cr.openjdk.java.net/~weijun/8063087/webrev.00/ which is simply void displayErrorDialog(Window w, Throwable t) { if (t instanceof NoDisplayException) { return; } + if (t.getClass() == Exception.class) { + displayErrorDialog(w, t.getLocalizedMessage()); + } else { displayErrorDialog(w, t.toString()); + } } Error messages like "java.lang.Exception:No Policy Entry selected" is now "No Policy Entry selected". For other exception types, there will be no change. Thanks Max From xuelei.fan at oracle.com Tue Nov 11 03:14:50 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Nov 2014 11:14:50 +0800 Subject: RFR 8063087: policytool reports error message with prefix of "java.lang.Exception" In-Reply-To: References: Message-ID: <54617F2A.4020609@oracle.com> Why not use "instanceof"? Xuelei On 11/11/2014 10:58 AM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8063087/webrev.00/ > > which is simply > > void displayErrorDialog(Window w, Throwable t) { > if (t instanceof NoDisplayException) { > return; > } > > + if (t.getClass() == Exception.class) { > + displayErrorDialog(w, t.getLocalizedMessage()); > + } else { > displayErrorDialog(w, t.toString()); > + } > } > > Error messages like "java.lang.Exception:No Policy Entry selected" is now "No Policy Entry selected". For other exception types, there will be no change. > > Thanks > Max > From xuelei.fan at oracle.com Tue Nov 11 03:33:16 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Nov 2014 11:33:16 +0800 Subject: JDK 9 Review Request for 8046949: Generify the javax.xml.crypto API In-Reply-To: <54538EDC.9030803@oracle.com> References: <54538EDC.9030803@oracle.com> Message-ID: <5461837C.7050408@oracle.com> Looks fine to me. A pretty minor comment. share/classes/javax/xml/crypto/dsig/spec/XPathType.java ----------------------- 157 this.expression = expression; 158 this.filter = filter; 159 if (namespaceMap == null) { 160 throw new NullPointerException("namespaceMap cannot be null"); 161 } I would like to check "namespaceMap == null" before the assignment of this.expression and this.filter. Thanks, Xuelei On 10/31/2014 9:30 PM, Sean Mullan wrote: > Earlier this year, we dropped the requirement to deliver JSR 105 (XML > Digital Signature API) as a standalone JSR [1], which will make it > easier to add some long-standing enhancements to the API. > > The first of those is to finally add support for generics to the API: > > - all Collection and Iterator parameters and return types have been > changed to parameterized types > - javax.xml.crypto.NodeSetData has been changed to a generic class and > also now implements Iterable so that it can be used in for-each loops > - many SuppressWarnings annotations have been removed as they are no > longer applicable > > Issue: https://bugs.openjdk.java.net/browse/JDK-8046949 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8046949/webrev.00/ > > --Sean > > [1] https://jcp.org/en/jsr/proposalDetails?id=105 From weijun.wang at oracle.com Tue Nov 11 05:31:39 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Nov 2014 13:31:39 +0800 Subject: RFR 8063087: policytool reports error message with prefix of "java.lang.Exception" In-Reply-To: <54617F2A.4020609@oracle.com> References: <54617F2A.4020609@oracle.com> Message-ID: <5E196766-A4FF-4BDC-830B-DFE9DB8EB6A0@oracle.com> A subclass of Exception would also return true when using instanceof, where I think the class name is still informational. --Max > On Nov 11, 2014, at 11:14, Xuelei Fan wrote: > > Why not use "instanceof"? > > Xuelei > > On 11/11/2014 10:58 AM, Wang Weijun wrote: >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8063087/webrev.00/ >> >> which is simply >> >> void displayErrorDialog(Window w, Throwable t) { >> if (t instanceof NoDisplayException) { >> return; >> } >> >> + if (t.getClass() == Exception.class) { >> + displayErrorDialog(w, t.getLocalizedMessage()); >> + } else { >> displayErrorDialog(w, t.toString()); >> + } >> } >> >> Error messages like "java.lang.Exception:No Policy Entry selected" is now "No Policy Entry selected". For other exception types, there will be no change. >> >> Thanks >> Max >> > From xuelei.fan at oracle.com Tue Nov 11 07:06:49 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Nov 2014 15:06:49 +0800 Subject: RFR 8063087: policytool reports error message with prefix of "java.lang.Exception" In-Reply-To: <5E196766-A4FF-4BDC-830B-DFE9DB8EB6A0@oracle.com> References: <54617F2A.4020609@oracle.com> <5E196766-A4FF-4BDC-830B-DFE9DB8EB6A0@oracle.com> Message-ID: <5461B589.2060209@oracle.com> On 11/11/2014 1:31 PM, Wang Weijun wrote: > A subclass of Exception would also return true when using instanceof, where I think the class name is still informational. > Got it. But Exception is still informational as it means it is not an other exception. I'm not sure it is something we really want to address. The coding logic does not looks reasonable or friendly. Or, would you please add some comments about why you want to treat the exception differently? Thanks, Xuelei > --Max > >> On Nov 11, 2014, at 11:14, Xuelei Fan wrote: >> >> Why not use "instanceof"? >> >> Xuelei >> >> On 11/11/2014 10:58 AM, Wang Weijun wrote: >>> Please review the fix at >>> >>> http://cr.openjdk.java.net/~weijun/8063087/webrev.00/ >>> >>> which is simply >>> >>> void displayErrorDialog(Window w, Throwable t) { >>> if (t instanceof NoDisplayException) { >>> return; >>> } >>> >>> + if (t.getClass() == Exception.class) { >>> + displayErrorDialog(w, t.getLocalizedMessage()); >>> + } else { >>> displayErrorDialog(w, t.toString()); >>> + } >>> } >>> >>> Error messages like "java.lang.Exception:No Policy Entry selected" is now "No Policy Entry selected". For other exception types, there will be no change. >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Tue Nov 11 08:54:05 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 11 Nov 2014 16:54:05 +0800 Subject: RFR 8063087: policytool reports error message with prefix of "java.lang.Exception" In-Reply-To: <5461B589.2060209@oracle.com> References: <54617F2A.4020609@oracle.com> <5E196766-A4FF-4BDC-830B-DFE9DB8EB6A0@oracle.com> <5461B589.2060209@oracle.com> Message-ID: <3942B133-871F-4B29-8F97-9B4564742BC6@oracle.com> > On Nov 11, 2014, at 15:06, Xuelei Fan wrote: > > On 11/11/2014 1:31 PM, Wang Weijun wrote: >> A subclass of Exception would also return true when using instanceof, where I think the class name is still informational. >> > Got it. But Exception is still informational as it means it is not an > other exception. Well, an Exception is usually thrown inside policytool to mark a user interaction error, while other exception types are about other errors, for example, a keystore cannot be loaded, a principal cannot be constructed etc. Therefore I think it's reasonable to omit the prefix of Exception. > > I'm not sure it is something we really want to address. The coding > logic does not looks reasonable or friendly. Or, would you please add > some comments about why you want to treat the exception differently? OK, I'll add my explanation above. Is that OK? Thanks Max > > Thanks, > Xuelei > >> --Max >> >>> On Nov 11, 2014, at 11:14, Xuelei Fan wrote: >>> >>> Why not use "instanceof"? >>> >>> Xuelei >>> >>> On 11/11/2014 10:58 AM, Wang Weijun wrote: >>>> Please review the fix at >>>> >>>> http://cr.openjdk.java.net/~weijun/8063087/webrev.00/ >>>> >>>> which is simply >>>> >>>> void displayErrorDialog(Window w, Throwable t) { >>>> if (t instanceof NoDisplayException) { >>>> return; >>>> } >>>> >>>> + if (t.getClass() == Exception.class) { >>>> + displayErrorDialog(w, t.getLocalizedMessage()); >>>> + } else { >>>> displayErrorDialog(w, t.toString()); >>>> + } >>>> } >>>> >>>> Error messages like "java.lang.Exception:No Policy Entry selected" is now "No Policy Entry selected". For other exception types, there will be no change. >>>> >>>> Thanks >>>> Max >>>> >>> >> > From xuelei.fan at oracle.com Tue Nov 11 11:03:59 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Nov 2014 19:03:59 +0800 Subject: RFR 8063087: policytool reports error message with prefix of "java.lang.Exception" In-Reply-To: <3942B133-871F-4B29-8F97-9B4564742BC6@oracle.com> References: <54617F2A.4020609@oracle.com> <5E196766-A4FF-4BDC-830B-DFE9DB8EB6A0@oracle.com> <5461B589.2060209@oracle.com> <3942B133-871F-4B29-8F97-9B4564742BC6@oracle.com> Message-ID: <5461ED1F.1080006@oracle.com> Looks fine to me. Xuelei On 11/11/2014 4:54 PM, Wang Weijun wrote: > >> On Nov 11, 2014, at 15:06, Xuelei Fan wrote: >> >> On 11/11/2014 1:31 PM, Wang Weijun wrote: >>> A subclass of Exception would also return true when using instanceof, where I think the class name is still informational. >>> >> Got it. But Exception is still informational as it means it is not an >> other exception. > > Well, an Exception is usually thrown inside policytool to mark a user interaction error, while other exception types are about other errors, for example, a keystore cannot be loaded, a principal cannot be constructed etc. Therefore I think it's reasonable to omit the prefix of Exception. > >> >> I'm not sure it is something we really want to address. The coding >> logic does not looks reasonable or friendly. Or, would you please add >> some comments about why you want to treat the exception differently? > > OK, I'll add my explanation above. Is that OK? > > Thanks > Max > >> >> Thanks, >> Xuelei >> >>> --Max >>> >>>> On Nov 11, 2014, at 11:14, Xuelei Fan wrote: >>>> >>>> Why not use "instanceof"? >>>> >>>> Xuelei >>>> >>>> On 11/11/2014 10:58 AM, Wang Weijun wrote: >>>>> Please review the fix at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8063087/webrev.00/ >>>>> >>>>> which is simply >>>>> >>>>> void displayErrorDialog(Window w, Throwable t) { >>>>> if (t instanceof NoDisplayException) { >>>>> return; >>>>> } >>>>> >>>>> + if (t.getClass() == Exception.class) { >>>>> + displayErrorDialog(w, t.getLocalizedMessage()); >>>>> + } else { >>>>> displayErrorDialog(w, t.toString()); >>>>> + } >>>>> } >>>>> >>>>> Error messages like "java.lang.Exception:No Policy Entry selected" is now "No Policy Entry selected". For other exception types, there will be no change. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> >>> >> > From sean.mullan at oracle.com Tue Nov 11 13:17:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Nov 2014 08:17:18 -0500 Subject: [9] request for review 8046777: apple.security.KeychainStore has a problem searching for identities In-Reply-To: <1BB3AB6A-31AC-4456-837F-22A5D77026DA@oracle.com> References: <6FD8CC8B-3D62-40EF-A90D-830CEAF6AB7B@oracle.com> <5460ECBA.9010204@oracle.com> <5461003E.9090406@oracle.com> <4B3BDB69-69EE-48AB-8D40-F6CA4E390C1B@oracle.com> <1BB3AB6A-31AC-4456-837F-22A5D77026DA@oracle.com> Message-ID: <54620C5E.6090308@oracle.com> Looks good. --Sean On 11/10/2014 04:53 PM, Vincent Ryan wrote: > I?ve updated the fix to reduce the casts to KeyEntry: > http://cr.openjdk.java.net/~vinnie/8046777/webrev.02/ > > > On 10 Nov 2014, at 18:48, Vincent Ryan wrote: > >> >> On 10 Nov 2014, at 18:13, Sean Mullan wrote: >> >>> You missed one of my comments: >>> >>>>> 623-629 similar comment as above >> >> I made the change to join the two if statements into a single one. >> Did you want me to use a local variable instead of casts? >> >>> >>> Otherwise looks fine. >>> >>> --Sean >>> >>> On 11/10/2014 01:05 PM, Vincent Ryan wrote: >>>> Thanks Sean. I?ve generated a new webrev that addresses your comments: >>>> http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/ >>>> >>>> On 10 Nov 2014, at 16:50, Sean Mullan wrote: >>>> >>>>> A few comments: >>>>> >>>>> * KeystoreImpl.m >>>>> >>>>> - it is odd to have a comment embedded in the parameter list and makes the line very long. Can you move this comment above the call? >>>>> >>>>> - update copyright year >>>>> >>>>> * KeychainStore.java >>>>> >>>>> 297-304 I think it would be cleaner to write these lines as: >>>>> >>>>> } else { >>>>> KeyEntry ke = (KeyEntry)entry; >>>>> if (ke.chain == null || ke.chain.length == 0) { >>>>> return null; >>>>> } >>>>> return ke.chain[0]; >>>>> } >>>>> >>>>> 623-629 similar comment as above >>>>> >>>>> * ListKeychainStore.sh >>>>> >>>>> # See JDK-8046777 >>>>> >>>>> 123,166: No need to add this comment, @bug label and source code history is sufficient. >>>>> >>>>> 156 if [ $RECOUNT -lt `expr $COUNT + 3 + 1` ]; then >>>>> >>>>> change to $COUNT + 4 >>>>> >>>>> 157 echo "Error: expected >=4 private key entries in the Keychain keystores" >>>>> >>>>> $COUNT is the number of private keys in the keystore before testing, so original code is still correct: "expected >$COUNT" >>>>> >>>>> --Sean >>>>> >>>>> On 10/29/2014 07:48 PM, Vincent Ryan wrote: >>>>>> Please review this fix contributed by David Kocher. >>>>>> >>>>>> It corrects an issue in the Keychain keystore implementation for Mac OS where private keys >>>>>> configured with a key usage other than ?any? are not retrieved. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046777 >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8046777/webrev.00/ >>>>>> >>>>>> Thanks. >>>>>> >>>> >> > From sean.mullan at oracle.com Tue Nov 11 16:59:47 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Nov 2014 11:59:47 -0500 Subject: JDK 9 Review Request for 8046949: Generify the javax.xml.crypto API In-Reply-To: <5461837C.7050408@oracle.com> References: <54538EDC.9030803@oracle.com> <5461837C.7050408@oracle.com> Message-ID: <54624083.6000206@oracle.com> On 11/10/2014 10:33 PM, Xuelei Fan wrote: > Looks fine to me. > > A pretty minor comment. > > share/classes/javax/xml/crypto/dsig/spec/XPathType.java > ----------------------- > 157 this.expression = expression; > 158 this.filter = filter; > 159 if (namespaceMap == null) { > 160 throw new NullPointerException("namespaceMap cannot be > null"); > 161 } > > I would like to check "namespaceMap == null" before the assignment of > this.expression and this.filter. I will fix that before I push the changeset. Thanks, Sean > > Thanks, > Xuelei > > On 10/31/2014 9:30 PM, Sean Mullan wrote: >> Earlier this year, we dropped the requirement to deliver JSR 105 (XML >> Digital Signature API) as a standalone JSR [1], which will make it >> easier to add some long-standing enhancements to the API. >> >> The first of those is to finally add support for generics to the API: >> >> - all Collection and Iterator parameters and return types have been >> changed to parameterized types >> - javax.xml.crypto.NodeSetData has been changed to a generic class and >> also now implements Iterable so that it can be used in for-each loops >> - many SuppressWarnings annotations have been removed as they are no >> longer applicable >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8046949 >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8046949/webrev.00/ >> >> --Sean >> >> [1] https://jcp.org/en/jsr/proposalDetails?id=105 > From weijun.wang at oracle.com Fri Nov 14 02:38:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Nov 2014 10:38:34 +0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 Message-ID: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> Hi All This is a doc change only bug. Fix at http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ Please take a review. Thanks Max From vincent.x.ryan at oracle.com Fri Nov 14 10:58:47 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 14 Nov 2014 10:58:47 +0000 Subject: [9] rfr 8034031: [parfait] JNI exception pending in jdk/src/macosx/native/apple/security/KeystoreImpl.m Message-ID: Please review this fix to check for pending exceptions in JNI: Bug: https://bugs.openjdk.java.net/browse/JDK-8034031 Webrev: http://cr.openjdk.java.net/~vinnie/8034031/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Fri Nov 14 11:08:23 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 14 Nov 2014 11:08:23 +0000 Subject: [9] rfr 8034031: [parfait] JNI exception pending in jdk/src/macosx/native/apple/security/KeystoreImpl.m Message-ID: <63A2D4D8-7D7A-4D8F-89DF-F6D452FCFAED@oracle.com> Please review this fix to check for pending exceptions in JNI: Bug: https://bugs.openjdk.java.net/browse/JDK-8034031 Webrev: http://cr.openjdk.java.net/~vinnie/8034031/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Nov 14 11:38:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Nov 2014 11:38:00 +0000 Subject: [9] rfr 8034031: [parfait] JNI exception pending in jdk/src/macosx/native/apple/security/KeystoreImpl.m In-Reply-To: <63A2D4D8-7D7A-4D8F-89DF-F6D452FCFAED@oracle.com> References: <63A2D4D8-7D7A-4D8F-89DF-F6D452FCFAED@oracle.com> Message-ID: <5465E998.2040109@oracle.com> On 14/11/2014 11:08, Vincent Ryan wrote: > Please review this fix to check for pending exceptions in JNI: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8034031 > Webrev: http://cr.openjdk.java.net/~vinnie/8034031/webrev.00/ > > This looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Nov 14 13:31:13 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Nov 2014 21:31:13 +0800 Subject: [9] rfr 8034031: [parfait] JNI exception pending in jdk/src/macosx/native/apple/security/KeystoreImpl.m In-Reply-To: References: Message-ID: <3CB56F35-1442-4A30-9D80-8E67CF26D17A@oracle.com> The last label has a trailing semicolon. Otherwise good. --Max > On Nov 14, 2014, at 18:58, Vincent Ryan wrote: > > Please review this fix to check for pending exceptions in JNI: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8034031 > Webrev: http://cr.openjdk.java.net/~vinnie/8034031/webrev.00/ > > Thanks. > From vincent.x.ryan at oracle.com Fri Nov 14 13:36:20 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 14 Nov 2014 13:36:20 +0000 Subject: [9] rfr 8034031: [parfait] JNI exception pending in jdk/src/macosx/native/apple/security/KeystoreImpl.m In-Reply-To: <3CB56F35-1442-4A30-9D80-8E67CF26D17A@oracle.com> References: <3CB56F35-1442-4A30-9D80-8E67CF26D17A@oracle.com> Message-ID: Thanks Max. The trailing semicolon is needed to satisfy the compiler (because of the macro that follows). On 14 Nov 2014, at 13:31, Wang Weijun wrote: > The last label has a trailing semicolon. Otherwise good. > > --Max > >> On Nov 14, 2014, at 18:58, Vincent Ryan wrote: >> >> Please review this fix to check for pending exceptions in JNI: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8034031 >> Webrev: http://cr.openjdk.java.net/~vinnie/8034031/webrev.00/ >> >> Thanks. >> > From weijun.wang at oracle.com Sat Nov 15 00:05:37 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 15 Nov 2014 08:05:37 +0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> Message-ID: <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> Webrev withdrawn. I'd like to make more changes. Thanks Max > On Nov 14, 2014, at 10:38, Wang Weijun wrote: > > Hi All > > This is a doc change only bug. Fix at > > http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ > > Please take a review. > > Thanks > Max > From bradford.wetmore at oracle.com Sat Nov 15 00:33:06 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 14 Nov 2014 16:33:06 -0800 Subject: A fully fledged TLS Extensions API ? In-Reply-To: References: Message-ID: <54669F42.6020108@oracle.com> Simone, Your note was good timing. ALPN and HTTP/2 is on our radar for 9, and we're starting to look at options now, maybe even using some type of general extension API. ALPN is pretty straightforward and can be done easily, but there are advantages to having a full extensions API. We're also looking at the older threads for additional context. Brad PS. Just a quick note, the reason for SSLSocket/SSLEngine/SSLParameters having duplicate methods is purely historical. Up to JDK 1.5 we added new methods to SSLEngine/SSLSocket for each new configuration option, but in JDK 6 a parameter group seemed a better way to go, so the "duplicate" APIs were added. The group allowed for a single call, which made for easier config of multiple sockets. sslp = sslSocket1.getSSLParameters(); or sslp = new SSLParameters(); sslp.set...(); sslp.set...(); sslp.set...(); sslSocket2.setSSLParameters(sslp); sslSocket3.setSSLParameters(sslp); On 11/7/2014 5:06 AM, Simone Bordet wrote: > Hi, > > I was writing the email about the ALPN API proposal when I realized > that it would have been better to split the arguments in different > emails. > > This email is about the idea to introduce in JDK 9 a fully fledged TLS > Extensions API. > > Adding ALPN [0] support to JDK 9 requires, differently from other TLS > extensions, to provide application code that will be run in the > context of the TLS implementation, rather than just values such as > booleans or strings. > > IMHO this chance can be lifted to provide a full TLS Extensions API. > Alternative providers such as IAIK offer a private API such as [1]: > > SSLSocket.getActiveExtensions() > SSLSocket.getPeerExtensions() > > Similarly, BouncyCastle offers [2]: > > DefaultTlsClient.getClientExtensions() > > In the JDK there is a class named SSLParameters that contains some of > the configuration values for TLS. > Some of those are duplicated in SSLSocket and SSLEngine (e.g. > wantClientAuth, needClientAuth, etc), with some temporal dependency > (call this before the other, if I have to trust the comments of > SSLSocketImpl.setHost()). > Eventually all values get forwarded to the handshaker, but from the > API point of view it's not very clear what API one should call (the > one on SSLEngine or the one on SSLParameters), nor where the ALPN > setup should be done. > > The idea would then be to introduce a fully fledged TLS extensions API > to handle all the TLS extensions related things, such as > renegotiation, SNI, elliptic curves, NPN, ALPN, session tickets etc. > Both applications and the JDK implementation would be able to leverage > this new API. > > Note that the bulk of this API already exists in sun.security.ssl. > > My question is really whether JDK 9 could take in consideration such > TLS Extension API be exposed publicly for applications to use it. > > See the other emails about ALPN and the interaction between ALPN and > HTTP 2 for further examples of where this TLS Extension API would come > handy. > > Thanks ! > > [0] http://tools.ietf.org/html/rfc7301 > [1] http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/SSLSocket.html > [2] https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/DefaultTlsClient.html > From valerie.peng at oracle.com Sat Nov 15 01:25:09 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 14 Nov 2014 17:25:09 -0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <545BBE8A.6060306@oracle.com> References: <545BBE8A.6060306@oracle.com> Message-ID: <5466AB75.1040807@oracle.com> Max, Most looks fine, just some questions. - Kinit.java: line 56, it should be "sun.security.krb5.internal.tools.Kinit"? - Kinit.java: for the switch block from 135 - 142: add a default case to catch illegal values? - Kinit.java: line 163, doesn't the credentials cache exist already? - KrbAsReq.java: line 128, what if rtime is 0 (default value)? - KDC.java: line 879-883, how can you be sure that there is always more than 1 eType and that the 2nd eType is supported. Valerie On 11/6/2014 10:31 AM, Valerie Peng wrote: > OK, I will take a look. > > Thanks, > Valerie > > On 11/5/2014 10:04 PM, Wang Weijun wrote: >> Ping ping... >> >>> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >>> >>> Anyone can take a look? >>> >>>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>>> >>>> Hi All >>>> >>>> Please review the code change at >>>> >>>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>>> >>>> It adds support for ticket_lifetime and renew_lifetime in >>>> krb5.conf, and add -r -l -R to kinit (on Windows). >>>> >>>> Thanks >>>> Max >>>> From weijun.wang at oracle.com Mon Nov 17 08:23:25 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 17 Nov 2014 16:23:25 +0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <5466AB75.1040807@oracle.com> References: <545BBE8A.6060306@oracle.com> <5466AB75.1040807@oracle.com> Message-ID: <8A2041CF-EE21-44F1-AE81-ECF46758EB3F@oracle.com> > On Nov 15, 2014, at 09:25, Valerie Peng wrote: > > Max, > > Most looks fine, just some questions. > > - Kinit.java: line 56, it should be "sun.security.krb5.internal.tools.Kinit"? Correct. > - Kinit.java: for the switch block from 135 - 142: add a default case to catch illegal values? Done. > - Kinit.java: line 163, doesn't the credentials cache exist already? This line would remove all existing service tickets so they will be re-acquired using the new TGT. I copied this behavior from other vendors. > - KrbAsReq.java: line 128, what if rtime is 0 (default value)? Not sure if I understand. There is no default value for "renew_lifetime". If it does not exist inside krb5.conf, then rtime is not reassigned, which is still null. > - KDC.java: line 879-883, how can you be sure that there is always more than 1 eType and that the 2nd eType is supported. I'll throw KDC_ERR_ETYPE_NOSUPP. Thanks Max > > Valerie > > On 11/6/2014 10:31 AM, Valerie Peng wrote: >> OK, I will take a look. >> >> Thanks, >> Valerie >> >> On 11/5/2014 10:04 PM, Wang Weijun wrote: >>> Ping ping... >>> >>>> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >>>> >>>> Anyone can take a look? >>>> >>>>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>>>> >>>>> Hi All >>>>> >>>>> Please review the code change at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>>>> >>>>> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >>>>> >>>>> Thanks >>>>> Max >>>>> From sean.mullan at oracle.com Mon Nov 17 21:55:53 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Nov 2014 16:55:53 -0500 Subject: Result: New Security Group Member: Anthony Scarpino Message-ID: <546A6EE9.70303@oracle.com> The vote for Anthony Scarpino [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011378.html From valerie.peng at oracle.com Mon Nov 17 23:43:00 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 17 Nov 2014 15:43:00 -0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <8A2041CF-EE21-44F1-AE81-ECF46758EB3F@oracle.com> References: <545BBE8A.6060306@oracle.com> <5466AB75.1040807@oracle.com> <8A2041CF-EE21-44F1-AE81-ECF46758EB3F@oracle.com> Message-ID: <546A8804.9070907@oracle.com> The default value 0 for the "renew_lifetime" is documented in MIT's Kerberos conf documentation. http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html However, I am not sure how this 0 value should be interpreted/handled. Valerie On 11/17/2014 12:23 AM, Wang Weijun wrote: >> On Nov 15, 2014, at 09:25, Valerie Peng wrote: >> >> Max, >> >> Most looks fine, just some questions. >> >> - Kinit.java: line 56, it should be "sun.security.krb5.internal.tools.Kinit"? > Correct. > >> - Kinit.java: for the switch block from 135 - 142: add a default case to catch illegal values? > Done. > >> - Kinit.java: line 163, doesn't the credentials cache exist already? > This line would remove all existing service tickets so they will be re-acquired using the new TGT. I copied this behavior from other vendors. > >> - KrbAsReq.java: line 128, what if rtime is 0 (default value)? > Not sure if I understand. There is no default value for "renew_lifetime". If it does not exist inside krb5.conf, then rtime is not reassigned, which is still null. > >> - KDC.java: line 879-883, how can you be sure that there is always more than 1 eType and that the 2nd eType is supported. > I'll throw KDC_ERR_ETYPE_NOSUPP. > > Thanks > Max > >> Valerie >> >> On 11/6/2014 10:31 AM, Valerie Peng wrote: >>> OK, I will take a look. >>> >>> Thanks, >>> Valerie >>> >>> On 11/5/2014 10:04 PM, Wang Weijun wrote: >>>> Ping ping... >>>> >>>>> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >>>>> >>>>> Anyone can take a look? >>>>> >>>>>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>>>>> >>>>>> Hi All >>>>>> >>>>>> Please review the code change at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>>>>> >>>>>> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> From weijun.wang at oracle.com Tue Nov 18 07:02:56 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 18 Nov 2014 15:02:56 +0800 Subject: RFR 8044500: Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <546A8804.9070907@oracle.com> References: <545BBE8A.6060306@oracle.com> <5466AB75.1040807@oracle.com> <8A2041CF-EE21-44F1-AE81-ECF46758EB3F@oracle.com> <546A8804.9070907@oracle.com> Message-ID: <12D71E87-EF4B-492F-8436-A954165F31E1@oracle.com> > On Nov 18, 2014, at 07:43, Valerie Peng wrote: > > > The default value 0 for the "renew_lifetime" is documented in MIT's Kerberos conf documentation. http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html > However, I am not sure how this 0 value should be interpreted/handled. From what I observe, MIT kinit by default sends a null rtime. So it is the same as us. On the other hand, MIT kinit default sets RENEWABLE_OK, so it always receives a renewable ticket and the renewable lifetime set by KDC. In Java, we only set it when "renewable = true" is included in krb5.conf (see KDCOptions::setDefault), so by default java kinit gets a non-renewable ticket. Thanks Max > Valerie > On 11/17/2014 12:23 AM, Wang Weijun wrote: >>> On Nov 15, 2014, at 09:25, Valerie Peng wrote: >>> >>> Max, >>> >>> Most looks fine, just some questions. >>> >>> - Kinit.java: line 56, it should be "sun.security.krb5.internal.tools.Kinit"? >> Correct. >> >>> - Kinit.java: for the switch block from 135 - 142: add a default case to catch illegal values? >> Done. >> >>> - Kinit.java: line 163, doesn't the credentials cache exist already? >> This line would remove all existing service tickets so they will be re-acquired using the new TGT. I copied this behavior from other vendors. >> >>> - KrbAsReq.java: line 128, what if rtime is 0 (default value)? >> Not sure if I understand. There is no default value for "renew_lifetime". If it does not exist inside krb5.conf, then rtime is not reassigned, which is still null. >> >>> - KDC.java: line 879-883, how can you be sure that there is always more than 1 eType and that the 2nd eType is supported. >> I'll throw KDC_ERR_ETYPE_NOSUPP. >> >> Thanks >> Max >> >>> Valerie >>> >>> On 11/6/2014 10:31 AM, Valerie Peng wrote: >>>> OK, I will take a look. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 11/5/2014 10:04 PM, Wang Weijun wrote: >>>>> Ping ping... >>>>> >>>>>> On Oct 20, 2014, at 13:22, Wang Weijun wrote: >>>>>> >>>>>> Anyone can take a look? >>>>>> >>>>>>> On Sep 25, 2014, at 18:54, Wang Weijun wrote: >>>>>>> >>>>>>> Hi All >>>>>>> >>>>>>> Please review the code change at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/8044500/webrev.00 >>>>>>> >>>>>>> It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r -l -R to kinit (on Windows). >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> From weijun.wang at oracle.com Tue Nov 18 07:47:00 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 18 Nov 2014 15:47:00 +0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> Message-ID: <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> Re-request for code review at http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ Most are still spec changes, with only one code change in KerberosTicket.java where KerberosPrincipal.toString() is changed to KerberosPrincipal.getName(). This is also because the spec for getName() is more suitable in this call. *Jamil*: I usually don't touch copyright years and let RE handle it. You might say this is not a good habit. Thanks Max > On Nov 15, 2014, at 08:05, Wang Weijun wrote: > > Webrev withdrawn. I'd like to make more changes. > > Thanks > Max > >> On Nov 14, 2014, at 10:38, Wang Weijun wrote: >> >> Hi All >> >> This is a doc change only bug. Fix at >> >> http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ >> >> Please take a review. >> >> Thanks >> Max >> > From jamil.j.nimeh at oracle.com Tue Nov 18 09:54:41 2014 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 18 Nov 2014 01:54:41 -0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> Message-ID: <546B1761.4070201@oracle.com> Hi Max, I only have very nit-picky comments/questions, actually the same question across 4 files. * KerberosKey.java o 298 and 305: Should the "KerberosKey" words be inside @code braces? * KerberosPrincipal.java o 195: Same @code question as above with "Principal" * KerberosTicket.java o 722 and 729: Same @code question for "KerberosTicket" * KeyTab.java o 341 and 347: ditto, but for "KeyTab" --Jamil On 11/17/2014 11:47 PM, Wang Weijun wrote: > Re-request for code review at > > http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ > > Most are still spec changes, with only one code change in KerberosTicket.java where KerberosPrincipal.toString() is changed to KerberosPrincipal.getName(). This is also because the spec for getName() is more suitable in this call. > > *Jamil*: I usually don't touch copyright years and let RE handle it. You might say this is not a good habit. > > Thanks > Max > >> On Nov 15, 2014, at 08:05, Wang Weijun wrote: >> >> Webrev withdrawn. I'd like to make more changes. >> >> Thanks >> Max >> >>> On Nov 14, 2014, at 10:38, Wang Weijun wrote: >>> >>> Hi All >>> >>> This is a doc change only bug. Fix at >>> >>> http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ >>> >>> Please take a review. >>> >>> Thanks >>> Max >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Nov 18 10:00:18 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 18 Nov 2014 18:00:18 +0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: <546B1761.4070201@oracle.com> References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> <546B1761.4070201@oracle.com> Message-ID: Since you asked, I'll fix them. I appreciate your pursuit of perfection. Thanks Max > On Nov 18, 2014, at 17:54, Jamil Nimeh wrote: > > Hi Max, I only have very nit-picky comments/questions, actually the same question across 4 files. > ? KerberosKey.java > ? 298 and 305: Should the "KerberosKey" words be inside @code braces? > ? KerberosPrincipal.java > ? 195: Same @code question as above with "Principal" > ? KerberosTicket.java > ? 722 and 729: Same @code question for "KerberosTicket" > ? KeyTab.java > ? 341 and 347: ditto, but for "KeyTab" > --Jamil > > On 11/17/2014 11:47 PM, Wang Weijun wrote: >> Re-request for code review at >> >> >> http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ >> >> >> Most are still spec changes, with only one code change in KerberosTicket.java where KerberosPrincipal.toString() is changed to KerberosPrincipal.getName(). This is also because the spec for getName() is more suitable in this call. >> >> *Jamil*: I usually don't touch copyright years and let RE handle it. You might say this is not a good habit. >> >> Thanks >> Max >> >> >>> On Nov 15, 2014, at 08:05, Wang Weijun >>> wrote: >>> >>> Webrev withdrawn. I'd like to make more changes. >>> >>> Thanks >>> Max >>> >>> >>>> On Nov 14, 2014, at 10:38, Wang Weijun >>>> wrote: >>>> >>>> Hi All >>>> >>>> This is a doc change only bug. Fix at >>>> >>>> >>>> http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ >>>> >>>> >>>> Please take a review. >>>> >>>> Thanks >>>> Max >>>> >>>> > From mark.reinhold at oracle.com Tue Nov 18 23:51:23 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 18 Nov 2014 15:51:23 -0800 (PST) Subject: JEP 229: Create PKCS12 Keystores by Default Message-ID: <20141118235123.DA9B94305D@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/229 - Mark From sean.mullan at oracle.com Wed Nov 19 14:10:13 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Nov 2014 09:10:13 -0500 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> Message-ID: <546CA4C5.80203@oracle.com> On 11/18/2014 02:47 AM, Wang Weijun wrote: > Re-request for code review at > > http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ * Principal: This should also be included in the @implSpec, is it? You might need another implSpec tag before this, or remove the

as it isn't really necessary.

Subclasses may override this with a different implementation, if necessary. * General Sometimes you say "the Foo" and other times you say "this Foo". I think you should try to be consistent. I prefer "this Foo". --Sean > > Most are still spec changes, with only one code change in > KerberosTicket.java where KerberosPrincipal.toString() is changed to > KerberosPrincipal.getName(). This is also because the spec for > getName() is more suitable in this call. > > *Jamil*: I usually don't touch copyright years and let RE handle it. > You might say this is not a good habit. > > Thanks Max > >> On Nov 15, 2014, at 08:05, Wang Weijun >> wrote: >> >> Webrev withdrawn. I'd like to make more changes. >> >> Thanks Max >> >>> On Nov 14, 2014, at 10:38, Wang Weijun >>> wrote: >>> >>> Hi All >>> >>> This is a doc change only bug. Fix at >>> >>> http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ >>> >>> Please take a review. >>> >>> Thanks Max >>> >> > From weijun.wang at oracle.com Wed Nov 19 14:27:27 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 19 Nov 2014 22:27:27 +0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: <546CA4C5.80203@oracle.com> References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> <546CA4C5.80203@oracle.com> Message-ID: > On Nov 19, 2014, at 22:10, Sean Mullan wrote: > > On 11/18/2014 02:47 AM, Wang Weijun wrote: >> Re-request for code review at >> >> http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ > > * Principal: > > This should also be included in the @implSpec, is it? You might need another implSpec tag before this, or remove the

as it isn't really necessary. > >

Subclasses may override this with a different implementation, if > necessary. Looks like one is enough. > > * General > > Sometimes you say "the Foo" and other times you say "this Foo". I think you should try to be consistent. I prefer "this Foo". OK, I'll go through it. Thanks Max > > --Sean > >> >> Most are still spec changes, with only one code change in >> KerberosTicket.java where KerberosPrincipal.toString() is changed to >> KerberosPrincipal.getName(). This is also because the spec for >> getName() is more suitable in this call. >> >> *Jamil*: I usually don't touch copyright years and let RE handle it. >> You might say this is not a good habit. >> >> Thanks Max >> >>> On Nov 15, 2014, at 08:05, Wang Weijun >>> wrote: >>> >>> Webrev withdrawn. I'd like to make more changes. >>> >>> Thanks Max >>> >>>> On Nov 14, 2014, at 10:38, Wang Weijun >>>> wrote: >>>> >>>> Hi All >>>> >>>> This is a doc change only bug. Fix at >>>> >>>> http://cr.openjdk.java.net/~weijun/8061253/webrev.00/ >>>> >>>> Please take a review. >>>> >>>> Thanks Max >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-19 at 22.25.34.png Type: image/png Size: 64840 bytes Desc: not available URL: From mark.reinhold at oracle.com Thu Nov 20 02:02:08 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 19 Nov 2014 18:02:08 -0800 (PST) Subject: JEP 232: Improve Secure Application Performance Message-ID: <20141120020208.6BCCE432B9@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/232 - Mark From jdk-security-dev at whittington.net.nz Thu Nov 20 22:37:53 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Fri, 21 Nov 2014 11:37:53 +1300 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <53F1F272.3030705@redhat.com> References: <53F1F272.3030705@redhat.com> Message-ID: On 19/08/2014, at 12:32 am, Florian Weimer wrote: > This change addresses a severe performance regression, first introduced in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS implementation. This regression is a result of the poor performance of the implementation of the GHASH function. > > I first tried to eliminate just the allocations in blockMult while still retaining the byte arrays. This did not substantially increase performance in my micro-benchmark. I then replaced the 16-byte arrays with longs, replaced the inner loops with direct bit fiddling on the longs, eliminated data-dependent conditionals (which are generally frowned upon in cryptographic algorithms due to the risk of timing attacks), and split the main loop in two, one for each half of the hash state. This is the result: > > > > Performance is roughly ten times faster. My test download over HTTPS is no longer CPU-bound, and GHASH hardly shows up in profiles anymore. (That's why I didn't consider further changes, lookup tables in particular.) Micro-benchmarking shows roughly a ten-fold increase in throughput, but this is probably underestimating it because of the high allocation rate of the old code. > Hi Florian It looks like your GHASH implementation as posted isn?t passing the tests in TestGHASH.java. The existing JDK implementation does, and the Bouncy Castle GHASH produces the same results. Can you reproduce that? cheers tim > The performance improvement on 32-bit architectures is probably a bit less, but I suspect that using four ints instead of two longs would penalize 64-bit architectures. > > -- > Florian Weimer / Red Hat Product Security From weijun.wang at oracle.com Mon Nov 24 08:59:56 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 24 Nov 2014 16:59:56 +0800 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> <546CA4C5.80203@oracle.com> Message-ID: >> On Nov 19, 2014, at 22:10, Sean Mullan wrote: >> >> On 11/18/2014 02:47 AM, Wang Weijun wrote: >>> Re-request for code review at >>> >>> http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ >> >> * Principal: >> >> This should also be included in the @implSpec, is it? You might need another implSpec tag before this, or remove the

as it isn't really necessary. >> > > Looks like one is enough. Is this OK? >> * General >> >> Sometimes you say "the Foo" and other times you say "this Foo". I think you should try to be consistent. I prefer "this Foo". > > OK, I'll go through it. I've s/the/this/ed in all hashCode() and toString(). If you don't have other comment, I'll push it. Thanks Max From sean.mullan at oracle.com Mon Nov 24 12:39:52 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Nov 2014 07:39:52 -0500 Subject: RFR 8061253: CCC 8043071 doesn't fully approve the change in JDK9b25 In-Reply-To: References: <87AD636A-6773-49A3-8B44-215C3E668F43@oracle.com> <2E487EA9-400F-4F00-9ABB-3360565285CC@oracle.com> <08183D12-9E96-43EC-9147-9034B0C6E989@oracle.com> <546CA4C5.80203@oracle.com> Message-ID: <54732718.5060507@oracle.com> On 11/24/2014 03:59 AM, Wang Weijun wrote: >>> On Nov 19, 2014, at 22:10, Sean Mullan wrote: >>> >>> On 11/18/2014 02:47 AM, Wang Weijun wrote: >>>> Re-request for code review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8061253/webrev.01/ >>> >>> * Principal: >>> >>> This should also be included in the @implSpec, is it? You might need another implSpec tag before this, or remove the

as it isn't really necessary. >>> >> >> Looks like one is enough. > > Is this OK? Yes. >>> * General >>> >>> Sometimes you say "the Foo" and other times you say "this Foo". I think you should try to be consistent. I prefer "this Foo". >> >> OK, I'll go through it. > > I've s/the/this/ed in all hashCode() and toString(). > > If you don't have other comment, I'll push it. Ok. --Sean From fweimer at redhat.com Mon Nov 24 15:11:10 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 24 Nov 2014 16:11:10 +0100 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: References: <53F1F272.3030705@redhat.com> Message-ID: <54734A8E.8050408@redhat.com> On 11/20/2014 11:37 PM, Tim Whittington wrote: > It looks like your GHASH implementation as posted isn?t passing the tests in TestGHASH.java. > The existing JDK implementation does, and the Bouncy Castle GHASH produces the same results. I can't reproduce this. I ported the patch to current JDK 9 (only path changes), and the test still passes for me. Could you share more details about your environment? -- Florian Weimer / Red Hat Product Security From weijun.wang at oracle.com Tue Nov 25 12:02:45 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Nov 2014 20:02:45 +0800 Subject: URLStreamHandler.getHostAddress() performance Message-ID: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> I am benchmarking security manager and notice this protected synchronized InetAddress getHostAddress(URL u) { if (u.hostAddress != null) return u.hostAddress; String host = u.getHost(); if (host == null || host.equals("")) { return null; } else { try { u.hostAddress = InetAddress.getByName(host); } catch (UnknownHostException ex) { return null; } catch (SecurityException se) { return null; } } return u.hostAddress; } Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? Thanks Max From tom.hawtin at oracle.com Tue Nov 25 12:55:31 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Tue, 25 Nov 2014 12:55:31 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> Message-ID: <54747C43.6060805@oracle.com> On 25/11/2014 12:02, Wang Weijun wrote: > I am benchmarking security manager and notice this > > protected synchronized InetAddress getHostAddress(URL u) { > [...] > > Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? Synchronizing on a public object is usually a bad idea. For instance Thread.join has had some interesting interactions with non-Java library code, and AFAIK that wasn't sprung in an update. If the address resolution is not pinned, then unsynchonised access could result in the hostAddress changing, which is bad. However, it seems the major useful effect is to stop a large number of parallel DNS lookups for the same address. Neither InetAddress nor DNSNameService does not appear to do that itself, though I've not looked deeply into the mechanism. So, I would suggest a lock/compare-and-set for just the write to the previously null URL.hostAddress, and locking based on the value of URL.getHost (don't synchronise on String (that'd be a little like synchronising on URL!)!). There's probably several places in the Java library doing something similar with Maps and Futures. Tom From weijun.wang at oracle.com Tue Nov 25 12:58:36 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Nov 2014 20:58:36 +0800 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> Message-ID: <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> > On Nov 25, 2014, at 20:25, Pavel Rappo wrote: > > Hi Max, > > I don't see any particular reason for this. Maybe it's just a "precaution". It seems to me it's the only field > of the URL class set directly (without setter) from an outside. > > Does it hurt performance a lot? In what cases? There is a 7x difference in my experiment on SecureClassLoader.defineClass(). Or, it can be shown using this benchmark: package org.openjdk.bench; import org.openjdk.jmh.annotations.*; import java.io.IOException; import java.net.URL; import java.util.*; import java.util.concurrent.ConcurrentHashMap; @State(Scope.Benchmark) public class Weird { final int num = 100; final Object[] urls = new Object[num]; public static class CS { private final Object url; public CS(Object url) { this.url = url; } public int hashCode() { return url.hashCode(); } public boolean equals(Object o) { return o instanceof CS && url.equals(((CS)o).url); } } private final Map pdcacheC = new ConcurrentHashMap<>(); @Setup public void init() throws Exception { for (int i=0; i< num; i++) { urls[i] = new URL("file:/tmp/"+i); } } @State(Scope.Thread) public static class ThreadState { final Random rand = new Random(); } @Benchmark public void setC(ThreadState state) throws IOException { Object cs = new CS(urls[next(state)]); pdcacheC.computeIfAbsent(cs, x -> ""); } private int next(ThreadState state) { return state.rand.nextInt(num); } } --Max > -Pavel > >> On 25 Nov 2014, at 12:02, Wang Weijun wrote: >> >> I am benchmarking security manager and notice this >> >> protected synchronized InetAddress getHostAddress(URL u) { >> if (u.hostAddress != null) >> return u.hostAddress; >> >> String host = u.getHost(); >> if (host == null || host.equals("")) { >> return null; >> } else { >> try { >> u.hostAddress = InetAddress.getByName(host); >> } catch (UnknownHostException ex) { >> return null; >> } catch (SecurityException se) { >> return null; >> } >> } >> return u.hostAddress; >> } >> >> Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? >> >> Thanks >> Max >> > From mark.sheppard at oracle.com Tue Nov 25 14:03:14 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 25 Nov 2014 14:03:14 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> Message-ID: <54748C22.9030109@oracle.com> I think this raises a more fundamental question, as to why the URL hashCode() and equals() methods delegates to URLStreamHandler in the first place? rather than performing the processing within the URL class itself, and synchronizing appropriately within. If you call equals() and hasCode() concurrently on the same URL instance, there exists the possibility (slight) that the hostAddress could be set differently, when it is being set for the first time, without the synchronization of the getHostAddress() in the URLStreamHandler. Although it may rarely happen the mechanics of InetAddress.getByName() potentially, lend itself to a different return address on multiple calls, as it returns the first address from a array of addresses retrieved - assumption is that the ordering will always be the same. regards Mark On 25/11/2014 12:58, Wang Weijun wrote: >> On Nov 25, 2014, at 20:25, Pavel Rappo wrote: >> >> Hi Max, >> >> I don't see any particular reason for this. Maybe it's just a "precaution". It seems to me it's the only field >> of the URL class set directly (without setter) from an outside. >> >> Does it hurt performance a lot? In what cases? > There is a 7x difference in my experiment on SecureClassLoader.defineClass(). > > Or, it can be shown using this benchmark: > > package org.openjdk.bench; > > import org.openjdk.jmh.annotations.*; > > import java.io.IOException; > import java.net.URL; > import java.util.*; > import java.util.concurrent.ConcurrentHashMap; > > @State(Scope.Benchmark) > public class Weird { > final int num = 100; > final Object[] urls = new Object[num]; > > public static class CS { > private final Object url; > public CS(Object url) { this.url = url; } > public int hashCode() { return url.hashCode(); } > public boolean equals(Object o) { return o instanceof CS && url.equals(((CS)o).url); } > } > > private final Map pdcacheC = new ConcurrentHashMap<>(); > > @Setup > public void init() throws Exception { > for (int i=0; i< num; i++) { > urls[i] = new URL("file:/tmp/"+i); > } > } > > @State(Scope.Thread) > public static class ThreadState { > final Random rand = new Random(); > } > > > @Benchmark > public void setC(ThreadState state) throws IOException { > Object cs = new CS(urls[next(state)]); > pdcacheC.computeIfAbsent(cs, x -> ""); > } > > private int next(ThreadState state) { > return state.rand.nextInt(num); > } > } > > --Max > > >> -Pavel >> >>> On 25 Nov 2014, at 12:02, Wang Weijun wrote: >>> >>> I am benchmarking security manager and notice this >>> >>> protected synchronized InetAddress getHostAddress(URL u) { >>> if (u.hostAddress != null) >>> return u.hostAddress; >>> >>> String host = u.getHost(); >>> if (host == null || host.equals("")) { >>> return null; >>> } else { >>> try { >>> u.hostAddress = InetAddress.getByName(host); >>> } catch (UnknownHostException ex) { >>> return null; >>> } catch (SecurityException se) { >>> return null; >>> } >>> } >>> return u.hostAddress; >>> } >>> >>> Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? >>> >>> Thanks >>> Max >>> From weijun.wang at oracle.com Tue Nov 25 14:13:10 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 25 Nov 2014 22:13:10 +0800 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <54747C43.6060805@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <54747C43.6060805@oracle.com> Message-ID: <082E0D8F-C6AA-4AE6-B376-8604B7EED70F@oracle.com> > On Nov 25, 2014, at 20:55, Tom Hawtin wrote: > > > > On 25/11/2014 12:02, Wang Weijun wrote: >> I am benchmarking security manager and notice this >> >> protected synchronized InetAddress getHostAddress(URL u) { >> [...] >> >> Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? > > Synchronizing on a public object is usually a bad idea. For instance Thread.join has had some interesting interactions with non-Java library code, and AFAIK that wasn't sprung in an update. > > If the address resolution is not pinned, then unsynchonised access could result in the hostAddress changing, which is bad. However, it seems the major useful effect is to stop a large number of parallel DNS lookups for the same address. This sounds reasonable. Otherwise I cannot imagine why the calculation needs be taken out of URL class. > Neither InetAddress nor DNSNameService does not appear to do that itself, though I've not looked deeply into the mechanism. > > So, I would suggest a lock/compare-and-set for just the write to the previously null URL.hostAddress, and locking based on the value of URL.getHost (don't synchronise on String (that'd be a little like synchronising on URL!)!). There's probably several places in the Java library doing something similar with Maps and Futures. Shall we encapsulate all of these in a new java.net.Host class? --Max > > Tom From ecki at zusammenkunft.net Tue Nov 25 16:34:35 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 25 Nov 2014 17:34:35 +0100 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <082E0D8F-C6AA-4AE6-B376-8604B7EED70F@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <54747C43.6060805@oracle.com> <082E0D8F-C6AA-4AE6-B376-8604B7EED70F@oracle.com> Message-ID: <20141125173435.00001639.ecki@zusammenkunft.net> Hello, well first of all, why is it doing a lookup at all? It the URL was specified with a hostname I guess that one is used. If the InetAddress object in the URL had no hostname, you probably do not want to reverse resolve one for Security Manager purpose. However, back to the synchronized: I dont think this is needed, InetAddress does synchronisation itself (InetAddress.getAddressFromNameService() is used inside synchronized(cacheLock)). Gruss Bernd Am Tue, 25 Nov 2014 22:13:10 +0800 schrieb Wang Weijun : > > > On Nov 25, 2014, at 20:55, Tom Hawtin wrote: > > > > > > > > On 25/11/2014 12:02, Wang Weijun wrote: > >> I am benchmarking security manager and notice this > >> > >> protected synchronized InetAddress getHostAddress(URL u) { > >> [...] > >> > >> Is there any reason why the method is synchronized? Why not simply > >> "synchronized (u)"? > > > > Synchronizing on a public object is usually a bad idea. For > > instance Thread.join has had some interesting interactions with > > non-Java library code, and AFAIK that wasn't sprung in an update. > > > > If the address resolution is not pinned, then unsynchonised access > > could result in the hostAddress changing, which is bad. However, it > > seems the major useful effect is to stop a large number of parallel > > DNS lookups for the same address. > > This sounds reasonable. Otherwise I cannot imagine why the > calculation needs be taken out of URL class. > > > Neither InetAddress nor DNSNameService does not appear to do that > > itself, though I've not looked deeply into the mechanism. > > > > So, I would suggest a lock/compare-and-set for just the write to > > the previously null URL.hostAddress, and locking based on the value > > of URL.getHost (don't synchronise on String (that'd be a little > > like synchronising on URL!)!). There's probably several places in > > the Java library doing something similar with Maps and Futures. > > Shall we encapsulate all of these in a new java.net.Host class? > > --Max > > > > > Tom > From tom.hawtin at oracle.com Tue Nov 25 17:42:52 2014 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Tue, 25 Nov 2014 17:42:52 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <082E0D8F-C6AA-4AE6-B376-8604B7EED70F@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <54747C43.6060805@oracle.com> <082E0D8F-C6AA-4AE6-B376-8604B7EED70F@oracle.com> Message-ID: <5474BF9C.7050808@oracle.com> On 25/11/2014 14:13, Wang Weijun wrote: >> So, I would suggest a lock/compare-and-set for just the write to the previously null URL.hostAddress, and locking based on the value of URL.getHost (don't synchronise on String (that'd be a little like synchronising on URL!)!). There's probably several places in the Java library doing something similar with Maps and Futures. > > Shall we encapsulate all of these in a new java.net.Host class? I meant the general algorithm for locking based on a value. Though a quick look through the JDK source doesn't turn up much. Looking at it a bit further, it may make sense to push the logic to avoid parallel identical DNS lookups down to at least InetAddress.getAllByName0. A "value-based" lock around the call to getAddressesFromNameService but not getCachedAddresses. This way, large numbers of identical, already-cached lookups could have minimal interference with each other. The Cache implementation is a bit old school, though probably sufficient. If you have large numbers of simultaneous lookups, I guess they're probably all of the same thing. Many class files loaded from the same host, for example. So switching from an effectively global lock to a lock based on hostname value is unlikely to help performance. Tom From otaviojava at java.net Tue Nov 18 08:58:59 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 18 Nov 2014 06:58:59 -0200 Subject: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters Message-ID: BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055723 WEBREV: http://cr.openjdk.java.net/~weijun/8055723/webrev.01/ -- Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Tue Nov 25 12:25:52 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 25 Nov 2014 12:25:52 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> Message-ID: <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> Hi Max, I don't see any particular reason for this. Maybe it's just a "precaution". It seems to me it's the only field of the URL class set directly (without setter) from an outside. Does it hurt performance a lot? In what cases? -Pavel > On 25 Nov 2014, at 12:02, Wang Weijun wrote: > > I am benchmarking security manager and notice this > > protected synchronized InetAddress getHostAddress(URL u) { > if (u.hostAddress != null) > return u.hostAddress; > > String host = u.getHost(); > if (host == null || host.equals("")) { > return null; > } else { > try { > u.hostAddress = InetAddress.getByName(host); > } catch (UnknownHostException ex) { > return null; > } catch (SecurityException se) { > return null; > } > } > return u.hostAddress; > } > > Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? > > Thanks > Max > From pavel.rappo at oracle.com Tue Nov 25 13:51:09 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 25 Nov 2014 13:51:09 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> Message-ID: <4937D40B-55BA-49B1-BA01-3AC0DC37F751@oracle.com> Max, this change dates back to 99/06/11. And there's not much info left on it. I suggest changing and running the full test suit. P.S. I assume the whole synchronization burden in the URL comes from lazy initialization of hostAddress and lazy computation of the hashCode (...and access to shared handlers, but that's guarded by different lock and thus of no interest to us right now). Without the 'hostAddress' the whole object could've been immutable (given the handler code is ALWAYS executed in the same thread as constructor, which is hard natural and it's hard to imagine the opposite). -Pavel > On 25 Nov 2014, at 12:58, Wang Weijun wrote: > > >> On Nov 25, 2014, at 20:25, Pavel Rappo wrote: >> >> Hi Max, >> >> I don't see any particular reason for this. Maybe it's just a "precaution". It seems to me it's the only field >> of the URL class set directly (without setter) from an outside. >> >> Does it hurt performance a lot? In what cases? > > There is a 7x difference in my experiment on SecureClassLoader.defineClass(). > > Or, it can be shown using this benchmark: > > package org.openjdk.bench; > > import org.openjdk.jmh.annotations.*; > > import java.io.IOException; > import java.net.URL; > import java.util.*; > import java.util.concurrent.ConcurrentHashMap; > > @State(Scope.Benchmark) > public class Weird { > final int num = 100; > final Object[] urls = new Object[num]; > > public static class CS { > private final Object url; > public CS(Object url) { this.url = url; } > public int hashCode() { return url.hashCode(); } > public boolean equals(Object o) { return o instanceof CS && url.equals(((CS)o).url); } > } > > private final Map pdcacheC = new ConcurrentHashMap<>(); > > @Setup > public void init() throws Exception { > for (int i=0; i< num; i++) { > urls[i] = new URL("file:/tmp/"+i); > } > } > > @State(Scope.Thread) > public static class ThreadState { > final Random rand = new Random(); > } > > > @Benchmark > public void setC(ThreadState state) throws IOException { > Object cs = new CS(urls[next(state)]); > pdcacheC.computeIfAbsent(cs, x -> ""); > } > > private int next(ThreadState state) { > return state.rand.nextInt(num); > } > } > > --Max > > >> -Pavel >> >>> On 25 Nov 2014, at 12:02, Wang Weijun wrote: >>> >>> I am benchmarking security manager and notice this >>> >>> protected synchronized InetAddress getHostAddress(URL u) { >>> if (u.hostAddress != null) >>> return u.hostAddress; >>> >>> String host = u.getHost(); >>> if (host == null || host.equals("")) { >>> return null; >>> } else { >>> try { >>> u.hostAddress = InetAddress.getByName(host); >>> } catch (UnknownHostException ex) { >>> return null; >>> } catch (SecurityException se) { >>> return null; >>> } >>> } >>> return u.hostAddress; >>> } >>> >>> Is there any reason why the method is synchronized? Why not simply "synchronized (u)"? >>> >>> Thanks >>> Max >>> >> > From peter.levart at gmail.com Thu Nov 27 20:17:32 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 27 Nov 2014 21:17:32 +0100 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <54748C22.9030109@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> <54748C22.9030109@oracle.com> Message-ID: <547786DC.5030703@gmail.com> Hi, Some time ago I dived into the sinchronization pitfalls of URL / URLStreamHandler and came up with a possible solution. Here's the thread (mostly just my comments) and a patch: http://mail.openjdk.java.net/pipermail/net-dev/2014-July/008592.html Regards, Peter On 11/25/2014 03:03 PM, Mark Sheppard wrote: > I think this raises a more fundamental question, as to why the URL > hashCode() and equals() methods delegates to URLStreamHandler > in the first place? rather than performing the processing within the > URL class itself, and synchronizing appropriately within. > > If you call equals() and hasCode() concurrently on the same URL > instance, there exists the possibility (slight) that > the hostAddress could be set differently, when it is being set for the > first time, without the synchronization of the getHostAddress() in the > URLStreamHandler. > > Although it may rarely happen the mechanics of InetAddress.getByName() > potentially, lend itself to a different return address > on multiple calls, as it returns the first address from a array of > addresses retrieved - assumption is that the ordering will always be > the same. > > regards > Mark > > On 25/11/2014 12:58, Wang Weijun wrote: >>> On Nov 25, 2014, at 20:25, Pavel Rappo wrote: >>> >>> Hi Max, >>> >>> I don't see any particular reason for this. Maybe it's just a >>> "precaution". It seems to me it's the only field >>> of the URL class set directly (without setter) from an outside. >>> >>> Does it hurt performance a lot? In what cases? >> There is a 7x difference in my experiment on >> SecureClassLoader.defineClass(). >> >> Or, it can be shown using this benchmark: >> >> package org.openjdk.bench; >> >> import org.openjdk.jmh.annotations.*; >> >> import java.io.IOException; >> import java.net.URL; >> import java.util.*; >> import java.util.concurrent.ConcurrentHashMap; >> >> @State(Scope.Benchmark) >> public class Weird { >> final int num = 100; >> final Object[] urls = new Object[num]; >> >> public static class CS { >> private final Object url; >> public CS(Object url) { this.url = url; } >> public int hashCode() { return url.hashCode(); } >> public boolean equals(Object o) { return o instanceof CS && >> url.equals(((CS)o).url); } >> } >> >> private final Map pdcacheC = new >> ConcurrentHashMap<>(); >> >> @Setup >> public void init() throws Exception { >> for (int i=0; i< num; i++) { >> urls[i] = new URL("file:/tmp/"+i); >> } >> } >> >> @State(Scope.Thread) >> public static class ThreadState { >> final Random rand = new Random(); >> } >> >> >> @Benchmark >> public void setC(ThreadState state) throws IOException { >> Object cs = new CS(urls[next(state)]); >> pdcacheC.computeIfAbsent(cs, x -> ""); >> } >> >> private int next(ThreadState state) { >> return state.rand.nextInt(num); >> } >> } >> >> --Max >> >> >>> -Pavel >>> >>>> On 25 Nov 2014, at 12:02, Wang Weijun wrote: >>>> >>>> I am benchmarking security manager and notice this >>>> >>>> protected synchronized InetAddress getHostAddress(URL u) { >>>> if (u.hostAddress != null) >>>> return u.hostAddress; >>>> >>>> String host = u.getHost(); >>>> if (host == null || host.equals("")) { >>>> return null; >>>> } else { >>>> try { >>>> u.hostAddress = InetAddress.getByName(host); >>>> } catch (UnknownHostException ex) { >>>> return null; >>>> } catch (SecurityException se) { >>>> return null; >>>> } >>>> } >>>> return u.hostAddress; >>>> } >>>> >>>> Is there any reason why the method is synchronized? Why not simply >>>> "synchronized (u)"? >>>> >>>> Thanks >>>> Max >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdk-security-dev at whittington.net.nz Fri Nov 28 08:29:45 2014 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Fri, 28 Nov 2014 21:29:45 +1300 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <53F1F272.3030705@redhat.com> References: <53F1F272.3030705@redhat.com> Message-ID: Hi Florian On 19/08/2014, at 12:32 am, Florian Weimer wrote: > This change addresses a severe performance regression, first introduced in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS implementation. This regression is a result of the poor performance of the implementation of the GHASH function. > > I first tried to eliminate just the allocations in blockMult while still retaining the byte arrays. This did not substantially increase performance in my micro-benchmark. I then replaced the 16-byte arrays with longs, replaced the inner loops with direct bit fiddling on the longs, eliminated data-dependent conditionals (which are generally frowned upon in cryptographic algorithms due to the risk of timing attacks), and split the main loop in two, one for each half of the hash state. This is the result: > > > > Performance is roughly ten times faster. My test download over HTTPS is no longer CPU-bound, and GHASH hardly shows up in profiles anymore. (That's why I didn't consider further changes, lookup tables in particular.) Micro-benchmarking shows roughly a ten-fold increase in throughput, but this is probably underestimating it because of the high allocation rate of the old code. I can reproduce these results using the Bouncy Castle GCM implementation and your multiplication strategy. Compared to a baseline for AES/GCM of 7.33 MB/s (Bouncy Castle basic multiplier) and 3.32 MB/s (Oracle JCE) using 1.8.0_25 with your 2x64 bit multiplier strategy I get 37.4 MB/s. This is a 4x improvement over the basic BC implementation and a 10x improvement over the Oracle 1.8 JCE version. For comparison, the BC table based implementations (not constant time) can be pushed to 68 MB/s (8x and 19x faster than the ref speeds). These results are consistent for 1.8, 1.7, 1.6 and 1.6 -d32 on the same OS/hardware (Mac OS X, Haswell MBP). Interestingly the constant time conditional masking outperforms the equivalent (non constant time) branching code slightly on 1.8/1.7 JVMs, so I don?t see any penalty whatsoever for the constant time (at least not on this architecture - it looks like the extra ops are less important than the branches being avoided?). > > The performance improvement on 32-bit architectures is probably a bit less, but I suspect that using four ints instead of two longs would penalize 64-bit architectures. > With the 2x64 adapted to a 4x32 bit multiplier I get about 24 MB/s on all architectures (about a 35% penalty). Interestingly this is consistent in 1.6 -d32. cheers tim > -- > Florian Weimer / Red Hat Product Security From pavel.rappo at oracle.com Thu Nov 27 21:42:53 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 27 Nov 2014 21:42:53 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <54748C22.9030109@oracle.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> <54748C22.9030109@oracle.com> Message-ID: > On 25 Nov 2014, at 14:03, Mark Sheppard wrote: > > I think this raises a more fundamental question, as to why the URL hashCode() and equals() methods delegates to URLStreamHandler > in the first place? rather than performing the processing within the URL class itself, and synchronizing appropriately within. Mark, I guess it's a part of initial design. Handlers know how to parse each individual URL (URLStreamHandler::parseURL), they know how to split URL into meaningful components. They know what these components mean. Therefore they were probably chosen as the best place calculate hash code and perform equality test. But that's in theory. In practise we have a purely-defined URL::equals and URL::hashCode > If you call equals() and hasCode() concurrently on the same URL instance, there exists the possibility (slight) that > the hostAddress could be set differently, when it is being set for the first time, without the synchronization of the getHostAddress() in the URLStreamHandler. > > Although it may rarely happen the mechanics of InetAddress.getByName() potentially, lend itself to a different return address > on multiple calls, as it returns the first address from a array of addresses retrieved - assumption is that the ordering will always be the same. > > regards > Mark Agreed. Correct me if I'm wrong, I believe InetAddress::getByName is inherently inconsistent since a naming service is involved. From pavel.rappo at oracle.com Thu Nov 27 22:11:42 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 27 Nov 2014 22:11:42 +0000 Subject: URLStreamHandler.getHostAddress() performance In-Reply-To: <547786DC.5030703@gmail.com> References: <38DE63AE-4280-4533-B5A9-FD8A2C6DBA23@oracle.com> <85889D9C-0B2B-489D-B1D2-A45096D83722@oracle.com> <1D42963F-C827-431C-89F0-C3848A7474B2@oracle.com> <54748C22.9030109@oracle.com> <547786DC.5030703@gmail.com> Message-ID: <86E78B95-F573-4FE9-AB10-60F36F362281@oracle.com> Peter, thanks a lot for the link and such a detailed explanation. I've been working with URL/URLStreamHandler recently to make them "modularization ready" and have noticed some of the problems you were talking about as well. I do think we should make our best effort to fix it. Give me some time and I'll get back to this. Thanks. -Pavel > On 27 Nov 2014, at 20:17, Peter Levart wrote: > > Hi, > > Some time ago I dived into the sinchronization pitfalls of URL / URLStreamHandler and came up with a possible solution. Here's the thread (mostly just my comments) and a patch: > > http://mail.openjdk.java.net/pipermail/net-dev/2014-July/008592.html > > Regards, Peter