From weijun.wang at oracle.com Thu Oct 1 09:10:47 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 1 Oct 2015 17:10:47 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: References: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com> Message-ID: > ? 2015?10?1????7:53?Steve Drach ??? > > - JDK 8 jar signer does not work with a JDK 9 created keystore > - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore > - JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore The default keystore type in jdk9 is pkcs12. I guess this is why jarsigner in jdk8 does not recognize it. As for the size, I guess the default signature algorithm or key size might not be the same, say, SHA1withRSA -> SHA256withRSA or 1024 to 2048. --Max From jamil.j.nimeh at oracle.com Thu Oct 1 16:02:41 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 01 Oct 2015 09:02:41 -0700 Subject: RFR 8138704: CertStatusReqItemV2 should not implement StatusRequest interface Message-ID: <560D5921.3010301@oracle.com> Hello all, While looking at CertStatusReqItemV2, I came across a left-over from early prototyping. The class currently implements StatusRequest, but it really shouldn't. It never caused a problem because StatusRequest requires the implementation of length and send methods, and that class needed those methods anyway. So this webrev is for the removal of that implements directive and reduces the visibility of those two methods to package-private. JBS: https://bugs.openjdk.java.net/browse/JDK-8138704 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8138704/webrev.01/ Thanks, --Jamil From bradford.wetmore at oracle.com Fri Oct 2 01:03:58 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 1 Oct 2015 18:03:58 -0700 Subject: TLS ALPN Proposal v6 In-Reply-To: <560AA924.1050706@redhat.com> References: <55ED0A6A.3050806@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> Message-ID: <560DD7FE.2060806@oracle.com> You guys (David/Simone/Bernd/Jason) are more on the front lines in server development and how functional this API will be, so I'll trust your judgement here. If you are ok with: 1. potentially being blind during renegotiations in the existing TLSv1/v1.1/v1.2, and, 2. not having an SSLExplorer as part of the JDK (i.e. you parsing the ClientHellos ala SSLExplorer), 3. requiring all ALPN logic be in the application and none in the JDK, I'm willing to go with this approach. It doesn't seem optimal for what I would call casual users, but it does solve the ugly issues with the matches() API. (BTW, I did consider adding a ClientHelloCallback/ClientHello/ServerHelloCallback/ServerHello class that would handle callbacks, but that was getting complicated also.) For current renegotiations, the big use case is adding client authentication, so it seems likely that the same ciphersuite will be offered/chosen, so it's likely moot. For the existing URL code, do you think we need: 1. to provide a "https.alpn" System Property for the existing URLConnections? 2. a getApplicationProtocol() for HttpsURLConnection? Michael (net-dev) says H2 will not be backported into the URL mechanism and doesn't see a need for it yet, so I'm inclined to say no. More inline: On 9/29/2015 8:07 AM, David M. Lloyd wrote: > Hi Brad, thanks for replying; comments are inline: > On 09/28/2015 08:40 PM, Bradford Wetmore wrote: >> 1. Only the initial ClientHellos are parsable. >> =============================================== >> The biggest problem I have with an Explorer-based design is that only >> the initial ClientHello on a connection is passed in the clear. >> Subsequent negotiations on this connection will be completely missed, as >> the ClientHellos are now encrypted. >> >> This seems like a deal breaker for me. > > You are right, I cannot come up with a good solution for this, so that > might mean the idea is shot - *however* - I would point out that the > latest draft of TLS 1.3 [1] completely kills off the capability of the > client to renegotiate a connection, meaning that this will no longer be > possible anyway, and given it's a 1% kind of use case, that might be > enough to let it slide. Combine this with what I consider to be the > unlikelihood of this working with HTTP/2.0, and I would feel very safe > assuming that nobody will ever actually do this. Thanks for pointing this out, I thought PSK+tickets were a replacement for a renegotiation (Section 6.2.3), but it's apparently only for session resumption. BTW, the WG is up to a Sept 29, 2015 version (draft-09). [1] https://tlswg.github.io/tls13-spec/ > I would also note that, as you state later on, it would be possible to > combine this solution with any other solution (including the proposed > one) to cover both cases. And given that this is still (in my > estimation) a "99%" solution, in my opinion it is still a viable > candidate for adding this functionality to Java 8 as a first pass or > stopgap as I described in my emails, particularly if the method(s) to > establish/query the protocol names are a strict subset of the proposed > Java 9 API (given that we cannot really overhaul the Java SE 8 API at > this point). > >> [...] >> 2. "SSLExplorer" or something similar is needed. >> ================================================= >> This approach depends on "examining SSLClientHello"s, but there isn't a >> class for this other than some sample code from a previous attempt. I >> am assuming that this approach would make such an external API a >> necessity? Being able to parse possible ClientHello formats is not a >> straightforward/easy job. This will add a fair amount of complexity, >> and likely not an easy job in the remaining few weeks. It could be >> added later for JDK 10 but that means apps would likely need to roll >> their own for 9. > > And 8, yes, you definitely would need to roll your own, though Xuelei > Fan already has a nice example up on his blog that was built for SNI > (but uses the same principle). If you are referring to: http://simsmi.blogspot.com/2014/01/jep-114-tls-sni-extension-virtual.html This is just describing the general approach for the sample SSLExplorer/SSLCapabilities code in the JSSE Reference Guide. The actual code can be found here: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#CodeExamples My hope is to expand it to include parsing the ciphersuites and ALPN extensions. I've moved/added some helper functions from ApplicationProtocol to StandardConstants. > If it were me, I wouldn't even bother > adding it even in JDK 10, since (a) it applies only to the server side > and (b) there are a plethora of third-party server-side network I/O and > security libraries which are natural candidates to host this type of logic. Ok. >> 3. "no_application_protocol" >> ============================= >> If the server doesn't support the protocols that the client advertises, >> the "no_application_protocol" must be thrown. We could add a >> "no_application_protocol" protocol String that would flag such a >> condition internally. > > Sure, though if you use the same method on both the client and server to > specify the matched protocol, then the method necessarily accepts an > array, in which case a null/unset could mean "no ALPN response" and an > empty array could mean "no acceptable protocols". But yeah I agree > otherwise. I meant if this value is set, then when the ALPN extensions are selected, it will send the alert to the peer and return an Exception to the local code. The latest webrev is at: http://cr.openjdk.java.net/~wetmore/8051498/webrev.16 This will be the final version as far as major architectural design goes, but minor things like parameter types/wording can still be tweaked. Major changes: 1. ApplicationProtocols is gone. The H2 black list and comparator were moved to StandardConstants. 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And now that you are parsing the raw network bytes, I added a convenience mapping between the two byte ciphersuite IANA-assigned value and the Java Standard Name. 3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even though these could go into SSLParameters, this change makes backporting much easier. The helper code simply has to reflectively look for the four methods in the implementation classes, and call if they are there. Otherwise, there would have to be reflection both in the user code (above) and implementation (to see if the passed SSLParameters had the new methods via a subclass). Thanks, Brad From xuelei.fan at oracle.com Fri Oct 2 02:35:50 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 2 Oct 2015 10:35:50 +0800 Subject: TLS ALPN Proposal v6 In-Reply-To: <560DD7FE.2060806@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> Message-ID: <560DED86.5070702@oracle.com> On 10/2/2015 9:03 AM, Bradford Wetmore wrote: > Major changes: > > 1. ApplicationProtocols is gone. The H2 black list and comparator were > moved to StandardConstants. > > 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And > now that you are parsing the raw network bytes, I added a convenience > mapping between the two byte ciphersuite IANA-assigned value and the > Java Standard Name. > There is no SSLExplorer in OpenJDK. I think, maybe, the map is not belong to OpenJDK either. I think, the constants for HTTP2 is also belong to application protocol (HTTP2) layer. Application (HTTP2) implementation would take care of them. Maybe, they are not a part of JSSE framework either. I would like to have "h2" and "http/1.1" defined as Standard Algorithms Docs as we usually did for other standard constants. > 3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even > though these could go into SSLParameters, this change makes backporting > much easier. The helper code simply has to reflectively look for the > four methods in the implementation classes, and call if they are there. > > Otherwise, there would have to be reflection both in the user code > (above) and implementation (to see if the passed SSLParameters had the > new methods via a subclass). But, looking forward, per JSSE framework, SSLParameters should be the central place to define SSL/TLS configuration parameters. We'd better follow the conventions so that application developers won't get confused about where SSL/TLS parameters should be configured. Maybe, we cannot add public APIs for backporting. I think backporting is another history, and would better not impact too much of the design for JDK 9 and future releases. Hope it helps! Xuelei From sean.mullan at oracle.com Fri Oct 2 13:41:36 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 2 Oct 2015 09:41:36 -0400 Subject: RFR 8138704: CertStatusReqItemV2 should not implement StatusRequest interface In-Reply-To: <560D5921.3010301@oracle.com> References: <560D5921.3010301@oracle.com> Message-ID: <560E8990.3060503@oracle.com> Looks fine to me. --Sean On 10/1/15 12:02 PM, Jamil Nimeh wrote: > Hello all, > > While looking at CertStatusReqItemV2, I came across a left-over from > early prototyping. The class currently implements StatusRequest, but it > really shouldn't. It never caused a problem because StatusRequest > requires the implementation of length and send methods, and that class > needed those methods anyway. > > So this webrev is for the removal of that implements directive and > reduces the visibility of those two methods to package-private. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8138704 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8138704/webrev.01/ > > Thanks, > --Jamil From anthony.scarpino at oracle.com Fri Oct 2 17:08:26 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 2 Oct 2015 10:08:26 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE Message-ID: <560EBA0A.7040808@oracle.com> Hi all, I'm need a review of the last developement piece to JEP 246, the configuration changes. I've copied the build-dev in case there were any comments on the minor changes in the make directory related to the java.security file. http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ thanks Tony From bradford.wetmore at oracle.com Sat Oct 3 00:19:00 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 2 Oct 2015 17:19:00 -0700 Subject: TLS ALPN Proposal v7 In-Reply-To: <560DED86.5070702@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> <560DED86.5070702@oracle.com> Message-ID: <560F1EF4.4060405@oracle.com> On 10/1/2015 7:35 PM, Xuelei Fan wrote: > On 10/2/2015 9:03 AM, Bradford Wetmore wrote: >> Major changes: >> >> 1. ApplicationProtocols is gone. The H2 black list and comparator were >> moved to StandardConstants. >> >> 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And >> now that you are parsing the raw network bytes, I added a convenience >> mapping between the two byte ciphersuite IANA-assigned value and the >> Java Standard Name. >> > There is no SSLExplorer in OpenJDK. I think, maybe, the map is not > belong to OpenJDK either. > > I think, the constants for HTTP2 is also belong to application protocol > (HTTP2) layer. Application (HTTP2) implementation would take care of > them. Maybe, they are not a part of JSSE framework either. Ok, I've removed all of the H2 constants from StandardConstants. I've mentioned to the the H2/network team that this is something they will need to handle/include (e.g. Blacklist/Comparator) in their code, and they might want to consider APIs similar to what I had. I personally found it very useful to have a proper mapping to get the SSL_ vs. TLS_ prefix correct in the blacklist. > I would like to have "h2" and "http/1.1" defined as Standard Algorithms > Docs as we usually did for other standard constants. Of course, they will be added as Standard Algorithm names. >> 3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even >> though these could go into SSLParameters, this change makes backporting >> much easier. The helper code simply has to reflectively look for the >> four methods in the implementation classes, and call if they are there. >> >> Otherwise, there would have to be reflection both in the user code >> (above) and implementation (to see if the passed SSLParameters had the >> new methods via a subclass). > But, looking forward, per JSSE framework, SSLParameters should be the > central place to define SSL/TLS configuration parameters. We'd better > follow the conventions so that application developers won't get confused > about where SSL/TLS parameters should be configured. I went back and forth on this many, many times yesterday. > Maybe, we cannot add public APIs for backporting. I figured we'd have to use reflection on user-derived classes to see if the methods were there, but apparently implementation-specifc APIs can be added in an update release, just not Java APIs. So if we really can do that, then we can add a jdk.SSLParameters/ org.openjdk.jsse.SSLParameters extends SSLParameters, and in the implementation, look for instanceof. > I think backporting is > another history, and would better not impact too much of the design for > JDK 9 and future releases. Ok, so get/setApplicationProtocols() is back in SSLParameters. Thanks for the comments everyone. I'm submitting the following to the CCC (internal review board): http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/ Changes: 1. No H2 Blacklist/Comparator 2. set/getApplicationProtocols() back to SSLParameters. Thanks, Brad From xuelei.fan at oracle.com Sat Oct 3 00:48:46 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 3 Oct 2015 08:48:46 +0800 Subject: TLS ALPN Proposal v7 In-Reply-To: <560F1EF4.4060405@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> <560DED86.5070702@oracle.com> <560F1EF4.4060405@oracle.com> Message-ID: <560F25EE.9080005@oracle.com> Thanks! Xuelei On 10/3/2015 8:19 AM, Bradford Wetmore wrote: > > > On 10/1/2015 7:35 PM, Xuelei Fan wrote: >> On 10/2/2015 9:03 AM, Bradford Wetmore wrote: >>> Major changes: >>> >>> 1. ApplicationProtocols is gone. The H2 black list and comparator were >>> moved to StandardConstants. >>> >>> 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And >>> now that you are parsing the raw network bytes, I added a convenience >>> mapping between the two byte ciphersuite IANA-assigned value and the >>> Java Standard Name. >>> >> There is no SSLExplorer in OpenJDK. I think, maybe, the map is not >> belong to OpenJDK either. >> >> I think, the constants for HTTP2 is also belong to application protocol >> (HTTP2) layer. Application (HTTP2) implementation would take care of >> them. Maybe, they are not a part of JSSE framework either. > > Ok, I've removed all of the H2 constants from StandardConstants. I've > mentioned to the the H2/network team that this is something they will > need to handle/include (e.g. Blacklist/Comparator) in their code, and > they might want to consider APIs similar to what I had. > > I personally found it very useful to have a proper mapping to get the > SSL_ vs. TLS_ prefix correct in the blacklist. > >> I would like to have "h2" and "http/1.1" defined as Standard Algorithms >> Docs as we usually did for other standard constants. > > Of course, they will be added as Standard Algorithm names. > >>> 3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even >>> though these could go into SSLParameters, this change makes backporting >>> much easier. The helper code simply has to reflectively look for the >>> four methods in the implementation classes, and call if they are there. >>> >>> Otherwise, there would have to be reflection both in the user code >>> (above) and implementation (to see if the passed SSLParameters had the >>> new methods via a subclass). >> But, looking forward, per JSSE framework, SSLParameters should be the >> central place to define SSL/TLS configuration parameters. We'd better >> follow the conventions so that application developers won't get confused >> about where SSL/TLS parameters should be configured. > > I went back and forth on this many, many times yesterday. > >> Maybe, we cannot add public APIs for backporting. > > I figured we'd have to use reflection on user-derived classes to see if > the methods were there, but apparently implementation-specifc APIs can > be added in an update release, just not Java APIs. So if we really can > do that, then we can add a jdk.SSLParameters/ > org.openjdk.jsse.SSLParameters extends SSLParameters, and in the > implementation, look for instanceof. > >> I think backporting is >> another history, and would better not impact too much of the design for >> JDK 9 and future releases. > > Ok, so get/setApplicationProtocols() is back in SSLParameters. > > Thanks for the comments everyone. I'm submitting the following to the > CCC (internal review board): > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/ > > Changes: > > 1. No H2 Blacklist/Comparator > > 2. set/getApplicationProtocols() back to SSLParameters. > > Thanks, > > Brad > From erik.joelsson at oracle.com Mon Oct 5 07:57:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 09:57:25 +0200 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <560EBA0A.7040808@oracle.com> References: <560EBA0A.7040808@oracle.com> Message-ID: <56122D65.4060607@oracle.com> Makefile change looks ok. /Erik On 2015-10-02 19:08, Anthony Scarpino wrote: > Hi all, > > I'm need a review of the last developement piece to JEP 246, the > configuration changes. > > I've copied the build-dev in case there were any comments on the minor > changes in the make directory related to the java.security file. > > http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ > > thanks > > Tony From david.lloyd at redhat.com Tue Oct 6 14:42:03 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 6 Oct 2015 09:42:03 -0500 Subject: TLS ALPN Proposal v7 In-Reply-To: <560F1EF4.4060405@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> <560DED86.5070702@oracle.com> <560F1EF4.4060405@oracle.com> Message-ID: <5613DDBB.9020707@redhat.com> I didn't reply on this last week, but this looks workable to me. Thanks! On 10/02/2015 07:19 PM, Bradford Wetmore wrote: > > > On 10/1/2015 7:35 PM, Xuelei Fan wrote: >> On 10/2/2015 9:03 AM, Bradford Wetmore wrote: >>> Major changes: >>> >>> 1. ApplicationProtocols is gone. The H2 black list and comparator were >>> moved to StandardConstants. >>> >>> 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And >>> now that you are parsing the raw network bytes, I added a convenience >>> mapping between the two byte ciphersuite IANA-assigned value and the >>> Java Standard Name. >>> >> There is no SSLExplorer in OpenJDK. I think, maybe, the map is not >> belong to OpenJDK either. >> >> I think, the constants for HTTP2 is also belong to application protocol >> (HTTP2) layer. Application (HTTP2) implementation would take care of >> them. Maybe, they are not a part of JSSE framework either. > > Ok, I've removed all of the H2 constants from StandardConstants. I've > mentioned to the the H2/network team that this is something they will > need to handle/include (e.g. Blacklist/Comparator) in their code, and > they might want to consider APIs similar to what I had. > > I personally found it very useful to have a proper mapping to get the > SSL_ vs. TLS_ prefix correct in the blacklist. > >> I would like to have "h2" and "http/1.1" defined as Standard Algorithms >> Docs as we usually did for other standard constants. > > Of course, they will be added as Standard Algorithm names. > >>> 3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even >>> though these could go into SSLParameters, this change makes backporting >>> much easier. The helper code simply has to reflectively look for the >>> four methods in the implementation classes, and call if they are there. >>> >>> Otherwise, there would have to be reflection both in the user code >>> (above) and implementation (to see if the passed SSLParameters had the >>> new methods via a subclass). >> But, looking forward, per JSSE framework, SSLParameters should be the >> central place to define SSL/TLS configuration parameters. We'd better >> follow the conventions so that application developers won't get confused >> about where SSL/TLS parameters should be configured. > > I went back and forth on this many, many times yesterday. > >> Maybe, we cannot add public APIs for backporting. > > I figured we'd have to use reflection on user-derived classes to see if > the methods were there, but apparently implementation-specifc APIs can > be added in an update release, just not Java APIs. So if we really can > do that, then we can add a jdk.SSLParameters/ > org.openjdk.jsse.SSLParameters extends SSLParameters, and in the > implementation, look for instanceof. > >> I think backporting is >> another history, and would better not impact too much of the design for >> JDK 9 and future releases. > > Ok, so get/setApplicationProtocols() is back in SSLParameters. > > Thanks for the comments everyone. I'm submitting the following to the > CCC (internal review board): > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/ > > Changes: > > 1. No H2 Blacklist/Comparator > > 2. set/getApplicationProtocols() back to SSLParameters. > > Thanks, > > Brad > -- - DML From tomas at primekey.se Wed Oct 7 13:21:50 2015 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 7 Oct 2015 15:21:50 +0200 Subject: Brainpool curves In-Reply-To: <1443616891.5777.1.camel@seth.inexnet.de> References: <84b37f14179b57a34c10d0596b6f7dc0@protonmail.ch> <55FAFE23.1030502@oracle.com> <5602C4D5.8040702@primekey.se> <1443616891.5777.1.camel@seth.inexnet.de> Message-ID: <56151C6E.9060008@primekey.se> Hi, If the JDK devs are interested we have a patch against the latest JDK 7 with Brainpool support through PKCS#11, so we can use Brainpool curves with HSMs (used in production). For SW based crypto we just use BouncyCastle (http://www.bouncycastle.org). Regards, Tomas ********** PrimeKey Solutions AB Lundagatan 16, 171 63 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI ********** On 2015-09-30 14:41, Laumann Andreas wrote: > Am Mittwoch, den 23.09.2015, 17:27 +0200 schrieb Tomas Gustavsson: >> +1 for this. > > +1 also from my side. Brainpool is really important in Europe. > > >> >> On 2015-09-17 19:53, Sean Mullan wrote: >>> On 08/19/2015 05:48 PM, Jiri Stary wrote: >>>> Hello, >>>> >>>> do you plan to support brainpool curves for TLS in Java 9 (RFC 7027) ? >>> >>> There is no plan to support it in 9. There is an open RFE for supporting >>> brainpool in JCE: https://bugs.openjdk.java.net/browse/JDK-7007966 but >>> no specific release has been targeted at this time. >>> >>> --Sean >>> >>>> >>>> Regards >>>> Jiri >>>> >>>> Sent from ProtonMail , encrypted email based in >>>> Switzerland. > > -- > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" > ----------------------------------------------------------------------------- > Andreas Laumann Phone: +49(0) 211 436 989 0 > Head of SW Development Fax: +49(0) 211 436 989 19 > Exceet Secure Solutions AG Mail: Andreas.Laumann at exceet.de > Rethelstra?e 47 Web: http://www.exceet-secure-solutions.de > D - 40237 D?sseldorf/ Germany HR: D?sseldorf 4436 > > > ________________________________ > exceet Secure Solutions AG > Rethelstra?e 47 > 40237 D?sseldorf/ Deutschland > HR D?sseldorf 44361 > www.exceet-secure-solutions.de > Vorstand: > Christian Methe (CEO), > Christian Schmitz > Aufsichtsratsvorsitzender: > Wolf-G?nter Freese > From chris.hegarty at oracle.com Wed Oct 7 18:19:17 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 19:19:17 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils Message-ID: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method that offers bulk blocking InputStream read semantics. In 9, java.io.InputStream has been retrofitted with two methods that provide similar, but not quite the same, functionality, readNBytes and readAllBytes, see JDK-8080835 [3]. There are a number of places where IOUtils can be replaced with the appropriate supported API, readNBytes or readAllBytes. There are a number of places, mainly in the security implementation, that required to read a specific number of bytes ( not to end of stream ), where it is preferable to not preallocate the byte[] and allow it to "grow" lazily, to be defensive against protocol errors. These cases cannot use read[N|All]Bytes, so it makes sense to retain IOUtils but locate it in a package, sun.security.util, that makes it clear who its primary consumer is. http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138978 [2] https://bugs.openjdk.java.net/browse/JDK-8132928 [3] https://bugs.openjdk.java.net/browse/JDK-8080835 From Roger.Riggs at Oracle.com Wed Oct 7 19:01:32 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Oct 2015 15:01:32 -0400 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: References: Message-ID: <56156C0C.90008@Oracle.com> Hi Chris, Looks fine. The change in exception message is more informative than the previous exception message. Roger On 10/7/2015 2:19 PM, Chris Hegarty wrote: > This primary motivation behind this bug [1] is the clearing out of > sun.misc, in preparation for JEP 260 [2]. > > sun.misc.IOUtils is a JDK internal convenience utility class that > provides a single method that offers bulk blocking InputStream read > semantics. In 9, java.io.InputStream has been retrofitted with two > methods that provide similar, but not quite the same, functionality, > readNBytes and readAllBytes, see JDK-8080835 [3]. > > There are a number of places where IOUtils can be replaced with the > appropriate supported API, readNBytes or readAllBytes. > > There are a number of places, mainly in the security implementation, > that required to read a specific number of bytes ( not to end of > stream ), where it is preferable to not preallocate the byte[] and > allow it to "grow" lazily, to be defensive against protocol errors. > These cases cannot use read[N|All]Bytes, so it makes sense to retain > IOUtils but locate it in a package, sun.security.util, that makes it > clear who its primary consumer is. > > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138978 > [2] https://bugs.openjdk.java.net/browse/JDK-8132928 > [3] https://bugs.openjdk.java.net/browse/JDK-8080835 From Alan.Bateman at oracle.com Wed Oct 7 19:04:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Oct 2015 20:04:01 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: References: Message-ID: <56156CA1.5090405@oracle.com> On 07/10/2015 19:19, Chris Hegarty wrote: > This primary motivation behind this bug [1] is the clearing out of > sun.misc, in preparation for JEP 260 [2]. > > It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, could that one be fixed? The rest look fine. -Alan From chris.hegarty at oracle.com Wed Oct 7 19:15:43 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 20:15:43 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <56156CA1.5090405@oracle.com> References: <56156CA1.5090405@oracle.com> Message-ID: <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> On 7 Oct 2015, at 20:04, Alan Bateman wrote: > On 07/10/2015 19:19, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in preparation for JEP 260 [2]. >> >> > It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, It certainly would be nice. > could that one be fixed? I didn?t look too hard at this because sun.security.util is already exported to java.naming, but yes I could write a readFully variant that works for this. I?ll take a closer look. > The rest look fine. Thanks. -Chris. > -Alan From chris.hegarty at oracle.com Wed Oct 7 19:57:16 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Oct 2015 20:57:16 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> References: <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> Message-ID: <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> On 7 Oct 2015, at 20:15, Chris Hegarty wrote: > On 7 Oct 2015, at 20:04, Alan Bateman wrote: > >> On 07/10/2015 19:19, Chris Hegarty wrote: >>> This primary motivation behind this bug [1] is the clearing out of >>> sun.misc, in preparation for JEP 260 [2]. >>> >>> >> It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, > > It certainly would be nice. > >> could that one be fixed? > > I didn?t look too hard at this because sun.security.util > is already exported to java.naming, but yes I could > write a readFully variant that works for this. I?ll take a > closer look. I updated Connection with a readFully that has the same semantics as IOUtils. http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ -Chris. From Alan.Bateman at oracle.com Wed Oct 7 20:28:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Oct 2015 21:28:50 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> References: <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> Message-ID: <56158082.4050304@oracle.com> On 07/10/2015 20:57, Chris Hegarty wrote: > : > I updated Connection with a readFully that has the same > semantics as IOUtils. > > http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ > I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? -Alan From paul.sandoz at oracle.com Thu Oct 8 08:32:05 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Oct 2015 10:32:05 +0200 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <56158082.4050304@oracle.com> References: <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> <56158082.4050304@oracle.com> Message-ID: <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> > On 7 Oct 2015, at 22:28, Alan Bateman wrote: > > > On 07/10/2015 20:57, Chris Hegarty wrote: >> : >> I updated Connection with a readFully that has the same >> semantics as IOUtils. >> >> http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ >> > I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? > It reads at most ?seqlen" bytes, so the array may be larger than necessary, which might be ok depending on whether one can trust "seqlen". The following pattern occurs a few times: byte[] b = is.readAllBytes(); if (len !- -1 && b.length != len) throw new EOFException(?) A further useful addition to consider would be an IS.readFulyl(int expectedLength). I suspect you could probably remove sun.security.util.IOUtils, if the assumption is correct than one never relies on a length of -1 or Integer.MAX_VALUE to signal ?readAllBytes?. That seems to be the case since all security usages pass in a true value for readAll. From what i can tell the length passed in is never < 0, since it is checked before hand. So that leaves the Integer.MAX_VALUE case, which i am not sure is intentional in the use-cases, as that will mean readAllBytes and not readNBytes. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chris.hegarty at oracle.com Thu Oct 8 08:46:42 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 8 Oct 2015 09:46:42 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> References: <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> <56158082.4050304@oracle.com> <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> Message-ID: <18078001-183E-4A5F-BA97-28EF3D149EE8@oracle.com> On 8 Oct 2015, at 09:32, Paul Sandoz wrote: > >> On 7 Oct 2015, at 22:28, Alan Bateman wrote: >> >> >> On 07/10/2015 20:57, Chris Hegarty wrote: >>> : >>> I updated Connection with a readFully that has the same >>> semantics as IOUtils. >>> >>> http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ >>> >> I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? >> > > It reads at most ?seqlen" bytes, so the array may be larger than necessary, which might be ok depending on whether one can trust "seqlen?. We do no trust ?seqlen?. :-( > The following pattern occurs a few times: > > byte[] b = is.readAllBytes(); > if (len !- -1 && b.length != len) throw new EOFException(?) > > A further useful addition to consider would be an IS.readFulyl(int expectedLength). Yes, I think a variant of readNBytes(long expectedLength), would be a useful addition. I can file a bug and add it to the I/O grab bag, 6852033 [1]. Then a further round of cleanup could possibly remove IOUtils completely. > I suspect you could probably remove sun.security.util.IOUtils, if the assumption is correct than one never relies on a length of -1 or Integer.MAX_VALUE to signal ?readAllBytes?. That seems to be the case since all security usages pass in a true value for readAll. From what i can tell the length passed in is never < 0, since it is checked before hand. So that leaves the Integer.MAX_VALUE case, which i am not sure is intentional in the use-cases, as that will mean readAllBytes and not readNBytes. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-6852033 From paul.sandoz at oracle.com Thu Oct 8 08:55:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Oct 2015 10:55:14 +0200 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <18078001-183E-4A5F-BA97-28EF3D149EE8@oracle.com> References: <56156CA1.5090405@oracle.com> <460DA874-DD8C-4999-92BE-91CC7E0392D6@oracle.com> <7724B104-27B8-4C07-95F9-F6D00D92FCCC@oracle.com> <56158082.4050304@oracle.com> <7A05EA1B-F4C1-4512-ABED-DBB169E70B38@oracle.com> <18078001-183E-4A5F-BA97-28EF3D149EE8@oracle.com> Message-ID: > On 8 Oct 2015, at 10:46, Chris Hegarty wrote: >> It reads at most ?seqlen" bytes, so the array may be larger than necessary, which might be ok depending on whether one can trust "seqlen?. > > We do no trust ?seqlen?. :-( > Good! >> The following pattern occurs a few times: >> >> byte[] b = is.readAllBytes(); >> if (len !- -1 && b.length != len) throw new EOFException(?) >> >> A further useful addition to consider would be an IS.readFulyl(int expectedLength). > > Yes, I think a variant of readNBytes(long expectedLength), > would be a useful addition. I can file a bug and add it to > the I/O grab bag, 6852033 [1]. Then a further round of > cleanup could possibly remove IOUtils completely. > Ok. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sean.mullan at oracle.com Thu Oct 8 12:34:00 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 8 Oct 2015 08:34:00 -0400 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: References: Message-ID: <561662B8.6070007@oracle.com> Looks fine to me, though I have one question below. On 10/7/15 2:19 PM, Chris Hegarty wrote: > This primary motivation behind this bug [1] is the clearing out of > sun.misc, in preparation for JEP 260 [2]. > > sun.misc.IOUtils is a JDK internal convenience utility class that > provides a single method that offers bulk blocking InputStream read > semantics. In 9, java.io.InputStream has been retrofitted with two > methods that provide similar, but not quite the same, functionality, > readNBytes and readAllBytes, see JDK-8080835 [3]. > > There are a number of places where IOUtils can be replaced with the > appropriate supported API, readNBytes or readAllBytes. > > There are a number of places, mainly in the security implementation, > that required to read a specific number of bytes ( not to end of > stream ), where it is preferable to not preallocate the byte[] and > allow it to "grow" lazily, to be defensive against protocol errors. > These cases cannot use read[N|All]Bytes, so it makes sense to retain > IOUtils but locate it in a package, sun.security.util, that makes it > clear who its primary consumer is. Would it make sense to add a method to InputStream that provides that functionality the security classes need? --Sean > > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ > http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138978 > [2] https://bugs.openjdk.java.net/browse/JDK-8132928 > [3] https://bugs.openjdk.java.net/browse/JDK-8080835 > From simone.bordet at gmail.com Thu Oct 8 16:55:35 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 8 Oct 2015 18:55:35 +0200 Subject: TLS ALPN Proposal v7 In-Reply-To: <560F1EF4.4060405@oracle.com> References: <55ED0A6A.3050806@oracle.com> <56051836.70901@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> <560DED86.5070702@oracle.com> <560F1EF4.4060405@oracle.com> Message-ID: Bradford, On Sat, Oct 3, 2015 at 2:19 AM, Bradford Wetmore wrote: > Thanks for the comments everyone. I'm submitting the following to the CCC > (internal review board): > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/ > > Changes: > > 1. No H2 Blacklist/Comparator > > 2. set/getApplicationProtocols() back to SSLParameters. Have you implemented this solution already ? Also for clients ? Do you have feedback on actually implementing ALPN in this way ? -- 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 bradford.wetmore at oracle.com Thu Oct 8 17:32:25 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 8 Oct 2015 10:32:25 -0700 Subject: TLS ALPN Proposal v7 In-Reply-To: References: <55ED0A6A.3050806@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> <560DED86.5070702@oracle.com> <560F1EF4.4060405@oracle.com> Message-ID: <5616A8A9.9010809@oracle.com> > On Sat, Oct 3, 2015 at 2:19 AM, Bradford Wetmore > wrote: >> Thanks for the comments everyone. I'm submitting the following to the CCC >> (internal review board): >> >> http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/ >> >> Changes: >> >> 1. No H2 Blacklist/Comparator >> >> 2. set/getApplicationProtocols() back to SSLParameters. > > Have you implemented this solution already ? It is underway. The guts was already done based on previous API versions. The new API is less involved, so it should be simpler to do as it's just cutting out the existing ciphersuite/ALPN selection stuff. > Also for clients ? Client/server are both externally(API)/internally essentially the same. The big difference is that for clients you send all the values passed in, for servers you only consult the first which is the selected ALPN value. > Do you have feedback on actually implementing ALPN in this way ? Based on what I saw previously, it should be pretty straighforward. Brad From chris.hegarty at oracle.com Thu Oct 8 22:18:38 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 8 Oct 2015 23:18:38 +0100 Subject: RFR [9] 8138978: Examine usages of sun.misc.IOUtils In-Reply-To: <561662B8.6070007@oracle.com> References: <561662B8.6070007@oracle.com> Message-ID: > On 8 Oct 2015, at 13:34, Sean Mullan wrote: > > Looks fine to me, though I have one question below. Thanks for looking at this Sean. > On 10/7/15 2:19 PM, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in preparation for JEP 260 [2]. >> >> sun.misc.IOUtils is a JDK internal convenience utility class that >> provides a single method that offers bulk blocking InputStream read >> semantics. In 9, java.io.InputStream has been retrofitted with two >> methods that provide similar, but not quite the same, functionality, >> readNBytes and readAllBytes, see JDK-8080835 [3]. >> >> There are a number of places where IOUtils can be replaced with the >> appropriate supported API, readNBytes or readAllBytes. >> >> There are a number of places, mainly in the security implementation, >> that required to read a specific number of bytes ( not to end of >> stream ), where it is preferable to not preallocate the byte[] and >> allow it to "grow" lazily, to be defensive against protocol errors. >> These cases cannot use read[N|All]Bytes, so it makes sense to retain >> IOUtils but locate it in a package, sun.security.util, that makes it >> clear who its primary consumer is. > > Would it make sense to add a method to InputStream that provides that functionality the security classes need? I filed 8139206 to track this. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8139206 > --Sean > >> >> http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ >> http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138978 >> [2] https://bugs.openjdk.java.net/browse/JDK-8132928 >> [3] https://bugs.openjdk.java.net/browse/JDK-8080835 >> From weijun.wang at oracle.com Thu Oct 8 23:43:14 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 9 Oct 2015 07:43:14 +0800 Subject: RFR 8085904: Test timeout on Mac Message-ID: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8085904/webrev.00/ I just s/home/tmp/g. /home is an autofs mount point and resolving it slows everything down. Hopefully FQDN look up is not the problem here. Thanks Max From bradford.wetmore at oracle.com Thu Oct 8 23:50:51 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 8 Oct 2015 16:50:51 -0700 Subject: RFR 8085904: Test timeout on Mac In-Reply-To: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> Message-ID: <5617015B.1010606@oracle.com> That look ok. I'm assuming this change won't cause problems on Windows that don't have a /tmp? I'm guessing not, since /home likely doesn't exist either on Windows. JRPT runs ok? Brad On 10/8/2015 4:43 PM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8085904/webrev.00/ > > I just s/home/tmp/g. /home is an autofs mount point and resolving it slows everything down. Hopefully FQDN look up is not the problem here. > > Thanks > Max > From weijun.wang at oracle.com Fri Oct 9 01:31:23 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 9 Oct 2015 09:31:23 +0800 Subject: RFR 8085904: Test timeout on Mac In-Reply-To: <5617015B.1010606@oracle.com> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> Message-ID: <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> > On Oct 9, 2015, at 7:50 AM, Bradford Wetmore wrote: > > That look ok. > > I'm assuming this change won't cause problems on Windows that don't have a /tmp? I'm guessing not, since /home likely doesn't exist either on Windows. I believe so. > JRPT runs ok? Yes. The Mac test shows all finish in 1 or 2 seconds. Thanks Max > > Brad > > > > On 10/8/2015 4:43 PM, Wang Weijun wrote: >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8085904/webrev.00/ >> >> I just s/home/tmp/g. /home is an autofs mount point and resolving it slows everything down. Hopefully FQDN look up is not the problem here. >> >> Thanks >> Max >> From anthony.scarpino at oracle.com Fri Oct 9 17:06:38 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 9 Oct 2015 10:06:38 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <560EBA0A.7040808@oracle.com> References: <560EBA0A.7040808@oracle.com> Message-ID: <5617F41E.6010803@oracle.com> Ping for a security review.. Tony On 10/02/2015 10:08 AM, Anthony Scarpino wrote: > Hi all, > > I'm need a review of the last developement piece to JEP 246, the > configuration changes. > > I've copied the build-dev in case there were any comments on the minor > changes in the make directory related to the java.security file. > > http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ > > thanks > > Tony From jetty at suche.org Sun Oct 11 07:59:22 2015 From: jetty at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 11 Oct 2015 09:59:22 +0200 Subject: Problems with CipherBox and AEAD In-Reply-To: <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> Message-ID: <561A16DA.5020301@suche.org> Hi, when i extends "sun.security.ssl.CipherSuite" with final static BulkCipher B_CHACHA20_POLY1305 = new BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 0, 0, true ); i found an Problem in "sun.security.ssl.CipherBox Method "applyExplicitNonce" there for the AEAD_CIPHER case is an NPE if the IV Length is zero. Then fixedIv become null and there is an NPE. The Workaround for this is final byte[] iv; if(this.fixedIv == null) { // FIX for CHACHA iv = new byte[this.recordIvSize]; // CHACHA fix bb.get(iv, 0, this.recordIvSize); } else { iv = Arrays.copyOf(this.fixedIv, this.fixedIv.length + this.recordIvSize); bb.get(iv, this.fixedIv.length, this.recordIvSize); } Another problem would occour if i use "new BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 8, 8, true );" Then in createExplicitNonce the nonce should become zero size but is fixed length for AEAD of 8 bytes. Both was seen in JDK-1.8.0_60 Gru? Thomas Lu?nig From christoph.langer at sap.com Mon Oct 12 21:04:08 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 12 Oct 2015 21:04:08 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you'll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property "sun.security.mscapi.ignoreFailingCertificates" which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here: http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Oct 13 02:14:33 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Oct 2015 10:14:33 +0800 Subject: Problems with CipherBox and AEAD In-Reply-To: <561A16DA.5020301@suche.org> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> <561A16DA.5020301@suche.org> Message-ID: <561C6909.2020305@oracle.com> Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC? Looks like the proposal was not moving forward since May, 2014. https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 Thanks, Xuelei On 10/11/2015 3:59 PM, Thomas Lu?nig wrote: > Hi, > > when i extends "sun.security.ssl.CipherSuite" with > final static BulkCipher B_CHACHA20_POLY1305 = new > BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 0, 0, true ); > i found an Problem in "sun.security.ssl.CipherBox > Method "applyExplicitNonce" there for the AEAD_CIPHER case is an NPE if > the IV Length is zero. Then fixedIv become null > and there is an NPE. The Workaround for this is > final byte[] iv; > if(this.fixedIv == null) { // FIX for CHACHA > iv = new byte[this.recordIvSize]; // CHACHA fix > bb.get(iv, 0, this.recordIvSize); > } else { > iv = Arrays.copyOf(this.fixedIv, this.fixedIv.length + > this.recordIvSize); > bb.get(iv, this.fixedIv.length, this.recordIvSize); > } > Another problem would occour if i use "new > BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 8, 8, true );" > Then in createExplicitNonce the nonce should become zero size but is > fixed length for AEAD of 8 bytes. > Both was seen in JDK-1.8.0_60 > > Gru? Thomas Lu?nig > From bradford.wetmore at oracle.com Tue Oct 13 22:54:17 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 13 Oct 2015 15:54:17 -0700 Subject: Problems with CipherBox and AEAD In-Reply-To: <561C6909.2020305@oracle.com> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> <561A16DA.5020301@suche.org> <561C6909.2020305@oracle.com> Message-ID: <561D8B99.3090705@oracle.com> A couple comments: > Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC? > Looks like the proposal was not moving forward since May, 2014. > > https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 AFAIK, CHACHA20/Poly1305 based suites were never issued ciphersuite numbers. http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml The following suites are in the "Unassigned" section, so I assume they are just for this draft: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x13} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x14} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x15} As you probably know, we haven't supported anything like that (Stream cipher + Poly1305 as an AEAD). I wouldn't be surprised if there were other problems. Brad On 10/12/2015 7:14 PM, Xuelei Fan wrote: > Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC? > Looks like the proposal was not moving forward since May, 2014. > > https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 > > Thanks, > Xuelei > > On 10/11/2015 3:59 PM, Thomas Lu?nig wrote: >> Hi, >> >> when i extends "sun.security.ssl.CipherSuite" with >> final static BulkCipher B_CHACHA20_POLY1305 = new >> BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 0, 0, true ); >> i found an Problem in "sun.security.ssl.CipherBox >> Method "applyExplicitNonce" there for the AEAD_CIPHER case is an NPE if >> the IV Length is zero. Then fixedIv become null >> and there is an NPE. The Workaround for this is >> final byte[] iv; >> if(this.fixedIv == null) { // FIX for CHACHA >> iv = new byte[this.recordIvSize]; // CHACHA fix >> bb.get(iv, 0, this.recordIvSize); >> } else { >> iv = Arrays.copyOf(this.fixedIv, this.fixedIv.length + >> this.recordIvSize); >> bb.get(iv, this.fixedIv.length, this.recordIvSize); >> } >> Another problem would occour if i use "new >> BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 8, 8, true );" >> Then in createExplicitNonce the nonce should become zero size but is >> fixed length for AEAD of 8 bytes. >> Both was seen in JDK-1.8.0_60 >> >> Gru? Thomas Lu?nig >> > From mstjohns at comcast.net Wed Oct 14 00:16:30 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Tue, 13 Oct 2015 20:16:30 -0400 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> Message-ID: <561D9EDE.1020408@comcast.net> Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: > > Hi, > > please review a change proposal regarding an issue in the Microsoft > Security API (mscapi). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ > > > I stumbled over the issue when using an old IAIK security provider. It > would throw java.security.cert.CertificateException upon parsing ECC > based certificates when generating Certificate objects. The way it is > right now, such exceptions are silently caught and the Windows > Keystore is created with incomplete data. Upon accessing such ECC > certificates from the Keystore object, e.g. when iterating over it, > you?ll get exceptions like: > > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > > at > sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) > > at > sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) > > at java.security.KeyStore.getCertificate(KeyStore.java:1095) > > At that point it is not obvious what the real root cause for that is. > > With my change, loading of the keystore would already throw like this: > > java.io.IOException: java.security.KeyStoreException: Exception > occurred generating certificate object for alias DigiCert Assured ID > Root G3 > > at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) > > at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) > > at java.security.KeyStore.load(KeyStore.java:1459) > > at > WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) > > Caused by: java.security.KeyStoreException: Exception occurred > generating certificate object for alias DigiCert Assured ID Root G3 > > at > sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) > > at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) > > ... 3 more > > Caused by: java.security.cert.CertificateException: Error parsing > certificates! iaik.asn1.DerInputException: Next ASN.1 object is no > OBJECT IDENTIFIER! > > at > iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) > > at > java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) > > at > sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) > > ... 5 more > > This is more obvious when it comes to analyzing such an issue. > > Also, I added a property > ?sun.security.mscapi.ignoreFailingCertificates? which, when set to > true, will cause skipping of certificates that failed with Exception. > That might be a nice workaround option if one is not particularly > interested in a failing certificate. > > You can reproduce all this with the test coding in the OpenJDK Bug, > the IAIK provider 3.15 which is downloadable here: > http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research > version, needs registration) and ECC certificates in the Windows Root > certificate store. > > Would you think this change is reasonable and worthwile? > > Thanks & Best regards > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Wed Oct 14 08:44:56 2015 From: sibabrata.sahoo at oracle.com (Siba Sahoo) Date: Wed, 14 Oct 2015 01:44:56 -0700 (PDT) Subject: [9] RFR:8078813:Test JAAS with modules Message-ID: <948f6d43-e2b9-4d57-ab82-5cb59d352cfd@default> Hi, Please review Jigsaw modular test for JAAS. Bug: https://bugs.openjdk.java.net/browse/JDK-8078813 Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8078813/webrev.01/ JPRT: http://scaaa637.us.oracle.com/archive/2015/10/2015-10-14-055613.sisahoo.jdk9jigsaw/ Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Oct 14 14:59:34 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Oct 2015 15:59:34 +0100 Subject: RFR :8136534: Loading JKS keystore using non-null InputStream results in closed stream Message-ID: <561E6DD6.1000600@oracle.com> Backporting this fix to jdk8u-dev sources. The jdk9 changeset didn't apply cleanly but the fix in essence is the removal of a try-with-resources block. Tests are green. bug report : https://bugs.openjdk.java.net/browse/JDK-8136534 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8136534.8u/webrev/ -- Regards, Sean. From vincent.x.ryan at oracle.com Wed Oct 14 15:08:22 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 14 Oct 2015 16:08:22 +0100 Subject: RFR :8136534: Loading JKS keystore using non-null InputStream results in closed stream In-Reply-To: <561E6DD6.1000600@oracle.com> References: <561E6DD6.1000600@oracle.com> Message-ID: <7AE2EE5B-1AE0-43FB-8FA1-430EB75D4F9D@oracle.com> Looks good to me. > On 14 Oct 2015, at 15:59, Se?n Coffey wrote: > > Backporting this fix to jdk8u-dev sources. > > The jdk9 changeset didn't apply cleanly but the fix in essence is the removal of a try-with-resources block. Tests are green. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8136534 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8136534.8u/webrev/ > > -- > Regards, > Sean. > From openjdk at suche.org Wed Oct 14 18:41:01 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 14 Oct 2015 20:41:01 +0200 Subject: Problems with CipherBox and AEAD In-Reply-To: <561D8BC0.5010903@oracle.com> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> <561A16DA.5020301@suche.org> <561C6909.2020305@oracle.com> <561D8BC0.5010903@oracle.com> Message-ID: <561EA1BD.1030103@suche.org> Hi, the first point is this suite is maybe only draft, but it is used in chrome an the strongest suite supported in chrome. GCM suites are only support in 128bit version,so this was the "request" to implement it. The second point is yes this was the only technical problem to get it running. Other points where the problem that there are two different RFC vs DRAFT how to implement it. But now i got it running. You can see it in action on http://suche.org/ . Since i use the code from bouncycastle as basis for the CHACHA and POLY i can not publish the full source here. But i think it was an good idea to point this out as an problem issue. Gru? Thomas Am 14.10.2015 um 00:54 schrieb Bradford Wetmore: > Thomas, > > Out of curiosity, are you getting requests for this suite? > > Brad > > > On 10/12/2015 7:14 PM, Xuelei Fan wrote: >> Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC? >> Looks like the proposal was not moving forward since May, 2014. >> >> https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 >> >> Thanks, >> Xuelei >> >> On 10/11/2015 3:59 PM, Thomas Lu?nig wrote: >>> Hi, >>> >>> when i extends "sun.security.ssl.CipherSuite" with >>> final static BulkCipher B_CHACHA20_POLY1305 = new >>> BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 0, 0, true ); >>> i found an Problem in "sun.security.ssl.CipherBox >>> Method "applyExplicitNonce" there for the AEAD_CIPHER case is an NPE if >>> the IV Length is zero. Then fixedIv become null >>> and there is an NPE. The Workaround for this is >>> final byte[] iv; >>> if(this.fixedIv == null) { // FIX for CHACHA >>> iv = new byte[this.recordIvSize]; // CHACHA fix >>> bb.get(iv, 0, this.recordIvSize); >>> } else { >>> iv = Arrays.copyOf(this.fixedIv, this.fixedIv.length + >>> this.recordIvSize); >>> bb.get(iv, this.fixedIv.length, this.recordIvSize); >>> } >>> Another problem would occour if i use "new >>> BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 8, 8, true );" >>> Then in createExplicitNonce the nonce should become zero size but is >>> fixed length for AEAD of 8 bytes. >>> Both was seen in JDK-1.8.0_60 >>> >>> Gru? Thomas Lu?nig >>> >> From christoph.langer at sap.com Wed Oct 14 22:35:50 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 14 Oct 2015 22:35:50 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <561D9EDE.1020408@comcast.net> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> Hi Mike, thanks for your comments on this. I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I'd say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you'll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException - however, it would still be difficult to find the root cause why a certificate could not be loaded. What do you think? @all: Are there other opinions? Thanks and best regards Christoph From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns Sent: Mittwoch, 14. Oktober 2015 02:17 To: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you'll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property "sun.security.mscapi.ignoreFailingCertificates" which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here: http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Thu Oct 15 00:09:19 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 14 Oct 2015 20:09:19 -0400 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> Message-ID: Sorry for the top post, I'm wring this on an iPad on a plane. It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. Mike Sent from my iPad > On Oct 14, 2015, at 18:35, Langer, Christoph wrote: > > Hi Mike, > > thanks for your comments on this. > > I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? > > The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. > > What do you think? > > @all: Are there other opinions? > > Thanks and best regards > Christoph > > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns > Sent: Mittwoch, 14. Oktober 2015 02:17 > To: security-dev at openjdk.java.net > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > Hi - > > I took a look and this probably isn't the correct way to fix this. > > A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? > > The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") > > Mike > > > On 10/12/2015 5:04 PM, Langer, Christoph wrote: > Hi, > > please review a change proposal regarding an issue in the Microsoft Security API (mscapi). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ > > I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) > at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) > at java.security.KeyStore.getCertificate(KeyStore.java:1095) > At that point it is not obvious what the real root cause for that is. > > With my change, loading of the keystore would already throw like this: > java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 > at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) > at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) > at java.security.KeyStore.load(KeyStore.java:1459) > at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) > Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 > at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) > at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) > ... 3 more > Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! > at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) > at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) > at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) > ... 5 more > This is more obvious when it comes to analyzing such an issue. > > Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. > > You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here: http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. > > Would you think this change is reasonable and worthwile? > > Thanks & Best regards > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Oct 15 07:47:04 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 15 Oct 2015 15:47:04 +0800 Subject: [9] RFR:8078813:Test JAAS with modules In-Reply-To: <948f6d43-e2b9-4d57-ab82-5cb59d352cfd@default> References: <948f6d43-e2b9-4d57-ab82-5cb59d352cfd@default> Message-ID: Looks fine, and very interesting. Just some questions: 1. expectedResult is PASS in all test runs. Do you think it would be something else? Maybe compiler error and jar creation error? Could that happen? 2. Are the .class files always the same? If so, is it possible to compile them once, and use them to create different jars? In fact, maybe you don't need to create jars every time. It looks like UN_NAMED and AUTO use the same jar, and if only clientModuleType changes there is no need to recreate service jar. 3. UN_NAMED looks strange, maybe UNNAMED? 4. Very tiny concern, but you are looking for "No LoginModule found" in output messages. We have some bugs complaining certain text not found if test is not running in an English locale. Is there a way to avoid looking for these exact words? Or maybe you can just add "-Duser.language=en -Duser.region=US" to @main. 5. JigsawCommon.createModularjar() is quite useful. Maybe you can add it into test/jdk/jigsaw/lib/JarUtils.java? Thanks Max > On Oct 14, 2015, at 4:44 PM, Siba Sahoo wrote: > > Hi, > > Please review Jigsaw modular test for JAAS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078813 > Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8078813/webrev.01/ > JPRT: http://scaaa637.us.oracle.com/archive/2015/10/2015-10-14-055613.sisahoo.jdk9jigsaw/ > > Thanks, > Siba From Alan.Bateman at oracle.com Thu Oct 15 08:26:51 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Oct 2015 09:26:51 +0100 Subject: [9] RFR:8078813:Test JAAS with modules In-Reply-To: References: <948f6d43-e2b9-4d57-ab82-5cb59d352cfd@default> Message-ID: <561F634B.9070604@oracle.com> On 15/10/2015 08:47, Wang Weijun wrote: > Looks fine, and very interesting. > > Just some questions: > > 1. expectedResult is PASS in all test runs. Do you think it would be something else? Maybe compiler error and jar creation error? Could that happen? > > 2. Are the .class files always the same? If so, is it possible to compile them once, and use them to create different jars? In fact, maybe you don't need to create jars every time. It looks like UN_NAMED and AUTO use the same jar, and if only clientModuleType changes there is no need to recreate service jar. > > 3. UN_NAMED looks strange, maybe UNNAMED? > > 4. Very tiny concern, but you are looking for "No LoginModule found" in output messages. We have some bugs complaining certain text not found if test is not running in an English locale. Is there a way to avoid looking for these exact words? Or maybe you can just add "-Duser.language=en -Duser.region=US" to @main. > > 5. JigsawCommon.createModularjar() is quite useful. Maybe you can add it into test/jdk/jigsaw/lib/JarUtils.java? Have you decided where these tests will be replaced? I assume test/java/security/jigsaw is temporary and you are scouting out a home under test/javax/security/auth/login, right? In time then jtreg will have support for tests that are modules so it should help with tests like this. I agree with your comment about renaming UN_NAMED to NAMED, I assume STRICT should be renamed to EXPLICIT too. On JarUtils then if the test writes the module-info.class in the right location then it should just work. For the explicit module case I expect it should just work when exploded on the file system too, it doesn't strictly need to be a modular JAR. -Alan. From valerie.peng at oracle.com Thu Oct 15 18:42:01 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Oct 2015 11:42:01 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <5617F41E.6010803@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> Message-ID: <561FF379.3040202@oracle.com> - line 58-59, the "[openjdk target cpu architecture]" one should be moved up. The optional restricted packages file names are at the end. - for the javadoc changes, the approved CCC has @implNote instead of @implSpec. Instead of just {@code getProviders}, it seems {@code Security.getProviders} is clearer. - line 262 - 267, given that there is an argument specifying provider name, I don't think your changes applies to this method. If correct, the javadoc change should be removed. - looks fine. I will continue to look at ProviderList.java and send u comments in a separate email. Thanks, Valerie On 10/9/2015 10:06 AM, Anthony Scarpino wrote: > Ping for a security review.. > > Tony > > On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >> Hi all, >> >> I'm need a review of the last developement piece to JEP 246, the >> configuration changes. >> >> I've copied the build-dev in case there were any comments on the minor >> changes in the make directory related to the java.security file. >> >> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >> >> thanks >> >> Tony > From anthony.scarpino at oracle.com Thu Oct 15 20:43:50 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 15 Oct 2015 13:43:50 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <561FF379.3040202@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> <561FF379.3040202@oracle.com> Message-ID: <56201006.5030901@oracle.com> On 10/15/2015 11:42 AM, Valerie Peng wrote: > > > - line 58-59, the "[openjdk target cpu architecture]" one should be > moved up. The optional restricted packages file names are at the end. Ah yes.. of course.. > > > - for the javadoc changes, the approved CCC has @implNote instead of > @implSpec. Sigh.. I must have cut-n-pasted the earlier version of the CCC.. > Instead of just {@code getProviders}, it seems {@code > Security.getProviders} is clearer. If I can change it without getting CCC approval, I will. If not, then it will remain this way. > > > - line 262 - 267, given that there is an argument specifying provider > name, I don't think your changes applies to this method. If correct, the > javadoc change should be removed. I must of pasted it their by mistake. It's not in the CCC either. > > > - looks fine. > > I will continue to look at ProviderList.java and send u comments in a > separate email. > Thanks, > Valerie > > On 10/9/2015 10:06 AM, Anthony Scarpino wrote: >> Ping for a security review.. >> >> Tony >> >> On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >>> Hi all, >>> >>> I'm need a review of the last developement piece to JEP 246, the >>> configuration changes. >>> >>> I've copied the build-dev in case there were any comments on the minor >>> changes in the make directory related to the java.security file. >>> >>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >>> >>> thanks >>> >>> Tony >> From valerie.peng at oracle.com Fri Oct 16 00:20:36 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Oct 2015 17:20:36 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <561FF379.3040202@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> <561FF379.3040202@oracle.com> Message-ID: <562042D4.3050009@oracle.com> Hi Tony, Here are the comments for the remaining file. - line 621, is there a particular reason to return immediately when s.ids is null? If there is, it should be commented here. The get(ServiceList s) method will fall back to s.type and s.algorithm when s.ids is null. Would be nice to state the reason for the difference in implementation. - line 698, the method name "compare" seems a little misleading, it only compares type and algorithm and it returns boolean instead of integer as the compare in other classes. Maybe names like "lookup" or "match" would be better... - line 705, there is no check on "t" being non-null, why not use type.compareToIgnoreCase(t) instead? - line 710, exact match on algorithm? I thought u will support partial match, e.g. AES entry matching AES/CBC/PKCS5Padding request. Why don't u use "toString()" in the debug output as it provides more info. - line 722, why is "type" not included in the toString()? Thanks, Valerie On 10/15/2015 11:42 AM, Valerie Peng wrote: > > > - line 58-59, the "[openjdk target cpu architecture]" one should be > moved up. The optional restricted packages file names are at the end. > > > - for the javadoc changes, the approved CCC has @implNote instead of > @implSpec. > Instead of just {@code getProviders}, it seems {@code > Security.getProviders} is clearer. > > > - line 262 - 267, given that there is an argument specifying provider > name, I don't think your changes applies to this method. If correct, > the javadoc change should be removed. > > > - looks fine. > > I will continue to look at ProviderList.java and send u comments in a > separate email. > Thanks, > Valerie > > On 10/9/2015 10:06 AM, Anthony Scarpino wrote: >> Ping for a security review.. >> >> Tony >> >> On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >>> Hi all, >>> >>> I'm need a review of the last developement piece to JEP 246, the >>> configuration changes. >>> >>> I've copied the build-dev in case there were any comments on the minor >>> changes in the make directory related to the java.security file. >>> >>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >>> >>> thanks >>> >>> Tony >> From xuelei.fan at oracle.com Fri Oct 16 02:46:09 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 16 Oct 2015 10:46:09 +0800 Subject: The fix for JDK-806769 breaks some ldap usages. In-Reply-To: References: <560558C9.40804@oracle.com> Message-ID: <562064F1.5050209@oracle.com> Hi David, Thanks for reporting the issue. I filed a bug for the tracking: https://bugs.openjdk.java.net/browse/JDK-8139721 Thanks, Xuelei On 9/26/2015 4:39 PM, David Black wrote: > > > On Saturday, 26 September 2015, Sean Mullan > wrote: > > JDK-806769 doesn't exist, can you double-check what issue you think > caused this? Looks like you are missing a digit. > > > Hi Sean, hmm I don't know how I managed that ... the complete issue id > is JDK-8067695. > > > > > On 9/24/15 10:46 PM, David Black wrote: > > As I do not have an account on https://bugs.openjdk.java.net, > yes I have > submitted a standard oracle java bug report, I thought it might > be of > interest to those on this mailing list to forward information on how > some java ldap users since the JDK-806769 fix may encounter invalid > ldaps hostname issues. > > When an "ldaps" provider url is set in the environment and a custom > SocketFactory, which sets the SSLSocket endpoint identification > algorithm to "LDAPS", is set in the ldap environment hostname > because of > the way the fix for JDK-806769 was implemented some clients > encounter a > CertificateException. This occurs because the code inside the > com.sun.jndi.ldap.Connection class createSocket method[0] > "prefers" to > invoke the socketFactory.createSocket() method instead of > socketFactory.createSocket(String host, int port) when a connection > timeout is set, which results in the host not being set in the > created > ssl socket instance. > > Steps to reproduce: > 1. git clone > https://bitbucket.org/atlassian/cwd-4444-java-bug-reproducer.git > 2. build the code - `cd src/main/java && javac Broken.java Main.java > Working.java` > 3. run the Main class and provide an ldaps url - `java Main > ldaps://example.java:10636` > 4. Observe that when the "Broken" SocketFactory is in use a hostname > verification error occurs. > > Workaround: > Naturally, one can workaround the Connection class's > "preference" for > the no argument createSocket method by not having such a method > in the > SocketFactory set in the ldap environment. > > > Untested potential patch: > --- Connection.java.orig2015-09-25 11:39:26.323117929 +1000 > +++ Connection.java2015-09-25 12:41:04.175068697 +1000 > @@ -33,6 +33,7 @@ > import java.io.InputStream; > import java.net.Socket; > import javax.net.ssl.SSLSocket; > +import javax.net.ssl.SSLSocketFactory; > import javax.naming.CommunicationException; > import javax.naming.ServiceUnavailableException; > @@ -287,7 +288,40 @@ > Method createSocket = null; > - if (connectTimeout > 0) { > + if (connectTimeout > 0 && socketFactoryClass instanceof > SSLSocketFactory) { > + > + try { > + Socket sock = null; > + createSocket = > socketFactoryClass.getMethod("createSocket", > + new Class[]{Socket.class, > String.class, > + int.class, boolean.class}); > + Constructor socketCons = > + Socket.class.getConstructor(new > Class[]{}); > + > + Method connect = > Socket.class.getMethod("connect", > + new > Class[]{Class.forName("java.net.SocketAddress"), > + int.class}); > + Object endpoint = > createInetSocketAddress(host, port); > + > + // unconnected underlying socket > + sock = socketCons.newInstance(new Object[]{}); > + > + if (debug) { > + System.err.println("Connection: > creating socket > with " + > + "a timeout"); > + } > + // connect the underlying socket > + connect.invoke(sock, new Object[]{ > + endpoint, new Integer(connectTimeout)}); > + // connect the ssl socket > + socket = createSocket(sock, host, port, true); > + > + } catch (NoSuchMethodException e) { > + // continue > + } > + } > + > + if (connectTimeout > 0 && socket == null) { > try { > createSocket = > socketFactoryClass.getMethod("createSocket", > > > > [0] > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/7d1d5f4d019a/src/share/classes/com/sun/jndi/ldap/Connection.java#l272 > > -- > David Black / Security Engineer. > > > > -- > David Black / Security Engineer. From tiantian.du at oracle.com Fri Oct 16 08:39:32 2015 From: tiantian.du at oracle.com (Tim Du) Date: Fri, 16 Oct 2015 16:39:32 +0800 Subject: [9] RFR:JDK-8077806:mismatch comment and code in CipherSuite.java Message-ID: <5620B7C4.1010707@oracle.com> Hi All: Please help to review for fixing one comments issue: webrev: http://cr.openjdk.java.net/~fyuan/tim/8077806/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8077806 Thank you very much. Regards Tim From anthony.scarpino at oracle.com Fri Oct 16 17:53:25 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 16 Oct 2015 10:53:25 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <562042D4.3050009@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> <561FF379.3040202@oracle.com> <562042D4.3050009@oracle.com> Message-ID: <56213995.8090703@oracle.com> On 10/15/2015 05:20 PM, Valerie Peng wrote: > Hi Tony, > > Here are the comments for the remaining file. > > > - line 621, is there a particular reason to return immediately when > s.ids is null? If there is, it should be commented here. The > get(ServiceList s) method will fall back to s.type and s.algorithm when > s.ids is null. Would be nice to state the reason for the difference in > implementation. I don't think there is a reason. I suspect it was an odd assumption that testing didn't reveal as a problem.. I'll change it to check type and algorithm if ids is null Going through the code I noticed the get(ServiceList) and get(type, algorithm) methods are not used, so I am removing them. They were there from older code that now uses getAll(...). > - line 698, the method name "compare" seems a little misleading, it only > compares type and algorithm and it returns boolean instead of integer as > the compare in other classes. Maybe names like "lookup" or "match" would > be better... Sure.. > - line 705, there is no check on "t" being non-null, why not use > type.compareToIgnoreCase(t) instead? Yep > - line 710, exact match on algorithm? I thought u will support partial > match, e.g. AES entry matching AES/CBC/PKCS5Padding request. Why don't u > use "toString()" in the debug output as it provides more info. The comment is old, I'll remove "full". The code does check for partial matches because classes like Cipher break up the transformation into pieces (Cipher.getTransforms()) creating many ServiceId's with AES, AES/CBC, AES/CBC/PKCS5Padding, etc. toString() fine. I added it to the previous debug.println too. > - line 722, why is "type" not included in the toString()? You've found a lot of code cleanup that I missed. It was that from from older version of the code before I started checking type. The webrev is updated http://cr.openjdk.java.net/~ascarpino/8133151/webrev.02/ > > Thanks, > Valerie > > On 10/15/2015 11:42 AM, Valerie Peng wrote: >> >> >> - line 58-59, the "[openjdk target cpu architecture]" one should be >> moved up. The optional restricted packages file names are at the end. >> >> >> - for the javadoc changes, the approved CCC has @implNote instead of >> @implSpec. >> Instead of just {@code getProviders}, it seems {@code >> Security.getProviders} is clearer. >> >> >> - line 262 - 267, given that there is an argument specifying provider >> name, I don't think your changes applies to this method. If correct, >> the javadoc change should be removed. >> >> >> - looks fine. >> >> I will continue to look at ProviderList.java and send u comments in a >> separate email. >> Thanks, >> Valerie >> >> On 10/9/2015 10:06 AM, Anthony Scarpino wrote: >>> Ping for a security review.. >>> >>> Tony >>> >>> On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >>>> Hi all, >>>> >>>> I'm need a review of the last developement piece to JEP 246, the >>>> configuration changes. >>>> >>>> I've copied the build-dev in case there were any comments on the minor >>>> changes in the make directory related to the java.security file. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >>>> >>>> thanks >>>> >>>> Tony >>> From valerie.peng at oracle.com Fri Oct 16 22:07:33 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 16 Oct 2015 15:07:33 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <56213995.8090703@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> <561FF379.3040202@oracle.com> <562042D4.3050009@oracle.com> <56213995.8090703@oracle.com> Message-ID: <56217525.20406@oracle.com> Update webrev looks fine, just one nit: ProviderList.java, line 671: The current output seems to suggest that there is a match with the "==" between the two entries. Perhaps something likedebug.println("Config match " + toString() + ": " + t + ", " + a); Since the toString() is already reported on line 671, line 683 doesn't need to repeat this info? Thanks, Valerie On 10/16/2015 10:53 AM, Anthony Scarpino wrote: > On 10/15/2015 05:20 PM, Valerie Peng wrote: >> Hi Tony, >> >> Here are the comments for the remaining file. >> >> >> - line 621, is there a particular reason to return immediately when >> s.ids is null? If there is, it should be commented here. The >> get(ServiceList s) method will fall back to s.type and s.algorithm when >> s.ids is null. Would be nice to state the reason for the difference in >> implementation. > > I don't think there is a reason. I suspect it was an odd assumption > that testing didn't reveal as a problem.. I'll change it to check type > and algorithm if ids is null > > Going through the code I noticed the get(ServiceList) and get(type, > algorithm) methods are not used, so I am removing them. They were > there from older code that now uses getAll(...). > >> - line 698, the method name "compare" seems a little misleading, it only >> compares type and algorithm and it returns boolean instead of integer as >> the compare in other classes. Maybe names like "lookup" or "match" would >> be better... > > Sure.. > >> - line 705, there is no check on "t" being non-null, why not use >> type.compareToIgnoreCase(t) instead? > > Yep > >> - line 710, exact match on algorithm? I thought u will support partial >> match, e.g. AES entry matching AES/CBC/PKCS5Padding request. Why don't u >> use "toString()" in the debug output as it provides more info. > > The comment is old, I'll remove "full". The code does check for > partial matches because classes like Cipher break up the > transformation into pieces (Cipher.getTransforms()) creating many > ServiceId's with AES, AES/CBC, AES/CBC/PKCS5Padding, etc. > > toString() fine. I added it to the previous debug.println too. > >> - line 722, why is "type" not included in the toString()? > > You've found a lot of code cleanup that I missed. It was that from > from older version of the code before I started checking type. > > The webrev is updated > http://cr.openjdk.java.net/~ascarpino/8133151/webrev.02/ > >> >> Thanks, >> Valerie >> >> On 10/15/2015 11:42 AM, Valerie Peng wrote: >>> >>> >>> - line 58-59, the "[openjdk target cpu architecture]" one should be >>> moved up. The optional restricted packages file names are at the end. >>> >>> >>> - for the javadoc changes, the approved CCC has @implNote instead of >>> @implSpec. >>> Instead of just {@code getProviders}, it seems {@code >>> Security.getProviders} is clearer. >>> >>> >>> - line 262 - 267, given that there is an argument specifying provider >>> name, I don't think your changes applies to this method. If correct, >>> the javadoc change should be removed. >>> >>> >>> - looks fine. >>> >>> I will continue to look at ProviderList.java and send u comments in a >>> separate email. >>> Thanks, >>> Valerie >>> >>> On 10/9/2015 10:06 AM, Anthony Scarpino wrote: >>>> Ping for a security review.. >>>> >>>> Tony >>>> >>>> On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >>>>> Hi all, >>>>> >>>>> I'm need a review of the last developement piece to JEP 246, the >>>>> configuration changes. >>>>> >>>>> I've copied the build-dev in case there were any comments on the >>>>> minor >>>>> changes in the make directory related to the java.security file. >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >>>>> >>>>> thanks >>>>> >>>>> Tony >>>> > From anthony.scarpino at oracle.com Fri Oct 16 22:52:59 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 16 Oct 2015 15:52:59 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <56217525.20406@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> <561FF379.3040202@oracle.com> <562042D4.3050009@oracle.com> <56213995.8090703@oracle.com> <56217525.20406@oracle.com> Message-ID: <56217FCB.6090504@oracle.com> I understand what you're saying about it repeating, but like specifying the entry as it gives reassurance which one matched. Since this is only a debug message, I'd prefer to keep it. thanks for the review Tony On 10/16/2015 03:07 PM, Valerie Peng wrote: > > Update webrev looks fine, just one nit: > > ProviderList.java, line 671: The current output seems to suggest that > there is a match with the "==" between the two entries. Perhaps > something likedebug.println("Config match " + toString() + ": " + t + ", > " + a); Since the toString() is already reported on line 671, line 683 > doesn't need to repeat this info? > > Thanks, > Valerie > > On 10/16/2015 10:53 AM, Anthony Scarpino wrote: >> On 10/15/2015 05:20 PM, Valerie Peng wrote: >>> Hi Tony, >>> >>> Here are the comments for the remaining file. >>> >>> >>> - line 621, is there a particular reason to return immediately when >>> s.ids is null? If there is, it should be commented here. The >>> get(ServiceList s) method will fall back to s.type and s.algorithm when >>> s.ids is null. Would be nice to state the reason for the difference in >>> implementation. >> >> I don't think there is a reason. I suspect it was an odd assumption >> that testing didn't reveal as a problem.. I'll change it to check type >> and algorithm if ids is null >> >> Going through the code I noticed the get(ServiceList) and get(type, >> algorithm) methods are not used, so I am removing them. They were >> there from older code that now uses getAll(...). >> >>> - line 698, the method name "compare" seems a little misleading, it only >>> compares type and algorithm and it returns boolean instead of integer as >>> the compare in other classes. Maybe names like "lookup" or "match" would >>> be better... >> >> Sure.. >> >>> - line 705, there is no check on "t" being non-null, why not use >>> type.compareToIgnoreCase(t) instead? >> >> Yep >> >>> - line 710, exact match on algorithm? I thought u will support partial >>> match, e.g. AES entry matching AES/CBC/PKCS5Padding request. Why don't u >>> use "toString()" in the debug output as it provides more info. >> >> The comment is old, I'll remove "full". The code does check for >> partial matches because classes like Cipher break up the >> transformation into pieces (Cipher.getTransforms()) creating many >> ServiceId's with AES, AES/CBC, AES/CBC/PKCS5Padding, etc. >> >> toString() fine. I added it to the previous debug.println too. >> >>> - line 722, why is "type" not included in the toString()? >> >> You've found a lot of code cleanup that I missed. It was that from >> from older version of the code before I started checking type. >> >> The webrev is updated >> http://cr.openjdk.java.net/~ascarpino/8133151/webrev.02/ >> >>> >>> Thanks, >>> Valerie >>> >>> On 10/15/2015 11:42 AM, Valerie Peng wrote: >>>> >>>> >>>> - line 58-59, the "[openjdk target cpu architecture]" one should be >>>> moved up. The optional restricted packages file names are at the end. >>>> >>>> >>>> - for the javadoc changes, the approved CCC has @implNote instead of >>>> @implSpec. >>>> Instead of just {@code getProviders}, it seems {@code >>>> Security.getProviders} is clearer. >>>> >>>> >>>> - line 262 - 267, given that there is an argument specifying provider >>>> name, I don't think your changes applies to this method. If correct, >>>> the javadoc change should be removed. >>>> >>>> >>>> - looks fine. >>>> >>>> I will continue to look at ProviderList.java and send u comments in a >>>> separate email. >>>> Thanks, >>>> Valerie >>>> >>>> On 10/9/2015 10:06 AM, Anthony Scarpino wrote: >>>>> Ping for a security review.. >>>>> >>>>> Tony >>>>> >>>>> On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >>>>>> Hi all, >>>>>> >>>>>> I'm need a review of the last developement piece to JEP 246, the >>>>>> configuration changes. >>>>>> >>>>>> I've copied the build-dev in case there were any comments on the >>>>>> minor >>>>>> changes in the make directory related to the java.security file. >>>>>> >>>>>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >>>>>> >>>>>> thanks >>>>>> >>>>>> Tony >>>>> >> From xuelei.fan at oracle.com Fri Oct 16 23:25:05 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 17 Oct 2015 07:25:05 +0800 Subject: [9] RFR:JDK-8077806:mismatch comment and code in CipherSuite.java In-Reply-To: <5620B7C4.1010707@oracle.com> References: <5620B7C4.1010707@oracle.com> Message-ID: <56218751.2080801@oracle.com> Looks fine to me. Thanks, Xuelei On 10/16/2015 4:39 PM, Tim Du wrote: > Hi All: > > Please help to review for fixing one comments issue: > webrev: http://cr.openjdk.java.net/~fyuan/tim/8077806/webrev/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8077806 > > Thank you very much. > > Regards > Tim From valerie.peng at oracle.com Fri Oct 16 23:44:14 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 16 Oct 2015 16:44:14 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <56217FCB.6090504@oracle.com> References: <560EBA0A.7040808@oracle.com> <5617F41E.6010803@oracle.com> <561FF379.3040202@oracle.com> <562042D4.3050009@oracle.com> <56213995.8090703@oracle.com> <56217525.20406@oracle.com> <56217FCB.6090504@oracle.com> Message-ID: <56218BCD.4060500@oracle.com> Sure. Valerie On 10/16/2015 3:52 PM, Anthony Scarpino wrote: > I understand what you're saying about it repeating, but like > specifying the entry as it gives reassurance which one matched. Since > this is only a debug message, I'd prefer to keep it. > > thanks for the review > > Tony > > > On 10/16/2015 03:07 PM, Valerie Peng wrote: >> >> Update webrev looks fine, just one nit: >> >> ProviderList.java, line 671: The current output seems to suggest that >> there is a match with the "==" between the two entries. Perhaps >> something likedebug.println("Config match " + toString() + ": " + t + ", >> " + a); Since the toString() is already reported on line 671, line 683 >> doesn't need to repeat this info? >> >> Thanks, >> Valerie >> >> On 10/16/2015 10:53 AM, Anthony Scarpino wrote: >>> On 10/15/2015 05:20 PM, Valerie Peng wrote: >>>> Hi Tony, >>>> >>>> Here are the comments for the remaining file. >>>> >>>> >>>> - line 621, is there a particular reason to return immediately when >>>> s.ids is null? If there is, it should be commented here. The >>>> get(ServiceList s) method will fall back to s.type and s.algorithm >>>> when >>>> s.ids is null. Would be nice to state the reason for the difference in >>>> implementation. >>> >>> I don't think there is a reason. I suspect it was an odd assumption >>> that testing didn't reveal as a problem.. I'll change it to check type >>> and algorithm if ids is null >>> >>> Going through the code I noticed the get(ServiceList) and get(type, >>> algorithm) methods are not used, so I am removing them. They were >>> there from older code that now uses getAll(...). >>> >>>> - line 698, the method name "compare" seems a little misleading, it >>>> only >>>> compares type and algorithm and it returns boolean instead of >>>> integer as >>>> the compare in other classes. Maybe names like "lookup" or "match" >>>> would >>>> be better... >>> >>> Sure.. >>> >>>> - line 705, there is no check on "t" being non-null, why not use >>>> type.compareToIgnoreCase(t) instead? >>> >>> Yep >>> >>>> - line 710, exact match on algorithm? I thought u will support partial >>>> match, e.g. AES entry matching AES/CBC/PKCS5Padding request. Why >>>> don't u >>>> use "toString()" in the debug output as it provides more info. >>> >>> The comment is old, I'll remove "full". The code does check for >>> partial matches because classes like Cipher break up the >>> transformation into pieces (Cipher.getTransforms()) creating many >>> ServiceId's with AES, AES/CBC, AES/CBC/PKCS5Padding, etc. >>> >>> toString() fine. I added it to the previous debug.println too. >>> >>>> - line 722, why is "type" not included in the toString()? >>> >>> You've found a lot of code cleanup that I missed. It was that from >>> from older version of the code before I started checking type. >>> >>> The webrev is updated >>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev.02/ >>> >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 10/15/2015 11:42 AM, Valerie Peng wrote: >>>>> >>>>> >>>>> - line 58-59, the "[openjdk target cpu architecture]" one should be >>>>> moved up. The optional restricted packages file names are at the end. >>>>> >>>>> >>>>> - for the javadoc changes, the approved CCC has @implNote instead of >>>>> @implSpec. >>>>> Instead of just {@code getProviders}, it seems {@code >>>>> Security.getProviders} is clearer. >>>>> >>>>> >>>>> - line 262 - 267, given that there is an argument specifying provider >>>>> name, I don't think your changes applies to this method. If correct, >>>>> the javadoc change should be removed. >>>>> >>>>> >>>>> - looks fine. >>>>> >>>>> I will continue to look at ProviderList.java and send u comments in a >>>>> separate email. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 10/9/2015 10:06 AM, Anthony Scarpino wrote: >>>>>> Ping for a security review.. >>>>>> >>>>>> Tony >>>>>> >>>>>> On 10/02/2015 10:08 AM, Anthony Scarpino wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I'm need a review of the last developement piece to JEP 246, the >>>>>>> configuration changes. >>>>>>> >>>>>>> I've copied the build-dev in case there were any comments on the >>>>>>> minor >>>>>>> changes in the make directory related to the java.security file. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>>>>> >>> > From anthony.scarpino at oracle.com Mon Oct 19 21:13:51 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 19 Oct 2015 14:13:51 -0700 Subject: RFR 8139860: Add ucrypto/TestRSA.java to ProblemList: Message is larger than modulus Message-ID: <56255D0F.1040603@oracle.com> Hi, I need a review of an addition to the ProblemList. http://cr.openjdk.java.net/~ascarpino/8139860/webrev/ The relates to SunRSASign bug found (8139859) which showed up during test of Preferred Provider changes.. thanks Tony From xuelei.fan at oracle.com Mon Oct 19 23:50:07 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 20 Oct 2015 07:50:07 +0800 Subject: RFR 8139860: Add ucrypto/TestRSA.java to ProblemList: Message is larger than modulus In-Reply-To: <56255D0F.1040603@oracle.com> References: <56255D0F.1040603@oracle.com> Message-ID: <562581AF.4030508@oracle.com> Looks fine to me. Xuelei On 10/20/2015 5:13 AM, Anthony Scarpino wrote: > Hi, > > I need a review of an addition to the ProblemList. > > http://cr.openjdk.java.net/~ascarpino/8139860/webrev/ > > The relates to SunRSASign bug found (8139859) which showed up during > test of Preferred Provider changes.. > > thanks > > Tony From jdk-security-dev at whittington.net.nz Wed Oct 21 18:52:01 2015 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Thu, 22 Oct 2015 07:52:01 +1300 Subject: Problems with CipherBox and AEAD In-Reply-To: <561C6909.2020305@oracle.com> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> <561A16DA.5020301@suche.org> <561C6909.2020305@oracle.com> Message-ID: <891B735C-2829-454E-AE1D-BB06FA943FDA@whittington.net.nz> An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Oct 21 23:04:36 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Oct 2015 07:04:36 +0800 Subject: Problems with CipherBox and AEAD In-Reply-To: <891B735C-2829-454E-AE1D-BB06FA943FDA@whittington.net.nz> References: <6397F2F0-84EE-4479-B309-C55772471C2F@oracle.com> <5617015B.1010606@oracle.com> <21933BAD-681E-4114-AD50-15F14C6CAED6@oracle.com> <561A16DA.5020301@suche.org> <561C6909.2020305@oracle.com> <891B735C-2829-454E-AE1D-BB06FA943FDA@whittington.net.nz> Message-ID: <56281A04.7050102@oracle.com> On 10/22/2015 2:52 AM, Tim Whittington wrote: > draft-agl-tls-chacha20poly1305-04 moved on (incompatibly) to > https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls, which > has since moved on to > https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00. > Yes. Good that the new proposal follow RFC 5116 specification, and does not use zero fixedIv any more. Thanks, Xuelei > tim > >> On 13/10/2015, at 3:14 PM, Xuelei Fan wrote: >> >> Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC? >> Looks like the proposal was not moving forward since May, 2014. >> >> https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 >> >> Thanks, >> Xuelei >> >> On 10/11/2015 3:59 PM, Thomas Lu?nig wrote: >>> Hi, >>> >>> when i extends "sun.security.ssl.CipherSuite" with >>> final static BulkCipher B_CHACHA20_POLY1305 = new >>> BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 0, 0, true ); >>> i found an Problem in "sun.security.ssl.CipherBox >>> Method "applyExplicitNonce" there for the AEAD_CIPHER case is an NPE if >>> the IV Length is zero. Then fixedIv become null >>> and there is an NPE. The Workaround for this is >>> final byte[] iv; >>> if(this.fixedIv == null) { // FIX for CHACHA >>> iv = new byte[this.recordIvSize]; // CHACHA fix >>> bb.get(iv, 0, this.recordIvSize); >>> } else { >>> iv = Arrays.copyOf(this.fixedIv, this.fixedIv.length + >>> this.recordIvSize); >>> bb.get(iv, this.fixedIv.length, this.recordIvSize); >>> } >>> Another problem would occour if i use "new >>> BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 8, 8, true );" >>> Then in createExplicitNonce the nonce should become zero size but is >>> fixed length for AEAD of 8 bytes. >>> Both was seen in JDK-1.8.0_60 >>> >>> Gru? Thomas Lu?nig >>> >> > From mark.sheppard at oracle.com Sun Oct 25 23:32:09 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Sun, 25 Oct 2015 23:32:09 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor Message-ID: <562D6679.9090509@oracle.com> Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been "eliminate". As such, the interface and service descriptor sun.net.spi.nameservice.NameService sun.net.spi.nameservice.NameServiceDescriptor* *together with its implementation (sun.net.nameservice.dns.DNSNameService) has been remove from the JDK libraries. The immediate impact is seen in the JDK testing framework. To facilitate testing activity, and provide a replacement for the customized NameService implementations in the JDK tests, the default NameService has been extended to support the retrieval of host to IP address mappings from a file. The file path is specified with a system property " jdk.internal.hosts". Previously a nameservice provider was specified by setting the system property "sun.net.spi.nameservice.provider.", as per the documentation http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html InetAddress now tests to determine if this property is set and will throw a ServiceConfigurationError indicating that this functionality is no longer supported. The choice of ServideConfigurationError may cause some debate, or disagreement. The rationale was that InternalError, is documented to relate to a JVM error, and javax.naming.NamingException has a context of DirContext. A possible alternative candidate could be javax.naming.ServiceUnavailableException. As such, the setting of the property "sun.net.spi.nameservice.provider." was used, previously, as a configuration parameter for the loading of a NamerService service provider, and as this is now (considered) an error, ServiceConfigurationError, seemed a best fit! These changes impacted a number of jdk security tests, also. The affected tetsts have been amended to adopt the changes, with the exception of test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java which will require some rewrite. regards Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Mon Oct 26 00:24:07 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 26 Oct 2015 03:24:07 +0300 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <562D6679.9090509@oracle.com> References: <562D6679.9090509@oracle.com> Message-ID: <562D72A7.1040302@oracle.com> Hi Mark, I am not a reviewer, just have a couple of comments about InetAddress.java 1. It may be better to create an instance of Scanner in try-with-resource block to be sure that Scanner.close() method is called. 2. Lines 909-923: There are two similar "if" blocks in the loop. Looks like the first one is not necessary (I also see similar code in lookupAllHostAddr() method, maybe this code could be moved to a separate method). 3. extractHostAddr() and extractHost() methods: The methods assume that "hostEntry" contains at least one whitespace, and access first and second elements of "mapping " array. It may be better to check that length of "mapping" is more than one to avoid a possible ArrayIndexOutOfBoundsException. Looks like those methods may also be static. Artem On 10/26/2015 02:32 AM, Mark Sheppard wrote: > Hi, > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8134577/webrev/ > > which address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8134577 > > the operative word has been "eliminate". > As such, the interface and service descriptor > sun.net.spi.nameservice.NameService > sun.net.spi.nameservice.NameServiceDescriptor* > *together with its implementation (sun.net.nameservice.dns.DNSNameService) > has been remove from the JDK libraries. > > The immediate impact is seen in the JDK testing framework. > > To facilitate testing activity, and provide a replacement for the > customized NameService implementations in the > JDK tests, the default NameService has been extended to support > the retrieval of host to IP address mappings from a file. > The file path is specified with a system property " jdk.internal.hosts". > > Previously a nameservice provider was specified by setting the system > property > "sun.net.spi.nameservice.provider.", as per the documentation > http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html > > InetAddress now tests to determine if this property is set and will > throw a ServiceConfigurationError > indicating that this functionality is no longer supported. The choice > of ServideConfigurationError may cause > some debate, or disagreement. The rationale was that InternalError, > is documented to relate to a JVM error, > and javax.naming.NamingException has a context of DirContext. > A possible alternative candidate could be > javax.naming.ServiceUnavailableException. > As such, the setting of the property > "sun.net.spi.nameservice.provider." was used, previously, as a > configuration > parameter for the loading of a NamerService service provider, and as > this is now (considered) an error, ServiceConfigurationError, > seemed a best fit! > > These changes impacted a number of jdk security tests, also. The > affected tetsts have been amended to adopt the > changes, with the exception of > test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java > which will require some rewrite. > > regards > Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Oct 26 01:57:23 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 26 Oct 2015 09:57:23 +0800 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <562D72A7.1040302@oracle.com> References: <562D6679.9090509@oracle.com> <562D72A7.1040302@oracle.com> Message-ID: I see a lot of krb5 tests modified. Basically, the NameServiceDescriptor inside KDC.java maps everything to localhost except for one (I guess Artem invented the 2nd feature). Can we expand the grammar a little bit to support this? For example: not.existing.host UnknownHostException * 127.0.0.1 I see you've added all names the tests have touched in test/sun/security/krb5/auto/hosts, but I am not sure if we might add randomly generated hostnames in any test later. BTW, the standard /etc/hosts has lines like "127.0.0.1 localhost" which has a different order than yours. Shall we rename hosts to something else so that people does not get confused? Thanks Max >> http://cr.openjdk.java.net/~msheppar/8134577/webrev/ >> >> which address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8134577 >> From volker.simonis at gmail.com Mon Oct 26 14:32:35 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 26 Oct 2015 15:32:35 +0100 Subject: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64 Message-ID: Hi, can somebody please review the following trivial fix to enable the pkcs11 tests for linux/ppc64: http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/ https://bugs.openjdk.java.net/browse/JDK-8140514 The pkcs11 tests need to load the native library libnss3.so the location of which is system dependent. Until now, the test didn't consider Linux/ppc64 systems. The fix is simple: just add a corresponding map entry which maps the platform to the correct library path. All the systems I've checked (various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so under /usr/lib64. Thank you and best regards, Volker From anthony.scarpino at oracle.com Mon Oct 26 18:25:25 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 26 Oct 2015 11:25:25 -0700 Subject: RFR: 8139859 :TestRSA.java: 'message larger than modulus' using SunRsaSign KeyFactory Message-ID: <562E7015.4080300@oracle.com> Hi I need a review of this test change that makes TestRSA.java work properly after the Preferred Provider code push. I also added some extra testing to make sure it runs in more situations. http://cr.openjdk.java.net/~ascarpino/8139859/webrev/ thanks Tony From mark.sheppard at oracle.com Tue Oct 27 12:22:15 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 27 Oct 2015 12:22:15 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <562D72A7.1040302@oracle.com> References: <562D6679.9090509@oracle.com> <562D72A7.1040302@oracle.com> Message-ID: <562F6C77.6000805@oracle.com> Hi Artem, thanks for the feedback, I'll make the changes for 2 & 3. I'll look into rework of try-with-resources. regards Mark On 26/10/2015 00:24, Artem Smotrakov wrote: > Hi Mark, > > I am not a reviewer, just have a couple of comments about InetAddress.java > > 1. It may be better to create an instance of Scanner in > try-with-resource block to be sure that Scanner.close() method is called. > > 2. Lines 909-923: > > There are two similar "if" blocks in the loop. Looks like the first > one is not necessary (I also see similar code in lookupAllHostAddr() > method, maybe this code could be moved to a separate method). > > 3. extractHostAddr() and extractHost() methods: > > The methods assume that "hostEntry" contains at least one whitespace, > and access first and second elements of "mapping " array. It may be > better to check that length of "mapping" is more than one to avoid a > possible ArrayIndexOutOfBoundsException. > > Looks like those methods may also be static. > > Artem > > On 10/26/2015 02:32 AM, Mark Sheppard wrote: >> Hi, >> please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8134577/webrev/ >> >> which address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8134577 >> >> the operative word has been "eliminate". >> As such, the interface and service descriptor >> sun.net.spi.nameservice.NameService >> sun.net.spi.nameservice.NameServiceDescriptor* >> *together with its implementation >> (sun.net.nameservice.dns.DNSNameService) >> has been remove from the JDK libraries. >> >> The immediate impact is seen in the JDK testing framework. >> >> To facilitate testing activity, and provide a replacement for the >> customized NameService implementations in the >> JDK tests, the default NameService has been extended to support >> the retrieval of host to IP address mappings from a file. >> The file path is specified with a system property " jdk.internal.hosts". >> >> Previously a nameservice provider was specified by setting the system >> property >> "sun.net.spi.nameservice.provider.", as per the documentation >> http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html >> >> InetAddress now tests to determine if this property is set and will >> throw a ServiceConfigurationError >> indicating that this functionality is no longer supported. The choice >> of ServideConfigurationError may cause >> some debate, or disagreement. The rationale was that InternalError, >> is documented to relate to a JVM error, >> and javax.naming.NamingException has a context of DirContext. >> A possible alternative candidate could be >> javax.naming.ServiceUnavailableException. >> As such, the setting of the property >> "sun.net.spi.nameservice.provider." was used, previously, as a >> configuration >> parameter for the loading of a NamerService service provider, and as >> this is now (considered) an error, ServiceConfigurationError, >> seemed a best fit! >> >> These changes impacted a number of jdk security tests, also. The >> affected tetsts have been amended to adopt the >> changes, with the exception of >> test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java >> which will require some rewrite. >> >> regards >> Mark >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Oct 27 18:02:07 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Oct 2015 19:02:07 +0100 Subject: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64 In-Reply-To: References: Message-ID: Resend to core-libs-dev to attract a broader audience :) On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis wrote: > Hi, > > can somebody please review the following trivial fix to enable the > pkcs11 tests for linux/ppc64: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/ > https://bugs.openjdk.java.net/browse/JDK-8140514 > > The pkcs11 tests need to load the native library libnss3.so the > location of which is system dependent. Until now, the test didn't > consider Linux/ppc64 systems. > > The fix is simple: just add a corresponding map entry which maps the > platform to the correct library path. All the systems I've checked > (various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so > under /usr/lib64. > > Thank you and best regards, > Volker From mark.sheppard at oracle.com Tue Oct 27 20:56:25 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 27 Oct 2015 20:56:25 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: References: <562D6679.9090509@oracle.com> <562D72A7.1040302@oracle.com> Message-ID: <562FE4F9.1080205@oracle.com> Hi Max, thanks for the reply. I'll change the hosts file names used to correspond with an associated test dynamic update of host / ip mappings updates are accommodated as seen per the tests http://cr.openjdk.java.net/~msheppar/8134577/webrev/test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java.sdiff.html http://cr.openjdk.java.net/~msheppar/8134577/webrev/test/sun/net/InetAddress/nameservice/simple/CacheTest.java.sdiff.html yes, that's correct the structure of hosts file does not align with /etc/hosts (ip address list of aliases), it aligns with the various customized NameService implementations in the test framework. I'll look into the UnknownHostException suggestion regards Mark On 26/10/2015 01:57, Wang Weijun wrote: > I see a lot of krb5 tests modified. > > Basically, the NameServiceDescriptor inside KDC.java maps everything to localhost except for one (I guess Artem invented the 2nd feature). Can we expand the grammar a little bit to support this? For example: > > not.existing.host UnknownHostException > * 127.0.0.1 > > I see you've added all names the tests have touched in test/sun/security/krb5/auto/hosts, but I am not sure if we might add randomly generated hostnames in any test later. > > BTW, the standard /etc/hosts has lines like "127.0.0.1 localhost" which has a different order than yours. Shall we rename hosts to something else so that people does not get confused? > > Thanks > Max > >>> http://cr.openjdk.java.net/~msheppar/8134577/webrev/ >>> >>> which address the issue raised in >>> https://bugs.openjdk.java.net/browse/JDK-8134577 >>> From weijun.wang at oracle.com Thu Oct 29 02:08:20 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 29 Oct 2015 10:08:20 +0800 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <562FE4F9.1080205@oracle.com> References: <562D6679.9090509@oracle.com> <562D72A7.1040302@oracle.com> <562FE4F9.1080205@oracle.com> Message-ID: <8D6810A3-EC43-4725-9EA3-C2CAC282FD04@oracle.com> > On Oct 28, 2015, at 4:56 AM, Mark Sheppard wrote: > > dynamic update of host / ip mappings updates are accommodated as seen per the tests > http://cr.openjdk.java.net/~msheppar/8134577/webrev/test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java.sdiff.html > http://cr.openjdk.java.net/~msheppar/8134577/webrev/test/sun/net/InetAddress/nameservice/simple/CacheTest.java.sdiff.html Oh, I would say the old SimpleNameService class is quite good. Since the current fix is meant for test only and the new system property is called jdk.internal something, can we just introduce an internal method that looks like SimpleNameService? Who wants to use it can add "@modules java.base/jdk.internal.net.SimpleNameService". Yes I know this is quite against API encapsulation, but so is the internal system property. Thanks Max From bradford.wetmore at oracle.com Thu Oct 29 21:12:49 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 29 Oct 2015 14:12:49 -0700 Subject: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64 In-Reply-To: References: Message-ID: <56328BD1.5030502@oracle.com> Most of us have been at JavaOne this week. Looks ok to me. Brad On 10/27/2015 11:02 AM, Volker Simonis wrote: > Resend to core-libs-dev to attract a broader audience :) > > On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis > wrote: >> Hi, >> >> can somebody please review the following trivial fix to enable the >> pkcs11 tests for linux/ppc64: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/ >> https://bugs.openjdk.java.net/browse/JDK-8140514 >> >> The pkcs11 tests need to load the native library libnss3.so the >> location of which is system dependent. Until now, the test didn't >> consider Linux/ppc64 systems. >> >> The fix is simple: just add a corresponding map entry which maps the >> platform to the correct library path. All the systems I've checked >> (various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so >> under /usr/lib64. >> >> Thank you and best regards, >> Volker From bradford.wetmore at oracle.com Thu Oct 29 21:17:20 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 29 Oct 2015 14:17:20 -0700 Subject: RFR: 8139859 :TestRSA.java: 'message larger than modulus' using SunRsaSign KeyFactory In-Reply-To: <562E7015.4080300@oracle.com> References: <562E7015.4080300@oracle.com> Message-ID: <56328CE0.6090301@oracle.com> Looks good. Brad On 10/26/2015 11:25 AM, Anthony Scarpino wrote: > Hi > > I need a review of this test change that makes TestRSA.java work > properly after the Preferred Provider code push. I also added some > extra testing to make sure it runs in more situations. > > http://cr.openjdk.java.net/~ascarpino/8139859/webrev/ > > thanks > > Tony >