From fweimer at redhat.com Mon Mar 2 14:24:14 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 02 Mar 2015 15:24:14 +0100 Subject: RFR 8072394: java.security.cert.PolicyQualifierInfo needs value-based equality In-Reply-To: <54E7B3D1.4070402@oracle.com> References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com> <54DE5B96.9000704@redhat.com> <54E26B6C.3040202@oracle.com> <54E35086.7090408@redhat.com> <54E7B3D1.4070402@oracle.com> Message-ID: <54F4728E.7070405@redhat.com> On 02/20/2015 11:23 PM, Sean Mullan wrote: > On 02/17/2015 09:30 AM, Florian Weimer wrote: >> On 02/16/2015 11:13 PM, Sean Mullan wrote: >> >>>> Based on that, PolicyQualifierInfo should have implemented value-based >>>> equals() and hashCode(), and the identity-based set is just a bug. >>>> (But >>>> the requirement I cited is a stronger requirement the Set would not >>>> enforce.) >>>> >>>> However, I think it's too late to fix this bug now. That's why I just >>>> added the identity counter. If you want the behavioral change instead, >>>> I can implement that as well. >>> >>> Maybe it's not too late. This is not a commonly used class, and the >>> compatibility risk is probably fairly low. If you code up the changes, I >>> can file a CCC on your behalf. >> >> Updated webrev: > > You need to add a description for the overridden equals/hashCode > methods, ex: Okay, I didn't know that. I don't like specifying the hash code so strongly. But if we want to fix it at Arrays.hashCode(byte[]), it's probably better to implement Comparable as well, to aid the collision resolution in HashMap. The new webrev does that: I also compute the hashcode unconditionally in the constructor because PolicyQualifierInfo objects are used with sets, so their hashcode is so often needed. Funny how I wanted to make things go faster, and ended up introducing a slowdown. But correctness over performance. Most policy qualifier sets in X.509 certificates seem to have just one element, so I looked at optimizing that, but there's a lot of copying going on inside the implementation, and I'd have to special-case the one element case in multiple locations. Switching from a HashSet to a TreeSet would be externally visible, so that doesn't seem to be a good idea, either. We need an optimized immutable set class in the JDK. :-) -- Florian Weimer / Red Hat Product Security From kevin.walls at oracle.com Mon Mar 2 14:51:23 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 02 Mar 2015 14:51:23 +0000 Subject: RFR(8u) 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC Message-ID: <54F478EB.6090605@oracle.com> Hi, This is a review request for a jdk8u backport of: https://bugs.openjdk.java.net/browse/JDK-8064331 8u webrev: http://cr.openjdk.java.net/~kevinw/8064331/webrev.00/ Original webrev and review email: http://cr.openjdk.java.net/~jbachorik/8064331/webrev.01/ http://mail.openjdk.java.net/pipermail/security-dev/2015-February/011694.html Thanks Kevin From sean.mullan at oracle.com Mon Mar 2 16:57:55 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 02 Mar 2015 11:57:55 -0500 Subject: RFR(8u) 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC In-Reply-To: <54F478EB.6090605@oracle.com> References: <54F478EB.6090605@oracle.com> Message-ID: <54F49693.5040505@oracle.com> Looks fine to me. --Sean On 03/02/2015 09:51 AM, Kevin Walls wrote: > > Hi, > > This is a review request for a jdk8u backport of: > https://bugs.openjdk.java.net/browse/JDK-8064331 > > 8u webrev: > http://cr.openjdk.java.net/~kevinw/8064331/webrev.00/ > > Original webrev and review email: > http://cr.openjdk.java.net/~jbachorik/8064331/webrev.01/ > http://mail.openjdk.java.net/pipermail/security-dev/2015-February/011694.html > > > Thanks > Kevin > > From kevin.walls at oracle.com Mon Mar 2 17:00:22 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 02 Mar 2015 17:00:22 +0000 Subject: RFR(8u) 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC In-Reply-To: <54F49693.5040505@oracle.com> References: <54F478EB.6090605@oracle.com> <54F49693.5040505@oracle.com> Message-ID: <54F49726.3030208@oracle.com> Thanks. Sorry should have mentioned that this is the same change as jdk9 (addition of getCombinedACC() in ProtectionDomain and constructor change in AccessControlContext.) It doesn't hg import, at least because the paths are now different, possibly also due to other differences in the files. Thanks Kevin On 02/03/2015 16:57, Sean Mullan wrote: > Looks fine to me. > > --Sean > > On 03/02/2015 09:51 AM, Kevin Walls wrote: >> >> Hi, >> >> This is a review request for a jdk8u backport of: >> https://bugs.openjdk.java.net/browse/JDK-8064331 >> >> 8u webrev: >> http://cr.openjdk.java.net/~kevinw/8064331/webrev.00/ >> >> Original webrev and review email: >> http://cr.openjdk.java.net/~jbachorik/8064331/webrev.01/ >> http://mail.openjdk.java.net/pipermail/security-dev/2015-February/011694.html >> >> >> >> Thanks >> Kevin >> >> From sean.coffey at oracle.com Mon Mar 2 17:26:09 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Mon, 02 Mar 2015 17:26:09 +0000 Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath In-Reply-To: <54DD3FD4.3000106@oracle.com> References: <54DD3FD4.3000106@oracle.com> Message-ID: <54F49D31.3090404@oracle.com> Jason, thanks for taking this on. Your changes look fine to be and should help the debugging experience. Some extra comments from me. Here's some standard output that one sees (early in connection) from a standard TLS connection attempt with verbose certpath logging : > certpath: PKIXCertPathValidator.engineValidate()... > certpath: AdaptableX509CertSelector.match: subject key IDs don't match > certpath: NO - don't try this trustedCert Can we print the subject key IDs for reference ? I'm conscious of line wastage in log files. Bunching the IDs in with the "don't try this trustedCert line" would work perhaps. Shortly after that, one reads : > certpath: Executing PKIX certification path validation algorithm. > certpath: Checking cert1 ... > certpath: Set of critical extensions: > certpath: 2.5.29.15 > certpath: 2.5.29.19 Could we improve the PKIXMasterCertPathValidator.validate printing in this case ? Let's print the Subject and/or ID of "cert1" I'm not sure why we print the critical extension list here. Could we append them after "Set of critical extensions:" to avoid extra lines ? Shortly after that, we have this in output : > certpath: ---checking basic constraints... > certpath: i = 1 > certpath: maxPathLength = 2 > certpath: after processing, maxPathLength = 0 > certpath: basic constraints verified. > certpath: ---checking name constraints... > certpath: prevNC = null > certpath: newNC = null > certpath: mergedNC = null > certpath: name constraints verified. > certpath: -checker4 validation succeeded just a tidy up thought, could some of the lines above be concatenated ? E.g. : ConstraintsChecker.java 227 debug.println("---checking " + msg + "..."); 228 debug.println("i = " + i); 229 debug.println("maxPathLength = " + maxPathLength); Maybe some room for concatenation here also : certpath: ---checking timestamp:Mon Mar 02 16:34:47 GMT 2015... certpath: timestamp verified. Finally - another reason for why I logged the enhancement request in the first place.. Take this output : > *** ServerHelloDone > [read] MD5 and SHA1 hashes: len = 4 > 0000: 0E 00 00 00 .... > *** Certificate chain > *** The final "***" here indicates that the truststore is empty. It's not very obvious to the novice user! I believe the output corresponds to : jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498 We need to at least print "Empty cert chain" where applicable. This belongs in jsse code but it would be great if this can be improved as part of this fix. regards, Sean. On 13/02/15 00:05, Jason Uh wrote: > Please review this change, which augments some of the debug statements > for java.security.debug=certpath. > > webrev: http://cr.openjdk.java.net/~juh/8054037/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8054037 > > Thanks, > Jason From vincent.x.ryan at oracle.com Mon Mar 2 18:01:02 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 2 Mar 2015 18:01:02 +0000 Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath In-Reply-To: <54F49D31.3090404@oracle.com> References: <54DD3FD4.3000106@oracle.com> <54F49D31.3090404@oracle.com> Message-ID: <0117C18C-860D-440A-86F1-BAAB3A5813F9@oracle.com> On 2 Mar 2015, at 17:26, Se?n Coffey wrote: > Jason, > > thanks for taking this on. Your changes look fine to be and should help the debugging experience. Some extra comments from me. Here's some standard output that one sees (early in connection) from a standard TLS connection attempt with verbose certpath logging : > >> certpath: PKIXCertPathValidator.engineValidate()... >> certpath: AdaptableX509CertSelector.match: subject key IDs don't match >> certpath: NO - don't try this trustedCert > > Can we print the subject key IDs for reference ? I'm conscious of line wastage in log files. Bunching the IDs in with the "don't try this trustedCert line" would work perhaps. > > Shortly after that, one reads : > >> certpath: Executing PKIX certification path validation algorithm. >> certpath: Checking cert1 ... >> certpath: Set of critical extensions: >> certpath: 2.5.29.15 >> certpath: 2.5.29.19 > Could we improve the PKIXMasterCertPathValidator.validate printing in this case ? Let's print the Subject and/or ID of "cert1" > I'm not sure why we print the critical extension list here. Could we append them after "Set of critical extensions:" to avoid extra lines ? > > Shortly after that, we have this in output : > >> certpath: ---checking basic constraints... >> certpath: i = 1 >> certpath: maxPathLength = 2 >> certpath: after processing, maxPathLength = 0 >> certpath: basic constraints verified. >> certpath: ---checking name constraints... >> certpath: prevNC = null >> certpath: newNC = null >> certpath: mergedNC = null >> certpath: name constraints verified. >> certpath: -checker4 validation succeeded > > just a tidy up thought, could some of the lines above be concatenated ? > E.g. : ConstraintsChecker.java > > 227 debug.println("---checking " + msg + "..."); > 228 debug.println("i = " + i); > 229 debug.println("maxPathLength = " + maxPathLength); > > Maybe some room for concatenation here also : > certpath: ---checking timestamp:Mon Mar 02 16:34:47 GMT 2015... > certpath: timestamp verified. > > Finally - another reason for why I logged the enhancement request in the first place.. > > Take this output : > >> *** ServerHelloDone >> [read] MD5 and SHA1 hashes: len = 4 >> 0000: 0E 00 00 00 .... >> *** Certificate chain >> *** > > The final "***" here indicates that the truststore is empty. It's not very obvious to the novice user! > I believe the output corresponds to : > jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498 > > We need to at least print "Empty cert chain" where applicable. This belongs in jsse code but it would be great if this can be improved as part of this fix. Jason, I have a patch prepared for this that never got pushed. You could include it in your changeset. diff --git a/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java b/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java --- a/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java +++ b/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -750,6 +750,11 @@ } else { warningSE(Alerts.alert_no_certificate); } + if (debug != null && Debug.isOn("handshake")) { + System.out.println( + "Warning: no suitable certificate found - " + + "continuing without client authentication"); + } } diff --git a/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java b/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java --- a/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java +++ b/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -490,11 +490,14 @@ void print(PrintStream s) throws IOException { s.println("*** Certificate chain"); - if (debug != null && Debug.isOn("verbose")) { - for (int i = 0; i < chain.length; i++) + if (chain.length == 0) { + s.println(""); + } else if (debug != null && Debug.isOn("verbose")) { + for (int i = 0; i < chain.length; i++) { s.println("chain [" + i + "] = " + chain[i]); - s.println("***"); + } } + s.println("***"); } X509Certificate[] getCertificateChain() { > > regards, > Sean. > > On 13/02/15 00:05, Jason Uh wrote: >> Please review this change, which augments some of the debug statements for java.security.debug=certpath. >> >> webrev: http://cr.openjdk.java.net/~juh/8054037/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8054037 >> >> Thanks, >> Jason > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.uh at oracle.com Mon Mar 2 23:07:03 2015 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 02 Mar 2015 15:07:03 -0800 Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath In-Reply-To: <54F49D31.3090404@oracle.com> References: <54DD3FD4.3000106@oracle.com> <54F49D31.3090404@oracle.com> Message-ID: <54F4ED17.3060000@oracle.com> Thanks for the comments, Sean; Vinnie, for the patch. Here's an updated webrev with your suggested changes and Vinnie's patch. http://cr.openjdk.java.net/~juh/8054037/01/ I've also removed a few unnecessary toString() calls in AdaptableX509CertSelector.java and DistributionPointFetcher.java. Jason On 03/02/2015 09:26 AM, Se?n Coffey wrote: > Jason, > > thanks for taking this on. Your changes look fine to be and should help > the debugging experience. Some extra comments from me. Here's some > standard output that one sees (early in connection) from a standard TLS > connection attempt with verbose certpath logging : > >> certpath: PKIXCertPathValidator.engineValidate()... >> certpath: AdaptableX509CertSelector.match: subject key IDs don't match >> certpath: NO - don't try this trustedCert > > Can we print the subject key IDs for reference ? I'm conscious of line > wastage in log files. Bunching the IDs in with the "don't try this > trustedCert line" would work perhaps. > > Shortly after that, one reads : > >> certpath: Executing PKIX certification path validation algorithm. >> certpath: Checking cert1 ... >> certpath: Set of critical extensions: >> certpath: 2.5.29.15 >> certpath: 2.5.29.19 > Could we improve the PKIXMasterCertPathValidator.validate printing in > this case ? Let's print the Subject and/or ID of "cert1" > I'm not sure why we print the critical extension list here. Could we > append them after "Set of critical extensions:" to avoid extra lines ? > > Shortly after that, we have this in output : > >> certpath: ---checking basic constraints... >> certpath: i = 1 >> certpath: maxPathLength = 2 >> certpath: after processing, maxPathLength = 0 >> certpath: basic constraints verified. >> certpath: ---checking name constraints... >> certpath: prevNC = null >> certpath: newNC = null >> certpath: mergedNC = null >> certpath: name constraints verified. >> certpath: -checker4 validation succeeded > > just a tidy up thought, could some of the lines above be concatenated ? > E.g. : ConstraintsChecker.java > > 227 debug.println("---checking " + msg + "..."); > 228 debug.println("i = " + i); > 229 debug.println("maxPathLength = " + maxPathLength); > > Maybe some room for concatenation here also : > certpath: ---checking timestamp:Mon Mar 02 16:34:47 GMT 2015... > certpath: timestamp verified. > > Finally - another reason for why I logged the enhancement request in the > first place.. > > Take this output : > >> *** ServerHelloDone >> [read] MD5 and SHA1 hashes: len = 4 >> 0000: 0E 00 00 00 .... >> *** Certificate chain >> *** > > The final "***" here indicates that the truststore is empty. It's not > very obvious to the novice user! > I believe the output corresponds to : > jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498 > > We need to at least print "Empty cert chain" where applicable. This > belongs in jsse code but it would be great if this can be improved as > part of this fix. > > regards, > Sean. > > On 13/02/15 00:05, Jason Uh wrote: >> Please review this change, which augments some of the debug statements >> for java.security.debug=certpath. >> >> webrev: http://cr.openjdk.java.net/~juh/8054037/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8054037 >> >> Thanks, >> Jason > From jamil.j.nimeh at oracle.com Tue Mar 3 00:05:20 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 02 Mar 2015 16:05:20 -0800 Subject: RFR: 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions Message-ID: <54F4FAC0.2040703@oracle.com> Hello all, this review fixes an issue in OCSPResponse where it does not parse singleExtensions in the SingleResponse structure. I also fixed two minor deviations from the OCSP.RevocationStatus interface when getRevocationTime and getRevocationReason are called on good responses. Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 Review: http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html Thank you, --Jamil From sean.coffey at oracle.com Tue Mar 3 09:25:50 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 03 Mar 2015 09:25:50 +0000 Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath (8055207) In-Reply-To: <54F4ED17.3060000@oracle.com> References: <54DD3FD4.3000106@oracle.com> <54F49D31.3090404@oracle.com> <54F4ED17.3060000@oracle.com> Message-ID: <54F57E1E.9080002@oracle.com> Jason, I think you're missing the HandshakeMessage.java changes that Vinnie proposed. Everything else looks good to me. I'd suggest that you push your changeset with both the 8054037 and 8055207 bug IDs then. regards, Sean. On 02/03/2015 23:07, Jason Uh wrote: > Thanks for the comments, Sean; Vinnie, for the patch. > > Here's an updated webrev with your suggested changes and Vinnie's patch. > http://cr.openjdk.java.net/~juh/8054037/01/ > > I've also removed a few unnecessary toString() calls in > AdaptableX509CertSelector.java and DistributionPointFetcher.java. > > Jason > > > On 03/02/2015 09:26 AM, Se?n Coffey wrote: >> Jason, >> >> thanks for taking this on. Your changes look fine to be and should help >> the debugging experience. Some extra comments from me. Here's some >> standard output that one sees (early in connection) from a standard TLS >> connection attempt with verbose certpath logging : >> >>> certpath: PKIXCertPathValidator.engineValidate()... >>> certpath: AdaptableX509CertSelector.match: subject key IDs don't match >>> certpath: NO - don't try this trustedCert >> >> Can we print the subject key IDs for reference ? I'm conscious of line >> wastage in log files. Bunching the IDs in with the "don't try this >> trustedCert line" would work perhaps. >> >> Shortly after that, one reads : >> >>> certpath: Executing PKIX certification path validation algorithm. >>> certpath: Checking cert1 ... >>> certpath: Set of critical extensions: >>> certpath: 2.5.29.15 >>> certpath: 2.5.29.19 >> Could we improve the PKIXMasterCertPathValidator.validate printing in >> this case ? Let's print the Subject and/or ID of "cert1" >> I'm not sure why we print the critical extension list here. Could we >> append them after "Set of critical extensions:" to avoid extra lines ? >> >> Shortly after that, we have this in output : >> >>> certpath: ---checking basic constraints... >>> certpath: i = 1 >>> certpath: maxPathLength = 2 >>> certpath: after processing, maxPathLength = 0 >>> certpath: basic constraints verified. >>> certpath: ---checking name constraints... >>> certpath: prevNC = null >>> certpath: newNC = null >>> certpath: mergedNC = null >>> certpath: name constraints verified. >>> certpath: -checker4 validation succeeded >> >> just a tidy up thought, could some of the lines above be concatenated ? >> E.g. : ConstraintsChecker.java >> >> 227 debug.println("---checking " + msg + "..."); >> 228 debug.println("i = " + i); >> 229 debug.println("maxPathLength = " + maxPathLength); >> >> Maybe some room for concatenation here also : >> certpath: ---checking timestamp:Mon Mar 02 16:34:47 GMT 2015... >> certpath: timestamp verified. >> >> Finally - another reason for why I logged the enhancement request in the >> first place.. >> >> Take this output : >> >>> *** ServerHelloDone >>> [read] MD5 and SHA1 hashes: len = 4 >>> 0000: 0E 00 00 00 .... >>> *** Certificate chain >>> *** >> >> The final "***" here indicates that the truststore is empty. It's not >> very obvious to the novice user! >> I believe the output corresponds to : >> jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498 >> >> >> We need to at least print "Empty cert chain" where applicable. This >> belongs in jsse code but it would be great if this can be improved as >> part of this fix. >> >> regards, >> Sean. >> >> On 13/02/15 00:05, Jason Uh wrote: >>> Please review this change, which augments some of the debug statements >>> for java.security.debug=certpath. >>> >>> webrev: http://cr.openjdk.java.net/~juh/8054037/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8054037 >>> >>> Thanks, >>> Jason >> From kevin.walls at oracle.com Tue Mar 3 13:29:27 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 03 Mar 2015 13:29:27 +0000 Subject: RFR(8u): 8072932: Test fails with java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getDomainCombiner") Message-ID: <54F5B737.10604@oracle.com> Hi, This is a review request for an 8u backport of the bug: https://bugs.openjdk.java.net/browse/JDK-8072932 It's a one-line change that backports cleanly: this is the 8u diff, shown after applying the change for 8064331 in 8u: (not hg imported, different paths) jdk8u-dev/jdk$ hg diff src/share/classes/java/security/ProtectionDomain.java diff --git a/src/share/classes/java/security/ProtectionDomain.java b/src/share/classes/java/security/ProtectionDomain.java --- a/src/share/classes/java/security/ProtectionDomain.java +++ b/src/share/classes/java/security/ProtectionDomain.java @@ -88,7 +88,7 @@ } private static AccessControlContext getCombinedACC(AccessControlContext context, AccessControlContext stack) { - AccessControlContext acc = new AccessControlContext(context, stack.getDomainCombiner(), true); + AccessControlContext acc = new AccessControlContext(context, stack.getCombiner(), true); return new AccessControlContext(stack.getContext(), acc).optimize(); } Original 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/f4ce7c7a0296 Thanks Kevin From jaroslav.bachorik at oracle.com Tue Mar 3 15:09:42 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Mar 2015 16:09:42 +0100 Subject: RFR(8u): 8072932: Test fails with java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getDomainCombiner") In-Reply-To: <54F5B737.10604@oracle.com> References: <54F5B737.10604@oracle.com> Message-ID: <54F5CEB6.10902@oracle.com> Hi Kevin, On 3.3.2015 14:29, Kevin Walls wrote: > Hi, > > This is a review request for an 8u backport of the bug: > https://bugs.openjdk.java.net/browse/JDK-8072932 > > It's a one-line change that backports cleanly: this is the 8u diff, > shown after applying the change for 8064331 in 8u: (not hg imported, > different paths) > > jdk8u-dev/jdk$ hg diff > src/share/classes/java/security/ProtectionDomain.java > diff --git a/src/share/classes/java/security/ProtectionDomain.java > b/src/share/classes/java/security/ProtectionDomain.java > --- a/src/share/classes/java/security/ProtectionDomain.java > +++ b/src/share/classes/java/security/ProtectionDomain.java > @@ -88,7 +88,7 @@ > } > > private static AccessControlContext > getCombinedACC(AccessControlContext context, AccessControlContext stack) { > - AccessControlContext acc = new > AccessControlContext(context, stack.getDomainCombiner(), true); > + AccessControlContext acc = new > AccessControlContext(context, stack.getCombiner(), true); > > return new AccessControlContext(stack.getContext(), > acc).optimize(); > } > > > Original 9 changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/f4ce7c7a0296 This looks good. Thanks for taking care of the backports. -JB- > > Thanks > Kevin From amanda.jiang at oracle.com Tue Mar 3 17:27:21 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 03 Mar 2015 09:27:21 -0800 Subject: Please review CR8048360 Test signed jar files In-Reply-To: <54EE67BA.1080105@oracle.com> References: <54EE3384.1080104@oracle.com> <54EE67BA.1080105@oracle.com> Message-ID: <54F5EEF9.5040405@oracle.com> Hi Max, Thanks for reviewing this changeset, could you please sponsor this? Regards, Amanda On 2/25/15 4:24 PM, Weijun Wang wrote: > Looks fine. > > Thanks > Max > > On 2/26/2015 4:41, Amanda Jiang wrote: >> Hi All, >> >> Could you please review following changeset for 1 new test, which check >> various combinations of permissions to execute the code from a signed >> jar file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048360 >> webrev: http://cr.openjdk.java.net/~tyan/amandaj/8048360/webrev.01/ >> >> >> Thanks, >> Amanda From jason.uh at oracle.com Tue Mar 3 18:25:42 2015 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 03 Mar 2015 10:25:42 -0800 Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath (8055207) In-Reply-To: <54F57E1E.9080002@oracle.com> References: <54DD3FD4.3000106@oracle.com> <54F49D31.3090404@oracle.com> <54F4ED17.3060000@oracle.com> <54F57E1E.9080002@oracle.com> Message-ID: <54F5FCA6.70405@oracle.com> Thanks for catching that. Here it is with the HandshakeMessage.java changes. I'll push with both bug IDs. On 03/03/2015 01:25 AM, Se?n Coffey wrote: > Jason, > > I think you're missing the HandshakeMessage.java changes that Vinnie > proposed. Everything else looks good to me. > I'd suggest that you push your changeset with both the 8054037 and > 8055207 bug IDs then. > > regards, > Sean. > > On 02/03/2015 23:07, Jason Uh wrote: >> Thanks for the comments, Sean; Vinnie, for the patch. >> >> Here's an updated webrev with your suggested changes and Vinnie's patch. >> http://cr.openjdk.java.net/~juh/8054037/01/ >> >> I've also removed a few unnecessary toString() calls in >> AdaptableX509CertSelector.java and DistributionPointFetcher.java. >> >> Jason >> >> >> On 03/02/2015 09:26 AM, Se?n Coffey wrote: >>> Jason, >>> >>> thanks for taking this on. Your changes look fine to be and should help >>> the debugging experience. Some extra comments from me. Here's some >>> standard output that one sees (early in connection) from a standard TLS >>> connection attempt with verbose certpath logging : >>> >>>> certpath: PKIXCertPathValidator.engineValidate()... >>>> certpath: AdaptableX509CertSelector.match: subject key IDs don't match >>>> certpath: NO - don't try this trustedCert >>> >>> Can we print the subject key IDs for reference ? I'm conscious of line >>> wastage in log files. Bunching the IDs in with the "don't try this >>> trustedCert line" would work perhaps. >>> >>> Shortly after that, one reads : >>> >>>> certpath: Executing PKIX certification path validation algorithm. >>>> certpath: Checking cert1 ... >>>> certpath: Set of critical extensions: >>>> certpath: 2.5.29.15 >>>> certpath: 2.5.29.19 >>> Could we improve the PKIXMasterCertPathValidator.validate printing in >>> this case ? Let's print the Subject and/or ID of "cert1" >>> I'm not sure why we print the critical extension list here. Could we >>> append them after "Set of critical extensions:" to avoid extra lines ? >>> >>> Shortly after that, we have this in output : >>> >>>> certpath: ---checking basic constraints... >>>> certpath: i = 1 >>>> certpath: maxPathLength = 2 >>>> certpath: after processing, maxPathLength = 0 >>>> certpath: basic constraints verified. >>>> certpath: ---checking name constraints... >>>> certpath: prevNC = null >>>> certpath: newNC = null >>>> certpath: mergedNC = null >>>> certpath: name constraints verified. >>>> certpath: -checker4 validation succeeded >>> >>> just a tidy up thought, could some of the lines above be concatenated ? >>> E.g. : ConstraintsChecker.java >>> >>> 227 debug.println("---checking " + msg + "..."); >>> 228 debug.println("i = " + i); >>> 229 debug.println("maxPathLength = " + maxPathLength); >>> >>> Maybe some room for concatenation here also : >>> certpath: ---checking timestamp:Mon Mar 02 16:34:47 GMT 2015... >>> certpath: timestamp verified. >>> >>> Finally - another reason for why I logged the enhancement request in the >>> first place.. >>> >>> Take this output : >>> >>>> *** ServerHelloDone >>>> [read] MD5 and SHA1 hashes: len = 4 >>>> 0000: 0E 00 00 00 .... >>>> *** Certificate chain >>>> *** >>> >>> The final "***" here indicates that the truststore is empty. It's not >>> very obvious to the novice user! >>> I believe the output corresponds to : >>> jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498 >>> >>> >>> We need to at least print "Empty cert chain" where applicable. This >>> belongs in jsse code but it would be great if this can be improved as >>> part of this fix. >>> >>> regards, >>> Sean. >>> >>> On 13/02/15 00:05, Jason Uh wrote: >>>> Please review this change, which augments some of the debug statements >>>> for java.security.debug=certpath. >>>> >>>> webrev: http://cr.openjdk.java.net/~juh/8054037/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054037 >>>> >>>> Thanks, >>>> Jason >>> > From sean.coffey at oracle.com Tue Mar 3 18:36:06 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 03 Mar 2015 18:36:06 +0000 Subject: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath (8055207) In-Reply-To: <54F5FCA6.70405@oracle.com> References: <54DD3FD4.3000106@oracle.com> <54F49D31.3090404@oracle.com> <54F4ED17.3060000@oracle.com> <54F57E1E.9080002@oracle.com> <54F5FCA6.70405@oracle.com> Message-ID: <54F5FF16.8080707@oracle.com> http://cr.openjdk.java.net/~juh/8054037/02/ Looks good. regards, Sean. On 03/03/2015 18:25, Jason Uh wrote: > Thanks for catching that. Here it is with the HandshakeMessage.java > changes. > > I'll push with both bug IDs. > > On 03/03/2015 01:25 AM, Se?n Coffey wrote: >> Jason, >> >> I think you're missing the HandshakeMessage.java changes that Vinnie >> proposed. Everything else looks good to me. >> I'd suggest that you push your changeset with both the 8054037 and >> 8055207 bug IDs then. >> >> regards, >> Sean. >> >> On 02/03/2015 23:07, Jason Uh wrote: >>> Thanks for the comments, Sean; Vinnie, for the patch. >>> >>> Here's an updated webrev with your suggested changes and Vinnie's >>> patch. >>> http://cr.openjdk.java.net/~juh/8054037/01/ >>> >>> I've also removed a few unnecessary toString() calls in >>> AdaptableX509CertSelector.java and DistributionPointFetcher.java. >>> >>> Jason >>> >>> >>> On 03/02/2015 09:26 AM, Se?n Coffey wrote: >>>> Jason, >>>> >>>> thanks for taking this on. Your changes look fine to be and should >>>> help >>>> the debugging experience. Some extra comments from me. Here's some >>>> standard output that one sees (early in connection) from a standard >>>> TLS >>>> connection attempt with verbose certpath logging : >>>> >>>>> certpath: PKIXCertPathValidator.engineValidate()... >>>>> certpath: AdaptableX509CertSelector.match: subject key IDs don't >>>>> match >>>>> certpath: NO - don't try this trustedCert >>>> >>>> Can we print the subject key IDs for reference ? I'm conscious of line >>>> wastage in log files. Bunching the IDs in with the "don't try this >>>> trustedCert line" would work perhaps. >>>> >>>> Shortly after that, one reads : >>>> >>>>> certpath: Executing PKIX certification path validation algorithm. >>>>> certpath: Checking cert1 ... >>>>> certpath: Set of critical extensions: >>>>> certpath: 2.5.29.15 >>>>> certpath: 2.5.29.19 >>>> Could we improve the PKIXMasterCertPathValidator.validate printing in >>>> this case ? Let's print the Subject and/or ID of "cert1" >>>> I'm not sure why we print the critical extension list here. Could we >>>> append them after "Set of critical extensions:" to avoid extra lines ? >>>> >>>> Shortly after that, we have this in output : >>>> >>>>> certpath: ---checking basic constraints... >>>>> certpath: i = 1 >>>>> certpath: maxPathLength = 2 >>>>> certpath: after processing, maxPathLength = 0 >>>>> certpath: basic constraints verified. >>>>> certpath: ---checking name constraints... >>>>> certpath: prevNC = null >>>>> certpath: newNC = null >>>>> certpath: mergedNC = null >>>>> certpath: name constraints verified. >>>>> certpath: -checker4 validation succeeded >>>> >>>> just a tidy up thought, could some of the lines above be >>>> concatenated ? >>>> E.g. : ConstraintsChecker.java >>>> >>>> 227 debug.println("---checking " + msg + "..."); >>>> 228 debug.println("i = " + i); >>>> 229 debug.println("maxPathLength = " + maxPathLength); >>>> >>>> Maybe some room for concatenation here also : >>>> certpath: ---checking timestamp:Mon Mar 02 16:34:47 GMT 2015... >>>> certpath: timestamp verified. >>>> >>>> Finally - another reason for why I logged the enhancement request >>>> in the >>>> first place.. >>>> >>>> Take this output : >>>> >>>>> *** ServerHelloDone >>>>> [read] MD5 and SHA1 hashes: len = 4 >>>>> 0000: 0E 00 00 00 .... >>>>> *** Certificate chain >>>>> *** >>>> >>>> The final "***" here indicates that the truststore is empty. It's not >>>> very obvious to the novice user! >>>> I believe the output corresponds to : >>>> jdk/src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java#498 >>>> >>>> >>>> >>>> We need to at least print "Empty cert chain" where applicable. This >>>> belongs in jsse code but it would be great if this can be improved as >>>> part of this fix. >>>> >>>> regards, >>>> Sean. >>>> >>>> On 13/02/15 00:05, Jason Uh wrote: >>>>> Please review this change, which augments some of the debug >>>>> statements >>>>> for java.security.debug=certpath. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~juh/8054037/00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054037 >>>>> >>>>> Thanks, >>>>> Jason >>>> >> From jamil.j.nimeh at oracle.com Tue Mar 3 22:18:24 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 03 Mar 2015 14:18:24 -0800 Subject: RFR: 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <54F4FAC0.2040703@oracle.com> References: <54F4FAC0.2040703@oracle.com> Message-ID: <54F63330.8030104@oracle.com> Hello all, I've come across a couple edge cases that this fix doesn't cover properly. I'll put out another webrev in a bit that should tighten up the singleResponse parsing, particularly with the optional fields. It will also include a couple other negative test input samples. Thanks, --Jamil On 03/02/2015 04:05 PM, Jamil Nimeh wrote: > Hello all, this review fixes an issue in OCSPResponse where it does > not parse singleExtensions in the SingleResponse structure. I also > fixed two minor deviations from the OCSP.RevocationStatus interface > when getRevocationTime and getRevocationReason are called on good > responses. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 > Review: > http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html > > Thank you, > --Jamil From jamil.j.nimeh at oracle.com Wed Mar 4 00:10:38 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 03 Mar 2015 16:10:38 -0800 Subject: RFR: [Updated] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <54F63330.8030104@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> Message-ID: <54F64D7E.4080802@oracle.com> Okay, I've got an updated webrev for this issue: http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html Thanks, --Jamil On 03/03/2015 02:18 PM, Jamil Nimeh wrote: > Hello all, I've come across a couple edge cases that this fix doesn't > cover properly. I'll put out another webrev in a bit that should > tighten up the singleResponse parsing, particularly with the optional > fields. It will also include a couple other negative test input samples. > > Thanks, > --Jamil > > On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >> Hello all, this review fixes an issue in OCSPResponse where it does >> not parse singleExtensions in the SingleResponse structure. I also >> fixed two minor deviations from the OCSP.RevocationStatus interface >> when getRevocationTime and getRevocationReason are called on good >> responses. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >> Review: >> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >> >> Thank you, >> --Jamil > From weijun.wang at oracle.com Wed Mar 4 01:09:54 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Mar 2015 09:09:54 +0800 Subject: Please review CR8048360 Test signed jar files In-Reply-To: <54F5EEF9.5040405@oracle.com> References: <54EE3384.1080104@oracle.com> <54EE67BA.1080105@oracle.com> <54F5EEF9.5040405@oracle.com> Message-ID: <43FD7722-022C-4E2D-AF9A-DDB101D68E9B@oracle.com> Sure. Are you an OpenJDK author? If yes, the changset will have Author: amanda Otherwise, it will be Author: weijun Contributed-by: amanda.jiang at oracle.com --Max > On Mar 4, 2015, at 01:27, Amanda Jiang wrote: > > Hi Max, > > Thanks for reviewing this changeset, could you please sponsor this? > > Regards, > Amanda > > On 2/25/15 4:24 PM, Weijun Wang wrote: >> Looks fine. >> >> Thanks >> Max >> >> On 2/26/2015 4:41, Amanda Jiang wrote: >>> Hi All, >>> >>> Could you please review following changeset for 1 new test, which check >>> various combinations of permissions to execute the code from a signed >>> jar file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048360 >>> webrev: http://cr.openjdk.java.net/~tyan/amandaj/8048360/webrev.01/ >>> >>> >>> Thanks, >>> Amanda > From amanda.jiang at oracle.com Wed Mar 4 01:26:32 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 03 Mar 2015 17:26:32 -0800 Subject: Please review CR8048360 Test signed jar files In-Reply-To: <43FD7722-022C-4E2D-AF9A-DDB101D68E9B@oracle.com> References: <54EE3384.1080104@oracle.com> <54EE67BA.1080105@oracle.com> <54F5EEF9.5040405@oracle.com> <43FD7722-022C-4E2D-AF9A-DDB101D68E9B@oracle.com> Message-ID: <54F65F48.6000003@oracle.com> Hi Max, I don't have an author ID yet. Thanks, Amanda On 3/3/15 5:09 PM, Wang Weijun wrote: > Sure. > > Are you an OpenJDK author? If yes, the changset will have > > Author: amanda > > Otherwise, it will be > > Author: weijun > Contributed-by: amanda.jiang at oracle.com > > --Max > > >> On Mar 4, 2015, at 01:27, Amanda Jiang wrote: >> >> Hi Max, >> >> Thanks for reviewing this changeset, could you please sponsor this? >> >> Regards, >> Amanda >> >> On 2/25/15 4:24 PM, Weijun Wang wrote: >>> Looks fine. >>> >>> Thanks >>> Max >>> >>> On 2/26/2015 4:41, Amanda Jiang wrote: >>>> Hi All, >>>> >>>> Could you please review following changeset for 1 new test, which check >>>> various combinations of permissions to execute the code from a signed >>>> jar file. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048360 >>>> webrev: http://cr.openjdk.java.net/~tyan/amandaj/8048360/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Amanda From weijun.wang at oracle.com Wed Mar 4 02:13:26 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Mar 2015 10:13:26 +0800 Subject: Please review CR8048360 Test signed jar files In-Reply-To: <54F65F48.6000003@oracle.com> References: <54EE3384.1080104@oracle.com> <54EE67BA.1080105@oracle.com> <54F5EEF9.5040405@oracle.com> <43FD7722-022C-4E2D-AF9A-DDB101D68E9B@oracle.com> <54F65F48.6000003@oracle.com> Message-ID: <0C9BE707-F60B-42AE-9EFD-9AE0DB44A413@oracle.com> Done at http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4503bd758762. From xuelei.fan at oracle.com Wed Mar 4 05:34:59 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 04 Mar 2015 13:34:59 +0800 Subject: [JDK-9] RFR: 8050371: MessageDigest tests In-Reply-To: <54D9B760.20801@oracle.com> References: <54D9B760.20801@oracle.com> Message-ID: <54F69983.7060304@oracle.com> Looks fine to me. Thanks, Xuelei On 2/10/2015 3:46 PM, zaiyao liu wrote: > Hi all, > > Please help to review those 2 new tests to be added for MessageDigest, > New tests are added to address following: > > - Fixed length hash value is returned with different data inputs > - Same hash value is returned with different update and digest methods > > JDK issue: https://bugs.openjdk.java.net/browse/JDK-8050371 > Webrev: http://cr.openjdk.java.net/~zailiu/8050371/webrev/ > > Thanks > > Kevin From zaiyao.liu at oracle.com Wed Mar 4 05:40:40 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 04 Mar 2015 13:40:40 +0800 Subject: [JDK-9] RFR: 8050371: MessageDigest tests In-Reply-To: <54F69983.7060304@oracle.com> References: <54D9B760.20801@oracle.com> <54F69983.7060304@oracle.com> Message-ID: <54F69AD8.9090405@oracle.com> Hi Xuelei, Thanks for review, Can you help to push it? Full comments: 8050371: MessageDigest tests Reviewed-by: xuelei Contributed-by: Zaiyao Liu Thanks again. Kevin ? 2015/3/4 13:34, Xuelei Fan ??: > Looks fine to me. > > Thanks, > Xuelei > > On 2/10/2015 3:46 PM, zaiyao liu wrote: >> Hi all, >> >> Please help to review those 2 new tests to be added for MessageDigest, >> New tests are added to address following: >> >> - Fixed length hash value is returned with different data inputs >> - Same hash value is returned with different update and digest methods >> >> JDK issue: https://bugs.openjdk.java.net/browse/JDK-8050371 >> Webrev: http://cr.openjdk.java.net/~zailiu/8050371/webrev/ >> >> Thanks >> >> Kevin From weijun.wang at oracle.com Wed Mar 4 05:52:15 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 04 Mar 2015 13:52:15 +0800 Subject: [JDK-9] RFR: 8048610 Implement regression tests for bug fixes in JCE In-Reply-To: <54E1497A.40703@oracle.com> References: <54E1497A.40703@oracle.com> Message-ID: <54F69D8F.5060002@oracle.com> Empty: - 29: I am not a fan of import static using like this, but you are free to do anyway - 34: "with expected message". You didn't check if the message is expected, you only check if it's empty - 39, 41, 43, 51: left brace should go back to previous lines - line 48 and 49 can be fit in one line, throw -> thrown - 45: space after comma - 47: no space before right parenthesis - 50: space before catch - 53: space after if - 57: InvalidKeyException is thrown bug4901658: - 69, 70: indent - 75: "has been encoded with", space after comma - 78: no need to try-with-resources, byte stream has no close - 85: what for? - 87,93: what is tmp for? - 89,98: what is toString() for? You want a hex dump? - 99: We normally write "if (!" --Max On 2/16/2015 9:35, zaiyao liu wrote: > Hi all, > > Please help to review those 2 new tests to verify following 2 JDK bug > fixes in JCE: > > - JDK-4686632: InvalidKeyException.getMessage() returns null > - JDK-4901658: Can not produce a string from key's encoded byte[] > consistently > > JDK issue: https://bugs.openjdk.java.net/browse/JDK-8048610 > Webrev: http://cr.openjdk.java.net/~zailiu/8048610/webrev/ > > Thanks > > Kevin From ecki at zusammenkunft.net Wed Mar 4 05:56:34 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 4 Mar 2015 06:56:34 +0100 Subject: skip-tls Message-ID: <20150304065634.00006d75.ecki@zusammenkunft.net> Hello, I just run across this work from a team of researchers on TLS protocol fuzzing. One part of this article describes what CVE-2014-6593 is all about. https://www.smacktls.com/#skip I must say, I had a brief look into this while checking the fixes in the January CPU, but due to the rather low 4.0 CVSS scoring with the "high access complexity" I did not really pay attention. So let me quote the finding of the researchers and keep in mind, this affects all of Java 5.0u75, 6u85, 7u72, 8u25 and older. (This especially affects all public available Java 6 updates). "A vulnerable JSSE client is then willing to accept the certificate and start exchanging unencrypted application data. In other words, the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years." I know here on the list are people which are not all developers of the security components but care about java security, so I guess it is fine to share that pointer here. Gruss Bernd From zaiyao.liu at oracle.com Wed Mar 4 07:53:13 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 04 Mar 2015 15:53:13 +0800 Subject: [JDK-9] RFR: 8048610 Implement regression tests for bug fixes in JCE In-Reply-To: <54F69D8F.5060002@oracle.com> References: <54E1497A.40703@oracle.com> <54F69D8F.5060002@oracle.com> Message-ID: <54F6B9E9.3080303@oracle.com> Thanks Max, please review the update: http://cr.openjdk.java.net/~zailiu/8048610/webrev.01/webrev/ Kevin ? 2015/3/4 13:52, Weijun Wang ??: > Empty: > > - 29: I am not a fan of import static using like this, but you are > free to do anyway > - 34: "with expected message". You didn't check if the message is > expected, you only check if it's empty > - 39, 41, 43, 51: left brace should go back to previous lines > - line 48 and 49 can be fit in one line, throw -> thrown > - 45: space after comma > - 47: no space before right parenthesis > - 50: space before catch > - 53: space after if > - 57: InvalidKeyException is thrown > > bug4901658: > > - 69, 70: indent > - 75: "has been encoded with", space after comma > - 78: no need to try-with-resources, byte stream has no close > - 85: what for? > - 87,93: what is tmp for? > - 89,98: what is toString() for? You want a hex dump? > - 99: We normally write "if (!" > > --Max > > On 2/16/2015 9:35, zaiyao liu wrote: >> Hi all, >> >> Please help to review those 2 new tests to verify following 2 JDK bug >> fixes in JCE: >> >> - JDK-4686632: InvalidKeyException.getMessage() returns null >> - JDK-4901658: Can not produce a string from key's encoded byte[] >> consistently >> >> JDK issue: https://bugs.openjdk.java.net/browse/JDK-8048610 >> Webrev: http://cr.openjdk.java.net/~zailiu/8048610/webrev/ >> >> Thanks >> >> Kevin From weijun.wang at oracle.com Wed Mar 4 08:05:25 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Mar 2015 16:05:25 +0800 Subject: [JDK-9] RFR: 8048610 Implement regression tests for bug fixes in JCE In-Reply-To: <54F6B9E9.3080303@oracle.com> References: <54E1497A.40703@oracle.com> <54F69D8F.5060002@oracle.com> <54F6B9E9.3080303@oracle.com> Message-ID: <7BEAF7A9-5210-4BCF-8271-59976E92C7EB@oracle.com> http://cr.openjdk.java.net/~zailiu/8048610/webrev.01/webrev/ > >> Empty: >> >> - line 48 and 49 can be fit in one line, throw -> thrown and you don't need + anymore. >> >> bug4901658: I reread the original bug and think it's not worth adding this test. The original bug complains byte[].toString() is not the same. This is just a misunderstanding of how the method works and once you know you should actually compare the byte elements inside, it becomes no more a problem. The bug was closed as Not-an-Issue and there is really no value creating a test for it. --Max From xuelei.fan at oracle.com Wed Mar 4 08:11:45 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 04 Mar 2015 16:11:45 +0800 Subject: [JDK-9] RFR: 8050371: MessageDigest tests In-Reply-To: <54F69AD8.9090405@oracle.com> References: <54D9B760.20801@oracle.com> <54F69983.7060304@oracle.com> <54F69AD8.9090405@oracle.com> Message-ID: <54F6BE41.5060802@oracle.com> On 3/4/2015 1:40 PM, zaiyao liu wrote: > Hi Xuelei, > > Thanks for review, Can you help to push it? Pushed. Thanks, Xuelei > Full comments: > 8050371: MessageDigest tests > Reviewed-by: xuelei > Contributed-by: Zaiyao Liu > > Thanks again. > > Kevin > ? 2015/3/4 13:34, Xuelei Fan ??: >> Looks fine to me. >> >> Thanks, >> Xuelei >> >> On 2/10/2015 3:46 PM, zaiyao liu wrote: >>> Hi all, >>> >>> Please help to review those 2 new tests to be added for MessageDigest, >>> New tests are added to address following: >>> >>> - Fixed length hash value is returned with different data inputs >>> - Same hash value is returned with different update and digest methods >>> >>> JDK issue: https://bugs.openjdk.java.net/browse/JDK-8050371 >>> Webrev: http://cr.openjdk.java.net/~zailiu/8050371/webrev/ >>> >>> Thanks >>> >>> Kevin > From magnus.ihse.bursie at oracle.com Wed Mar 4 13:17:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Mar 2015 14:17:20 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis Message-ID: <54F705E0.2030102@oracle.com> When building the native code in the jdk repo, a lot of warnings are generated. So many that it's hard to spot any new issues. While the ultimate goal must be to address and fix these warnings individually, this bug is about disabling these warnings where they occur, so that it is easier to spot new warnings, and that the existing warnings can be addressed one at a time. Disabling warnings instead of fixing them can be problematic. If you are too broad with disabling warnings, you might hide future problems. On the other hand, there have been a lot of warnings that indicate serious problems that has been "hidden in plain sight" for a very long time in the code base anyway. I have opted to disable warnings at the library level. Disabling warnings globally would be too broad. Disabling per file would have been too tedious. Many warnings also tend to repeat across multiple files in the same library, due to e.g. less well-suited programming style or design choice. A library also seems like a suitable chunk of work to address later on, in trying to get rid of the source of the warnings. This fix will not get rid of all warnings, but the bulk of them. It will make the remaining warnings stick out more. The few warnings that remain are either: * Not possible to disable. * Not resulting from native compilation (but from linking, or javadoc, etc). * Not possible to disable with this framework (this goes for builds on pre-4.4 gcc, which Oracle currently does as default on macosx), and libfontmanager on Solaris, which mixes C and C++ code. (While the solstudio C compiler does not fail on requests to disable C++ warnings, the converse is unfortunately not true). It did not seem worth the trouble to build a more extensible framework to handle this, compared to actually fixing these warnings. Note that the current JPRT build environment in Oracle uses a pre-4.4 gcc for macosx by default, so the default macosx build will still contain warnings. When building with --with-toolchain-type=clang, the clang warning disabling kicks in. (This will be the default in JPRT later on this year.) I intend to file individual bugs to handle these remaining warnings, so the net result will be a completely warning free build. I also intend to file individual bugs on all the libraries that has had warnings disabled. I expect the outcome of these bugs to be either: A) The code modified so it does not trigger warnings, and the warnings re-enabled, or B) The warnings (or a subset of them) kept disabled, but a comment added to the makefile describing why this is the proper course of action. Not all bugs might be worth fixing. For instance, the GCC warnings type-limits, sign-compare, pointer-to-int-cast, conversion-null, deprecated-declarations, clobbered, int-to-pointer-cast and type-limits are all more or less benign, and is possibly the result of a false positive. On the other hands, warnings such as format-nonliteral, unused-result, maybe-uninitialized, format, format-security, int-to-pointer-cast, reorder and delete-non-virtual-dtor are more likely to actually point to real issues. I recommend anyone finding these warnings on a library they care about to try and fix them as soon as possible. Here is a summary of the libraries and binaries that have gotten warnings disabled. I'm not sure about what group owns all these libraries; if I missed sending this mail to the correct list, please help me and forward it. * libunpack * libfdlibm * libverify * libjava * libzip * libjli/libjli_static * libj2gss * libsunec * libj2pkcs11 * libnet * libnio * libosxkrb5 * libosxapp * libosx * libapplescriptengine * libjsound * libjsoundalsa * libmlib_image * libawt * libawt_xawt * libawt_lwawt * liblcms * libjavajpeg * libawt_headless * libfontmanager * libsplashscreen * unpack200 * The JVMTI demos compiledMethodLoad and waiters Bug: https://bugs.openjdk.java.net/browse/JDK-8074096 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Mar 4 13:31:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 04 Mar 2015 14:31:53 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F705E0.2030102@oracle.com> References: <54F705E0.2030102@oracle.com> Message-ID: <54F70949.4040900@oracle.com> Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line options to grep so that the command line could be copied to the shell for debugging in the future? Also, how hard would it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead test for capability? /Erik On 2015-03-04 14:17, Magnus Ihse Bursie wrote: > When building the native code in the jdk repo, a lot of warnings are > generated. So many that it's hard to spot any new issues. > > While the ultimate goal must be to address and fix these warnings > individually, this bug is about disabling these warnings where they > occur, so that it is easier to spot new warnings, and that the > existing warnings can be addressed one at a time. > > Disabling warnings instead of fixing them can be problematic. If you > are too broad with disabling warnings, you might hide future problems. > On the other hand, there have been a lot of warnings that indicate > serious problems that has been "hidden in plain sight" for a very long > time in the code base anyway. > > I have opted to disable warnings at the library level. Disabling > warnings globally would be too broad. Disabling per file would have > been too tedious. Many warnings also tend to repeat across multiple > files in the same library, due to e.g. less well-suited programming > style or design choice. A library also seems like a suitable chunk of > work to address later on, in trying to get rid of the source of the > warnings. > > This fix will not get rid of all warnings, but the bulk of them. It > will make the remaining warnings stick out more. The few warnings that > remain are either: > * Not possible to disable. > * Not resulting from native compilation (but from linking, or javadoc, > etc). > * Not possible to disable with this framework (this goes for builds on > pre-4.4 gcc, which Oracle currently does as default on macosx), and > libfontmanager on Solaris, which mixes C and C++ code. (While the > solstudio C compiler does not fail on requests to disable C++ > warnings, the converse is unfortunately not true). It did not seem > worth the trouble to build a more extensible framework to handle this, > compared to actually fixing these warnings. > > Note that the current JPRT build environment in Oracle uses a pre-4.4 > gcc for macosx by default, so the default macosx build will still > contain warnings. When building with --with-toolchain-type=clang, the > clang warning disabling kicks in. (This will be the default in JPRT > later on this year.) > > I intend to file individual bugs to handle these remaining warnings, > so the net result will be a completely warning free build. > > I also intend to file individual bugs on all the libraries that has > had warnings disabled. I expect the outcome of these bugs to be either: > > A) The code modified so it does not trigger warnings, and the warnings > re-enabled, or > > B) The warnings (or a subset of them) kept disabled, but a comment > added to the makefile describing why this is the proper course of action. > > Not all bugs might be worth fixing. For instance, the GCC warnings > type-limits, sign-compare, pointer-to-int-cast, conversion-null, > deprecated-declarations, clobbered, int-to-pointer-cast and > type-limits are all more or less benign, and is possibly the result of > a false positive. > > On the other hands, warnings such as format-nonliteral, unused-result, > maybe-uninitialized, format, format-security, int-to-pointer-cast, > reorder and delete-non-virtual-dtor are more likely to actually point > to real issues. I recommend anyone finding these warnings on a library > they care about to try and fix them as soon as possible. > > Here is a summary of the libraries and binaries that have gotten > warnings disabled. I'm not sure about what group owns all these > libraries; if I missed sending this mail to the correct list, please > help me and forward it. > > * libunpack > * libfdlibm > * libverify > * libjava > * libzip > * libjli/libjli_static > * libj2gss > * libsunec > * libj2pkcs11 > * libnet > * libnio > * libosxkrb5 > * libosxapp > * libosx > * libapplescriptengine > * libjsound > * libjsoundalsa > * libmlib_image > * libawt > * libawt_xawt > * libawt_lwawt > * liblcms > * libjavajpeg > * libawt_headless > * libfontmanager > * libsplashscreen > * unpack200 > * The JVMTI demos compiledMethodLoad and waiters > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074096 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01 > > /Magnus > From Alan.Bateman at oracle.com Wed Mar 4 13:48:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Mar 2015 13:48:50 +0000 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F705E0.2030102@oracle.com> References: <54F705E0.2030102@oracle.com> Message-ID: <54F70D42.3010905@oracle.com> On 04/03/2015 13:17, Magnus Ihse Bursie wrote: > : > > I intend to file individual bugs to handle these remaining warnings, > so the net result will be a completely warning free build. > > I also intend to file individual bugs on all the libraries that has > had warnings disabled. I expect the outcome of these bugs to be either: > > A) The code modified so it does not trigger warnings, and the warnings > re-enabled, or > > B) The warnings (or a subset of them) kept disabled, but a comment > added to the makefile describing why this is the proper course of action. > > Not all bugs might be worth fixing. For instance, the GCC warnings > type-limits, sign-compare, pointer-to-int-cast, conversion-null, > deprecated-declarations, clobbered, int-to-pointer-cast and > type-limits are all more or less benign, and is possibly the result of > a false positive. Right, although for some of these it is important to double check. Do you plan to paste in the warnings into the bugs that you will create? That wold be useful as warnings are a moving target. -Alan From xuelei.fan at oracle.com Wed Mar 4 14:51:17 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 04 Mar 2015 22:51:17 +0800 Subject: Code review of JDK-8072385, Only the first DNSName entry is checked for endpoint identification Message-ID: <54F71BE5.2050205@oracle.com> Hi, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8072385 In SunJSSE implementation, during endpoint identification, there is a bug in SubjectAlternativeName matching that only the fist DNSName are checked. As may impact some business where host-name alias are used. The patch is attached. Thanks, Xuelei -------------- next part -------------- A non-text attachment was scrubbed... Name: ClientHandshaker.patch Type: text/x-patch Size: 5798 bytes Desc: not available URL: From magnus.ihse.bursie at oracle.com Wed Mar 4 15:03:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 04 Mar 2015 16:03:20 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F70D42.3010905@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> Message-ID: <54F71EB8.3030109@oracle.com> On 2015-03-04 14:48, Alan Bateman wrote: > On 04/03/2015 13:17, Magnus Ihse Bursie wrote: >> : >> >> I intend to file individual bugs to handle these remaining warnings, >> so the net result will be a completely warning free build. >> >> I also intend to file individual bugs on all the libraries that has >> had warnings disabled. I expect the outcome of these bugs to be either: >> >> A) The code modified so it does not trigger warnings, and the >> warnings re-enabled, or >> >> B) The warnings (or a subset of them) kept disabled, but a comment >> added to the makefile describing why this is the proper course of >> action. >> >> Not all bugs might be worth fixing. For instance, the GCC warnings >> type-limits, sign-compare, pointer-to-int-cast, conversion-null, >> deprecated-declarations, clobbered, int-to-pointer-cast and >> type-limits are all more or less benign, and is possibly the result >> of a false positive. > Right, although for some of these it is important to double check. I believe all warnings are important to check! Unfortunately, this has not been done for a lot of warnings for a lot of time. :( With this framework, it is simple to enable a single warning, recompile and see the effect. Hopefully this lowers the threshold far enough so that all warnings are given proper attention. The incremental build functionality will come in very handy. Just by simply removing a warning from the DISABLED_WARNINGS_ on a library and running "make" again, only the files affected will be recompiled. > > Do you plan to paste in the warnings into the bugs that you will > create? That wold be useful as warnings are a moving target. I can easily paste in what warning categories are disabled for a specific library, yes. However, if you are asking me to build each library, individually, with warnings re-enabled, and pasting the output, I'd rather not. That would be a lot of work, to detangle the output of each individual library. /Magnus From tim.bell at oracle.com Wed Mar 4 16:19:32 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 04 Mar 2015 08:19:32 -0800 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F70949.4040900@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com> Message-ID: <54F73094.8020108@oracle.com> Magnus: Looks good to me as well. Tim On 03/04/15 05:31, Erik Joelsson wrote: > Hello, > > Really nice to finally see this patch getting done! > > Only one comment: > > flags.m4: > In the grep expression, could you move the extra [] outside of the > actual command line options to grep so that the command line could be > copied to the shell for debugging in the future? Also, how hard would > it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead > test for capability? > > /Erik > > On 2015-03-04 14:17, Magnus Ihse Bursie wrote: >> When building the native code in the jdk repo, a lot of warnings are >> generated. So many that it's hard to spot any new issues. >> >> While the ultimate goal must be to address and fix these warnings >> individually, this bug is about disabling these warnings where they >> occur, so that it is easier to spot new warnings, and that the >> existing warnings can be addressed one at a time. >> >> Disabling warnings instead of fixing them can be problematic. If you >> are too broad with disabling warnings, you might hide future >> problems. On the other hand, there have been a lot of warnings that >> indicate serious problems that has been "hidden in plain sight" for a >> very long time in the code base anyway. >> >> I have opted to disable warnings at the library level. Disabling >> warnings globally would be too broad. Disabling per file would have >> been too tedious. Many warnings also tend to repeat across multiple >> files in the same library, due to e.g. less well-suited programming >> style or design choice. A library also seems like a suitable chunk of >> work to address later on, in trying to get rid of the source of the >> warnings. >> >> This fix will not get rid of all warnings, but the bulk of them. It >> will make the remaining warnings stick out more. The few warnings >> that remain are either: >> * Not possible to disable. >> * Not resulting from native compilation (but from linking, or >> javadoc, etc). >> * Not possible to disable with this framework (this goes for builds >> on pre-4.4 gcc, which Oracle currently does as default on macosx), >> and libfontmanager on Solaris, which mixes C and C++ code. (While the >> solstudio C compiler does not fail on requests to disable C++ >> warnings, the converse is unfortunately not true). It did not seem >> worth the trouble to build a more extensible framework to handle >> this, compared to actually fixing these warnings. >> >> Note that the current JPRT build environment in Oracle uses a pre-4.4 >> gcc for macosx by default, so the default macosx build will still >> contain warnings. When building with --with-toolchain-type=clang, the >> clang warning disabling kicks in. (This will be the default in JPRT >> later on this year.) >> >> I intend to file individual bugs to handle these remaining warnings, >> so the net result will be a completely warning free build. >> >> I also intend to file individual bugs on all the libraries that has >> had warnings disabled. I expect the outcome of these bugs to be either: >> >> A) The code modified so it does not trigger warnings, and the >> warnings re-enabled, or >> >> B) The warnings (or a subset of them) kept disabled, but a comment >> added to the makefile describing why this is the proper course of >> action. >> >> Not all bugs might be worth fixing. For instance, the GCC warnings >> type-limits, sign-compare, pointer-to-int-cast, conversion-null, >> deprecated-declarations, clobbered, int-to-pointer-cast and >> type-limits are all more or less benign, and is possibly the result >> of a false positive. >> >> On the other hands, warnings such as format-nonliteral, >> unused-result, maybe-uninitialized, format, format-security, >> int-to-pointer-cast, reorder and delete-non-virtual-dtor are more >> likely to actually point to real issues. I recommend anyone finding >> these warnings on a library they care about to try and fix them as >> soon as possible. >> >> Here is a summary of the libraries and binaries that have gotten >> warnings disabled. I'm not sure about what group owns all these >> libraries; if I missed sending this mail to the correct list, please >> help me and forward it. >> >> * libunpack >> * libfdlibm >> * libverify >> * libjava >> * libzip >> * libjli/libjli_static >> * libj2gss >> * libsunec >> * libj2pkcs11 >> * libnet >> * libnio >> * libosxkrb5 >> * libosxapp >> * libosx >> * libapplescriptengine >> * libjsound >> * libjsoundalsa >> * libmlib_image >> * libawt >> * libawt_xawt >> * libawt_lwawt >> * liblcms >> * libjavajpeg >> * libawt_headless >> * libfontmanager >> * libsplashscreen >> * unpack200 >> * The JVMTI demos compiledMethodLoad and waiters >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096 >> >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01 >> >> /Magnus >> > From Alan.Bateman at oracle.com Wed Mar 4 16:30:47 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 04 Mar 2015 16:30:47 +0000 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F71EB8.3030109@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> <54F71EB8.3030109@oracle.com> Message-ID: <54F73337.3090309@oracle.com> On 04/03/2015 15:03, Magnus Ihse Bursie wrote: > I believe all warnings are important to check! Unfortunately, this has > not been done for a lot of warnings for a lot of time. :( Right, although in the past we had some areas close to be cleared of warnings, it's just that we didn't keep up the effort and of course the compilers get more pedantic with each version. > > With this framework, it is simple to enable a single warning, > recompile and see the effect. Hopefully this lowers the threshold far > enough so that all warnings are given proper attention. The > incremental build functionality will come in very handy. Just by > simply removing a warning from the DISABLED_WARNINGS_ on a > library and running "make" again, only the files affected will be > recompiled. Yes, it looks easy to maintain. > > I can easily paste in what warning categories are disabled for a > specific library, yes. > > However, if you are asking me to build each library, individually, > with warnings re-enabled, and pasting the output, I'd rather not. That > would be a lot of work, to detangle the output of each individual > library. I'm not asking that, it would be too much work. Maybe it's worth saving the logs somewhere so that you can point the bugs at it. It would also be useful for the bugs to point to your change sets (when they are pushed) so that it's obvious which make files were changed to silence the warnings. -Alan From sean.mullan at oracle.com Wed Mar 4 17:47:57 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 04 Mar 2015 12:47:57 -0500 Subject: RFR 8072394: java.security.cert.PolicyQualifierInfo needs value-based equality In-Reply-To: <54F4728E.7070405@redhat.com> References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com> <54DE5B96.9000704@redhat.com> <54E26B6C.3040202@oracle.com> <54E35086.7090408@redhat.com> <54E7B3D1.4070402@oracle.com> <54F4728E.7070405@redhat.com> Message-ID: <54F7454D.4050906@oracle.com> On 03/02/2015 09:24 AM, Florian Weimer wrote: > On 02/20/2015 11:23 PM, Sean Mullan wrote: >> On 02/17/2015 09:30 AM, Florian Weimer wrote: >>> On 02/16/2015 11:13 PM, Sean Mullan wrote: >>> >>>>> Based on that, PolicyQualifierInfo should have implemented value-based >>>>> equals() and hashCode(), and the identity-based set is just a bug. >>>>> (But >>>>> the requirement I cited is a stronger requirement the Set would not >>>>> enforce.) >>>>> >>>>> However, I think it's too late to fix this bug now. That's why I just >>>>> added the identity counter. If you want the behavioral change instead, >>>>> I can implement that as well. >>>> >>>> Maybe it's not too late. This is not a commonly used class, and the >>>> compatibility risk is probably fairly low. If you code up the changes, I >>>> can file a CCC on your behalf. >>> >>> Updated webrev: >> >> You need to add a description for the overridden equals/hashCode >> methods, ex: > > Okay, I didn't know that. > > I don't like specifying the hash code so strongly. What about adding it as an @implNote? > But if we want to > fix it at Arrays.hashCode(byte[]), it's probably better to implement > Comparable as well, to aid the collision resolution in HashMap. The new > webrev does that: > > There is a typo on line 203: s/orded/ordered Also, while you are in there, can you add an @Override to toString. I can take care of filing an internal CCC and will let you know when that is approved or if there are any questions. --Sean > I also compute the hashcode unconditionally in the constructor because > PolicyQualifierInfo objects are used with sets, so their hashcode is so > often needed. > > Funny how I wanted to make things go faster, and ended up introducing a > slowdown. But correctness over performance. > > Most policy qualifier sets in X.509 certificates seem to have just one > element, so I looked at optimizing that, but there's a lot of copying > going on inside the implementation, and I'd have to special-case the one > element case in multiple locations. Switching from a HashSet to a > TreeSet would be externally visible, so that doesn't seem to be a good > idea, either. > > We need an optimized immutable set class in the JDK. :-) > From jason.uh at oracle.com Wed Mar 4 19:02:07 2015 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 04 Mar 2015 11:02:07 -0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded Message-ID: <54F756AF.7060906@oracle.com> webrev: http://cr.openjdk.java.net/~juh/8073430/00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. Two methods HandshakeCompletedEvent.getPeerCertificateChain SSLSession.getPeerCertificateChain that return the javax.security.cert.X509Certificate type will also be deprecated. The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. Thanks, Jason From gitne at gmx.de Wed Mar 4 20:26:42 2015 From: gitne at gmx.de (Jacob Wisor) Date: Wed, 04 Mar 2015 21:26:42 +0100 Subject: [rfc][jdk8u/jdk] Disable broken crypto algorithms (sane defaults) Message-ID: <54F76A82.6020903@gmx.de> Hello there! Please review this patch disabling deprecated, broken, or, insecure crypto algorithms. I think it is fair to say that these should be sane defaults by now, similar to what main web browser vendors do. AFAIKT, JDK 8 ships with only one legacy MD5withRSA signed certificate which is from the GTE CyberTrust Global Root CA. All other CAs have moved to SHA1 or SHA256 signatures. So this certificate would have to be replaced by package maintainers and/or release engineers. If it is too late for JDK 8 then JDK 9 should definitely deploy with these defaults. Regards, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: DisableBrokenCryptoAlgorithms.patch Type: text/x-patch Size: 4099 bytes Desc: not available URL: From philip.race at oracle.com Wed Mar 4 21:31:34 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 04 Mar 2015 13:31:34 -0800 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F73337.3090309@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> <54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com> Message-ID: <54F779B6.1000503@oracle.com> I like the overall approach. We can then attack the warnings lib by lib and/or platform by platform. I do want to mention that some libs like liblcms are 3rd party open source libraries and it may not always be possible to convince upstream to change their code. -phil. On 03/04/2015 08:30 AM, Alan Bateman wrote: > On 04/03/2015 15:03, Magnus Ihse Bursie wrote: >> I believe all warnings are important to check! Unfortunately, this >> has not been done for a lot of warnings for a lot of time. :( > Right, although in the past we had some areas close to be cleared of > warnings, it's just that we didn't keep up the effort and of course > the compilers get more pedantic with each version. > >> >> With this framework, it is simple to enable a single warning, >> recompile and see the effect. Hopefully this lowers the threshold far >> enough so that all warnings are given proper attention. The >> incremental build functionality will come in very handy. Just by >> simply removing a warning from the DISABLED_WARNINGS_ on a >> library and running "make" again, only the files affected will be >> recompiled. > Yes, it looks easy to maintain. > > >> >> I can easily paste in what warning categories are disabled for a >> specific library, yes. >> >> However, if you are asking me to build each library, individually, >> with warnings re-enabled, and pasting the output, I'd rather not. >> That would be a lot of work, to detangle the output of each >> individual library. > I'm not asking that, it would be too much work. Maybe it's worth > saving the logs somewhere so that you can point the bugs at it. It > would also be useful for the bugs to point to your change sets (when > they are pushed) so that it's obvious which make files were changed to > silence the warnings. > > -Alan From jamil.j.nimeh at oracle.com Wed Mar 4 22:50:14 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 04 Mar 2015 14:50:14 -0800 Subject: RFR: [Update 2] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <54F64D7E.4080802@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> <54F64D7E.4080802@oracle.com> Message-ID: <54F78C26.8090207@oracle.com> One more round of updates. Only the test code and the test inputs have changed. Test input is now Base64 format, with comment headers that display the OCSP response pretty-print (or an asn1parse of the BasicOCSPResponse for malformed response test cases). http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.03/index.html Thanks, Vinnie for the feedback and suggestions! --Jamil On 03/03/2015 04:10 PM, Jamil Nimeh wrote: > Okay, I've got an updated webrev for this issue: > http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html > > Thanks, > --Jamil > > On 03/03/2015 02:18 PM, Jamil Nimeh wrote: >> Hello all, I've come across a couple edge cases that this fix doesn't >> cover properly. I'll put out another webrev in a bit that should >> tighten up the singleResponse parsing, particularly with the optional >> fields. It will also include a couple other negative test input samples. >> >> Thanks, >> --Jamil >> >> On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >>> Hello all, this review fixes an issue in OCSPResponse where it does >>> not parse singleExtensions in the SingleResponse structure. I also >>> fixed two minor deviations from the OCSP.RevocationStatus interface >>> when getRevocationTime and getRevocationReason are called on good >>> responses. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >>> Review: >>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >>> >>> Thank you, >>> --Jamil >> > From mandy.chung at oracle.com Thu Mar 5 01:13:50 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Mar 2015 17:13:50 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules Message-ID: <54F7ADCE.50900@oracle.com> As listed in an open issue in JEP 200: The jdk.dev and jdk.runtime modules contain miscellaneous tools that do not obviously belong to any other module; these modules will eventually be either renamed or refactored. Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in the JDK that are organized around its primary tool. Such organization is easy to name, document and understand. This patch proposes to move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, jdk.policytool modules. Overall Webrev that will be convenient to review the build change and modules.xml change. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ Separate webrevs for each issue: 1. pack200, unpack200 to jdk.pack200 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ 2. jar, jarsigner to jdk.jartool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ 3. policytool to jdk.policytool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ There are remaining tools in jdk.dev that will be handled separately. jdk.dev will disappear when all of the remaining tools find its home. Mandy From weijun.wang at oracle.com Thu Mar 5 02:55:26 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 10:55:26 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. So what I am suggesting is - Create jdk.security.util - Move jarsigner, policytool to jdk.security.util - Create the new APIs in this module - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). Or, we can break it into jdk.security.tools and jdk.security.util. Put the executables into tools and APIs into util. --Max > On Mar 5, 2015, at 09:13, Mandy Chung wrote: > > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From weijun.wang at oracle.com Thu Mar 5 03:14:48 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 11:14:48 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54F756AF.7060906@oracle.com> References: <54F756AF.7060906@oracle.com> Message-ID: Hi Jason I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.* classes and it makes me feel uncomfortable. The usage of this annotation, if I understand correctly, means we know we should not use it but we have to use it because we are lazy or there are no better alternatives. I highly doubt if any is the case here. So, we should investigate how those methods are used. If they are strictly internal (not jdk.exported) and not used inside JDK, remove them since they will be inaccessible anymore in jdk9. If they are still used somewhere, consider rewriting them (maybe in another fix). If they are jdk.exported, rewrite if the deprecated interfaces is not shown in the API itself (type or argument or return), otherwise, @deprecate them also. Thanks Max > On Mar 5, 2015, at 03:02, Jason Uh wrote: > > webrev: http://cr.openjdk.java.net/~juh/8073430/00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 > > Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. > > For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. > > Two methods > > HandshakeCompletedEvent.getPeerCertificateChain > SSLSession.getPeerCertificateChain > > that return the javax.security.cert.X509Certificate type will also be deprecated. > > The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. > > Thanks, > Jason From mandy.chung at oracle.com Thu Mar 5 03:25:16 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Mar 2015 19:25:16 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: References: <54F7ADCE.50900@oracle.com> Message-ID: <54F7CC9C.2020500@oracle.com> On 3/4/2015 6:55 PM, Wang Weijun wrote: > I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. Are you referring to these 2 RFEs? https://bugs.openjdk.java.net/browse/JDK-8056174 https://bugs.openjdk.java.net/browse/JDK-8058778 We have to see the details and webrev to comment on your proposed jdk.security.tools and jdk.security.util modules. There is no issue in keeping a CLI like keytool in java.base. What is your concern? policytool is a GUI app that depends on java.desktop module. If you move jarsigner, policytool and keytool, this new module would require java.desktop to be present to be used. Mandy > So what I am suggesting is > > - Create jdk.security.util > - Move jarsigner, policytool to jdk.security.util > - Create the new APIs in this module > - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). > > Or, we can break it into jdk.security.tools and jdk.security.util. Put the executables into tools and APIs into util. > > --Max > >> On Mar 5, 2015, at 09:13, Mandy Chung wrote: >> >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> From weijun.wang at oracle.com Thu Mar 5 03:33:12 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 11:33:12 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7CC9C.2020500@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F7CC9C.2020500@oracle.com> Message-ID: > On Mar 5, 2015, at 11:25, Mandy Chung wrote: > > > On 3/4/2015 6:55 PM, Wang Weijun wrote: >> I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. > > Are you referring to these 2 RFEs? > https://bugs.openjdk.java.net/browse/JDK-8056174 > https://bugs.openjdk.java.net/browse/JDK-8058778 > > We have to see the details and webrev to comment on your > proposed jdk.security.tools and jdk.security.util modules. Still in design, but you can look at it at http://cr.openjdk.java.net/~weijun/8058778/webrev.00. Or you can read the CCCs. > > There is no issue in keeping a CLI like keytool in java.base. > What is your concern? I just think keytool and jarsigner should stay together. :-) > > policytool is a GUI app that depends on java.desktop module. > If you move jarsigner, policytool and keytool, this new module > would require java.desktop to be present to be used. Correct. Put it in its own module. --Max > > Mandy From Alan.Bateman at oracle.com Thu Mar 5 08:23:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:23:50 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: References: <54F7ADCE.50900@oracle.com> Message-ID: <54F81296.5080006@oracle.com> On 05/03/2015 02:55, Wang Weijun wrote: > - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). > > The reason that keytool is in java.base is so that keys and certificates can be managed on a small runtime. It's the same reason that it is in our compact1 builds too. I wasn't aware of JDK-8058778 but it can't result in java.base exporting a JDK-specific API. -Alan From Alan.Bateman at oracle.com Thu Mar 5 08:31:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:31:31 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F81463.7000903@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > : > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > I think this looks okay. In the unshuffle_list (for back/forward porting patches) then it lists specific files, I wonder if we can move that to directories. I also see remnants of the tracing API in that file, I assume they can be removed. -Alan. From Alan.Bateman at oracle.com Thu Mar 5 08:35:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:35:11 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F8153F.9060301@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > This part looks good to me. -Alan From chris.hegarty at oracle.com Thu Mar 5 09:05:31 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Mar 2015 09:05:31 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81463.7000903@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81463.7000903@oracle.com> Message-ID: On 5 Mar 2015, at 08:31, Alan Bateman wrote: > On 05/03/2015 01:13, Mandy Chung wrote: >> : >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > I think this looks okay. In the unshuffle_list (for back/forward porting patches) then it lists specific files, I wonder if we can move that to directories. It should be possible to reduced the following set down from: jdk/src/jdk.pack200/share/native/common-unpack/bands.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/bands.cpp jdk/src/jdk.pack200/share/native/common-unpack/bands.h : jdk/src/share/native/com/sun/java/util/jar/pack/bands.h jdk/src/jdk.pack200/share/native/common-unpack/bytes.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/bytes.cpp jdk/src/jdk.pack200/share/native/common-unpack/bytes.h : jdk/src/share/native/com/sun/java/util/jar/pack/bytes.h jdk/src/jdk.pack200/share/native/common-unpack/coding.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/coding.cpp jdk/src/jdk.pack200/share/native/common-unpack/coding.h : jdk/src/share/native/com/sun/java/util/jar/pack/coding.h jdk/src/jdk.pack200/share/native/common-unpack/constants.h : jdk/src/share/native/com/sun/java/util/jar/pack/constants.h jdk/src/jdk.pack200/share/native/common-unpack/defines.h : jdk/src/share/native/com/sun/java/util/jar/pack/defines.h jdk/src/jdk.pack200/share/native/common-unpack/unpack.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/unpack.cpp jdk/src/jdk.pack200/share/native/common-unpack/unpack.h : jdk/src/share/native/com/sun/java/util/jar/pack/unpack.h jdk/src/jdk.pack200/share/native/common-unpack/utils.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/utils.cpp jdk/src/jdk.pack200/share/native/common-unpack/utils.h : jdk/src/share/native/com/sun/java/util/jar/pack/utils.h jdk/src/jdk.pack200/share/native/common-unpack/zip.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp jdk/src/jdk.pack200/share/native/common-unpack/zip.h : jdk/src/share/native/com/sun/java/util/jar/pack/zip.h to jdk/src/jdk.pack200/share/native/common-unpack : jdk/src/share/native/com/sun/java/util/jar/pack ...since the script attempts to match the full path, before reducing. I did mean to do further reductions on this shuffle list, but it just doesn?t seem worth it now, and care needs to be taken to ensure both shuffling and unshuffling work correctly. -Chris. > I also see remnants of the tracing API in that file, I assume they can be removed. > > -Alan. From weijun.wang at oracle.com Thu Mar 5 09:13:19 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 05 Mar 2015 17:13:19 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81296.5080006@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> Message-ID: <54F81E2F.7010000@oracle.com> There is no problem the new API be in a separate module. It is independent of keytool now. Said that, I've been thinking about rewriting keytool to use this new API. --Max On 3/5/2015 16:23, Alan Bateman wrote: > On 05/03/2015 02:55, Wang Weijun wrote: >> - Move keytool to jdk.security.util, it's now in java.base but keytool >> is not part of Java SE spec (Of course, if that means keytool will be >> in JDK instead of JRE please stop. But will there will the name >> difference anymore? I am thinking of an installer like cygwin that you >> can choose anything except that java.base is checked grayed). >> >> > The reason that keytool is in java.base is so that keys and certificates > can be managed on a small runtime. It's the same reason that it is in > our compact1 builds too. I wasn't aware of JDK-8058778 but it can't > result in java.base exporting a JDK-specific API. > > -Alan From erik.joelsson at oracle.com Thu Mar 5 09:25:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:25:06 +0100 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F820F2.8070009@oracle.com> Hello Mandy, The build changes look ok to me. /Erik On 2015-03-05 02:13, Mandy Chung wrote: > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From Alan.Bateman at oracle.com Thu Mar 5 16:07:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 16:07:04 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F87F28.2080904@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > : > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > It seems reasonable to have both jar and jarsigner in the same module so I think this is good. This will also work if Max adds an API to the jarsigner tool as he mentioned in one of the mails. -Alan From mandy.chung at oracle.com Thu Mar 5 16:19:23 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Mar 2015 08:19:23 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81463.7000903@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81463.7000903@oracle.com> Message-ID: <54F8820B.2050201@oracle.com> On 3/5/2015 12:31 AM, Alan Bateman wrote: > On 05/03/2015 01:13, Mandy Chung wrote: >> : >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> > I think this looks okay. In the unshuffle_list (for back/forward > porting patches) then it lists specific files, I wonder if we can move > that to directories. I also see remnants of the tracing API in that > file, I assume they can be removed. I also notice the tracing API left in unshuffle_list should be removed. At some point the entire jdk.dev should go away and so I'm thinking to leave this cleanup for the removal of jdk.dev. Mandy From mandy.chung at oracle.com Thu Mar 5 17:55:44 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Mar 2015 09:55:44 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81E2F.7010000@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> <54F81E2F.7010000@oracle.com> Message-ID: <54F898A0.90707@oracle.com> Max, Since the new APIs you're working on are still in design phase, I think it's a bit early to discuss where these new APIs should be in. Just one thing to say about the new JarSigner API from your webrev. com.sun.jarsigner is an existing exported package that you should consider whether the new APIs should be added there rather than a new package. Anyway, we can discuss that when your work is further along. For this review request, are you okay with this patch moving policytool and jarsigner tools to the new home? Mandy [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/85b61f4eee66/src/jdk.dev/share/classes/com/sun/jarsigner/package-info.java On 3/5/15 1:13 AM, Weijun Wang wrote: > There is no problem the new API be in a separate module. It is > independent of keytool now. > > Said that, I've been thinking about rewriting keytool to use this new > API. > > --Max > > On 3/5/2015 16:23, Alan Bateman wrote: >> On 05/03/2015 02:55, Wang Weijun wrote: >>> - Move keytool to jdk.security.util, it's now in java.base but keytool >>> is not part of Java SE spec (Of course, if that means keytool will be >>> in JDK instead of JRE please stop. But will there will the name >>> difference anymore? I am thinking of an installer like cygwin that you >>> can choose anything except that java.base is checked grayed). >>> >>> >> The reason that keytool is in java.base is so that keys and certificates >> can be managed on a small runtime. It's the same reason that it is in >> our compact1 builds too. I wasn't aware of JDK-8058778 but it can't >> result in java.base exporting a JDK-specific API. >> >> -Alan From sean.mullan at oracle.com Thu Mar 5 21:35:04 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 05 Mar 2015 16:35:04 -0500 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54F756AF.7060906@oracle.com> References: <54F756AF.7060906@oracle.com> Message-ID: <54F8CC08.6070406@oracle.com> Looks good, Jason, just a couple of comments: - Add an @Deprecated annotation to the package-info.java files since the entire package is deprecated. Put {@code} around the package/class names. - add a noreg label to the bug --Sean On 03/04/2015 02:02 PM, Jason Uh wrote: > webrev: http://cr.openjdk.java.net/~juh/8073430/00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 > > Please review this change, which deprecates the classes in > java.security.acl and javax.security.cert. These packages have been > superseded by replacements for a long time. > > For java.security.acl, there have been replacement APIs available since > JDK 1.2 in java.security.Policy and related classes. For > javax.security.cert, replacements have existed in java.security.cert > since JDK 1.4. These replacements have been noted in the javadocs, so > applications using these old APIs have had plenty of time to migrate. > > Two methods > > HandshakeCompletedEvent.getPeerCertificateChain > SSLSession.getPeerCertificateChain > > that return the javax.security.cert.X509Certificate type will also be > deprecated. > > The change also includes deprecation warning suppression in a few areas, > including sun.net.www.protocol.https. > > Thanks, > Jason From weijun.wang at oracle.com Fri Mar 6 01:16:46 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 09:16:46 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F898A0.90707@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> <54F81E2F.7010000@oracle.com> <54F898A0.90707@oracle.com> Message-ID: <8BCFD039-161B-42EE-9638-6E81E3B62F0C@oracle.com> > On Mar 6, 2015, at 01:55, Mandy Chung wrote: > > For this review request, are you okay with this patch moving policytool and jarsigner tools to the new home? Yes. --Max From xuelei.fan at oracle.com Fri Mar 6 02:20:35 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 06 Mar 2015 10:20:35 +0800 Subject: Code review of JDK-8072385, Only the first DNSName entry is checked for endpoint identification In-Reply-To: <54F71BE5.2050205@oracle.com> References: <54F71BE5.2050205@oracle.com> Message-ID: <54F90EF3.70105@oracle.com> webrev: http://cr.openjdk.java.net/~xuelei/8072385/webrev.00/ On 3/4/2015 10:51 PM, Xuelei Fan wrote: > Hi, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8072385 > > In SunJSSE implementation, during endpoint identification, there is a > bug in SubjectAlternativeName matching that only the fist DNSName are > checked. As may impact some business where host-name alias are used. > > The patch is attached. > > Thanks, > Xuelei > From jason.uh at oracle.com Fri Mar 6 04:01:20 2015 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 05 Mar 2015 20:01:20 -0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: References: <54F756AF.7060906@oracle.com> Message-ID: <54F92690.2070301@oracle.com> Hi Max, A couple of these, we probably won't be able to remove in JDK 9. I'm deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession interface in this change, so the implementation in sun.security.ssl.SSLSessionImpl will have to be suppressed. Also, X509V1CertImpl will probably have to be marked with @SupressWarnings in JDK 9 and then hopefully it can be removed altogether in JDK 10 along with javax.security.cert. As for some of the other methods causing warnings, I think they can actually be removed, but I'd like to track that change in a different issue. I'm not sure yet, but there might have to be some minor test changes to accommodate the changes, too. I filed an issue to track it: https://bugs.openjdk.java.net/browse/JDK-8074531 For now, here are my changes again with Sean's suggested changes to the package-info.java files. http://cr.openjdk.java.net/~juh/8073430/01/ Thanks, Jason On 03/04/2015 07:14 PM, Wang Weijun wrote: > Hi Jason > > I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.* classes and it makes me feel uncomfortable. The usage of this annotation, if I understand correctly, means we know we should not use it but we have to use it because we are lazy or there are no better alternatives. I highly doubt if any is the case here. > > So, we should investigate how those methods are used. If they are strictly internal (not jdk.exported) and not used inside JDK, remove them since they will be inaccessible anymore in jdk9. If they are still used somewhere, consider rewriting them (maybe in another fix). If they are jdk.exported, rewrite if the deprecated interfaces is not shown in the API itself (type or argument or return), otherwise, @deprecate them also. > > Thanks > Max > >> On Mar 5, 2015, at 03:02, Jason Uh wrote: >> >> webrev: http://cr.openjdk.java.net/~juh/8073430/00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 >> >> Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. >> >> For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. >> >> Two methods >> >> HandshakeCompletedEvent.getPeerCertificateChain >> SSLSession.getPeerCertificateChain >> >> that return the javax.security.cert.X509Certificate type will also be deprecated. >> >> The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. >> >> Thanks, >> Jason > From weijun.wang at oracle.com Fri Mar 6 05:30:54 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 13:30:54 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54F92690.2070301@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> Message-ID: <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? If I understand correctly, there should be no warning if a deprecated method calls another deprecated method. And by deprecating the caller we will get warnings if they are called by more methods and we can evaluate if they can be further deprecated or modified. This way we would reveal everything that is related with the deprecated APIs. Hopefully they are actually useless inside JDK. --Max > On Mar 6, 2015, at 12:01, Jason Uh wrote: > > Hi Max, > > A couple of these, we probably won't be able to remove in JDK 9. I'm deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession interface in this change, so the implementation in sun.security.ssl.SSLSessionImpl will have to be suppressed. Also, X509V1CertImpl will probably have to be marked with @SupressWarnings in JDK 9 and then hopefully it can be removed altogether in JDK 10 along with javax.security.cert. > > As for some of the other methods causing warnings, I think they can actually be removed, but I'd like to track that change in a different issue. I'm not sure yet, but there might have to be some minor test changes to accommodate the changes, too. I filed an issue to track it: > https://bugs.openjdk.java.net/browse/JDK-8074531 > > For now, here are my changes again with Sean's suggested changes to the package-info.java files. > http://cr.openjdk.java.net/~juh/8073430/01/ > > Thanks, > Jason From weijun.wang at oracle.com Fri Mar 6 05:32:16 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 13:32:16 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> Message-ID: <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> What is the policy for deprecating a non-public-API method? > On Mar 6, 2015, at 13:30, Wang Weijun wrote: > > Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? From weijun.wang at oracle.com Fri Mar 6 10:07:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 18:07:45 +0800 Subject: Reading a pkcs12 keystore always need storepass Message-ID: <95C9D8C0-42C7-47F6-9B05-3BA5EB397204@oracle.com> Hi Vinnie I noticed that without providing a storepass, all certificates in a pkcs12 keystore is invisible, i.e. no TrustedCertEntry and PrivateKeyEntry has no cert. This is quite different from the jks storetype. Is this avoidable? Thanks Max From vincent.x.ryan at oracle.com Fri Mar 6 11:49:21 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 6 Mar 2015 11:49:21 +0000 Subject: Reading a pkcs12 keystore always need storepass In-Reply-To: <95C9D8C0-42C7-47F6-9B05-3BA5EB397204@oracle.com> References: <95C9D8C0-42C7-47F6-9B05-3BA5EB397204@oracle.com> Message-ID: <37E29578-52C1-40FA-8104-D771BA3AF716@oracle.com> That?s right, a store password is required when creating and accessing a PKCS12 keystore. It is used to en-/decrypt the collection of certs in the keystore. A store password is also required when creating a JKS keystore. However, JKS permits a null password when accessing the keystore, to indicate that the keystore's integrity check can be skipped. If it helps then the PKCS12 implementation could be modified to use the empty password (??) when a null password is supplied. On 6 Mar 2015, at 10:07, Wang Weijun wrote: > Hi Vinnie > > I noticed that without providing a storepass, all certificates in a pkcs12 keystore is invisible, i.e. no TrustedCertEntry and PrivateKeyEntry has no cert. This is quite different from the jks storetype. Is this avoidable? > > Thanks > Max > From weijun.wang at oracle.com Fri Mar 6 14:00:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 22:00:45 +0800 Subject: Reading a pkcs12 keystore always need storepass In-Reply-To: <37E29578-52C1-40FA-8104-D771BA3AF716@oracle.com> References: <95C9D8C0-42C7-47F6-9B05-3BA5EB397204@oracle.com> <37E29578-52C1-40FA-8104-D771BA3AF716@oracle.com> Message-ID: > ? 2015?3?6??19:49?Vincent Ryan ??? > > If it helps then the PKCS12 implementation could be modified to use the empty password (??) > when a null password is supplied. I'm not suggesting this. It's just the behavior change might break some existing codes. When I try to export a cert, I never provide any password. Also, cacerts is still in JKS now, right? Are we going to make it pkcs12? And if so what will the password be? --Max From magnus.ihse.bursie at oracle.com Fri Mar 6 14:33:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:33:28 +0100 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F820F2.8070009@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F820F2.8070009@oracle.com> Message-ID: <54F9BAB8.1070601@oracle.com> On 2015-03-05 10:25, Erik Joelsson wrote: > Hello Mandy, > > The build changes look ok to me. Build changes are OK for me too. /Magnus > > /Erik > > On 2015-03-05 02:13, Mandy Chung wrote: >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> > From vincent.x.ryan at oracle.com Fri Mar 6 15:07:42 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 6 Mar 2015 15:07:42 +0000 Subject: Reading a pkcs12 keystore always need storepass In-Reply-To: References: <95C9D8C0-42C7-47F6-9B05-3BA5EB397204@oracle.com> <37E29578-52C1-40FA-8104-D771BA3AF716@oracle.com> Message-ID: Yes cacerts is still in the JKS format but that might change given the additional features and extensibility offered by PKCS12 keystores. Also, since the cacerts keystore contains only root CA certs its certs could be handled differently. For example, the certs could be stored unencrypted and/or separately from the regular certs. This would allow passwordless access but at the cost of interoperability. On 6 Mar 2015, at 14:00, Wang Weijun wrote: > >> ? 2015?3?6??19:49?Vincent Ryan ??? >> >> If it helps then the PKCS12 implementation could be modified to use the empty password (??) >> when a null password is supplied. > > I'm not suggesting this. It's just the behavior change might break some existing codes. When I try to export a cert, I never provide any password. > > Also, cacerts is still in JKS now, right? Are we going to make it pkcs12? And if so what will the password be? > > --Max From magnus.ihse.bursie at oracle.com Fri Mar 6 16:13:09 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 17:13:09 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F73337.3090309@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com> <54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com> Message-ID: <54F9D215.8090806@oracle.com> On 2015-03-04 17:30, Alan Bateman wrote: > On 04/03/2015 15:03, Magnus Ihse Bursie wrote: >> I believe all warnings are important to check! Unfortunately, this >> has not been done for a lot of warnings for a lot of time. :( > Right, although in the past we had some areas close to be cleared of > warnings, it's just that we didn't keep up the effort and of course > the compilers get more pedantic with each version. > >> >> With this framework, it is simple to enable a single warning, >> recompile and see the effect. Hopefully this lowers the threshold far >> enough so that all warnings are given proper attention. The >> incremental build functionality will come in very handy. Just by >> simply removing a warning from the DISABLED_WARNINGS_ on a >> library and running "make" again, only the files affected will be >> recompiled. > Yes, it looks easy to maintain. > > >> >> I can easily paste in what warning categories are disabled for a >> specific library, yes. >> >> However, if you are asking me to build each library, individually, >> with warnings re-enabled, and pasting the output, I'd rather not. >> That would be a lot of work, to detangle the output of each >> individual library. > I'm not asking that, it would be too much work. Maybe it's worth > saving the logs somewhere so that you can point the bugs at it. It > would also be useful for the bugs to point to your change sets (when > they are pushed) so that it's obvious which make files were changed to > silence the warnings. I'll try to locate a suitable way of storing the logs, and record a pointer to that in the bugs. I'll also link to the change set in the bugs as you request. /Magnus > > -Alan From magnus.ihse.bursie at oracle.com Fri Mar 6 16:14:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 17:14:57 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F70949.4040900@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com> Message-ID: <54F9D281.3030206@oracle.com> On 2015-03-04 14:31, Erik Joelsson wrote: > Hello, > > Really nice to finally see this patch getting done! > > Only one comment: > > flags.m4: > In the grep expression, could you move the extra [] outside of the > actual command line options to grep so that the command line could be > copied to the shell for debugging in the future? Also, how hard would > it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead > test for capability? I have updated the fix to use the eminent FLAGS_COMPILER_CHECK_ARGUMENTS instead. :-) http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02 /Magnus From jason.uh at oracle.com Sat Mar 7 05:05:03 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 06 Mar 2015 21:05:03 -0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> Message-ID: <54FA86FF.60201@oracle.com> While these methods are going to be removed soon anyway, @Deprecated actually seems like the more appropriate choice because we do want to discourage use of these methods, even if they are non-public APIs. Here it is with that change; please take a look: http://cr.openjdk.java.net/~juh/8073430/02/ Thanks, Jason On 03/05/2015 09:32 PM, Wang Weijun wrote: > What is the policy for deprecating a non-public-API method? > >> On Mar 6, 2015, at 13:30, Wang Weijun wrote: >> >> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? > From weijun.wang at oracle.com Mon Mar 9 07:05:53 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Mar 2015 15:05:53 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54FA86FF.60201@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> <54FA86FF.60201@oracle.com> Message-ID: <2AE37A92-7263-48AF-86AB-357D8D345483@oracle.com> Code change looks fine. Thanks Max > On Mar 7, 2015, at 13:05, Jason Uh wrote: > > While these methods are going to be removed soon anyway, @Deprecated actually seems like the more appropriate choice because we do want to discourage use of these methods, even if they are non-public APIs. > > Here it is with that change; please take a look: > http://cr.openjdk.java.net/~juh/8073430/02/ > > Thanks, > Jason > > On 03/05/2015 09:32 PM, Wang Weijun wrote: >> What is the policy for deprecating a non-public-API method? >> >>> On Mar 6, 2015, at 13:30, Wang Weijun wrote: >>> >>> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? >> From erik.joelsson at oracle.com Mon Mar 9 09:08:54 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Mar 2015 10:08:54 +0100 Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis In-Reply-To: <54F9D281.3030206@oracle.com> References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com> <54F9D281.3030206@oracle.com> Message-ID: <54FD6326.4070403@oracle.com> Thanks, looks good! /Erik On 2015-03-06 17:14, Magnus Ihse Bursie wrote: > On 2015-03-04 14:31, Erik Joelsson wrote: >> Hello, >> >> Really nice to finally see this patch getting done! >> >> Only one comment: >> >> flags.m4: >> In the grep expression, could you move the extra [] outside of the >> actual command line options to grep so that the command line could be >> copied to the shell for debugging in the future? Also, how hard would >> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead >> test for capability? > > I have updated the fix to use the eminent > FLAGS_COMPILER_CHECK_ARGUMENTS instead. :-) > > http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02 > > > /Magnus > From xuelei.fan at oracle.com Tue Mar 10 00:24:11 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Mar 2015 08:24:11 +0800 Subject: Code review of JDK-8072385, Only the first DNSName entry is checked for endpoint identification In-Reply-To: <54F71BE5.2050205@oracle.com> References: <54F71BE5.2050205@oracle.com> Message-ID: <54FE39AB.1080503@oracle.com> Ping ... wbrev: http://cr.openjdk.java.net/~xuelei/8072385/webrev.00/ On 3/4/2015 10:51 PM, Xuelei Fan wrote: > Hi, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8072385 > > In SunJSSE implementation, during endpoint identification, there is a > bug in SubjectAlternativeName matching that only the fist DNSName are > checked. As may impact some business where host-name alias are used. > > The patch is attached. > > Thanks, > Xuelei > From joe.darcy at oracle.com Tue Mar 10 00:56:41 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 09 Mar 2015 17:56:41 -0700 Subject: JDK 9 RFR of javadoc typo in PKCS8EncodedKeySpec Message-ID: <54FE4149.9050900@oracle.com> Hello, When doing a JDK docs build, I noticed a javadoc warning is reported for PKCS8EncodedKeySpec; the type is missing the "code" in a {@code ...} tag. Patch below. Upon successful review, I'll file a bug. Thanks, -Joe diff -r 439cf0adaf29 src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java --- a/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java Mon Mar 09 17:37:34 2015 -0700 +++ b/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java Mon Mar 09 17:55:01 2015 -0700 @@ -89,7 +89,7 @@ * Java Cryptography Architecture Standard Algorithm Name Documentation * for information about standard algorithm names. * @throws NullPointerException if {@code encodedKey} - * or {@algorithm} is null. + * or {@code algorithm} is null. * @throws IllegalArgumentException if {@code algorithm} is * the empty string {@code ""} * @since 1.9 From xuelei.fan at oracle.com Tue Mar 10 01:02:32 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Mar 2015 09:02:32 +0800 Subject: JDK 9 RFR of javadoc typo in PKCS8EncodedKeySpec In-Reply-To: <54FE4149.9050900@oracle.com> References: <54FE4149.9050900@oracle.com> Message-ID: <54FE42A8.5030005@oracle.com> Looks fine to me. Thanks! Xuelei On 3/10/2015 8:56 AM, joe darcy wrote: > Hello, > > When doing a JDK docs build, I noticed a javadoc warning is reported for > PKCS8EncodedKeySpec; the type is missing the "code" in a {@code ...} tag. > > Patch below. Upon successful review, I'll file a bug. > > Thanks, > > -Joe > > diff -r 439cf0adaf29 > src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java > --- > a/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java Mon > Mar 09 17:37:34 2015 -0700 > +++ > b/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java Mon > Mar 09 17:55:01 2015 -0700 > @@ -89,7 +89,7 @@ > * Java Cryptography Architecture Standard Algorithm Name > Documentation > * for information about standard algorithm names. > * @throws NullPointerException if {@code encodedKey} > - * or {@algorithm} is null. > + * or {@code algorithm} is null. > * @throws IllegalArgumentException if {@code algorithm} is > * the empty string {@code ""} > * @since 1.9 > From jason.uh at oracle.com Tue Mar 10 02:13:16 2015 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 09 Mar 2015 19:13:16 -0700 Subject: JDK 9 RFR of javadoc typo in PKCS8EncodedKeySpec In-Reply-To: <54FE4149.9050900@oracle.com> References: <54FE4149.9050900@oracle.com> Message-ID: <54FE533C.6020203@oracle.com> Hi Joe, Looks good to me. There actually is already a bug for this: https://bugs.openjdk.java.net/browse/JDK-8074673 Thanks for the fix, Jason On 3/9/15 5:56 PM, joe darcy wrote: > Hello, > > When doing a JDK docs build, I noticed a javadoc warning is reported for > PKCS8EncodedKeySpec; the type is missing the "code" in a {@code ...} tag. > > Patch below. Upon successful review, I'll file a bug. > > Thanks, > > -Joe > > diff -r 439cf0adaf29 > src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java > --- > a/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java Mon > Mar 09 17:37:34 2015 -0700 > +++ > b/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java Mon > Mar 09 17:55:01 2015 -0700 > @@ -89,7 +89,7 @@ > * Java Cryptography Architecture Standard Algorithm Name > Documentation > * for information about standard algorithm names. > * @throws NullPointerException if {@code encodedKey} > - * or {@algorithm} is null. > + * or {@code algorithm} is null. > * @throws IllegalArgumentException if {@code algorithm} is > * the empty string {@code ""} > * @since 1.9 > From joe.darcy at oracle.com Tue Mar 10 04:38:13 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 09 Mar 2015 21:38:13 -0700 Subject: JDK 9 RFR of javadoc typo in PKCS8EncodedKeySpec In-Reply-To: <54FE533C.6020203@oracle.com> References: <54FE4149.9050900@oracle.com> <54FE533C.6020203@oracle.com> Message-ID: <54FE7535.9050604@oracle.com> Hi Jason, Thanks for the notification; I've closed out the open bug as a duplicate of the fixed one. Cheers, -Joe On 3/9/2015 7:13 PM, Jason Uh wrote: > Hi Joe, > > Looks good to me. There actually is already a bug for this: > https://bugs.openjdk.java.net/browse/JDK-8074673 > > Thanks for the fix, > > Jason > > On 3/9/15 5:56 PM, joe darcy wrote: >> Hello, >> >> When doing a JDK docs build, I noticed a javadoc warning is reported for >> PKCS8EncodedKeySpec; the type is missing the "code" in a {@code ...} >> tag. >> >> Patch below. Upon successful review, I'll file a bug. >> >> Thanks, >> >> -Joe >> >> diff -r 439cf0adaf29 >> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java >> --- >> a/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java >> Mon >> Mar 09 17:37:34 2015 -0700 >> +++ >> b/src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java >> Mon >> Mar 09 17:55:01 2015 -0700 >> @@ -89,7 +89,7 @@ >> * Java Cryptography Architecture Standard Algorithm Name >> Documentation >> * for information about standard algorithm names. >> * @throws NullPointerException if {@code encodedKey} >> - * or {@algorithm} is null. >> + * or {@code algorithm} is null. >> * @throws IllegalArgumentException if {@code algorithm} is >> * the empty string {@code ""} >> * @since 1.9 >> > From alexander.v.stepanov at oracle.com Tue Mar 10 13:04:40 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 10 Mar 2015 16:04:40 +0300 Subject: [9] Review Request: 8028266 Tidy warnings cleanup for packages java.security/javax.security In-Reply-To: <535671A3.2070804@oracle.com> References: <5354EEE8.8040303@oracle.com> <535588E8.5080200@oracle.com> <535671A3.2070804@oracle.com> Message-ID: <54FEEBE8.8050907@oracle.com> Hello Bradford, I have finally to fix tidy warnings for java.security, javax.security, javax.crypto and javax.net packages (sorry for repeated request). Could you please review the webrev updated? http://cr.openjdk.java.net/~avstepan/8028266/webrev.02/ It was re-generated because of changes in JDK code layout and contains fixes for JDK-8040260, JDK-8028266. Could please anyone from JCE team suggest what should be done for the next step if the fixes are satisfactory? Thanks, Alexander On 22.04.2014 16:41, alexander stepanov wrote: > Hello Bradford, > > Thanks, > > Could you please review again: > http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.01/ > > > Who is going to help you with that? > I didn't communicate with JCE team before. So could you please appoint > me someone to contact? Thanks. > > Regards, > Alexander > > > On 22.04.2014 1:08, Bradford Wetmore wrote: >> We usually update the copyright dates: >> >> * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights >> reserved. >> >> javax/security/auth/kerberos/package-info.java >> ============================================== >> >> "yes", or "no", case-insensitive. >> -> >> "yes", or "no", and values are case-insensitive. >> >> I noticed in several places that while your changes are ok, it >> doesn't update the value instead of switching to {@code value}. >> >> In a previous webrev, I mentioned that you'll need to work with >> someone to update the built JCE binaries for the javax.crypto >> changes. Who is going to help you with that? >> >> Brad >> >> >> >> On 4/21/2014 3:11 AM, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the fix for the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8028266 >>> >>> Webrev corresponding: >>> http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.00/ >>> >>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >>> affected. >>> >>> Thanks. >>> >>> Regards, >>> Alexander > From kumar.x.srinivasan at oracle.com Tue Mar 10 17:23:48 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 10 Mar 2015 10:23:48 -0700 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54FF28A4.9080303@oracle.com> The changes look ok to me, however I am wondering if the module could be called jdk.unpack200 and not jdk.pack200 ? since it contains only the unpacker, and the bin utilities are pack200 and unpack200. Kumar On 3/4/2015 5:13 PM, Mandy Chung wrote: > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From gitne at gmx.de Tue Mar 10 18:50:02 2015 From: gitne at gmx.de (Jacob Wisor) Date: Tue, 10 Mar 2015 19:50:02 +0100 Subject: RFR: [jdk8u/jdk] Disable broken crypto algorithms (sane defaults) In-Reply-To: <54F76A82.6020903@gmx.de> References: <54F76A82.6020903@gmx.de> Message-ID: <54FF3CDA.5080203@gmx.de> Ping? On 03/04/2015 at 09:26 PM CET Jacob Wisor wrote: > Hello there! > > Please review this patch disabling deprecated, broken, or, insecure crypto > algorithms. I think it is fair to say that these should be sane defaults by now, > similar to what main web browser vendors do. > > AFAIKT, JDK 8 ships with only one legacy MD5withRSA signed certificate which is > from the GTE CyberTrust Global Root CA. All other CAs have moved to SHA1 or > SHA256 signatures. So this certificate would have to be replaced by package > maintainers and/or release engineers. > > If it is too late for JDK 8 then JDK 9 should definitely deploy with these > defaults. > > Regards, > > Jacob From sean.mullan at oracle.com Wed Mar 11 14:38:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 11 Mar 2015 10:38:33 -0400 Subject: RFR: [Update 2] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <54F78C26.8090207@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> <54F64D7E.4080802@oracle.com> <54F78C26.8090207@oracle.com> Message-ID: <55005369.207@oracle.com> Hi Jamil, Just a few comments, mostly minor. * OCSPResponse 768: there is an extra space in the indentation 811: use Collections.emptyMap instead of new HashMap<>() as that does not allocate a new Map object. 813-15,861-63: Use Map.values instead of Map.keySet, ex: for (Extension ext : singleExtensions.values()) { sb.append("singleExtension: " + ext + "\n"); } 784-807: I think this code could be compressed a bit to avoid calling parseExtensions twice. You can eliminate lines 786-92, if you do something like this (I think), starting at line 784: if (tmp.available() > 0) { derVal = tmp.getDerValue(); } else { derVal == null; } then what is now line 794 becomes: if (derVal != null && derVal.isContextSpecific((byte)1)) { --Sean On 03/04/2015 05:50 PM, Jamil Nimeh wrote: > One more round of updates. Only the test code and the test inputs have > changed. Test input is now Base64 format, with comment headers that > display the OCSP response pretty-print (or an asn1parse of the > BasicOCSPResponse for malformed response test cases). > > http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.03/index.html > > Thanks, Vinnie for the feedback and suggestions! > --Jamil > > On 03/03/2015 04:10 PM, Jamil Nimeh wrote: >> Okay, I've got an updated webrev for this issue: >> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html >> >> Thanks, >> --Jamil >> >> On 03/03/2015 02:18 PM, Jamil Nimeh wrote: >>> Hello all, I've come across a couple edge cases that this fix doesn't >>> cover properly. I'll put out another webrev in a bit that should >>> tighten up the singleResponse parsing, particularly with the optional >>> fields. It will also include a couple other negative test input samples. >>> >>> Thanks, >>> --Jamil >>> >>> On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >>>> Hello all, this review fixes an issue in OCSPResponse where it does >>>> not parse singleExtensions in the SingleResponse structure. I also >>>> fixed two minor deviations from the OCSP.RevocationStatus interface >>>> when getRevocationTime and getRevocationReason are called on good >>>> responses. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >>>> Review: >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >>>> >>>> Thank you, >>>> --Jamil >>> >> > From jamil.j.nimeh at oracle.com Wed Mar 11 14:55:24 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 11 Mar 2015 07:55:24 -0700 Subject: RFR: [Update 2] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <55005369.207@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> <54F64D7E.4080802@oracle.com> <54F78C26.8090207@oracle.com> <55005369.207@oracle.com> Message-ID: <5500575C.7080609@oracle.com> On 03/11/2015 07:38 AM, Sean Mullan wrote: > Hi Jamil, > > Just a few comments, mostly minor. > > * OCSPResponse > > 768: there is an extra space in the indentation > > 811: use Collections.emptyMap instead of new HashMap<>() as that does > not allocate a new Map object. > > 813-15,861-63: Use Map.values instead of Map.keySet, ex: > > for (Extension ext : singleExtensions.values()) { > sb.append("singleExtension: " + ext + "\n"); > } > Easily fixed, thanks! > 784-807: I think this code could be compressed a bit to avoid calling > parseExtensions twice. You can eliminate lines 786-92, if you do > something like this (I think), starting at line 784: > > if (tmp.available() > 0) { > derVal = tmp.getDerValue(); > } else { > derVal == null; > } > > then what is now line 794 becomes: > > if (derVal != null && derVal.isContextSpecific((byte)1)) { > I'll go back and take a crack at refactoring this and see if we can make it a bit more elegant. I had done something that used parseExtensions once initially using a loop but found that I mistakenly accepted a case where the two context-specific tags were both present, but reversed in their order. Regardless, I'll take a whack at it and see what happens. Thanks for the comments! --Jamil > --Sean > > On 03/04/2015 05:50 PM, Jamil Nimeh wrote: >> One more round of updates. Only the test code and the test inputs have >> changed. Test input is now Base64 format, with comment headers that >> display the OCSP response pretty-print (or an asn1parse of the >> BasicOCSPResponse for malformed response test cases). >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.03/index.html >> >> Thanks, Vinnie for the feedback and suggestions! >> --Jamil >> >> On 03/03/2015 04:10 PM, Jamil Nimeh wrote: >>> Okay, I've got an updated webrev for this issue: >>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html >>> >>> Thanks, >>> --Jamil >>> >>> On 03/03/2015 02:18 PM, Jamil Nimeh wrote: >>>> Hello all, I've come across a couple edge cases that this fix doesn't >>>> cover properly. I'll put out another webrev in a bit that should >>>> tighten up the singleResponse parsing, particularly with the optional >>>> fields. It will also include a couple other negative test input >>>> samples. >>>> >>>> Thanks, >>>> --Jamil >>>> >>>> On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >>>>> Hello all, this review fixes an issue in OCSPResponse where it does >>>>> not parse singleExtensions in the SingleResponse structure. I also >>>>> fixed two minor deviations from the OCSP.RevocationStatus interface >>>>> when getRevocationTime and getRevocationReason are called on good >>>>> responses. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >>>>> Review: >>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >>>>> >>>>> >>>>> Thank you, >>>>> --Jamil >>>> >>> >> From jamil.j.nimeh at oracle.com Wed Mar 11 22:10:18 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 11 Mar 2015 15:10:18 -0700 Subject: RFR: [Update 2] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <55005369.207@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> <54F64D7E.4080802@oracle.com> <54F78C26.8090207@oracle.com> <55005369.207@oracle.com> Message-ID: <5500BD4A.6070505@oracle.com> Okay, an updated webrev has been posted that addresses Sean's comments (thanks, BTW). http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.04/ --Jamil On 03/11/2015 07:38 AM, Sean Mullan wrote: > Hi Jamil, > > Just a few comments, mostly minor. > > * OCSPResponse > > 768: there is an extra space in the indentation > > 811: use Collections.emptyMap instead of new HashMap<>() as that does > not allocate a new Map object. > > 813-15,861-63: Use Map.values instead of Map.keySet, ex: > > for (Extension ext : singleExtensions.values()) { > sb.append("singleExtension: " + ext + "\n"); > } > > 784-807: I think this code could be compressed a bit to avoid calling > parseExtensions twice. You can eliminate lines 786-92, if you do > something like this (I think), starting at line 784: > > if (tmp.available() > 0) { > derVal = tmp.getDerValue(); > } else { > derVal == null; > } > > then what is now line 794 becomes: > > if (derVal != null && derVal.isContextSpecific((byte)1)) { > > --Sean > > On 03/04/2015 05:50 PM, Jamil Nimeh wrote: >> One more round of updates. Only the test code and the test inputs have >> changed. Test input is now Base64 format, with comment headers that >> display the OCSP response pretty-print (or an asn1parse of the >> BasicOCSPResponse for malformed response test cases). >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.03/index.html >> >> Thanks, Vinnie for the feedback and suggestions! >> --Jamil >> >> On 03/03/2015 04:10 PM, Jamil Nimeh wrote: >>> Okay, I've got an updated webrev for this issue: >>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html >>> >>> Thanks, >>> --Jamil >>> >>> On 03/03/2015 02:18 PM, Jamil Nimeh wrote: >>>> Hello all, I've come across a couple edge cases that this fix doesn't >>>> cover properly. I'll put out another webrev in a bit that should >>>> tighten up the singleResponse parsing, particularly with the optional >>>> fields. It will also include a couple other negative test input >>>> samples. >>>> >>>> Thanks, >>>> --Jamil >>>> >>>> On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >>>>> Hello all, this review fixes an issue in OCSPResponse where it does >>>>> not parse singleExtensions in the SingleResponse structure. I also >>>>> fixed two minor deviations from the OCSP.RevocationStatus interface >>>>> when getRevocationTime and getRevocationReason are called on good >>>>> responses. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >>>>> Review: >>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >>>>> >>>>> >>>>> Thank you, >>>>> --Jamil >>>> >>> >> From jamil.j.nimeh at oracle.com Wed Mar 11 23:55:22 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 11 Mar 2015 16:55:22 -0700 Subject: RFR: JDK-6996366 : convert MacAlg to an enum Message-ID: <5500D5EA.9060902@oracle.com> Hello all, This bug moves the internal MacAlg concrete class to an enum, and alters the CipherSuite constructor to no longer use String parsing on the cipher suite name to determine the MacAlg. Instead, the constructor now requires the caller to pass in a MacAlg, similar to how it already takes a KeyExchange and BulkCipher. Bug: https://bugs.openjdk.java.net/browse/JDK-6996366 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.01/ Thanks, --Jamil From joe.darcy at oracle.com Thu Mar 12 02:31:05 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 11 Mar 2015 19:31:05 -0700 Subject: JDK 9 RFR of JDK-8075034: Bad javadoc tags in javax.xml.crypto.dsig Message-ID: <5500FA69.1070300@oracle.com> Hello, Please review the patch below to correct JDK-8075034: Bad javadoc tags in javax.xml.crypto.dsig. In several cases, the javadoc uses unescaped "<" and ">" characters which is flagged as a problem by doclint. In addition, the javadoc as it currently stands renders improperly and omits the generics information; in other words, the code in the javadoc gets listed as List references .... rather than List references ... as intended. I have verified a docs build with the fix produced the desired output. I came across this javadoc issue while working on a fix for JDK-8072734: Turn on doclint checking in the build of modules in the jdk repo. Fixing JDK-8075034 will allow full doclint checking on the module containing javax.xml.crypto.dsig. Thanks, -Joe diff -r bd800bc5d699 src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Manifest.java --- a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Manifest.java Wed Mar 11 08:33:12 2015 -0700 +++ b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Manifest.java Wed Mar 11 19:25:51 2015 -0700 @@ -52,7 +52,7 @@ * 
   *   XMLSignatureFactory factory = XMLSignatureFactory.getInstance("DOM");
   *   Reference ref = factory.newReference("#reference-1", 
DigestMethod.SHA1);
- *   List references = Collections.singletonList(ref);
+ *   List<Reference> references = Collections.singletonList(ref);
   *   Manifest manifest = factory.newManifest(references, "manifest-1");
   *
* diff -r bd800bc5d699 src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLObject.java --- a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLObject.java Wed Mar 11 08:33:12 2015 -0700 +++ b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLObject.java Wed Mar 11 19:25:51 2015 -0700 @@ -65,7 +65,7 @@ * 
   *   XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
   *   Manifest manifest = fac.newManifest(references);
- *   List content = Collections.singletonList(manifest);
+ *   List<XMLStructure> content = 
Collections.singletonList(manifest);
   *   XMLObject object = factory.newXMLObject(content, "object-1", 
null, null);
   *
* From sean.mullan at oracle.com Thu Mar 12 11:51:44 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Mar 2015 07:51:44 -0400 Subject: JDK 9 RFR of JDK-8075034: Bad javadoc tags in javax.xml.crypto.dsig In-Reply-To: <5500FA69.1070300@oracle.com> References: <5500FA69.1070300@oracle.com> Message-ID: <55017DD0.7030705@oracle.com> Looks good. Thanks, Sean On 03/11/2015 10:31 PM, joe darcy wrote: > Hello, > > Please review the patch below to correct JDK-8075034: Bad javadoc tags > in javax.xml.crypto.dsig. > > In several cases, the javadoc uses unescaped "<" and ">" characters > which is flagged as a problem by doclint. In addition, the javadoc as it > currently stands renders improperly and omits the generics information; > in other words, the code in the javadoc gets listed as > > List references .... > > rather than > > List references ... > > as intended. I have verified a docs build with the fix produced the > desired output. > > I came across this javadoc issue while working on a fix for JDK-8072734: > Turn on doclint checking in the build of modules in the jdk repo. Fixing > JDK-8075034 will allow full doclint checking on the module containing > javax.xml.crypto.dsig. > > Thanks, > > -Joe > > diff -r bd800bc5d699 > src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Manifest.java > --- > a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Manifest.java > Wed Mar 11 08:33:12 2015 -0700 > +++ > b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Manifest.java > Wed Mar 11 19:25:51 2015 -0700 > @@ -52,7 +52,7 @@ > * 
>    *   XMLSignatureFactory factory =
> XMLSignatureFactory.getInstance("DOM");
>    *   Reference ref = factory.newReference("#reference-1",
> DigestMethod.SHA1);
> - *   List references = Collections.singletonList(ref);
> + *   List<Reference> references = Collections.singletonList(ref);
>    *   Manifest manifest = factory.newManifest(references, "manifest-1");
>    *
> * > diff -r bd800bc5d699 > src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLObject.java > --- > a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLObject.java > Wed Mar 11 08:33:12 2015 -0700 > +++ > b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLObject.java > Wed Mar 11 19:25:51 2015 -0700 > @@ -65,7 +65,7 @@ > * 
>    *   XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
>    *   Manifest manifest = fac.newManifest(references);
> - *   List content = Collections.singletonList(manifest);
> + *   List<XMLStructure> content =
> Collections.singletonList(manifest);
>    *   XMLObject object = factory.newXMLObject(content, "object-1",
> null, null);
>    *
> * > From sean.mullan at oracle.com Thu Mar 12 15:29:07 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Mar 2015 11:29:07 -0400 Subject: [9] Review Request: 8028266 Tidy warnings cleanup for packages java.security/javax.security In-Reply-To: <54FEEBE8.8050907@oracle.com> References: <5354EEE8.8040303@oracle.com> <535588E8.5080200@oracle.com> <535671A3.2070804@oracle.com> <54FEEBE8.8050907@oracle.com> Message-ID: <5501B0C3.40704@oracle.com> This looks fine to me. Note that the warning in PKCS8EncodedKeySpec has already been fixed -- see JDK-8074788. --Sean On 03/10/2015 09:04 AM, alexander stepanov wrote: > Hello Bradford, > > I have finally to fix tidy warnings for java.security, javax.security, > javax.crypto and javax.net packages (sorry for repeated request). > > Could you please review the webrev updated? > http://cr.openjdk.java.net/~avstepan/8028266/webrev.02/ > > It was re-generated because of changes in JDK code layout and contains > fixes for JDK-8040260, JDK-8028266. > > Could please anyone from JCE team suggest what should be done for the > next step if the fixes are satisfactory? > > Thanks, > Alexander > > > On 22.04.2014 16:41, alexander stepanov wrote: >> Hello Bradford, >> >> Thanks, >> >> Could you please review again: >> http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.01/ >> >> > Who is going to help you with that? >> I didn't communicate with JCE team before. So could you please appoint >> me someone to contact? Thanks. >> >> Regards, >> Alexander >> >> >> On 22.04.2014 1:08, Bradford Wetmore wrote: >>> We usually update the copyright dates: >>> >>> * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> >>> javax/security/auth/kerberos/package-info.java >>> ============================================== >>> >>> "yes", or "no", case-insensitive. >>> -> >>> "yes", or "no", and values are case-insensitive. >>> >>> I noticed in several places that while your changes are ok, it >>> doesn't update the value instead of switching to {@code value}. >>> >>> In a previous webrev, I mentioned that you'll need to work with >>> someone to update the built JCE binaries for the javax.crypto >>> changes. Who is going to help you with that? >>> >>> Brad >>> >>> >>> >>> On 4/21/2014 3:11 AM, alexander stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the fix for the following bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8028266 >>>> >>>> Webrev corresponding: >>>> http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.00/ >>>> >>>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >>>> affected. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Alexander >> > From alexander.v.stepanov at oracle.com Fri Mar 13 14:08:56 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 13 Mar 2015 17:08:56 +0300 Subject: [9] Review Request: 8028266 Tidy warnings cleanup for packages java.security/javax.security In-Reply-To: <5501B0C3.40704@oracle.com> References: <5354EEE8.8040303@oracle.com> <535588E8.5080200@oracle.com> <535671A3.2070804@oracle.com> <54FEEBE8.8050907@oracle.com> <5501B0C3.40704@oracle.com> Message-ID: <5502EF78.7060601@oracle.com> Hello Sean, Thank you. Regards, Alexander On 12.03.2015 18:29, Sean Mullan wrote: > This looks fine to me. Note that the warning in PKCS8EncodedKeySpec > has already been fixed -- see JDK-8074788. > > --Sean > > On 03/10/2015 09:04 AM, alexander stepanov wrote: >> Hello Bradford, >> >> I have finally to fix tidy warnings for java.security, javax.security, >> javax.crypto and javax.net packages (sorry for repeated request). >> >> Could you please review the webrev updated? >> http://cr.openjdk.java.net/~avstepan/8028266/webrev.02/ >> >> It was re-generated because of changes in JDK code layout and contains >> fixes for JDK-8040260, JDK-8028266. >> >> Could please anyone from JCE team suggest what should be done for the >> next step if the fixes are satisfactory? >> >> Thanks, >> Alexander >> >> >> On 22.04.2014 16:41, alexander stepanov wrote: >>> Hello Bradford, >>> >>> Thanks, >>> >>> Could you please review again: >>> http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.01/ >>> >>> > Who is going to help you with that? >>> I didn't communicate with JCE team before. So could you please appoint >>> me someone to contact? Thanks. >>> >>> Regards, >>> Alexander >>> >>> >>> On 22.04.2014 1:08, Bradford Wetmore wrote: >>>> We usually update the copyright dates: >>>> >>>> * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights >>>> reserved. >>>> >>>> javax/security/auth/kerberos/package-info.java >>>> ============================================== >>>> >>>> "yes", or "no", case-insensitive. >>>> -> >>>> "yes", or "no", and values are case-insensitive. >>>> >>>> I noticed in several places that while your changes are ok, it >>>> doesn't update the value instead of switching to {@code value}. >>>> >>>> In a previous webrev, I mentioned that you'll need to work with >>>> someone to update the built JCE binaries for the javax.crypto >>>> changes. Who is going to help you with that? >>>> >>>> Brad >>>> >>>> >>>> >>>> On 4/21/2014 3:11 AM, alexander stepanov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the fix for the following bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8028266 >>>>> >>>>> Webrev corresponding: >>>>> http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.00/ >>>>> >>>>> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >>>>> affected. >>>>> >>>>> Thanks. >>>>> >>>>> Regards, >>>>> Alexander >>> >> From sean.mullan at oracle.com Fri Mar 13 15:43:56 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Mar 2015 11:43:56 -0400 Subject: RFR: [Update 2] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <5500BD4A.6070505@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> <54F64D7E.4080802@oracle.com> <54F78C26.8090207@oracle.com> <55005369.207@oracle.com> <5500BD4A.6070505@oracle.com> Message-ID: <550305BC.7000303@oracle.com> On 03/11/2015 06:10 PM, Jamil Nimeh wrote: > Okay, an updated webrev has been posted that addresses Sean's comments > (thanks, BTW). > > http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.04/ Code changes look good, but I had not reviewed the test so here are a few more comments on that part. - for the path, can you remove "Tests" from the directory name? Everything is a test so that seems redundant to me. So the new path would be test/sun/security/provider/certpath/OCSP - Why do you need the DEBUG boolean property? When would you ever want to turn this off? Most of the debug info is valuable (like "Single Extension count mismatch ...") so when something fails you would always want to see it in the logs. - readFile should create the FileReader in a try-with-resources block so it is closed. - line 165 needs a 4-space indent --Sean > > --Jamil > > On 03/11/2015 07:38 AM, Sean Mullan wrote: >> Hi Jamil, >> >> Just a few comments, mostly minor. >> >> * OCSPResponse >> >> 768: there is an extra space in the indentation >> >> 811: use Collections.emptyMap instead of new HashMap<>() as that does >> not allocate a new Map object. >> >> 813-15,861-63: Use Map.values instead of Map.keySet, ex: >> >> for (Extension ext : singleExtensions.values()) { >> sb.append("singleExtension: " + ext + "\n"); >> } >> >> 784-807: I think this code could be compressed a bit to avoid calling >> parseExtensions twice. You can eliminate lines 786-92, if you do >> something like this (I think), starting at line 784: >> >> if (tmp.available() > 0) { >> derVal = tmp.getDerValue(); >> } else { >> derVal == null; >> } >> >> then what is now line 794 becomes: >> >> if (derVal != null && derVal.isContextSpecific((byte)1)) { >> >> --Sean >> >> On 03/04/2015 05:50 PM, Jamil Nimeh wrote: >>> One more round of updates. Only the test code and the test inputs have >>> changed. Test input is now Base64 format, with comment headers that >>> display the OCSP response pretty-print (or an asn1parse of the >>> BasicOCSPResponse for malformed response test cases). >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.03/index.html >>> >>> Thanks, Vinnie for the feedback and suggestions! >>> --Jamil >>> >>> On 03/03/2015 04:10 PM, Jamil Nimeh wrote: >>>> Okay, I've got an updated webrev for this issue: >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html >>>> >>>> Thanks, >>>> --Jamil >>>> >>>> On 03/03/2015 02:18 PM, Jamil Nimeh wrote: >>>>> Hello all, I've come across a couple edge cases that this fix doesn't >>>>> cover properly. I'll put out another webrev in a bit that should >>>>> tighten up the singleResponse parsing, particularly with the optional >>>>> fields. It will also include a couple other negative test input >>>>> samples. >>>>> >>>>> Thanks, >>>>> --Jamil >>>>> >>>>> On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >>>>>> Hello all, this review fixes an issue in OCSPResponse where it does >>>>>> not parse singleExtensions in the SingleResponse structure. I also >>>>>> fixed two minor deviations from the OCSP.RevocationStatus interface >>>>>> when getRevocationTime and getRevocationReason are called on good >>>>>> responses. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >>>>>> Review: >>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >>>>>> >>>>>> >>>>>> Thank you, >>>>>> --Jamil >>>>> >>>> >>> > From jamil.j.nimeh at oracle.com Fri Mar 13 16:04:01 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 13 Mar 2015 09:04:01 -0700 Subject: RFR: [Update 2] 8074064 : OCSPResponse.SingleResponse objects do not parse singleExtensions In-Reply-To: <550305BC.7000303@oracle.com> References: <54F4FAC0.2040703@oracle.com> <54F63330.8030104@oracle.com> <54F64D7E.4080802@oracle.com> <54F78C26.8090207@oracle.com> <55005369.207@oracle.com> <5500BD4A.6070505@oracle.com> <550305BC.7000303@oracle.com> Message-ID: <55030A71.7050203@oracle.com> On 03/13/2015 08:43 AM, Sean Mullan wrote: > On 03/11/2015 06:10 PM, Jamil Nimeh wrote: >> Okay, an updated webrev has been posted that addresses Sean's comments >> (thanks, BTW). >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.04/ > > Code changes look good, but I had not reviewed the test so here are a > few more comments on that part. > > - for the path, can you remove "Tests" from the directory name? > Everything is a test so that seems redundant to me. So the new path > would be test/sun/security/provider/certpath/OCSP Yeah, I guess it is redundant, isn't it? I can change that. I probably should do the same with a bunch of my OCSP stapling unit tests too. > > - Why do you need the DEBUG boolean property? When would you ever want > to turn this off? Most of the debug info is valuable (like "Single > Extension count mismatch ...") so when something fails you would > always want to see it in the logs. > Force of habit. Some of my other tests, particularly in the SSL arena, have debug output that can get very chatty, above and beyond what would be useful for normal log output. For a test like this though, what you say makes sense. I'll rip that out and just go with normal System.out.println output. > - readFile should create the FileReader in a try-with-resources block > so it is closed. Oh wow. I should've caught that. > > - line 165 needs a 4-space indent > All these will be fixed up in a jiffy. > --Sean > >> >> --Jamil >> >> On 03/11/2015 07:38 AM, Sean Mullan wrote: >>> Hi Jamil, >>> >>> Just a few comments, mostly minor. >>> >>> * OCSPResponse >>> >>> 768: there is an extra space in the indentation >>> >>> 811: use Collections.emptyMap instead of new HashMap<>() as that does >>> not allocate a new Map object. >>> >>> 813-15,861-63: Use Map.values instead of Map.keySet, ex: >>> >>> for (Extension ext : singleExtensions.values()) { >>> sb.append("singleExtension: " + ext + "\n"); >>> } >>> >>> 784-807: I think this code could be compressed a bit to avoid calling >>> parseExtensions twice. You can eliminate lines 786-92, if you do >>> something like this (I think), starting at line 784: >>> >>> if (tmp.available() > 0) { >>> derVal = tmp.getDerValue(); >>> } else { >>> derVal == null; >>> } >>> >>> then what is now line 794 becomes: >>> >>> if (derVal != null && derVal.isContextSpecific((byte)1)) { >>> >>> --Sean >>> >>> On 03/04/2015 05:50 PM, Jamil Nimeh wrote: >>>> One more round of updates. Only the test code and the test inputs >>>> have >>>> changed. Test input is now Base64 format, with comment headers that >>>> display the OCSP response pretty-print (or an asn1parse of the >>>> BasicOCSPResponse for malformed response test cases). >>>> >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.03/index.html >>>> >>>> >>>> Thanks, Vinnie for the feedback and suggestions! >>>> --Jamil >>>> >>>> On 03/03/2015 04:10 PM, Jamil Nimeh wrote: >>>>> Okay, I've got an updated webrev for this issue: >>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html >>>>> >>>>> >>>>> Thanks, >>>>> --Jamil >>>>> >>>>> On 03/03/2015 02:18 PM, Jamil Nimeh wrote: >>>>>> Hello all, I've come across a couple edge cases that this fix >>>>>> doesn't >>>>>> cover properly. I'll put out another webrev in a bit that should >>>>>> tighten up the singleResponse parsing, particularly with the >>>>>> optional >>>>>> fields. It will also include a couple other negative test input >>>>>> samples. >>>>>> >>>>>> Thanks, >>>>>> --Jamil >>>>>> >>>>>> On 03/02/2015 04:05 PM, Jamil Nimeh wrote: >>>>>>> Hello all, this review fixes an issue in OCSPResponse where it does >>>>>>> not parse singleExtensions in the SingleResponse structure. I also >>>>>>> fixed two minor deviations from the OCSP.RevocationStatus interface >>>>>>> when getRevocationTime and getRevocationReason are called on good >>>>>>> responses. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074064 >>>>>>> Review: >>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.01/index.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> --Jamil >>>>>> >>>>> >>>> >> From mandy.chung at oracle.com Fri Mar 13 18:37:36 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2015 11:37:36 -0700 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54FF28A4.9080303@oracle.com> References: <54F7ADCE.50900@oracle.com> <54FF28A4.9080303@oracle.com> Message-ID: <55032E70.1040302@oracle.com> This module contains both pack200 and unpack200 tools although it only contains the native implementation of unpacker. Naming it as jdk.unpack200 would give an impression that it contains the unpacker only which isn't the case. Like the API java.util.jar.Pack200 class, it's about Pack200 format and it has both Pack200.Packer and Pack200.Unpacker nested interfaces jdk.pack200 represents the tools for Pack200 format that sounds fine to me. Mandy On 3/10/2015 10:23 AM, Kumar Srinivasan wrote: > The changes look ok to me, however I am wondering if the module > could be called jdk.unpack200 and not jdk.pack200 ? since it > contains only the unpacker, and the bin utilities are pack200 and > unpack200. > > Kumar > > On 3/4/2015 5:13 PM, Mandy Chung wrote: >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> > From jamil.j.nimeh at oracle.com Sat Mar 14 06:17:35 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 13 Mar 2015 23:17:35 -0700 Subject: RFR: JDK-6996366 : convert MacAlg to an enum In-Reply-To: <5500D5EA.9060902@oracle.com> References: <5500D5EA.9060902@oracle.com> Message-ID: <5503D27F.8040107@oracle.com> Ping? On 03/11/2015 04:55 PM, Jamil Nimeh wrote: > Hello all, > > This bug moves the internal MacAlg concrete class to an enum, and > alters the CipherSuite constructor to no longer use String parsing on > the cipher suite name to determine the MacAlg. Instead, the > constructor now requires the caller to pass in a MacAlg, similar to > how it already takes a KeyExchange and BulkCipher. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6996366 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.01/ > > Thanks, > --Jamil From xuelei.fan at oracle.com Sat Mar 14 08:08:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 14 Mar 2015 16:08:34 +0800 Subject: RFR: JDK-6996366 : convert MacAlg to an enum In-Reply-To: <5500D5EA.9060902@oracle.com> References: <5500D5EA.9060902@oracle.com> Message-ID: <5503EC82.5020808@oracle.com> Looks fine to me. Do you want to consider a similar conversion on BulkCipher? Maybe in a new bug. Thanks, Xuelei On 3/12/2015 7:55 AM, Jamil Nimeh wrote: > Hello all, > > This bug moves the internal MacAlg concrete class to an enum, and alters > the CipherSuite constructor to no longer use String parsing on the > cipher suite name to determine the MacAlg. Instead, the constructor now > requires the caller to pass in a MacAlg, similar to how it already takes > a KeyExchange and BulkCipher. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6996366 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.01/ > > Thanks, > --Jamil From jamil.j.nimeh at oracle.com Sat Mar 14 10:54:52 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 14 Mar 2015 03:54:52 -0700 Subject: RFR: JDK-6996366 : convert MacAlg to an enum In-Reply-To: <5503EC82.5020808@oracle.com> References: <5500D5EA.9060902@oracle.com> <5503EC82.5020808@oracle.com> Message-ID: <5504137C.7000004@oracle.com> Or we could just take care of it now, since I'm already making enums out of things. http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.02/ I don't see any differences in jtreg results across the 211 ssl tests I ran so that seems like a good sign. I've got a jprt run going now to see if anything happens there. Let me know what you think. --Jamil On 03/14/2015 01:08 AM, Xuelei Fan wrote: > Looks fine to me. > > Do you want to consider a similar conversion on BulkCipher? Maybe in a > new bug. > > Thanks, > Xuelei > > On 3/12/2015 7:55 AM, Jamil Nimeh wrote: >> Hello all, >> >> This bug moves the internal MacAlg concrete class to an enum, and alters >> the CipherSuite constructor to no longer use String parsing on the >> cipher suite name to determine the MacAlg. Instead, the constructor now >> requires the caller to pass in a MacAlg, similar to how it already takes >> a KeyExchange and BulkCipher. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6996366 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.01/ >> >> Thanks, >> --Jamil From xuelei.fan at oracle.com Sat Mar 14 11:13:09 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 14 Mar 2015 19:13:09 +0800 Subject: RFR: JDK-6996366 : convert MacAlg to an enum In-Reply-To: <5504137C.7000004@oracle.com> References: <5500D5EA.9060902@oracle.com> <5503EC82.5020808@oracle.com> <5504137C.7000004@oracle.com> Message-ID: <550417C5.2030501@oracle.com> On 3/14/2015 6:54 PM, Jamil Nimeh wrote: > Or we could just take care of it now, since I'm already making enums out > of things. > > http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.02/ > Looks fine to me. > I don't see any differences in jtreg results across the 211 ssl tests I > ran so that seems like a good sign. I've got a jprt run going now to > see if anything happens there. Let me know what you think. > It's OK as the JPRT jobs passed. Please add a "noreg-cleanup" tag as this is a refactoring of existing code and need no additional test. Thanks, Xuelei > --Jamil > > On 03/14/2015 01:08 AM, Xuelei Fan wrote: >> Looks fine to me. >> >> Do you want to consider a similar conversion on BulkCipher? Maybe in a >> new bug. >> >> Thanks, >> Xuelei >> >> On 3/12/2015 7:55 AM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This bug moves the internal MacAlg concrete class to an enum, and alters >>> the CipherSuite constructor to no longer use String parsing on the >>> cipher suite name to determine the MacAlg. Instead, the constructor now >>> requires the caller to pass in a MacAlg, similar to how it already takes >>> a KeyExchange and BulkCipher. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6996366 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.01/ >>> >>> Thanks, >>> --Jamil > From weijun.wang at oracle.com Sat Mar 14 23:34:42 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 15 Mar 2015 07:34:42 +0800 Subject: RFR: JDK-6996366 : convert MacAlg to an enum In-Reply-To: <550417C5.2030501@oracle.com> References: <5500D5EA.9060902@oracle.com> <5503EC82.5020808@oracle.com> <5504137C.7000004@oracle.com> <550417C5.2030501@oracle.com> Message-ID: <08807220-176A-4CD7-B810-7841F68332EB@oracle.com> One disadvantage of enum to constant is that third-party library will not be able to extend it. I noticed this when I was trying to extend TLS to use non-certificate-based ciphersuites by providing more KeyExchange values. That work is stalled now but if we want to do it later this should be considered. Can MacAlg also be extended? --Max >> >> http://cr.openjdk.java.net/~jnimeh/reviews/6996366/webrev.02/ >> From weijun.wang at oracle.com Mon Mar 16 03:12:57 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Mar 2015 11:12:57 +0800 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 Message-ID: Hi All Please review the change at http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ Thanks Max From weijun.wang at oracle.com Mon Mar 16 03:46:46 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Mar 2015 11:46:46 +0800 Subject: On stream-based GSSContext methods in RFC 5653 In-Reply-To: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> Message-ID: Hi All I discussed with my colleagues on the stream-based methods and we think they are not well-designed: 1. A library should not define a wire protocol and assume the peer is using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 requires the application to define it. 2. It's impossible to implement these methods correctly when the mechanism token has no self-framing or the library has no knowledge of the token format (for example, as a bridge talking to another GSS library). Therefore, I propose to deprecate these methods in an I-D. By deprecation, I'd like to remove the methods from the main content and describe the reason in a "Changes since RFC 5653" section. The specification for the methods will be moved to an appendix or the "Changes since RFC 5653" section will contain links to sections inside RFC 5653. In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecated. The existing implementations will be still supported. Thanks Max From erik.joelsson at oracle.com Mon Mar 16 08:31:38 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Mar 2015 09:31:38 +0100 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 In-Reply-To: References: Message-ID: <550694EA.3060603@oracle.com> Looks good to me. Thanks for fixing warnings! /Erik On 2015-03-16 04:12, Wang Weijun wrote: > Hi All > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ > > Thanks > Max > From artem.smotrakov at oracle.com Mon Mar 16 10:47:25 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 16 Mar 2015 13:47:25 +0300 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs Message-ID: <5506B4BD.2000004@oracle.com> Hello, Please review a couple of new tests for privilege checks on Subject.doAs(). https://bugs.openjdk.java.net/browse/JDK-8048147 http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ Artem From magnus.ihse.bursie at oracle.com Mon Mar 16 14:04:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Mar 2015 15:04:38 +0100 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 In-Reply-To: References: Message-ID: <5506E2F6.3060005@oracle.com> On 2015-03-16 04:12, Wang Weijun wrote: > Hi All > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ > > Thanks > Max > Looks good to me. Thanks for fixing this. I'm just curious about the new deprecated-declarations warning. I didn't see it when I excluded the warnings for the library in the first place. Did it show up when you fixed the other warnings, or did you see it all the time? If so, what compiler version are you using? /Magnus From weijun.wang at oracle.com Mon Mar 16 15:19:41 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Mar 2015 23:19:41 +0800 Subject: RFR 8074835/8074836: Resolve disabled warnings for libj2gss/libosxkrb5 In-Reply-To: <5506E2F6.3060005@oracle.com> References: <5506E2F6.3060005@oracle.com> Message-ID: <342E2791-8CC9-44BC-99A9-1DC7365D357C@oracle.com> > On Mar 16, 2015, at 22:04, Magnus Ihse Bursie wrote: > > On 2015-03-16 04:12, Wang Weijun wrote: >> Hi All >> >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8074836/webrev.00/ >> >> Thanks >> Max >> > > Looks good to me. Thanks for fixing this. > > I'm just curious about the new deprecated-declarations warning. I didn't see it when I excluded the warnings for the library in the first place. Did it show up when you fixed the other warnings, or did you see it all the time? If so, what compiler version are you using? All the time. It's in /System/Library/Frameworks/Kerberos.framework/Headers/krb5.h. All those "KERBEROS_APPLE_DEPRECATED("use GSS.framework")" words. $ /usr/bin/clang -v Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix --Max > > /Magnus From weijun.wang at oracle.com Tue Mar 17 09:39:13 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 Mar 2015 17:39:13 +0800 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <5506B4BD.2000004@oracle.com> References: <5506B4BD.2000004@oracle.com> Message-ID: Hi Artem The tests are good but I am thinking if we can simplify them. There are too many duplicate actions here, for example, packing the same classes again and again to the same jar file, and the 4 ***Test.java files are quite similar. Is it possible to create a single Test.java to do everything in a single main()? Is it possible to convert javac calls to @compile or @build? Is it possible to convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of using jar files is it possible to put the classes into different sub-directories and point classpath to them? Is it possible to convert java calls to @run? Finally, you create a new nested directory. Is it because there is already a "doAs" there? I'd rather see a doAs2 containing these new tests. The new Utils.java can also be put inside this directory. BTW, the auth.policy file was so old and I wonder if we still need to test it. Thanks Max > On Mar 16, 2015, at 18:47, Artem Smotrakov wrote: > > Hello, > > Please review a couple of new tests for privilege checks on Subject.doAs(). > > https://bugs.openjdk.java.net/browse/JDK-8048147 > http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ > > Artem From weijun.wang at oracle.com Tue Mar 17 10:02:12 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 Mar 2015 18:02:12 +0800 Subject: RFR 8074935: jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did Message-ID: <9C3DEB27-8B39-446D-9CAC-21EAE4C24D40@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8074935/webrev.00/ In jdk8, we use Base64.getMimeDecoder() to parse PEM-encoded certs and it ignores every character not in the base-64 alphabet. PEM is more restricted and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug report and test). This fix will also reject them. I also updated the encode side so that the output is always 64 chars wide, which is a requirement of PEM (http://en.wikipedia.org/wiki/Base64#Privacy-enhanced_mail). Thanks Max From jason.uh at oracle.com Wed Mar 18 01:34:34 2015 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 17 Mar 2015 18:34:34 -0700 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names Message-ID: <5508D62A.9010507@oracle.com> Please review this fix, which changes the internal map in sun.security.x509.CertificateExtensions and CRLExtensions to always use the OID as the key. As stated in the JBS issue: > The sun.security.x509.CertificateExtensions class maintains a Map map field to store all the extensions it manages. The key of map uses the name (say, "BasicConstraints") of the extension, or the OID when the type of the extension is unknown. With this change, the map will consistently use the OID as the key. webrev: http://cr.openjdk.java.net/~juh/7145757/00/ bug: https://bugs.openjdk.java.net/browse/JDK-7145757 Thanks, Jason From artem.smotrakov at oracle.com Wed Mar 18 09:21:04 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 18 Mar 2015 12:21:04 +0300 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: References: <5506B4BD.2000004@oracle.com> Message-ID: <55094380.6040809@oracle.com> Hi Max, Thank you for the review, it really helped to simplify the tests. I combined your suggestions, please take a look: http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/ Artem On 03/17/2015 12:39 PM, Wang Weijun wrote: > Hi Artem > > The tests are good but I am thinking if we can simplify them. > > There are too many duplicate actions here, for example, packing the same classes again and again to the same jar file, and the 4 ***Test.java files are quite similar. Is it possible to create a single Test.java to do everything in a single main()? > > Is it possible to convert javac calls to @compile or @build? Is it possible to convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of using jar files is it possible to put the classes into different sub-directories and point classpath to them? Is it possible to convert java calls to @run? > > Finally, you create a new nested directory. Is it because there is already a "doAs" there? I'd rather see a doAs2 containing these new tests. The new Utils.java can also be put inside this directory. > > BTW, the auth.policy file was so old and I wonder if we still need to test it. > > Thanks > Max > >> On Mar 16, 2015, at 18:47, Artem Smotrakov wrote: >> >> Hello, >> >> Please review a couple of new tests for privilege checks on Subject.doAs(). >> >> https://bugs.openjdk.java.net/browse/JDK-8048147 >> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ >> >> Artem From weijun.wang at oracle.com Wed Mar 18 09:39:39 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 Mar 2015 17:39:39 +0800 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <55094380.6040809@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> Message-ID: <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> It looks like the classes are loaded from test.classes since there is nowhere setting classpath to those jars. Maybe you cannot rely on "@run main". --Max > On Mar 18, 2015, at 17:21, Artem Smotrakov wrote: > > Hi Max, > > Thank you for the review, it really helped to simplify the tests. I combined your suggestions, please take a look: > > http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/ > > Artem > > On 03/17/2015 12:39 PM, Wang Weijun wrote: >> Hi Artem >> >> The tests are good but I am thinking if we can simplify them. >> >> There are too many duplicate actions here, for example, packing the same classes again and again to the same jar file, and the 4 ***Test.java files are quite similar. Is it possible to create a single Test.java to do everything in a single main()? >> >> Is it possible to convert javac calls to @compile or @build? Is it possible to convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of using jar files is it possible to put the classes into different sub-directories and point classpath to them? Is it possible to convert java calls to @run? >> >> Finally, you create a new nested directory. Is it because there is already a "doAs" there? I'd rather see a doAs2 containing these new tests. The new Utils.java can also be put inside this directory. >> >> BTW, the auth.policy file was so old and I wonder if we still need to test it. >> >> Thanks >> Max >> >>> On Mar 16, 2015, at 18:47, Artem Smotrakov wrote: >>> >>> Hello, >>> >>> Please review a couple of new tests for privilege checks on Subject.doAs(). >>> >>> https://bugs.openjdk.java.net/browse/JDK-8048147 >>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ >>> >>> Artem > From weijun.wang at oracle.com Wed Mar 18 09:43:31 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 Mar 2015 17:43:31 +0800 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> Message-ID: <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> Honestly, writing a shell script test would be much cleaner, although it does not have the same performance as a Java test. Copying Jon, there should be cases where a script should be preferred. --Max > On Mar 18, 2015, at 17:39, Wang Weijun wrote: > > It looks like the classes are loaded from test.classes since there is nowhere setting classpath to those jars. Maybe you cannot rely on "@run main". > > --Max > >> On Mar 18, 2015, at 17:21, Artem Smotrakov wrote: >> >> Hi Max, >> >> Thank you for the review, it really helped to simplify the tests. I combined your suggestions, please take a look: >> >> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/ >> >> Artem >> >> On 03/17/2015 12:39 PM, Wang Weijun wrote: >>> Hi Artem >>> >>> The tests are good but I am thinking if we can simplify them. >>> >>> There are too many duplicate actions here, for example, packing the same classes again and again to the same jar file, and the 4 ***Test.java files are quite similar. Is it possible to create a single Test.java to do everything in a single main()? >>> >>> Is it possible to convert javac calls to @compile or @build? Is it possible to convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of using jar files is it possible to put the classes into different sub-directories and point classpath to them? Is it possible to convert java calls to @run? >>> >>> Finally, you create a new nested directory. Is it because there is already a "doAs" there? I'd rather see a doAs2 containing these new tests. The new Utils.java can also be put inside this directory. >>> >>> BTW, the auth.policy file was so old and I wonder if we still need to test it. >>> >>> Thanks >>> Max >>> >>>> On Mar 16, 2015, at 18:47, Artem Smotrakov wrote: >>>> >>>> Hello, >>>> >>>> Please review a couple of new tests for privilege checks on Subject.doAs(). >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8048147 >>>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ >>>> >>>> Artem >> > From artem.smotrakov at oracle.com Wed Mar 18 11:31:14 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 18 Mar 2015 14:31:14 +0300 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> Message-ID: <55096202.9010100@oracle.com> Yes, it looks like the classes are loaded from test.classes, here is a piece of jtr file CLASSPATH=/home/artem/tools/jtreg/4.1/lib/javatest.jar:/home/artem/tools/jtreg/4.1/lib/jtreg.jar:/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs:/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs \\ /home/artem/jdk/jdk1.9.0b51/bin/java \\ -Dtest.vm.opts= \\ -Dtest.jdk=/home/artem/jdk/jdk1.9.0b51 \\ -Dtest.timeout.factor=1.0 \\ -Dtest.src.path=/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs \\ -Dtest.compiler.opts= \\ -Dcompile.jdk=/home/artem/jdk/jdk1.9.0b51 \\ -Dtest.classes=/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs \\ -Dtest.class.path=/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs \\ -Dtest.java.opts= \\ -Dtest.src=/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs \\ -Dtest.tool.vm.opts= \\ -Djava.security.policy==/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/scratch/policy.expect.ace_new \\ -Djava.security.manager=default \\ com.sun.javatest.regtest.MainWrapper /home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs/NestedActions.jta expectACE I am not sure that it is possible to modify classpath for othervm tests. http://openjdk.java.net/jtreg/faq.html#question4.2 ... 4.2. How do I set the CLASSPATH environment variable for my test? The harness sets the CLASSPATH for the compile, main, and applet actions to be the system class path plus the test's source and classes directory. It is possible to set the classpath for the main/othervm action via the -classpath option to java. Any other modification of the CLASSPATH must be done using the shell action. ... "@run main/othervm -classpath ..." doesn't seem to work because it can't find com.sun.javatest.regtest.MainWrapper The tests can be updated to start a new process with ProcessTools, or use a script. Artem On 03/18/2015 12:43 PM, Wang Weijun wrote: > Honestly, writing a shell script test would be much cleaner, although it does not have the same performance as a Java test. > > Copying Jon, there should be cases where a script should be preferred. > > --Max > >> On Mar 18, 2015, at 17:39, Wang Weijun wrote: >> >> It looks like the classes are loaded from test.classes since there is nowhere setting classpath to those jars. Maybe you cannot rely on "@run main". >> >> --Max >> >>> On Mar 18, 2015, at 17:21, Artem Smotrakov wrote: >>> >>> Hi Max, >>> >>> Thank you for the review, it really helped to simplify the tests. I combined your suggestions, please take a look: >>> >>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/ >>> >>> Artem >>> >>> On 03/17/2015 12:39 PM, Wang Weijun wrote: >>>> Hi Artem >>>> >>>> The tests are good but I am thinking if we can simplify them. >>>> >>>> There are too many duplicate actions here, for example, packing the same classes again and again to the same jar file, and the 4 ***Test.java files are quite similar. Is it possible to create a single Test.java to do everything in a single main()? >>>> >>>> Is it possible to convert javac calls to @compile or @build? Is it possible to convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of using jar files is it possible to put the classes into different sub-directories and point classpath to them? Is it possible to convert java calls to @run? >>>> >>>> Finally, you create a new nested directory. Is it because there is already a "doAs" there? I'd rather see a doAs2 containing these new tests. The new Utils.java can also be put inside this directory. >>>> >>>> BTW, the auth.policy file was so old and I wonder if we still need to test it. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Mar 16, 2015, at 18:47, Artem Smotrakov wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review a couple of new tests for privilege checks on Subject.doAs(). >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8048147 >>>>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ >>>>> >>>>> Artem From weijun.wang at oracle.com Wed Mar 18 15:08:05 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 Mar 2015 23:08:05 +0800 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <55096202.9010100@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> <55096202.9010100@oracle.com> Message-ID: <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> > On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: > > The tests can be updated to start a new process with ProcessTools, or use a script. Choose anyone you like. Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes. I'm a little surprised that with the classpath not pointing to jars the test still succeeds. The jars should have been granted different permissions. Maybe the test is not designed smart enough to detect the problem? --Max > > Artem From jason.uh at oracle.com Wed Mar 18 21:52:44 2015 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 18 Mar 2015 14:52:44 -0700 Subject: [9] RFR: 8074531: Remove javax.security.cert.X509Certificate usage in internal networking packages Message-ID: <5509F3AC.4030809@oracle.com> Please review this change, which removes methods in internal net packages that use the deprecated javax.security.cert.X509Certificate type. webrev: http://cr.openjdk.java.net/~juh/8074531/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8074531 Thanks, Jason From weijun.wang at oracle.com Wed Mar 18 23:09:08 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Mar 2015 07:09:08 +0800 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: <5508D62A.9010507@oracle.com> References: <5508D62A.9010507@oracle.com> Message-ID: Hi Jason I was thinking about changing all set/get calls to using OID so inside CertificateExtensions and CRLExtensions you won't need to care about name conversions. Is that possible? Also I see you adding some IOException throwing and catching. Is there any case you actually see them? I would think if that really happen there might be some programming error. --Max > On Mar 18, 2015, at 09:34, Jason Uh wrote: > > Please review this fix, which changes the internal map in sun.security.x509.CertificateExtensions and CRLExtensions to always use the OID as the key. > > As stated in the JBS issue: >> The sun.security.x509.CertificateExtensions class maintains a Map map field to store all the extensions it manages. The key of map uses the name (say, "BasicConstraints") of the extension, or the OID when the type of the extension is unknown. > > With this change, the map will consistently use the OID as the key. > > webrev: http://cr.openjdk.java.net/~juh/7145757/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-7145757 > > Thanks, > Jason From jason.uh at oracle.com Wed Mar 18 23:40:56 2015 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 18 Mar 2015 16:40:56 -0700 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: References: <5508D62A.9010507@oracle.com> Message-ID: <550A0D08.1020901@oracle.com> Hi Max, On 03/18/2015 04:09 PM, Wang Weijun wrote: > Hi Jason > > I was thinking about changing all set/get calls to using OID so inside CertificateExtensions and CRLExtensions you won't need to care about name conversions. Is that possible? It might be, but it'd call for more extensive changes. Currently, when certificates are parsed, the extensions are added using the name, and when they are retrieved, they are also specified by name -- for example, X509CertImpl.getBasicConstraints() calls a get() method with the BasicConstraints alias as the lookup parameter. It's been a while, but the last we spoke about this, I think you wanted to keep the changes for this contained within CertificateExtensions and CRLExtensions. If that's still the case, we'll have to do this name conversion. If not, I could try changing things outside of these classes. > Also I see you adding some IOException throwing and catching. Is there any case you actually see them? I would think if that really happen there might be some programming error. I added the IOExceptions mainly to keep CRLExtensions consistent with CertificateExtensions. I thought it was a little odd that they weren't being thrown, but they may not need to be there for CRLExtensions. I can take them out. > --Max > >> On Mar 18, 2015, at 09:34, Jason Uh wrote: >> >> Please review this fix, which changes the internal map in sun.security.x509.CertificateExtensions and CRLExtensions to always use the OID as the key. >> >> As stated in the JBS issue: >>> The sun.security.x509.CertificateExtensions class maintains a Map map field to store all the extensions it manages. The key of map uses the name (say, "BasicConstraints") of the extension, or the OID when the type of the extension is unknown. >> >> With this change, the map will consistently use the OID as the key. >> >> webrev: http://cr.openjdk.java.net/~juh/7145757/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-7145757 >> >> Thanks, >> Jason > From weijun.wang at oracle.com Thu Mar 19 01:06:58 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Mar 2015 09:06:58 +0800 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: <550A0D08.1020901@oracle.com> References: <5508D62A.9010507@oracle.com> <550A0D08.1020901@oracle.com> Message-ID: <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> Yes, it will be extensive, but since we already make all keys OID, we should always call those set/get() with OIDs for performance. In case we might miss some, inside the implementation of get/set(), we can still accept names. Also, it seems there is no need for a nameCache everywhere, you can probably maintain a global one inside OIDMap. As for the IOException, I think it's because CRLExtensions does not have getExtension() that returns null. Now that you create another inconsistence that X509CRLImpl.getExtension() is starting to throw IOE while X509CertImpl.getExtension() does not. --Max > On Mar 19, 2015, at 07:40, Jason Uh wrote: > > Hi Max, > > On 03/18/2015 04:09 PM, Wang Weijun wrote: >> Hi Jason >> >> I was thinking about changing all set/get calls to using OID so inside CertificateExtensions and CRLExtensions you won't need to care about name conversions. Is that possible? > > It might be, but it'd call for more extensive changes. Currently, when certificates are parsed, the extensions are added using the name, and when they are retrieved, they are also specified by name -- for example, X509CertImpl.getBasicConstraints() calls a get() method with the BasicConstraints alias as the lookup parameter. > > It's been a while, but the last we spoke about this, I think you wanted to keep the changes for this contained within CertificateExtensions and CRLExtensions. If that's still the case, we'll have to do this name conversion. If not, I could try changing things outside of these classes. > >> Also I see you adding some IOException throwing and catching. Is there any case you actually see them? I would think if that really happen there might be some programming error. > > I added the IOExceptions mainly to keep CRLExtensions consistent with CertificateExtensions. I thought it was a little odd that they weren't being thrown, but they may not need to be there for CRLExtensions. I can take them out. > >> --Max >> >>> On Mar 18, 2015, at 09:34, Jason Uh wrote: >>> >>> Please review this fix, which changes the internal map in sun.security.x509.CertificateExtensions and CRLExtensions to always use the OID as the key. >>> >>> As stated in the JBS issue: >>>> The sun.security.x509.CertificateExtensions class maintains a Map map field to store all the extensions it manages. The key of map uses the name (say, "BasicConstraints") of the extension, or the OID when the type of the extension is unknown. >>> >>> With this change, the map will consistently use the OID as the key. >>> >>> webrev: http://cr.openjdk.java.net/~juh/7145757/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-7145757 >>> >>> Thanks, >>> Jason >> From weijun.wang at oracle.com Thu Mar 19 02:56:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Mar 2015 10:56:57 +0800 Subject: [kitten] On stream-based GSSContext methods in RFC 5653 In-Reply-To: <20150319023703.GA8099@localhost> References: <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <20150319023703.GA8099@localhost> Message-ID: <550A3AF9.4020701@oracle.com> So what's your suggestion on their future? A: Remove them and say "they are removed" in a "Changed since" section. B: Move them to an appendix and say "they will not be developed anymore and please do not use them". C: Keep them in the old section and say "they will not be developed anymore and please do not use them". Thanks Max On 3/19/2015 10:37, Nico Williams wrote: > On Mon, Mar 16, 2015 at 11:46:46AM +0800, Wang Weijun wrote: >> I discussed with my colleagues on the stream-based methods and we >> think they are not well-designed: > > I agree. > From zaiyao.liu at oracle.com Thu Mar 19 06:04:02 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Thu, 19 Mar 2015 14:04:02 +0800 Subject: [JDK-9] RFR: 8048618 Tests for PKCS12 write operations In-Reply-To: <5531F555-9EFC-4AEE-BE34-DCA7E9CDC0BD@oracle.com> References: <55090E13.6080701@oracle.com> <5531F555-9EFC-4AEE-BE34-DCA7E9CDC0BD@oracle.com> Message-ID: <550A66D2.60706@oracle.com> Hi Max, Thanks for review, please check the update: http://cr.openjdk.java.net/~zailiu/8048618/webrev01/test/java/security/KeyStore/PKCS12/WriteP12Test.java.html Thanks again. Kevin ? 2015/3/18 14:23, Wang Weijun ??: > > 33 * WriteP12CertChainBad: same as WriteP12CertChain but chains order is > 34 * user-ca-lead, the order is wrong so expects to fail. > > Really? What is the exception? this line will catch the exception. 167 } catch (KeyStoreException e) { > Another suggestion, please move the text in the summary before the actual codes inside main() as comments. It's hard to page up and page down to find out what the tests are doing. Fixed, thanks. > Thanks > Max > > >> On Mar 18, 2015, at 13:33, zaiyao liu wrote: >> >> Hi Max, >> >> Please help to review this test: >> >> JDK issue:https://bugs.openjdk.java.net/browse/JDK-8048618 >> Webrev:http://cr.openjdk.java.net/~zailiu/8048618/webrev/ >> >> Thanks >> >> Kevin From artem.smotrakov at oracle.com Thu Mar 19 11:39:21 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 19 Mar 2015 14:39:21 +0300 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> <55096202.9010100@oracle.com> <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> Message-ID: <550AB569.80402@oracle.com> Hi Max, I agree that sometimes use of a shell script makes a test clearer. On the other hand, if we are trying to create pure Java tests, it increases overall coverage of Java APIs. I updated the tests to use ProcessTools, and simplified a little bit policy files for negative tests to make them clearer. Please take a look: http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/ Artem On 03/18/2015 06:08 PM, Wang Weijun wrote: >> On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: >> >> The tests can be updated to start a new process with ProcessTools, or use a script. > Choose anyone you like. > > Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes. > > I'm a little surprised that with the classpath not pointing to jars the test still succeeds. The jars should have been granted different permissions. Maybe the test is not designed smart enough to detect the problem? > > --Max > >> Artem From weijun.wang at oracle.com Thu Mar 19 14:33:33 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Mar 2015 22:33:33 +0800 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <550AB569.80402@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> <55096202.9010100@oracle.com> <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> <550AB569.80402@oracle.com> Message-ID: <354B2ADB-0FBD-45AC-8CBB-E27744779F3C@oracle.com> This looks fine. One comment, 156 cmds.add("-Duser.dir=" + WORK_DIR); Looks unnecessary. In fact, I've never seen people setting user.dir on the command line. Another comment, 80 * @run main NestedActions jar ReadPropertyExceptionAction.jar 81 * ReadPropertyExceptionAction.class ReadPropertyException.class 82 * 83 * run tests Will line 83 make any trouble? I remember bare words (not in a tag) will be absorbed by the previous action so the lines above will be interpreted as @run main NestedActions jar ReadPropertyExceptionAction.jar ReadPropertyExceptionAction.class ReadPropertyException.class run tests Or maybe that blank line can end an a tag? Anyway I dare not use this. Thanks Max > On Mar 19, 2015, at 19:39, Artem Smotrakov wrote: > > Hi Max, > > I agree that sometimes use of a shell script makes a test clearer. On the other hand, if we are trying to create pure Java tests, it increases overall coverage of Java APIs. > > I updated the tests to use ProcessTools, and simplified a little bit policy files for negative tests to make them clearer. Please take a look: > > http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/ > > Artem > > On 03/18/2015 06:08 PM, Wang Weijun wrote: >>> On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: >>> >>> The tests can be updated to start a new process with ProcessTools, or use a script. >> Choose anyone you like. >> >> Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes. >> >> I'm a little surprised that with the classpath not pointing to jars the test still succeeds. The jars should have been granted different permissions. Maybe the test is not designed smart enough to detect the problem? >> >> --Max >> >>> Artem > From nico at cryptonector.com Thu Mar 19 02:37:04 2015 From: nico at cryptonector.com (Nico Williams) Date: Wed, 18 Mar 2015 21:37:04 -0500 Subject: [kitten] On stream-based GSSContext methods in RFC 5653 In-Reply-To: References: <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> Message-ID: <20150319023703.GA8099@localhost> On Mon, Mar 16, 2015 at 11:46:46AM +0800, Wang Weijun wrote: > I discussed with my colleagues on the stream-based methods and we > think they are not well-designed: I agree. From nico at cryptonector.com Thu Mar 19 15:01:16 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 19 Mar 2015 10:01:16 -0500 Subject: [kitten] On stream-based GSSContext methods in RFC 5653 In-Reply-To: <550A3AF9.4020701@oracle.com> References: <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <20150319023703.GA8099@localhost> <550A3AF9.4020701@oracle.com> Message-ID: <20150319150115.GC8099@localhost> On Thu, Mar 19, 2015 at 10:56:57AM +0800, Weijun Wang wrote: > So what's your suggestion on their future? > > A: Remove them and say "they are removed" in a "Changed since" section. Remove them and mention that they used to be there and they have been removed, "do not use". Nico -- From joe.darcy at oracle.com Fri Mar 20 01:12:44 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 Mar 2015 18:12:44 -0700 Subject: JDK 9 RFR of JDK-8075567: Mark intermittently failuring security-libs tests Message-ID: <550B740C.9010004@oracle.com> Hello, Per a policy to mark intermittently failing tests (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032383.html), please review the changes below to mark two security libs tests as failing intermittently: sun/security/mscapi/ShortRSAKey1024.sh sun/security/mscapi/SignUsingNONEwithRSA.sh To find these tests, I went through unresolved security-libs bugs looking for test failures that had information updated within the last six months or so. Please add or remove the intermittent jtreg keyword to security tests appropriately going forward. Also, please consider the general recommendation to rewrite shell tests as Java programs. The langtools team was able to remove nearly all shell tests in their test suite. Thanks, -Joe diff -r cd4aea326e89 test/sun/security/mscapi/ShortRSAKey1024.sh --- a/test/sun/security/mscapi/ShortRSAKey1024.sh Thu Mar 19 13:18:49 2015 -0700 +++ b/test/sun/security/mscapi/ShortRSAKey1024.sh Thu Mar 19 17:59:43 2015 -0700 @@ -30,6 +30,7 @@ # @run shell ShortRSAKey1024.sh 1024 # @run shell ShortRSAKey1024.sh 768 # @run shell ShortRSAKey1024.sh 512 +# @key intermittent # set a few environment variables so that the shell-script can run stand-alone # in the source directory diff -r cd4aea326e89 test/sun/security/mscapi/SignUsingNONEwithRSA.sh --- a/test/sun/security/mscapi/SignUsingNONEwithRSA.sh Thu Mar 19 13:18:49 2015 -0700 +++ b/test/sun/security/mscapi/SignUsingNONEwithRSA.sh Thu Mar 19 17:59:43 2015 -0700 @@ -28,6 +28,7 @@ # @bug 6578658 # @run shell SignUsingNONEwithRSA.sh # @summary Sign using the NONEwithRSA signature algorithm from SunMSCAPI +# @key intermittent # set a few environment variables so that the shell-script can run stand-alone # in the source directory From weijun.wang at oracle.com Fri Mar 20 03:24:20 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Mar 2015 11:24:20 +0800 Subject: On stream-based GSSContext methods in RFC 5653 In-Reply-To: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <, <>> Message-ID: <96E28C34-69BC-411B-A9FB-C352E270D648@oracle.com> Hi Thomas On Mar 20, 2015, at 10:15, Thomas Maslen wrote: > > My personal 0.02. > > First, my overall reaction to this is pretty much the same as my reaction to the GSSException change proposed in the rfc5653bis draft: I believe that this aspect of 2853 / 5653 isn't broken and so I'm leery of "fixing" it -- but I don't feel strongly about it and I don't really object to it (much), I mostly just want to make sure that we look before we leap. The GSSException case is not broken. It's just that the Java binding does not have the same feature as the C binding, at least for the token-based methods. You may say people can find a way to send the error token using the stream-based methods without any API change, but since we never documented anything before it could bring unexpected behavior to current users. Also, it is too automatic and a user might want to send a normal token but not send an error token. > > [But I do agree that if (a) we deprecate the stream-based GSSContext methods and (b) we care about being able to both throw a GSSException and return an error token, then (c) yes, in that case the GSSException change would then be necessary]. > > To me, neither item 1 nor item 2 below is problematic for the stream-based methods. Perhaps the assumptions that I'm using are different than yours? For me, the main reason of (a) is that GSS-API is defined around tokens and sending/receiving these tokens should be left to applications. Using them, documenting them, and implementing them, are all unnecessarily complicated. > > What I mean by that is: > > I agree that if you took the raw InputStream from e.g. Socket.getInputStream() and passed it to a stream-based GSSContext method then yes, it would be problematic. The javadoc for the methods seems to suggest that * while (!context.isEstablished()) { * * context.initSecContext(is, os); * * // send output token if generated * os.flush(); * } > > But don't do that. Instead: > > (1) Read the token-length field from the raw InputStream. (There must be a token-length field, or something equivalent to it -- if there wasn't, you wouldn't be able to use the byte[]-based GSSContext methods either) > > (2) Use that length field to construct a wrapper InputStream (probably a subclass of FilterInputStream) that lets you read that number of bytes and then returns EOF (even though the underlying raw InputStream probably still has data available). Yes, I'm definitely glossing over some details about ensuring that you always advance the underlying stream to the end of the token, but that's just a SMOP. > > (3) Pass that wrapper InputStream (not the underlying raw InputStream) to the stream-based GSSContext method. > > The advantage of doing this, c.f. just using the byte[]-based methods, is efficiency: with the byte[]-based methods you have to read the token length, then allocate a byte[] that's at least that large and System.arraycopy() all those bytes into it. [Unless, of course, you have already paid the price to read the entire application-protocol message into a byte[] -- in that case, sure, it makes sense to use the byte[]-based GSSContext methods]. > > So I believe that the InputStream parameters are useful because they allow a more efficient implementation than using byte[]. This is somehow what the example inside RFC 5653 7.4.8 is suggesting ByteArrayOutputStream os = new ByteArrayOutputStream(); ByteArrayInputStream is = null; do { // Re-create os? context.initSecContext(is, os); // send token if present if (os.size() > 0) sendToken(os); // check if we should expect more tokens if (context.isEstablished()) break; // another token expected from peer is = recvToken(); } while (true); but then the recvToken in the example above should not be defined as a ByteArrayInputStream. > > I admit that the argument for the OutputStream parameters is much weaker (hypothetically they could be useful if the application protocol used chunked framing such as ASN.1 indefinite-length encoding, but in reality application protocols probably just use simple framing with a token-length field at the beginning and so yeah, the OutputStream doesn't buy you anything, you may as well just go ahead and return a byte[]). Exactly, I don't know how to emit that length field before sending the bytes into the stream. Creating a method like the following is ugly. byte[] initSecContext(InputStream ins) > > > I agree that the "GSS-API authentication tokens contain a definite start and end" wording in RFC 2853 / 5653 makes it sound as though perhaps the original authors mistakenly believed that all GSSAPI context tokens included their own framing (if so, then the stream-based methods were just a mistake caused by a flawed assumption, and it would be good to correct that mistake). I'm a Johnny-come-lately to this and I don't know what the original authors actually thought / meant, but I choose to believe that no, they weren't confused about the (non-)framing of GSSAPI context tokens and so no, the stream-based GSSContext methods weren't a mistake; rather, I believe that they were thinking about InputStream wrappers such as the one I outlined above, so the stream-based GSSContext methods are valid (and shouldn't be deprecated), and the only thing that needs to be fixed is the misleading wording, not the Java methods. I don't know now. I am also late to this. > > If we do go ahead with deprecating the stream-based methods then yes, I'm fine with the changes that you outlined below: > >> [...] I propose to deprecate these methods in an I-D. >> [...] In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecated. The existing implementations will be still supported. > > Good. > > Incidentally, w.r.t. Oracle JDK / OpenJDK: the current implementation assumes that all context-initiation tokens (not just the initial token but also all subsequent context-initiation tokens) _do_ include framing (a GSSHeader). There are a couple of special-case exceptions (for the SPNEGO mechanism and for the SunNativeGSS provider), but in general the code requires that all input tokens have a GSSHeader (and will error out, probably with DEFECTIVE_TOKEN, if they don't), and always prepends a GSSHeader to any outgoing tokens that GSSContextSpi returns. > > So, even if the stream-based methods are deprecated, the current implementation will still only support GSSAPI mechanisms where every context-initiation token has GSSHeader framing. My guess is that removing that limitation would entail breaking the sun.security.jgss.spi (again). We don't plan to make any change. What we can say now is that they have a problem and could go wrong. If we add a new mechanism later that does not have a self-framing, we might have to consume all bytes available and treat it as the input token. --Max > > > > ________________________________________ > From: Wang Weijun [weijun.wang at oracle.com] > Sent: Sunday, March 15, 2015 20:46 > To: kitten at ietf.org; OpenJDK Dev list > Cc: Thomas Maslen; Benjamin Kaduk > Subject: On stream-based GSSContext methods in RFC 5653 > > Hi All > > I discussed with my colleagues on the stream-based methods and we think they are not well-designed: > > 1. A library should not define a wire protocol and assume the peer is using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 requires the application to define it. > > 2. It's impossible to implement these methods correctly when the mechanism token has no self-framing or the library has no knowledge of the token format (for example, > as a bridge talking to another GSS library). > > Therefore, I propose to deprecate these methods in an I-D. By deprecation, I'd like to remove the methods from the main content and describe the reason in a "Changes since RFC 5653" section. The specification for the methods will be moved to an appendix or the "Changes since RFC 5653" section will contain links to sections inside RFC 5653. > > In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecated. The existing implementations will be still supported. > > Thanks > Max From artem.smotrakov at oracle.com Fri Mar 20 06:49:48 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 20 Mar 2015 09:49:48 +0300 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <354B2ADB-0FBD-45AC-8CBB-E27744779F3C@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> <55096202.9010100@oracle.com> <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> <550AB569.80402@oracle.com> <354B2ADB-0FBD-45AC-8CBB-E27744779F3C@oracle.com> Message-ID: <550BC30C.3030400@oracle.com> Hi Max, Please see inline. On 03/19/2015 05:33 PM, Wang Weijun wrote: > This looks fine. > > One comment, > > 156 cmds.add("-Duser.dir=" + WORK_DIR); > > Looks unnecessary. In fact, I've never seen people setting user.dir on the command line. Agree. I removed this. > > Another comment, > > 80 * @run main NestedActions jar ReadPropertyExceptionAction.jar > 81 * ReadPropertyExceptionAction.class ReadPropertyException.class > 82 * > 83 * run tests > > Will line 83 make any trouble? I remember bare words (not in a tag) will be absorbed by the previous action so the lines above will be interpreted as > > @run main NestedActions jar ReadPropertyExceptionAction.jar ReadPropertyExceptionAction.class ReadPropertyException.class run tests > > Or maybe that blank line can end an a tag? Anyway I dare not use this. Yes, it makes a trouble. I removed this, but didn't update the webrev. Sorry about that and thanks for attention. Please take a look at http://cr.openjdk.java.net/~asmotrak/8048147/webrev.03/ Artem > > Thanks > Max > >> On Mar 19, 2015, at 19:39, Artem Smotrakov wrote: >> >> Hi Max, >> >> I agree that sometimes use of a shell script makes a test clearer. On the other hand, if we are trying to create pure Java tests, it increases overall coverage of Java APIs. >> >> I updated the tests to use ProcessTools, and simplified a little bit policy files for negative tests to make them clearer. Please take a look: >> >> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/ >> >> Artem >> >> On 03/18/2015 06:08 PM, Wang Weijun wrote: >>>> On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: >>>> >>>> The tests can be updated to start a new process with ProcessTools, or use a script. >>> Choose anyone you like. >>> >>> Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes. >>> >>> I'm a little surprised that with the classpath not pointing to jars the test still succeeds. The jars should have been granted different permissions. Maybe the test is not designed smart enough to detect the problem? >>> >>> --Max >>> >>>> Artem From weijun.wang at oracle.com Fri Mar 20 07:38:10 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Mar 2015 15:38:10 +0800 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: <550BC30C.3030400@oracle.com> References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> <55096202.9010100@oracle.com> <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> <550AB569.80402@oracle.com> <354B2ADB-0FBD-45AC-8CBB-E27744779F3C@oracle.com> <550BC30C.3030400@oracle.com> Message-ID: I see no problem now. Would you like me to push it for you? Please provide me the changeset comment you want to use. Thanks Max > On Mar 20, 2015, at 14:49, Artem Smotrakov wrote: > > Hi Max, > > Please see inline. > > On 03/19/2015 05:33 PM, Wang Weijun wrote: >> This looks fine. >> >> One comment, >> >> 156 cmds.add("-Duser.dir=" + WORK_DIR); >> >> Looks unnecessary. In fact, I've never seen people setting user.dir on the command line. > Agree. I removed this. >> >> Another comment, >> >> 80 * @run main NestedActions jar ReadPropertyExceptionAction.jar >> 81 * ReadPropertyExceptionAction.class ReadPropertyException.class >> 82 * >> 83 * run tests >> >> Will line 83 make any trouble? I remember bare words (not in a tag) will be absorbed by the previous action so the lines above will be interpreted as >> >> @run main NestedActions jar ReadPropertyExceptionAction.jar ReadPropertyExceptionAction.class ReadPropertyException.class run tests >> >> Or maybe that blank line can end an a tag? Anyway I dare not use this. > Yes, it makes a trouble. I removed this, but didn't update the webrev. Sorry about that and thanks for attention. > > Please take a look at http://cr.openjdk.java.net/~asmotrak/8048147/webrev.03/ > > Artem >> >> Thanks >> Max >> >>> On Mar 19, 2015, at 19:39, Artem Smotrakov wrote: >>> >>> Hi Max, >>> >>> I agree that sometimes use of a shell script makes a test clearer. On the other hand, if we are trying to create pure Java tests, it increases overall coverage of Java APIs. >>> >>> I updated the tests to use ProcessTools, and simplified a little bit policy files for negative tests to make them clearer. Please take a look: >>> >>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/ >>> >>> Artem >>> >>> On 03/18/2015 06:08 PM, Wang Weijun wrote: >>>>> On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: >>>>> >>>>> The tests can be updated to start a new process with ProcessTools, or use a script. >>>> Choose anyone you like. >>>> >>>> Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes. >>>> >>>> I'm a little surprised that with the classpath not pointing to jars the test still succeeds. The jars should have been granted different permissions. Maybe the test is not designed smart enough to detect the problem? >>>> >>>> --Max >>>> >>>>> Artem From artem.smotrakov at oracle.com Fri Mar 20 07:54:21 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 20 Mar 2015 10:54:21 +0300 Subject: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs In-Reply-To: References: <5506B4BD.2000004@oracle.com> <55094380.6040809@oracle.com> <493ED341-AE33-488B-B326-B02B224D882E@oracle.com> <08FAF349-7C9A-46EC-9A9F-C3AF8D1FBB89@oracle.com> <55096202.9010100@oracle.com> <97A64FC5-2EC3-41CE-8878-09CBBC692127@oracle.com> <550AB569.80402@oracle.com> <354B2ADB-0FBD-45AC-8CBB-E27744779F3C@oracle.com> <550BC30C.3030400@oracle.com> Message-ID: <550BD22D.2060904@oracle.com> Yes, please push it. 8048147: Privilege tests with JAAS Subject.doAs Reviewed-by: weijun My username is asmotrak http://openjdk.java.net/census#asmotrak Artem On 03/20/2015 10:38 AM, Wang Weijun wrote: > I see no problem now. > > Would you like me to push it for you? Please provide me the changeset comment you want to use. > > Thanks > Max > >> On Mar 20, 2015, at 14:49, Artem Smotrakov wrote: >> >> Hi Max, >> >> Please see inline. >> >> On 03/19/2015 05:33 PM, Wang Weijun wrote: >>> This looks fine. >>> >>> One comment, >>> >>> 156 cmds.add("-Duser.dir=" + WORK_DIR); >>> >>> Looks unnecessary. In fact, I've never seen people setting user.dir on the command line. >> Agree. I removed this. >>> Another comment, >>> >>> 80 * @run main NestedActions jar ReadPropertyExceptionAction.jar >>> 81 * ReadPropertyExceptionAction.class ReadPropertyException.class >>> 82 * >>> 83 * run tests >>> >>> Will line 83 make any trouble? I remember bare words (not in a tag) will be absorbed by the previous action so the lines above will be interpreted as >>> >>> @run main NestedActions jar ReadPropertyExceptionAction.jar ReadPropertyExceptionAction.class ReadPropertyException.class run tests >>> >>> Or maybe that blank line can end an a tag? Anyway I dare not use this. >> Yes, it makes a trouble. I removed this, but didn't update the webrev. Sorry about that and thanks for attention. >> >> Please take a look at http://cr.openjdk.java.net/~asmotrak/8048147/webrev.03/ >> >> Artem >>> Thanks >>> Max >>> >>>> On Mar 19, 2015, at 19:39, Artem Smotrakov wrote: >>>> >>>> Hi Max, >>>> >>>> I agree that sometimes use of a shell script makes a test clearer. On the other hand, if we are trying to create pure Java tests, it increases overall coverage of Java APIs. >>>> >>>> I updated the tests to use ProcessTools, and simplified a little bit policy files for negative tests to make them clearer. Please take a look: >>>> >>>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/ >>>> >>>> Artem >>>> >>>> On 03/18/2015 06:08 PM, Wang Weijun wrote: >>>>>> On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: >>>>>> >>>>>> The tests can be updated to start a new process with ProcessTools, or use a script. >>>>> Choose anyone you like. >>>>> >>>>> Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes. >>>>> >>>>> I'm a little surprised that with the classpath not pointing to jars the test still succeeds. The jars should have been granted different permissions. Maybe the test is not designed smart enough to detect the problem? >>>>> >>>>> --Max >>>>> >>>>>> Artem From weijun.wang at oracle.com Fri Mar 20 14:39:04 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Mar 2015 22:39:04 +0800 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules Message-ID: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Please review the code changes at http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ LoginContext is updated to use ServiceLoader to load configured LoginModules, and fallback to reflection if it cannot find one. Please notice that the fix does not include configuration of existing LoginModules since the current jdk9/dev module system does not support multiple modules implementing the same interface. Suppose it does, these 2 extra files will do the configuration: src/jdk.security.auth/META-INF/services/javax.security.auth.spi.LoginModule com.sun.security.auth.module.Krb5LoginModule com.sun.security.auth.module.UnixLoginModule com.sun.security.auth.module.JndiLoginModule com.sun.security.auth.module.KeyStoreLoginModule com.sun.security.auth.module.LdapLoginModule com.sun.security.auth.module.NTLoginModule src/java.management/META-INF/services/javax.security.auth.spi.LoginModule com.sun.jmx.remote.security.FileLoginModule I am hearing that jigsaw will provide a new way for service configuration. Compatibility issue: Before this code change, any class that includes the necessary methods (initialize, login, logout, abort, commit) can be configured as a login module, which does not necessarily implement the LoginModule interface itself. After this code change, it must implement the interface. We might need to update the JAAS programming guide in Java SE documentation to describe the new loading mechanism. Thanks Max From Alan.Bateman at oracle.com Fri Mar 20 15:38:35 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2015 15:38:35 +0000 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Message-ID: <550C3EFB.50401@oracle.com> On 20/03/2015 14:39, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ > > LoginContext is updated to use ServiceLoader to load configured LoginModules, and fallback to reflection if it cannot find one. Please notice that the fix does not include configuration of existing LoginModules since the current jdk9/dev module system does not support multiple modules implementing the same interface. Suppose it does, these 2 extra files will do the configuration: > > Just to clarify this, there isn't a module system in JDK 9 yet. The issue here is just having several resources named META-INF/services/javax.security.auth.spi.LoginModule as the build needs to concatenate the entries to create one services configuration file. This is a temporary issue of course and same named resources won't be an issue once all resources in the jimage container are keyed on module. Also as you said, we don't expect services configuration files will be needed anyway. -Alan. From mandy.chung at oracle.com Fri Mar 20 20:12:39 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Mar 2015 13:12:39 -0700 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Message-ID: <550C7F37.8050206@oracle.com> On 3/20/15 7:39 AM, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ It looks okay to me. Removing some use of reflection seems a good thing. One observation: invoke(String methodName) now calls the method statically and the implementation has conditional code depending on which of the four methods. It seems that you could do some refactoring to define 4 different methods for example: 571 invokePriv(LOGIN_METHOD) -> invokeLoginMethod This is an separate issue. Just to mention for future cleanup to consider. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Fri Mar 20 22:00:34 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 20 Mar 2015 15:00:34 -0700 Subject: Code review of JDK-8072385, Only the first DNSName entry is checked for endpoint identification In-Reply-To: <54FE8691.9060405@oracle.com> References: <54F71BE5.2050205@oracle.com> <54FE39AB.1080503@oracle.com> <54FE72C0.9000602@oracle.com> <54FE8691.9060405@oracle.com> Message-ID: <550C9882.4060908@oracle.com> Hi Xuelei, this looks good to me. --Jamil On 3/9/2015 10:52 PM, Xuelei Fan wrote: > On 3/10/2015 12:27 PM, Jamil Nimeh wrote: >> Hi Xuelei, I can't be an official reviewer, but I did look over the code >> and it looks pretty good to me. > I think it is OK to push if you reviewed the code. > >> I did have a couple questions though: >> >> * Line 1570 >> o Since the getSubjectAltNames() method is generic enough to take >> any int type it might be worthwhile to put some comments into >> the header stating that only those subjectAltName types that use >> String data should be passed into this function (see follow-on >> question below). > Good point. I added a note comment and updated the webrev. > >> * Line 1580 >> o If, for some reason, a maintainer were to ever pass in a >> different altname value, like 4 (X400Address), wouldn't the code >> cause a ClassCastException when trying to cast the returned >> byte[] to a String? Would it be worthwhile to either do a >> instanceof check on the returned value before the cast or catch >> the CCE before it goes up the stack? Or is it your desire to >> let the CCE be thrown? I ask only because earlier in >> isIdentityEquivalent() you take the time to catch parsing >> exceptions and handle it with a log message rather than let it >> unwind the stack. Would it be worthwhile to do something >> similar with a CCE down in getSubjectAltNames()? >> > It's better to check the instance for a good coding experiences. > > It's safe here as for subjectAltName type of DNS and IPAddress, the data > type is String. See the spec of > X509Certificate.getSubjectAlternativeNames(). > > We have the similar code in sun/security/util/HostnameChecker.java. > > Thanks, > Xuelei > >> But even as-is, this still looks good to me. >> >> --Jamil >> >> On 03/09/2015 05:24 PM, Xuelei Fan wrote: >>> Ping ... >>> >>> wbrev: http://cr.openjdk.java.net/~xuelei/8072385/webrev.00/ >>> >>> On 3/4/2015 10:51 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8072385 >>>> >>>> In SunJSSE implementation, during endpoint identification, there is a >>>> bug in SubjectAlternativeName matching that only the fist DNSName are >>>> checked. As may impact some business where host-name alias are used. >>>> >>>> The patch is attached. >>>> >>>> Thanks, >>>> Xuelei >>>> From jason.uh at oracle.com Fri Mar 20 23:10:43 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 20 Mar 2015 16:10:43 -0700 Subject: [9] RFR: 7194452: Remove "Reverse" PKIX CertPathBuilder implementation Message-ID: <550CA8F3.2070007@oracle.com> Please review this change to remove the "Reverse" CertPathBuilder mode, which has never been supported and is undocumented. webrev: http://cr.openjdk.java.net/~juh/7194452/00/ bug: https://bugs.openjdk.java.net/browse/JDK-7194452 Thanks, Jason From Thomas.Maslen at software.dell.com Fri Mar 20 02:15:08 2015 From: Thomas.Maslen at software.dell.com (Thomas Maslen) Date: Fri, 20 Mar 2015 02:15:08 +0000 Subject: On stream-based GSSContext methods in RFC 5653 In-Reply-To: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> , Message-ID: My personal 0.02. First, my overall reaction to this is pretty much the same as my reaction to the GSSException change proposed in the rfc5653bis draft: I believe that this aspect of 2853 / 5653 isn't broken and so I'm leery of "fixing" it -- but I don't feel strongly about it and I don't really object to it (much), I mostly just want to make sure that we look before we leap. [But I do agree that if (a) we deprecate the stream-based GSSContext methods and (b) we care about being able to both throw a GSSException and return an error token, then (c) yes, in that case the GSSException change would then be necessary]. To me, neither item 1 nor item 2 below is problematic for the stream-based methods. Perhaps the assumptions that I'm using are different than yours? What I mean by that is: I agree that if you took the raw InputStream from e.g. Socket.getInputStream() and passed it to a stream-based GSSContext method then yes, it would be problematic. But don't do that. Instead: (1) Read the token-length field from the raw InputStream. (There must be a token-length field, or something equivalent to it -- if there wasn't, you wouldn't be able to use the byte[]-based GSSContext methods either) (2) Use that length field to construct a wrapper InputStream (probably a subclass of FilterInputStream) that lets you read that number of bytes and then returns EOF (even though the underlying raw InputStream probably still has data available). Yes, I'm definitely glossing over some details about ensuring that you always advance the underlying stream to the end of the token, but that's just a SMOP. (3) Pass that wrapper InputStream (not the underlying raw InputStream) to the stream-based GSSContext method. The advantage of doing this, c.f. just using the byte[]-based methods, is efficiency: with the byte[]-based methods you have to read the token length, then allocate a byte[] that's at least that large and System.arraycopy() all those bytes into it. [Unless, of course, you have already paid the price to read the entire application-protocol message into a byte[] -- in that case, sure, it makes sense to use the byte[]-based GSSContext methods]. So I believe that the InputStream parameters are useful because they allow a more efficient implementation than using byte[]. I admit that the argument for the OutputStream parameters is much weaker (hypothetically they could be useful if the application protocol used chunked framing such as ASN.1 indefinite-length encoding, but in reality application protocols probably just use simple framing with a token-length field at the beginning and so yeah, the OutputStream doesn't buy you anything, you may as well just go ahead and return a byte[]). I agree that the "GSS-API authentication tokens contain a definite start and end" wording in RFC 2853 / 5653 makes it sound as though perhaps the original authors mistakenly believed that all GSSAPI context tokens included their own framing (if so, then the stream-based methods were just a mistake caused by a flawed assumption, and it would be good to correct that mistake). I'm a Johnny-come-lately to this and I don't know what the original authors actually thought / meant, but I choose to believe that no, they weren't confused about the (non-)framing of GSSAPI context tokens and so no, the stream-based GSSContext methods weren't a mistake; rather, I believe that they were thinking about InputStream wrappers such as the one I outlined above, so the stream-based GSSContext methods are valid (and shouldn't be deprecated), and the only thing that needs to be fixed is the misleading wording, not the Java methods. If we do go ahead with deprecating the stream-based methods then yes, I'm fine with the changes that you outlined below: > [...] I propose to deprecate these methods in an I-D. > [...] In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecated. The existing implementations will be still supported. Good. Incidentally, w.r.t. Oracle JDK / OpenJDK: the current implementation assumes that all context-initiation tokens (not just the initial token but also all subsequent context-initiation tokens) _do_ include framing (a GSSHeader). There are a couple of special-case exceptions (for the SPNEGO mechanism and for the SunNativeGSS provider), but in general the code requires that all input tokens have a GSSHeader (and will error out, probably with DEFECTIVE_TOKEN, if they don't), and always prepends a GSSHeader to any outgoing tokens that GSSContextSpi returns. So, even if the stream-based methods are deprecated, the current implementation will still only support GSSAPI mechanisms where every context-initiation token has GSSHeader framing. My guess is that removing that limitation would entail breaking the sun.security.jgss.spi (again). ________________________________________ From: Wang Weijun [weijun.wang at oracle.com] Sent: Sunday, March 15, 2015 20:46 To: kitten at ietf.org; OpenJDK Dev list Cc: Thomas Maslen; Benjamin Kaduk Subject: On stream-based GSSContext methods in RFC 5653 Hi All I discussed with my colleagues on the stream-based methods and we think they are not well-designed: 1. A library should not define a wire protocol and assume the peer is using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 requires the application to define it. 2. It's impossible to implement these methods correctly when the mechanism token has no self-framing or the library has no knowledge of the token format (for example, as a bridge talking to another GSS library). Therefore, I propose to deprecate these methods in an I-D. By deprecation, I'd like to remove the methods from the main content and describe the reason in a "Changes since RFC 5653" section. The specification for the methods will be moved to an appendix or the "Changes since RFC 5653" section will contain links to sections inside RFC 5653. In Oracle JDK and OpenJDK, we would like to mark these methods as @deprecated. The existing implementations will be still supported. Thanks Max From Alan.Bateman at oracle.com Sat Mar 21 10:54:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Mar 2015 10:54:19 +0000 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Message-ID: <550D4DDB.6080303@oracle.com> On 20/03/2015 14:39, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ > > : > > Compatibility issue: Before this code change, any class that includes the necessary methods (initialize, login, logout, abort, commit) can be configured as a login module, which does not necessarily implement the LoginModule interface itself. After this code change, it must implement the interface. > > We might need to update the JAAS programming guide in Java SE documentation to describe the new loading mechanism. > I think the changes look reasonable too. A minor suggestion is to change the existing comment "instantiate the LoginModule" to "locate and instantiate ...". On the compatibility issue then someone creating a JAAS configuration file that lists a that is not a LoginModule will cause CCE but this pops out as a LoginException with the CCE as cause now - right? This may be something for release notes. It would be good to get the JAAS documentation updated too. -Alan From weijun.wang at oracle.com Sat Mar 21 23:47:30 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 22 Mar 2015 07:47:30 +0800 Subject: [JDK-9] RFR: 8048618 Tests for PKCS12 write operations In-Reply-To: <550A66D2.60706@oracle.com> References: <55090E13.6080701@oracle.com> <5531F555-9EFC-4AEE-BE34-DCA7E9CDC0BD@oracle.com> <550A66D2.60706@oracle.com> Message-ID: Looks fine. One small issue: LEAD_CERT does not have a "\n" before the "-----END" line. Although X509Factory accepts it this is not correct. --Max > On Mar 19, 2015, at 14:04, zaiyao liu wrote: > > Hi Max, > > Thanks for review, > please check the update: http://cr.openjdk.java.net/~zailiu/8048618/webrev01/test/java/security/KeyStore/PKCS12/WriteP12Test.java.html > > Thanks again. > Kevin > ? 2015/3/18 14:23, Wang Weijun ??: >> >> 33 * WriteP12CertChainBad: same as WriteP12CertChain but chains order is >> 34 * user-ca-lead, the order is wrong so expects to fail. >> >> Really? What is the exception? > this line will catch the exception. > > 167 } catch (KeyStoreException e) { > >> Another suggestion, please move the text in the summary before the actual codes inside main() as comments. It's hard to page up and page down to find out what the tests are doing. > Fixed, thanks. >> Thanks >> Max >> >> >>> On Mar 18, 2015, at 13:33, zaiyao liu wrote: >>> >>> Hi Max, >>> >>> Please help to review this test: >>> >>> JDK issue:https://bugs.openjdk.java.net/browse/JDK-8048618 >>> Webrev:http://cr.openjdk.java.net/~zailiu/8048618/webrev/ >>> >>> Thanks >>> >>> Kevin > From weijun.wang at oracle.com Sun Mar 22 00:03:11 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 22 Mar 2015 08:03:11 +0800 Subject: Code review of JDK-8072385, Only the first DNSName entry is checked for endpoint identification In-Reply-To: <550C9882.4060908@oracle.com> References: <54F71BE5.2050205@oracle.com> <54FE39AB.1080503@oracle.com> <54FE72C0.9000602@oracle.com> <54FE8691.9060405@oracle.com> <550C9882.4060908@oracle.com> Message-ID: Looks fine to me too. The isEquivalent() method name is not very precise IMHO, maybe hasSame()? Of course, if has same is what isEquivalent means then it's OK. :-) Thanks Max > On Mar 21, 2015, at 06:00, Jamil Nimeh wrote: > > Hi Xuelei, this looks good to me. > > --Jamil > > On 3/9/2015 10:52 PM, Xuelei Fan wrote: >> On 3/10/2015 12:27 PM, Jamil Nimeh wrote: >>> Hi Xuelei, I can't be an official reviewer, but I did look over the code >>> and it looks pretty good to me. >> I think it is OK to push if you reviewed the code. >> >>> I did have a couple questions though: >>> >>> * Line 1570 >>> o Since the getSubjectAltNames() method is generic enough to take >>> any int type it might be worthwhile to put some comments into >>> the header stating that only those subjectAltName types that use >>> String data should be passed into this function (see follow-on >>> question below). >> Good point. I added a note comment and updated the webrev. >> >>> * Line 1580 >>> o If, for some reason, a maintainer were to ever pass in a >>> different altname value, like 4 (X400Address), wouldn't the code >>> cause a ClassCastException when trying to cast the returned >>> byte[] to a String? Would it be worthwhile to either do a >>> instanceof check on the returned value before the cast or catch >>> the CCE before it goes up the stack? Or is it your desire to >>> let the CCE be thrown? I ask only because earlier in >>> isIdentityEquivalent() you take the time to catch parsing >>> exceptions and handle it with a log message rather than let it >>> unwind the stack. Would it be worthwhile to do something >>> similar with a CCE down in getSubjectAltNames()? >>> >> It's better to check the instance for a good coding experiences. >> >> It's safe here as for subjectAltName type of DNS and IPAddress, the data >> type is String. See the spec of >> X509Certificate.getSubjectAlternativeNames(). >> >> We have the similar code in sun/security/util/HostnameChecker.java. >> >> Thanks, >> Xuelei >> >>> But even as-is, this still looks good to me. >>> >>> --Jamil >>> >>> On 03/09/2015 05:24 PM, Xuelei Fan wrote: >>>> Ping ... >>>> >>>> wbrev: http://cr.openjdk.java.net/~xuelei/8072385/webrev.00/ >>>> >>>> On 3/4/2015 10:51 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8072385 >>>>> >>>>> In SunJSSE implementation, during endpoint identification, there is a >>>>> bug in SubjectAlternativeName matching that only the fist DNSName are >>>>> checked. As may impact some business where host-name alias are used. >>>>> >>>>> The patch is attached. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> > From sean.mullan at oracle.com Sun Mar 22 14:41:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 22 Mar 2015 10:41:33 -0400 Subject: RFR 8074935: jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did In-Reply-To: <9C3DEB27-8B39-446D-9CAC-21EAE4C24D40@oracle.com> References: <9C3DEB27-8B39-446D-9CAC-21EAE4C24D40@oracle.com> Message-ID: <550ED49D.10207@oracle.com> Looks ok, though the copyright date on BadPem.java is incorrect. --Sean On 03/17/2015 06:02 AM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8074935/webrev.00/ > > In jdk8, we use Base64.getMimeDecoder() to parse PEM-encoded certs and it ignores every character not in the base-64 alphabet. PEM is more restricted and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug report and test). This fix will also reject them. > > I also updated the encode side so that the output is always 64 chars wide, which is a requirement of PEM (http://en.wikipedia.org/wiki/Base64#Privacy-enhanced_mail). > > Thanks > Max > From sean.mullan at oracle.com Sun Mar 22 15:04:51 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Sun, 22 Mar 2015 11:04:51 -0400 Subject: JDK 9 RFR of JDK-8075567: Mark intermittently failuring security-libs tests In-Reply-To: <550B740C.9010004@oracle.com> References: <550B740C.9010004@oracle.com> Message-ID: <550EDA13.1010204@oracle.com> Looks fine to me, Joe. --Sean On 03/19/2015 09:12 PM, joe darcy wrote: > Hello, > > Per a policy to mark intermittently failing tests (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032383.html), > please review the changes below to mark two security libs tests as > failing intermittently: > > sun/security/mscapi/ShortRSAKey1024.sh > sun/security/mscapi/SignUsingNONEwithRSA.sh > > To find these tests, I went through unresolved security-libs bugs > looking for test failures that had information updated within the last > six months or so. > > Please add or remove the intermittent jtreg keyword to security tests > appropriately going forward. > > Also, please consider the general recommendation to rewrite shell tests > as Java programs. The langtools team was able to remove nearly all shell > tests in their test suite. > > Thanks, > > -Joe > > diff -r cd4aea326e89 test/sun/security/mscapi/ShortRSAKey1024.sh > --- a/test/sun/security/mscapi/ShortRSAKey1024.sh Thu Mar 19 13:18:49 > 2015 -0700 > +++ b/test/sun/security/mscapi/ShortRSAKey1024.sh Thu Mar 19 17:59:43 > 2015 -0700 > @@ -30,6 +30,7 @@ > # @run shell ShortRSAKey1024.sh 1024 > # @run shell ShortRSAKey1024.sh 768 > # @run shell ShortRSAKey1024.sh 512 > +# @key intermittent > > # set a few environment variables so that the shell-script can run > stand-alone > # in the source directory > diff -r cd4aea326e89 test/sun/security/mscapi/SignUsingNONEwithRSA.sh > --- a/test/sun/security/mscapi/SignUsingNONEwithRSA.sh Thu Mar 19 > 13:18:49 2015 -0700 > +++ b/test/sun/security/mscapi/SignUsingNONEwithRSA.sh Thu Mar 19 > 17:59:43 2015 -0700 > @@ -28,6 +28,7 @@ > # @bug 6578658 > # @run shell SignUsingNONEwithRSA.sh > # @summary Sign using the NONEwithRSA signature algorithm from SunMSCAPI > +# @key intermittent > > # set a few environment variables so that the shell-script can run > stand-alone > # in the source directory > From zaiyao.liu at oracle.com Mon Mar 23 02:05:28 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Mon, 23 Mar 2015 10:05:28 +0800 Subject: [JDK-9] RFR: 8048618 Tests for PKCS12 write operations In-Reply-To: References: <55090E13.6080701@oracle.com> <5531F555-9EFC-4AEE-BE34-DCA7E9CDC0BD@oracle.com> <550A66D2.60706@oracle.com> Message-ID: <550F74E8.5000106@oracle.com> Hi Max, Thanks for review, please check the update: http://cr.openjdk.java.net/~zailiu/8048618/webrev.02/test/java/security/KeyStore/PKCS12/WriteP12Test.java.html Please help to push code after you finished review with following full comments: 8048618: Tests for PKCS12 write operations. Reviewed-by: weijun Contributed-by: Zaiyao Liu Thanks again. Kevin ? 2015/3/22 7:47, Wang Weijun ??: > Looks fine. > > One small issue: LEAD_CERT does not have a "\n" before the "-----END" line. Although X509Factory accepts it this is not correct. > > --Max > >> On Mar 19, 2015, at 14:04, zaiyao liu wrote: >> >> Hi Max, >> >> Thanks for review, >> please check the update: http://cr.openjdk.java.net/~zailiu/8048618/webrev01/test/java/security/KeyStore/PKCS12/WriteP12Test.java.html >> >> Thanks again. >> Kevin >> ? 2015/3/18 14:23, Wang Weijun ??: >>> 33 * WriteP12CertChainBad: same as WriteP12CertChain but chains order is >>> 34 * user-ca-lead, the order is wrong so expects to fail. >>> >>> Really? What is the exception? >> this line will catch the exception. >> >> 167 } catch (KeyStoreException e) { >> >>> Another suggestion, please move the text in the summary before the actual codes inside main() as comments. It's hard to page up and page down to find out what the tests are doing. >> Fixed, thanks. >>> Thanks >>> Max >>> >>> >>>> On Mar 18, 2015, at 13:33, zaiyao liu wrote: >>>> >>>> Hi Max, >>>> >>>> Please help to review this test: >>>> >>>> JDK issue:https://bugs.openjdk.java.net/browse/JDK-8048618 >>>> Webrev:http://cr.openjdk.java.net/~zailiu/8048618/webrev/ >>>> >>>> Thanks >>>> >>>> Kevin From fweimer at redhat.com Mon Mar 23 08:33:18 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 23 Mar 2015 09:33:18 +0100 Subject: RFR 8074935: jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did In-Reply-To: <9C3DEB27-8B39-446D-9CAC-21EAE4C24D40@oracle.com> References: <9C3DEB27-8B39-446D-9CAC-21EAE4C24D40@oracle.com> Message-ID: <550FCFCE.2060904@redhat.com> On 03/17/2015 11:02 AM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8074935/webrev.00/ > > In jdk8, we use Base64.getMimeDecoder() to parse PEM-encoded certs and it ignores every character not in the base-64 alphabet. PEM is more restricted and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug report and test). This fix will also reject them. Shouldn't you add a Base64.getPemDecoder() with these semantics? I think this decoder would be useful in other contexts as well. -- Florian Weimer / Red Hat Product Security From sean.mullan at oracle.com Mon Mar 23 18:57:14 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 23 Mar 2015 14:57:14 -0400 Subject: [9] RFR: 8074531: Remove javax.security.cert.X509Certificate usage in internal networking packages In-Reply-To: <5509F3AC.4030809@oracle.com> References: <5509F3AC.4030809@oracle.com> Message-ID: <5510620A.4040209@oracle.com> Hi Jason, * HttpsURLConnection.java, HttpsURLConnectionOldImpl.java This looks fine but as a next-step, we may be able to completely remove these classes, which have been deprecated for a long time and are implementation-specific. Can you check with Brad/Xuelei and open a separate issue to remove them if so? Otherwise, looks good. --Sean On 03/18/2015 05:52 PM, Jason Uh wrote: > Please review this change, which removes methods in internal net > packages that use the deprecated javax.security.cert.X509Certificate type. > > webrev: http://cr.openjdk.java.net/~juh/8074531/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8074531 > > Thanks, > Jason From weijun.wang at oracle.com Tue Mar 24 09:47:10 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 Mar 2015 17:47:10 +0800 Subject: RFR 8056174: New APIs for jar signing Message-ID: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ It provides a new jdk.Exported API JarSigner to perform jar signing. The class contains popular functions of the jarsigner tool. The jarsigner tool is unchanged and currently independent of the new class. The root repo also needs a little change: diff --git a/common/bin/unshuffle_list.txt b/common/bin/unshuffle_list.txt --- a/common/bin/unshuffle_list.txt +++ b/common/bin/unshuffle_list.txt @@ -1305,6 +1304,7 @@ jdk/src/jdk.httpserver/share/classes/com/sun/net/httpserver : jdk/src/share/classes/com/sun/net/httpserver jdk/src/jdk.httpserver/share/classes/sun/net/httpserver : jdk/src/share/classes/sun/net/httpserver jdk/src/jdk.jartool/share/classes/com/sun/jarsigner : jdk/src/share/classes/com/sun/jarsigner +jdk/src/jdk.jartool/share/classes/jdk/security/jarsigner : jdk/src/share/classes/jdk/security/jarsigner jdk/src/jdk.jartool/share/classes/sun/security/tools/jarsigner : jdk/src/share/classes/sun/security/tools/jarsigner jdk/src/jdk.jartool/share/classes/sun/tools/jar : jdk/src/share/classes/sun/tools/jar jdk/src/jdk.jcmd/share/classes/sun/tools/jcmd : jdk/src/share/classes/sun/tools/jcmd diff --git a/modules.xml b/modules.xml --- a/modules.xml +++ b/modules.xml @@ -1634,6 +1645,9 @@ com.sun.jarsigner + + jdk.security.jarsigner + jdk.javadoc Thanks Max From weijun.wang at oracle.com Tue Mar 24 10:13:32 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 Mar 2015 18:13:32 +0800 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <550D4DDB.6080303@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> <550D4DDB.6080303@oracle.com> Message-ID: <310D4B79-8ABF-4656-A246-6710B69EB65A@oracle.com> > On Mar 21, 2015, at 18:54, Alan Bateman wrote: > > On the compatibility issue then someone creating a JAAS configuration file that lists a that is not a LoginModule will cause CCE but this pops out as a LoginException with the CCE as cause now - right? This may be something for release notes. Correct. Added. --Max From ecki at zusammenkunft.net Tue Mar 24 11:28:24 2015 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 24 Mar 2015 12:28:24 +0100 Subject: DH Key sizes (again) Message-ID: Hello, it is good to see Java 8 support EDH with 1024 and 2048 bit keys. However it is still a problem that there is no negotiation in the TLS handshake and so a flexible client should be able to accept different key siztes. Apache since 2.4.7 sends 2048/3072 and 4096. And starting with 2.4.10 it sends even 6k and 8k (standard) primes. I see a comment in the source that the DH provider needs to be improved to actually handle those. So I wonder if there are any plans for this? Is there a good way to request it? Would filing a RFE on bugreport.java.com be the right place? Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From janwillem.janssen at luminis.eu Tue Mar 24 12:53:07 2015 From: janwillem.janssen at luminis.eu (Jan Willem Janssen) Date: Tue, 24 Mar 2015 12:53:07 +0000 Subject: custom critical X509v3 extensions Message-ID: Hi, When a X509TrustManager validates an endpoint certificate containing a critical custom extension the sun.security.validator.EndEntityChecker will always fail. While this is correct behaviour, and according to the spec, there appears no way of adding support for custom critical extensions on endpoint certificates?! -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 My world is revolving around INAETICS and Amdatu Luminis Technologies B.V. Churchillplein 1 7314 BZ Apeldoorn +31 88 586 46 00 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 817 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sean.mullan at oracle.com Tue Mar 24 13:12:19 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 24 Mar 2015 09:12:19 -0400 Subject: custom critical X509v3 extensions In-Reply-To: References: Message-ID: <551162B3.9090202@oracle.com> On 03/24/2015 08:53 AM, Jan Willem Janssen wrote: > Hi, > > When a X509TrustManager validates an endpoint certificate containing a > critical custom extension the sun.security.validator.EndEntityChecker > will always fail. While this is correct behaviour, and according to > the spec, there appears no way of adding support for custom critical > extensions on endpoint certificates?! The CertPath API allows you to create your own PKIXCertPathChecker to process custom extensions. This could then be added to the CertPathTrustManagerParameters (via the addCertPathChecker method of PKIXParameters), but it looks like there is no hook in the EndEntityChecker to call the PKIXCertPathCheckers. I'll file a bug. --Sean > > -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > My world is revolving around INAETICS and Amdatu > > Luminis Technologies B.V. > Churchillplein 1 > 7314 BZ Apeldoorn > +31 88 586 46 00 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > From janwillem.janssen at luminis.eu Wed Mar 25 08:00:58 2015 From: janwillem.janssen at luminis.eu (Jan Willem Janssen) Date: Wed, 25 Mar 2015 08:00:58 +0000 Subject: custom critical X509v3 extensions In-Reply-To: <551162B3.9090202@oracle.com> References: <551162B3.9090202@oracle.com> Message-ID: > On 24 Mar 2015, at 14:12, Sean Mullan wrote: > > On 03/24/2015 08:53 AM, Jan Willem Janssen wrote: >> >> When a X509TrustManager validates an endpoint certificate containing a >> critical custom extension the sun.security.validator.EndEntityChecker >> will always fail. While this is correct behaviour, and according to >> the spec, there appears no way of adding support for custom critical >> extensions on endpoint certificates?! > > The CertPath API allows you to create your own PKIXCertPathChecker to process custom extensions. This could then be added to the CertPathTrustManagerParameters (via the addCertPathChecker method of PKIXParameters), but it looks like there is no hook in the EndEntityChecker to call the PKIXCertPathCheckers. Yes, that is also what I was doing, but was a little surprised that EndEntityChecker didn?t take any of those custom PKIXCertPathCheckers into consideration. > I'll file a bug. Thanks for the clarification, Sean! -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 My world is revolving around INAETICS and Amdatu Luminis Technologies B.V. Churchillplein 1 7314 BZ Apeldoorn +31 88 586 46 00 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 817 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sean.coffey at oracle.com Wed Mar 25 13:52:45 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 25 Mar 2015 13:52:45 +0000 Subject: RFR (xs) 8059588: deadlock in java/io/PrintStream when verbose javax.net.debug flags are set Message-ID: <5512BDAD.3010901@oracle.com> This issue was reported while debugging a pkcs11 issue. While I can't reproduce it, the captured stack trace does show a deadlock issue. Fix is to simply stop using the SessionManager class lock to record and print the maxActiveSessions in use and replace it with a local lock. bug: https://bugs.openjdk.java.net/browse/JDK-8059588 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8059588/webrev/ Regards, Sean. From sean.mullan at oracle.com Wed Mar 25 19:17:18 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 25 Mar 2015 15:17:18 -0400 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <550D4DDB.6080303@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> <550D4DDB.6080303@oracle.com> Message-ID: <551309BE.6050108@oracle.com> On 03/21/2015 06:54 AM, Alan Bateman wrote: > On 20/03/2015 14:39, Wang Weijun wrote: >> Please review the code changes at >> >> http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ >> This looks good to me too. > It would be good to get the JAAS documentation updated too. Yes, we should update the specification of the JavaLoginConfig type and the relevant JAAS tutorials and programming guides to describe the use of ServiceLoader to find LoginModule implementations. Can you file a followon issue in the docs/guides component and add a "securitydocs" label? --Sean From weijun.wang at oracle.com Thu Mar 26 05:28:42 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Mar 2015 13:28:42 +0800 Subject: RFR 8075575/8075576: 2 com/sun/security/auth tests failed in certain env Message-ID: <5513990A.5080207@oracle.com> Please review the change at http://cr.openjdk.java.net/~weijun/8075575/webrev.00 The test checks for certain English text in the output, and cannot find if running in another locale. Tests now forced running in English. I've tried modifying the tests to check for localized texts returning from ResourceBundle.getgetBundle().getString(). The test is not easy to read and in one test MessageFormat.format() needs to be called. I abandon this attempt and choose the current fix. Thanks Max From mandy.chung at oracle.com Thu Mar 26 16:26:00 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 Mar 2015 09:26:00 -0700 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> Message-ID: <55143318.8050407@oracle.com> On 3/24/2015 2:47 AM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ > > It provides a new jdk.Exported API JarSigner to perform jar signing. The class contains popular functions of the jarsigner tool. The jarsigner tool is unchanged and currently independent of the new class. Passing comment when skimming on the webrev: JarSignerException.ErrorCode - do you expect the caller will want to process error handling differently with different type of error? I wonder if the error message would be good enough wrapping the Throwable cause. Should JarSignerException be an unchecked exception? One other thing to mention: @jdk.Exported will go away some time. For now it's okay to use it and will be cleaned up together with other JDK exported APIs when time comes. > The root repo also needs a little change: > > diff --git a/common/bin/unshuffle_list.txt b/common/bin/unshuffle_list.txt This is a new package that you don't need to include in the unshuffle_list.txt (that's mainly for backporting use). > diff --git a/modules.xml b/modules.xml > --- a/modules.xml > +++ b/modules.xml > @@ -1634,6 +1645,9 @@ > > com.sun.jarsigner > > + > + jdk.security.jarsigner > + > > > jdk.javadoc > Looks fine. Mandy From anthony.scarpino at oracle.com Thu Mar 26 17:46:58 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 26 Mar 2015 10:46:58 -0700 Subject: Code Review Request: 8064546 CipherInputStream throws BadPaddingException if stream is not fully read Message-ID: <55144612.4090308@oracle.com> Hi, I'd like a review of the below webrev: http://cr.openjdk.java.net/~ascarpino/8064546/webrev/ The code change is very simple, where close() should not throw exceptions. Most of the code change is comments that are just informational The attached test goes through all the scenarios making sure AEAD and non-AEAD ciphers operate as expected. thanks Tony From sean.mullan at oracle.com Thu Mar 26 19:32:36 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Mar 2015 15:32:36 -0400 Subject: DH Key sizes (again) In-Reply-To: References: Message-ID: <55145ED4.9040403@oracle.com> Hi Bernd, On 03/24/2015 07:28 AM, Bernd wrote: > Hello, > > it is good to see Java 8 support EDH with 1024 and 2048 bit keys. > However it is still a problem that there is no negotiation in the TLS > handshake and so a flexible client should be able to accept different > key siztes. Apache since 2.4.7 sends 2048/3072 and 4096. And starting > with 2.4.10 it sends even 6k and 8k (standard) primes. > > I see a comment in the source that the DH provider needs to be improved > to actually handle those. So I wonder if there are any plans for this? > Is there a good way to request it? Would filing a RFE on > bugreport.java.com be the right place? There is currently an open issue for this: https://bugs.openjdk.java.net/browse/JDK-8072452 Let me look into what our plans are for this and get back to you. I agree it is important to resolve. --Sean From sean.mullan at oracle.com Thu Mar 26 20:41:22 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Mar 2015 16:41:22 -0400 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> Message-ID: <55146EF2.2010005@oracle.com> On 03/24/2015 05:47 AM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ > > It provides a new jdk.Exported API JarSigner to perform jar signing. The class contains popular functions of the jarsigner tool. The jarsigner tool is unchanged and currently independent of the new class. * AlgorithmId - checKeyAlgSigAlgkMatch Should this be named "checkKeyAndSigAlgMatch"? * Builder - why are methods public when class is package-private? * JarSigner - For digestAlg and sigAlg you should add a pointer to the relevant section of the Standard Algorithm Names guide for a list of standard algorithms that can be specified. * JarSignerException - is there ever a reason to add a ctor that takes a String for the exception message? * API - copyright should be 2015 * options.sh - how is this relevant if jarsigner has not been updated to use the new API yet? Also, we should avoid adding more shell script tests. --Sean From jason.uh at oracle.com Thu Mar 26 22:37:56 2015 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 26 Mar 2015 15:37:56 -0700 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> References: <5508D62A.9010507@oracle.com> <550A0D08.1020901@oracle.com> <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> Message-ID: <55148A44.1040700@oracle.com> Please review this revision: http://cr.openjdk.java.net/~juh/7145757/01/ * all get()/set() calls to CertificateExtensions and CRLExtensions is by OID * get()/set() from X509CertImpl/Info continue to work by name. ex: X509CertImpl.get("x509.info.extensions.") * a global nameCache is maintained in OIDMap as suggested * no IOException from CRLExtensions * fixed a bug on line 753 of X509CertImpl to allow extension deletion Thanks, Jason On 03/18/2015 06:06 PM, Wang Weijun wrote: > Yes, it will be extensive, but since we already make all keys OID, we should always call those set/get() with OIDs for performance. In case we might miss some, inside the implementation of get/set(), we can still accept names. > > Also, it seems there is no need for a nameCache everywhere, you can probably maintain a global one inside OIDMap. > > As for the IOException, I think it's because CRLExtensions does not have getExtension() that returns null. Now that you create another inconsistence that X509CRLImpl.getExtension() is starting to throw IOE while X509CertImpl.getExtension() does not. > > --Max > >> On Mar 19, 2015, at 07:40, Jason Uh wrote: >> >> Hi Max, >> >> On 03/18/2015 04:09 PM, Wang Weijun wrote: >>> Hi Jason >>> >>> I was thinking about changing all set/get calls to using OID so inside CertificateExtensions and CRLExtensions you won't need to care about name conversions. Is that possible? >> >> It might be, but it'd call for more extensive changes. Currently, when certificates are parsed, the extensions are added using the name, and when they are retrieved, they are also specified by name -- for example, X509CertImpl.getBasicConstraints() calls a get() method with the BasicConstraints alias as the lookup parameter. >> >> It's been a while, but the last we spoke about this, I think you wanted to keep the changes for this contained within CertificateExtensions and CRLExtensions. If that's still the case, we'll have to do this name conversion. If not, I could try changing things outside of these classes. >> >>> Also I see you adding some IOException throwing and catching. Is there any case you actually see them? I would think if that really happen there might be some programming error. >> >> I added the IOExceptions mainly to keep CRLExtensions consistent with CertificateExtensions. I thought it was a little odd that they weren't being thrown, but they may not need to be there for CRLExtensions. I can take them out. >> >>> --Max >>> >>>> On Mar 18, 2015, at 09:34, Jason Uh wrote: >>>> >>>> Please review this fix, which changes the internal map in sun.security.x509.CertificateExtensions and CRLExtensions to always use the OID as the key. >>>> >>>> As stated in the JBS issue: >>>>> The sun.security.x509.CertificateExtensions class maintains a Map map field to store all the extensions it manages. The key of map uses the name (say, "BasicConstraints") of the extension, or the OID when the type of the extension is unknown. >>>> >>>> With this change, the map will consistently use the OID as the key. >>>> >>>> webrev: http://cr.openjdk.java.net/~juh/7145757/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-7145757 >>>> >>>> Thanks, >>>> Jason >>> > From weijun.wang at oracle.com Fri Mar 27 04:18:16 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 27 Mar 2015 12:18:16 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <55146EF2.2010005@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> <55146EF2.2010005@oracle.com> Message-ID: <3B75C91A-7B6C-4A23-9EC9-8454F05F94E2@oracle.com> > On Mar 27, 2015, at 04:41, Sean Mullan wrote: > > On 03/24/2015 05:47 AM, Wang Weijun wrote: >> Hi All >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ >> >> It provides a new jdk.Exported API JarSigner to perform jar signing. The class contains popular functions of the jarsigner tool. The jarsigner tool is unchanged and currently independent of the new class. > > * AlgorithmId > > - checKeyAlgSigAlgkMatch > > Should this be named "checkKeyAndSigAlgMatch"? OK. > > * Builder > > - why are methods public when class is package-private? I forgot to move the class into sun.security.tools.jarsigner and make it public. Then it's accessible from both JarSigner (the API) and sun.security.tools.jarsigner.Main (the tool). > > * JarSigner > > - For digestAlg and sigAlg you should add a pointer to the relevant section of the Standard Algorithm Names guide for a list of standard algorithms that can be specified. Yes. > > * JarSignerException > > - is there ever a reason to add a ctor that takes a String for the exception message? I added your comments from the other mail below. > Passing comment when skimming on the webrev: > > JarSignerException.ErrorCode - do you expect the caller will want > to process error handling differently with different type of error? > > I wonder if the error message would be good enough wrapping the > Throwable cause. Yes, I agree a ctor with arguments (message, cause) is enough. The type of cause is actually equivalent to the ErrorCode. The new message argument should be localized. > Should JarSignerException be an unchecked exception? In traditional Java style, it should be checked. Normally unchecked exception should not be expected if running normally, but here we will see TSA connection error, algorithm name error, etc. In fact I originally suggested unchecked exception, but my main reason is that a checked permission is not friendly with lambda and a little old fashioned. > > * API > > - copyright should be 2015 > > * options.sh > > - how is this relevant if jarsigner has not been updated to use the new API yet? Also, we should avoid adding more shell script tests. Not relevant, I'll remove it. Thanks Max > > --Sean > > From weijun.wang at oracle.com Fri Mar 27 10:53:52 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 27 Mar 2015 18:53:52 +0800 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: <55148A44.1040700@oracle.com> References: <5508D62A.9010507@oracle.com> <550A0D08.1020901@oracle.com> <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> <55148A44.1040700@oracle.com> Message-ID: > On Mar 27, 2015, at 06:37, Jason Uh wrote: > > Please review this revision: > http://cr.openjdk.java.net/~juh/7145757/01/ > > * a global nameCache is maintained in OIDMap as suggested Can you just use the existing OIDMap.getId() method? It looks like your getCachedOid(name) is the same as getId("x509.info.extensions." + name). In fact, since the OIDMap only contains mapping of extensions, I'd suggest renaming it to ExtensionMap and change the name inside to short names (without the "x509.info.extensions." prefix). --Max From sean.mullan at oracle.com Fri Mar 27 18:58:26 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 27 Mar 2015 14:58:26 -0400 Subject: RFR (xs) 8059588: deadlock in java/io/PrintStream when verbose javax.net.debug flags are set In-Reply-To: <5512BDAD.3010901@oracle.com> References: <5512BDAD.3010901@oracle.com> Message-ID: <5515A852.5040806@oracle.com> This looks fine, just one comment. Can you put braces around the if debug statement on lines 117-118 (just to be safe). --Sean On 03/25/2015 09:52 AM, Se?n Coffey wrote: > This issue was reported while debugging a pkcs11 issue. While I can't > reproduce it, the captured stack trace does show a deadlock issue. Fix > is to simply stop using the SessionManager class lock to record and > print the maxActiveSessions in use and replace it with a local lock. > > bug: https://bugs.openjdk.java.net/browse/JDK-8059588 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8059588/webrev/ > > Regards, > Sean. From sean.coffey at oracle.com Fri Mar 27 19:05:41 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 27 Mar 2015 19:05:41 +0000 Subject: RFR (xs) 8059588: deadlock in java/io/PrintStream when verbose javax.net.debug flags are set In-Reply-To: <5515A852.5040806@oracle.com> References: <5512BDAD.3010901@oracle.com> <5515A852.5040806@oracle.com> Message-ID: <5515AA05.1010308@oracle.com> Thanks Sean. Yes - I'll add those braces before pushing. regards, Sean. On 27/03/2015 18:58, Sean Mullan wrote: > This looks fine, just one comment. Can you put braces around the if > debug statement on lines 117-118 (just to be safe). > > --Sean > > On 03/25/2015 09:52 AM, Se?n Coffey wrote: >> This issue was reported while debugging a pkcs11 issue. While I can't >> reproduce it, the captured stack trace does show a deadlock issue. Fix >> is to simply stop using the SessionManager class lock to record and >> print the maxActiveSessions in use and replace it with a local lock. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8059588 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8059588/webrev/ >> >> Regards, >> Sean. From bradford.wetmore at oracle.com Fri Mar 27 19:27:43 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 27 Mar 2015 12:27:43 -0700 Subject: RFR (xs) 8059588: deadlock in java/io/PrintStream when verbose javax.net.debug flags are set In-Reply-To: <5515AA05.1010308@oracle.com> References: <5512BDAD.3010901@oracle.com> <5515A852.5040806@oracle.com> <5515AA05.1010308@oracle.com> Message-ID: <5515AF2F.6070605@oracle.com> Sean, Is this a java.security.debug or a javax.net.debug issue as mentioned in the synopsis? It imports from sun.security.util.Debug, which is java.security.debug, not javax.net.debug. In the bug, both variables were set. ...deleted... -Djavax.net.debug=ssl,handshake,record,keygen,session,defaultctx,sslctx,ses sioncache,keymanager,trustmanager -Dcom.oracle.security.ucrypto.debug=true -Djava.security.debug=all -Djsse.S Probably the synopsis should be changed. Brad On 3/27/2015 12:05 PM, Se?n Coffey wrote: > Thanks Sean. Yes - I'll add those braces before pushing. > > regards, > Sean. > > On 27/03/2015 18:58, Sean Mullan wrote: >> This looks fine, just one comment. Can you put braces around the if >> debug statement on lines 117-118 (just to be safe). >> >> --Sean >> >> On 03/25/2015 09:52 AM, Se?n Coffey wrote: >>> This issue was reported while debugging a pkcs11 issue. While I can't >>> reproduce it, the captured stack trace does show a deadlock issue. Fix >>> is to simply stop using the SessionManager class lock to record and >>> print the maxActiveSessions in use and replace it with a local lock. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8059588 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8059588/webrev/ >>> >>> Regards, >>> Sean. > From sean.coffey at oracle.com Fri Mar 27 19:30:28 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 27 Mar 2015 19:30:28 +0000 Subject: RFR (xs) 8059588: deadlock in java/io/PrintStream when verbose javax.net.debug flags are set In-Reply-To: <5515AF2F.6070605@oracle.com> References: <5512BDAD.3010901@oracle.com> <5515A852.5040806@oracle.com> <5515AA05.1010308@oracle.com> <5515AF2F.6070605@oracle.com> Message-ID: <5515AFD4.4080509@oracle.com> Brad, you're correct. The debug flag for pkcs11 is enabled via java.security.debug=pkcs11 - I'll update the bug synopsis. The changeset has already been pushed though. regards, Sean. On 27/03/2015 19:27, Bradford Wetmore wrote: > Sean, > > Is this a java.security.debug or a javax.net.debug issue as mentioned > in the synopsis? It imports from sun.security.util.Debug, which is > java.security.debug, not javax.net.debug. > > In the bug, both variables were set. > > ...deleted... > -Djavax.net.debug=ssl,handshake,record,keygen,session,defaultctx,sslctx,ses > > sioncache,keymanager,trustmanager > -Dcom.oracle.security.ucrypto.debug=true > -Djava.security.debug=all -Djsse.S > > Probably the synopsis should be changed. > > Brad > > > > On 3/27/2015 12:05 PM, Se?n Coffey wrote: >> Thanks Sean. Yes - I'll add those braces before pushing. >> >> regards, >> Sean. >> >> On 27/03/2015 18:58, Sean Mullan wrote: >>> This looks fine, just one comment. Can you put braces around the if >>> debug statement on lines 117-118 (just to be safe). >>> >>> --Sean >>> >>> On 03/25/2015 09:52 AM, Se?n Coffey wrote: >>>> This issue was reported while debugging a pkcs11 issue. While I can't >>>> reproduce it, the captured stack trace does show a deadlock issue. Fix >>>> is to simply stop using the SessionManager class lock to record and >>>> print the maxActiveSessions in use and replace it with a local lock. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059588 >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8059588/webrev/ >>>> >>>> Regards, >>>> Sean. >> From mandy.chung at oracle.com Fri Mar 27 20:30:30 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 Mar 2015 13:30:30 -0700 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <3B75C91A-7B6C-4A23-9EC9-8454F05F94E2@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> <55146EF2.2010005@oracle.com> <3B75C91A-7B6C-4A23-9EC9-8454F05F94E2@oracle.com> Message-ID: <5515BDE6.4090807@oracle.com> On 3/26/15 9:18 PM, Wang Weijun wrote: >> >> JarSignerException.ErrorCode - do you expect the caller will want >> to process error handling differently with different type of error? >> >> I wonder if the error message would be good enough wrapping the >> Throwable cause. > Yes, I agree a ctor with arguments (message, cause) is enough. The type of cause is actually equivalent to the ErrorCode. The new message argument should be localized. Generally, JDK tool emitted messages are localized but exception messages are not localized. I notice that some security exception messages are localized (sun/security/util/Resources.java and sun/security/util/AuthResources.java) that may make sense for example parsing policy file. I think the application using this API should be handling the localization not in the exception message. > >> Should JarSignerException be an unchecked exception? > In traditional Java style, it should be checked. Normally unchecked exception should not be expected if running normally, but here we will see TSA connection error, algorithm name error, etc. > > In fact I originally suggested unchecked exception, but my main reason is that a checked permission is not friendly with lambda and a little old fashioned. This exception is thrown at error cases. It looks like when the exception is raised, there is no action the caller can do other than outputting an error message and exit, right? Then unchecked exception would be more appropriate (see Effective Java item 59). Mandy From jason.uh at oracle.com Fri Mar 27 21:19:16 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 27 Mar 2015 14:19:16 -0700 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: References: <5508D62A.9010507@oracle.com> <550A0D08.1020901@oracle.com> <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> <55148A44.1040700@oracle.com> Message-ID: <5515C954.8010306@oracle.com> On 03/27/2015 03:53 AM, Wang Weijun wrote: > >> On Mar 27, 2015, at 06:37, Jason Uh wrote: >> >> Please review this revision: >> http://cr.openjdk.java.net/~juh/7145757/01/ >> >> * a global nameCache is maintained in OIDMap as suggested > > Can you just use the existing OIDMap.getId() method? It looks like your getCachedOid(name) is the same as getId("x509.info.extensions." + name). > > In fact, since the OIDMap only contains mapping of extensions, I'd suggest renaming it to ExtensionMap and change the name inside to short names (without the "x509.info.extensions." prefix). OK, thanks for that suggestion. I thought there was some significance to using the "full" name in OIDMap, but if that's not necessary, it makes things more flexible. Here is the latest revision that uses only the existing OIDMap (now called ExtensionsMap). http://cr.openjdk.java.net/~juh/7145757/02/ Thanks, Jason > --Max > From weijun.wang at oracle.com Sat Mar 28 14:45:55 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 28 Mar 2015 22:45:55 +0800 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: <5515C954.8010306@oracle.com> References: <5508D62A.9010507@oracle.com> <550A0D08.1020901@oracle.com> <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> <55148A44.1040700@oracle.com> <5515C954.8010306@oracle.com> Message-ID: > On Mar 28, 2015, at 05:19, Jason Uh wrote: > > > > On 03/27/2015 03:53 AM, Wang Weijun wrote: >> >>> On Mar 27, 2015, at 06:37, Jason Uh wrote: >>> >>> Please review this revision: >>> http://cr.openjdk.java.net/~juh/7145757/01/ >>> >>> * a global nameCache is maintained in OIDMap as suggested >> >> Can you just use the existing OIDMap.getId() method? It looks like your getCachedOid(name) is the same as getId("x509.info.extensions." + name). >> >> In fact, since the OIDMap only contains mapping of extensions, I'd suggest renaming it to ExtensionMap and change the name inside to short names (without the "x509.info.extensions." prefix). > > OK, thanks for that suggestion. I thought there was some significance to using the "full" name in OIDMap, I think it was designed to be more powerful (see how OtherName uses it) but unfortunately it hasn't been so. Now that with jdk9/module it is no more accessible from outside the JDK, we can simplify it. > but if that's not necessary, it makes things more flexible. Here is the latest revision that uses only the existing OIDMap (now called ExtensionsMap). > > http://cr.openjdk.java.net/~juh/7145757/02/ Will read it. Thanks Max > > Thanks, > Jason > >> --Max >> From weijun.wang at oracle.com Sat Mar 28 15:17:59 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 28 Mar 2015 23:17:59 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <5515BDE6.4090807@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> <55146EF2.2010005@oracle.com> <3B75C91A-7B6C-4A23-9EC9-8454F05F94E2@oracle.com> <5515BDE6.4090807@oracle.com> Message-ID: > On Mar 28, 2015, at 04:30, Mandy Chung wrote: > > On 3/26/15 9:18 PM, Wang Weijun wrote: >>> >>> JarSignerException.ErrorCode - do you expect the caller will want >>> to process error handling differently with different type of error? >>> >>> I wonder if the error message would be good enough wrapping the >>> Throwable cause. >> Yes, I agree a ctor with arguments (message, cause) is enough. The type of cause is actually equivalent to the ErrorCode. The new message argument should be localized. > > Generally, JDK tool emitted messages are localized but exception messages > are not localized. I notice that some security exception messages are > localized (sun/security/util/Resources.java and sun/security/util/AuthResources.java) > that may make sense for example parsing policy file. (Not really, the policy file format is not localized, why should its error msg be?) > > I think the application using this API should be handling the localization > not in the exception message. Suppose someone writes a GUI tool as a wrapper of this API. It is not easy for it to understand all exception messages and localize them. Throwable has a getLocalizedMessage() method, I'll see if I can use it. Actually, since this exception should always be generated inside JDK, shall I just remove all constructors from the public API? (Suppose there is an easy way to construct it without a public ctor). Is there such an example? > >> >>> Should JarSignerException be an unchecked exception? >> In traditional Java style, it should be checked. Normally unchecked exception should not be expected if running normally, but here we will see TSA connection error, algorithm name error, etc. >> >> In fact I originally suggested unchecked exception, but my main reason is that a checked permission is not friendly with lambda and a little old fashioned. > > This exception is thrown at error cases. It looks like when the > exception is raised, there is no action the caller can do other > than outputting an error message and exit, right? Then > unchecked exception would be more appropriate (see Effective Java > item 59). Great answer. I now think it should be unchecked. Thanks Max > > Mandy > > From weijun.wang at oracle.com Mon Mar 30 15:24:24 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 30 Mar 2015 23:24:24 +0800 Subject: Lambda in security manager initialization fail Message-ID: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> I have a customized security manager: import java.security.AccessController; import java.security.PrivilegedAction; public class A3 extends SecurityManager { public A3() { // 1. Using lambda AccessController.doPrivileged((PrivilegedAction) () -> null); // 2. Using inner class AccessController.doPrivileged(new PrivilegedAction() { @Override public Void run() { return null; } }); } } If I use the inner class, everything is OK. If the lambda, I see this error: $ java -Djava.security.manager=A3 Error occurred during initialization of VM java.lang.ExceptionInInitializerError at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) at A3.(A3.java:6) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:444) at sun.misc.Launcher.(Launcher.java:96) at sun.misc.Launcher.(Launcher.java:57) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1440) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1425) Caused by: java.lang.NullPointerException at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:1065) at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) at java.lang.invoke.BoundMethodHandle$SpeciesData.initForBootstrap(BoundMethodHandle.java:358) at java.lang.invoke.BoundMethodHandle$SpeciesData.(BoundMethodHandle.java:447) at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) at A3.(A3.java:6) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:444) Any reason why? Thanks Max From peter.levart at gmail.com Mon Mar 30 20:01:42 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 30 Mar 2015 22:01:42 +0200 Subject: Lambda in security manager initialization fail In-Reply-To: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> References: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> Message-ID: <5519ABA6.2030409@gmail.com> Hi Max, On 03/30/2015 05:24 PM, Wang Weijun wrote: > I have a customized security manager: > > import java.security.AccessController; > import java.security.PrivilegedAction; > > public class A3 extends SecurityManager { > public A3() { > // 1. Using lambda > AccessController.doPrivileged((PrivilegedAction) > () -> null); > // 2. Using inner class > AccessController.doPrivileged(new PrivilegedAction() { > @Override > public Void run() { > return null; > } > }); > } > } > > If I use the inner class, everything is OK. If the lambda, I see this error: > > $ java -Djava.security.manager=A3 > Error occurred during initialization of VM > java.lang.ExceptionInInitializerError > at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) > at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) > at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) > at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) > at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) > at A3.(A3.java:6) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:444) > at sun.misc.Launcher.(Launcher.java:96) > at sun.misc.Launcher.(Launcher.java:57) > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1440) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1425) > Caused by: java.lang.NullPointerException > at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) > at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:1065) > at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) > at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) > at java.lang.invoke.BoundMethodHandle$SpeciesData.initForBootstrap(BoundMethodHandle.java:358) > at java.lang.invoke.BoundMethodHandle$SpeciesData.(BoundMethodHandle.java:447) > at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) > at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) > at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) > at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) > at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) > at A3.(A3.java:6) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:444) > > Any reason why? > > Thanks > Max > > I'm including mlvm-dev list because I think this is caused by unusual initialization sequence triggered by initialization of java.lang.invoke infrastructure because lambdas use invokedynamic and method handles. The part of stack trace that is interesting is this: Caused by: java.lang.NullPointerException at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:1065) at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) makeCbmhCtor calls MethodType.fromMethodDescriptorString(..., null) with null ClassLoader, which propagates to the following BytecodeDescriptor.parseMethod method: static List> parseMethod(String bytecodeSignature, int start, int end, ClassLoader loader) { if (loader == null) loader = ClassLoader.getSystemClassLoader(); String str = bytecodeSignature; int[] i = {start}; ArrayList> ptypes = new ArrayList>(); if (i[0] < end && str.charAt(i[0]) == '(') { ++i[0]; // skip '(' while (i[0] < end && str.charAt(i[0]) != ')') { Class pt = parseSig(str, i, end, loader); if (pt == null || pt == void.class) parseError(str, "bad argument type"); ptypes.add(pt); } ++i[0]; // skip ')' } else { parseError(str, "not a method type"); } Class rtype = parseSig(str, i, end, loader); if (rtype == null || i[0] != end) parseError(str, "bad return type"); ptypes.add(rtype); return ptypes; } this method checks for null 'loader' and replaces it with the result of ClassLoader.getSystemClassLoader(). But invoking this method is actually re-entering it, as this whole stack trace is started from within the call to that method: .... .... at sun.misc.Launcher.(Launcher.java:96) at sun.misc.Launcher.(Launcher.java:57) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1440) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1425) ...this re-entering of ClassLoader.getSystemClassLoader() also re-enters Launcher.getLauncher(): private static synchronized void initSystemClassLoader() { if (!sclSet) { if (scl != null) throw new IllegalStateException("recursive invocation"); sun.misc.Launcher l = sun.misc.Launcher.getLauncher(); if (l != null) { Throwable oops = null; scl = l.getClassLoader(); try { scl = AccessController.doPrivileged( new SystemClassLoaderAction(scl)); } catch (PrivilegedActionException pae) { oops = pae.getCause(); if (oops instanceof InvocationTargetException) { oops = oops.getCause(); } } if (oops != null) { if (oops instanceof Error) { throw (Error) oops; } else { // wrap the exception throw new Error(oops); } } } sclSet = true; } } ...which returns null and the whole initialization of 'scl' is skipped, therefore ClassLoader.getSystemClassLoader() returns null, which is later passed to BytecodeDescriptor.parseSig(...., null) which throws NPE when dereferencing it. This re-entering of ClassLoader.getSystemClassLoader() is caused by Launcher which instantiates a custom SecurityManager, which uses lambdas which triggers java.lang.invoke infrastructure initialization which uses ClassLoader.getSystemClassLoader(). I think that java.lang.invoke infrastructure initialization should not need to have access to system class loader. All types it deals with are loadable by bootstrap class loader. I too have already encountered a problem because of that and my suggestion was to create an internal method similar to MethodType.fromMethodDescriptorString() that would treat null ClassLoader as bootstrap class loader and use this method for internal initialization instead of the public one: http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodType.fromDescriptor/webrev.01/ With this patch, your A3 security manager using lambdas works normally. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Mar 30 20:12:43 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 30 Mar 2015 16:12:43 -0400 Subject: Lambda in security manager initialization fail In-Reply-To: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> References: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> Message-ID: <5519AE3B.9050300@oracle.com> The NPE is at BytecodeDescriptor.parseSig#83, which says: return loader.loadClass(name); so the null ref seems likely to be loader. The loader is initially passed in from BoundMethodHandle#817, which provides a null loader, indicating that it wants the system loader. At the start of parseMethod, we see: if (loader == null) loader = ClassLoader.getSystemClassLoader(); so the loader variable that is being deref'ed is the result of ClassLoader.getSystemClassLoader, which must be null in order to NPE here. ClassLoader.getSystemClassLoader checks for a security manager, but since you're still initializing the security manager, this is likely to be null. So you're going to get the value of `scl` after `initSystemClassLoader` has completed. Overall this smells of a bootstrapping issue; you're calling into the MH machinery possibly before the classloading machinery (and definitely before the security manager) is fully initialized, and you're getting back a null from ClassLoader.getSystemClassLoader. HTH, -Brian On 3/30/2015 11:24 AM, Wang Weijun wrote: > I have a customized security manager: > > import java.security.AccessController; > import java.security.PrivilegedAction; > > public class A3 extends SecurityManager { > public A3() { > // 1. Using lambda > AccessController.doPrivileged((PrivilegedAction) > () -> null); > // 2. Using inner class > AccessController.doPrivileged(new PrivilegedAction() { > @Override > public Void run() { > return null; > } > }); > } > } > > If I use the inner class, everything is OK. If the lambda, I see this error: > > $ java -Djava.security.manager=A3 > Error occurred during initialization of VM > java.lang.ExceptionInInitializerError > at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) > at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) > at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) > at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) > at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) > at A3.(A3.java:6) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:444) > at sun.misc.Launcher.(Launcher.java:96) > at sun.misc.Launcher.(Launcher.java:57) > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1440) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1425) > Caused by: java.lang.NullPointerException > at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) > at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:1065) > at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) > at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) > at java.lang.invoke.BoundMethodHandle$SpeciesData.initForBootstrap(BoundMethodHandle.java:358) > at java.lang.invoke.BoundMethodHandle$SpeciesData.(BoundMethodHandle.java:447) > at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) > at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) > at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) > at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) > at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) > at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) > at A3.(A3.java:6) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:444) > > Any reason why? > > Thanks > Max > > From Alan.Bateman at oracle.com Mon Mar 30 20:29:54 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Mar 2015 21:29:54 +0100 Subject: Lambda in security manager initialization fail In-Reply-To: <5519ABA6.2030409@gmail.com> References: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> <5519ABA6.2030409@gmail.com> Message-ID: <5519B242.1070403@oracle.com> On 30/03/2015 21:01, Peter Levart wrote: > : > > I think that java.lang.invoke infrastructure initialization should not > need to have access to system class loader. All types it deals with > are loadable by bootstrap class loader. I too have already encountered > a problem because of that and my suggestion was to create an internal > method similar to MethodType.fromMethodDescriptorString() that would > treat null ClassLoader as bootstrap class loader and use this method > for internal initialization instead of the public one: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodType.fromDescriptor/webrev.01/ > > > With this patch, your A3 security manager using lambdas works normally. Another one that has come once or twice is using method references in code that executes early in the startup. There are boxing cases that use TypeConvertingMethodAdapter.boxingDescriptor and hence the formatter code that tries to locate locale providers using the system class loader. This can lead to recursive initialization issues that pop out as BootstrapMethodError. So if we are making this area more robust then this might need to be looked at too. -Alan From weijun.wang at oracle.com Tue Mar 31 03:40:23 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 31 Mar 2015 11:40:23 +0800 Subject: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names In-Reply-To: References: <5508D62A.9010507@oracle.com> <550A0D08.1020901@oracle.com> <523E4097-9101-438A-AE21-50754131B2C3@oracle.com> <55148A44.1040700@oracle.com> <5515C954.8010306@oracle.com> Message-ID: CRLExtensions.java ================== 116 Class extClass = ExtensionsMap.getClass(ext.getExtensionId()); 117 if (extClass == null) { // Unsupported extension 118 if (ext.isCritical()) 119 unsupportedCritExt = true; 120 if (map.put(ext.getId(), ext) != null) 121 throw new CRLException("Duplicate extensions not allowed"); 122 return; 123 } 124 Constructor cons = extClass.getConstructor(PARAMS); 125 Object[] passed = new Object[] {Boolean.valueOf(ext.isCritical()), 126 ext.getExtensionValue()}; 127 CertAttrSet crlExt = (CertAttrSet)cons.newInstance(passed); 128 if (map.put(ext.getId(), (Extension)crlExt) != null) { 129 throw new CRLException("Duplicate extensions not allowed"); 130 } I see no reason to convert cons.newInstance(passed) first to one type then another. Also, the 2 throw statements can be combined to one. 195 public void set(String oid, Object obj) { 196 map.put(oid, (Extension) obj); 197 } How about simply set(Object obj) or set(Extension ext)? You can always find oid from ext.getId(). This prevents unnoticed codes still using the name as keys. I'd like to add a comment to the map field, something like For known extensions listed in ExtensionMap, the value must be of a child type of Extension (defined in ExtensionMap). This is quite critical for the getExtension() methods in X509CRLImpl to work correctly. CertificateExtensions.java ========================== Same as above, but in the comment of map, there is an extra case Known extensions which is unparseable and not critical will be stored in an unparseableExtensions map. Since we don't use names as keys, CertificateExtensions is not a typical CertAttrSet now. Remove the implements clause. OtherName.java ============== ExtensionMap will not support OtherName anymore. getGNI() should always return null. File a new RFE on how to implement OtherName in post-jdk9 era. certAttributes.html =================== 229 Extensions can be added by implementing the 230 sun.security.x509.CertAttrSet interface and 231 subclassing sun.security.x509.Extension class. 232 Register the new extension using the ExtensionsMap class. After jdk9, these interface/class will not be available outside jdk. File an enhancement on how to do this later. ExtensionsMap.java ================== 195 public static void addAttribute(String name, String oid, Class clazz) 196 throws CertificateException { After jdk9, this method will not be available outside jdk. Mention this in the enhancement filed above. Thanks Max > On Mar 28, 2015, at 22:45, Wang Weijun wrote: > >> >> On Mar 28, 2015, at 05:19, Jason Uh wrote: >> >> >> >> On 03/27/2015 03:53 AM, Wang Weijun wrote: >>> >>>> On Mar 27, 2015, at 06:37, Jason Uh wrote: >>>> >>>> Please review this revision: >>>> http://cr.openjdk.java.net/~juh/7145757/01/ >>>> >>>> * a global nameCache is maintained in OIDMap as suggested >>> >>> Can you just use the existing OIDMap.getId() method? It looks like your getCachedOid(name) is the same as getId("x509.info.extensions." + name). >>> >>> In fact, since the OIDMap only contains mapping of extensions, I'd suggest renaming it to ExtensionMap and change the name inside to short names (without the "x509.info.extensions." prefix). >> >> OK, thanks for that suggestion. I thought there was some significance to using the "full" name in OIDMap, > > I think it was designed to be more powerful (see how OtherName uses it) but unfortunately it hasn't been so. Now that with jdk9/module it is no more accessible from outside the JDK, we can simplify it. > >> but if that's not necessary, it makes things more flexible. Here is the latest revision that uses only the existing OIDMap (now called ExtensionsMap). >> >> http://cr.openjdk.java.net/~juh/7145757/02/ > > Will read it. > > Thanks > Max > >> >> Thanks, >> Jason >> >>> --Max From weijun.wang at oracle.com Tue Mar 31 03:57:31 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 31 Mar 2015 11:57:31 +0800 Subject: CertificateExtensions References: Message-ID: <8592CB88-7F28-48BF-AC5B-E0C0C573E955@oracle.com> Hi Sean Are you OK with this? > CertificateExtensions.java > ========================== > > Since we don't use names as keys, CertificateExtensions is not a typical CertAttrSet now. Remove the implements clause. Almost every class in the x509 package is built around the CertAttrSet and they together weave an elegant net. It will be nice if CertificateExtensions can only use the hierarchical names as keys, but unfortunately, it has to use OID sometimes. My suggestion above breaks it from the CertAttrSet net. I won't dare to do this before jdk9 because people outside might use these classes, but now it's probably safe to do so. Said that, CertificateExtensions is now an alien. Although its sibling CRLExtensions has always been one. Thanks Max From Jenny.Lighthart at Polycom.com Tue Mar 31 17:09:15 2015 From: Jenny.Lighthart at Polycom.com (Lighthart, Jenny) Date: Tue, 31 Mar 2015 10:09:15 -0700 Subject: Does TLS 1.2 with SunPKCS11-NSS provider work in FIPS mode Message-ID: <5F5B900BF6A44E40939EEE937F9CA1251A7CD47773@CRPMBOXPRD09.polycom.com> Hello Java Security Devs, The following exception occurs while processing serverHelloDone during an attempt at TLS1.2 with NSS in FIPS mode (via modutil) . java.security.NoSuchAlgorithmException: no such algorithm: SunTls12RsaPremasterSecret for provider SunPKCS11-NSS Both the client and the server are running from a unit test using: * JDK 1.8.0_31-b13 * nss-3.16.2.3-3 The same test runs fine in FIPS mode using TLS1.1 or TLS1.0. The same test also runs with TLS1.2 when the keystore is not in FIPS mode. I am thinking that it is not supported. SunPKCS11-NSS provider needs to be updated with the SunTLS12* algorithms before this will work. The JSSE's ClientKeyExchange expects to be able to obtain a KeyGenerator specific to TLS1.2. When in FIPS mode, the crypto provider is SunPKCS11-NSS and it does not have the requested algorithm. Can anyone confirm or deny this? Any ideas as to when it will be supported? I've been all over the map trying to figure this one out. I am pretty sure at this point that it is not a problem with the NSS library. I can provide full stack trace and debug output as needed, but am hoping someone can answer first whether this configuration should be expected to work. Thanks for your help, Jenny -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Mar 31 23:35:08 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Apr 2015 07:35:08 +0800 Subject: Does TLS 1.2 with SunPKCS11-NSS provider work in FIPS mode In-Reply-To: <5F5B900BF6A44E40939EEE937F9CA1251A7CD47773@CRPMBOXPRD09.polycom.com> References: <5F5B900BF6A44E40939EEE937F9CA1251A7CD47773@CRPMBOXPRD09.polycom.com> Message-ID: <551B2F2C.9070803@oracle.com> Hi Jenny, As there is no PKCS#11 spec to support the mechanism, it is a known issue to us: https://bugs.openjdk.java.net/browse/JDK-8029661 Need to look into the new development of PKCS11 standards. Regards, Xuelei On 4/1/2015 1:09 AM, Lighthart, Jenny wrote: > Hello Java Security Devs, > > > > The following exception occurs while processing serverHelloDone during > an attempt at TLS1.2 with NSS in FIPS mode (via modutil) . > > > > java.security.NoSuchAlgorithmException: no such algorithm: > SunTls12RsaPremasterSecret for provider SunPKCS11-NSS > > > > Both the client and the server are running from a unit test using: > > ? JDK 1.8.0_31-b13 > > ? nss-3.16.2.3-3 > > > > The same test runs fine in FIPS mode using TLS1.1 or TLS1.0. The same > test also runs with TLS1.2 when the keystore is not in FIPS mode. > > > > I am thinking that it is not supported. SunPKCS11-NSS provider needs to > be updated with the SunTLS12* algorithms before this will work. The > JSSE's ClientKeyExchange expects to be able to obtain a KeyGenerator > specific to TLS1.2. When in FIPS mode, the crypto provider is > SunPKCS11-NSS and it does not have the requested algorithm. > > > > Can anyone confirm or deny this? Any ideas as to when it will be supported? > > > > I've been all over the map trying to figure this one out. I am pretty > sure at this point that it is not a problem with the NSS library. I can > provide full stack trace and debug output as needed, but am hoping > someone can answer first whether this configuration should be expected > to work. > > > > Thanks for your help, > > Jenny >