Re: Relook at 6937978: let keytool -gencert generate the chain
OK.
Thanks,
Xuelei
On 1/21/2011 4:23 PM, Weijun Wang wrote:
On 01/21/2011 04:12 PM, Xuelei Fan wrote:
Is there any impact on the return value of
KeyStore.getCertificateChain(String)?
Nothing. This method returns what's actually inside the KeyStore entry.
My proposal only make the output of keytool -gencert -file certs
command different. As described in my number 2 reason below, it won't
even make any changes to the keytool -import -file certs result.
Max
Andrew
On 1/21/2011 12:25 PM, Weijun Wang wrote:
Hi Sean
Some time ago we enhanced keytool -gencert to generate a cert chain,
including certicates from the end-entity to the secondary level CA,
except the root CA. I have some different opinion now, and think maybe
it's better to include the root CA.
1. There is no spec saying a chain cannot include the root CA. In fact,
in MSIE's certificate exporting dialog, when p7b format is selected and
a chain is exported, it includes the root CA cert.
2. No matter if the root CA cert is there or not, when we call keytool
-importcert on the chain, if the root CA is already trusted, the reply
can be imported silently, and inside the PrivateKeyEntry, the root CA
cert will be added anyway.
3. *Here comes the important reason*: If the root CA is not already
trusted, keytool -importcert command will show a warning asking the
user to accept the last cert in the chain. I'm quite sure the user would
like to see the root CA info here, but not the secondary CA.
The code change will be a simple
diff --git a/src/share/classes/sun/security/tools/KeyTool.java
b/src/share/classes/sun/security/tools/KeyTool.java
--- a/src/share/classes/sun/security/tools/KeyTool.java
+++ b/src/share/classes/sun/security/tools/KeyTool.java
@@ -1249,9 +1249,7 @@
for (Certificate ca: keyStore.getCertificateChain(alias)) {
if (ca instanceof X509Certificate) {
X509Certificate xca = (X509Certificate)ca;
-if (!isSelfSigned(xca)) {
dumpCert(xca, out);
-}
}
}
}
Thanks
Max
Original Message
Subject: hg: jdk7/tl/jdk: 6937978: let keytool -gencert generate the
chain
Date: Fri, 16 Apr 2010 02:06:34 +
From: weijun.w...@sun.com
To: jdk7-chan...@openjdk.java.net, compiler-...@openjdk.java.net,
core-libs-...@openjdk.java.net, serviceability-...@openjdk.java.net,
security-dev@openjdk.java.net, net-...@openjdk.java.net
Changeset: db4fd2fdf196
Author:weijun
Date: 2010-04-16 10:06 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db4fd2fdf196
6937978: let keytool -gencert generate the chain
Reviewed-by: mullan
! src/share/classes/sun/security/tools/KeyTool.java
! test/sun/security/tools/keytool/selfissued.sh
Re: code review request for CR 6989705: ECC security code native code compiler warnings
Vincent Ryan wrote: Hello Alan, Please review the following webrev which removes 100's of nuisance compiler warnings generated by our ECC code: http://rialto.ireland.sun.com/~vinnie/webrevs/jdk7/6989705/webrev/ Getting rid of the #pragmas and the other changes look okay to me. The only concern is the Makefile changes to hide the remaining warnings. Would there be many changes required to address those so that those warnings can be re-enabled? -Alan
Re: code review request for CR 6989705: ECC security code native code compiler warnings
On 21/01/2011 14:42, Alan Bateman wrote: Vincent Ryan wrote: Hello Alan, Please review the following webrev which removes 100's of nuisance compiler warnings generated by our ECC code: http://rialto.ireland.sun.com/~vinnie/webrevs/jdk7/6989705/webrev/ Getting rid of the #pragmas and the other changes look okay to me. The only concern is the Makefile changes to hide the remaining warnings. Would there be many changes required to address those so that those warnings can be re-enabled? -Alan The remaining warnings are mostly loss-of-precision warnings - which are safe to inhibit because they are due to wide data types which have been masked down to narrower data types before assignment. I'll take another pass through the code to examine whether any of these warnings can also be eliminated.
Re: code review request for CR 6989705: ECC security code native code compiler warnings
On Jan 21, 2011, at 7:08 AM, Vincent Ryan wrote: On 21/01/2011 14:42, Alan Bateman wrote: Vincent Ryan wrote: Hello Alan, Please review the following webrev which removes 100's of nuisance compiler warnings generated by our ECC code: http://rialto.ireland.sun.com/~vinnie/webrevs/jdk7/6989705/webrev/ Getting rid of the #pragmas and the other changes look okay to me. The only concern is the Makefile changes to hide the remaining warnings. Would there be many changes required to address those so that those warnings can be re-enabled? -Alan The remaining warnings are mostly loss-of-precision warnings - which are safe to inhibit because they are due to wide data types which have been masked down to narrower data types before assignment. I'll take another pass through the code to examine whether any of these warnings can also be eliminated. Normally explicit casts tend to get rid of the narrowing warnings, and makes it obvious in the code that we know it is happening and want it to be happening. It's the 'long' type you have to watch out for, on 64bit Windows it's 32bits as I recall. I'm ok with some special cases warnings that we decide we never want to see because they are like 90% useless or broken, but it makes me nervous to just shut down all occurrences if there might be some value to that warning. I know fixing these warnings is a bit of a pain, but I do think it's worth it in the long run. I appreciate all efforts in this area. Thanks. -kto
hg: jdk7/tl/jdk: 2 new changesets
Changeset: f26d1a7fe4d2 Author:mchung Date: 2011-01-21 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f26d1a7fe4d2 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Reviewed-by: ksrini ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 9c18818e7a5f Author:mchung Date: 2011-01-21 09:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c18818e7a5f Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java
hg: jdk7/tl/jdk: 2 new changesets
Changeset: 2381e810330b Author:zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter exception. Reviewed-by: alanb, phh, dcubed, dsamersoff, coleenp, acorn ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d03e47de3a89 Author:zgu Date: 2011-01-21 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d03e47de3a89 Merge
