[security-dev 01659]: Code review request: 6923681: Jarsigner crashes during timestamping
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.w...@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=AA,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:///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.dco...@sun.com
[security-dev 01658]: Re: Code review request: 6844909: support allow_weak_crypto in krb5.conf
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.w...@sun.com
[security-dev 01657]: Re: Code review request: 6844909: support allow_weak_crypto in krb5.conf
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.w...@sun.com >>> >>> >>> >> >> >> >
[security-dev 01656]: Re: Code review request: 6844909: support allow_weak_crypto in krb5.conf
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.w...@sun.com
[security-dev 01655]: hg: jdk7/tl/jdk: 2 new changesets
Changeset: 78d91c4223cb Author:vinnie Date: 2010-03-01 17:54 + 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 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/893034df4ec2 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java
[security-dev 01654]: Re: Ending support for Java 1.1 policy files
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.
[security-dev 01653]: Re: Ending support for Java 1.1 policy files
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.
