Re: RFR 7191662: JCE providers should be located via ServiceLoader
Hello Valerie, The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. /Erik On 2015-06-04 23:58, Valerie Peng wrote: Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. Thanks, Valerie On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: On 2015-05-29 00:10, Valerie Peng wrote: Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. I’ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus . Mandy On May 27, 2015, at 3:29 PM, Valerie Pengvalerie.p...@oracle.com wrote: Hi, build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. The rest of source code changes are reviewed by my team already. Thanks, Valerie (Java Security Team)
Re: TLS ALPN Proposal v2
I've just noticed the SSLParameters.setUseCipherSuitesOrder() method. I guess this can be used to enforce a higher priority for the h2 compatible ciphers on the server side. On the new API, I'm not sure about the SSLBase, SSLFunction construct either. I don't think it is very clear, and if its purpose is just to allow use of lambdas, then I think the original approach was better. Michael. On 05/06/15 05:11, Xuelei Fan wrote: Hi, See inlines, please. On 6/5/2015 5:30 AM, Simone Bordet wrote: Hi, On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan xuelei@oracle.com wrote: Hm, I see your point now. But I may not agree with your ALPN MUST happen after protocol/cipher suite negotiation conclusion. I parse this section as, a H2 server must be strong enough(comply to RFC7540), and a H2 client must also be strong enough (comply to RFC7540). Otherwise, both side may terminated the connection, and cannot declare as complying to H2. It is not necessary for an application protocol selector to detect whether a H2 server/client comply to H2 or not. If H2 is requested, it means that the client supports H2. Otherwise, it's a client application bug. Not that simple, see below. If H2 is selected by a selected, it means that the selected server supports H2. Otherwise, it is a selector implementation bug. If something wrong in either client or server, it is expected to terminate the connection immediately, rather than downgrade to a not-strong enough level. From the points above, I think an application protocol selector may not need to know the negotiated protocol version and cipher suite. No. The client may send ciphers that are valid for http/1.1 (but invalid for h2), along with ciphers that are good for h2 (as well as http/1.1 of course), plus the list of protocols it supports. The client has no idea what the server supports. I think it should be true that if a client requests h2, the client MUST support H2 and the requested cipher suites MUST contains at least one H2 required cipher suite. Otherwise, it's bug in client side. When the server sees that the client supports h2, it MUST pick a cipher that is valid for h2. Alternatively, the ciphers on the server are sorted so that those valid for h2 have higher priority (they are attempted before all the others), so that there is a high chance that a h2 valid cipher is chosen (but no guarantee) before choosing the application protocol. When the application protocol selector callback is invoked, it can only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback to http/1.1. I think it should be true that if a server can negotiate h2, the server MUST support H2 and the enabled cipher suites MUST contains at least one H2 required cipher suite. Otherwise, it's bug in server side. It's instinctive that if a server support h2, and then the application protocol selector would select h2. If the server declare to support h2, but no suitable cipher suites, it may be a server bug. The connection should be terminated rather than downgrade to HTTP/1.1, I think. Is it possible that client only request h2_valid_cipher_a, but server only support h2_valid_cipher_b, and as would result in that there is no common cipher suites between client and server for H2? It is possible, surely. Should the connection be terminated, or fall-back to HTTP/1.1? I think connection should be terminated immediately, rather than fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST be supported in both client and server. If there is no common cipher suites between client and server for H2, it is actually a bad deployments, and the connection should be terminated rather than fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. With your reasoning, the client can send [h2_invalid_cipher, h2_valid_cipher], the server may pick h2_invalid_cipher, then the application protocol selector is invoked, which will only look at the protocols, pick h2 since it's supported by client and server, and now you have an invalid connection: the h2 protocol with h2_invalid_cipher. That's an interesting case. The question actually is: between requested application protocols and cipher suites, which preference should be respected at first. Because it is a application requirement that a certain cipher suite is not suitable to H2, I think requested application protocols should be respected at first. My scenarios look like: 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 application protocol. 2. server selects h2 (we need an API for the selection). 3. server selects h2_valid_cipher because of h2 is selected previously (may need an API for the selection). In #1, if there is no h2_valid_cipher requested, it is a bug in client side. In #3, if there is no h2_valid_cipher that can be negotiated, it is a bug in server side, or the client does not enabled the
RFR [9] 8081517: minor cleanup for docs
Hello, Could you please review the fix http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8081517 Just some cleanup for docs. Thanks, Alexander
Re: TLS ALPN Proposal v2
See more inlines, please. Please help on one question I'm not sure of. Per HTTP/2 specification, Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2 connection? I did not find the answer from RFC 7540. In TLS, if client requests to negotiate TLS v1.2, and server supports TLS 1.2, it is not allowed to fallback to TLS v1.1. If there is not suitable cipher suite to negotiate TLS 1.2, the connection would be terminated immediately. I'm not sure what's the spec for HTTP/2, HTTP/1.1 and HTTP/1.0. On 6/5/2015 4:05 PM, Simone Bordet wrote: Hi, On Fri, Jun 5, 2015 at 6:11 AM, Xuelei Fan xuelei@oracle.com wrote: I think it should be true that if a server can negotiate h2, the server MUST support H2 and the enabled cipher suites MUST contains at least one H2 required cipher suite. Otherwise, it's bug in server side. It's instinctive that if a server support h2, and then the application protocol selector would select h2. If the server declare to support h2, but no suitable cipher suites, it may be a server bug. The connection should be terminated rather than downgrade to HTTP/1.1, I think. The server may support h2, but there is no valid h2 cipher in common with the client, so it's not a server bug. Per RFC 7540, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a mandatory cipher suite for H2. The case is not expected that there is no cipher in common. It's a fatal error if there is no cipher in common. In that case, client and server cannot speak h2, but nothing forbids them to speak http/1.1. It would be really bad for the user experience if both client and server could speak http/1.1, but they don't just because they can't speak h2. They would appear like spoiled children :) The point of ALPN is to *negotiate* a protocol, not to give up on the first failure. I cannot agree, ALPN is not a mechanism to tolerant incorrect protocol implementation. If H2 is bad implemented or bad deployed, terminate the connection, rather than fallback to HTTP/1.1 is a better and safer user experience. Is it possible that client only request h2_valid_cipher_a, but server only support h2_valid_cipher_b, and as would result in that there is no common cipher suites between client and server for H2? It is possible, surely. Should the connection be terminated, or fall-back to HTTP/1.1? I think connection should be terminated immediately, rather than fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST be supported in both client and server. If there is no common cipher suites between client and server for H2, it is actually a bad deployments, and the connection should be terminated rather than fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. That is not what the 7540 expert group thinks, certainly not what browsers do, and certainly not what servers do. The behavior is to speak http/1.1 (or the next protocol that fits). Hm, that what I want to know. Do you mean that RFC 7540 expect a H2 server fall-back to HTTP/1.1 from HTTP/2 request? See also my question in the beginning. Per my understanding, if server does not support H2, downgrade to use HTTP/1.1 is allowed. But if the server supports H2, is it still allowed to use HTTP/1.1? That may be the key for our discussion. That's an interesting case. The question actually is: between requested application protocols and cipher suites, which preference should be respected at first. Because it is a application requirement that a certain cipher suite is not suitable to H2, I think requested application protocols should be respected at first. My scenarios look like: 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 application protocol. 2. server selects h2 (we need an API for the selection). 3. server selects h2_valid_cipher because of h2 is selected previously (may need an API for the selection). Does not work. How do you know that server has h2_valid_cipher available ? If it does not, you have picked h2, and an invalid cipher (breaks 7540), or you terminate the connection while instead you could speak http/1.1. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a mandatory cipher suite for H2. Per RFC 7540, ... To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256 elliptic curve In #1, if there is no h2_valid_cipher requested, it is a bug in client side. In #3, if there is no h2_valid_cipher that can be negotiated, it is a bug in server side, or the client does not enabled the mandatory cipher suite (a bug in client). Does not work. The client may be using TLS 1.4, where that mandatory cipher suite (it's mandatory only for TLS 1.2 deployments) has been removed because insecure. There is no bug on either side, just no cipher in
Re: RFR [9] 8081517: minor cleanup for docs
Hi Alxander
Overall. looks OK. A couple of things I thought could be changed;
In FTPURLConnection, I probably would surround the code in an {@code} tag
In VmIdentifier, I do not see think we still need p in the LI tags
Best
Lance
On Jun 5, 2015, at 8:51 AM, alexander stepanov
alexander.v.stepa...@oracle.com wrote:
Hello,
Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8081517
Just some cleanup for docs.
Thanks,
Alexander
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Re: TLS ALPN Proposal v2
Hi, On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan xuelei@oracle.com wrote: See more inlines, please. Please help on one question I'm not sure of. Per HTTP/2 specification, Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2 connection? I did not find the answer from RFC 7540. Yes. The intended behavior is exactly to fall back to http/1.1 if h2 cannot be negotiated. This is implicitly explained in the ALPN spec, RFC 7301, see http://tools.ietf.org/html/rfc7301#section-3.2. In TLS, if client requests to negotiate TLS v1.2, and server supports TLS 1.2, it is not allowed to fallback to TLS v1.1. If there is not suitable cipher suite to negotiate TLS 1.2, the connection would be terminated immediately. I'm not sure what's the spec for HTTP/2, HTTP/1.1 and HTTP/1.0. HTTP/2 does not behave like TLS in this sense. ALPN is for *application* protocol selection. A client can send: [h2, spdy/3.1, http/1.1] Failing h2, spdy/3.1 is attempted, which is a completely different protocol, with different restrictions, etc. Per RFC 7540, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a mandatory cipher suite for H2. No. It's a mandatory cipher for *TLS 1.2 deployments only*. If the client uses TLS 1.4 does not have to have that cipher, and hence there can be an empty intersection of ciphers with the server. That cipher is only mentioned because all the mandatory TLS 1.2 ciphers have been blacklisted by HTTP/2. If TLS 1.3 was specified before HTTP/2, that cipher would not even be mentioned, and the HTTP/2 spec would have referenced only TLS 1.3 as mandatory: no black lists, no special cipher. The TLS and HTTP specifications will evolve independently, and there cannot be a requirement that whenever TLS changes, an update to HTTP/2 must be published. Hope this clarifies. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
RFR: 8077418: StackOverflowError during PolicyFile lookup
A regression has been discovered after JDK-8058547 was fixed in 8u60. For now, I'm proposing we back the fix out from the jdk8u-dev forest and plan a new fix. This is a straight-forward anti delta of 8058547 JDK 9 is not impacted since JDK-8055753 already removed this code. bug : https://bugs.openjdk.java.net/browse/JDK-8077418 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077418.8u/webrev/ -- Regards, Sean.
Re: TLS ALPN Proposal v2
On 6/5/2015 11:16 PM, Simone Bordet wrote: Hi, On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan xuelei@oracle.com wrote: If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not supported HTTP/1.1 would be attempted. Correct. If H2 is supported in both side, but H2 does not work, it is a H2 problem that need to be addressed in H2 layer. If both client and server have h2 as a potentially supported protocol, but the cipher to use h2 is not valid, then h2 is not supported for that particular connection. At that point, like you said above, spdy/3.1 is attempted, and so on. ;-) That's the point we cannot agree with each other at present. No application protocol fallback in TLS layer if the application protocol is supported. Your interpretation of supported is not what browser and server implementors mean :) ;-) maybe. It's not my expertise. I understand your concerns now. I think we have different understanding of the ALPN protocols. It's a good thing to understand the actually requirements of the industry, I think. Thank you! So where does this leave us know ? ;-) I think Brad would consider our information for his design. By the way, while I have participated in the RFC 7540 discussions, and implemented HTTP/2 in Jetty to be interoperable with a variety of other clients and servers, feel free to ask clarifications to the RFC 7540 and RFC 7301 mailing lists, or even directly to the editors of those RFCs; they are typically open to answer questions, I guess especially so if they come from the OpenJDK team that is implementing those specification. Yes. It would be help to know the implementation of other SSL/TLS vendors, too. Thanks, Xuelei
Re: JEP 232 RFR: JDK-8065942 and JDK-8056179
Hi Sean
Everything is fine, some comments:
FilePermission (also in SocketPermission, PropertyPermission,
ServicePermission):
int oldMask = ((FilePermission)existingVal).getMask();
int newMask = ((FilePermission)newVal).getMask();
if (oldMask != newMask) {
int effective = oldMask | newMask;
if (effective != oldMask) {
return new FilePermission(fp.getName(), effective);
}
}
return existingVal;
Is it worth checking if (effective == newMask)? Then you can return
newVal without creating a new FilePermission object.
SocketPermission:
JDK-431064? There should be 7 digits.
UnresolvedPermissionCollection:
The use of CopyOnWriteArrayList is cool, but add(up) right after an
empty one is created seems like an unnecessary copy-on-write. Maybe we
can file an RFE on CopyOnWriteArrayList itself?
The newly added tests are great, but are they already covered by JCK or
shall we contribute them to JCK?
Thanks
Max
On 06/04/2015 04:38 AM, Sean Mullan wrote:
This is the third and fourth in a series of fixes for JEP 232 (Improve
Secure Application Performance) [1].
webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/
bugs: https://bugs.openjdk.java.net/browse/JDK-8065942 and
https://bugs.openjdk.java.net/browse/JDK-8056179
This fix changes the Permissions and PermissionCollection subclasses to
use concurrent collections, which significantly reduces contention when
multiple threads are performing security checks. The bugs needed to be
fixed together, because removing the synchronized blocks in Permissions
revealed that several of the underlying PermissionCollection
implementations were not thread-safe.
Several new unit tests were also added to test basic functionality of
these classes.
With these fixes, the throughput of the Permissions.implies method
improves from approximately 6x to 10x when more than one thread is
running. Each of the bugs contains a performance chart with more details.
Thanks,
Sean
[1] http://openjdk.java.net/jeps/232
RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC
Looking to resolve a recently reported issue where the P11ECKeyFactory class has too much dependence on the SunEC provider. With some reshuffling and creation of a new P11ECUtil class, I was able to remove the call for lookup of SunEC Provider. The test picks up the regression when running with the SunPKCS11-NSS provider. bug report : https://bugs.openjdk.java.net/browse/JDK-8080102 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ -- Regards, Sean.
Re: TLS ALPN Proposal v2
Hi, On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan xuelei@oracle.com wrote: If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not supported HTTP/1.1 would be attempted. Correct. If H2 is supported in both side, but H2 does not work, it is a H2 problem that need to be addressed in H2 layer. If both client and server have h2 as a potentially supported protocol, but the cipher to use h2 is not valid, then h2 is not supported for that particular connection. At that point, like you said above, spdy/3.1 is attempted, and so on. No application protocol fallback in TLS layer if the application protocol is supported. Your interpretation of supported is not what browser and server implementors mean :) I understand your concerns now. I think we have different understanding of the ALPN protocols. It's a good thing to understand the actually requirements of the industry, I think. Thank you! So where does this leave us know ? By the way, while I have participated in the RFC 7540 discussions, and implemented HTTP/2 in Jetty to be interoperable with a variety of other clients and servers, feel free to ask clarifications to the RFC 7540 and RFC 7301 mailing lists, or even directly to the editors of those RFCs; they are typically open to answer questions, I guess especially so if they come from the OpenJDK team that is implementing those specification. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: JEP 232 RFR: JDK-8065942 and JDK-8056179
Thanks for the comments, Max. Replies below ...
On 06/05/2015 11:44 AM, Weijun Wang wrote:
Hi Sean
Everything is fine, some comments:
FilePermission (also in SocketPermission, PropertyPermission,
ServicePermission):
int oldMask = ((FilePermission)existingVal).getMask();
int newMask = ((FilePermission)newVal).getMask();
if (oldMask != newMask) {
int effective = oldMask | newMask;
if (effective != oldMask) {
return new FilePermission(fp.getName(), effective);
}
}
return existingVal;
Is it worth checking if (effective == newMask)? Then you can return
newVal without creating a new FilePermission object.
Yes - very good point, will change that.
SocketPermission:
JDK-431064? There should be 7 digits.
Oops, should be 4301064, will fix.
UnresolvedPermissionCollection:
The use of CopyOnWriteArrayList is cool, but add(up) right after an
empty one is created seems like an unnecessary copy-on-write. Maybe we
can file an RFE on CopyOnWriteArrayList itself?
Yeah maybe. An alternative is:
new CopyOnWriteArrayList(Collections.singletonList(up));
but it seems a bit like overkill.
The newly added tests are great, but are they already covered by JCK or
shall we contribute them to JCK?
I'll take a look, but this area is lacking in regression tests, so some
duplication I think is ok.
--Sean
Thanks
Max
On 06/04/2015 04:38 AM, Sean Mullan wrote:
This is the third and fourth in a series of fixes for JEP 232 (Improve
Secure Application Performance) [1].
webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/
bugs: https://bugs.openjdk.java.net/browse/JDK-8065942 and
https://bugs.openjdk.java.net/browse/JDK-8056179
This fix changes the Permissions and PermissionCollection subclasses to
use concurrent collections, which significantly reduces contention when
multiple threads are performing security checks. The bugs needed to be
fixed together, because removing the synchronized blocks in Permissions
revealed that several of the underlying PermissionCollection
implementations were not thread-safe.
Several new unit tests were also added to test basic functionality of
these classes.
With these fixes, the throughput of the Permissions.implies method
improves from approximately 6x to 10x when more than one thread is
running. Each of the bugs contains a performance chart with more details.
Thanks,
Sean
[1] http://openjdk.java.net/jeps/232
Re: RFR: 8077418: StackOverflowError during PolicyFile lookup
Looks good. Please add noreg-other label to bug. --Sean On 06/05/2015 01:37 PM, Seán Coffey wrote: A regression has been discovered after JDK-8058547 was fixed in 8u60. For now, I'm proposing we back the fix out from the jdk8u-dev forest and plan a new fix. This is a straight-forward anti delta of 8058547 JDK 9 is not impacted since JDK-8055753 already removed this code. bug : https://bugs.openjdk.java.net/browse/JDK-8077418 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077418.8u/webrev/ -- Regards, Sean.
Re: RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC
This looks pretty good. However, I suspect this will stop working once the Jake changes are integrated as module boundaries are enforced? Valerie On 6/5/2015 3:21 AM, Seán Coffey wrote: Looking to resolve a recently reported issue where the P11ECKeyFactory class has too much dependence on the SunEC provider. With some reshuffling and creation of a new P11ECUtil class, I was able to remove the call for lookup of SunEC Provider. The test picks up the regression when running with the SunPKCS11-NSS provider. bug report : https://bugs.openjdk.java.net/browse/JDK-8080102 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ -- Regards, Sean.
Re: RFR 7191662: JCE providers should be located via ServiceLoader
I don't know image builder well enough to answer your question. Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. Thanks, Valerie On 6/5/2015 12:21 AM, Erik Joelsson wrote: Hello Valerie, The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. /Erik On 2015-06-04 23:58, Valerie Peng wrote: Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. Thanks, Valerie On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: On 2015-05-29 00:10, Valerie Peng wrote: Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. I’ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus . Mandy On May 27, 2015, at 3:29 PM, Valerie Pengvalerie.p...@oracle.com wrote: Hi, build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. The rest of source code changes are reviewed by my team already. Thanks, Valerie (Java Security Team)
Re: JEP 232 RFR: JDK-8065942 and JDK-8056179
ServicePermission: We can also add a ServicePermission(String,int) like FilePermission has. --Max http://cr.openjdk.java.net/~mullan/webrevs/8065942-8056179/webrev.00/
Re: RFR 7191662: JCE providers should be located via ServiceLoader
On Jun 5, 2015, at 4:32 PM, Valerie Peng valerie.p...@oracle.com wrote: I don't know image builder well enough to answer your question. The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. There is no guarantee in what particular order a module is processed first. I don’t know if the jimage refresh work will change the ordering either. Since this is temporary, I’m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it’s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. Mandy Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. Thanks, Valerie On 6/5/2015 12:21 AM, Erik Joelsson wrote: Hello Valerie, The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. /Erik On 2015-06-04 23:58, Valerie Peng wrote: Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. Thanks, Valerie On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: On 2015-05-29 00:10, Valerie Peng wrote: Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. I’ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus . Mandy On May 27, 2015, at 3:29 PM, Valerie Pengvalerie.p...@oracle.com wrote: Hi, build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image
Re: TLS ALPN Proposal v2
On 6/5/2015 10:11 PM, Simone Bordet wrote: On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan xuelei@oracle.com wrote: See more inlines, please. Please help on one question I'm not sure of. Per HTTP/2 specification, Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2 connection? I did not find the answer from RFC 7540. Yes. The intended behavior is exactly to fall back to http/1.1 if h2 cannot be negotiated. This is implicitly explained in the ALPN spec, RFC 7301, see http://tools.ietf.org/html/rfc7301#section-3.2. This section says: It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. I may have different understanding. If server support H2, H2 should be used. No fallback is expected. Support does not means the protocol must work in any cases. Fallback to use HTTP/1.1 should be a spec of HTTP/2, rather than TLS protocols. I would like to see an evidence in HTTP/2 spec that H2 server allow fallback to HTTP/1.1. In TLS, if client requests to negotiate TLS v1.2, and server supports TLS 1.2, it is not allowed to fallback to TLS v1.1. If there is not suitable cipher suite to negotiate TLS 1.2, the connection would be terminated immediately. I'm not sure what's the spec for HTTP/2, HTTP/1.1 and HTTP/1.0. HTTP/2 does not behave like TLS in this sense. ALPN is for *application* protocol selection. A client can send: [h2, spdy/3.1, http/1.1] Failing h2, spdy/3.1 is attempted, which is a completely different protocol, with different restrictions, etc. Failing is confusing. Support does not means the protocol must work in any cases. But failing means that. I would use support for the description as what RFC 7301 does. If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not supported HTTP/1.1 would be attempted. If H2 is supported in both side, but H2 does not work, it is a H2 problem that need to be addressed in H2 layer. No application protocol fallback in TLS layer if the application protocol is supported. I understand your concerns now. I think we have different understanding of the ALPN protocols. It's a good thing to understand the actually requirements of the industry, I think. Thank you! Xuelei
