From Vincent.Ryan at Sun.COM Mon Mar 1 03:43:07 2010 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Mon, 01 Mar 2010 11:43:07 +0000 Subject: [security-dev 01653]: Re: Ending support for Java 1.1 policy files In-Reply-To: <4B065D7D.3090600@sun.com> References: <4B065D7D.3090600@sun.com> Message-ID: <4B8BA84B.9040101@sun.com> Please review this minor change to eliminate a reference to the sun.security.provider.IdentityDatabase class in the java.security configuration file. That class was removed as part of our modularization effort. http://cr.openjdk.java.net/~vinnie/6921001/webrev.00/ Thanks. From Sean.Mullan at Sun.COM Mon Mar 1 07:19:11 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Mon, 01 Mar 2010 10:19:11 -0500 Subject: [security-dev 01654]: Re: Ending support for Java 1.1 policy files In-Reply-To: <4B8BA84B.9040101@sun.com> References: <4B065D7D.3090600@sun.com> <4B8BA84B.9040101@sun.com> Message-ID: <4B8BDAEF.90706@sun.com> Looks fine to me. --Sean Vincent Ryan wrote: > Please review this minor change to eliminate a reference to the > sun.security.provider.IdentityDatabase class in the java.security > configuration file. That class was removed as part of our > modularization effort. > > > http://cr.openjdk.java.net/~vinnie/6921001/webrev.00/ > > > Thanks. From vincent.ryan at sun.com Mon Mar 1 10:00:23 2010 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Mon, 01 Mar 2010 18:00:23 +0000 Subject: [security-dev 01655]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100301180103.D0ACF41DBD@hg.openjdk.java.net> Changeset: 78d91c4223cb Author: vinnie Date: 2010-03-01 17:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78d91c4223cb 6921001: api/java_security/IdentityScope/IdentityScopeTests.html#getSystemScope fails starting from b78 JDK7 Reviewed-by: mullan ! src/share/classes/java/security/IdentityScope.java ! src/share/lib/security/java.security + test/java/security/IdentityScope/NoDefaultSystemScope.java Changeset: 893034df4ec2 Author: vinnie Date: 2010-03-01 18:00 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/893034df4ec2 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java From Yu-Ching.Peng at Sun.COM Mon Mar 1 16:44:17 2010 From: Yu-Ching.Peng at Sun.COM (Valerie Peng) Date: Mon, 01 Mar 2010 16:44:17 -0800 Subject: [security-dev 01656]: Re: Code review request: 6844909: support allow_weak_crypto in krb5.conf In-Reply-To: References: <31561261.1243309885610.JavaMail.sbladm@swsblss4-new> Message-ID: <4B8C5F61.2060205@Sun.COM> Hi, Max, Changes look fine, here are some minor comments: 1) In EType.java, line 60, 64 should be indented w/ one extra space. 2) In EType.java, there should be comments added to "BUILTIN_ETYPES", and "BUILTIN_ETYPES_NOAES256" mentioning about the first two entries are removed when ALLOW_WEAK_CRYPTO is false. 3) In EType.java, line 235 and 236 still mentions these weak crypto etypes regardless. Shouldn't it be updated? Thanks, Valerie On 02/28/10 23:07, Max (Weijun) Wang wrote: > Hi Valerie > > Can you please take a review on this fix? > > http://cr.openjdk.java.net/~weijun/6844909/webrev.00 > > Basically, when "allow_weak_crypto = false" is set in krb5.conf's [libdefaults], DES-related etypes will not be used. Note that this setting also removes any weak etypes in the default_*_enctypes settings. This config was added in MIT's krb5-1.7 and defaults to false in 1.8. However, for compatibility (which we care a lot in Java), its default value is still true in Java. > > Thanks > Max > > > >> *Change Request ID*: 6844909 >> >> *Synopsis*: support allow_weak_crypto in krb5.conf >> >> >> === *Description* ============================================================ >> Latest MIT krb5 supports a allow_weak_crypto key in krb5.conf, when set to true, disallows DES be used in all kinds of etypes. We can support it also. >> >> Currently, MIT krb5's default value for this key is false, but it might become true one day. >> >> > It's true in 1.8 now. > > >> *** (#1 of 1): 2009-05-26 03:50:36 GMT+00:00 weijun.wang at sun.com >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100301/26a1040d/attachment.html From Weijun.Wang at Sun.COM Mon Mar 1 16:54:03 2010 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 02 Mar 2010 08:54:03 +0800 Subject: [security-dev 01657]: Re: Code review request: 6844909: support allow_weak_crypto in krb5.conf In-Reply-To: <4B8C5F61.2060205@Sun.COM> References: <31561261.1243309885610.JavaMail.sbladm@swsblss4-new> <4B8C5F61.2060205@Sun.COM> Message-ID: <3A4C9B54-C867-4D00-9A0A-0FF64230604D@Sun.COM> Hi Valerie Thanks! All suggestions accepted. Webrev updated at http://cr.openjdk.java.net/~weijun/6844909/webrev.01 Thanks again Max On Mar 2, 2010, at 8:44 AM, Valerie Peng wrote: > Hi, Max, > > Changes look fine, here are some minor comments: > 1) In EType.java, line 60, 64 should be indented w/ one extra space. > 2) In EType.java, there should be comments added to "BUILTIN_ETYPES", and "BUILTIN_ETYPES_NOAES256" mentioning about the first two entries are removed when ALLOW_WEAK_CRYPTO is false. > 3) In EType.java, line 235 and 236 still mentions these weak crypto etypes regardless. Shouldn't it be updated? > > Thanks, > Valerie > On 02/28/10 23:07, Max (Weijun) Wang wrote: >> Hi Valerie >> >> Can you please take a review on this fix? >> >> >> http://cr.openjdk.java.net/~weijun/6844909/webrev.00 >> >> >> Basically, when "allow_weak_crypto = false" is set in krb5.conf's [libdefaults], DES-related etypes will not be used. Note that this setting also removes any weak etypes in the default_*_enctypes settings. This config was added in MIT's krb5-1.7 and defaults to false in 1.8. However, for compatibility (which we care a lot in Java), its default value is still true in Java. >> >> Thanks >> Max >> >> >> >> >>> *Change Request ID*: 6844909 >>> >>> *Synopsis*: support allow_weak_crypto in krb5.conf >>> >>> >>> === *Description* ============================================================ >>> Latest MIT krb5 supports a allow_weak_crypto key in krb5.conf, when set to true, disallows DES be used in all kinds of etypes. We can support it also. >>> >>> Currently, MIT krb5's default value for this key is false, but it might become true one day. >>> >>> >>> >> It's true in 1.8 now. >> >> >> >>> *** (#1 of 1): 2009-05-26 03:50:36 GMT+00:00 weijun.wang at sun.com >>> >>> >>> >> >> >> > From Yu-Ching.Peng at Sun.COM Mon Mar 1 16:59:43 2010 From: Yu-Ching.Peng at Sun.COM (Valerie Peng) Date: Mon, 01 Mar 2010 16:59:43 -0800 Subject: [security-dev 01658]: Re: Code review request: 6844909: support allow_weak_crypto in krb5.conf In-Reply-To: <3A4C9B54-C867-4D00-9A0A-0FF64230604D@Sun.COM> References: <31561261.1243309885610.JavaMail.sbladm@swsblss4-new> <4B8C5F61.2060205@Sun.COM> <3A4C9B54-C867-4D00-9A0A-0FF64230604D@Sun.COM> Message-ID: <4B8C62FF.2060807@Sun.COM> Hi, Max, Looks good, no further comments. Thanks, Valerie On 03/01/10 16:54, Max (Weijun) Wang wrote: > Hi Valerie > > Thanks! All suggestions accepted. > > Webrev updated at http://cr.openjdk.java.net/~weijun/6844909/webrev.01 > > Thanks again > Max > > > On Mar 2, 2010, at 8:44 AM, Valerie Peng wrote: > > >> Hi, Max, >> >> Changes look fine, here are some minor comments: >> 1) In EType.java, line 60, 64 should be indented w/ one extra space. >> 2) In EType.java, there should be comments added to "BUILTIN_ETYPES", and "BUILTIN_ETYPES_NOAES256" mentioning about the first two entries are removed when ALLOW_WEAK_CRYPTO is false. >> 3) In EType.java, line 235 and 236 still mentions these weak crypto etypes regardless. Shouldn't it be updated? >> >> Thanks, >> Valerie >> On 02/28/10 23:07, Max (Weijun) Wang wrote: >> >>> Hi Valerie >>> >>> Can you please take a review on this fix? >>> >>> >>> http://cr.openjdk.java.net/~weijun/6844909/webrev.00 >>> >>> >>> Basically, when "allow_weak_crypto = false" is set in krb5.conf's [libdefaults], DES-related etypes will not be used. Note that this setting also removes any weak etypes in the default_*_enctypes settings. This config was added in MIT's krb5-1.7 and defaults to false in 1.8. However, for compatibility (which we care a lot in Java), its default value is still true in Java. >>> >>> Thanks >>> Max >>> >>> >>> >>> >>> >>>> *Change Request ID*: 6844909 >>>> >>>> *Synopsis*: support allow_weak_crypto in krb5.conf >>>> >>>> >>>> === *Description* ============================================================ >>>> Latest MIT krb5 supports a allow_weak_crypto key in krb5.conf, when set to true, disallows DES be used in all kinds of etypes. We can support it also. >>>> >>>> Currently, MIT krb5's default value for this key is false, but it might become true one day. >>>> >>>> >>>> >>>> >>> It's true in 1.8 now. >>> >>> >>> >>> >>>> *** (#1 of 1): 2009-05-26 03:50:36 GMT+00:00 weijun.wang at sun.com >>>> >>>> >>>> >>>> >>> >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100301/460269f5/attachment.html From Weijun.Wang at Sun.COM Mon Mar 1 17:03:04 2010 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 02 Mar 2010 09:03:04 +0800 Subject: [security-dev 01659]: Code review request: 6923681: Jarsigner crashes during timestamping In-Reply-To: <4B712BB6.9080202@sun.com> References: <23967760.1265706759090.JavaMail.sbladm@swsblss3-new> <4B712BB6.9080202@sun.com> Message-ID: <91FF634E-4AAC-471E-B0DB-631715922CE4@Sun.COM> Hi Vinnie Turns out it's not related to LDAP at all. Just a small coding error, already confirmed by customer. Please take a review: http://cr.openjdk.java.net/~weijun/6923681/webrev.00 Bug is: http://bugs.sun.com/view_bug.do?bug_id=6923681 No reg test. Trivial code update. Why hasn't Findbugs noticed it? Thanks Max On Feb 9, 2010, at 5:32 PM, Vincent Ryan wrote: > This is an interesting one Max. Our LDAP provider already supports LDAP server > discovery (ldap:///). Do you have the offending certificates? > > > On 09/02/2010 09:12, Weijun.Wang at Sun.COM wrote: >> >> *Change Request ID*: 6923681 >> >> *Synopsis*: Jarsigner crashes during timestamping >> >> === *Description* ============================================================ >> FULL PRODUCT VERSION : >> java version "1.6.0_18" >> Java(TM) SE Runtime Environment (build 1.6.0_18-b07) >> Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing) >> >> ADDITIONAL OS VERSION INFORMATION : >> Microsoft Windows XP [Version 5.1.2600] >> >> A DESCRIPTION OF THE PROBLEM : >> When timestamping a java-jar, the jarsigner crashes with a NullPointerexception. >> >> The issuing CA of the TSA-certificate has multiple revocation list distribution points. Two of the distribution points start with ldap and do not contain servernames >> >> URL=ldap:///CN=MY-CA,CN=AAAAAA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ad,DC=oenb,DC=co,DC=at?certificateRevocationList?base?objectClass=cRLDistributionPoint. >> >> We assume that the absence of the servername is the reason for jarsigner to crash with the null-pointer exception. >> >> This is the Windows default behaviour when creating certificates. >> >> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : >> Create a Microsoft Windows CA, which has ldap distribution points but no servernames listed. >> >> Issue a timestamping-certificate from this windows ca. Then try to timestamp some jar with this server. >> >> EXPECTED VERSUS ACTUAL BEHAVIOR : >> EXPECTED - >> jarsigner should handle the revocation list distribution points correctly. If at least one distribution point can be reached (like http://xxxx/xxx.crl, the jar should be timestamped correctly. >> ACTUAL - >> jarsigner crashes. >> >> ERROR MESSAGES/STACK TRACES THAT OCCUR : >> jarsigner error: java.lang.NullPointerException >> >> REPRODUCIBILITY : >> This bug can be reproduced always. >> >> ---------- BEGIN SOURCE ---------- >> n/a, just timestamp an arbitrary jar using jarsigned >> ---------- END SOURCE ---------- >> >> CUSTOMER SUBMITTED WORKAROUND : >> create an AD-CA that includes servernames in all revocation list distribution points >> >> *** (#1 of 1): 2010-02-05 09:31:33 GMT+00:00 nelson.dcosta at sun.com From Vincent.Ryan at Sun.COM Tue Mar 2 01:29:02 2010 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Tue, 02 Mar 2010 09:29:02 +0000 Subject: [security-dev 01660]: Re: Code review request: 6923681: Jarsigner crashes during timestamping In-Reply-To: <91FF634E-4AAC-471E-B0DB-631715922CE4@Sun.COM> References: <23967760.1265706759090.JavaMail.sbladm@swsblss3-new> <4B712BB6.9080202@sun.com> <91FF634E-4AAC-471E-B0DB-631715922CE4@Sun.COM> Message-ID: <4B8CDA5E.10109@sun.com> You fix looks good. Thanks. On 02/03/2010 01:03, Max (Weijun) Wang wrote: > Hi Vinnie > > Turns out it's not related to LDAP at all. Just a small coding error, already confirmed by customer. Please take a review: > > http://cr.openjdk.java.net/~weijun/6923681/webrev.00 > > Bug is: > > http://bugs.sun.com/view_bug.do?bug_id=6923681 > > No reg test. Trivial code update. > > Why hasn't Findbugs noticed it? > > Thanks > Max > > On Feb 9, 2010, at 5:32 PM, Vincent Ryan wrote: > >> This is an interesting one Max. Our LDAP provider already supports LDAP server >> discovery (ldap:///). Do you have the offending certificates? >> >> >> On 09/02/2010 09:12, Weijun.Wang at Sun.COM wrote: >>> >>> *Change Request ID*: 6923681 >>> >>> *Synopsis*: Jarsigner crashes during timestamping >>> >>> === *Description* ============================================================ >>> FULL PRODUCT VERSION : >>> java version "1.6.0_18" >>> Java(TM) SE Runtime Environment (build 1.6.0_18-b07) >>> Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing) >>> >>> ADDITIONAL OS VERSION INFORMATION : >>> Microsoft Windows XP [Version 5.1.2600] >>> >>> A DESCRIPTION OF THE PROBLEM : >>> When timestamping a java-jar, the jarsigner crashes with a NullPointerexception. >>> >>> The issuing CA of the TSA-certificate has multiple revocation list distribution points. Two of the distribution points start with ldap and do not contain servernames >>> >>> URL=ldap:///CN=MY-CA,CN=AAAAAA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ad,DC=oenb,DC=co,DC=at?certificateRevocationList?base?objectClass=cRLDistributionPoint. >>> >>> We assume that the absence of the servername is the reason for jarsigner to crash with the null-pointer exception. >>> >>> This is the Windows default behaviour when creating certificates. >>> >>> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : >>> Create a Microsoft Windows CA, which has ldap distribution points but no servernames listed. >>> >>> Issue a timestamping-certificate from this windows ca. Then try to timestamp some jar with this server. >>> >>> EXPECTED VERSUS ACTUAL BEHAVIOR : >>> EXPECTED - >>> jarsigner should handle the revocation list distribution points correctly. If at least one distribution point can be reached (like http://xxxx/xxx.crl, the jar should be timestamped correctly. >>> ACTUAL - >>> jarsigner crashes. >>> >>> ERROR MESSAGES/STACK TRACES THAT OCCUR : >>> jarsigner error: java.lang.NullPointerException >>> >>> REPRODUCIBILITY : >>> This bug can be reproduced always. >>> >>> ---------- BEGIN SOURCE ---------- >>> n/a, just timestamp an arbitrary jar using jarsigned >>> ---------- END SOURCE ---------- >>> >>> CUSTOMER SUBMITTED WORKAROUND : >>> create an AD-CA that includes servernames in all revocation list distribution points >>> >>> *** (#1 of 1): 2010-02-05 09:31:33 GMT+00:00 nelson.dcosta at sun.com > From joe.darcy at sun.com Tue Mar 2 13:57:06 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 02 Mar 2010 21:57:06 +0000 Subject: [security-dev 01661]: hg: jdk7/tl/langtools: 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Message-ID: <20100302215709.B65C341F86@hg.openjdk.java.net> Changeset: 7c23bbbe0dbd Author: darcy Date: 2010-03-02 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c23bbbe0dbd 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java From jonathan.gibbons at sun.com Tue Mar 2 16:41:43 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 03 Mar 2010 00:41:43 +0000 Subject: [security-dev 01662]: hg: jdk7/tl/langtools: 6931482: minor findbugs fixes Message-ID: <20100303004146.B692D41FB5@hg.openjdk.java.net> Changeset: 6e1e2738c530 Author: jjg Date: 2010-03-02 16:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e1e2738c530 6931482: minor findbugs fixes Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java From jonathan.gibbons at sun.com Tue Mar 2 16:44:42 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 03 Mar 2010 00:44:42 +0000 Subject: [security-dev 01663]: hg: jdk7/tl/langtools: 6931127: strange test class files Message-ID: <20100303004445.7B6E041FB6@hg.openjdk.java.net> Changeset: 235135d61974 Author: jjg Date: 2010-03-02 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/235135d61974 6931127: strange test class files Reviewed-by: darcy ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java From alan.bateman at sun.com Wed Mar 3 08:10:11 2010 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Wed, 03 Mar 2010 16:10:11 +0000 Subject: [security-dev 01664]: hg: jdk7/tl/jdk: 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Message-ID: <20100303161050.CC14143C39@hg.openjdk.java.net> Changeset: cddb43b12d28 Author: alanb Date: 2010-03-03 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cddb43b12d28 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Reviewed-by: chegar ! test/java/nio/file/WatchService/LotsOfEvents.java From kelly.ohair at sun.com Wed Mar 3 11:30:18 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 03 Mar 2010 19:30:18 +0000 Subject: [security-dev 01665]: hg: jdk7/tl/jdk: 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Message-ID: <20100303193038.0881343C6C@hg.openjdk.java.net> Changeset: 507159d8d143 Author: ohair Date: 2010-03-03 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/507159d8d143 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Reviewed-by: jjg ! make/common/shared/Sanity.gmk From joe.darcy at sun.com Wed Mar 3 16:05:47 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 04 Mar 2010 00:05:47 +0000 Subject: [security-dev 01666]: hg: jdk7/tl/langtools: 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Message-ID: <20100304000550.9A71443CAE@hg.openjdk.java.net> Changeset: fc7132746501 Author: darcy Date: 2010-03-03 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc7132746501 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/element/TestAnonClassNames.java + test/tools/javac/processing/model/element/TestAnonSourceNames.java From jonathan.gibbons at sun.com Wed Mar 3 17:23:54 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 04 Mar 2010 01:23:54 +0000 Subject: [security-dev 01667]: hg: jdk7/tl/langtools: 6931927: position issues with synthesized anonymous class Message-ID: <20100304012357.898BF43CC4@hg.openjdk.java.net> Changeset: 7f5db2e8b423 Author: jjg Date: 2010-03-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7f5db2e8b423 6931927: position issues with synthesized anonymous class Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/TestAnnotatedAnonClass.java + test/tools/javac/tree/TreePosTest.java - test/tools/javac/treepostests/TreePosTest.java From weijun.wang at sun.com Wed Mar 3 18:40:26 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 04 Mar 2010 02:40:26 +0000 Subject: [security-dev 01668]: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100304024122.AFDFC43CD7@hg.openjdk.java.net> Changeset: 61c298558549 Author: weijun Date: 2010-03-04 10:37 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61c298558549 6844909: support allow_weak_crypto in krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java + test/sun/security/krb5/etype/WeakCrypto.java + test/sun/security/krb5/etype/weakcrypto.conf Changeset: 0f383673ce31 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f383673ce31 6923681: Jarsigner crashes during timestamping Reviewed-by: vinnie ! src/share/classes/sun/security/tools/TimestampedSigner.java Changeset: 5e15b70e6d27 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e15b70e6d27 6880321: sun.security.provider.JavaKeyStore abuse of OOM Exception handling Reviewed-by: xuelei ! src/share/classes/sun/security/provider/JavaKeyStore.java From jonathan.gibbons at sun.com Wed Mar 3 19:35:50 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 04 Mar 2010 03:35:50 +0000 Subject: [security-dev 01669]: hg: jdk7/tl/langtools: 6931126: jtreg tests not Windows friendly Message-ID: <20100304033552.E838743CE5@hg.openjdk.java.net> Changeset: 117c95448ab9 Author: jjg Date: 2010-03-03 19:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/117c95448ab9 6931126: jtreg tests not Windows friendly Reviewed-by: darcy ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/generics/NameOrder.java From lana.steuck at sun.com Thu Mar 4 22:46:13 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:46:13 +0000 Subject: [security-dev 01670]: hg: jdk7/tl: Added tag jdk7-b84 for changeset 2f3ea057d1ad Message-ID: <20100305064613.4D93E43E6F@hg.openjdk.java.net> Changeset: cf26288a114b Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cf26288a114b Added tag jdk7-b84 for changeset 2f3ea057d1ad ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:46:19 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:46:19 +0000 Subject: [security-dev 01671]: hg: jdk7/tl/corba: Added tag jdk7-b84 for changeset 68c8961a82e4 Message-ID: <20100305064620.B3DA043E70@hg.openjdk.java.net> Changeset: c67a9df7bc0c Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c67a9df7bc0c Added tag jdk7-b84 for changeset 68c8961a82e4 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:48:40 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:48:40 +0000 Subject: [security-dev 01672]: hg: jdk7/tl/hotspot: 27 new changesets Message-ID: <20100305065004.1989143E71@hg.openjdk.java.net> Changeset: 125eb6a9fccf Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/125eb6a9fccf Added tag jdk7-b84 for changeset ffc8d176b84b ! .hgtags Changeset: 745c853ee57f Author: johnc Date: 2010-01-29 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/745c853ee57f 6885297: java -XX:RefDiscoveryPolicy=2 or -XX:TLABWasteTargetPercent=0 cause VM crash Summary: Interval checking is now being performed on the values passed in for these two flags. The current acceptable range for RefDiscoveryPolicy is [0..1], and for TLABWasteTargetPercent it is [1..100]. Reviewed-by: apetrusenko, ysr ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 6484c4ee11cb Author: ysr Date: 2010-02-01 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6484c4ee11cb 6904516: More object array barrier fixes, following up on 6906727 Summary: Fixed missing pre-barrier calls for G1, modified C1 to call pre- and correct post-barrier interfaces, deleted obsolete interface, (temporarily) disabled redundant deferred barrier in BacktraceBuilder. Reviewed-by: coleenp, jmasa, kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/runtime/stubRoutines.cpp Changeset: deada8912c54 Author: johnc Date: 2010-02-02 18:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/deada8912c54 6914402: G1: assert(!is_young_card(cached_ptr),"shouldn't get a card in young region") Summary: Invalid assert. Filter cards evicted from the card count cache instead. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 230fac611b50 Author: johnc Date: 2010-02-08 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/230fac611b50 Merge ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_core Changeset: 455df1b81409 Author: kamg Date: 2010-02-08 13:49 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/455df1b81409 6587322: dtrace probe object__alloc doesn't fire in some situations on amd64 Summary: Fix misplaced probe point Reviewed-by: rasbold, phh Contributed-by: neojia at gmail.com ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 95d21201c29a Author: apangin Date: 2010-02-11 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/95d21201c29a Merge Changeset: 3f5b7efb9642 Author: never Date: 2010-02-05 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f5b7efb9642 6920293: OptimizeStringConcat causing core dumps Reviewed-by: kvn, twisti ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 576e77447e3c Author: kvn Date: 2010-02-07 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/576e77447e3c 6923002: assert(false,"this call site should not be polymorphic") Summary: Clear the total count when a receiver information is cleared. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f516d5d7a019 Author: kvn Date: 2010-02-08 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f516d5d7a019 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Summary: Set the reexecute bit for runtime calls _new_array_Java when they used for _multianewarray bytecode. Reviewed-by: never ! src/share/vm/code/pcDesc.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/6910605/Test.java Changeset: f70b0d9ab095 Author: kvn Date: 2010-02-09 01:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f70b0d9ab095 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Summary: Mark in PcDesc call sites which return oop and save the result oop across objects reallocation during deoptimization. Reviewed-by: never ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/includeDB_core ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/deoptimization.cpp + test/compiler/6910618/Test.java Changeset: 4ee1c645110e Author: kvn Date: 2010-02-09 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4ee1c645110e 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Summary: Use PhiNode::make_blank(r, n) method to construct the phi. Reviewed-by: never ! src/share/vm/opto/loopopts.cpp Changeset: e3a4305c6bc3 Author: kvn Date: 2010-02-12 08:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e3a4305c6bc3 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Summary: Fix assert since top deoptimized frame has last_sp == interpreter_frame_monitor_begin if there are no expressions. Reviewed-by: twisti ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: c09ee209b65c Author: kvn Date: 2010-02-12 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c09ee209b65c 6926048: Improve Zero performance Summary: Make Zero figure out result types in a similar way to C++ interpreter implementation. Reviewed-by: kvn Contributed-by: gbenson at redhat.com ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp Changeset: 7b4415a18c8a Author: kvn Date: 2010-02-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7b4415a18c8a Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 38836cf1d8d2 Author: tonyp Date: 2010-02-05 11:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38836cf1d8d2 6920977: G1: guarantee(k == probe->klass(),"klass should be in dictionary") fails Summary: the guarantee is too strict and the test will fail (incorrectly) if the class is not in the system dictionary but in the placeholders. Reviewed-by: acorn, phh ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/includeDB_core Changeset: 9eee977dd1a9 Author: tonyp Date: 2010-02-08 14:23 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eee977dd1a9 6802453: G1: hr()->is_in_reserved(from),"Precondition." Summary: The operations of re-using a RSet component and expanding the same RSet component were not mutually exlusive, and this could lead to RSets getting corrupted and entries being dropped. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 8859772195c6 Author: johnc Date: 2010-02-09 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8859772195c6 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate. Summary: Update and display the timers associated with these flags for all safepoints. Reviewed-by: ysr, jcoomes ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/runtimeService.cpp Changeset: 0414c1049f15 Author: iveresov Date: 2010-02-11 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0414c1049f15 6923991: G1: improve scalability of RSet scanning Summary: Implemented block-based work stealing. Moved copying during the rset scanning phase to the main copying phase. Made the size of rset table depend on the region size. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 58add740c4ee Author: johnc Date: 2010-02-16 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/58add740c4ee Merge ! src/share/vm/includeDB_core Changeset: e7b1cc79bd25 Author: kvn Date: 2010-02-16 16:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7b1cc79bd25 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Summary: Define AdapterHandlerTableIterator class as non product instead of debug. Reviewed-by: never ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 106f41e88c85 Author: never Date: 2010-02-16 20:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/106f41e88c85 6877221: Endless deoptimizations in OSR nmethod Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: b4b440360f1e Author: twisti Date: 2010-02-18 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b4b440360f1e 6926782: CodeBuffer size too small after 6921352 Summary: After 6921352 the CodeBuffer size was too small. Reviewed-by: kvn, never ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: 3b687c53c266 Author: twisti Date: 2010-02-18 06:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3b687c53c266 6927165: Zero S/390 fixes Summary: Fixes two failures on 31-bit S/390. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp Changeset: 72f1840531a4 Author: twisti Date: 2010-02-18 10:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72f1840531a4 Merge Changeset: 1f341bb67b5b Author: trims Date: 2010-02-18 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f341bb67b5b Merge Changeset: 6c9796468b91 Author: trims Date: 2010-02-18 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c9796468b91 6927886: Bump the HS17 build number to 10 Summary: Update the HS17 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version From lana.steuck at sun.com Thu Mar 4 22:53:59 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:53:59 +0000 Subject: [security-dev 01673]: hg: jdk7/tl/jaxp: Added tag jdk7-b84 for changeset 32c0cf01d555 Message-ID: <20100305065359.9313F43E73@hg.openjdk.java.net> Changeset: 6c0ccabb430d Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/6c0ccabb430d Added tag jdk7-b84 for changeset 32c0cf01d555 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:54:06 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:54:06 +0000 Subject: [security-dev 01674]: hg: jdk7/tl/jaxws: Added tag jdk7-b84 for changeset 8bc02839eee4 Message-ID: <20100305065406.7BDCD43E74@hg.openjdk.java.net> Changeset: 8424512588ff Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8424512588ff Added tag jdk7-b84 for changeset 8bc02839eee4 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:54:39 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:54:39 +0000 Subject: [security-dev 01675]: hg: jdk7/tl/jdk: 5 new changesets Message-ID: <20100305065612.5781943E77@hg.openjdk.java.net> Changeset: a9b4fde406d4 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a9b4fde406d4 Added tag jdk7-b84 for changeset 7cb9388bb1a1 ! .hgtags Changeset: 2ba381560071 Author: dcherepanov Date: 2010-02-12 19:58 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ba381560071 6705345: Enable multiple file selection in AWT FileDialog Reviewed-by: art, anthony, alexp ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h + test/java/awt/FileDialog/MultipleMode/MultipleMode.html + test/java/awt/FileDialog/MultipleMode/MultipleMode.java Changeset: d6d2de6ee2d1 Author: lana Date: 2010-02-19 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6d2de6ee2d1 Merge Changeset: b396584a3e64 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b396584a3e64 Merge - make/java/text/FILES_java.gmk Changeset: c2d29e5695c2 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2d29e5695c2 Merge From lana.steuck at sun.com Thu Mar 4 23:03:30 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 07:03:30 +0000 Subject: [security-dev 01676]: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100305070338.B02E543E79@hg.openjdk.java.net> Changeset: 75d5bd12eb86 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/75d5bd12eb86 Added tag jdk7-b84 for changeset d9cd5b8286e4 ! .hgtags Changeset: 136bfc679462 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/136bfc679462 Merge Changeset: c55733ceed61 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c55733ceed61 Merge From jonathan.gibbons at sun.com Fri Mar 5 16:14:47 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Sat, 06 Mar 2010 00:14:47 +0000 Subject: [security-dev 01677]: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100306001501.DFE7143F6E@hg.openjdk.java.net> Changeset: a23282f17d0b Author: jjg Date: 2010-03-05 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a23282f17d0b 6930108: IllegalArgumentException in AbstractDiagnosticFormatter for tools/javac/api/TestJavacTaskScanner.jav Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/api/TestResolveError.java Changeset: a4f3b97c8028 Author: jjg Date: 2010-03-05 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a4f3b97c8028 Merge From kelly.ohair at sun.com Sat Mar 6 15:00:11 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Mar 2010 23:00:11 +0000 Subject: [security-dev 01678]: hg: jdk7/tl/jdk: 6915983: testing problems, adjusting list of tests, needs some investigation Message-ID: <20100306230106.5B8CA440AE@hg.openjdk.java.net> Changeset: 58b44ac0b10d Author: ohair Date: 2010-03-06 14:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58b44ac0b10d 6915983: testing problems, adjusting list of tests, needs some investigation Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt From kelly.ohair at sun.com Sat Mar 6 15:01:34 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Mar 2010 23:01:34 +0000 Subject: [security-dev 01679]: hg: jdk7/tl: 2 new changesets Message-ID: <20100306230134.7DB32440AF@hg.openjdk.java.net> Changeset: 4d7419e4b759 Author: ohair Date: 2010-03-06 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4d7419e4b759 6928700: Configure top repo for JPRT testing Reviewed-by: alanb, jjg ! make/jprt.properties + test/Makefile Changeset: f3664d6879ab Author: ohair Date: 2010-03-06 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f3664d6879ab Merge From christopher.hegarty at sun.com Wed Mar 10 06:47:32 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 10 Mar 2010 14:47:32 +0000 Subject: [security-dev 01680]: hg: jdk7/tl/jdk: 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Message-ID: <20100310144817.62C2D445BC@hg.openjdk.java.net> Changeset: 47958f76babc Author: chegar Date: 2010-03-10 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47958f76babc 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Reviewed-by: alanb ! test/java/net/MulticastSocket/NoLoopbackPackets.java From martinrb at google.com Wed Mar 10 15:14:43 2010 From: martinrb at google.com (martinrb at google.com) Date: Wed, 10 Mar 2010 23:14:43 +0000 Subject: [security-dev 01681]: hg: jdk7/tl/jdk: 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Message-ID: <20100310231507.8C5B944633@hg.openjdk.java.net> Changeset: 467484e025d6 Author: martin Date: 2010-03-10 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/467484e025d6 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Summary: uc >> 16 == 0 is superior to (int) (char) uc == uc Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/sun/nio/cs/Surrogate.java From jonathan.gibbons at sun.com Wed Mar 10 16:24:36 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 11 Mar 2010 00:24:36 +0000 Subject: [security-dev 01682]: hg: jdk7/tl/langtools: 6933914: fix missing newlines Message-ID: <20100311002440.1FD1244644@hg.openjdk.java.net> Changeset: 9871ce4fd56f Author: jjg Date: 2010-03-10 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9871ce4fd56f 6933914: fix missing newlines Reviewed-by: ohair ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/api/6731573/Erroneous.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/varargs/T6746184.java - test/tools/javap/T6305779.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java From christopher.hegarty at sun.com Thu Mar 11 08:20:14 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 16:20:14 +0000 Subject: [security-dev 01683]: hg: jdk7/tl/jdk: 6934054: java/net/Socket/FDClose.java return error in samevm Message-ID: <20100311162054.0273244735@hg.openjdk.java.net> Changeset: 07e1c5a90c6a Author: chegar Date: 2010-03-11 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07e1c5a90c6a 6934054: java/net/Socket/FDClose.java return error in samevm Summary: test is no longer useful Reviewed-by: alanb ! test/ProblemList.txt - test/java/net/Socket/FDClose.java From christopher.hegarty at sun.com Thu Mar 11 09:39:36 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 17:39:36 +0000 Subject: [security-dev 01684]: hg: jdk7/tl/jdk: 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Message-ID: <20100311173955.C60B444747@hg.openjdk.java.net> Changeset: c342735a3e58 Author: chegar Date: 2010-03-11 17:37 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c342735a3e58 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieHandlerTest.java From christopher.hegarty at sun.com Thu Mar 11 09:51:09 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 17:51:09 +0000 Subject: [security-dev 01685]: hg: jdk7/tl/jdk: 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Message-ID: <20100311175127.DA7B84474C@hg.openjdk.java.net> Changeset: c6f8c58ed51a Author: chegar Date: 2010-03-11 17:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f8c58ed51a 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Reviewed-by: michaelm, chegar Contributed-by: damjan.jov at gmail.com ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java + test/java/net/Socket/SocksConnectTimeout.java From xueming.shen at sun.com Thu Mar 11 14:13:54 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 11 Mar 2010 22:13:54 +0000 Subject: [security-dev 01686]: hg: jdk7/tl/jdk: 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Message-ID: <20100311221413.1ACC14478B@hg.openjdk.java.net> Changeset: ee385b4e2ffb Author: sherman Date: 2010-03-11 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee385b4e2ffb 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Summary: system property sun.zip.disableMemoryMapping to disable mmap use Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h From jonathan.gibbons at sun.com Fri Mar 12 12:01:35 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 12 Mar 2010 20:01:35 +0000 Subject: [security-dev 01687]: hg: jdk7/tl/langtools: 6934224: update langtools/test/Makefile Message-ID: <20100312200137.D4E54448C3@hg.openjdk.java.net> Changeset: f856c0942c06 Author: jjg Date: 2010-03-12 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f856c0942c06 6934224: update langtools/test/Makefile Reviewed-by: ohair ! make/jprt.properties ! test/Makefile From kelly.ohair at sun.com Fri Mar 12 12:15:43 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 12 Mar 2010 20:15:43 +0000 Subject: [security-dev 01688]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100312201621.2443B448C8@hg.openjdk.java.net> Changeset: bf6eb240e718 Author: ohair Date: 2010-03-12 09:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf6eb240e718 6933294: Fix some test/Makefile issues around Linux ARCH settings, better defaults Reviewed-by: jjg ! test/Makefile ! test/ProblemList.txt Changeset: cda90ceb7176 Author: ohair Date: 2010-03-12 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cda90ceb7176 Merge ! test/ProblemList.txt From jonathan.gibbons at sun.com Fri Mar 12 15:25:00 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 12 Mar 2010 23:25:00 +0000 Subject: [security-dev 01689]: hg: jdk7/tl: 6934712: run langtools jtreg tests from top level test/Makefile Message-ID: <20100312232500.DB883448F5@hg.openjdk.java.net> Changeset: bbd817429100 Author: jjg Date: 2010-03-12 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/bbd817429100 6934712: run langtools jtreg tests from top level test/Makefile Reviewed-by: ohair ! test/Makefile From kelly.ohair at sun.com Fri Mar 12 17:47:22 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 13 Mar 2010 01:47:22 +0000 Subject: [security-dev 01690]: hg: jdk7/tl: 6934759: Add langtools testing to jprt control builds Message-ID: <20100313014722.B3FF544918@hg.openjdk.java.net> Changeset: c60ed0f6d91a Author: ohair Date: 2010-03-12 17:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/c60ed0f6d91a 6934759: Add langtools testing to jprt control builds Reviewed-by: jjg ! make/jprt.properties From christopher.hegarty at sun.com Tue Mar 16 03:06:44 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 16 Mar 2010 10:06:44 +0000 Subject: [security-dev 01691]: hg: jdk7/tl/jdk: 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Message-ID: <20100316100704.71B7644D83@hg.openjdk.java.net> Changeset: f88f6f8ddd21 Author: chegar Date: 2010-03-16 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f88f6f8ddd21 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Reviewed-by: alanb ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java From christopher.hegarty at sun.com Tue Mar 16 07:34:19 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 16 Mar 2010 14:34:19 +0000 Subject: [security-dev 01692]: hg: jdk7/tl/jdk: 6935199: java/net regression tests failing with Assertions Message-ID: <20100316143439.1BD6244DC5@hg.openjdk.java.net> Changeset: 895a1211b2e1 Author: chegar Date: 2010-03-16 14:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/895a1211b2e1 6935199: java/net regression tests failing with Assertions Reviewed-by: michaelm ! test/ProblemList.txt ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/URLClassLoader/closetest/CloseTest.java From weijun.wang at sun.com Tue Mar 16 18:55:37 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Wed, 17 Mar 2010 01:55:37 +0000 Subject: [security-dev 01693]: hg: jdk7/tl/jdk: 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Message-ID: <20100317015556.BC14844E6E@hg.openjdk.java.net> Changeset: 0500f7306cbe Author: weijun Date: 2010-03-17 09:55 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0500f7306cbe 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Reviewed-by: wetmore ! test/sun/security/tools/jarsigner/oldsig.sh From weijun.wang at sun.com Thu Mar 18 03:27:35 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 18 Mar 2010 10:27:35 +0000 Subject: [security-dev 01694]: hg: jdk7/tl/jdk: 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Message-ID: <20100318102854.BFEB644088@hg.openjdk.java.net> Changeset: 2796f839e337 Author: weijun Date: 2010-03-18 18:26 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2796f839e337 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java From Christopher.Hegarty at Sun.COM Thu Mar 18 07:28:26 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 14:28:26 +0000 Subject: [security-dev 01695]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA2311B.1090300@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> Message-ID: <4BA2388A.9020502@sun.com> Alan Bateman wrote: > Pavel Tisnovsky wrote: >> Hi, >> >> please review new regression test for java.net.* API. This test check >> if the cacerts keytool database is configured properly and SSL is >> really working. The test should not fail if SSL is working (in other >> case it simply throws IOException). Webrev si available at >> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >> >> Thanks in advance >> Pavel Tisnovsky > I suspect the dependency on verisign.com will be problematic. Isn't SSL > already covered by the javax.net and https tests? I'm not sure what the prime motivation of the test is. Pavel, can you please elaborate? Reading between the lines I guess the test is verifying that the correct root Certification Authority is installed in cacerts, i.e. the cert from www.verisign.com can be validated. Alan is correct there are already tests for SSL/Https in javax.net, but I believe these use self signed certs, no dependency on cacerts. -Chris. > > -Alan. From ahughes at redhat.com Thu Mar 18 07:39:51 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 14:39:51 +0000 Subject: [security-dev 01696]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA2388A.9020502@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> Message-ID: <17c6771e1003180739v1a40dd52nabb67a46b8fdecbb@mail.gmail.com> On 18 March 2010 14:28, Christopher Hegarty -Sun Microsystems Ireland wrote: > Alan Bateman wrote: >> >> Pavel Tisnovsky wrote: >>> >>> Hi, >>> >>> please review new regression test for java.net.* API. This test check if >>> the cacerts keytool database is configured properly and SSL is really >>> working. The test should not fail if SSL is working (in other case it simply >>> throws IOException). Webrev si available at >>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>> >>> Thanks in advance >>> Pavel Tisnovsky >> >> I suspect the dependency on verisign.com will be problematic. ?Isn't SSL >> already covered by the javax.net and https tests? > > I'm not sure what the prime motivation of the test is. Pavel, can you please > elaborate? > > Reading between the lines I guess the test is verifying that the correct > ?root Certification Authority is installed in cacerts, i.e. the cert from > www.verisign.com can be validated. > > Alan is correct there are already tests for SSL/Https in javax.net, but I > believe these use self signed certs, no dependency on cacerts. > Sounds like you have things spot on to me, Chris. > -Chris. > >> >> -Alan. > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Alan.Bateman at Sun.COM Thu Mar 18 07:48:44 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 18 Mar 2010 14:48:44 +0000 Subject: [security-dev 01697]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA2388A.9020502@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> Message-ID: <4BA23D4C.3020500@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > : > > Alan is correct there are already tests for SSL/Https in javax.net, > but I believe these use self signed certs, no dependency on cacerts. OK, in that case adding a new test make sense. The test/java/net tree is probably not the best place though - maybe test/javax/net/ssl? I'm sure there will be suggestions on security-dev on the best way to exercise/test it. -Alan. From ptisnovs at redhat.com Thu Mar 18 08:50:05 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Thu, 18 Mar 2010 16:50:05 +0100 Subject: [security-dev 01698]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA2388A.9020502@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> Message-ID: <4BA24BAD.9020206@redhat.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Alan Bateman wrote: >> Pavel Tisnovsky wrote: >>> Hi, >>> >>> please review new regression test for java.net.* API. This test check >>> if the cacerts keytool database is configured properly and SSL is >>> really working. The test should not fail if SSL is working (in other >>> case it simply throws IOException). Webrev si available at >>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>> >>> Thanks in advance >>> Pavel Tisnovsky >> I suspect the dependency on verisign.com will be problematic. Isn't >> SSL already covered by the javax.net and https tests? > > I'm not sure what the prime motivation of the test is. Pavel, can you > please elaborate? > > Reading between the lines I guess the test is verifying that the correct > root Certification Authority is installed in cacerts, i.e. the cert > from www.verisign.com can be validated. Hi Chris, you guessed correctly :-) And we can use other URL if verisign.com is problematic. > > Alan is correct there are already tests for SSL/Https in javax.net, but > I believe these use self signed certs, no dependency on cacerts. > > -Chris. > >> >> -Alan. From Christopher.Hegarty at Sun.COM Thu Mar 18 07:57:07 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 14:57:07 +0000 Subject: [security-dev 01699]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA24BAD.9020206@redhat.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> Message-ID: <4BA23F43.70203@sun.com> Pavel Tisnovsky wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> Alan Bateman wrote: >>> Pavel Tisnovsky wrote: >>>> Hi, >>>> >>>> please review new regression test for java.net.* API. This test >>>> check if the cacerts keytool database is configured properly and SSL >>>> is really working. The test should not fail if SSL is working (in >>>> other case it simply throws IOException). Webrev si available at >>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>> >>>> Thanks in advance >>>> Pavel Tisnovsky >>> I suspect the dependency on verisign.com will be problematic. Isn't >>> SSL already covered by the javax.net and https tests? >> >> I'm not sure what the prime motivation of the test is. Pavel, can you >> please elaborate? >> >> Reading between the lines I guess the test is verifying that the >> correct root Certification Authority is installed in cacerts, i.e. >> the cert from www.verisign.com can be validated. > > Hi Chris, you guessed correctly :-) And we can use other URL if > verisign.com is problematic. OK, so the test is trying to validate cacerts. Does it make sense to validate this certificate store in a general purpose regression test? The test will of course pass with Sun's priority build and probably RedHats too, since they contain the root certificate for verisign, but an OpenJDK build will not contain it, right? So the test will fail. Security folk: Do we currently have any tests with a dependency on cacerts? -Chris. > >> >> Alan is correct there are already tests for SSL/Https in javax.net, >> but I believe these use self signed certs, no dependency on cacerts. >> >> -Chris. >> >>> >>> -Alan. > From Sean.Mullan at Sun.COM Thu Mar 18 07:59:56 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Thu, 18 Mar 2010 10:59:56 -0400 Subject: [security-dev 01700]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA23D4C.3020500@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA23D4C.3020500@sun.com> Message-ID: <4BA23FEC.2020409@sun.com> Alan Bateman wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> : >> >> Alan is correct there are already tests for SSL/Https in javax.net, >> but I believe these use self signed certs, no dependency on cacerts. > OK, in that case adding a new test make sense. The test/java/net tree is > probably not the best place though - maybe test/javax/net/ssl? I'm sure > there will be suggestions on security-dev on the best way to > exercise/test it. The dependency on cacerts is definitely an issue. The cacerts file is empty in JDK 7. --Sean From Sean.Mullan at Sun.COM Thu Mar 18 08:00:55 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Thu, 18 Mar 2010 11:00:55 -0400 Subject: [security-dev 01701]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA23F43.70203@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> Message-ID: <4BA24027.2050700@sun.com> Christopher Hegarty -Sun Microsystems Ireland wrote: > Pavel Tisnovsky wrote: >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> Alan Bateman wrote: >>>> Pavel Tisnovsky wrote: >>>>> Hi, >>>>> >>>>> please review new regression test for java.net.* API. This test >>>>> check if the cacerts keytool database is configured properly and >>>>> SSL is really working. The test should not fail if SSL is working >>>>> (in other case it simply throws IOException). Webrev si available >>>>> at http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>> >>>>> Thanks in advance >>>>> Pavel Tisnovsky >>>> I suspect the dependency on verisign.com will be problematic. Isn't >>>> SSL already covered by the javax.net and https tests? >>> >>> I'm not sure what the prime motivation of the test is. Pavel, can you >>> please elaborate? >>> >>> Reading between the lines I guess the test is verifying that the >>> correct root Certification Authority is installed in cacerts, i.e. >>> the cert from www.verisign.com can be validated. >> >> Hi Chris, you guessed correctly :-) And we can use other URL if >> verisign.com is problematic. > > OK, so the test is trying to validate cacerts. > > Does it make sense to validate this certificate store in a general > purpose regression test? The test will of course pass with Sun's > priority build and probably RedHats too, since they contain the root > certificate for verisign, but an OpenJDK build will not contain it, > right? So the test will fail. > > Security folk: > Do we currently have any tests with a dependency on cacerts? yes, but they would be in the closed tests. --Sean From ahughes at redhat.com Thu Mar 18 08:04:40 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 15:04:40 +0000 Subject: [security-dev 01702]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA23F43.70203@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> Message-ID: <17c6771e1003180804q532d147djd19839f03f616d0c@mail.gmail.com> On 18 March 2010 14:57, Christopher Hegarty -Sun Microsystems Ireland wrote: > Pavel Tisnovsky wrote: >> >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> >>> Alan Bateman wrote: >>>> >>>> Pavel Tisnovsky wrote: >>>>> >>>>> Hi, >>>>> >>>>> please review new regression test for java.net.* API. This test check >>>>> if the cacerts keytool database is configured properly and SSL is really >>>>> working. The test should not fail if SSL is working (in other case it simply >>>>> throws IOException). Webrev si available at >>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>> >>>>> Thanks in advance >>>>> Pavel Tisnovsky >>>> >>>> I suspect the dependency on verisign.com will be problematic. ?Isn't SSL >>>> already covered by the javax.net and https tests? >>> >>> I'm not sure what the prime motivation of the test is. Pavel, can you >>> please elaborate? >>> >>> Reading between the lines I guess the test is verifying that the correct >>> ?root Certification Authority is installed in cacerts, i.e. the cert from >>> www.verisign.com can be validated. >> >> Hi Chris, you guessed correctly :-) And we can use other URL if >> verisign.com is problematic. > > OK, so the test is trying to validate cacerts. > > Does it make sense to validate this certificate store in a general purpose > regression test? The test will of course pass with Sun's priority build and > probably RedHats too, since they contain the root certificate for verisign, > but an OpenJDK build will not contain it, right? So the test will fail. > > Security folk: > ?Do we currently have any tests with a dependency on cacerts? > > -Chris. > > >> >>> >>> Alan is correct there are already tests for SSL/Https in javax.net, but I >>> believe these use self signed certs, no dependency on cacerts. >>> >>> -Chris. >>> >>>> >>>> -Alan. >> > Yes, it will fail. >From an OpenJDK build: $ /mnt/builder/jdk7/j2sdk-image/bin/java TestHttps Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty This has been posted about before; OpenJDK currently can't bootstrap itself because it doesn't have a working cacerts store (the JAXP URL uses https). I don't know how to solve this; we can certainly have the cacerts file populated on GNU/Linux systems, but I don't have a clue how you'd do it on Solaris or Windows. How do Sun populate it? Can that be shared? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 08:07:25 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 15:07:25 +0000 Subject: [security-dev 01703]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA24027.2050700@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <4BA24027.2050700@sun.com> Message-ID: <4BA241AD.7020709@sun.com> Sean Mullan wrote: > .... >> >> Security folk: >> Do we currently have any tests with a dependency on cacerts? > > yes, but they would be in the closed tests. So we have your own non public tests for this. Maybe RedHat should take a similar approach then. -Chris. > > --Sean From Sean.Mullan at Sun.COM Thu Mar 18 08:13:17 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Thu, 18 Mar 2010 11:13:17 -0400 Subject: [security-dev 01704]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003180804q532d147djd19839f03f616d0c@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <17c6771e1003180804q532d147djd19839f03f616d0c@mail.gmail.com> Message-ID: <4BA2430D.5020803@sun.com> Andrew John Hughes wrote: > This has been posted about before; OpenJDK currently can't bootstrap > itself because it doesn't have a working cacerts store (the JAXP URL > uses https). > > I don't know how to solve this; we can certainly have the cacerts file > populated on GNU/Linux systems, but I don't have a clue how you'd do > it on Solaris or Windows. How do Sun populate it? Can that be shared? No. The agreements we have with CAs to include root CA certificates are for our product releases only, we can't (at least not right now) include them in OpenJDK. I haven't been following this thread in great detail, but don't existing JSSE tests cover this? --Sean From ahughes at redhat.com Thu Mar 18 08:15:12 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 15:15:12 +0000 Subject: [security-dev 01705]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA241AD.7020709@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <4BA24027.2050700@sun.com> <4BA241AD.7020709@sun.com> Message-ID: <17c6771e1003180815y3ff466e6ncc10fbdf8812c005@mail.gmail.com> On 18 March 2010 15:07, Christopher Hegarty -Sun Microsystems Ireland wrote: > > > Sean Mullan wrote: >> >> .... >>> >>> Security folk: >>> ?Do we currently have any tests with a dependency on cacerts? >> >> yes, but they would be in the closed tests. > > So we have your own non public tests for this. Maybe RedHat should take a > similar approach then. > > -Chris. > >> >> --Sean > We don't really do 'non public' at Red Hat. The patch will be in IcedTea which is publicly available, but it would be better for upstream to remain as in sync with us as possible. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Mar 18 08:16:16 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 15:16:16 +0000 Subject: [security-dev 01706]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA2430D.5020803@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA23F43.70203@sun.com> <17c6771e1003180804q532d147djd19839f03f616d0c@mail.gmail.com> <4BA2430D.5020803@sun.com> Message-ID: <17c6771e1003180816lb18e3c0n4055051ee83caaf5@mail.gmail.com> On 18 March 2010 15:13, Sean Mullan wrote: > Andrew John Hughes wrote: > >> This has been posted about before; OpenJDK currently can't bootstrap >> itself because it doesn't have a working cacerts store (the JAXP URL >> uses https). >> >> I don't know how to solve this; we can certainly have the cacerts file >> populated on GNU/Linux systems, but I don't have a clue how you'd do >> it on Solaris or Windows. ?How do Sun populate it? Can that be shared? > > No. The agreements we have with CAs to include root CA certificates are for > our product releases only, we can't (at least not right now) include them in > OpenJDK. > So they don't just use system-installed ones? Ok. > I haven't been following this thread in great detail, but don't existing > JSSE tests cover this? > No, if they did we wouldn't need another test. > --Sean > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Bradford.Wetmore at Sun.COM Thu Mar 18 11:40:05 2010 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Thu, 18 Mar 2010 11:40:05 -0700 Subject: [security-dev 01707]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA24BAD.9020206@redhat.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> Message-ID: <4BA27385.9060200@sun.com> I have a couple important tasks to finish ASAP, so if there is more discussion, I'll have to jump in sometime next week, but wanted to add one thing before anything was done: Pavel wrote: > And we can use other URL if verisign.com is problematic. We've tried to limit the reliance on servers outside our control for the open tests and to be as self-contained as possible, tho I'm sure there are still some tests that do this anyway. IMHO, it's not exactly neighborly of OpenJDK to include tests that just bang on someone's server(s) for "testing", even if the volume isn't terribly high. I think we should check with the server's admin before we included such a test in the general repository. In the past we've also had transient network errors (servers or network down), so that was another reason to limit our external dependencies. But they still had to be investigated and took time. Brad On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: > Christopher Hegarty -Sun Microsystems Ireland wrote: >> Alan Bateman wrote: >>> Pavel Tisnovsky wrote: >>>> Hi, >>>> >>>> please review new regression test for java.net.* API. This test >>>> check if the cacerts keytool database is configured properly and SSL >>>> is really working. The test should not fail if SSL is working (in >>>> other case it simply throws IOException). Webrev si available at >>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>> >>>> Thanks in advance >>>> Pavel Tisnovsky >>> I suspect the dependency on verisign.com will be problematic. Isn't >>> SSL already covered by the javax.net and https tests? >> >> I'm not sure what the prime motivation of the test is. Pavel, can you >> please elaborate? >> >> Reading between the lines I guess the test is verifying that the >> correct root Certification Authority is installed in cacerts, i.e. >> the cert from www.verisign.com can be validated. > > Hi Chris, you guessed correctly :-) And we can use other URL if > verisign.com is problematic. > >> >> Alan is correct there are already tests for SSL/Https in javax.net, >> but I believe these use self signed certs, no dependency on cacerts. >> >> -Chris. >> >>> >>> -Alan. > From ahughes at redhat.com Thu Mar 18 11:45:45 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 18:45:45 +0000 Subject: [security-dev 01708]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA27385.9060200@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> Message-ID: <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> On 18 March 2010 18:40, Brad Wetmore wrote: > > I have a couple important tasks to finish ASAP, so if there is more > discussion, I'll have to jump in sometime next week, but wanted to add > one thing before anything was done: > > Pavel wrote: >> And we can use other URL if verisign.com is problematic. > > We've tried to limit the reliance on servers outside our control for the > open tests and to be as self-contained as possible, tho I'm sure there > are still some tests that do this anyway. ?IMHO, it's not exactly > neighborly of OpenJDK to include tests that just bang on someone's > server(s) for "testing", even if the volume isn't terribly high. ?I > think we should check with the server's admin before we included such a > test in the general repository. > > In the past we've also had transient network errors (servers or network > down), so that was another reason to limit our external dependencies. > But they still had to be investigated and took time. > https://jaxp.dev.java.net/files/documents/913/147490 seems an appropriate URL to hit. It's the very URL that causes the OpenJDK build to fail to bootstrap itself and I assume Oracle do control dev.java.net to some degree. > Brad > > > > > > > On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >> Christopher Hegarty -Sun Microsystems Ireland wrote: >>> Alan Bateman wrote: >>>> Pavel Tisnovsky wrote: >>>>> Hi, >>>>> >>>>> please review new regression test for java.net.* API. This test >>>>> check if the cacerts keytool database is configured properly and SSL >>>>> is really working. The test should not fail if SSL is working (in >>>>> other case it simply throws IOException). Webrev si available at >>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>> >>>>> Thanks in advance >>>>> Pavel Tisnovsky >>>> I suspect the dependency on verisign.com will be problematic. ?Isn't >>>> SSL already covered by the javax.net and https tests? >>> >>> I'm not sure what the prime motivation of the test is. Pavel, can you >>> please elaborate? >>> >>> Reading between the lines I guess the test is verifying that the >>> correct ?root Certification Authority is installed in cacerts, i.e. >>> the cert from www.verisign.com can be validated. >> >> Hi Chris, you guessed correctly :-) And we can use other URL if >> verisign.com is problematic. >> >>> >>> Alan is correct there are already tests for SSL/Https in javax.net, >>> but I believe these use self signed certs, no dependency on cacerts. >>> >>> -Chris. >>> >>>> >>>> -Alan. >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 13:56:37 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 20:56:37 +0000 Subject: [security-dev 01709]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> Message-ID: <4BA29385.7020600@sun.com> Brad, Pavel, Andrew, I'm also not comfortable with this test, but what bothers me more than the reliance on an external server is the reliance on cacerts. While cacerts (or equivalent) is not part of OpenJDK I don't think it makes sense adding a test to OpenJDK that has a reliance on it. For now I think is makes more sense to add a test like this to wherever in the build process cacerts (or equivalent) is added. -Chris Andrew John Hughes wrote: > On 18 March 2010 18:40, Brad Wetmore wrote: >> I have a couple important tasks to finish ASAP, so if there is more >> discussion, I'll have to jump in sometime next week, but wanted to add >> one thing before anything was done: >> >> Pavel wrote: >>> And we can use other URL if verisign.com is problematic. >> We've tried to limit the reliance on servers outside our control for the >> open tests and to be as self-contained as possible, tho I'm sure there >> are still some tests that do this anyway. IMHO, it's not exactly >> neighborly of OpenJDK to include tests that just bang on someone's >> server(s) for "testing", even if the volume isn't terribly high. I >> think we should check with the server's admin before we included such a >> test in the general repository. >> >> In the past we've also had transient network errors (servers or network >> down), so that was another reason to limit our external dependencies. >> But they still had to be investigated and took time. >> > > https://jaxp.dev.java.net/files/documents/913/147490 seems an > appropriate URL to hit. It's the very URL that causes the OpenJDK > build to fail to bootstrap itself and I assume Oracle do control > dev.java.net to some degree. > >> Brad >> >> >> >> >> >> >> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>> Alan Bateman wrote: >>>>> Pavel Tisnovsky wrote: >>>>>> Hi, >>>>>> >>>>>> please review new regression test for java.net.* API. This test >>>>>> check if the cacerts keytool database is configured properly and SSL >>>>>> is really working. The test should not fail if SSL is working (in >>>>>> other case it simply throws IOException). Webrev si available at >>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>> >>>>>> Thanks in advance >>>>>> Pavel Tisnovsky >>>>> I suspect the dependency on verisign.com will be problematic. Isn't >>>>> SSL already covered by the javax.net and https tests? >>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>> please elaborate? >>>> >>>> Reading between the lines I guess the test is verifying that the >>>> correct root Certification Authority is installed in cacerts, i.e. >>>> the cert from www.verisign.com can be validated. >>> Hi Chris, you guessed correctly :-) And we can use other URL if >>> verisign.com is problematic. >>> >>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>> but I believe these use self signed certs, no dependency on cacerts. >>>> >>>> -Chris. >>>> >>>>> -Alan. > > > From ahughes at redhat.com Thu Mar 18 14:08:56 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 21:08:56 +0000 Subject: [security-dev 01710]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA29385.7020600@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> Message-ID: <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland wrote: > Brad, Pavel, Andrew, > > I'm also not comfortable with this test, but what bothers me more than the > reliance on an external server is the reliance on cacerts. While cacerts (or > equivalent) is not part of OpenJDK I don't think it makes sense adding a > test to OpenJDK that has a reliance on it. > > For now I think is makes more sense to add a test like this to wherever in > the build process cacerts (or equivalent) is added. > The problem is nothing does in the OpenJDK build process. So SSL is always broken for OpenJDK builds. Is this something we really want? > -Chris > > Andrew John Hughes wrote: >> >> On 18 March 2010 18:40, Brad Wetmore wrote: >>> >>> I have a couple important tasks to finish ASAP, so if there is more >>> discussion, I'll have to jump in sometime next week, but wanted to add >>> one thing before anything was done: >>> >>> Pavel wrote: >>>> >>>> And we can use other URL if verisign.com is problematic. >>> >>> We've tried to limit the reliance on servers outside our control for the >>> open tests and to be as self-contained as possible, tho I'm sure there >>> are still some tests that do this anyway. ?IMHO, it's not exactly >>> neighborly of OpenJDK to include tests that just bang on someone's >>> server(s) for "testing", even if the volume isn't terribly high. ?I >>> think we should check with the server's admin before we included such a >>> test in the general repository. >>> >>> In the past we've also had transient network errors (servers or network >>> down), so that was another reason to limit our external dependencies. >>> But they still had to be investigated and took time. >>> >> >> https://jaxp.dev.java.net/files/documents/913/147490 seems an >> appropriate URL to hit. ?It's the very URL that causes the OpenJDK >> build to fail to bootstrap itself and I assume Oracle do control >> dev.java.net to some degree. >> >>> Brad >>> >>> >>> >>> >>> >>> >>> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>>> >>>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>>> >>>>> Alan Bateman wrote: >>>>>> >>>>>> Pavel Tisnovsky wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review new regression test for java.net.* API. This test >>>>>>> check if the cacerts keytool database is configured properly and SSL >>>>>>> is really working. The test should not fail if SSL is working (in >>>>>>> other case it simply throws IOException). Webrev si available at >>>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>>> >>>>>>> Thanks in advance >>>>>>> Pavel Tisnovsky >>>>>> >>>>>> I suspect the dependency on verisign.com will be problematic. ?Isn't >>>>>> SSL already covered by the javax.net and https tests? >>>>> >>>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>>> please elaborate? >>>>> >>>>> Reading between the lines I guess the test is verifying that the >>>>> correct ?root Certification Authority is installed in cacerts, i.e. >>>>> the cert from www.verisign.com can be validated. >>>> >>>> Hi Chris, you guessed correctly :-) And we can use other URL if >>>> verisign.com is problematic. >>>> >>>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>>> but I believe these use self signed certs, no dependency on cacerts. >>>>> >>>>> -Chris. >>>>> >>>>>> -Alan. >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Thu Mar 18 14:12:49 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 18 Mar 2010 21:12:49 +0000 Subject: [security-dev 01711]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> Message-ID: <4BA29751.2020104@sun.com> Andrew John Hughes wrote: > On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland > wrote: >> Brad, Pavel, Andrew, >> >> I'm also not comfortable with this test, but what bothers me more than the >> reliance on an external server is the reliance on cacerts. While cacerts (or >> equivalent) is not part of OpenJDK I don't think it makes sense adding a >> test to OpenJDK that has a reliance on it. >> >> For now I think is makes more sense to add a test like this to wherever in >> the build process cacerts (or equivalent) is added. >> > > The problem is nothing does in the OpenJDK build process. So SSL is > always broken for OpenJDK builds. Is this something we really want? This is certainly not ideal, but is a separate issue to the test, right? It seems Sean or someone in the security team should comment on the possibility of adding root CA's to OpenJDK, until then I don't see any requirement for a test. -Chris. > >> -Chris >> >> Andrew John Hughes wrote: >>> On 18 March 2010 18:40, Brad Wetmore wrote: >>>> I have a couple important tasks to finish ASAP, so if there is more >>>> discussion, I'll have to jump in sometime next week, but wanted to add >>>> one thing before anything was done: >>>> >>>> Pavel wrote: >>>>> And we can use other URL if verisign.com is problematic. >>>> We've tried to limit the reliance on servers outside our control for the >>>> open tests and to be as self-contained as possible, tho I'm sure there >>>> are still some tests that do this anyway. IMHO, it's not exactly >>>> neighborly of OpenJDK to include tests that just bang on someone's >>>> server(s) for "testing", even if the volume isn't terribly high. I >>>> think we should check with the server's admin before we included such a >>>> test in the general repository. >>>> >>>> In the past we've also had transient network errors (servers or network >>>> down), so that was another reason to limit our external dependencies. >>>> But they still had to be investigated and took time. >>>> >>> https://jaxp.dev.java.net/files/documents/913/147490 seems an >>> appropriate URL to hit. It's the very URL that causes the OpenJDK >>> build to fail to bootstrap itself and I assume Oracle do control >>> dev.java.net to some degree. >>> >>>> Brad >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>>>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>>>> Alan Bateman wrote: >>>>>>> Pavel Tisnovsky wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review new regression test for java.net.* API. This test >>>>>>>> check if the cacerts keytool database is configured properly and SSL >>>>>>>> is really working. The test should not fail if SSL is working (in >>>>>>>> other case it simply throws IOException). Webrev si available at >>>>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>>>> >>>>>>>> Thanks in advance >>>>>>>> Pavel Tisnovsky >>>>>>> I suspect the dependency on verisign.com will be problematic. Isn't >>>>>>> SSL already covered by the javax.net and https tests? >>>>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>>>> please elaborate? >>>>>> >>>>>> Reading between the lines I guess the test is verifying that the >>>>>> correct root Certification Authority is installed in cacerts, i.e. >>>>>> the cert from www.verisign.com can be validated. >>>>> Hi Chris, you guessed correctly :-) And we can use other URL if >>>>> verisign.com is problematic. >>>>> >>>>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>>>> but I believe these use self signed certs, no dependency on cacerts. >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> -Alan. >>> >>> > > > From ahughes at redhat.com Thu Mar 18 14:23:05 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 21:23:05 +0000 Subject: [security-dev 01712]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA29751.2020104@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> <4BA29751.2020104@sun.com> Message-ID: <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> On 18 March 2010 21:12, Christopher Hegarty -Sun Microsystems Ireland wrote: > Andrew John Hughes wrote: >> >> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland >> wrote: >>> >>> Brad, Pavel, Andrew, >>> >>> I'm also not comfortable with this test, but what bothers me more than >>> the >>> reliance on an external server is the reliance on cacerts. While cacerts >>> (or >>> equivalent) is not part of OpenJDK I don't think it makes sense adding a >>> test to OpenJDK that has a reliance on it. >>> >>> For now I think is makes more sense to add a test like this to wherever >>> in >>> the build process cacerts (or equivalent) is added. >>> >> >> The problem is nothing does in the OpenJDK build process. ?So SSL is >> always broken for OpenJDK builds. ?Is this something we really want? > > This is certainly not ideal, but is a separate issue to the test, right? It > seems Sean or someone in the security team should comment on the possibility > of adding root CA's to OpenJDK, until then I don't see any requirement for a > test. > My thoughts too. We have a solution for GNU/Linux where cacerts is populated from the crt files found on the system (installed by Mozilla and the like). I don't know what the equivalent would be for Windows and Solaris though. A quick look on my OpenSolaris box didn't find any crt files but I only looked in installed packages. I presume firefox may bring some in if it's available. > -Chris. > >> >>> -Chris >>> >>> Andrew John Hughes wrote: >>>> >>>> On 18 March 2010 18:40, Brad Wetmore wrote: >>>>> >>>>> I have a couple important tasks to finish ASAP, so if there is more >>>>> discussion, I'll have to jump in sometime next week, but wanted to add >>>>> one thing before anything was done: >>>>> >>>>> Pavel wrote: >>>>>> >>>>>> And we can use other URL if verisign.com is problematic. >>>>> >>>>> We've tried to limit the reliance on servers outside our control for >>>>> the >>>>> open tests and to be as self-contained as possible, tho I'm sure there >>>>> are still some tests that do this anyway. ?IMHO, it's not exactly >>>>> neighborly of OpenJDK to include tests that just bang on someone's >>>>> server(s) for "testing", even if the volume isn't terribly high. ?I >>>>> think we should check with the server's admin before we included such a >>>>> test in the general repository. >>>>> >>>>> In the past we've also had transient network errors (servers or network >>>>> down), so that was another reason to limit our external dependencies. >>>>> But they still had to be investigated and took time. >>>>> >>>> https://jaxp.dev.java.net/files/documents/913/147490 seems an >>>> appropriate URL to hit. ?It's the very URL that causes the OpenJDK >>>> build to fail to bootstrap itself and I assume Oracle do control >>>> dev.java.net to some degree. >>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote: >>>>>> >>>>>> Christopher Hegarty -Sun Microsystems Ireland wrote: >>>>>>> >>>>>>> Alan Bateman wrote: >>>>>>>> >>>>>>>> Pavel Tisnovsky wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review new regression test for java.net.* API. This test >>>>>>>>> check if the cacerts keytool database is configured properly and >>>>>>>>> SSL >>>>>>>>> is really working. The test should not fail if SSL is working (in >>>>>>>>> other case it simply throws IOException). Webrev si available at >>>>>>>>> http://cr.openjdk.java.net/~ptisnovs/TestHttps/ >>>>>>>>> >>>>>>>>> Thanks in advance >>>>>>>>> Pavel Tisnovsky >>>>>>>> >>>>>>>> I suspect the dependency on verisign.com will be problematic. ?Isn't >>>>>>>> SSL already covered by the javax.net and https tests? >>>>>>> >>>>>>> I'm not sure what the prime motivation of the test is. Pavel, can you >>>>>>> please elaborate? >>>>>>> >>>>>>> Reading between the lines I guess the test is verifying that the >>>>>>> correct ?root Certification Authority is installed in cacerts, i.e. >>>>>>> the cert from www.verisign.com can be validated. >>>>>> >>>>>> Hi Chris, you guessed correctly :-) And we can use other URL if >>>>>> verisign.com is problematic. >>>>>> >>>>>>> Alan is correct there are already tests for SSL/Https in javax.net, >>>>>>> but I believe these use self signed certs, no dependency on cacerts. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>>> -Alan. >>>> >>>> >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From yu-ching.peng at sun.com Thu Mar 18 18:08:20 2010 From: yu-ching.peng at sun.com (yu-ching.peng at sun.com) Date: Fri, 19 Mar 2010 01:08:20 +0000 Subject: [security-dev 01713]: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100319010953.BA4894417C@hg.openjdk.java.net> Changeset: c52f292a8f86 Author: valeriep Date: 2010-03-18 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c52f292a8f86 6695485: SignedObject constructor throws ProviderException if it's called using provider "SunPKCS11-Solaris" Summary: Added checking for RSA key lengths in initSign and initVerify Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Signature.java + test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: df5714cbe76d Author: valeriep Date: 2010-03-18 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df5714cbe76d 6591117: Poor preformance of PKCS#11 security provider compared to Sun default provider Summary: Added internal buffering to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java Changeset: dc42c9d9ca16 Author: valeriep Date: 2010-03-18 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc42c9d9ca16 6837847: PKCS#11 A SecureRandom and a serialization error following installation of 1.5.0_18 Summary: Added a custom readObject method to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java + test/sun/security/pkcs11/SecureRandom/TestDeserialization.java From Weijun.Wang at Sun.COM Thu Mar 18 19:03:29 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Fri, 19 Mar 2010 10:03:29 +0800 Subject: [security-dev 01714]: '\0' in alias name of a pkcs11 keystore Message-ID: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> Hi Valerie As described in http://forums.sun.com/thread.jspa?threadID=5432248, customer's pkcs11 keystore has aliases ended with '\0'. Is this something we should fix on the Java side? Thanks Max From lana.steuck at sun.com Thu Mar 18 22:17:04 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:17:04 +0000 Subject: [security-dev 01715]: hg: jdk7/tl: 3 new changesets Message-ID: <20100319051704.78292441C6@hg.openjdk.java.net> Changeset: 3ddf90b39176 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3ddf90b39176 Added tag jdk7-b85 for changeset cf26288a114b ! .hgtags Changeset: 433a60a9c0bf Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/433a60a9c0bf Merge Changeset: 98505d97a822 Author: lana Date: 2010-03-18 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/98505d97a822 Merge From lana.steuck at sun.com Thu Mar 18 22:17:11 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:17:11 +0000 Subject: [security-dev 01716]: hg: jdk7/tl/corba: Added tag jdk7-b85 for changeset c67a9df7bc0c Message-ID: <20100319051713.B7AF2441C7@hg.openjdk.java.net> Changeset: 6253e28826d1 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6253e28826d1 Added tag jdk7-b85 for changeset c67a9df7bc0c ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:19:23 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:19:23 +0000 Subject: [security-dev 01717]: hg: jdk7/tl/hotspot: 2 new changesets Message-ID: <20100319051931.87330441C8@hg.openjdk.java.net> Changeset: 418bc80ce139 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/418bc80ce139 Added tag jdk7-b85 for changeset 6c9796468b91 ! .hgtags Changeset: bf823ef06b4f Author: trims Date: 2010-03-08 15:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bf823ef06b4f Added tag hs17-b10 for changeset 418bc80ce139 ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:23:25 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:23:25 +0000 Subject: [security-dev 01718]: hg: jdk7/tl/jaxp: Added tag jdk7-b85 for changeset 6c0ccabb430d Message-ID: <20100319052325.DADBE441CA@hg.openjdk.java.net> Changeset: 81c0f115bbe5 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/81c0f115bbe5 Added tag jdk7-b85 for changeset 6c0ccabb430d ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:23:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:23:32 +0000 Subject: [security-dev 01719]: hg: jdk7/tl/jaxws: Added tag jdk7-b85 for changeset 8424512588ff Message-ID: <20100319052332.21C08441CB@hg.openjdk.java.net> Changeset: 512b0e924a5a Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/512b0e924a5a Added tag jdk7-b85 for changeset 8424512588ff ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:24:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:24:32 +0000 Subject: [security-dev 01720]: hg: jdk7/tl/jdk: 22 new changesets Message-ID: <20100319053136.DA606441CE@hg.openjdk.java.net> Changeset: 03cd9e62961f Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03cd9e62961f Added tag jdk7-b85 for changeset b396584a3e64 ! .hgtags Changeset: 840601ac5ab7 Author: rkennke Date: 2010-03-03 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/840601ac5ab7 6892485: Deadlock in SunGraphicsEnvironment / FontManager Summary: Synchronize on correct monitor in SunFontManager. Reviewed-by: igor, prr ! src/share/classes/sun/font/SunFontManager.java Changeset: 1d7db2d5c4c5 Author: minqi Date: 2010-03-08 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1d7db2d5c4c5 6918065: Crash in Java2D blit loop (IntArgbToIntArgbPreSrcOverMaskBlit) in 64bit mode Reviewed-by: igor, bae ! src/share/classes/java/awt/AlphaComposite.java + test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java Changeset: 494f5e4f24da Author: lana Date: 2010-03-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/494f5e4f24da Merge Changeset: e64331144648 Author: rupashka Date: 2010-02-10 15:15 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e64331144648 6848475: JSlider does not display the correct value of its BoundedRangeModel Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6848475/bug6848475.java Changeset: f81c8041ccf4 Author: peytoia Date: 2010-02-11 15:58 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f81c8041ccf4 6909002: Remove indicim.jar and thaiim.jar from JRE and move to samples if needed Reviewed-by: okutsu ! make/com/sun/Makefile Changeset: e2b58a45a426 Author: peytoia Date: 2010-02-12 14:38 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2b58a45a426 6921289: (tz) Support tzdata2010b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e8340332745e Author: malenkov Date: 2010-02-18 17:46 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8340332745e 4498236: RFE: Provide a toString method for PropertyChangeEvent and other classes Reviewed-by: peterz ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyChangeEvent.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test4498236.java Changeset: 5c03237838e1 Author: rupashka Date: 2010-02-27 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c03237838e1 6913758: Specification for SynthViewportUI.paintBorder(...) should mention that this method is never called Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 96205ed1b196 Author: rupashka Date: 2010-02-27 14:47 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/96205ed1b196 6918447: SynthToolBarUI.setBorderToXXXX() methods don't correspond inherited spec. They do nothing. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java Changeset: 621e921a14cd Author: rupashka Date: 2010-02-27 15:09 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/621e921a14cd 6918861: SynthSliderUI.uninstallDefaults() is not called when UI is uninstalled Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6918861/bug6918861.java Changeset: 28741de0bb4a Author: rupashka Date: 2010-02-27 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28741de0bb4a 6923305: SynthSliderUI paints the slider track when the slider's "paintTrack" property is set to false Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6923305/bug6923305.java Changeset: 2bf137beb9bd Author: rupashka Date: 2010-02-27 16:14 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2bf137beb9bd 6929298: The SynthSliderUI#calculateTickRect method should be removed Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java Changeset: d6b3a07c8752 Author: rupashka Date: 2010-03-03 17:57 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6b3a07c8752 6924059: SynthScrollBarUI.configureScrollBarColors() should have spec different from the overridden method Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/6924059/bug6924059.java Changeset: 30c520bd148f Author: rupashka Date: 2010-03-03 20:08 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/30c520bd148f 6913768: With default SynthLookAndFeel instance installed new JTable creation leads to throwing NPE Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java + test/javax/swing/JTable/6913768/bug6913768.java Changeset: f13fc955be62 Author: rupashka Date: 2010-03-03 20:53 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f13fc955be62 6917744: JScrollPane Page Up/Down keys do not handle correctly html tables with different cells contents Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/text/DefaultEditorKit.java + test/javax/swing/JEditorPane/6917744/bug6917744.java + test/javax/swing/JEditorPane/6917744/test.html Changeset: 0622086d82ac Author: malenkov Date: 2010-03-04 21:17 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0622086d82ac 6921644: XMLEncoder generates invalid XML Reviewed-by: peterz ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test5023550.java + test/java/beans/XMLEncoder/Test5023557.java + test/java/beans/XMLEncoder/Test6921644.java Changeset: 79a509ac8f35 Author: lana Date: 2010-03-01 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79a509ac8f35 Merge ! make/com/sun/Makefile - make/java/text/FILES_java.gmk Changeset: 90248595ec35 Author: lana Date: 2010-03-04 13:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90248595ec35 Merge Changeset: 2fe4e72288ce Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fe4e72288ce Merge Changeset: eae6e9ab2606 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eae6e9ab2606 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: dff4f51b73d4 Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dff4f51b73d4 Merge From lana.steuck at sun.com Thu Mar 18 22:37:45 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:37:45 +0000 Subject: [security-dev 01721]: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100319053756.31267441D1@hg.openjdk.java.net> Changeset: b816baf594e3 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b816baf594e3 Added tag jdk7-b85 for changeset 136bfc679462 ! .hgtags Changeset: ef07347428f2 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ef07347428f2 Merge - test/tools/javac/treepostests/TreePosTest.java Changeset: 6fad35d25b1e Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6fad35d25b1e Merge From christopher.hegarty at sun.com Fri Mar 19 06:27:27 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Fri, 19 Mar 2010 13:27:27 +0000 Subject: [security-dev 01722]: hg: jdk7/tl/jdk: 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Message-ID: <20100319132803.016AC44258@hg.openjdk.java.net> Changeset: 3bb93c410f41 Author: chegar Date: 2010-03-19 13:07 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3bb93c410f41 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java + test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh From kelly.ohair at sun.com Fri Mar 19 18:18:24 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 20 Mar 2010 01:18:24 +0000 Subject: [security-dev 01723]: hg: jdk7/tl: 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Message-ID: <20100320011825.0F4AE44311@hg.openjdk.java.net> Changeset: 35d272ef7598 Author: ohair Date: 2010-03-19 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/35d272ef7598 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Reviewed-by: jjg ! test/Makefile From christopher.hegarty at sun.com Mon Mar 22 05:00:30 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 22 Mar 2010 12:00:30 +0000 Subject: [security-dev 01724]: hg: jdk7/tl/jdk: 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Message-ID: <20100322120310.8BCBE4465E@hg.openjdk.java.net> Changeset: c40572afb29e Author: chegar Date: 2010-03-22 11:55 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c40572afb29e 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java From Sean.Mullan at Sun.COM Mon Mar 22 08:41:07 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Mon, 22 Mar 2010 11:41:07 -0400 Subject: [security-dev 01725]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2311B.1090300@sun.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> <4BA29751.2020104@sun.com> <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> Message-ID: <4BA78F93.4080507@sun.com> Andrew John Hughes wrote: > On 18 March 2010 21:12, Christopher Hegarty -Sun Microsystems Ireland > wrote: >> Andrew John Hughes wrote: >>> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland >>> wrote: >>>> Brad, Pavel, Andrew, >>>> >>>> I'm also not comfortable with this test, but what bothers me more than >>>> the >>>> reliance on an external server is the reliance on cacerts. While cacerts >>>> (or >>>> equivalent) is not part of OpenJDK I don't think it makes sense adding a >>>> test to OpenJDK that has a reliance on it. >>>> >>>> For now I think is makes more sense to add a test like this to wherever >>>> in >>>> the build process cacerts (or equivalent) is added. >>>> >>> The problem is nothing does in the OpenJDK build process. So SSL is >>> always broken for OpenJDK builds. Is this something we really want? >> This is certainly not ideal, but is a separate issue to the test, right? It >> seems Sean or someone in the security team should comment on the possibility >> of adding root CA's to OpenJDK, until then I don't see any requirement for a >> test. I don't have an answer right now - this will take some more investigation first. > My thoughts too. We have a solution for GNU/Linux where cacerts is > populated from the crt files found on the system (installed by Mozilla > and the like). I don't know what the equivalent would be for Windows > and Solaris though. A quick look on my OpenSolaris box didn't find > any crt files but I only looked in installed packages. I presume > firefox may bring some in if it's available. On Windows you can use the "Windows-ROOT" KeyStore type, ex: keytool -list -keystore NONE -storetype Windows-ROOT I haven't tried it, but you could probably use the keytool -importkeystore option to import all of these certs into the cacerts file. On Solaris, you could use the /usr/java/jre/lib/security/cacerts file. --Sean From Christopher.Hegarty at Sun.COM Mon Mar 22 09:01:31 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Mon, 22 Mar 2010 16:01:31 +0000 Subject: [security-dev 01726]: Code Review: 6614957, 6771432, 6766775 Message-ID: <4BA7945B.6070904@Sun.COM> Hi Andrew, Michael, This review is to forward port the following three bugs from 6uXX to JDK7: 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 The source changes are identical to what we have in JDK6uXX. The tests come from 6uXX verbatim with minimal changes (license header, com.sun.net.ssl.internal.ssl.SSLSocketImpl -> sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs together since they directly impact on each other. Please let me know if you require more information to be able to review. -Chris. From ahughes at redhat.com Mon Mar 22 09:01:38 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 22 Mar 2010 16:01:38 +0000 Subject: [security-dev 01727]: Re: Please review new regression test for java.net.* API In-Reply-To: <4BA78F93.4080507@sun.com> References: <4BA23AD9.4060906@redhat.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> <4BA29751.2020104@sun.com> <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> <4BA78F93.4080507@sun.com> Message-ID: <17c6771e1003220901q59b8a4a3pffb328a46615d8d6@mail.gmail.com> On 22 March 2010 15:41, Sean Mullan wrote: > Andrew John Hughes wrote: >> >> On 18 March 2010 21:12, Christopher Hegarty -Sun Microsystems Ireland >> wrote: >>> >>> Andrew John Hughes wrote: >>>> >>>> On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland >>>> wrote: >>>>> >>>>> Brad, Pavel, Andrew, >>>>> >>>>> I'm also not comfortable with this test, but what bothers me more than >>>>> the >>>>> reliance on an external server is the reliance on cacerts. While >>>>> cacerts >>>>> (or >>>>> equivalent) is not part of OpenJDK I don't think it makes sense adding >>>>> a >>>>> test to OpenJDK that has a reliance on it. >>>>> >>>>> For now I think is makes more sense to add a test like this to wherever >>>>> in >>>>> the build process cacerts (or equivalent) is added. >>>>> >>>> The problem is nothing does in the OpenJDK build process. ?So SSL is >>>> always broken for OpenJDK builds. ?Is this something we really want? >>> >>> This is certainly not ideal, but is a separate issue to the test, right? >>> It >>> seems Sean or someone in the security team should comment on the >>> possibility >>> of adding root CA's to OpenJDK, until then I don't see any requirement >>> for a >>> test. > > I don't have an answer right now - this will take some more investigation > first. > >> My thoughts too. ?We have a solution for GNU/Linux where cacerts is >> populated from the crt files found on the system (installed by Mozilla >> and the like). ?I don't know what the equivalent would be for Windows >> and Solaris though. ?A quick look on my OpenSolaris box didn't find >> any crt files but I only looked in installed packages. ?I presume >> firefox may bring some in if it's available. > > On Windows you can use the "Windows-ROOT" KeyStore type, ex: > > keytool -list -keystore NONE -storetype Windows-ROOT > Ok, so that presumably makes some Windows system call, right? > I haven't tried it, but you could probably use the keytool -importkeystore > option to import all of these certs into the cacerts file. > > On Solaris, you could use the /usr/java/jre/lib/security/cacerts file. > Isn't that exactly what's being installed? Though maybe there's a general solution there of importing from the bootstrap JDK. > > --Sean > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Sean.Mullan at Sun.COM Mon Mar 22 09:38:57 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Mon, 22 Mar 2010 12:38:57 -0400 Subject: [security-dev 01728]: Re: Please review new regression test for java.net.* API In-Reply-To: <17c6771e1003220901q59b8a4a3pffb328a46615d8d6@mail.gmail.com> References: <4BA23AD9.4060906@redhat.com> <4BA2388A.9020502@sun.com> <4BA24BAD.9020206@redhat.com> <4BA27385.9060200@sun.com> <17c6771e1003181145n1b1dc2b8na5fbab2be346ca0e@mail.gmail.com> <4BA29385.7020600@sun.com> <17c6771e1003181408k3faca6f7y75eec4c030519a9c@mail.gmail.com> <4BA29751.2020104@sun.com> <17c6771e1003181423o502b906s7c784c789509d15b@mail.gmail.com> <4BA78F93.4080507@sun.com> <17c6771e1003220901q59b8a4a3pffb328a46615d8d6@mail.gmail.com> Message-ID: <4BA79D21.4030907@sun.com> Andrew John Hughes wrote: >> On Windows you can use the "Windows-ROOT" KeyStore type, ex: >> >> keytool -list -keystore NONE -storetype Windows-ROOT >> > > Ok, so that presumably makes some Windows system call, right? Yes. > >> I haven't tried it, but you could probably use the keytool -importkeystore >> option to import all of these certs into the cacerts file. >> >> On Solaris, you could use the /usr/java/jre/lib/security/cacerts file. >> > > Isn't that exactly what's being installed? > Though maybe there's a general solution there of importing from the > bootstrap JDK. Right, or more specifically look in /usr/jdk for the installed JREs. Use something that isn't jdk1.7* ... --Sean From Christopher.Hegarty at Sun.COM Mon Mar 22 09:45:53 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Mon, 22 Mar 2010 16:45:53 +0000 Subject: [security-dev 01729]: Re: Code Review: 6614957, 6771432, 6766775 In-Reply-To: <4BA7945B.6070904@Sun.COM> References: <4BA7945B.6070904@Sun.COM> Message-ID: <4BA79EC1.7090701@Sun.COM> Dooh! Webrev: http://cr.openjdk.java.net/~chegar/6614957/webrev.00/webrev/ -Chris. On 22/03/2010 16:01, Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Andrew, Michael, > > This review is to forward port the following three bugs from 6uXX to JDK7: > 6614957: HttpsURLConnection not using the set SSLSocketFactory for > creating all its Sockets > 6771432: createSocket() - smpatch fails using 1.6.0_10 because of > "Unconnected sockets not implemented" > 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 > > The source changes are identical to what we have in JDK6uXX. > The tests come from 6uXX verbatim with minimal changes (license header, > com.sun.net.ssl.internal.ssl.SSLSocketImpl -> > sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs together > since they directly impact on each other. > > Please let me know if you require more information to be able to review. > > -Chris. > > From Xuelei.Fan at Sun.COM Mon Mar 22 17:53:51 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Tue, 23 Mar 2010 08:53:51 +0800 Subject: [security-dev 01730]: Re: Code Review: 6614957, 6771432, 6766775 In-Reply-To: <4BA7945B.6070904@Sun.COM> References: <4BA7945B.6070904@Sun.COM> Message-ID: <4BA8111F.9050501@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Andrew, Michael, > > This review is to forward port the following three bugs from 6uXX to > JDK7: > 6614957: HttpsURLConnection not using the set SSLSocketFactory for > creating all its Sockets > 6771432: createSocket() - smpatch fails using 1.6.0_10 because of > "Unconnected sockets not implemented" > 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 > > The source changes are identical to what we have in JDK6uXX. > The tests come from 6uXX verbatim with minimal changes (license > header, com.sun.net.ssl.internal.ssl.SSLSocketImpl -> > sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs > together since they directly impact on each other. Sounds good to me. Andrew > > Please let me know if you require more information to be able to review. > > -Chris. > > From Xuelei.Fan at Sun.COM Mon Mar 22 19:40:58 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Tue, 23 Mar 2010 10:40:58 +0800 Subject: [security-dev 01731]: Re: Code Review: 6614957, 6771432, 6766775 In-Reply-To: <4BA79EC1.7090701@Sun.COM> References: <4BA7945B.6070904@Sun.COM> <4BA79EC1.7090701@Sun.COM> Message-ID: <4BA82A3A.4040003@sun.com> Christopher Hegarty - Sun Microsystems Ireland wrote: > Dooh! Webrev: > > http://cr.openjdk.java.net/~chegar/6614957/webrev.00/webrev/ > Looks fine to me. Andrew > -Chris. > > On 22/03/2010 16:01, Christopher Hegarty - Sun Microsystems Ireland > wrote: >> Hi Andrew, Michael, >> >> This review is to forward port the following three bugs from 6uXX to >> JDK7: >> 6614957: HttpsURLConnection not using the set SSLSocketFactory for >> creating all its Sockets >> 6771432: createSocket() - smpatch fails using 1.6.0_10 because of >> "Unconnected sockets not implemented" >> 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 >> >> The source changes are identical to what we have in JDK6uXX. >> The tests come from 6uXX verbatim with minimal changes (license header, >> com.sun.net.ssl.internal.ssl.SSLSocketImpl -> >> sun.net.ssl.SSLSocketImpl). I plan to integrate all three bugs together >> since they directly impact on each other. >> >> Please let me know if you require more information to be able to review. >> >> -Chris. >> >> From weijun.wang at sun.com Mon Mar 22 19:42:26 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 23 Mar 2010 02:42:26 +0000 Subject: [security-dev 01732]: hg: jdk7/tl/jdk: 6586707: NTLM authentication with proxy fails Message-ID: <20100323024302.3CD6A4472E@hg.openjdk.java.net> Changeset: 31dcf23042f9 Author: weijun Date: 2010-03-23 10:41 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31dcf23042f9 6586707: NTLM authentication with proxy fails Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java From christopher.hegarty at sun.com Tue Mar 23 06:57:59 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 23 Mar 2010 13:57:59 +0000 Subject: [security-dev 01733]: hg: jdk7/tl/jdk: 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets; ... Message-ID: <20100323135911.52071447CD@hg.openjdk.java.net> Changeset: 8a9ebdc27045 Author: chegar Date: 2010-03-23 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a9ebdc27045 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 Summary: All three bugs are interdependent Reviewed-by: xuelei ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java From jonathan.gibbons at sun.com Tue Mar 23 18:07:03 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 24 Mar 2010 01:07:03 +0000 Subject: [security-dev 01734]: hg: jdk7/tl/langtools: 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Message-ID: <20100324010711.722334408A@hg.openjdk.java.net> Changeset: dd30de080cb9 Author: jjg Date: 2010-03-23 18:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd30de080cb9 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/6937244/T6937244.java + test/tools/javap/6937244/T6937244A.java From daniel.daugherty at sun.com Tue Mar 23 20:20:33 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 24 Mar 2010 03:20:33 +0000 Subject: [security-dev 01735]: hg: jdk7/tl/jdk: 6915365: 3/4 assert(false, "Unsupported VMGlobal Type") at management.cpp:1540 Message-ID: <20100324032046.21DBD440B1@hg.openjdk.java.net> Changeset: f8c9a5e3f5db Author: dcubed Date: 2010-03-23 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8c9a5e3f5db 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove exception throw to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/native/sun/management/Flag.c From jonathan.gibbons at sun.com Wed Mar 24 12:19:58 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 24 Mar 2010 19:19:58 +0000 Subject: [security-dev 01736]: hg: jdk7/tl/langtools: 6937318: jdk7 b86: javah and javah -help is no output for these commands Message-ID: <20100324192003.81CA4441A5@hg.openjdk.java.net> Changeset: 3058880c0b8d Author: jjg Date: 2010-03-24 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3058880c0b8d 6937318: jdk7 b86: javah and javah -help is no output for these commands Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java ! test/tools/javah/T6893943.java From joe.darcy at sun.com Wed Mar 24 17:03:57 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 25 Mar 2010 00:03:57 +0000 Subject: [security-dev 01737]: hg: jdk7/tl/langtools: 6937417: javac -Xprint returns IndexOutOfBoundsException Message-ID: <20100325000401.C8A36441EB@hg.openjdk.java.net> Changeset: 65e422bbb984 Author: darcy Date: 2010-03-24 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/65e422bbb984 6937417: javac -Xprint returns IndexOutOfBoundsException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + test/tools/javac/processing/model/util/elements/VacuousEnum.java From weijun.wang at sun.com Wed Mar 24 21:09:04 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 25 Mar 2010 04:09:04 +0000 Subject: [security-dev 01738]: hg: jdk7/tl/jdk: 6813340: X509Factory should not depend on is.available()==0 Message-ID: <20100325040917.7E9654422E@hg.openjdk.java.net> Changeset: 26477628f2d5 Author: weijun Date: 2010-03-25 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26477628f2d5 6813340: X509Factory should not depend on is.available()==0 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/KeyTool.java + test/java/security/cert/CertificateFactory/ReturnStream.java + test/java/security/cert/CertificateFactory/SlowStream.java + test/java/security/cert/CertificateFactory/slowstream.sh From christopher.hegarty at sun.com Thu Mar 25 02:40:31 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 25 Mar 2010 09:40:31 +0000 Subject: [security-dev 01739]: hg: jdk7/tl/jdk: 6937703: java/net regression test issues with samevm Message-ID: <20100325094056.833F744286@hg.openjdk.java.net> Changeset: 6109b166bf68 Author: chegar Date: 2010-03-25 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6109b166bf68 6937703: java/net regression test issues with samevm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java From Yu-Ching.Peng at Sun.COM Thu Mar 25 16:17:34 2010 From: Yu-Ching.Peng at Sun.COM (Valerie Peng) Date: Thu, 25 Mar 2010 16:17:34 -0700 Subject: [security-dev 01740]: Re: '\0' in alias name of a pkcs11 keystore In-Reply-To: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> Message-ID: <4BABEF0E.9030308@Sun.COM> Probably not. Unless explicitly specified through KeyStore APIs, aliases are constructed using the attributes values associated with the keys/certs. Thus, this is probably due to some problem with the native library which generated the keys/certs. Valerie On 03/18/10 19:03, Weijun Wang wrote: > Hi Valerie > > As described in http://forums.sun.com/thread.jspa?threadID=5432248, customer's pkcs11 keystore has aliases ended with '\0'. > > Is this something we should fix on the Java side? > > Thanks > Max > > From tomas at primekey.se Fri Mar 26 00:05:12 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Fri, 26 Mar 2010 08:05:12 +0100 Subject: [security-dev 01741]: Re: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BABEF0E.9030308@Sun.COM> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> Message-ID: <4BAC5CA8.8000602@primekey.se> Slightly off topic. Something I would like to see is API support for setting aliases when using the KeyPairGenerator. This is due to the fact that many HSMs do not allow changing an alias of private keys after they have been generated. Since the key pair generator sets a blank alias when using PKCS#11, HSM key pairs are left with no alias. You can set an alias by providing it using pkcs11 attributes through the provider, but that alias is provider global (for all generated key pairs) which is not very usable. Regards, Tomas On 03/26/2010 12:17 AM, Valerie Peng wrote: > > Probably not. Unless explicitly specified through KeyStore APIs, aliases > are constructed using the attributes values associated with the > keys/certs. Thus, this is probably due to some problem with the native > library which generated the keys/certs. > Valerie > > On 03/18/10 19:03, Weijun Wang wrote: >> Hi Valerie >> >> As described in http://forums.sun.com/thread.jspa?threadID=5432248, >> customer's pkcs11 keystore has aliases ended with '\0'. >> >> Is this something we should fix on the Java side? >> >> Thanks >> Max >> From kelly.ohair at sun.com Fri Mar 26 22:44:16 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 27 Mar 2010 05:44:16 +0000 Subject: [security-dev 01742]: hg: jdk7/tl/langtools: 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Message-ID: <20100327054418.366324454D@hg.openjdk.java.net> Changeset: de6375751eb7 Author: ohair Date: 2010-03-26 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/de6375751eb7 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Reviewed-by: jjg ! make/Makefile From xuelei.fan at sun.com Sun Mar 28 22:51:14 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Mon, 29 Mar 2010 05:51:14 +0000 Subject: [security-dev 01743]: hg: jdk7/tl/jdk: 6693917: regression tests need to update for supporting ECC on solaris 11 Message-ID: <20100329055200.65A9D44814@hg.openjdk.java.net> Changeset: 31517a0345d1 Author: xuelei Date: 2010-03-29 13:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31517a0345d1 6693917: regression tests need to update for supporting ECC on solaris 11 Reviewed-by: weijun ! test/sun/security/ssl/etc/keystore ! test/sun/security/ssl/etc/truststore ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java From Yu-Ching.Peng at Sun.COM Mon Mar 29 17:09:12 2010 From: Yu-Ching.Peng at Sun.COM (Valerie Peng) Date: Mon, 29 Mar 2010 17:09:12 -0700 Subject: [security-dev 01744]: Re: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BAC5CA8.8000602@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> Message-ID: <4BB14128.8080502@Sun.COM> Have you tried saving that key through the KeyStore API which allows you to specify an alias? Thanks, Valerie On 03/26/10 00:05, Tomas Gustavsson wrote: > > Slightly off topic. > Something I would like to see is API support for setting aliases when > using the KeyPairGenerator. This is due to the fact that many HSMs do > not allow changing an alias of private keys after they have been > generated. Since the key pair generator sets a blank alias when using > PKCS#11, HSM key pairs are left with no alias. > > You can set an alias by providing it using pkcs11 attributes through > the provider, but that alias is provider global (for all generated key > pairs) which is not very usable. > > Regards, > Tomas > > On 03/26/2010 12:17 AM, Valerie Peng wrote: >> >> Probably not. Unless explicitly specified through KeyStore APIs, aliases >> are constructed using the attributes values associated with the >> keys/certs. Thus, this is probably due to some problem with the native >> library which generated the keys/certs. >> Valerie >> >> On 03/18/10 19:03, Weijun Wang wrote: >>> Hi Valerie >>> >>> As described in http://forums.sun.com/thread.jspa?threadID=5432248, >>> customer's pkcs11 keystore has aliases ended with '\0'. >>> >>> Is this something we should fix on the Java side? >>> >>> Thanks >>> Max >>> > From tomas at primekey.se Mon Mar 29 22:57:38 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Tue, 30 Mar 2010 07:57:38 +0200 Subject: [security-dev 01745]: Re: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BB14128.8080502@Sun.COM> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> Message-ID: <4BB192D2.3000106@primekey.se> Hi, thanks for the answer. Generating a key in software and trying to store it on the HSM violates the whole idea of using an HSM. Which is to generate and maintain the keys in the HSM at all times. Most high security policies *requires* that the keys are generated by the HSM, inside the HSM. I also doubt that it would work to store software generated keys using the keytool API. Many HSMs even forbid this, at least when running in strict FIPS mode. Regards, Tomas Valerie Peng wrote: > Have you tried saving that key through the KeyStore API which allows you > to specify an alias? > Thanks, > Valerie > > On 03/26/10 00:05, Tomas Gustavsson wrote: >> >> Slightly off topic. >> Something I would like to see is API support for setting aliases when >> using the KeyPairGenerator. This is due to the fact that many HSMs do >> not allow changing an alias of private keys after they have been >> generated. Since the key pair generator sets a blank alias when using >> PKCS#11, HSM key pairs are left with no alias. >> >> You can set an alias by providing it using pkcs11 attributes through >> the provider, but that alias is provider global (for all generated key >> pairs) which is not very usable. >> >> Regards, >> Tomas >> >> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>> >>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>> are constructed using the attributes values associated with the >>> keys/certs. Thus, this is probably due to some problem with the native >>> library which generated the keys/certs. >>> Valerie >>> >>> On 03/18/10 19:03, Weijun Wang wrote: >>>> Hi Valerie >>>> >>>> As described in http://forums.sun.com/thread.jspa?threadID=5432248, >>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>> >>>> Is this something we should fix on the Java side? >>>> >>>> Thanks >>>> Max >>>> >> From valerie.peng at oracle.com Tue Mar 30 11:34:54 2010 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 30 Mar 2010 11:34:54 -0700 Subject: [security-dev 01746]: Re: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BB192D2.3000106@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> Message-ID: <4BB2444E.2030907@oracle.com> Why do you assume that the key is generated in software? You use the KeyGenerator API to generate a key, this key can be generated on the HSM if you have SunPKCS11 provider configured to be the most preferred provider. This key should actually just encapsulate the native key handle (not the actual value/encoding) which you can then pass it to the KeyStore API and specify an alias. The PKCS11 keystore impl would then take this key object (with the native key handle) and create a persistent copy on the HSM with the specified alias. Regards, Valerie On 03/29/10 22:57, Tomas Gustavsson wrote: > Hi, thanks for the answer. > > Generating a key in software and trying to store it on the HSM violates > the whole idea of using an HSM. Which is to generate and maintain the > keys in the HSM at all times. > Most high security policies *requires* that the keys are generated by > the HSM, inside the HSM. > I also doubt that it would work to store software generated keys using > the keytool API. Many HSMs even forbid this, at least when running in > strict FIPS mode. > > Regards, > Tomas > > Valerie Peng wrote: > >> Have you tried saving that key through the KeyStore API which allows you >> to specify an alias? >> Thanks, >> Valerie >> >> On 03/26/10 00:05, Tomas Gustavsson wrote: >> >>> Slightly off topic. >>> Something I would like to see is API support for setting aliases when >>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>> not allow changing an alias of private keys after they have been >>> generated. Since the key pair generator sets a blank alias when using >>> PKCS#11, HSM key pairs are left with no alias. >>> >>> You can set an alias by providing it using pkcs11 attributes through >>> the provider, but that alias is provider global (for all generated key >>> pairs) which is not very usable. >>> >>> Regards, >>> Tomas >>> >>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>> >>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>> are constructed using the attributes values associated with the >>>> keys/certs. Thus, this is probably due to some problem with the native >>>> library which generated the keys/certs. >>>> Valerie >>>> >>>> On 03/18/10 19:03, Weijun Wang wrote: >>>> >>>>> Hi Valerie >>>>> >>>>> As described in http://forums.sun.com/thread.jspa?threadID=5432248, >>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>> >>>>> Is this something we should fix on the Java side? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100330/2941f94a/attachment.html From mstjohns at comcast.net Tue Mar 30 12:40:03 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 30 Mar 2010 15:40:03 -0400 Subject: [security-dev 01747]: Re: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BAC5CA8.8000602@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> Message-ID: <20100330194013.24FB76054@mail.openjdk.java.net> At 03:05 AM 3/26/2010, Tomas Gustavsson wrote: >You can set an alias by providing it using pkcs11 attributes through the provider, but that alias is provider global (for all generated key pairs) which is not very usable. The work around for this is to open up the provider different times with different arguments. Build the config file as a string, open the string as a stream and then provide it to sun.security.pkcs11.SunPKCS11 (InputStream). A bit clumsy, but it does work. Mike From boris.dusek at gmail.com Tue Mar 30 04:55:07 2010 From: boris.dusek at gmail.com (=?UTF-8?B?Qm9yaXMgRHXFoWVr?=) Date: Tue, 30 Mar 2010 13:55:07 +0200 Subject: [security-dev 01748]: 6522064: Keystore aliases from MS CryptoAPI have bad encoding Message-ID: Hello, this is my first time contributing to Java or Sun (Oracle), so please forgive me if I am doing something wrong. I am writing because I met an issue with JSignPdf app and my testing certificates, which contain non-ASCII characters in my name (and so in CN field) [1]. So I found it's bug 6522064, and after a bit of hesitation, I downloaded the OpenJDK bundle for the first time and pin-pointed the issue down to src/windows/native/sun/security/mscapi/security.cpp, line 389, where CertGetNameString gets called in the "ANSI" version instead of Unicode version (bug 1), and what is more, converted into java String with NewStringUTF (bug 2). A quick test I then made was to make the call specifically reference the Unicode version (CertGetNameStringW) along with needed changes for this. The result was that the issue was fixed [2]. I am sending the patch in attachment to give you an idea of the problem and as a "proof of concept", but know that there are still questions to be answered to determine maybe more correct and systematic ways to fix/code this: 1. Is there a reason the security.cpp file (or even the entire JDK) is not built with UNICODE macro defined, so that functions like CertGetNameString automatically expand to their Unicode variants (CertGetNameStringW) and so that as a result Unicode is used throughout the place? Would it be a big deal to turn UNICODE on for the file (provided I fix the calls to Unicode)? 2. Do you think it's OK to convert all calls in security.cpp to Unicode (either explicitely with the "W" suffix to function name, or by defining UNICODE macro), or should only enough to fix the bug be converted (i.e. as in the patch)? Or more generally, what is the smallest unit of code that has to be converted (just the function, the whole security.cpp file, or the whole "security" directory? 3. What about unit tests for this issue? Do you think it's possible (or desirable) to write a unit test for this? If (according to point 2.) whole file gets fixed, then I think creating a certificate in Java with non-ASCII characters in CN and then storing and getting such certificate from Windows Certificate Store fails because no cert with that alias is found, that could be a test, but are such changes (adding certificate) to testing system OK for unit tests? 4. For testing, I am building the sunmscapi.dll just from the security.cpp file (to avoid building the whole JDK6 - I am using latest "user" JRE 6 from java.com), and statically link the C++ runtime from VC9 (to avoid using VC 2003, which I don't have). Should I still build the whole JDK (I have only VC2008 Express)? If yes, should I build and test jdk6, or jdk7 (security.cpp is unchanged between jdk6 and jdk7). 5. If I do work on this, is there any special location I should send the SCA to? The "deadline" for SCA is before someone commits the change, or am I late by not having it sent before sending this email? Please let me know your comments and suggestions. Thanks, Boris Du?ek [1]: http://www.flickr.com/photos/48318243 at N04/4476189180/ [2]: http://www.flickr.com/photos/48318243 at N04/4476189652/ - for fun, the names are, in order, Shimon Peres, Yellow Horse in Czech, Gandhi, Mohammed bin Rashid Al Maktoum, Mao Zedong, and Sergei Rachmaninoff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100330/87829ea3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: mscapi_unicode_alias.diff Type: application/octet-stream Size: 2505 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100330/87829ea3/mscapi_unicode_alias.diff From xueming.shen at sun.com Tue Mar 30 19:15:11 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Wed, 31 Mar 2010 02:15:11 +0000 Subject: [security-dev 01749]: hg: jdk7/tl/jdk: 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7; ... Message-ID: <20100331021524.C3C5044ABB@hg.openjdk.java.net> Changeset: 3771ac2a8b3b Author: sherman Date: 2010-03-30 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3771ac2a8b3b 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7 6911753: NSN wants to add Big5 HKSCS-2004 support Summary: support HKSCS2008 in Big5_HKSCS and MS950_HKSCS Reviewed-by: okutsu ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile + make/tools/CharsetMapping/Big5.c2b + make/tools/CharsetMapping/Big5.map + make/tools/CharsetMapping/Big5.nr + make/tools/CharsetMapping/HKSCS2001.c2b + make/tools/CharsetMapping/HKSCS2001.map + make/tools/CharsetMapping/HKSCS2008.c2b + make/tools/CharsetMapping/HKSCS2008.map + make/tools/CharsetMapping/HKSCS_XP.c2b + make/tools/CharsetMapping/HKSCS_XP.map ! make/tools/CharsetMapping/dbcs - make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/DBCS.java + make/tools/src/build/tools/charsetmapping/EUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java + make/tools/src/build/tools/charsetmapping/HKSCS.java + make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java + make/tools/src/build/tools/charsetmapping/SBCS.java + make/tools/src/build/tools/charsetmapping/Utils.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5.java ! src/share/classes/sun/io/ByteToCharBig5_HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5.java ! src/share/classes/sun/io/CharToByteBig5_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/nio/cs/ext/Big5.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS.java + src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java + src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/native/java/lang/java_props_md.c ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/native/java/lang/java_props_md.c ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/Charset/RegisteredCharsets.java From tomas at primekey.se Wed Mar 31 00:26:54 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 31 Mar 2010 09:26:54 +0200 Subject: [security-dev 01750]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BB2444E.2030907@oracle.com> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> Message-ID: <4BB2F93E.4070300@primekey.se> Hi, Sorry if I misunderstood you. That is actually exactly how we do it, 1. Use KeyPairGenerator with P11 provider to generate key pair. 2. Create a keystore with the P11 provier. 3. Generate a self signed certificate. 4. keystore.setKeyEntry(myalias, privateKey, null, cert). The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. 1. Private key - no alias 2. Public key - no alias 3. Certificate - myalias The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. Cheers, Tomas On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: > Why do you assume that the key is generated in software? > You use the KeyGenerator API to generate a key, this key can be > generated on the HSM if you have SunPKCS11 provider configured to be the > most preferred provider. This key should actually just encapsulate the > native key handle (not the actual value/encoding) which you can then > pass it to the KeyStore API and specify an alias. The PKCS11 keystore > impl would then take this key object (with the native key handle) and > create a persistent copy on the HSM with the specified alias. > > Regards, > Valerie > > On 03/29/10 22:57, Tomas Gustavsson wrote: >> Hi, thanks for the answer. >> >> Generating a key in software and trying to store it on the HSM violates >> the whole idea of using an HSM. Which is to generate and maintain the >> keys in the HSM at all times. >> Most high security policies *requires* that the keys are generated by >> the HSM, inside the HSM. >> I also doubt that it would work to store software generated keys using >> the keytool API. Many HSMs even forbid this, at least when running in >> strict FIPS mode. >> >> Regards, >> Tomas >> >> Valerie Peng wrote: >> >>> Have you tried saving that key through the KeyStore API which allows you >>> to specify an alias? >>> Thanks, >>> Valerie >>> >>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>> >>>> Slightly off topic. >>>> Something I would like to see is API support for setting aliases when >>>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>>> not allow changing an alias of private keys after they have been >>>> generated. Since the key pair generator sets a blank alias when using >>>> PKCS#11, HSM key pairs are left with no alias. >>>> >>>> You can set an alias by providing it using pkcs11 attributes through >>>> the provider, but that alias is provider global (for all generated key >>>> pairs) which is not very usable. >>>> >>>> Regards, >>>> Tomas >>>> >>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>> >>>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>> are constructed using the attributes values associated with the >>>>> keys/certs. Thus, this is probably due to some problem with the native >>>>> library which generated the keys/certs. >>>>> Valerie >>>>> >>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>> >>>>>> Hi Valerie >>>>>> >>>>>> As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>> >>>>>> Is this something we should fix on the Java side? >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >> >> > From mstjohns at comcast.net Wed Mar 31 17:51:47 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 31 Mar 2010 20:51:47 -0400 Subject: [security-dev 01751]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: <4BB2F93E.4070300@primekey.se> References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> Message-ID: <20100401005145.4B1A6686B@mail.openjdk.java.net> This may actually be a bug in the PKCS11 provider. KeyPairGenerator should be generating a "Session" key pair. When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. Let me look at the code and see what's going on and make further comments tomorrow. Mike At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: >Hi, > >Sorry if I misunderstood you. That is actually exactly how we do it, > >1. Use KeyPairGenerator with P11 provider to generate key pair. >2. Create a keystore with the P11 provier. >3. Generate a self signed certificate. >4. keystore.setKeyEntry(myalias, privateKey, null, cert). > >The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >1. Private key - no alias >2. Public key - no alias >3. Certificate - myalias > >The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. > >If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. > >So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. > >Cheers, >Tomas > > >On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >>Why do you assume that the key is generated in software? >>You use the KeyGenerator API to generate a key, this key can be >>generated on the HSM if you have SunPKCS11 provider configured to be the >>most preferred provider. This key should actually just encapsulate the >>native key handle (not the actual value/encoding) which you can then >>pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>impl would then take this key object (with the native key handle) and >>create a persistent copy on the HSM with the specified alias. >> >>Regards, >>Valerie >> >>On 03/29/10 22:57, Tomas Gustavsson wrote: >>>Hi, thanks for the answer. >>> >>>Generating a key in software and trying to store it on the HSM violates >>>the whole idea of using an HSM. Which is to generate and maintain the >>>keys in the HSM at all times. >>>Most high security policies *requires* that the keys are generated by >>>the HSM, inside the HSM. >>>I also doubt that it would work to store software generated keys using >>>the keytool API. Many HSMs even forbid this, at least when running in >>>strict FIPS mode. >>> >>>Regards, >>>Tomas >>> >>>Valerie Peng wrote: >>> >>>>Have you tried saving that key through the KeyStore API which allows you >>>>to specify an alias? >>>>Thanks, >>>>Valerie >>>> >>>>On 03/26/10 00:05, Tomas Gustavsson wrote: >>>> >>>>>Slightly off topic. >>>>>Something I would like to see is API support for setting aliases when >>>>>using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>not allow changing an alias of private keys after they have been >>>>>generated. Since the key pair generator sets a blank alias when using >>>>>PKCS#11, HSM key pairs are left with no alias. >>>>> >>>>>You can set an alias by providing it using pkcs11 attributes through >>>>>the provider, but that alias is provider global (for all generated key >>>>>pairs) which is not very usable. >>>>> >>>>>Regards, >>>>>Tomas >>>>> >>>>>On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>> >>>>>>Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>are constructed using the attributes values associated with the >>>>>>keys/certs. Thus, this is probably due to some problem with the native >>>>>>library which generated the keys/certs. >>>>>>Valerie >>>>>> >>>>>>On 03/18/10 19:03, Weijun Wang wrote: >>>>>> >>>>>>>Hi Valerie >>>>>>> >>>>>>>As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>> >>>>>>>Is this something we should fix on the Java side? >>>>>>> >>>>>>>Thanks >>>>>>>Max >>>>>>> >>> From valerie.peng at oracle.com Wed Mar 31 18:00:15 2010 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 31 Mar 2010 18:00:15 -0700 Subject: [security-dev 01752]: Re: alias in KeyPairGenerator - was: '\0' in alias name of a pkcs11 keystore In-Reply-To: References: <21773780-0803-4F32-A1B1-84FB5E700E6A@Sun.COM> <4BABEF0E.9030308@Sun.COM> <4BAC5CA8.8000602@primekey.se> <4BB14128.8080502@Sun.COM> <4BB192D2.3000106@primekey.se> <4BB2444E.2030907@oracle.com> <4BB2F93E.4070300@primekey.se> Message-ID: <4BB3F01F.6080504@oracle.com> If the default PKCS11 config is used, I'd expect that KeyPairGenerator to generate a "session" key and then SunPKCS11 keystore impl will do a C_CopyObject(...) w/ the desired alias. Is a custom PKCS11 config file used here? If yes, perhaps it specifies that token key be generated for key generation? Valerie On 03/31/10 17:51, Michael StJohns wrote: > KeyPairGenerator should be generating a "Session" key pair. > > When you write the key store object, the underlying function should do a C_CopyObject from the Session object to a Token object. (Or from a software key to a Token object). At that point, the template provided to C_CopyObject should be able to reset the CKA_LABEL attribute to the alias. > > Let me look at the code and see what's going on and make further comments tomorrow. > > Mike > > > At 03:26 AM 3/31/2010, Tomas Gustavsson wrote: > > >> Hi, >> >> Sorry if I misunderstood you. That is actually exactly how we do it, >> >> 1. Use KeyPairGenerator with P11 provider to generate key pair. >> 2. Create a keystore with the P11 provier. >> 3. Generate a self signed certificate. >> 4. keystore.setKeyEntry(myalias, privateKey, null, cert). >> >> The keys work fine to use in java. The issue is that in the HSM three objects are generated/stored. >> 1. Private key - no alias >> 2. Public key - no alias >> 3. Certificate - myalias >> >> The reason for this is that the alias of the private and public keys are set in the HSM when the keys are generated (with the KeyPairGenerator). The HSMs do not allow an alias of a private key (in particular) to be changed after generation, so setKeyEntry can not change the empty alias of the private key object. >> This has been confirmed by technicians at AEP, but it works the same in nCipher, SafeNet and Utimaco, i.e. no alias on the private key object. >> >> If we want to use HSM vendors tools to manipulate objects this usually causes problems because they mostly rely on an alias. >> >> So finally :-) this is why an alias parameter to KeyPairGenerator would be useful. >> >> Cheers, >> Tomas >> >> >> On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote: >> >>> Why do you assume that the key is generated in software? >>> You use the KeyGenerator API to generate a key, this key can be >>> generated on the HSM if you have SunPKCS11 provider configured to be the >>> most preferred provider. This key should actually just encapsulate the >>> native key handle (not the actual value/encoding) which you can then >>> pass it to the KeyStore API and specify an alias. The PKCS11 keystore >>> impl would then take this key object (with the native key handle) and >>> create a persistent copy on the HSM with the specified alias. >>> >>> Regards, >>> Valerie >>> >>> On 03/29/10 22:57, Tomas Gustavsson wrote: >>> >>>> Hi, thanks for the answer. >>>> >>>> Generating a key in software and trying to store it on the HSM violates >>>> the whole idea of using an HSM. Which is to generate and maintain the >>>> keys in the HSM at all times. >>>> Most high security policies *requires* that the keys are generated by >>>> the HSM, inside the HSM. >>>> I also doubt that it would work to store software generated keys using >>>> the keytool API. Many HSMs even forbid this, at least when running in >>>> strict FIPS mode. >>>> >>>> Regards, >>>> Tomas >>>> >>>> Valerie Peng wrote: >>>> >>>> >>>>> Have you tried saving that key through the KeyStore API which allows you >>>>> to specify an alias? >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 03/26/10 00:05, Tomas Gustavsson wrote: >>>>> >>>>> >>>>>> Slightly off topic. >>>>>> Something I would like to see is API support for setting aliases when >>>>>> using the KeyPairGenerator. This is due to the fact that many HSMs do >>>>>> not allow changing an alias of private keys after they have been >>>>>> generated. Since the key pair generator sets a blank alias when using >>>>>> PKCS#11, HSM key pairs are left with no alias. >>>>>> >>>>>> You can set an alias by providing it using pkcs11 attributes through >>>>>> the provider, but that alias is provider global (for all generated key >>>>>> pairs) which is not very usable. >>>>>> >>>>>> Regards, >>>>>> Tomas >>>>>> >>>>>> On 03/26/2010 12:17 AM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>>> Probably not. Unless explicitly specified through KeyStore APIs, aliases >>>>>>> are constructed using the attributes values associated with the >>>>>>> keys/certs. Thus, this is probably due to some problem with the native >>>>>>> library which generated the keys/certs. >>>>>>> Valerie >>>>>>> >>>>>>> On 03/18/10 19:03, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Valerie >>>>>>>> >>>>>>>> As described inhttp://forums.sun.com/thread.jspa?threadID=5432248, >>>>>>>> customer's pkcs11 keystore has aliases ended with '\0'. >>>>>>>> >>>>>>>> Is this something we should fix on the Java side? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20100331/39e2f95e/attachment.html