From gnu_andrew at member.fsf.org Tue Sep 1 02:43:35 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 1 Sep 2009 10:43:35 +0100 Subject: [security-dev 01160]: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS Message-ID: <17c6771e0909010243j1a654815xea9dc9a45023becf@mail.gmail.com> 2009/8/28 Andrew John Hughes : > In OpenJDK6, the elliptic curve cryptography algorithms are available > if the PKCS11 provider is configured to point to NSS. See: > > http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider > > If NSS is configured as specified in this blog, keytool can be used to > generate a key as follows: > > $ keytool -v -genkeypair -keyalg EC -keysize 256 -keystore ectest.jks > -storepass test12 -dname "CN=ECC Test" > > With NSS 3.12.3 (the current version), this fails as follows: > > java.lang.RuntimeException: Could not parse key values > ? ? ? ?at sun.security.pkcs11.P11Key$P11ECPublicKey.fetchValues(P11Key.java:1028) > ? ? ? ?at sun.security.pkcs11.P11Key$P11ECPublicKey.getEncodedInternal(P11Key.java:1038) > ? ? ? ?at sun.security.pkcs11.P11Key.getEncoded(P11Key.java:126) > ? ? ? ?at sun.security.x509.CertificateX509Key.encode(CertificateX509Key.java:105) > ? ? ? ?at sun.security.x509.X509CertInfo.emit(X509CertInfo.java:819) > ? ? ? ?at sun.security.x509.X509CertInfo.encode(X509CertInfo.java:189) > ? ? ? ?at sun.security.x509.X509CertImpl.sign(X509CertImpl.java:528) > ? ? ? ?at sun.security.x509.X509CertImpl.sign(X509CertImpl.java:486) > ? ? ? ?at sun.security.x509.CertAndKeyGen.getSelfCertificate(CertAndKeyGen.java:288) > ? ? ? ?at sun.security.tools.KeyTool.doGenKeyPair(KeyTool.java:1223) > ? ? ? ?at sun.security.tools.KeyTool.doCommands(KeyTool.java:827) > ? ? ? ?at sun.security.tools.KeyTool.run(KeyTool.java:194) > ? ? ? ?at sun.security.tools.KeyTool.main(KeyTool.java:188) > Caused by: java.io.IOException: Point does not match field size > ? ? ? ?at sun.security.ec.ECParameters.decodePoint(ECParameters.java:95) > ? ? ? ?at sun.security.pkcs11.P11ECKeyFactory.decodePoint(P11ECKeyFactory.java:78) > ? ? ? ?at sun.security.pkcs11.P11Key$P11ECPublicKey.fetchValues(P11Key.java:1023) > ? ? ? ?... 12 more > > I did a bit of debugging, and the exception is caused by the array > generated by NSS being too large (for a keysize of 256, its size is 67 > rather than 65). > > Looking at the NSS code, it turns out that it handles a case which the > code in ECParameters.decodePoint doesn't: > > ? ? ? ? ? /* special note: We can't just use the first byte to > determine > ? ? ? ? ? ? * between these 2 cases because both > EC_POINT_FORM_UNCOMPRESSED > ? ? ? ? ? ? * and SEC_ASN1_OCTET_STRING are 0x04 */ > > ? ? ? ? ? ?/* handle the non-DER encoded case (UNCOMPRESSED only) */ > ? ? ? ? ? ?if (pubKey->u.ec.publicValue.data[0] == EC_POINT_FORM_UNCOMPRESSED > ? ? ? ? ? ? ? ?&& pubKey->u.ec.publicValue.len == keyLen) { > ? ? ? ? ? ? ? ?break; /* key was not DER encoded, no need to unwrap */ > ? ? ? ? ? ?} > > ? ? ? ? ? ?/* if we ever support compressed, handle it here */ > > ? ? ? ? ? ?/* handle the encoded case */ > ? ? ? ? ? ?if ((pubKey->u.ec.publicValue.data[0] == SEC_ASN1_OCTET_STRING) > ? ? ? ? ? ? ? ?&& pubKey->u.ec.publicValue.len > keyLen) { > ? ? ? ? ? ? ? ?SECItem publicValue; > ? ? ? ? ? ? ? ?SECStatus rv; > > ? ? ? ? ? ? ? ?rv = SEC_QuickDERDecodeItem(arena, &publicValue, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SEC_ASN1_GET(SEC_OctetStringTemplate), > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &pubKey->u.ec.publicValue); > ? ? ? ? ? ? ? ?/* nope, didn't decode correctly */ > ? ? ? ? ? ? ? ?if ((rv != SECSuccess) > ? ? ? ? ? ? ? ? ? ?|| (publicValue.data[0] != EC_POINT_FORM_UNCOMPRESSED) > ? ? ? ? ? ? ? ? ? ?|| (publicValue.len != keyLen)) { > ? ? ? ? ? ? ? ? ? ?crv = CKR_ATTRIBUTE_VALUE_INVALID; > ? ? ? ? ? ? ? ? ? ?break; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?/* replace our previous with the decoded key */ > ? ? ? ? ? ? ? ?pubKey->u.ec.publicValue = publicValue; > ? ? ? ? ? ? ? ?break; > ? ? ? ? ? ?} > > The code in decodePoint, by comparison, assumes that a block beginning > with 0x04 is uncompressed, then throws an exception because the array > is too large. ?The fact is that the array returned by NSS is DER > encoded, and this encoding specifies an octet string using a header of > 0x04. ?Luckily enough, there is a DER encoder in sun.security.util > which can decode this and with the following webrev: > > http://cr.openjdk.java.net/~andrew/ec/webrev.01/jdk.patch > > we can quite easily support this format. > > With the patch applied: > > $ keytool -v -genkeypair -keyalg EC -keysize 256 -keystore ectest.jks > -storepass test12 -dname "CN=ECC Test" > Generating 256 bit EC key pair and self-signed certificate > (SHA1withECDSA) with a validity of 90 days > ? ? ? ?for: CN=ECC Test > Enter key password for > ? ? ? ?(RETURN if same as keystore password): > [Storing ectest.jks] > > $ keytool -v -list -keystore ectest.jks -storepass test12 -dname "CN=ECC Test" > > Keystore type: JKS > Keystore provider: SUN > > Your keystore contains 1 entry > > Alias name: mykey > Creation date: 27-Aug-2009 > Entry type: PrivateKeyEntry > Certificate chain length: 1 > Certificate[1]: > Owner: CN=ECC Test > Issuer: CN=ECC Test > Serial number: 4a97068b > Valid from: Thu Aug 27 23:19:55 BST 2009 until: Wed Nov 25 22:19:55 GMT 2009 > Certificate fingerprints: > ? ? ? ? MD5: ?10:39:9E:CA:11:50:CD:BF:61:BC:16:1F:B2:43:52:E6 > ? ? ? ? SHA1: F7:8F:80:77:48:51:C6:3B:49:89:28:A8:5E:5F:7C:ED:D1:BD:CF:BE > ? ? ? ? Signature algorithm name: SHA1withECDSA > ? ? ? ? Version: 3 > > > ******************************************* > ******************************************* > > key creation works fine. > > The code has been refactored in 7 and the NSS source code included > (ugh) so this bug isn't triggered there: > > keytool -v -genkeypair -keyalg EC -keysize 256 -keystore ectest.jks > -storepass test12 -dname "CN=ECC Test" > Generating 256 bit EC key pair and self-signed certificate > (SHA1withECDSA) with a validity of 90 days > ? ? ? ?for: CN=ECC Test > Enter key password for > ? ? ? ?(RETURN if same as keystore password): > New certificate (self-signed): > [ > [ > ?Version: V3 > ?Subject: CN=ECC Test > ?Signature Algorithm: SHA1withECDSA, OID = 1.2.840.10045.4.1 > > ?Key: ?Sun EC public key, 256 bits > ?public x coord: > 111384255692518988314535813062807496116713232200028578473047050707653587930695 > ?public y coord: > 64522353781112987171728292648151233343880335217175194500175071174794420240032 > ?parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7) > ?Validity: [From: Fri Aug 28 00:17:30 BST 2009, > ? ? ? ? ? ? ? To: Wed Nov 25 23:17:30 GMT 2009] > ?Issuer: CN=ECC Test > ?SerialNumber: [ ? ?67f1afea] > > Certificate Extensions: 1 > [1]: ObjectId: 2.5.29.14 Criticality=false > SubjectKeyIdentifier [ > KeyIdentifier [ > 0000: C0 12 A6 B9 61 A7 78 C3 ? F9 B2 A4 E6 76 69 12 A0 ?....a.x.....vi.. > 0010: 10 59 C8 90 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.Y.. > ] > ] > > ] > ?Algorithm: [SHA1withECDSA] > ?Signature: > 0000: 30 44 02 20 2B 9A D6 8A ? 3E F4 37 2D D8 43 67 F6 ?0D. +...>.7-.Cg. > 0010: DF 51 EC 9D DC EF 0A 88 ? 86 F5 2F 25 84 3E E6 92 ?.Q......../%.>.. > 0020: 0D DA D5 51 02 20 0F 34 ? 9D 55 E5 C2 74 14 72 DA ?...Q. .4.U..t.r. > 0030: 53 95 9B 60 01 9A 0D D0 ? 64 89 B6 28 7F 96 22 83 ?S..`....d..(..". > 0040: DC 7F EF 10 EF 21 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.....! > > ] > [Storing ectest.jks] > > However, the same block of code is still there in ECParameters.java so > I presume the version of NSS imported from OpenSolaris is just older. > -- > 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 > Ping? Anyone home? -- 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 maurizio.cimadamore at sun.com Tue Sep 1 07:01:43 2009 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Tue, 01 Sep 2009 14:01:43 +0000 Subject: [security-dev 01161]: hg: jdk7/tl/langtools: 6650759: Inference of formal type parameter (unused in formal parameters) is not performed Message-ID: <20090901140148.62F2C12978@hg.openjdk.java.net> Changeset: dda7e13f09fb Author: mcimadamore Date: 2009-09-01 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dda7e13f09fb 6650759: Inference of formal type parameter (unused in formal parameters) is not performed Summary: propagate inference constraints from 15.12.2.7 to 15.12.2.8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712e.out + test/tools/javac/generics/inference/6650759/T6650759a.java + test/tools/javac/generics/inference/6650759/T6650759b.java + test/tools/javac/generics/inference/6650759/T6650759c.java + test/tools/javac/generics/inference/6650759/T6650759d.java + test/tools/javac/generics/inference/6650759/T6650759e.java + test/tools/javac/generics/inference/6650759/T6650759f.java + test/tools/javac/generics/inference/6650759/T6650759g.java + test/tools/javac/generics/inference/6650759/T6650759h.java + test/tools/javac/generics/inference/6650759/T6650759i.java + test/tools/javac/generics/inference/6650759/T6650759j.java + test/tools/javac/generics/inference/6650759/T6650759k.java + test/tools/javac/generics/inference/6650759/T6650759l.java + test/tools/javac/generics/inference/6650759/T6650759m.java + test/tools/javac/generics/inference/6650759/T6650759m.out From jonathan.gibbons at sun.com Tue Sep 1 11:43:17 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 01 Sep 2009 18:43:17 +0000 Subject: [security-dev 01162]: hg: jdk7/tl/langtools: 6877763: update langtools/test/Makefile for JPRT Message-ID: <20090901184328.8E6481298A@hg.openjdk.java.net> Changeset: 40a1327a5283 Author: jjg Date: 2009-09-01 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/40a1327a5283 6877763: update langtools/test/Makefile for JPRT Reviewed-by: ohair ! test/Makefile From Joe.Darcy at Sun.COM Tue Sep 1 13:39:09 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 01 Sep 2009 13:39:09 -0700 Subject: [security-dev 01163]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS In-Reply-To: <17c6771e0909010243j1a654815xea9dc9a45023becf@mail.gmail.com> References: <17c6771e0909010243j1a654815xea9dc9a45023becf@mail.gmail.com> Message-ID: <4A9D866D.30300@sun.com> Andrew John Hughes wrote: > 2009/8/28 Andrew John Hughes : >> In OpenJDK6, the elliptic curve cryptography algorithms are available >> if the PKCS11 provider is configured to point to NSS. See: >> >> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >> >> If NSS is configured as specified in this blog, keytool can be used to >> generate a key as follows: Hello. Allowing keytool and friends to work in more cases if the provider is capable seems fine to me. Security team, do you have concerns about this patch? Thanks, -Joe From mstjohns at comcast.net Tue Sep 1 16:40:44 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 01 Sep 2009 19:40:44 -0400 Subject: [security-dev 01164]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS In-Reply-To: <4A9D866D.30300@sun.com> References: <17c6771e0909010243j1a654815xea9dc9a45023becf@mail.gmail.com> <4A9D866D.30300@sun.com> Message-ID: <20090901234046.9AD0B11CF05@mail.openjdk.java.net> This appears to be related specifically to PKCS11. Specifically, PKCS11 v2.20 has some ambiguity of the representation of an EC point (which is different in the text than an ASN1 ECPoint). This is being clarified in v2.30 with the unencoded point format (e.g.the format described in X9.62, where the first octet indicates the encoding and there are either N or 2N octets following) being the expected value, but with PKCS11 providers allowed - legacy - to accept either. One of the reasons for going that way was how the JDK PKCS11 provider had interpreted the issue and implemented its code. I don't support this fix - among other things, this fix only deals with 1/2 of the problem. The other half is related to encoding the value. Also, changing the code at decodePoint seems further into the stack than needed and may affect other uses of that method. There's an existing JDK bug on this coming at it from a different direction - 6763530 ... and there may be considerations at https://bugzilla.mozilla.org/show_bug.cgi?id=480280 that should be looked at. Also see 6779460 which is mostly a duplicate of 6763530. It's probable that the fix I suggested at 6763530 (in comments submitted 29 Nov 08) may be a better approach given the NSS fixes. I believe it will fix the keytool problem noted in the original message. Mike At 04:39 PM 9/1/2009, Joe Darcy wrote: >Andrew John Hughes wrote: >>2009/8/28 Andrew John Hughes : >>>In OpenJDK6, the elliptic curve cryptography algorithms are available >>>if the PKCS11 provider is configured to point to NSS. See: >>> >>>http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>> >>>If NSS is configured as specified in this blog, keytool can be used to >>>generate a key as follows: > >Hello. > >Allowing keytool and friends to work in more cases if the provider is capable seems fine to me. > >Security team, do you have concerns about this patch? > >Thanks, > >-Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20090901/be39edf3/attachment.html From gnu_andrew at member.fsf.org Tue Sep 1 18:38:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Sep 2009 02:38:12 +0100 Subject: [security-dev 01165]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS In-Reply-To: <4a9db101.a415f10a.5a99.6040SMTPIN_ADDED@mx.google.com> References: <17c6771e0909010243j1a654815xea9dc9a45023becf@mail.gmail.com> <4A9D866D.30300@sun.com> <4a9db101.a415f10a.5a99.6040SMTPIN_ADDED@mx.google.com> Message-ID: <17c6771e0909011838r244bae49h788689a9b5844da@mail.gmail.com> 2009/9/2 Michael StJohns : > ?This appears to be related specifically to PKCS11.? Specifically, PKCS11 > v2.20 has some ambiguity of the representation of an EC point (which is > different in the text than an ASN1 ECPoint). > > This is being clarified in v2.30 with the unencoded point format (e.g.the > format described in? X9.62, where the first octet indicates the encoding and > there are either N or 2N octets following)? being the expected value, but > with PKCS11 providers allowed - legacy - to accept either. > > One of the reasons for going that way was how the JDK PKCS11 provider had > interpreted the issue and implemented its code. > > I don't support this fix - among other things, this fix only deals with 1/2 > of the problem.? The other half is related to encoding the value.? Also, > changing the code at decodePoint seems further into the stack than needed > and may affect other uses of that method. > That's really too vague to be of much help in improving the patch. You seem to be saying little more than 'I don't like it'. > There's an existing JDK bug on this coming at it from a different direction > - 6763530 ... and there may be considerations at > > https://bugzilla.mozilla.org/show_bug.cgi?id=480280 > It seems likely that's the NSS change that causes the current failure. The fix I submitted here is based on the way this is handle in NSS. In fact, the code is similar enough to suggest that one was developed from the other. > ?that should be looked at. The JDK bug is not really 'from a different direction', it's reporting exactly the same error but from a less trivial example (I get the same failure while trying to create an example key, while this seems to require specific hardware if I'm reading it correctly). Also see 6779460 which is mostly a duplicate of > 6763530. > The patch on 6779460 seems wrong. It means that the method will return a DER-encoded value where it would either have returned an uncompressed value before or failed. > > It's probable that the fix I suggested at 6763530? (in comments submitted 29 > Nov 08) may be a better approach given the NSS fixes.? I believe it will fix > the keytool problem noted in the original message. > Ok, I can see the logic in the fix and it would appear to work, though I haven't tested it. Given the patch was written nine months ago, why has it not been applied? If it had, it would have saved me hours having to debug this same issue again. Do you have an SCA with Sun? If so, I'll create a webrev based on your patch and we can finally get this fixed. Without it, NSS support is completely broken in OpenJDK6 which makes me wonder why this is a low priority bug! > Mike > > > > > > At 04:39 PM 9/1/2009, Joe Darcy wrote: > > Andrew John Hughes wrote: > > 2009/8/28 Andrew John Hughes : > > In OpenJDK6, the elliptic curve cryptography algorithms are available > if the PKCS11 provider is configured to point to NSS. See: > > http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider > > If NSS is configured as specified in this blog, keytool can be used to > generate a key as follows: > > Hello. > > Allowing keytool and friends to work in more cases if the provider is > capable seems fine to me. > > Security team, do you have concerns about this patch? > > Thanks, > > -Joe > -- 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 mstjohns at comcast.net Tue Sep 1 21:36:16 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 02 Sep 2009 00:36:16 -0400 Subject: [security-dev 01166]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS In-Reply-To: <17c6771e0909011838r244bae49h788689a9b5844da@mail.gmail.com > References: <17c6771e0909010243j1a654815xea9dc9a45023becf@mail.gmail.com> <4A9D866D.30300@sun.com> <4a9db101.a415f10a.5a99.6040SMTPIN_ADDED@mx.google.com> <17c6771e0909011838r244bae49h788689a9b5844da@mail.gmail.com> Message-ID: <20090902043618.87C2811C39F@mail.openjdk.java.net> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >2009/9/2 Michael StJohns : >> ? This appears to be related specifically to PKCS11.? Specifically, PKCS11 >> v2.20 has some ambiguity of the representation of an EC point (which is >> different in the text than an ASN1 ECPoint). >> >> This is being clarified in v2.30 with the unencoded point format (e.g.the >> format described in? X9.62, where the first octet indicates the encoding and >> there are either N or 2N octets following)? being the expected value, but >> with PKCS11 providers allowed - legacy - to accept either. >> >> One of the reasons for going that way was how the JDK PKCS11 provider had >> interpreted the issue and implemented its code. >> >> I don't support this fix - among other things, this fix only deals with 1/2 >> of the problem.? The other half is related to encoding the value.? Also, >> changing the code at decodePoint seems further into the stack than needed >> and may affect other uses of that method. >> > >That's really too vague to be of much help in improving the patch. >You seem to be saying little more than 'I don't like it'. Sorry about that. My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >> There's an existing JDK bug on this coming at it from a different direction >> - 6763530 ... and there may be considerations at >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >> > >It seems likely that's the NSS change that causes the current failure. > The fix I submitted here is based on the way this is handle in NSS. >In fact, the code is similar enough to suggest that one was developed >from the other. > >> ? that should be looked at. > >The JDK bug is not really 'from a different direction', it's reporting >exactly the same error but from a less trivial example (I get the same >failure while trying to create an example key, while this seems to >require specific hardware if I'm reading it correctly). Not exactly. You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >Also see 6779460 which is mostly a duplicate of >> 6763530. >> > >The patch on 6779460 seems wrong. It means that the method will >return a DER-encoded value where it would either have returned an >uncompressed value before or failed. My point exactly as I mentioned in the comments. :-) >> >> It's probable that the fix I suggested at 6763530? (in comments submitted 29 >> Nov 08) may be a better approach given the NSS fixes.? I believe it will fix >> the keytool problem noted in the original message. >> > >Ok, I can see the logic in the fix and it would appear to work, though >I haven't tested it. >Given the patch was written nine months ago, why has it not been >applied? If it had, it would have saved me hours having to debug this >same issue again. Yup. I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >Do you have an SCA with Sun? If so, I'll create a webrev based on your >patch and we can finally get this fixed. Without it, NSS support is >completely broken in OpenJDK6 which makes me wonder why this is a low >priority bug! I do have an SCA on file. Note that the recommendation from the NSS guys was to raise the priority. The reason I haven't submitted this is because I submitted a different EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process and was waiting on progress there before continuing. I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. And then I got busy with some other things... Mike >> Mike >> >> >> >> >> >> At 04:39 PM 9/1/2009, Joe Darcy wrote: >> >> Andrew John Hughes wrote: >> >> 2009/8/28 Andrew John Hughes : >> >> In OpenJDK6, the elliptic curve cryptography algorithms are available >> if the PKCS11 provider is configured to point to NSS. See: >> >> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >> >> If NSS is configured as specified in this blog, keytool can be used to >> generate a key as follows: >> >> Hello. >> >> Allowing keytool and friends to work in more cases if the provider is >> capable seems fine to me. >> >> Security team, do you have concerns about this patch? >> >> Thanks, >> >> -Joe >> > > > >-- >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 jonathan.gibbons at sun.com Wed Sep 2 10:29:18 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 02 Sep 2009 17:29:18 +0000 Subject: [security-dev 01167]: hg: jdk7/tl/langtools: 6874249: Check has duplicate local variable and field for "source" Message-ID: <20090902172924.4036112A6E@hg.openjdk.java.net> Changeset: 8d999cb7ec09 Author: jjg Date: 2009-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8d999cb7ec09 6874249: Check has duplicate local variable and field for "source" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java From gnu_andrew at member.fsf.org Wed Sep 2 12:14:43 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Sep 2009 20:14:43 +0100 Subject: [security-dev 01168]: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 Message-ID: <17c6771e0909021214u54676f86sd3c0fc82a5b622db@mail.gmail.com> 2009/9/2 Michael StJohns : > At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>2009/9/2 Michael StJohns : >>> ? This appears to be related specifically to PKCS11.? ?Specifically, PKCS11 >>> v2.20 has some ambiguity of the representation of an EC point (which is >>> different in the text than an ASN1 ECPoint). >>> >>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>> format described in? ?X9.62, where the first octet indicates the encoding and >>> there are either N or 2N octets following)? ?being the expected value, but >>> with PKCS11 providers allowed - legacy - to accept either. >>> >>> One of the reasons for going that way was how the JDK PKCS11 provider had >>> interpreted the issue and implemented its code. >>> >>> I don't support this fix - among other things, this fix only deals with 1/2 >>> of the problem.? ?The other half is related to encoding the value.? ?Also, >>> changing the code at decodePoint seems further into the stack than needed >>> and may affect other uses of that method. >>> >> >>That's really too vague to be of much help in improving the patch. >>You seem to be saying little more than 'I don't like it'. > > Sorry about that. ?My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. > > >>> There's an existing JDK bug on this coming at it from a different direction >>> - 6763530 ... and there may be considerations at >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>> >> >>It seems likely that's the NSS change that causes the current failure. >> The fix I submitted here is based on the way this is handle in NSS. >>In fact, the code is similar enough to suggest that one was developed >>from the other. >> >>> ? that should be looked at. >> >>The JDK bug is not really 'from a different direction', it's reporting >>exactly the same error but from a less trivial example (I get the same >>failure while trying to create an example key, while this seems to >>require specific hardware if I'm reading it correctly). > > Not exactly. ?You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. > > >>Also see 6779460 which is mostly a duplicate of >>> 6763530. >>> >> >>The patch on 6779460 seems wrong. ?It means that the method will >>return a DER-encoded value where it would either have returned an >>uncompressed value before or failed. > > My point exactly as I mentioned in the comments. ?:-) > > >>> >>> It's probable that the fix I suggested at 6763530? ?(in comments submitted 29 >>> Nov 08) may be a better approach given the NSS fixes.? ?I believe it will fix >>> the keytool problem noted in the original message. >>> >> >>Ok, I can see the logic in the fix and it would appear to work, though >>I haven't tested it. >>Given the patch was written nine months ago, why has it not been >>applied? ?If it had, it would have saved me hours having to debug this >>same issue again. > > Yup. ?I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. > >>Do you have an SCA with Sun? If so, I'll create a webrev based on your >>patch and we can finally get this fixed. ?Without it, NSS support is >>completely broken in OpenJDK6 which makes me wonder why this is a low >>priority bug! > > I do have an SCA on file. ?Note that the recommendation from the NSS guys was to raise the priority. > > The reason I haven't submitted this is because I submitted a different EC fix ?https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process > ?and was waiting on progress there before continuing. ?I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. ?And then I got busy with some other things... > > Mike > > > > > >>> Mike >>> >>> >>> >>> >>> >>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>> >>> Andrew John Hughes wrote: >>> >>> 2009/8/28 Andrew John Hughes : >>> >>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>> if the PKCS11 provider is configured to point to NSS. See: >>> >>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>> >>> If NSS is configured as specified in this blog, keytool can be used to >>> generate a key as follows: >>> >>> Hello. >>> >>> Allowing keytool and friends to work in more cases if the provider is >>> capable seems fine to me. >>> >>> Security team, do you have concerns about this patch? >>> >>> Thanks, >>> >>> -Joe >>> >> >> >> >>-- >>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 > > > Ok here is a new webrev: http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ with a slightly revised version of your change (you can't throw a PKCS11Exception which only takes a long ID from the native code, so I changed this to an IllegalArgumentException). Security team, does this look ok to push? -- 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 Ulf.Zibis at gmx.de Wed Sep 2 13:12:10 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 02 Sep 2009 22:12:10 +0200 Subject: [security-dev 01169]: Re: hg: jdk7/tl/jdk: 16 new changesets In-Reply-To: <20090830070022.D6A6B12820@hg.openjdk.java.net> References: <20090830070022.D6A6B12820@hg.openjdk.java.net> Message-ID: <4A9ED19A.7050608@gmx.de> Am 30.08.2009 08:54, tim.bell at sun.com schrieb: > Changeset: 4c6a5ea563ba > Author: peytoia > Date: 2009-07-30 14:45 +0900 > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c6a5ea563ba > > 6866243: Javadoc for java.lang.Character still refers to Unicode 4 instead of 5 > Reviewed-by: okutsu > > ! src/share/classes/java/lang/Character.java > There is still a reference to Unicode 4. See comment in method toUpperCaseCharArray(int codePoint). -Ulf From mstjohns at comcast.net Thu Sep 3 09:10:23 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 03 Sep 2009 12:10:23 -0400 Subject: [security-dev 01170]: Re: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <17c6771e0909021214u54676f86sd3c0fc82a5b622db@mail.gmail.co m> References: <17c6771e0909021214u54676f86sd3c0fc82a5b622db@mail.gmail.com> Message-ID: <20090903161025.A3C7C11C75A@mail.openjdk.java.net> At 03:14 PM 9/2/2009, Andrew John Hughes wrote: >Ok here is a new webrev: > >http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ > >with a slightly revised version of your change (you can't throw a >PKCS11Exception which only takes a long ID from the native code, so I >changed this to an IllegalArgumentException). Yeah - when I realized this a while later (when I actually started building the JDK from source) I actually considered changing PKCS11Exception to implement constructors with just a message and with a message and a code. If you throw with just a message the code would get set to CKR_GENERAL_ERROR. If you throw with message and a code, the message for the code would get prepended to the provided message. That's another topic though. This particular error comes under the heading of one that shouldn't happen - we did the explicit encoding so the "toByteArray()" shouldn't fail. That's pretty much the definition of a runtime error. Maybe use the little used PKCS11RuntimeError instead of the IllegalArgumentException? Mike From gnu_andrew at member.fsf.org Thu Sep 3 10:39:03 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 3 Sep 2009 18:39:03 +0100 Subject: [security-dev 01171]: Re: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4a9fea75.9e15f10a.7b21.1ed1SMTPIN_ADDED@mx.google.com> References: <17c6771e0909021214u54676f86sd3c0fc82a5b622db@mail.gmail.com> <4a9fea75.9e15f10a.7b21.1ed1SMTPIN_ADDED@mx.google.com> Message-ID: <17c6771e0909031039i2d0a8a0o17ea0fe37a7e93da@mail.gmail.com> 2009/9/3 Michael StJohns : > > > > At 03:14 PM 9/2/2009, Andrew John Hughes wrote: >>Ok here is a new webrev: >> >>http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >> >>with a slightly revised version of your change (you can't throw a >>PKCS11Exception which only takes a long ID from the native code, so I >>changed this to an IllegalArgumentException). > > Yeah - when I realized this a while later (when I actually started building the JDK from source) I actually considered changing PKCS11Exception to implement constructors with just a message and with a message and a code. ? If you throw with just a message the code would get set to CKR_GENERAL_ERROR. ?If you throw with message and a code, the message for the code would get prepended to the provided message. ?That's another topic though. > > This particular error comes under the heading of one that shouldn't happen - we did the explicit encoding so the "toByteArray()" shouldn't fail. ?That's pretty much the definition of a runtime error. ?Maybe use the little used PKCS11RuntimeError instead of the IllegalArgumentException? > IllegalArgumentException seems appropriate to me as it's a failure with one of the arguments to that method (the params). Assuming PKCS11RuntimeError is in the same vein as PKCS11Exception, we don't want to use them as they pertain to the native NSS code which isn't the result of the fault here. The main thing is that the IOException is available via the cause of the exception that actually gets thrown. > > Mike > > > > -- 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 mstjohns at comcast.net Thu Sep 3 11:49:35 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 03 Sep 2009 14:49:35 -0400 Subject: [security-dev 01172]: Re: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <17c6771e0909031039i2d0a8a0o17ea0fe37a7e93da@mail.gmail.com > References: <17c6771e0909021214u54676f86sd3c0fc82a5b622db@mail.gmail.com> <4a9fea75.9e15f10a.7b21.1ed1SMTPIN_ADDED@mx.google.com> <17c6771e0909031039i2d0a8a0o17ea0fe37a7e93da@mail.gmail.com> Message-ID: <20090903184937.6CE7811CD07@mail.openjdk.java.net> At 01:39 PM 9/3/2009, Andrew John Hughes wrote: >2009/9/3 Michael StJohns : >> >> >> >> At 03:14 PM 9/2/2009, Andrew John Hughes wrote: >>>Ok here is a new webrev: >>> >>>http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >>>with a slightly revised version of your change (you can't throw a >>>PKCS11Exception which only takes a long ID from the native code, so I >>>changed this to an IllegalArgumentException). >> >> Yeah - when I realized this a while later (when I actually started building the JDK from source) I actually considered changing PKCS11Exception to implement constructors with just a message and with a message and a code. ? If you throw with just a message the code would get set to CKR_GENERAL_ERROR. ? If you throw with message and a code, the message for the code would get prepended to the provided message. ? That's another topic though. >> >> This particular error comes under the heading of one that shouldn't happen - we did the explicit encoding so the "toByteArray()" shouldn't fail. ? That's pretty much the definition of a runtime error. ? Maybe use the little used PKCS11RuntimeError instead of the IllegalArgumentException? >> > >IllegalArgumentException seems appropriate to me as it's a failure >with one of the arguments to that method (the params). Assuming >PKCS11RuntimeError is in the same vein as PKCS11Exception, we don't >want to use them as they pertain to the native NSS code which isn't >the result of the fault here. The main thing is that the IOException >is available via the cause of the exception that actually gets thrown. > >> Except that we're trapping errors from the DER encoding of the wrapped point, not from problems with the provided argument. By the time we get to try-catch block, we've already turned the ECPoint into a byte array and wrapped it in a DerValue(OctetString,..). PKCS11RuntimeException does allow you to pass on the IOException and an informative message. It has the normal 4 constructors - null, message, exception, message and exception. Alternately, IOError may be appropriate. If you actually have an encoding error, something really bad went wrong with the DerValue functions and user programs probably shouldn't attempt to handle it. I can live with IllegalArgumentException - its Runtime so it doesn't change the requirements for calling the method. But it seems a little bit off as a choice here. >> Mike >> >> >> >> > > > >-- >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 weijun.wang at sun.com Fri Sep 4 00:09:45 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 04 Sep 2009 07:09:45 +0000 Subject: [security-dev 01173]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090904071039.9227012BD5@hg.openjdk.java.net> Changeset: ee5300e1835a Author: weijun Date: 2009-09-04 14:58 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee5300e1835a 6876328: different names for the same digest algorithms breaks jarsigner Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/nameclash.sh Changeset: 98ad1322051e Author: weijun Date: 2009-09-04 14:59 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98ad1322051e 6871847: AlgorithmId.get("SHA256withECDSA") not available Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/SHA256withECDSA.java From joe.darcy at sun.com Fri Sep 4 13:19:49 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 04 Sep 2009 20:19:49 +0000 Subject: [security-dev 01174]: hg: jdk7/tl/jdk: 6873951: test/java/lang/reflect/Generics/Probe.java fails. Message-ID: <20090904202035.25AB812FEA@hg.openjdk.java.net> Changeset: c34f92a47245 Author: darcy Date: 2009-09-04 13:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c34f92a47245 6873951: test/java/lang/reflect/Generics/Probe.java fails. Reviewed-by: alanb ! test/java/lang/reflect/Generics/Probe.java From martinrb at google.com Fri Sep 4 13:59:01 2009 From: martinrb at google.com (martinrb at google.com) Date: Fri, 04 Sep 2009 20:59:01 +0000 Subject: [security-dev 01175]: hg: jdk7/tl/jdk: 6879368: Remove stray quote in Character javadoc Message-ID: <20090904205940.3BF69E013@hg.openjdk.java.net> Changeset: 704296144175 Author: martin Date: 2009-09-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/704296144175 6879368: Remove stray quote in Character javadoc Summary: Remove stray quote in Character.valueOf javadoc, using Ulf's \u005CuXXXX technique Reviewed-by: darcy ! src/share/classes/java/lang/Character.java From alan.bateman at sun.com Sat Sep 5 08:07:05 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Sat, 05 Sep 2009 15:07:05 +0000 Subject: [security-dev 01176]: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20090905150831.EE952E07F@hg.openjdk.java.net> Changeset: 3f87b755b1c8 Author: alanb Date: 2009-09-04 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3f87b755b1c8 6873621: (file) FileStore.supportsFileAttributeView(Class type) returns wrong result Reviewed-by: andrew ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: 05ea733a7ae2 Author: alanb Date: 2009-09-04 18:17 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05ea733a7ae2 6868627: (spec) Files.walkFileTree doesn't make it clear that uncaught errors and exceptions are propagated Reviewed-by: sherman ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java Changeset: 87a2ef2439bc Author: alanb Date: 2009-09-04 22:22 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/87a2ef2439bc 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException Reviewed-by: tbell, ohair, dcubed, andrew ! src/share/transport/socket/socketTransport.c ! test/com/sun/jdi/BadHandshakeTest.java Changeset: 7afdf9d0bc2c Author: alanb Date: 2009-09-05 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7afdf9d0bc2c Merge From Ulf.Zibis at gmx.de Sat Sep 5 12:54:30 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 05 Sep 2009 21:54:30 +0200 Subject: [security-dev 01177]: Re: hg: jdk7/tl/jdk: 6879368: Remove stray quote in Character javadoc In-Reply-To: <20090904205940.3BF69E013@hg.openjdk.java.net> References: <20090904205940.3BF69E013@hg.openjdk.java.net> Message-ID: <4AA2C1F6.8000403@gmx.de> Am 04.09.2009 22:59, martinrb at google.com schrieb: > Changeset: 704296144175 > Author: martin > Date: 2009-09-04 13:44 -0700 > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/704296144175 > > 6879368: Remove stray quote in Character javadoc > Summary: Remove stray quote in Character.valueOf javadoc, using Ulf's \u005CuXXXX technique > Reviewed-by: darcy > > ! src/share/classes/java/lang/Character.java > > > To be accurate: It's David M. Lloyd's technique! -Ulf From tim.bell at sun.com Mon Sep 7 09:44:52 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 16:44:52 +0000 Subject: [security-dev 01178]: hg: jdk7/tl: Added tag jdk7-b71 for changeset 4c36e9853dda Message-ID: <20090907164453.2B39CE0F1@hg.openjdk.java.net> Changeset: 378f57273f09 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/378f57273f09 Added tag jdk7-b71 for changeset 4c36e9853dda ! .hgtags From tim.bell at sun.com Mon Sep 7 09:51:22 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 16:51:22 +0000 Subject: [security-dev 01179]: hg: jdk7/tl/corba: 4 new changesets Message-ID: <20090907165126.8A819E0F8@hg.openjdk.java.net> Changeset: 8001ba2bf10d Author: andrew Date: 2009-08-20 01:28 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/8001ba2bf10d 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: jjg, ohair ! make/common/shared/Defs-java.gmk Changeset: 04414f276160 Author: xdono Date: 2009-08-24 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/04414f276160 Merge Changeset: 3f1ef7f899ea Author: andrew Date: 2009-09-01 23:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/3f1ef7f899ea 6878106: Synchronize CORBA and JDK makefiles where possible Summary: Add recent changes to the JDK makefile to the CORBA makefile Reviewed-by: jjg, never ! make/common/shared/Defs-java.gmk Changeset: c793a3120926 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c793a3120926 Added tag jdk7-b71 for changeset 3f1ef7f899ea ! .hgtags From tim.bell at sun.com Mon Sep 7 09:59:41 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 16:59:41 +0000 Subject: [security-dev 01180]: hg: jdk7/tl/hotspot: Added tag jdk7-b71 for changeset 50a95aa4a247 Message-ID: <20090907165947.3A9F5E0FF@hg.openjdk.java.net> Changeset: 6e6427f797c0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6e6427f797c0 Added tag jdk7-b71 for changeset 50a95aa4a247 ! .hgtags From tim.bell at sun.com Mon Sep 7 10:15:50 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 17:15:50 +0000 Subject: [security-dev 01181]: hg: jdk7/tl/jaxp: Added tag jdk7-b71 for changeset ff94d8ce0dad Message-ID: <20090907171552.7AF24E104@hg.openjdk.java.net> Changeset: 37c805b6156f Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/37c805b6156f Added tag jdk7-b71 for changeset ff94d8ce0dad ! .hgtags From tim.bell at sun.com Mon Sep 7 10:22:01 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 17:22:01 +0000 Subject: [security-dev 01182]: hg: jdk7/tl/jaxws: Added tag jdk7-b71 for changeset 03314cf56a72 Message-ID: <20090907172204.27D39E109@hg.openjdk.java.net> Changeset: 4c990aa99bc0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/4c990aa99bc0 Added tag jdk7-b71 for changeset 03314cf56a72 ! .hgtags From tim.bell at sun.com Mon Sep 7 10:29:02 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 17:29:02 +0000 Subject: [security-dev 01183]: hg: jdk7/tl/jdk: 9 new changesets Message-ID: <20090907173119.D25E8E10E@hg.openjdk.java.net> Changeset: 80368890a2a0 Author: andrew Date: 2009-08-18 19:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80368890a2a0 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: 43465920bf47 Author: xdono Date: 2009-08-18 19:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/43465920bf47 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: b3aac0db5586 Author: tbell Date: 2009-08-21 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b3aac0db5586 6705913: freetype_versioncheck.exe - Unable To Locate Component Summary: Update freetype_versioncheck to deal with newer Visual Studio releases Reviewed-by: ohair ! make/tools/freetypecheck/Makefile ! make/tools/freetypecheck/freetypecheck.c Changeset: e0b26d347302 Author: xdono Date: 2009-08-24 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0b26d347302 Merge Changeset: b3f3240135f0 Author: xdono Date: 2009-09-01 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b3f3240135f0 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: ce3fde68c495 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce3fde68c495 Added tag jdk7-b71 for changeset b3f3240135f0 ! .hgtags Changeset: ed0863629d28 Author: tbell Date: 2009-09-03 18:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed0863629d28 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 658a4255c797 Author: tbell Date: 2009-09-04 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/658a4255c797 Merge Changeset: abb69e8b1774 Author: tbell Date: 2009-09-06 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abb69e8b1774 Merge From tim.bell at sun.com Mon Sep 7 10:44:03 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 07 Sep 2009 17:44:03 +0000 Subject: [security-dev 01184]: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20090907174410.44916E11F@hg.openjdk.java.net> Changeset: d434aa041b52 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d434aa041b52 Added tag jdk7-b71 for changeset 33c8c38e1757 ! .hgtags Changeset: 90c28923e449 Author: tbell Date: 2009-09-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/90c28923e449 Merge - test/tools/javac/innerClassFile/Driver.java - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java From jonathan.gibbons at sun.com Tue Sep 8 11:20:35 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 08 Sep 2009 18:20:35 +0000 Subject: [security-dev 01185]: hg: jdk7/tl/langtools: 6419701: DefaultFileManager clean up: URI.create; ... Message-ID: <20090908182040.7DCC1E24D@hg.openjdk.java.net> Changeset: 35e29f51a7c3 Author: jjg Date: 2009-09-08 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/35e29f51a7c3 6419701: DefaultFileManager clean up: URI.create 6483788: DefaultFileManager.ZipFileObject.toUri() fails to escape space characters 6501502: JSR 199: FileObject.toUri should return file:///c:/ or file:/c:/ not file://c:/ 6877206: JavaFileObject.toUri returns bogus URI (win) 6877223: tests @ignored because of issues with File.toURI on Windows Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! test/tools/javac/Diagnostics/6769027/tester.properties ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java + test/tools/javac/api/T6483788.java + test/tools/javac/api/T6501502.java + test/tools/javac/api/T6877206.java From jonathan.gibbons at sun.com Tue Sep 8 11:38:59 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 08 Sep 2009 18:38:59 +0000 Subject: [security-dev 01186]: hg: jdk7/tl/langtools: 6879346: files have Windows newlines Message-ID: <20090908183904.4E176E254@hg.openjdk.java.net> Changeset: dd98acd9f717 Author: jjg Date: 2009-09-08 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd98acd9f717 6879346: files have Windows newlines Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testHref/package-list ! test/com/sun/javadoc/testLinkOption/testNewLineInLink/package.html ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testRelativeLinks/pkg/package.html ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testWarnings/pkg/package.html ! test/tools/javah/SubClassConsts.win From gnu_andrew at member.fsf.org Tue Sep 8 11:48:00 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Sep 2009 19:48:00 +0100 Subject: [security-dev 01187]: Re: 6840752: Provide out-of-the-box support for ECC algorithms In-Reply-To: <4A968683.7090105@sun.com> References: <17c6771e0908241226m5c953906qcb34ada4f89c9c5b@mail.gmail.com> <4A968683.7090105@sun.com> Message-ID: <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> 2009/8/27 Vincent Ryan : > Hello Andrew, > > Our original intention was to provide a Java implementation of ECC. > > However due to software patents already granted for ECC we were > constrained in what we could reasonably resource and openly discuss. > > In the end we opted to reuse the NSS code from OpenSolaris (which was > originally developed at Sun Labs and donated to OpenSSL and NSS). > > Although, on many non-Windows platforms, this does result in an existing > system library being replicated in the JDK perhaps that issue can be > solved in future by making use of modules. > > > > Andrew John Hughes wrote: >> With this changeset: >> >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7 >> >> the new ECC was added to OpenJDK. ?When I first read about this, I'd >> assumed we were getting a Java-based implementation. ?The final >> changeset seem to just be an inclusion of the NSS code into the >> OpenJDK codebase, which adds yet another case where a system library >> is replicated internally (the others being libjpeg, libpng, zlib, lcms >> and probably others I've missed). >> >> Is this correct? Were there local modifications to this code as well? >> >> As seems to be common practice with OpenJDK, this changeset just >> appeared with very little, if any, public discussion. > Thanks for your reply, Vincent. I've now had chance to look at the changeset in more detail, including comparing it with the sources from my system NSS, and have a few more questions: * Which version of NSS were these sources pulled from? Running diff -bu on them, and ignoring the additional copyright headers, there are still a large number of changes. I suspect this is because the version is older than my system copy (3.12.3); notably my testing shows it does not exhibit the bug discussed in http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html (which incidentally is still awaiting review). * Why was a new provider used instead of the existing sun.security.pkcs11.SunPKCS11 provider? I noticed this has not be removed, yet it appears to provide duplicate functionality unless I'm mistaken. This does perhaps mean we could fix the issues with this changeset simply by allowing the ec subdirectory to be turned off, but there may be something about the new provider I'm missing. * I notice that a number of algorithms are replaced with NULL. I assume there is some (perhaps legal) reason for this? I'm afraid my current impression of this changeset is that it doesn't help us with packaging OpenJDK for GNU/Linux distributions at all, but instead makes things ten times worse as there is now a stale NSS to contend with. Not only are there the issues with bit rot I alluded to last time, but as you mention in your reply there are legal issues with EC support. Notably, I've found that Fedora doesn't ship any EC support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd have to rip this out in packages for that distribution (and it's dubious whether others should be shipping it). IANAL, so I won't comment further on such issues, but suffice to say this changeset significantly reduces the options for handling NSS support downstream. In contrast, the existing support in 1.6 is almost ideal, once you've discovered how it works; the distro packager can choose whether to enable support or not and they don't have to worry about rotting security code in OpenJDK. Maybe I'm missing something but this makes me think this would have been better as a local addition to Sun's proprietary builds rather than adding it to OpenJDK. I try to be as positive as I can about the OpenJDK project, but I'm sorry to say that changesets like this don't help. I actually find them quite depressing. As I said in my previous email, there appears to have been no discussion of this change; it was merely committed with no public review and appeared in b70. Meanwhile, myself and other external contributors have to spend days trying to get replies to emails to even get a simple bug fix in (I've lost count of how many I still have waiting; there must be at least four or five). That's just not fair and doesn't bode well for a successful community project. Thanks, -- 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 jonathan.gibbons at sun.com Tue Sep 8 11:52:20 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 08 Sep 2009 18:52:20 +0000 Subject: [security-dev 01188]: hg: jdk7/tl/langtools: 6879371: javap does not close internal default file manager Message-ID: <20090908185225.9D5B1E259@hg.openjdk.java.net> Changeset: 261c54b2312e Author: jjg Date: 2009-09-08 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/261c54b2312e 6879371: javap does not close internal default file manager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6879371.java From mandy.chung at sun.com Tue Sep 8 13:12:35 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Tue, 08 Sep 2009 20:12:35 +0000 Subject: [security-dev 01189]: hg: jdk7/tl/jdk: 7 new changesets Message-ID: <20090908201437.B63FAE2D9@hg.openjdk.java.net> Changeset: fdf11ce72e8e Author: mchung Date: 2009-08-06 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fdf11ce72e8e 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions during class-loading Summary: Change findBootstrapClass to return null instead of throwing CNFE if class not found Reviewed-by: alanb, dholmes, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/ClassLoader.c Changeset: 3323e6c925f9 Author: mchung Date: 2009-08-06 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3323e6c925f9 6864028: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Summary: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Reviewed-by: ksrini ! src/share/bin/java.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c Changeset: 1f1c824e6244 Author: mchung Date: 2009-08-24 10:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f1c824e6244 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 799731b1cd03 Author: mchung Date: 2009-08-27 12:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/799731b1cd03 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: dfb5cf81d8cd Author: mchung Date: 2009-09-03 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dfb5cf81d8cd Merge Changeset: b9b7f56bdfa3 Author: mchung Date: 2009-09-04 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b9b7f56bdfa3 Merge Changeset: 466915134131 Author: mchung Date: 2009-09-08 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/466915134131 Merge From jonathan.gibbons at sun.com Tue Sep 8 14:07:28 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 08 Sep 2009 21:07:28 +0000 Subject: [security-dev 01190]: hg: jdk7/tl/langtools: 5093723: REGRESSION: ClassCastException in SingleIndexWriter Message-ID: <20090908210735.49896E2E4@hg.openjdk.java.net> Changeset: ebb6ad5a95bb Author: jjg Date: 2009-09-08 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ebb6ad5a95bb 5093723: REGRESSION: ClassCastException in SingleIndexWriter Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/5093723/DocumentedClass.java + test/com/sun/javadoc/5093723/T5093723.java + test/com/sun/javadoc/5093723/UndocumentedClass.java From jonathan.gibbons at sun.com Tue Sep 8 14:19:13 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 08 Sep 2009 21:19:13 +0000 Subject: [security-dev 01191]: hg: jdk7/tl/langtools: 6709246: ClassCastException in javadoc Message-ID: <20090908211923.6C716E2EB@hg.openjdk.java.net> Changeset: 071a4e36cd87 Author: jjg Date: 2009-09-08 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/071a4e36cd87 6709246: ClassCastException in javadoc Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/tools/javadoc/annotations/missing/Main.java + test/tools/javadoc/annotations/missing/somepackage/MissingAnnotationClass.java From martinrb at google.com Tue Sep 8 16:39:09 2009 From: martinrb at google.com (martinrb at google.com) Date: Tue, 08 Sep 2009 23:39:09 +0000 Subject: [security-dev 01192]: hg: jdk7/tl/jdk: 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit Message-ID: <20090908233956.9A942E308@hg.openjdk.java.net> Changeset: 0d50d40a4a39 Author: martin Date: 2009-09-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d50d40a4a39 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit Summary: Test hotspot/jvmti fix 6850957 using ProcessBuilder test infrastructure Reviewed-by: tbell, dholmes, alanb, ysr ! test/java/lang/ProcessBuilder/Basic.java From sean.mullan at sun.com Wed Sep 9 09:52:58 2009 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Wed, 09 Sep 2009 16:52:58 +0000 Subject: [security-dev 01193]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090909165352.6752BE36B@hg.openjdk.java.net> Changeset: 8252729d51a3 Author: mullan Date: 2009-09-09 09:54 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8252729d51a3 6745437: Add option to only check revocation of end-entity certificate in a chain of certificates 6869739: Cannot check revocation of single certificate without validating the entire chain Reviewed-by: xuelei + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/x509/AccessDescription.java Changeset: 7b85ef3d752e Author: mullan Date: 2009-09-09 09:59 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b85ef3d752e Merge From mstjohns at comcast.net Wed Sep 9 12:47:23 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 09 Sep 2009 15:47:23 -0400 Subject: [security-dev 01194]: PKCS11 and Win X64? Message-ID: <20090909194724.CDA1F11E577@mail.openjdk.java.net> Any idea why the win x64 jdk and jre 6 builds (1.6.0_16) are shipping without the sunpkcs11.jar? The only posted bug I see on this is from 1.5 ( 6571044) and its marked as resolved. I'm in the process of moving over to an x64 system and this is a prelim to doing an x64 build of jdk6. Its possible this is already resolved, but I'm not tracking the build system stuff so it probably got past me. Thanks - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20090909/0b8e79ae/attachment.html From Vincent.Ryan at Sun.COM Wed Sep 9 14:49:45 2009 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Wed, 09 Sep 2009 22:49:45 +0100 Subject: [security-dev 01195]: Re: 6840752: Provide out-of-the-box support for ECC algorithms In-Reply-To: <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> References: <17c6771e0908241226m5c953906qcb34ada4f89c9c5b@mail.gmail.com> <4A968683.7090105@sun.com> <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> Message-ID: <4AA822F9.4010100@sun.com> Hello Andrew, I realize that you, along with others in the Linux community, are less than satisfied with the changeset to provide out-of-the-box support for ECC algorithms. As I mentioned earlier, we were quite constrained in what we could openly discuss before we pushed. However, now that we have pushed I am eager to fix any problems that I've introduced. We wish to reconcile the conflicting demands of including an ECC implementation for platforms without underlying ECC support with the exclusion of the ECC implementation on platforms with underlying ECC support. I'd like to solicit input from security-dev on how best to achieve this. Your proposal to supply an NSS config file for the SunPKCS11 provider is one approach but what about platforms where an ECC-enabled NSS is not present? Andrew John Hughes wrote: > 2009/8/27 Vincent Ryan : >> Hello Andrew, >> >> Our original intention was to provide a Java implementation of ECC. >> >> However due to software patents already granted for ECC we were >> constrained in what we could reasonably resource and openly discuss. >> >> In the end we opted to reuse the NSS code from OpenSolaris (which was >> originally developed at Sun Labs and donated to OpenSSL and NSS). >> >> Although, on many non-Windows platforms, this does result in an existing >> system library being replicated in the JDK perhaps that issue can be >> solved in future by making use of modules. >> >> >> >> Andrew John Hughes wrote: >>> With this changeset: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7 >>> >>> the new ECC was added to OpenJDK. When I first read about this, I'd >>> assumed we were getting a Java-based implementation. The final >>> changeset seem to just be an inclusion of the NSS code into the >>> OpenJDK codebase, which adds yet another case where a system library >>> is replicated internally (the others being libjpeg, libpng, zlib, lcms >>> and probably others I've missed). >>> >>> Is this correct? Were there local modifications to this code as well? >>> >>> As seems to be common practice with OpenJDK, this changeset just >>> appeared with very little, if any, public discussion. > > Thanks for your reply, Vincent. > > I've now had chance to look at the changeset in more detail, including > comparing it with the sources from my system NSS, and have a few more > questions: > > * Which version of NSS were these sources pulled from? Running diff > -bu on them, and ignoring the additional copyright headers, > there are still a large number of changes. I suspect this is > because the version is older than my system copy (3.12.3); notably my > testing shows it does not exhibit the bug discussed in > http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html > (which > incidentally is still awaiting review). The sources were pulled from OpenSolaris 2009.06. > * Why was a new provider used instead of the existing > sun.security.pkcs11.SunPKCS11 provider? I noticed this has not be > removed, yet > it appears to provide duplicate functionality unless I'm mistaken. > This does perhaps mean we could fix the issues with this changeset > simply > by allowing the ec subdirectory to be turned off, but there may be > something about the new provider I'm missing. We introduced the new SunEC provider because we wanted a fast compact ECC implementation that we could ship on all platforms. We have not bundled all of NSS - only its ECC implementation. > * I notice that a number of algorithms are replaced with NULL. I > assume there is some (perhaps legal) reason for this? Which ones? > > I'm afraid my current impression of this changeset is that it doesn't > help us with packaging OpenJDK for GNU/Linux distributions at all, but > instead makes things ten times worse as there is now a stale NSS to > contend with. Not only are there the issues with bit rot I alluded to > last time, but as you mention in your reply there are legal issues > with EC support. Notably, I've found that Fedora doesn't ship any EC > support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd > have to rip this out in packages for that distribution (and it's > dubious whether others should be shipping it). IANAL, so I won't > comment further on such issues, but suffice to say this changeset > significantly reduces the options for handling NSS support downstream. > In contrast, the existing support in 1.6 is almost ideal, once you've > discovered how it works; the distro packager can choose whether to > enable support or not and they don't have to worry about rotting > security code in OpenJDK. Maybe I'm missing something but this makes > me think this would have been better as a local addition to Sun's > proprietary builds rather than adding it to OpenJDK. > > I try to be as positive as I can about the OpenJDK project, but I'm > sorry to say that changesets like this don't help. I actually find > them quite depressing. As I said in my previous email, there appears > to have been no discussion of this change; it was merely committed > with no public review and appeared in b70. Meanwhile, myself and > other external contributors have to spend days trying to get replies > to emails to even get a simple bug fix in (I've lost count of how many > I still have waiting; there must be at least four or five). That's > just not fair and doesn't bode well for a successful community > project. > > Thanks, From lance.andersen at sun.com Wed Sep 9 14:53:09 2009 From: lance.andersen at sun.com (lance.andersen at sun.com) Date: Wed, 09 Sep 2009 21:53:09 +0000 Subject: [security-dev 01196]: hg: jdk7/tl/jdk: 6737212: Fixed javadoc warning messages in RowSet classes Message-ID: <20090909215352.F154BE392@hg.openjdk.java.net> Changeset: f1eb4c28b313 Author: lancea Date: 2009-09-09 20:15 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1eb4c28b313 6737212: Fixed javadoc warning messages in RowSet classes Reviewed-by: darcy ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java From gnu_andrew at member.fsf.org Wed Sep 9 16:14:31 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Sep 2009 00:14:31 +0100 Subject: [security-dev 01197]: Re: 6840752: Provide out-of-the-box support for ECC algorithms In-Reply-To: <4AA822F9.4010100@sun.com> References: <17c6771e0908241226m5c953906qcb34ada4f89c9c5b@mail.gmail.com> <4A968683.7090105@sun.com> <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> <4AA822F9.4010100@sun.com> Message-ID: <17c6771e0909091614m78197ba0mb571a744f526696f@mail.gmail.com> 2009/9/9 Vincent Ryan : > Hello Andrew, > > I realize that you, along with others in the Linux community, are less > than satisfied with the changeset to provide out-of-the-box support for > ECC algorithms. > > As I mentioned earlier, we were quite constrained in what we could > openly discuss before we pushed. However, now that we have pushed I > am eager to fix any problems that I've introduced. > Yes, I can understand that to an extent, but I find it hard to believe that you had to push it before it could even be discussed. Why could the same patch that was pushed not have been posted for public review instead? This seems to be a more general issue. This is endemic behaviour that I've seen from the majority of Sun engineers working on OpenJDK (there are thankfully some exceptions) and I've blogged about this in more detail: http://blog.fuseyism.com/index.php/2009/09/08/im-so-tired/ > We wish to reconcile the conflicting demands of including an ECC > implementation for platforms without underlying ECC support with the > exclusion of the ECC implementation on platforms with underlying ECC > support. I'd like to solicit input from security-dev on how best to > achieve this. > It's good to hear you're open to changing this. There is a third option you've missed; the demand of not wanting ECC support at all. You'll be aware that there are legal issues from your own discussions on this within Sun, and the change in direction that occurred. Not having ECC support needs to be an option as well. The existing ECC implementation already fulfilled two of these demands; it could be enabled on platforms with ECC support but this wasn't the default case. We can make this easier with IcedTea by detecting NSS at build time and auto-generating the configuration if the user wishes. This also can be used to ship it 'out of the box' on distributions if required; all the distro packager has to do is build IcedTea with NSS support enabled and then make their binary depend on it. So the real problem here is that Sun's proprietary builds can't ship it 'out of the box' because they don't know if the system it ends up on will have NSS and, even if it does, where it will be located. I can understand how that's a problem that needs to be fixed, but we need a way of disabling that. If the PKCS11 provider is still suitable, then making building the ec directory would actually be enough: ifndef DISABLE_NSS SUBDIRS += ec endif Job done. A more complex solution is to link against the system NSS instead of the provided C sources. I've managed to do this with the following change: diff -r 7a23bfc44c92 make/sun/security/ec/Makefile --- a/make/sun/security/ec/Makefile Tue Sep 08 18:03:43 2009 +0100 +++ b/make/sun/security/ec/Makefile Wed Sep 09 23:50:24 2009 +0100 @@ -153,7 +153,9 @@ # # C and C++ files # +ifndef USE_SYSTEM_NSS include FILES_c.gmk +endif FILES_cpp = ECC_JNI.cpp @@ -185,6 +187,11 @@ OTHER_LDLIBS += $(JVMLIB) else OTHER_LDLIBS = -ldl $(JVMLIB) $(LIBCXX) + ifdef USE_SYSTEM_NSS + OTHER_LDLIBS += -Wl,-rpath $(SYSTEM_NSS_DIR) -Wl,-rpath $(SYSTEM_NSPR_DIR) \ + -L$(SYSTEM_NSS_DIR) -L$(SYSTEM_NSPR_DIR) -lnssutil3 -lnss3 \ + -lplds4 -lplc4 -lnspr4 -lsoftokn -lfreebl + endif endif include $(BUILDDIR)/common/Mapfile-vers.gmk but unfortunately, while the resulting sunecc library is dynamically linked against NSS, it causes HotSpot to segfault in sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[J. I'm still looking into this, I assume there is either some mismatch in the versions of NSS or local changes in the Sun copy. As you say, only part of the library was imported into OpenJDK; does this mean that the JNI code is not using published interfaces for NSS? > Your proposal to supply an NSS config file for the SunPKCS11 provider > is one approach but what about platforms where an ECC-enabled NSS is > not present? > > It's only really an idea that works where we have an autoconf wrapper to detect NSS at build time, and which also allows it to be disabled. The patch to IcedTea automatically finds out where NSS is installed, via pkg-config, and writes the config file based on that. I don't know of a portable way of doing that in OpenJDK's makefiles as pkg-config won't be available on all platforms. snip... > >> ?* Which version of NSS were these sources pulled from? ?Running diff >> -bu on them, and ignoring the additional copyright headers, >> ?there are still a large number of changes. ?I suspect this is >> because the version is older than my system copy (3.12.3); notably my >> ?testing shows it does not exhibit the bug discussed in >> >> http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html >> (which >> ?incidentally is still awaiting review). > > The sources were pulled from OpenSolaris 2009.06. > Ok, so which version of NSS does that have? > >> ?* Why was a new provider used instead of the existing >> sun.security.pkcs11.SunPKCS11 provider? ?I noticed this has not be >> removed, yet >> ?it appears to provide duplicate functionality unless I'm mistaken. >> This does perhaps mean we could fix the issues with this changeset >> simply >> ?by allowing the ec subdirectory to be turned off, but there may be >> something about the new provider I'm missing. > > We introduced the new SunEC provider because we wanted a fast compact > ECC implementation that we could ship on all platforms. We have not > bundled all of NSS - only its ECC implementation. > Yeah I noticed that. I suppose the big question is how interchangable are SunEC and PKCS11? Could we just turn off SunEC, given we already have NSS support via PKCS11? If so, just making SunEC optional would solve this IMO. > > >> ?* I notice that a number of algorithms are replaced with NULL. ?I >> assume there is some (perhaps legal) reason for this? > > Which ones? > This is the change I'm referring to: /* mapping between ECCurveName enum and pointers to ECCurveParams */ static const ECCurveParams *ecCurve_map[] = { NULL, /* ECCurve_noName */ - &ecCurve_NIST_P192, /* ECCurve_NIST_P192 */ - &ecCurve_NIST_P224, /* ECCurve_NIST_P224 */ + NULL, /* ECCurve_NIST_P192 */ + NULL, /* ECCurve_NIST_P224 */ &ecCurve_NIST_P256, /* ECCurve_NIST_P256 */ &ecCurve_NIST_P384, /* ECCurve_NIST_P384 */ &ecCurve_NIST_P521, /* ECCurve_NIST_P521 */ - &ecCurve_NIST_K163, /* ECCurve_NIST_K163 */ - &ecCurve_NIST_B163, /* ECCurve_NIST_B163 */ - &ecCurve_NIST_K233, /* ECCurve_NIST_K233 */ - &ecCurve_NIST_B233, /* ECCurve_NIST_B233 */ - &ecCurve_NIST_K283, /* ECCurve_NIST_K283 */ - &ecCurve_NIST_B283, /* ECCurve_NIST_B283 */ - &ecCurve_NIST_K409, /* ECCurve_NIST_K409 */ - &ecCurve_NIST_B409, /* ECCurve_NIST_B409 */ - &ecCurve_NIST_K571, /* ECCurve_NIST_K571 */ - &ecCurve_NIST_B571, /* ECCurve_NIST_B571 */ - &ecCurve_X9_62_PRIME_192V2, /* ECCurve_X9_62_PRIME_192V2 */ - &ecCurve_X9_62_PRIME_192V3, /* ECCurve_X9_62_PRIME_192V3 */ - &ecCurve_X9_62_PRIME_239V1, /* ECCurve_X9_62_PRIME_239V1 */ - &ecCurve_X9_62_PRIME_239V2, /* ECCurve_X9_62_PRIME_239V2 */ - &ecCurve_X9_62_PRIME_239V3, /* ECCurve_X9_62_PRIME_239V3 */ - &ecCurve_X9_62_CHAR2_PNB163V1, /* ECCurve_X9_62_CHAR2_PNB163V1 */ - &ecCurve_X9_62_CHAR2_PNB163V2, /* ECCurve_X9_62_CHAR2_PNB163V2 */ - &ecCurve_X9_62_CHAR2_PNB163V3, /* ECCurve_X9_62_CHAR2_PNB163V3 */ - &ecCurve_X9_62_CHAR2_PNB176V1, /* ECCurve_X9_62_CHAR2_PNB176V1 */ - &ecCurve_X9_62_CHAR2_TNB191V1, /* ECCurve_X9_62_CHAR2_TNB191V1 */ - &ecCurve_X9_62_CHAR2_TNB191V2, /* ECCurve_X9_62_CHAR2_TNB191V2 */ - &ecCurve_X9_62_CHAR2_TNB191V3, /* ECCurve_X9_62_CHAR2_TNB191V3 */ - &ecCurve_X9_62_CHAR2_PNB208W1, /* ECCurve_X9_62_CHAR2_PNB208W1 */ - &ecCurve_X9_62_CHAR2_TNB239V1, /* ECCurve_X9_62_CHAR2_TNB239V1 */ - &ecCurve_X9_62_CHAR2_TNB239V2, /* ECCurve_X9_62_CHAR2_TNB239V2 */ - &ecCurve_X9_62_CHAR2_TNB239V3, /* ECCurve_X9_62_CHAR2_TNB239V3 */ - &ecCurve_X9_62_CHAR2_PNB272W1, /* ECCurve_X9_62_CHAR2_PNB272W1 */ - &ecCurve_X9_62_CHAR2_PNB304W1, /* ECCurve_X9_62_CHAR2_PNB304W1 */ - &ecCurve_X9_62_CHAR2_TNB359V1, /* ECCurve_X9_62_CHAR2_TNB359V1 */ - &ecCurve_X9_62_CHAR2_PNB368W1, /* ECCurve_X9_62_CHAR2_PNB368W1 */ - &ecCurve_X9_62_CHAR2_TNB431R1, /* ECCurve_X9_62_CHAR2_TNB431R1 */ - &ecCurve_SECG_PRIME_112R1, /* ECCurve_SECG_PRIME_112R1 */ - &ecCurve_SECG_PRIME_112R2, /* ECCurve_SECG_PRIME_112R2 */ - &ecCurve_SECG_PRIME_128R1, /* ECCurve_SECG_PRIME_128R1 */ - &ecCurve_SECG_PRIME_128R2, /* ECCurve_SECG_PRIME_128R2 */ - &ecCurve_SECG_PRIME_160K1, /* ECCurve_SECG_PRIME_160K1 */ - &ecCurve_SECG_PRIME_160R1, /* ECCurve_SECG_PRIME_160R1 */ - &ecCurve_SECG_PRIME_160R2, /* ECCurve_SECG_PRIME_160R2 */ - &ecCurve_SECG_PRIME_192K1, /* ECCurve_SECG_PRIME_192K1 */ - &ecCurve_SECG_PRIME_224K1, /* ECCurve_SECG_PRIME_224K1 */ - &ecCurve_SECG_PRIME_256K1, /* ECCurve_SECG_PRIME_256K1 */ - &ecCurve_SECG_CHAR2_113R1, /* ECCurve_SECG_CHAR2_113R1 */ - &ecCurve_SECG_CHAR2_113R2, /* ECCurve_SECG_CHAR2_113R2 */ - &ecCurve_SECG_CHAR2_131R1, /* ECCurve_SECG_CHAR2_131R1 */ - &ecCurve_SECG_CHAR2_131R2, /* ECCurve_SECG_CHAR2_131R2 */ - &ecCurve_SECG_CHAR2_163R1, /* ECCurve_SECG_CHAR2_163R1 */ - &ecCurve_SECG_CHAR2_193R1, /* ECCurve_SECG_CHAR2_193R1 */ - &ecCurve_SECG_CHAR2_193R2, /* ECCurve_SECG_CHAR2_193R2 */ - &ecCurve_SECG_CHAR2_239K1, /* ECCurve_SECG_CHAR2_239K1 */ - &ecCurve_WTLS_1, /* ECCurve_WTLS_1 */ - &ecCurve_WTLS_8, /* ECCurve_WTLS_8 */ - &ecCurve_WTLS_9, /* ECCurve_WTLS_9 */ + NULL, /* ECCurve_NIST_K163 */ + NULL, /* ECCurve_NIST_B163 */ + NULL, /* ECCurve_NIST_K233 */ + NULL, /* ECCurve_NIST_B233 */ + NULL, /* ECCurve_NIST_K283 */ + NULL, /* ECCurve_NIST_B283 */ + NULL, /* ECCurve_NIST_K409 */ + NULL, /* ECCurve_NIST_B409 */ + NULL, /* ECCurve_NIST_K571 */ + NULL, /* ECCurve_NIST_B571 */ + NULL, /* ECCurve_X9_62_PRIME_192V2 */ + NULL, /* ECCurve_X9_62_PRIME_192V3 */ + NULL, /* ECCurve_X9_62_PRIME_239V1 */ + NULL, /* ECCurve_X9_62_PRIME_239V2 */ + NULL, /* ECCurve_X9_62_PRIME_239V3 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB163V1 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB163V2 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB163V3 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB176V1 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB191V1 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB191V2 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB191V3 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB208W1 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB239V1 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB239V2 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB239V3 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB272W1 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB304W1 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB359V1 */ + NULL, /* ECCurve_X9_62_CHAR2_PNB368W1 */ + NULL, /* ECCurve_X9_62_CHAR2_TNB431R1 */ + NULL, /* ECCurve_SECG_PRIME_112R1 */ + NULL, /* ECCurve_SECG_PRIME_112R2 */ + NULL, /* ECCurve_SECG_PRIME_128R1 */ + NULL, /* ECCurve_SECG_PRIME_128R2 */ + NULL, /* ECCurve_SECG_PRIME_160K1 */ + NULL, /* ECCurve_SECG_PRIME_160R1 */ + NULL, /* ECCurve_SECG_PRIME_160R2 */ + NULL, /* ECCurve_SECG_PRIME_192K1 */ + NULL, /* ECCurve_SECG_PRIME_224K1 */ + NULL, /* ECCurve_SECG_PRIME_256K1 */ + NULL, /* ECCurve_SECG_CHAR2_113R1 */ + NULL, /* ECCurve_SECG_CHAR2_113R2 */ + NULL, /* ECCurve_SECG_CHAR2_131R1 */ + NULL, /* ECCurve_SECG_CHAR2_131R2 */ + NULL, /* ECCurve_SECG_CHAR2_163R1 */ + NULL, /* ECCurve_SECG_CHAR2_193R1 */ + NULL, /* ECCurve_SECG_CHAR2_193R2 */ + NULL, /* ECCurve_SECG_CHAR2_239K1 */ + NULL, /* ECCurve_WTLS_1 */ + NULL, /* ECCurve_WTLS_8 */ + NULL, /* ECCurve_WTLS_9 */ NULL /* ECCurve_pastLastCurve */ }; It could be a NSS version issue, but seems more deliberate to me. It leaves three curves: &ecCurve_NIST_P256, /* ECCurve_NIST_P256 */ &ecCurve_NIST_P384, /* ECCurve_NIST_P384 */ &ecCurve_NIST_P521, /* ECCurve_NIST_P521 */ > >> >> I'm afraid my current impression of this changeset is that it doesn't >> help us with packaging OpenJDK for GNU/Linux distributions at all, but >> instead makes things ten times worse as there is now a stale NSS to >> contend with. ?Not only are there the issues with bit rot I alluded to >> last time, but as you mention in your reply there are legal issues >> with EC support. ?Notably, I've found that Fedora doesn't ship any EC >> support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd >> have to rip this out in packages for that distribution (and it's >> dubious whether others should be shipping it). ?IANAL, so I won't >> comment further on such issues, but suffice to say this changeset >> significantly reduces the options for handling NSS support downstream. >> ?In contrast, the existing support in 1.6 is almost ideal, once you've >> discovered how it works; the distro packager can choose whether to >> enable support or not and they don't have to worry about rotting >> security code in OpenJDK. ?Maybe I'm missing something but this makes >> me think this would have been better as a local addition to Sun's >> proprietary builds rather than adding it to OpenJDK. >> >> I try to be as positive as I can about the OpenJDK project, but I'm >> sorry to say that changesets like this don't help. ?I actually find >> them quite depressing. ?As I said in my previous email, there appears >> to have been no discussion of this change; it was merely committed >> with no public review and appeared in b70. ?Meanwhile, myself and >> other external contributors have to spend days trying to get replies >> to emails to even get a simple bug fix in (I've lost count of how many >> I still have waiting; there must be at least four or five). ?That's >> just not fair and doesn't bode well for a successful community >> project. >> >> Thanks, > > Cheers, -- 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 Wed Sep 9 17:05:13 2009 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Wed, 09 Sep 2009 17:05:13 -0700 Subject: [security-dev 01198]: Re: PKCS11 and Win X64? In-Reply-To: <20090909194724.CDA1F11E577@mail.openjdk.java.net> References: <20090909194724.CDA1F11E577@mail.openjdk.java.net> Message-ID: <4AA842B9.7040505@sun.com> Hi Michael, In JDK6, the primary reason we did not ship a win64 version of the SunPKCS11 provider is that we did not have access to any PKCS#11 implementation to test with on win64. We did not want to ship something that could not be tested at all and could potentially be DOA. I looked for a bugid, but don't see one offhand. It shouldn't be too hard to enable such a build. Brad Michael StJohns wrote: > Any idea why the win x64 jdk and jre 6 builds (1.6.0_16) are shipping > without the sunpkcs11.jar? The only posted bug I see on this is from 1.5 ( > > > 6571044) and its marked as resolved. > > I'm in the process of moving over to an x64 system and this is a > prelim to doing an x64 build of jdk6. Its possible this is already > resolved, but I'm not tracking the build system stuff so it probably > got past me. > > Thanks - Mike > From mstjohns at comcast.net Wed Sep 9 17:53:59 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 09 Sep 2009 20:53:59 -0400 Subject: [security-dev 01199]: Re: PKCS11 and Win X64? In-Reply-To: <4AA842B9.7040505@sun.com> References: <20090909194724.CDA1F11E577@mail.openjdk.java.net> <4AA842B9.7040505@sun.com> Message-ID: <20090910005402.AAB7011ECC1@mail.openjdk.java.net> That makes sense - but was a surprise. Let me see if I can get one of the companies I work with to contribute their simulator - not to be shipped, but to be tested against. The simulator runs at 32bits, but the pkcs11 library that talks to the simulator has builds for win 32/64 linux 32/64 and Solaris. Mike At 08:05 PM 9/9/2009, Brad Wetmore wrote: >Hi Michael, > >In JDK6, the primary reason we did not ship a win64 version of the SunPKCS11 provider is that we did not have access to any PKCS#11 implementation to test with on win64. We did not want to ship something that could not be tested at all and could potentially be DOA. > >I looked for a bugid, but don't see one offhand. > >It shouldn't be too hard to enable such a build. > >Brad > > >Michael StJohns wrote: >>Any idea why the win x64 jdk and jre 6 builds (1.6.0_16) are shipping without the sunpkcs11.jar? The only posted bug I see on this is from 1.5 ( >> >> 6571044) and its marked as resolved. >> I'm in the process of moving over to an x64 system and this is a >> prelim to doing an x64 build of jdk6. Its possible this is already >> resolved, but I'm not tracking the build system stuff so it probably >> got past me. >> Thanks - Mike From gnu_andrew at member.fsf.org Thu Sep 10 10:54:51 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Sep 2009 18:54:51 +0100 Subject: [security-dev 01200]: Re: PKCS11 and Win X64? In-Reply-To: <20090910005402.AAB7011ECC1@mail.openjdk.java.net> References: <20090909194724.CDA1F11E577@mail.openjdk.java.net> <4AA842B9.7040505@sun.com> <20090910005402.AAB7011ECC1@mail.openjdk.java.net> Message-ID: <17c6771e0909101054r5b714cb3ld593805acf8749e6@mail.gmail.com> 2009/9/10 Michael StJohns : > That makes sense - but was a surprise. ?Let me see if I can get one of the companies I work with to contribute their simulator - not to be shipped, but to be tested against. ?The simulator runs at 32bits, but the pkcs11 library that talks to the simulator has builds for win 32/64 linux 32/64 and Solaris. > This OpenJDK7 changeset might help in the future on Windows x86_64: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7 It would be nice if it did help someone. It doesn't help us with IcedTea. Interesting Windows on x86_64 seems to be one of the builds that's always tested, whereas GNU/Linux on x86_64 isn't -- strange given the latter is older and far more widespread. See http://mail.openjdk.java.net/pipermail/jdk7-dev > Mike > > > > At 08:05 PM 9/9/2009, Brad Wetmore wrote: >>Hi Michael, >> >>In JDK6, the primary reason we did not ship a win64 version of the SunPKCS11 provider is that we did not have access to any PKCS#11 implementation to test with on win64. We did not want to ship something that could not be tested at all and could potentially be DOA. >> >>I looked for a bugid, but don't see one offhand. >> >>It shouldn't be too hard to enable such a build. >> >>Brad >> >> >>Michael StJohns wrote: >>>Any idea why the win x64 jdk and jre 6 builds ?(1.6.0_16) are shipping without the sunpkcs11.jar? ?The only posted bug I see on this is from 1.5 ( >>> >>> ? ?6571044) and its marked as resolved. >>> ? ?I'm in the process of moving over to an x64 system and this is a >>> ? ?prelim to doing an x64 build of ?jdk6. ?Its possible this is already >>> ? ?resolved, but I'm not tracking the build system stuff so it probably >>> ? ?got past me. >>> ? ?Thanks - Mike > > > -- 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 gnu_andrew at member.fsf.org Thu Sep 10 13:02:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Sep 2009 21:02:39 +0100 Subject: [security-dev 01201]: Re: 6840752: Provide out-of-the-box support for ECC algorithms In-Reply-To: <17c6771e0909091614m78197ba0mb571a744f526696f@mail.gmail.com> References: <17c6771e0908241226m5c953906qcb34ada4f89c9c5b@mail.gmail.com> <4A968683.7090105@sun.com> <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> <4AA822F9.4010100@sun.com> <17c6771e0909091614m78197ba0mb571a744f526696f@mail.gmail.com> Message-ID: <17c6771e0909101302u47dafb43gbf85cf2b9c29ded9@mail.gmail.com> 2009/9/10 Andrew John Hughes : > 2009/9/9 Vincent Ryan : >> Hello Andrew, >> >> I realize that you, along with others in the Linux community, are less >> than satisfied with the changeset to provide out-of-the-box support for >> ECC algorithms. >> >> As I mentioned earlier, we were quite constrained in what we could >> openly discuss before we pushed. However, now that we have pushed I >> am eager to fix any problems that I've introduced. >> > > Yes, I can understand that to an extent, but I find it hard to believe > that you had to push it before it could even be discussed. ?Why could > the same patch that was pushed not have been posted for public review > instead? > > This seems to be a more general issue. ?This is endemic behaviour that > I've seen from the majority of Sun engineers working on OpenJDK (there > are thankfully some exceptions) and I've blogged about this in more > detail: http://blog.fuseyism.com/index.php/2009/09/08/im-so-tired/ > >> We wish to reconcile the conflicting demands of including an ECC >> implementation for platforms without underlying ECC support with the >> exclusion of the ECC implementation on platforms with underlying ECC >> support. I'd like to solicit input from security-dev on how best to >> achieve this. >> > > It's good to hear you're open to changing this. ?There is a third > option you've missed; the demand of not wanting ECC support at all. > You'll be aware that there are legal issues from your own discussions > on this within Sun, and the change in direction that occurred. ?Not > having ECC support needs to be an option as well. > > The existing ECC implementation already fulfilled two of these > demands; it could be enabled on platforms with ECC support but this > wasn't the default case. ?We can make this easier with IcedTea by > detecting NSS at build time and auto-generating the configuration if > the user wishes. ?This also can be used to ship it 'out of the box' on > distributions if required; all the distro packager has to do is build > IcedTea with NSS support enabled and then make their binary depend on > it. > > So the real problem here is that Sun's proprietary builds can't ship > it 'out of the box' because they don't know if the system it ends up > on will have NSS and, even if it does, where it will be located. ?I > can understand how that's a problem that needs to be fixed, but we > need a way of disabling that. ?If the PKCS11 provider is still > suitable, then making building the ec directory would actually be > enough: > > ifndef DISABLE_NSS > ?SUBDIRS += ec > endif > > Job done. ?A more complex solution is to link against the system NSS > instead of the provided C sources. ?I've managed to do this with the > following change: > > diff -r 7a23bfc44c92 make/sun/security/ec/Makefile > --- a/make/sun/security/ec/Makefile ? ? Tue Sep 08 18:03:43 2009 +0100 > +++ b/make/sun/security/ec/Makefile ? ? Wed Sep 09 23:50:24 2009 +0100 > @@ -153,7 +153,9 @@ > ? # > ? # C and C++ files > ? # > +ifndef USE_SYSTEM_NSS > ? include FILES_c.gmk > +endif > > ? FILES_cpp = ECC_JNI.cpp > > @@ -185,6 +187,11 @@ > ? ? OTHER_LDLIBS += $(JVMLIB) > ? else > ? ? OTHER_LDLIBS = -ldl $(JVMLIB) $(LIBCXX) > + ? ?ifdef USE_SYSTEM_NSS > + ? ? ?OTHER_LDLIBS += -Wl,-rpath $(SYSTEM_NSS_DIR) -Wl,-rpath > $(SYSTEM_NSPR_DIR) \ > + ? ? ? ?-L$(SYSTEM_NSS_DIR) -L$(SYSTEM_NSPR_DIR) -lnssutil3 -lnss3 \ > + ? ? ? ?-lplds4 -lplc4 -lnspr4 -lsoftokn -lfreebl > + ? ?endif > ? endif > > ? include $(BUILDDIR)/common/Mapfile-vers.gmk > > but unfortunately, while the resulting sunecc library is dynamically > linked against NSS, it causes HotSpot to segfault in > sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[J. ?I'm > still looking into this, I assume there is either some mismatch in the > versions of NSS or local changes in the Sun copy. ?As you say, only > part of the library was imported into OpenJDK; does this mean that the > JNI code is not using published interfaces for NSS? > >> Your proposal to supply an NSS config file for the SunPKCS11 provider >> is one approach but what about platforms where an ECC-enabled NSS is >> not present? >> >> > > It's only really an idea that works where we have an autoconf wrapper > to detect NSS at build time, and which also allows it to be disabled. > The patch to IcedTea automatically finds out where NSS is installed, > via pkg-config, and writes the config file based on that. ?I don't > know of a portable way of doing that in OpenJDK's makefiles as > pkg-config won't be available on all platforms. > > snip... > >> >>> ?* Which version of NSS were these sources pulled from? ?Running diff >>> -bu on them, and ignoring the additional copyright headers, >>> ?there are still a large number of changes. ?I suspect this is >>> because the version is older than my system copy (3.12.3); notably my >>> ?testing shows it does not exhibit the bug discussed in >>> >>> http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html >>> (which >>> ?incidentally is still awaiting review). >> >> The sources were pulled from OpenSolaris 2009.06. >> > > Ok, so which version of NSS does that have? > >> >>> ?* Why was a new provider used instead of the existing >>> sun.security.pkcs11.SunPKCS11 provider? ?I noticed this has not be >>> removed, yet >>> ?it appears to provide duplicate functionality unless I'm mistaken. >>> This does perhaps mean we could fix the issues with this changeset >>> simply >>> ?by allowing the ec subdirectory to be turned off, but there may be >>> something about the new provider I'm missing. >> >> We introduced the new SunEC provider because we wanted a fast compact >> ECC implementation that we could ship on all platforms. We have not >> bundled all of NSS - only its ECC implementation. >> > > Yeah I noticed that. ?I suppose the big question is how interchangable > are SunEC and PKCS11? ?Could we just turn off SunEC, given we already > have NSS support via PKCS11? ?If so, just making SunEC optional would > solve this IMO. > >> >> >>> ?* I notice that a number of algorithms are replaced with NULL. ?I >>> assume there is some (perhaps legal) reason for this? >> >> Which ones? >> > > This is the change I'm referring to: > > /* mapping between ECCurveName enum and pointers to ECCurveParams */ > ?static const ECCurveParams *ecCurve_map[] = { > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ECCurve_noName */ > - ? ?&ecCurve_NIST_P192, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P192 */ > - ? ?&ecCurve_NIST_P224, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P224 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_P192 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_P224 */ > ? ? &ecCurve_NIST_P256, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P256 */ > ? ? &ecCurve_NIST_P384, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P384 */ > ? ? &ecCurve_NIST_P521, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P521 */ > - ? ?&ecCurve_NIST_K163, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K163 */ > - ? ?&ecCurve_NIST_B163, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B163 */ > - ? ?&ecCurve_NIST_K233, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K233 */ > - ? ?&ecCurve_NIST_B233, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B233 */ > - ? ?&ecCurve_NIST_K283, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K283 */ > - ? ?&ecCurve_NIST_B283, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B283 */ > - ? ?&ecCurve_NIST_K409, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K409 */ > - ? ?&ecCurve_NIST_B409, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B409 */ > - ? ?&ecCurve_NIST_K571, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K571 */ > - ? ?&ecCurve_NIST_B571, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B571 */ > - ? ?&ecCurve_X9_62_PRIME_192V2, ? ? ? ? /* ECCurve_X9_62_PRIME_192V2 */ > - ? ?&ecCurve_X9_62_PRIME_192V3, ? ? ? ? /* ECCurve_X9_62_PRIME_192V3 */ > - ? ?&ecCurve_X9_62_PRIME_239V1, ? ? ? ? /* ECCurve_X9_62_PRIME_239V1 */ > - ? ?&ecCurve_X9_62_PRIME_239V2, ? ? ? ? /* ECCurve_X9_62_PRIME_239V2 */ > - ? ?&ecCurve_X9_62_PRIME_239V3, ? ? ? ? /* ECCurve_X9_62_PRIME_239V3 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB163V1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB163V1 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB163V2, ? ? ?/* ECCurve_X9_62_CHAR2_PNB163V2 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB163V3, ? ? ?/* ECCurve_X9_62_CHAR2_PNB163V3 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB176V1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB176V1 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB191V1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB191V1 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB191V2, ? ? ?/* ECCurve_X9_62_CHAR2_TNB191V2 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB191V3, ? ? ?/* ECCurve_X9_62_CHAR2_TNB191V3 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB208W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB208W1 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB239V1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB239V1 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB239V2, ? ? ?/* ECCurve_X9_62_CHAR2_TNB239V2 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB239V3, ? ? ?/* ECCurve_X9_62_CHAR2_TNB239V3 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB272W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB272W1 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB304W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB304W1 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB359V1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB359V1 */ > - ? ?&ecCurve_X9_62_CHAR2_PNB368W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB368W1 */ > - ? ?&ecCurve_X9_62_CHAR2_TNB431R1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB431R1 */ > - ? ?&ecCurve_SECG_PRIME_112R1, ? ? ? ? ?/* ECCurve_SECG_PRIME_112R1 */ > - ? ?&ecCurve_SECG_PRIME_112R2, ? ? ? ? ?/* ECCurve_SECG_PRIME_112R2 */ > - ? ?&ecCurve_SECG_PRIME_128R1, ? ? ? ? ?/* ECCurve_SECG_PRIME_128R1 */ > - ? ?&ecCurve_SECG_PRIME_128R2, ? ? ? ? ?/* ECCurve_SECG_PRIME_128R2 */ > - ? ?&ecCurve_SECG_PRIME_160K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_160K1 */ > - ? ?&ecCurve_SECG_PRIME_160R1, ? ? ? ? ?/* ECCurve_SECG_PRIME_160R1 */ > - ? ?&ecCurve_SECG_PRIME_160R2, ? ? ? ? ?/* ECCurve_SECG_PRIME_160R2 */ > - ? ?&ecCurve_SECG_PRIME_192K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_192K1 */ > - ? ?&ecCurve_SECG_PRIME_224K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_224K1 */ > - ? ?&ecCurve_SECG_PRIME_256K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_256K1 */ > - ? ?&ecCurve_SECG_CHAR2_113R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_113R1 */ > - ? ?&ecCurve_SECG_CHAR2_113R2, ? ? ? ? ?/* ECCurve_SECG_CHAR2_113R2 */ > - ? ?&ecCurve_SECG_CHAR2_131R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_131R1 */ > - ? ?&ecCurve_SECG_CHAR2_131R2, ? ? ? ? ?/* ECCurve_SECG_CHAR2_131R2 */ > - ? ?&ecCurve_SECG_CHAR2_163R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_163R1 */ > - ? ?&ecCurve_SECG_CHAR2_193R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_193R1 */ > - ? ?&ecCurve_SECG_CHAR2_193R2, ? ? ? ? ?/* ECCurve_SECG_CHAR2_193R2 */ > - ? ?&ecCurve_SECG_CHAR2_239K1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_239K1 */ > - ? ?&ecCurve_WTLS_1, ? ? ? ? ? ? ? ? ? ?/* ECCurve_WTLS_1 */ > - ? ?&ecCurve_WTLS_8, ? ? ? ? ? ? ? ? ? ?/* ECCurve_WTLS_8 */ > - ? ?&ecCurve_WTLS_9, ? ? ? ? ? ? ? ? ? ?/* ECCurve_WTLS_9 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K163 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B163 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K233 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B233 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K283 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B283 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K409 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B409 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K571 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B571 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_192V2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_192V3 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_239V1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_239V2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_239V3 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB163V1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB163V2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB163V3 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB176V1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB191V1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB191V2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB191V3 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB208W1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB239V1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB239V2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB239V3 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB272W1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB304W1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB359V1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB368W1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB431R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_112R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_112R2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_128R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_128R2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_160K1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_160R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_160R2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_192K1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_224K1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_256K1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_113R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_113R2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_131R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_131R2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_163R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_193R1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_193R2 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_239K1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_WTLS_1 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_WTLS_8 */ > + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_WTLS_9 */ > ? ? NULL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* ECCurve_pastLastCurve */ > ?}; > > > It could be a NSS version issue, but seems more deliberate to me. > It leaves three curves: > ? ? &ecCurve_NIST_P256, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P256 */ > ? ? &ecCurve_NIST_P384, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P384 */ > ? ? &ecCurve_NIST_P521, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P521 */ > >> >>> >>> I'm afraid my current impression of this changeset is that it doesn't >>> help us with packaging OpenJDK for GNU/Linux distributions at all, but >>> instead makes things ten times worse as there is now a stale NSS to >>> contend with. ?Not only are there the issues with bit rot I alluded to >>> last time, but as you mention in your reply there are legal issues >>> with EC support. ?Notably, I've found that Fedora doesn't ship any EC >>> support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd >>> have to rip this out in packages for that distribution (and it's >>> dubious whether others should be shipping it). ?IANAL, so I won't >>> comment further on such issues, but suffice to say this changeset >>> significantly reduces the options for handling NSS support downstream. >>> ?In contrast, the existing support in 1.6 is almost ideal, once you've >>> discovered how it works; the distro packager can choose whether to >>> enable support or not and they don't have to worry about rotting >>> security code in OpenJDK. ?Maybe I'm missing something but this makes >>> me think this would have been better as a local addition to Sun's >>> proprietary builds rather than adding it to OpenJDK. >>> >>> I try to be as positive as I can about the OpenJDK project, but I'm >>> sorry to say that changesets like this don't help. ?I actually find >>> them quite depressing. ?As I said in my previous email, there appears >>> to have been no discussion of this change; it was merely committed >>> with no public review and appeared in b70. ?Meanwhile, myself and >>> other external contributors have to spend days trying to get replies >>> to emails to even get a simple bug fix in (I've lost count of how many >>> I still have waiting; there must be at least four or five). ?That's >>> just not fair and doesn't bode well for a successful community >>> project. >>> >>> Thanks, >> >> > > Cheers, > -- > 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 > I've added this changeset: http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/2a1a7fb44226 to the IcedTea project's JDK7 forest to solve this issue. If it looks ok, then give me a bug ID and I'll push it to tl-gate. -- 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 xueming.shen at sun.com Fri Sep 11 16:45:15 2009 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Fri, 11 Sep 2009 23:45:15 +0000 Subject: [security-dev 01202]: hg: jdk7/tl/jdk: 6881337: ZipEntry.setComment() was accidentally changed back to old spec/impl in jdk7-b64 Message-ID: <20090911234603.9E71112044@hg.openjdk.java.net> Changeset: 46406871599c Author: sherman Date: 2009-09-11 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/46406871599c 6881337: ZipEntry.setComment() was accidentally changed back to old spec/impl in jdk7-b64 Summary: restored the correct spec and implementation of setComment Reviewed-by: martin ! src/share/classes/java/util/zip/ZipEntry.java From martinrb at google.com Sat Sep 12 15:32:32 2009 From: martinrb at google.com (martinrb at google.com) Date: Sat, 12 Sep 2009 22:32:32 +0000 Subject: [security-dev 01203]: hg: jdk7/tl/jdk: 6881442: (reflect) Race condition in Class.getName() Message-ID: <20090912223309.8736A12067@hg.openjdk.java.net> Changeset: 020a0fed38c9 Author: martin Date: 2009-09-12 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/020a0fed38c9 6881442: (reflect) Race condition in Class.getName() Summary: only read "name" field racily once Reviewed-by: darcy ! src/share/classes/java/lang/Class.java From alan.bateman at sun.com Mon Sep 14 10:03:40 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Mon, 14 Sep 2009 17:03:40 +0000 Subject: [security-dev 01204]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090914170432.B75AF1210B@hg.openjdk.java.net> Changeset: 060c4c7082ef Author: alanb Date: 2009-09-14 15:29 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/060c4c7082ef 6529758: JVMTI Waiters demo crashes. Double free. Reviewed-by: ohair, tbell ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp Changeset: aac01ec2cec4 Author: alanb Date: 2009-09-14 17:47 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aac01ec2cec4 6876541: (file) Files.walkFileTree(...): no SecurityException if read access to the starting file is denied Reviewed-by: chegar ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/denyAll.policy + test/java/nio/file/Files/grantAll.policy + test/java/nio/file/Files/grantTopOnly.policy From kevin.walls at sun.com Mon Sep 14 12:57:06 2009 From: kevin.walls at sun.com (kevin.walls at sun.com) Date: Mon, 14 Sep 2009 19:57:06 +0000 Subject: [security-dev 01205]: hg: jdk7/tl/jdk: 6842838: 64-bit failure in handling invalid manifest in launcher. Message-ID: <20090914195748.B8D6712176@hg.openjdk.java.net> Changeset: eb19c5dc52bf Author: kevinw Date: 2009-09-14 20:55 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb19c5dc52bf 6842838: 64-bit failure in handling invalid manifest in launcher. Summary: Don't compare with hard-coded 32-bit -1 when checking zip fields. Reviewed-by: ksrini ! src/share/bin/parse_manifest.c + test/tools/launcher/6842838/CreateBadJar.java + test/tools/launcher/6842838/Test6842838.sh From mandy.chung at sun.com Mon Sep 14 13:44:22 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Mon, 14 Sep 2009 20:44:22 +0000 Subject: [security-dev 01206]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090914204454.07EA912181@hg.openjdk.java.net> Changeset: c7e469ae3edb Author: mchung Date: 2009-09-14 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c7e469ae3edb 6878481: Add performance counters in the JDK Summary: Added new performance counters in the JDK to track performance metrics Reviewed-by: alanb, dholmes, iris, forax, andrew ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/zip/ZipFile.java + src/share/classes/sun/misc/PerfCounter.java ! src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java Changeset: 0a3244fe7142 Author: mchung Date: 2009-09-14 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0a3244fe7142 Merge From jonathan.gibbons at sun.com Mon Sep 14 17:15:42 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 15 Sep 2009 00:15:42 +0000 Subject: [security-dev 01207]: hg: jdk7/tl/langtools: 6881317: regression: NPE in CloseableURLClassLoader Message-ID: <20090915001550.EA9F612199@hg.openjdk.java.net> Changeset: f8be8bf150c3 Author: jjg Date: 2009-09-14 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f8be8bf150c3 6881317: regression: NPE in CloseableURLClassLoader Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java From daniel.daugherty at sun.com Mon Sep 14 17:51:16 2009 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Tue, 15 Sep 2009 00:51:16 +0000 Subject: [security-dev 01208]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090915005310.1407B121AA@hg.openjdk.java.net> Changeset: f0182203084a Author: dcubed Date: 2009-09-14 18:45 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f0182203084a 6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints) Summary: New test for the above fix. Reviewed-by: tbell + test/com/sun/jdi/BreakpointWithFullGC.sh Changeset: f78b7d9973b7 Author: dcubed Date: 2009-09-14 18:54 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f78b7d9973b7 Merge From Alan.Bateman at Sun.COM Tue Sep 15 06:54:57 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 15 Sep 2009 14:54:57 +0100 Subject: [security-dev 01209]: 6854954: Eliminate static dependency on java.awt.AWTPermission Message-ID: <4AAF9CB1.5000505@sun.com> Sean, Mandy - can you review this? I also need someone from the AWT team. This patch eliminates the static dependency on java.awt.AWTPermission from the security code, needed for the SecurityManager and default policy code to work in the event that the permission class is not present (in gui-less profile for example). The changes are relatively simple. Creation of the AWTPermissions is deferred until needed. If sun.awt.AWTPermissionFactory is present then it is used to create the AWTPermission instances. If not present, but somehow one the security manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods is invoked then "fake" permissions are used. The reason for the approach is to keep the reflection usage to a minimum (usually we use the shared secrets mechanism to avoid reflection completely but for this case, there isn't one place to setup the secret). The webrev is here: http://cr.openjdk.java.net/~alanb/6854954/webrev.00/ Thanks, Alan. From jonathan.gibbons at sun.com Tue Sep 15 12:22:02 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 15 Sep 2009 19:22:02 +0000 Subject: [security-dev 01210]: hg: jdk7/tl/langtools: 6882235: invalid exponent causes silent javac crash Message-ID: <20090915192203.BF6CB1221C@hg.openjdk.java.net> Changeset: 9dd34ed62341 Author: jjg Date: 2009-09-15 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9dd34ed62341 6882235: invalid exponent causes silent javac crash Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T6882235.java + test/tools/javac/T6882235.out From Sean.Mullan at Sun.COM Tue Sep 15 14:23:52 2009 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Tue, 15 Sep 2009 17:23:52 -0400 Subject: [security-dev 01211]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AAF9CB1.5000505@sun.com> References: <4AAF9CB1.5000505@sun.com> Message-ID: <4AB005E8.7070803@sun.com> Looks good to me. Super small nit in SecurityConstants: 120 try { indentation is off by one space with rest of code. --Sean Alan Bateman wrote: > > Sean, Mandy - can you review this? I also need someone from the AWT team. > > This patch eliminates the static dependency on java.awt.AWTPermission > from the security code, needed for the SecurityManager and default > policy code to work in the event that the permission class is not > present (in gui-less profile for example). The changes are relatively > simple. Creation of the AWTPermissions is deferred until needed. If > sun.awt.AWTPermissionFactory is present then it is used to create the > AWTPermission instances. If not present, but somehow one the security > manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods > is invoked then "fake" permissions are used. The reason for the approach > is to keep the reflection usage to a minimum (usually we use the shared > secrets mechanism to avoid reflection completely but for this case, > there isn't one place to setup the secret). > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6854954/webrev.00/ > > Thanks, > > Alan. From Mandy.Chung at Sun.COM Tue Sep 15 15:51:01 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Tue, 15 Sep 2009 15:51:01 -0700 Subject: [security-dev 01212]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AAF9CB1.5000505@sun.com> References: <4AAF9CB1.5000505@sun.com> Message-ID: <4AB01A55.80104@Sun.com> Alan, Looks good. Minor nit in SecurityConstants.java line 148 - good to add a blank line to separate the two fields Mandy Alan Bateman wrote: > > Sean, Mandy - can you review this? I also need someone from the AWT team. > > This patch eliminates the static dependency on java.awt.AWTPermission > from the security code, needed for the SecurityManager and default > policy code to work in the event that the permission class is not > present (in gui-less profile for example). The changes are relatively > simple. Creation of the AWTPermissions is deferred until needed. If > sun.awt.AWTPermissionFactory is present then it is used to create the > AWTPermission instances. If not present, but somehow one the security > manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods > is invoked then "fake" permissions are used. The reason for the approach > is to keep the reflection usage to a minimum (usually we use the shared > secrets mechanism to avoid reflection completely but for this case, > there isn't one place to setup the secret). > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6854954/webrev.00/ > > Thanks, > > Alan. From jonathan.gibbons at sun.com Tue Sep 15 18:37:26 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 16 Sep 2009 01:37:26 +0000 Subject: [security-dev 01213]: hg: jdk7/tl/langtools: 6860965: Project Coin: binary literals; ... Message-ID: <20090916013728.7A9981224D@hg.openjdk.java.net> Changeset: 69eaccd3ea85 Author: jjg Date: 2009-09-15 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/69eaccd3ea85 6860965: Project Coin: binary literals 6860973: Project Coin: Underscores in literals Summary: [Portions contributed by Bruce Chapman] Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/enum/6384542/T6384542.out + test/tools/javac/literals/BadBinaryLiterals.6.out + test/tools/javac/literals/BadBinaryLiterals.7.out + test/tools/javac/literals/BadBinaryLiterals.java + test/tools/javac/literals/BadUnderscoreLiterals.6.out + test/tools/javac/literals/BadUnderscoreLiterals.7.out + test/tools/javac/literals/BadUnderscoreLiterals.java + test/tools/javac/literals/BinaryLiterals.java + test/tools/javac/literals/UnderscoreLiterals.java From daniel.daugherty at sun.com Tue Sep 15 21:13:28 2009 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 16 Sep 2009 04:13:28 +0000 Subject: [security-dev 01214]: hg: jdk7/tl/jdk: 6882363: 4/4 typos in java.util.logging javadocs Message-ID: <20090916041404.D86C512266@hg.openjdk.java.net> Changeset: e8c2dd4b8bac Author: dcubed Date: 2009-09-15 22:11 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8c2dd4b8bac 6882363: 4/4 typos in java.util.logging javadocs Summary: Fix typos, some grammar and some inconsistencies in phrasing. Reviewed-by: tbell ! src/share/classes/java/util/logging/ErrorManager.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Formatter.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java From Anthony.Petrov at Sun.COM Wed Sep 16 03:22:37 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 16 Sep 2009 14:22:37 +0400 Subject: [security-dev 01215]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AAF9CB1.5000505@sun.com> References: <4AAF9CB1.5000505@sun.com> Message-ID: <4AB0BC6D.4030604@sun.com> Hi Alan, To contribute a little to the small nit picking process :) : 1. src/share/classes/javax/swing/JPopupMenu.java Line 415 might be realigned to keep standard indentation. 2. The copyright notices might be updated to indicate that 2009 is the year of last modification of the files. The rest looks good. Please consider that approved by the AWT team. -- best regards, Anthony On 09/15/2009 05:54 PM, Alan Bateman wrote: > > Sean, Mandy - can you review this? I also need someone from the AWT team. > > This patch eliminates the static dependency on java.awt.AWTPermission > from the security code, needed for the SecurityManager and default > policy code to work in the event that the permission class is not > present (in gui-less profile for example). The changes are relatively > simple. Creation of the AWTPermissions is deferred until needed. If > sun.awt.AWTPermissionFactory is present then it is used to create the > AWTPermission instances. If not present, but somehow one the security > manager's checkTopLevelWindow, checkSystemClipboardAccess, etc. methods > is invoked then "fake" permissions are used. The reason for the approach > is to keep the reflection usage to a minimum (usually we use the shared > secrets mechanism to avoid reflection completely but for this case, > there isn't one place to setup the secret). > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6854954/webrev.00/ > > Thanks, > > Alan. From Alan.Bateman at Sun.COM Wed Sep 16 09:21:48 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 16 Sep 2009 17:21:48 +0100 Subject: [security-dev 01216]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AB0BC6D.4030604@sun.com> References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com> Message-ID: <4AB1109C.8040906@sun.com> Anthony Petrov wrote: > Hi Alan, > > To contribute a little to the small nit picking process :) : > > 1. src/share/classes/javax/swing/JPopupMenu.java > Line 415 might be realigned to keep standard indentation. > > 2. The copyright notices might be updated to indicate that 2009 is the > year of last modification of the files. > > The rest looks good. Please consider that approved by the AWT team. Thanks (and thanks Sean and Mandy). I'll fix the alignment in JPopupMenu (it pre-dates my proposed change of course). I could update the date range in the header but I don't think we have to do that (I'm pretty sure Xiomara runs a script that periodically updates these). -Alan. From Anthony.Petrov at Sun.COM Wed Sep 16 10:08:13 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 16 Sep 2009 21:08:13 +0400 Subject: [security-dev 01217]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AB1109C.8040906@sun.com> References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com> <4AB1109C.8040906@sun.com> Message-ID: <4AB11B7D.4090200@sun.com> On 9/16/2009 8:21 PM Alan Bateman wrote: >> 2. The copyright notices might be updated to indicate that 2009 is the >> year of last modification of the files. >> ... > (it pre-dates my proposed change of course). I could update the date > range in the header but I don't think we have to do that (I'm pretty > sure Xiomara runs a script that periodically updates these). Xiomara, could you confirm that? -- best regards, Anthony From Xiomara.Jayasena at Sun.COM Wed Sep 16 10:17:01 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Wed, 16 Sep 2009 10:17:01 -0700 Subject: [security-dev 01218]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AB11B7D.4090200@sun.com> References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com> <4AB1109C.8040906@sun.com> <4AB11B7D.4090200@sun.com> Message-ID: <4AB11D8D.8000304@sun.com> Anthony Petrov wrote: > On 9/16/2009 8:21 PM Alan Bateman wrote: >>> 2. The copyright notices might be updated to indicate that 2009 is >>> the year of last modification of the files. >>> > ... >> (it pre-dates my proposed change of course). I could update the date >> range in the header but I don't think we have to do that (I'm pretty >> sure Xiomara runs a script that periodically updates these). > > Xiomara, could you confirm that? Right, that is the process. -Xiomara > > -- > best regards, > Anthony From Weijun.Wang at Sun.COM Wed Sep 16 10:46:12 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Thu, 17 Sep 2009 01:46:12 +0800 Subject: [security-dev 01219]: code review request: 6882687 KerberosTime too imprecise References: <14434827.1253121133435.JavaMail.sbladm@swsblss3-new> Message-ID: <8DA2958C-3667-4388-A3AF-38D40128FD7A@Sun.COM> Hi Valerie Please take a review for the fix at http://cr.openjdk.java.net/~weijun/6882687/webrev.00 Brad This would fix the IgnoreChannelBindings test failure on CYGWIN. Thanks Max Begin forwarded message: > From: Weijun.Wang at Sun.COM > Date: September 17, 2009 1:12:13 AM GMT+08:00 > *Synopsis*: KerberosTime too imprecise > > === *Description* > ============================================================ > Recently I notice a Kerberos test fails on CYGWIN saying an AP-REQ > is a "replay detected". It turns out that the Windows time (returned > by new Date()) is too coarse (15 millisecond precision) and the two > AP-REQs in the test have the same KerberosTime value. > > Also, the KerberosTime class is the source of microseconds value > used in Authenticator etc. Since Date only provides milliseconds, > this means even if on a system with ideal Date, the microsecond > value is always a multiple of 1000. > From Anthony.Petrov at Sun.COM Wed Sep 16 10:46:22 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 16 Sep 2009 21:46:22 +0400 Subject: [security-dev 01220]: Re: 6854954: Eliminate static dependency on java.awt.AWTPermission In-Reply-To: <4AB11D8D.8000304@sun.com> References: <4AAF9CB1.5000505@sun.com> <4AB0BC6D.4030604@sun.com> <4AB1109C.8040906@sun.com> <4AB11B7D.4090200@sun.com> <4AB11D8D.8000304@sun.com> Message-ID: <4AB1246E.6020806@sun.com> On 9/16/2009 9:17 PM Xiomara Jayasena wrote: >>>> 2. The copyright notices might be updated to indicate that 2009 is >>>> the year of last modification of the files. >>>> >> ... >>> (it pre-dates my proposed change of course). I could update the date >>> range in the header but I don't think we have to do that (I'm pretty >>> sure Xiomara runs a script that periodically updates these). >> >> Xiomara, could you confirm that? > > Right, that is the process. That sounds great! Thanks for the information! -- best regards, Anthony From tim.bell at sun.com Thu Sep 17 11:09:07 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Thu, 17 Sep 2009 18:09:07 +0000 Subject: [security-dev 01221]: hg: jdk7/tl: 2 new changesets Message-ID: <20090917180908.0077C12342@hg.openjdk.java.net> Changeset: 4079d923a501 Author: peterz Date: 2009-08-31 14:10 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4079d923a501 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README-builds.html Changeset: 0d7e03b426df Author: yan Date: 2009-09-09 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/0d7e03b426df Merge From tim.bell at sun.com Thu Sep 17 11:09:47 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Thu, 17 Sep 2009 18:09:47 +0000 Subject: [security-dev 01222]: hg: jdk7/tl/hotspot: 31 new changesets Message-ID: <20090917181049.9CCD412349@hg.openjdk.java.net> Changeset: a05ea7791ee3 Author: trims Date: 2009-08-21 20:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a05ea7791ee3 6873236: Fork HS16 to HS17 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS17 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1760a1cbed36 Author: dcubed Date: 2009-08-11 11:57 -0600 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1760a1cbed36 6862945: 4/3 conversion of jmethodID to methodOop in JVMTI is too expensive Summary: Refactor JNIHandles::checked_resolve_jmethod_id() into fast and paranoid parts. Reviewed-by: never, alanb ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/runtime/jniHandles.hpp Changeset: 6ab1d6ece8bd Author: apangin Date: 2009-08-17 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6ab1d6ece8bd Merge Changeset: 585222cadf79 Author: apangin Date: 2009-08-19 15:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/585222cadf79 Merge Changeset: a774e1abbe85 Author: trims Date: 2009-08-21 20:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a774e1abbe85 Merge Changeset: 046932b72aa2 Author: never Date: 2009-08-14 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/046932b72aa2 6862956: PhaseIdealLoop should have a CFG verification mode Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp Changeset: 1a81ea4b45d4 Author: kvn Date: 2009-08-14 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1a81ea4b45d4 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") Summary: Replace the assert with narrow_oop_shift set to 0. Reviewed-by: never, jcoomes ! src/share/vm/memory/universe.cpp Changeset: a70508bb21c3 Author: never Date: 2009-08-14 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a70508bb21c3 6862863: C2 compiler fails in elide_copy() Reviewed-by: kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 55784fd95fe3 Author: never Date: 2009-08-14 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/55784fd95fe3 Merge Changeset: 7c14587118b3 Author: never Date: 2009-08-14 22:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c14587118b3 Merge Changeset: c8e2135f7e30 Author: cfang Date: 2009-08-17 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c8e2135f7e30 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 Summary: Make sure the control word is correct in deopt_blob after restore_result_registers Reviewed-by: kvn, never ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp Changeset: 662f330d7275 Author: cfang Date: 2009-08-17 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/662f330d7275 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) Summary: delay dead code elimination in set_req_X to make it safe Reviewed-by: kvn, never ! src/share/vm/opto/phaseX.cpp + test/compiler/6866651/Test.java Changeset: d0acbc302e14 Author: never Date: 2009-08-17 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d0acbc302e14 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Reviewed-by: twisti, cfang ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/includeDB_compiler1 + test/compiler/6795465/Test6795465.java Changeset: cd18bd5e667c Author: never Date: 2009-08-19 18:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd18bd5e667c 6873777: FPU control word optimization still performed with SSE Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 357d4e2eb4dd Author: kvn Date: 2009-08-19 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/357d4e2eb4dd 6873799: enable escape analysis by default Summary: enable escape analysis by default Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp Changeset: 72088be4b386 Author: cfang Date: 2009-08-20 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72088be4b386 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit Summary: use PcDesc to keep record of the reexecute bit instead of using DebugInfoStreams Reviewed-by: kvn, never, twisti ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 82bd76d4d7f2 Author: kvn Date: 2009-08-24 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/82bd76d4d7f2 6873800: enable compressed oops by default Summary: enable compressed oops by default Reviewed-by: never, ysr ! src/share/vm/runtime/arguments.cpp Changeset: cdb8b7c37ac1 Author: never Date: 2009-08-24 22:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cdb8b7c37ac1 6875329: fix for 6795465 broke exception handler cloning Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: aba04734b61e Author: kvn Date: 2009-08-25 13:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aba04734b61e Merge Changeset: 05f89f00a864 Author: jmasa Date: 2009-08-24 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/05f89f00a864 6798898: CMS: bugs related to class unloading Summary: Override should_remember_klasses() and remember_klass() as needed. Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp Changeset: e1fdf4fd34dc Author: tonyp Date: 2009-08-19 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e1fdf4fd34dc 6871111: G1: remove the concurrent overhead tracker Summary: Removing the concurrent overhead tracker from G1, along with the GC overhead reporter and the G1AccountConcurrentOverhead (both of which rely on the the concurrent overhead tracker). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: ead53f6b615d Author: tonyp Date: 2009-08-24 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ead53f6b615d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: b37c246bf7ce Author: jcoomes Date: 2009-08-11 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b37c246bf7ce 6861660: OopMapBlock count/size confusion Reviewed-by: tonyp, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp Changeset: 9eebd3ac74cf Author: jcoomes Date: 2009-08-13 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eebd3ac74cf 6845368: large objects cause a crash or unexpected exception Reviewed-by: jmasa, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp + test/gc/6845368/bigobj.java Changeset: 8624da129f0b Author: apetrusenko Date: 2009-08-31 05:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8624da129f0b 6841313: G1: dirty cards of survivor regions in parallel Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 8b46c4d82093 Author: ysr Date: 2009-09-02 00:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b46c4d82093 4957990: Perm heap bloat in JVM Summary: Treat ProfileData in MDO's as a source of weak, not strong, roots. Fixes the bug for stop-world collection -- the case of concurrent collection will be fixed separately. Reviewed-by: jcoomes, jmasa, kvn, never ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 2c79770d1f6e Author: tonyp Date: 2009-07-30 16:22 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2c79770d1f6e 6819085: G1: use larger and/or user settable region size Summary: Instead of the region size being hard-coded, allow the user to set it. Reviewed-by: jmasa, johnc, apetrusenko ! 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/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b1606b3c0a8a Author: apetrusenko Date: 2009-09-04 05:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b1606b3c0a8a Merge ! src/share/vm/code/nmethod.cpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp Changeset: b1f5ced5da21 Author: jcoomes Date: 2009-09-03 19:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b1f5ced5da21 6879076: disable jprt sync after builds are done Reviewed-by: kamg, dholmes ! make/jprt.properties Changeset: 68ef3fdcdb76 Author: ysr Date: 2009-09-10 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/68ef3fdcdb76 6872136: CMS: confusing message may be printed when a collector is switched off implicitly Summary: Fix CDS/CMS option overrides related to iCMS option CMSIncrementalMode; explicate overrides to error stream. Reviewed-by: coleenp ! src/share/vm/runtime/arguments.cpp Changeset: a94714c55065 Author: trims Date: 2009-09-15 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a94714c55065 Merge From tim.bell at sun.com Thu Sep 17 11:12:35 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Thu, 17 Sep 2009 18:12:35 +0000 Subject: [security-dev 01223]: hg: jdk7/tl/jdk: 30 new changesets Message-ID: <20090917181908.4B32E12352@hg.openjdk.java.net> Changeset: 559fb14d0ae9 Author: anthony Date: 2009-08-27 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/559fb14d0ae9 6780496: Javaw process taking up 80-90 percent of CPU time! Summary: The transparency effects get enabled on showing, and disabled on hiding a window Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: 7599cca4fe5e Author: dcherepanov Date: 2009-08-27 17:04 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7599cca4fe5e 6852051: Getting Null Pointer Exception when displaying message for TrayIcon on Opensolaris Reviewed-by: anthony ! src/share/classes/java/awt/Component.java Changeset: 911a82b4901f Author: dcherepanov Date: 2009-08-27 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/911a82b4901f 6854898: Frame is located at the negative coordinates instead of origin for Solaris 10 CDE Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: d5ac8fb96d13 Author: anthony Date: 2009-08-28 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5ac8fb96d13 6689468: test/closed/java/awt/Component/VisibleHwInLwContTest/VisibleHwInLwContTest.html fails Summary: The addNotify() checks whether the component is actually hidden, and hides the peer appropriately if needed Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java Changeset: d755ace580b2 Author: yan Date: 2009-09-04 14:50 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d755ace580b2 6871299: Shift+Tab no longer generates a KEY_TYPED event; used to with JRE 1.5 Summary: Add XK_ISO_Left_Tab -> VK_TAB rule Reviewed-by: dcherepanov ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 5a584fbcc712 Author: yan Date: 2009-09-09 00:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5a584fbcc712 Merge Changeset: a48c15bcf64f Author: rupashka Date: 2009-08-14 13:18 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a48c15bcf64f 6824600: OOM occurs when setLookAndFeel() is executed in Windows L&F(XP style) Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalFontDesktopProperty.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java + test/com/sun/java/swing/plaf/windows/Test6824600.java Changeset: fa334ff12794 Author: alexp Date: 2009-08-19 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa334ff12794 6872492: JLayer sources contain wrong header Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: 3e36c9abb569 Author: yan Date: 2009-08-20 23:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e36c9abb569 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: e8d93257cf7e Author: rupashka Date: 2009-08-21 16:59 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8d93257cf7e 6579827: vista : JSlider on JColorchooser is not properly render or can't be seen completely. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6579827/bug6579827.java Changeset: d07bd8fa89e4 Author: rupashka Date: 2009-08-24 18:21 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d07bd8fa89e4 6849266: closed/javax/swing/JFileChooser/6484091/bug6484091.java fails on solaris 10 sparc Reviewed-by: peterz + test/javax/swing/JFileChooser/6484091/bug6484091.java Changeset: 799439873bf9 Author: alexp Date: 2009-08-24 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/799439873bf9 6824395: Several Swing core components prevent using them in wrapper classes Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JLayer/6824395/bug6824395.java ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 4914723317b9 Author: peytoia Date: 2009-08-31 12:55 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4914723317b9 6851214: (tz) New Jordan rule creates a failure for SimpleTimeZone parsing post tzdata2009h Reviewed-by: okutsu ! src/share/classes/java/util/SimpleTimeZone.java + test/java/util/TimeZone/ListTimeZones.java Changeset: 7aa6cb832991 Author: peytoia Date: 2009-08-31 14:50 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7aa6cb832991 6872467: (tz) Support tzdata2009l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab Changeset: 92b6482e7719 Author: peytoia Date: 2009-08-31 14:53 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92b6482e7719 6456628: (tz) Default timezone is incorrectly set occasionally on Linux Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: f7d606ca25a9 Author: peterz Date: 2009-08-31 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f7d606ca25a9 6802944: Nimbus initialization is too slow Reviewed-by: jasper ! make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/DerivedColor.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Changeset: 7e7153da24ef Author: peterz Date: 2009-08-31 13:56 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e7153da24ef 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README ! make/common/Sanity.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile - make/javax/swing/plaf/nimbus/Makefile ! make/tools/Makefile + make/tools/generate_nimbus/Makefile + make/tools/src/build/tools/generatenimbus/Generator.java + make/tools/src/build/tools/generatenimbus/ObjectFactory.java + make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/PainterGenerator.java + make/tools/src/build/tools/generatenimbus/Shape.java + make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIStyle.java + make/tools/src/build/tools/generatenimbus/Utils.java - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: e7d311b4ae94 Author: alexp Date: 2009-08-31 18:39 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7d311b4ae94 6872503: JLayer event handling should be rewritten Reviewed-by: art ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6872503/bug6872503.java Changeset: 9d8f551780d5 Author: peytoia Date: 2009-09-01 15:39 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d8f551780d5 6830423: Unified Ext B character not displayed with Dialog font Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 37c33432e98a Author: peytoia Date: 2009-09-01 15:42 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/37c33432e98a 6838887: (tz) Add UTC and Yerevan to tzmappings Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: 5780cff2763c Author: peytoia Date: 2009-09-01 16:15 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5780cff2763c 6856390: RFE : sequence.allfonts.UTF-8.ja for Windows fontconfig.properties Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 4f819e2e0bfc Author: peterz Date: 2009-09-01 15:34 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f819e2e0bfc 6387579: Usage of package-private class as parameter of a method (javax.swing.tree.DefaultTreeSelectionModel) Reviewed-by: rupashka ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 935814bd43a6 Author: alexp Date: 2009-09-01 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/935814bd43a6 6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java + test/javax/swing/JLayer/6875153/bug6875153.java Changeset: 281fbd82a971 Author: alexp Date: 2009-09-02 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/281fbd82a971 6797139: JButton title is truncating for some strings irrespective of preferred size. Reviewed-by: peterz ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/SwingUtilities/6797139/bug6797139.java Changeset: ff468ef27959 Author: gsm Date: 2009-09-07 12:27 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff468ef27959 6699856: Creating text in a JTextPane using Chinese text causes undesired behavior Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 01c46cb72eb7 Author: rupashka Date: 2009-09-07 15:09 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/01c46cb72eb7 6589634: Unable to view focus on "Up one level", "create new folder" etc. of JFileChooser Dialog Reviewed-by: peterz, loneid ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: d73a741a7ea1 Author: malenkov Date: 2009-09-08 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d73a741a7ea1 6868185: 2 JCK api/java_beans/Introspector/ tests fails starting from jdk7 b66 Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java Changeset: e289c06b6d36 Author: yan Date: 2009-09-09 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e289c06b6d36 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: 460639b036f3 Author: yan Date: 2009-09-15 23:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/460639b036f3 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: 81b85ea694f8 Author: tbell Date: 2009-09-16 09:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/81b85ea694f8 Merge From Vincent.Ryan at Sun.COM Fri Sep 18 01:25:47 2009 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Fri, 18 Sep 2009 09:25:47 +0100 Subject: [security-dev 01224]: Re: 6840752: Provide out-of-the-box support for ECC algorithms In-Reply-To: <17c6771e0909101302u47dafb43gbf85cf2b9c29ded9@mail.gmail.com> References: <17c6771e0908241226m5c953906qcb34ada4f89c9c5b@mail.gmail.com> <4A968683.7090105@sun.com> <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> <4AA822F9.4010100@sun.com> <17c6771e0909091614m78197ba0mb571a744f526696f@mail.gmail.com> <17c6771e0909101302u47dafb43gbf85cf2b9c29ded9@mail.gmail.com> Message-ID: <4AB3440B.5050607@sun.com> Hello again Andrew, Sorry for the delay getting to your request. Your mechanism to control the inclusion of the SunEC provider looks like a fine solution. I've created the following CR: http://bugs.sun.com/view_bug.do?bug_id=6882745 Andrew John Hughes wrote: > 2009/9/10 Andrew John Hughes : >> 2009/9/9 Vincent Ryan : >>> Hello Andrew, >>> >>> I realize that you, along with others in the Linux community, are less >>> than satisfied with the changeset to provide out-of-the-box support for >>> ECC algorithms. >>> >>> As I mentioned earlier, we were quite constrained in what we could >>> openly discuss before we pushed. However, now that we have pushed I >>> am eager to fix any problems that I've introduced. >>> >> Yes, I can understand that to an extent, but I find it hard to believe >> that you had to push it before it could even be discussed. Why could >> the same patch that was pushed not have been posted for public review >> instead? >> >> This seems to be a more general issue. This is endemic behaviour that >> I've seen from the majority of Sun engineers working on OpenJDK (there >> are thankfully some exceptions) and I've blogged about this in more >> detail: http://blog.fuseyism.com/index.php/2009/09/08/im-so-tired/ >> >>> We wish to reconcile the conflicting demands of including an ECC >>> implementation for platforms without underlying ECC support with the >>> exclusion of the ECC implementation on platforms with underlying ECC >>> support. I'd like to solicit input from security-dev on how best to >>> achieve this. >>> >> It's good to hear you're open to changing this. There is a third >> option you've missed; the demand of not wanting ECC support at all. >> You'll be aware that there are legal issues from your own discussions >> on this within Sun, and the change in direction that occurred. Not >> having ECC support needs to be an option as well. >> >> The existing ECC implementation already fulfilled two of these >> demands; it could be enabled on platforms with ECC support but this >> wasn't the default case. We can make this easier with IcedTea by >> detecting NSS at build time and auto-generating the configuration if >> the user wishes. This also can be used to ship it 'out of the box' on >> distributions if required; all the distro packager has to do is build >> IcedTea with NSS support enabled and then make their binary depend on >> it. >> >> So the real problem here is that Sun's proprietary builds can't ship >> it 'out of the box' because they don't know if the system it ends up >> on will have NSS and, even if it does, where it will be located. I >> can understand how that's a problem that needs to be fixed, but we >> need a way of disabling that. If the PKCS11 provider is still >> suitable, then making building the ec directory would actually be >> enough: >> >> ifndef DISABLE_NSS >> SUBDIRS += ec >> endif >> >> Job done. A more complex solution is to link against the system NSS >> instead of the provided C sources. I've managed to do this with the >> following change: >> >> diff -r 7a23bfc44c92 make/sun/security/ec/Makefile >> --- a/make/sun/security/ec/Makefile Tue Sep 08 18:03:43 2009 +0100 >> +++ b/make/sun/security/ec/Makefile Wed Sep 09 23:50:24 2009 +0100 >> @@ -153,7 +153,9 @@ >> # >> # C and C++ files >> # >> +ifndef USE_SYSTEM_NSS >> include FILES_c.gmk >> +endif >> >> FILES_cpp = ECC_JNI.cpp >> >> @@ -185,6 +187,11 @@ >> OTHER_LDLIBS += $(JVMLIB) >> else >> OTHER_LDLIBS = -ldl $(JVMLIB) $(LIBCXX) >> + ifdef USE_SYSTEM_NSS >> + OTHER_LDLIBS += -Wl,-rpath $(SYSTEM_NSS_DIR) -Wl,-rpath >> $(SYSTEM_NSPR_DIR) \ >> + -L$(SYSTEM_NSS_DIR) -L$(SYSTEM_NSPR_DIR) -lnssutil3 -lnss3 \ >> + -lplds4 -lplc4 -lnspr4 -lsoftokn -lfreebl >> + endif >> endif >> >> include $(BUILDDIR)/common/Mapfile-vers.gmk >> >> but unfortunately, while the resulting sunecc library is dynamically >> linked against NSS, it causes HotSpot to segfault in >> sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[J. I'm >> still looking into this, I assume there is either some mismatch in the >> versions of NSS or local changes in the Sun copy. As you say, only >> part of the library was imported into OpenJDK; does this mean that the >> JNI code is not using published interfaces for NSS? >> >>> Your proposal to supply an NSS config file for the SunPKCS11 provider >>> is one approach but what about platforms where an ECC-enabled NSS is >>> not present? >>> >>> >> It's only really an idea that works where we have an autoconf wrapper >> to detect NSS at build time, and which also allows it to be disabled. >> The patch to IcedTea automatically finds out where NSS is installed, >> via pkg-config, and writes the config file based on that. I don't >> know of a portable way of doing that in OpenJDK's makefiles as >> pkg-config won't be available on all platforms. >> >> snip... >> >>>> * Which version of NSS were these sources pulled from? Running diff >>>> -bu on them, and ignoring the additional copyright headers, >>>> there are still a large number of changes. I suspect this is >>>> because the version is older than my system copy (3.12.3); notably my >>>> testing shows it does not exhibit the bug discussed in >>>> >>>> http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html >>>> (which >>>> incidentally is still awaiting review). >>> The sources were pulled from OpenSolaris 2009.06. >>> >> Ok, so which version of NSS does that have? >> >>>> * Why was a new provider used instead of the existing >>>> sun.security.pkcs11.SunPKCS11 provider? I noticed this has not be >>>> removed, yet >>>> it appears to provide duplicate functionality unless I'm mistaken. >>>> This does perhaps mean we could fix the issues with this changeset >>>> simply >>>> by allowing the ec subdirectory to be turned off, but there may be >>>> something about the new provider I'm missing. >>> We introduced the new SunEC provider because we wanted a fast compact >>> ECC implementation that we could ship on all platforms. We have not >>> bundled all of NSS - only its ECC implementation. >>> >> Yeah I noticed that. I suppose the big question is how interchangable >> are SunEC and PKCS11? Could we just turn off SunEC, given we already >> have NSS support via PKCS11? If so, just making SunEC optional would >> solve this IMO. >> >>> >>>> * I notice that a number of algorithms are replaced with NULL. I >>>> assume there is some (perhaps legal) reason for this? >>> Which ones? >>> >> This is the change I'm referring to: >> >> /* mapping between ECCurveName enum and pointers to ECCurveParams */ >> static const ECCurveParams *ecCurve_map[] = { >> NULL, /* ECCurve_noName */ >> - &ecCurve_NIST_P192, /* ECCurve_NIST_P192 */ >> - &ecCurve_NIST_P224, /* ECCurve_NIST_P224 */ >> + NULL, /* ECCurve_NIST_P192 */ >> + NULL, /* ECCurve_NIST_P224 */ >> &ecCurve_NIST_P256, /* ECCurve_NIST_P256 */ >> &ecCurve_NIST_P384, /* ECCurve_NIST_P384 */ >> &ecCurve_NIST_P521, /* ECCurve_NIST_P521 */ >> - &ecCurve_NIST_K163, /* ECCurve_NIST_K163 */ >> - &ecCurve_NIST_B163, /* ECCurve_NIST_B163 */ >> - &ecCurve_NIST_K233, /* ECCurve_NIST_K233 */ >> - &ecCurve_NIST_B233, /* ECCurve_NIST_B233 */ >> - &ecCurve_NIST_K283, /* ECCurve_NIST_K283 */ >> - &ecCurve_NIST_B283, /* ECCurve_NIST_B283 */ >> - &ecCurve_NIST_K409, /* ECCurve_NIST_K409 */ >> - &ecCurve_NIST_B409, /* ECCurve_NIST_B409 */ >> - &ecCurve_NIST_K571, /* ECCurve_NIST_K571 */ >> - &ecCurve_NIST_B571, /* ECCurve_NIST_B571 */ >> - &ecCurve_X9_62_PRIME_192V2, /* ECCurve_X9_62_PRIME_192V2 */ >> - &ecCurve_X9_62_PRIME_192V3, /* ECCurve_X9_62_PRIME_192V3 */ >> - &ecCurve_X9_62_PRIME_239V1, /* ECCurve_X9_62_PRIME_239V1 */ >> - &ecCurve_X9_62_PRIME_239V2, /* ECCurve_X9_62_PRIME_239V2 */ >> - &ecCurve_X9_62_PRIME_239V3, /* ECCurve_X9_62_PRIME_239V3 */ >> - &ecCurve_X9_62_CHAR2_PNB163V1, /* ECCurve_X9_62_CHAR2_PNB163V1 */ >> - &ecCurve_X9_62_CHAR2_PNB163V2, /* ECCurve_X9_62_CHAR2_PNB163V2 */ >> - &ecCurve_X9_62_CHAR2_PNB163V3, /* ECCurve_X9_62_CHAR2_PNB163V3 */ >> - &ecCurve_X9_62_CHAR2_PNB176V1, /* ECCurve_X9_62_CHAR2_PNB176V1 */ >> - &ecCurve_X9_62_CHAR2_TNB191V1, /* ECCurve_X9_62_CHAR2_TNB191V1 */ >> - &ecCurve_X9_62_CHAR2_TNB191V2, /* ECCurve_X9_62_CHAR2_TNB191V2 */ >> - &ecCurve_X9_62_CHAR2_TNB191V3, /* ECCurve_X9_62_CHAR2_TNB191V3 */ >> - &ecCurve_X9_62_CHAR2_PNB208W1, /* ECCurve_X9_62_CHAR2_PNB208W1 */ >> - &ecCurve_X9_62_CHAR2_TNB239V1, /* ECCurve_X9_62_CHAR2_TNB239V1 */ >> - &ecCurve_X9_62_CHAR2_TNB239V2, /* ECCurve_X9_62_CHAR2_TNB239V2 */ >> - &ecCurve_X9_62_CHAR2_TNB239V3, /* ECCurve_X9_62_CHAR2_TNB239V3 */ >> - &ecCurve_X9_62_CHAR2_PNB272W1, /* ECCurve_X9_62_CHAR2_PNB272W1 */ >> - &ecCurve_X9_62_CHAR2_PNB304W1, /* ECCurve_X9_62_CHAR2_PNB304W1 */ >> - &ecCurve_X9_62_CHAR2_TNB359V1, /* ECCurve_X9_62_CHAR2_TNB359V1 */ >> - &ecCurve_X9_62_CHAR2_PNB368W1, /* ECCurve_X9_62_CHAR2_PNB368W1 */ >> - &ecCurve_X9_62_CHAR2_TNB431R1, /* ECCurve_X9_62_CHAR2_TNB431R1 */ >> - &ecCurve_SECG_PRIME_112R1, /* ECCurve_SECG_PRIME_112R1 */ >> - &ecCurve_SECG_PRIME_112R2, /* ECCurve_SECG_PRIME_112R2 */ >> - &ecCurve_SECG_PRIME_128R1, /* ECCurve_SECG_PRIME_128R1 */ >> - &ecCurve_SECG_PRIME_128R2, /* ECCurve_SECG_PRIME_128R2 */ >> - &ecCurve_SECG_PRIME_160K1, /* ECCurve_SECG_PRIME_160K1 */ >> - &ecCurve_SECG_PRIME_160R1, /* ECCurve_SECG_PRIME_160R1 */ >> - &ecCurve_SECG_PRIME_160R2, /* ECCurve_SECG_PRIME_160R2 */ >> - &ecCurve_SECG_PRIME_192K1, /* ECCurve_SECG_PRIME_192K1 */ >> - &ecCurve_SECG_PRIME_224K1, /* ECCurve_SECG_PRIME_224K1 */ >> - &ecCurve_SECG_PRIME_256K1, /* ECCurve_SECG_PRIME_256K1 */ >> - &ecCurve_SECG_CHAR2_113R1, /* ECCurve_SECG_CHAR2_113R1 */ >> - &ecCurve_SECG_CHAR2_113R2, /* ECCurve_SECG_CHAR2_113R2 */ >> - &ecCurve_SECG_CHAR2_131R1, /* ECCurve_SECG_CHAR2_131R1 */ >> - &ecCurve_SECG_CHAR2_131R2, /* ECCurve_SECG_CHAR2_131R2 */ >> - &ecCurve_SECG_CHAR2_163R1, /* ECCurve_SECG_CHAR2_163R1 */ >> - &ecCurve_SECG_CHAR2_193R1, /* ECCurve_SECG_CHAR2_193R1 */ >> - &ecCurve_SECG_CHAR2_193R2, /* ECCurve_SECG_CHAR2_193R2 */ >> - &ecCurve_SECG_CHAR2_239K1, /* ECCurve_SECG_CHAR2_239K1 */ >> - &ecCurve_WTLS_1, /* ECCurve_WTLS_1 */ >> - &ecCurve_WTLS_8, /* ECCurve_WTLS_8 */ >> - &ecCurve_WTLS_9, /* ECCurve_WTLS_9 */ >> + NULL, /* ECCurve_NIST_K163 */ >> + NULL, /* ECCurve_NIST_B163 */ >> + NULL, /* ECCurve_NIST_K233 */ >> + NULL, /* ECCurve_NIST_B233 */ >> + NULL, /* ECCurve_NIST_K283 */ >> + NULL, /* ECCurve_NIST_B283 */ >> + NULL, /* ECCurve_NIST_K409 */ >> + NULL, /* ECCurve_NIST_B409 */ >> + NULL, /* ECCurve_NIST_K571 */ >> + NULL, /* ECCurve_NIST_B571 */ >> + NULL, /* ECCurve_X9_62_PRIME_192V2 */ >> + NULL, /* ECCurve_X9_62_PRIME_192V3 */ >> + NULL, /* ECCurve_X9_62_PRIME_239V1 */ >> + NULL, /* ECCurve_X9_62_PRIME_239V2 */ >> + NULL, /* ECCurve_X9_62_PRIME_239V3 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB163V1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB163V2 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB163V3 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB176V1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB191V1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB191V2 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB191V3 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB208W1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB239V1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB239V2 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB239V3 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB272W1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB304W1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB359V1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_PNB368W1 */ >> + NULL, /* ECCurve_X9_62_CHAR2_TNB431R1 */ >> + NULL, /* ECCurve_SECG_PRIME_112R1 */ >> + NULL, /* ECCurve_SECG_PRIME_112R2 */ >> + NULL, /* ECCurve_SECG_PRIME_128R1 */ >> + NULL, /* ECCurve_SECG_PRIME_128R2 */ >> + NULL, /* ECCurve_SECG_PRIME_160K1 */ >> + NULL, /* ECCurve_SECG_PRIME_160R1 */ >> + NULL, /* ECCurve_SECG_PRIME_160R2 */ >> + NULL, /* ECCurve_SECG_PRIME_192K1 */ >> + NULL, /* ECCurve_SECG_PRIME_224K1 */ >> + NULL, /* ECCurve_SECG_PRIME_256K1 */ >> + NULL, /* ECCurve_SECG_CHAR2_113R1 */ >> + NULL, /* ECCurve_SECG_CHAR2_113R2 */ >> + NULL, /* ECCurve_SECG_CHAR2_131R1 */ >> + NULL, /* ECCurve_SECG_CHAR2_131R2 */ >> + NULL, /* ECCurve_SECG_CHAR2_163R1 */ >> + NULL, /* ECCurve_SECG_CHAR2_193R1 */ >> + NULL, /* ECCurve_SECG_CHAR2_193R2 */ >> + NULL, /* ECCurve_SECG_CHAR2_239K1 */ >> + NULL, /* ECCurve_WTLS_1 */ >> + NULL, /* ECCurve_WTLS_8 */ >> + NULL, /* ECCurve_WTLS_9 */ >> NULL /* ECCurve_pastLastCurve */ >> }; >> >> >> It could be a NSS version issue, but seems more deliberate to me. >> It leaves three curves: >> &ecCurve_NIST_P256, /* ECCurve_NIST_P256 */ >> &ecCurve_NIST_P384, /* ECCurve_NIST_P384 */ >> &ecCurve_NIST_P521, /* ECCurve_NIST_P521 */ >> >>>> I'm afraid my current impression of this changeset is that it doesn't >>>> help us with packaging OpenJDK for GNU/Linux distributions at all, but >>>> instead makes things ten times worse as there is now a stale NSS to >>>> contend with. Not only are there the issues with bit rot I alluded to >>>> last time, but as you mention in your reply there are legal issues >>>> with EC support. Notably, I've found that Fedora doesn't ship any EC >>>> support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd >>>> have to rip this out in packages for that distribution (and it's >>>> dubious whether others should be shipping it). IANAL, so I won't >>>> comment further on such issues, but suffice to say this changeset >>>> significantly reduces the options for handling NSS support downstream. >>>> In contrast, the existing support in 1.6 is almost ideal, once you've >>>> discovered how it works; the distro packager can choose whether to >>>> enable support or not and they don't have to worry about rotting >>>> security code in OpenJDK. Maybe I'm missing something but this makes >>>> me think this would have been better as a local addition to Sun's >>>> proprietary builds rather than adding it to OpenJDK. >>>> >>>> I try to be as positive as I can about the OpenJDK project, but I'm >>>> sorry to say that changesets like this don't help. I actually find >>>> them quite depressing. As I said in my previous email, there appears >>>> to have been no discussion of this change; it was merely committed >>>> with no public review and appeared in b70. Meanwhile, myself and >>>> other external contributors have to spend days trying to get replies >>>> to emails to even get a simple bug fix in (I've lost count of how many >>>> I still have waiting; there must be at least four or five). That's >>>> just not fair and doesn't bode well for a successful community >>>> project. >>>> >>>> Thanks, >>> >> Cheers, >> -- >> 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 >> > > I've added this changeset: > > http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/2a1a7fb44226 > > to the IcedTea project's JDK7 forest to solve this issue. If it looks > ok, then give me a bug ID and I'll push it to tl-gate. From jean-christophe.collet at sun.com Fri Sep 18 02:04:02 2009 From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com) Date: Fri, 18 Sep 2009 09:04:02 +0000 Subject: [security-dev 01225]: hg: jdk7/tl/jdk: 6737819: sun.misc.net.DefaultProxySelector doesn't use proxy setting to localhost Message-ID: <20090918090436.38E6612454@hg.openjdk.java.net> Changeset: ee68feef41d2 Author: jccollet Date: 2009-09-18 10:51 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee68feef41d2 6737819: sun.misc.net.DefaultProxySelector doesn't use proxy setting to localhost Summary: Move default nonProxyHosts from hardcoded to property default value Reviewed-by: chegar ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/lib/net.properties + test/java/net/ProxySelector/B6737819.java From ahughes at redhat.com Fri Sep 18 04:24:01 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 18 Sep 2009 11:24:01 +0000 Subject: [security-dev 01226]: hg: jdk7/tl/jdk: 6882745: Add DISABLE_INTREE_EC option to make new EC provider optional. Message-ID: <20090918112448.4509712468@hg.openjdk.java.net> Changeset: 39c15c0a71f7 Author: andrew Date: 2009-09-10 19:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 6882745: Add DISABLE_INTREE_EC option to make new EC provider optional. Summary: Don't build the ec subdirectory when DISABLE_INTREE_EC is defined. Reviewed-by: vinnie ! make/sun/security/Makefile From gnu_andrew at member.fsf.org Fri Sep 18 04:28:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 18 Sep 2009 12:28:44 +0100 Subject: [security-dev 01227]: Re: 6840752: Provide out-of-the-box support for ECC algorithms In-Reply-To: <4AB3440B.5050607@sun.com> References: <17c6771e0908241226m5c953906qcb34ada4f89c9c5b@mail.gmail.com> <4A968683.7090105@sun.com> <17c6771e0909081148r1ba5c18u669f243fba37c1bc@mail.gmail.com> <4AA822F9.4010100@sun.com> <17c6771e0909091614m78197ba0mb571a744f526696f@mail.gmail.com> <17c6771e0909101302u47dafb43gbf85cf2b9c29ded9@mail.gmail.com> <4AB3440B.5050607@sun.com> Message-ID: <17c6771e0909180428l1fdfea5dqf592876b32cc53c1@mail.gmail.com> 2009/9/18 Vincent Ryan : > Hello again Andrew, > > Sorry for the delay getting to your request. > No problem. > Your mechanism to control the inclusion of the SunEC provider looks like a > fine solution. I've created the following CR: > > ?http://bugs.sun.com/view_bug.do?bug_id=6882745 > Thanks. Pushed: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 > > > > Andrew John Hughes wrote: >> 2009/9/10 Andrew John Hughes : >>> 2009/9/9 Vincent Ryan : >>>> Hello Andrew, >>>> >>>> I realize that you, along with others in the Linux community, are less >>>> than satisfied with the changeset to provide out-of-the-box support for >>>> ECC algorithms. >>>> >>>> As I mentioned earlier, we were quite constrained in what we could >>>> openly discuss before we pushed. However, now that we have pushed I >>>> am eager to fix any problems that I've introduced. >>>> >>> Yes, I can understand that to an extent, but I find it hard to believe >>> that you had to push it before it could even be discussed. ?Why could >>> the same patch that was pushed not have been posted for public review >>> instead? >>> >>> This seems to be a more general issue. ?This is endemic behaviour that >>> I've seen from the majority of Sun engineers working on OpenJDK (there >>> are thankfully some exceptions) and I've blogged about this in more >>> detail: http://blog.fuseyism.com/index.php/2009/09/08/im-so-tired/ >>> >>>> We wish to reconcile the conflicting demands of including an ECC >>>> implementation for platforms without underlying ECC support with the >>>> exclusion of the ECC implementation on platforms with underlying ECC >>>> support. I'd like to solicit input from security-dev on how best to >>>> achieve this. >>>> >>> It's good to hear you're open to changing this. ?There is a third >>> option you've missed; the demand of not wanting ECC support at all. >>> You'll be aware that there are legal issues from your own discussions >>> on this within Sun, and the change in direction that occurred. ?Not >>> having ECC support needs to be an option as well. >>> >>> The existing ECC implementation already fulfilled two of these >>> demands; it could be enabled on platforms with ECC support but this >>> wasn't the default case. ?We can make this easier with IcedTea by >>> detecting NSS at build time and auto-generating the configuration if >>> the user wishes. ?This also can be used to ship it 'out of the box' on >>> distributions if required; all the distro packager has to do is build >>> IcedTea with NSS support enabled and then make their binary depend on >>> it. >>> >>> So the real problem here is that Sun's proprietary builds can't ship >>> it 'out of the box' because they don't know if the system it ends up >>> on will have NSS and, even if it does, where it will be located. ?I >>> can understand how that's a problem that needs to be fixed, but we >>> need a way of disabling that. ?If the PKCS11 provider is still >>> suitable, then making building the ec directory would actually be >>> enough: >>> >>> ifndef DISABLE_NSS >>> ?SUBDIRS += ec >>> endif >>> >>> Job done. ?A more complex solution is to link against the system NSS >>> instead of the provided C sources. ?I've managed to do this with the >>> following change: >>> >>> diff -r 7a23bfc44c92 make/sun/security/ec/Makefile >>> --- a/make/sun/security/ec/Makefile ? ? Tue Sep 08 18:03:43 2009 +0100 >>> +++ b/make/sun/security/ec/Makefile ? ? Wed Sep 09 23:50:24 2009 +0100 >>> @@ -153,7 +153,9 @@ >>> ? # >>> ? # C and C++ files >>> ? # >>> +ifndef USE_SYSTEM_NSS >>> ? include FILES_c.gmk >>> +endif >>> >>> ? FILES_cpp = ECC_JNI.cpp >>> >>> @@ -185,6 +187,11 @@ >>> ? ? OTHER_LDLIBS += $(JVMLIB) >>> ? else >>> ? ? OTHER_LDLIBS = -ldl $(JVMLIB) $(LIBCXX) >>> + ? ?ifdef USE_SYSTEM_NSS >>> + ? ? ?OTHER_LDLIBS += -Wl,-rpath $(SYSTEM_NSS_DIR) -Wl,-rpath >>> $(SYSTEM_NSPR_DIR) \ >>> + ? ? ? ?-L$(SYSTEM_NSS_DIR) -L$(SYSTEM_NSPR_DIR) -lnssutil3 -lnss3 \ >>> + ? ? ? ?-lplds4 -lplc4 -lnspr4 -lsoftokn -lfreebl >>> + ? ?endif >>> ? endif >>> >>> ? include $(BUILDDIR)/common/Mapfile-vers.gmk >>> >>> but unfortunately, while the resulting sunecc library is dynamically >>> linked against NSS, it causes HotSpot to segfault in >>> sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[J. ?I'm >>> still looking into this, I assume there is either some mismatch in the >>> versions of NSS or local changes in the Sun copy. ?As you say, only >>> part of the library was imported into OpenJDK; does this mean that the >>> JNI code is not using published interfaces for NSS? >>> >>>> Your proposal to supply an NSS config file for the SunPKCS11 provider >>>> is one approach but what about platforms where an ECC-enabled NSS is >>>> not present? >>>> >>>> >>> It's only really an idea that works where we have an autoconf wrapper >>> to detect NSS at build time, and which also allows it to be disabled. >>> The patch to IcedTea automatically finds out where NSS is installed, >>> via pkg-config, and writes the config file based on that. ?I don't >>> know of a portable way of doing that in OpenJDK's makefiles as >>> pkg-config won't be available on all platforms. >>> >>> snip... >>> >>>>> ?* Which version of NSS were these sources pulled from? ?Running diff >>>>> -bu on them, and ignoring the additional copyright headers, >>>>> ?there are still a large number of changes. ?I suspect this is >>>>> because the version is older than my system copy (3.12.3); notably my >>>>> ?testing shows it does not exhibit the bug discussed in >>>>> >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html >>>>> (which >>>>> ?incidentally is still awaiting review). >>>> The sources were pulled from OpenSolaris 2009.06. >>>> >>> Ok, so which version of NSS does that have? >>> >>>>> ?* Why was a new provider used instead of the existing >>>>> sun.security.pkcs11.SunPKCS11 provider? ?I noticed this has not be >>>>> removed, yet >>>>> ?it appears to provide duplicate functionality unless I'm mistaken. >>>>> This does perhaps mean we could fix the issues with this changeset >>>>> simply >>>>> ?by allowing the ec subdirectory to be turned off, but there may be >>>>> something about the new provider I'm missing. >>>> We introduced the new SunEC provider because we wanted a fast compact >>>> ECC implementation that we could ship on all platforms. We have not >>>> bundled all of NSS - only its ECC implementation. >>>> >>> Yeah I noticed that. ?I suppose the big question is how interchangable >>> are SunEC and PKCS11? ?Could we just turn off SunEC, given we already >>> have NSS support via PKCS11? ?If so, just making SunEC optional would >>> solve this IMO. >>> >>>> >>>>> ?* I notice that a number of algorithms are replaced with NULL. ?I >>>>> assume there is some (perhaps legal) reason for this? >>>> Which ones? >>>> >>> This is the change I'm referring to: >>> >>> /* mapping between ECCurveName enum and pointers to ECCurveParams */ >>> ?static const ECCurveParams *ecCurve_map[] = { >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ECCurve_noName */ >>> - ? ?&ecCurve_NIST_P192, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P192 */ >>> - ? ?&ecCurve_NIST_P224, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P224 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_P192 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_P224 */ >>> ? ? &ecCurve_NIST_P256, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P256 */ >>> ? ? &ecCurve_NIST_P384, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P384 */ >>> ? ? &ecCurve_NIST_P521, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P521 */ >>> - ? ?&ecCurve_NIST_K163, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K163 */ >>> - ? ?&ecCurve_NIST_B163, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B163 */ >>> - ? ?&ecCurve_NIST_K233, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K233 */ >>> - ? ?&ecCurve_NIST_B233, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B233 */ >>> - ? ?&ecCurve_NIST_K283, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K283 */ >>> - ? ?&ecCurve_NIST_B283, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B283 */ >>> - ? ?&ecCurve_NIST_K409, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K409 */ >>> - ? ?&ecCurve_NIST_B409, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B409 */ >>> - ? ?&ecCurve_NIST_K571, ? ? ? ? ? ? ? ? /* ECCurve_NIST_K571 */ >>> - ? ?&ecCurve_NIST_B571, ? ? ? ? ? ? ? ? /* ECCurve_NIST_B571 */ >>> - ? ?&ecCurve_X9_62_PRIME_192V2, ? ? ? ? /* ECCurve_X9_62_PRIME_192V2 */ >>> - ? ?&ecCurve_X9_62_PRIME_192V3, ? ? ? ? /* ECCurve_X9_62_PRIME_192V3 */ >>> - ? ?&ecCurve_X9_62_PRIME_239V1, ? ? ? ? /* ECCurve_X9_62_PRIME_239V1 */ >>> - ? ?&ecCurve_X9_62_PRIME_239V2, ? ? ? ? /* ECCurve_X9_62_PRIME_239V2 */ >>> - ? ?&ecCurve_X9_62_PRIME_239V3, ? ? ? ? /* ECCurve_X9_62_PRIME_239V3 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB163V1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB163V1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB163V2, ? ? ?/* ECCurve_X9_62_CHAR2_PNB163V2 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB163V3, ? ? ?/* ECCurve_X9_62_CHAR2_PNB163V3 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB176V1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB176V1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB191V1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB191V1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB191V2, ? ? ?/* ECCurve_X9_62_CHAR2_TNB191V2 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB191V3, ? ? ?/* ECCurve_X9_62_CHAR2_TNB191V3 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB208W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB208W1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB239V1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB239V1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB239V2, ? ? ?/* ECCurve_X9_62_CHAR2_TNB239V2 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB239V3, ? ? ?/* ECCurve_X9_62_CHAR2_TNB239V3 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB272W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB272W1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB304W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB304W1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB359V1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB359V1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_PNB368W1, ? ? ?/* ECCurve_X9_62_CHAR2_PNB368W1 */ >>> - ? ?&ecCurve_X9_62_CHAR2_TNB431R1, ? ? ?/* ECCurve_X9_62_CHAR2_TNB431R1 */ >>> - ? ?&ecCurve_SECG_PRIME_112R1, ? ? ? ? ?/* ECCurve_SECG_PRIME_112R1 */ >>> - ? ?&ecCurve_SECG_PRIME_112R2, ? ? ? ? ?/* ECCurve_SECG_PRIME_112R2 */ >>> - ? ?&ecCurve_SECG_PRIME_128R1, ? ? ? ? ?/* ECCurve_SECG_PRIME_128R1 */ >>> - ? ?&ecCurve_SECG_PRIME_128R2, ? ? ? ? ?/* ECCurve_SECG_PRIME_128R2 */ >>> - ? ?&ecCurve_SECG_PRIME_160K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_160K1 */ >>> - ? ?&ecCurve_SECG_PRIME_160R1, ? ? ? ? ?/* ECCurve_SECG_PRIME_160R1 */ >>> - ? ?&ecCurve_SECG_PRIME_160R2, ? ? ? ? ?/* ECCurve_SECG_PRIME_160R2 */ >>> - ? ?&ecCurve_SECG_PRIME_192K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_192K1 */ >>> - ? ?&ecCurve_SECG_PRIME_224K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_224K1 */ >>> - ? ?&ecCurve_SECG_PRIME_256K1, ? ? ? ? ?/* ECCurve_SECG_PRIME_256K1 */ >>> - ? ?&ecCurve_SECG_CHAR2_113R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_113R1 */ >>> - ? ?&ecCurve_SECG_CHAR2_113R2, ? ? ? ? ?/* ECCurve_SECG_CHAR2_113R2 */ >>> - ? ?&ecCurve_SECG_CHAR2_131R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_131R1 */ >>> - ? ?&ecCurve_SECG_CHAR2_131R2, ? ? ? ? ?/* ECCurve_SECG_CHAR2_131R2 */ >>> - ? ?&ecCurve_SECG_CHAR2_163R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_163R1 */ >>> - ? ?&ecCurve_SECG_CHAR2_193R1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_193R1 */ >>> - ? ?&ecCurve_SECG_CHAR2_193R2, ? ? ? ? ?/* ECCurve_SECG_CHAR2_193R2 */ >>> - ? ?&ecCurve_SECG_CHAR2_239K1, ? ? ? ? ?/* ECCurve_SECG_CHAR2_239K1 */ >>> - ? ?&ecCurve_WTLS_1, ? ? ? ? ? ? ? ? ? ?/* ECCurve_WTLS_1 */ >>> - ? ?&ecCurve_WTLS_8, ? ? ? ? ? ? ? ? ? ?/* ECCurve_WTLS_8 */ >>> - ? ?&ecCurve_WTLS_9, ? ? ? ? ? ? ? ? ? ?/* ECCurve_WTLS_9 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K163 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B163 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K233 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B233 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K283 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B283 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K409 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B409 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_K571 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_NIST_B571 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_192V2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_192V3 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_239V1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_239V2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_PRIME_239V3 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB163V1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB163V2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB163V3 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB176V1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB191V1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB191V2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB191V3 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB208W1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB239V1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB239V2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB239V3 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB272W1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB304W1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB359V1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_PNB368W1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_X9_62_CHAR2_TNB431R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_112R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_112R2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_128R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_128R2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_160K1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_160R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_160R2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_192K1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_224K1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_PRIME_256K1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_113R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_113R2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_131R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_131R2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_163R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_193R1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_193R2 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_SECG_CHAR2_239K1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_WTLS_1 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_WTLS_8 */ >>> + ? ? ? NULL, ? ? ? ? ? ? ? ? ? /* ECCurve_WTLS_9 */ >>> ? ? NULL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* ECCurve_pastLastCurve */ >>> ?}; >>> >>> >>> It could be a NSS version issue, but seems more deliberate to me. >>> It leaves three curves: >>> ? ? &ecCurve_NIST_P256, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P256 */ >>> ? ? &ecCurve_NIST_P384, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P384 */ >>> ? ? &ecCurve_NIST_P521, ? ? ? ? ? ? ? ? /* ECCurve_NIST_P521 */ >>> >>>>> I'm afraid my current impression of this changeset is that it doesn't >>>>> help us with packaging OpenJDK for GNU/Linux distributions at all, but >>>>> instead makes things ten times worse as there is now a stale NSS to >>>>> contend with. ?Not only are there the issues with bit rot I alluded to >>>>> last time, but as you mention in your reply there are legal issues >>>>> with EC support. ?Notably, I've found that Fedora doesn't ship any EC >>>>> support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd >>>>> have to rip this out in packages for that distribution (and it's >>>>> dubious whether others should be shipping it). ?IANAL, so I won't >>>>> comment further on such issues, but suffice to say this changeset >>>>> significantly reduces the options for handling NSS support downstream. >>>>> ?In contrast, the existing support in 1.6 is almost ideal, once you've >>>>> discovered how it works; the distro packager can choose whether to >>>>> enable support or not and they don't have to worry about rotting >>>>> security code in OpenJDK. ?Maybe I'm missing something but this makes >>>>> me think this would have been better as a local addition to Sun's >>>>> proprietary builds rather than adding it to OpenJDK. >>>>> >>>>> I try to be as positive as I can about the OpenJDK project, but I'm >>>>> sorry to say that changesets like this don't help. ?I actually find >>>>> them quite depressing. ?As I said in my previous email, there appears >>>>> to have been no discussion of this change; it was merely committed >>>>> with no public review and appeared in b70. ?Meanwhile, myself and >>>>> other external contributors have to spend days trying to get replies >>>>> to emails to even get a simple bug fix in (I've lost count of how many >>>>> I still have waiting; there must be at least four or five). ?That's >>>>> just not fair and doesn't bode well for a successful community >>>>> project. >>>>> >>>>> Thanks, >>>> >>> Cheers, >>> -- >>> 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 >>> >> >> I've added this changeset: >> >> http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/2a1a7fb44226 >> >> to the IcedTea project's JDK7 forest to solve this issue. ?If it looks >> ok, then give me a bug ID and I'll push it to tl-gate. > -- 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 tim.bell at sun.com Fri Sep 18 09:27:14 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:27:14 +0000 Subject: [security-dev 01228]: hg: jdk7/tl: Added tag jdk7-b72 for changeset 0d7e03b426df Message-ID: <20090918162715.46E7112494@hg.openjdk.java.net> Changeset: 4c4fe09fb670 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4c4fe09fb670 Added tag jdk7-b72 for changeset 0d7e03b426df ! .hgtags From tim.bell at sun.com Fri Sep 18 09:27:45 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:27:45 +0000 Subject: [security-dev 01229]: hg: jdk7/tl/corba: Added tag jdk7-b72 for changeset c793a3120926 Message-ID: <20090918162747.6A4FD12499@hg.openjdk.java.net> Changeset: 12991b453239 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/12991b453239 Added tag jdk7-b72 for changeset c793a3120926 ! .hgtags From tim.bell at sun.com Fri Sep 18 09:29:15 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:29:15 +0000 Subject: [security-dev 01230]: hg: jdk7/tl/hotspot: Added tag jdk7-b72 for changeset a94714c55065 Message-ID: <20090918162923.A45D61249E@hg.openjdk.java.net> Changeset: 1e5f0e56d242 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1e5f0e56d242 Added tag jdk7-b72 for changeset a94714c55065 ! .hgtags From tim.bell at sun.com Fri Sep 18 09:32:57 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:32:57 +0000 Subject: [security-dev 01231]: hg: jdk7/tl/jaxp: Added tag jdk7-b72 for changeset 37c805b6156f Message-ID: <20090918163259.BDEBA124A3@hg.openjdk.java.net> Changeset: 93dfa6e0fe76 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/93dfa6e0fe76 Added tag jdk7-b72 for changeset 37c805b6156f ! .hgtags From tim.bell at sun.com Fri Sep 18 09:33:32 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:33:32 +0000 Subject: [security-dev 01232]: hg: jdk7/tl/jaxws: Added tag jdk7-b72 for changeset 4c990aa99bc0 Message-ID: <20090918163335.CF608124A8@hg.openjdk.java.net> Changeset: d79f0d601c2b Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d79f0d601c2b Added tag jdk7-b72 for changeset 4c990aa99bc0 ! .hgtags From tim.bell at sun.com Fri Sep 18 09:34:32 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:34:32 +0000 Subject: [security-dev 01233]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090918163545.6099B124AD@hg.openjdk.java.net> Changeset: f09a2bfba691 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f09a2bfba691 Added tag jdk7-b72 for changeset 460639b036f3 ! .hgtags Changeset: f119e21c0ca7 Author: tbell Date: 2009-09-18 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f119e21c0ca7 Merge From tim.bell at sun.com Fri Sep 18 09:38:22 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Sep 2009 16:38:22 +0000 Subject: [security-dev 01234]: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20090918163829.C000A124B2@hg.openjdk.java.net> Changeset: bfad32768345 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bfad32768345 Added tag jdk7-b72 for changeset 261c54b2312e ! .hgtags Changeset: 5dd400fd62d9 Author: tbell Date: 2009-09-18 08:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5dd400fd62d9 Merge From christopher.hegarty at sun.com Fri Sep 18 14:21:56 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Fri, 18 Sep 2009 21:21:56 +0000 Subject: [security-dev 01235]: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20090918212320.2ACA81252D@hg.openjdk.java.net> Changeset: c9cbd2a09fd4 Author: chegar Date: 2009-09-18 16:24 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c9cbd2a09fd4 6882609: Move default InMemoryCookieStore to java.net Summary: remove static dependency on sun.net.www.protocol.http Reviewed-by: alanb, jccollet ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/CookieManager.java + src/share/classes/java/net/InMemoryCookieStore.java - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java Changeset: 9cd7133ea287 Author: chegar Date: 2009-09-18 22:18 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cd7133ea287 6882594: Remove static dependancy on NTLM authentication Reviewed-by: alanb, weijun ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/net/www/protocol/http/AuthCache.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java + src/share/classes/sun/net/www/protocol/http/AuthScheme.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 45a343706f73 Author: chegar Date: 2009-09-18 22:19 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45a343706f73 Merge From mandy.chung at sun.com Fri Sep 18 18:51:57 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Sat, 19 Sep 2009 01:51:57 +0000 Subject: [security-dev 01236]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090919015248.8C8E8125E7@hg.openjdk.java.net> Changeset: d3281fa8e46c Author: mchung Date: 2009-09-17 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3281fa8e46c 6882376: Add internal support for JRE implementation to eliminate the dependency on logging Summary: Added sun.util.logging.PlatformLogger for JRE implementation to log messages. Reviewed-by: alanb, naoto ! make/java/logging/Makefile ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java + src/share/classes/sun/util/logging/PlatformLogger.java ! src/windows/classes/java/util/prefs/WindowsPreferences.java + test/sun/util/logging/PlatformLoggerTest.java Changeset: 7b4e73ca6fd7 Author: mchung Date: 2009-09-18 17:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b4e73ca6fd7 Merge From vincent.ryan at sun.com Mon Sep 21 15:16:14 2009 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Mon, 21 Sep 2009 22:16:14 +0000 Subject: [security-dev 01237]: hg: jdk7/tl/jdk: 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Message-ID: <20090921221715.ED322126A6@hg.openjdk.java.net> Changeset: 845fefff00a4 Author: vinnie Date: 2009-09-21 23:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/845fefff00a4 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: wetmore ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/native/sun/security/ec/ECC_JNI.cpp - src/share/native/sun/security/ec/ec.c + src/share/native/sun/security/ec/impl/ec.c + src/share/native/sun/security/ec/impl/ec.h + src/share/native/sun/security/ec/impl/ec2.h + src/share/native/sun/security/ec/impl/ec2_163.c + src/share/native/sun/security/ec/impl/ec2_193.c + src/share/native/sun/security/ec/impl/ec2_233.c + src/share/native/sun/security/ec/impl/ec2_aff.c + src/share/native/sun/security/ec/impl/ec2_mont.c + src/share/native/sun/security/ec/impl/ec_naf.c + src/share/native/sun/security/ec/impl/ecc_impl.h + src/share/native/sun/security/ec/impl/ecdecode.c + src/share/native/sun/security/ec/impl/ecl-curve.h + src/share/native/sun/security/ec/impl/ecl-exp.h + src/share/native/sun/security/ec/impl/ecl-priv.h + src/share/native/sun/security/ec/impl/ecl.c + src/share/native/sun/security/ec/impl/ecl.h + src/share/native/sun/security/ec/impl/ecl_curve.c + src/share/native/sun/security/ec/impl/ecl_gf.c + src/share/native/sun/security/ec/impl/ecl_mult.c + src/share/native/sun/security/ec/impl/ecp.h + src/share/native/sun/security/ec/impl/ecp_192.c + src/share/native/sun/security/ec/impl/ecp_224.c + src/share/native/sun/security/ec/impl/ecp_256.c + src/share/native/sun/security/ec/impl/ecp_384.c + src/share/native/sun/security/ec/impl/ecp_521.c + src/share/native/sun/security/ec/impl/ecp_aff.c + src/share/native/sun/security/ec/impl/ecp_jac.c + src/share/native/sun/security/ec/impl/ecp_jm.c + src/share/native/sun/security/ec/impl/ecp_mont.c + src/share/native/sun/security/ec/impl/logtab.h + src/share/native/sun/security/ec/impl/mp_gf2m-priv.h + src/share/native/sun/security/ec/impl/mp_gf2m.c + src/share/native/sun/security/ec/impl/mp_gf2m.h + src/share/native/sun/security/ec/impl/mpi-config.h + src/share/native/sun/security/ec/impl/mpi-priv.h + src/share/native/sun/security/ec/impl/mpi.c + src/share/native/sun/security/ec/impl/mpi.h + src/share/native/sun/security/ec/impl/mplogic.c + src/share/native/sun/security/ec/impl/mplogic.h + src/share/native/sun/security/ec/impl/mpmontg.c + src/share/native/sun/security/ec/impl/mpprime.h + src/share/native/sun/security/ec/impl/oid.c + src/share/native/sun/security/ec/impl/secitem.c + src/share/native/sun/security/ec/impl/secoidt.h ! test/sun/security/ec/TestEC.java + test/sun/security/ec/certs/sunlabscerts.pem + test/sun/security/ec/keystore + test/sun/security/ec/truststore ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/sslecc/CipherTest.java From weijun.wang at sun.com Mon Sep 21 19:03:40 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 22 Sep 2009 02:03:40 +0000 Subject: [security-dev 01238]: hg: jdk7/tl/jdk: 6877357: IPv6 address does not work Message-ID: <20090922020417.316C0126D0@hg.openjdk.java.net> Changeset: 81dffe63c913 Author: weijun Date: 2009-09-22 10:01 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/81dffe63c913 6877357: IPv6 address does not work Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/krb5/KrbKdcReq.java + test/sun/security/krb5/IPv6.java From joe.darcy at sun.com Mon Sep 21 21:09:19 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 22 Sep 2009 04:09:19 +0000 Subject: [security-dev 01239]: hg: jdk7/tl/langtools: 6884227: Clarify ordering requirements of javax.lang.model.TypeElement.getEnclosedElements Message-ID: <20090922040921.9BEFB126E5@hg.openjdk.java.net> Changeset: 789ee1acf107 Author: darcy Date: 2009-09-21 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/789ee1acf107 6884227: Clarify ordering requirements of javax.lang.model.TypeElement.getEnclosedElements Reviewed-by: ahe ! src/share/classes/javax/lang/model/element/TypeElement.java From Weijun.Wang at Sun.COM Tue Sep 22 00:26:58 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 22 Sep 2009 15:26:58 +0800 Subject: [security-dev 01240]: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling References: <810427.1253583171156.JavaMail.sbladm@swsblss3-new> Message-ID: <75745240-D2CA-482E-B4A0-CFDF27A5BD8F@Sun.COM> Hi Andrew Please take a review on this code change: http://cr.openjdk.java.net/~weijun/6880321/webrev.00/ Thanks Max > > *Change Request ID*: 6880321 > > *Synopsis*: sun.security.provider.JavaKeyStore abuse of OOM > Exception handling > > === *Description* > ============================================================ > FULL PRODUCT VERSION : > 1.6.0.X > > A DESCRIPTION OF THE PROBLEM : > This class catches OOM exceptions and throws Non chainen IOException. > > This is a massive abuse of exception handling and hides errors > information from the caller. It also misleads the caller to the > reason for the error > > EXPECTED VERSUS ACTUAL BEHAVIOR : > EXPECTED - > Provider proper chained exceptions or Dont catch OOM errors > > REPRODUCIBILITY : > This bug can be reproduced always. From fweimer at bfk.de Tue Sep 22 01:09:57 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 22 Sep 2009 08:09:57 +0000 Subject: [security-dev 01241]: Re: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling In-Reply-To: <75745240-D2CA-482E-B4A0-CFDF27A5BD8F@Sun.COM> (Max Wang's message of "Tue\, 22 Sep 2009 15\:26\:58 +0800") References: <810427.1253583171156.JavaMail.sbladm@swsblss3-new> <75745240-D2CA-482E-B4A0-CFDF27A5BD8F@Sun.COM> Message-ID: <82hbuvflii.fsf@mid.bfk.de> * Max Wang: > Please take a review on this code change: > > http://cr.openjdk.java.net/~weijun/6880321/webrev.00/ This code is still unreliable. You cannot hide OutOfMemoryError this way. The error could even be thrown in a completely unrelated thread. There is no really good way to deal with this type of resource exhaustation. To deal with corrupted files, it is sufficient to grow arrays as the file is read, so you will hit the end of the file before the OOM error occurs. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Weijun.Wang at Sun.COM Tue Sep 22 01:59:09 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 22 Sep 2009 16:59:09 +0800 Subject: [security-dev 01242]: Re: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling In-Reply-To: <82hbuvflii.fsf@mid.bfk.de> References: <810427.1253583171156.JavaMail.sbladm@swsblss3-new> <75745240-D2CA-482E-B4A0-CFDF27A5BD8F@Sun.COM> <82hbuvflii.fsf@mid.bfk.de> Message-ID: On Sep 22, 2009, at 4:09 PM, Florian Weimer wrote: > * Max Wang: > >> Please take a review on this code change: >> >> http://cr.openjdk.java.net/~weijun/6880321/webrev.00/ > > This code is still unreliable. You cannot hide OutOfMemoryError this > way. The error could even be thrown in a completely unrelated thread. > > There is no really good way to deal with this type of resource > exhaustation. To deal with corrupted files, it is sufficient to grow > arrays as the file is read, so you will hit the end of the file before > the OOM error occurs. This sounds better. Thanks Max > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 From Xuelei.Fan at Sun.COM Tue Sep 22 03:10:52 2009 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Tue, 22 Sep 2009 18:10:52 +0800 Subject: [security-dev 01243]: Re: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling In-Reply-To: References: <810427.1253583171156.JavaMail.sbladm@swsblss3-new> <75745240-D2CA-482E-B4A0-CFDF27A5BD8F@Sun.COM> <82hbuvflii.fsf@mid.bfk.de> Message-ID: <4AB8A2AC.3090506@Sun.COM> Max (Weijun) Wang wrote: > > On Sep 22, 2009, at 4:09 PM, Florian Weimer wrote: > >> * Max Wang: >> >>> Please take a review on this code change: >>> >>> http://cr.openjdk.java.net/~weijun/6880321/webrev.00/ >> >> This code is still unreliable. You cannot hide OutOfMemoryError this >> way. The error could even be thrown in a completely unrelated thread. >> >> There is no really good way to deal with this type of resource >> exhaustation. To deal with corrupted files, it is sufficient to grow >> arrays as the file is read, so you will hit the end of the file before >> the OOM error occurs. > > This sounds better. Sounds better to me also. Andrew > > Thanks > Max > >> >> -- >> Florian Weimer >> BFK edv-consulting GmbH http://www.bfk.de/ >> Kriegsstra?e 100 tel: +49-721-96201-1 >> D-76133 Karlsruhe fax: +49-721-96201-99 > From gnu_andrew at member.fsf.org Tue Sep 22 03:18:34 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 22 Sep 2009 11:18:34 +0100 Subject: [security-dev 01244]: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 Message-ID: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> 2009/9/2 Andrew John Hughes : > 2009/9/2 Michael StJohns : >> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>2009/9/2 Michael StJohns : >>>> ? This appears to be related specifically to PKCS11.? ?Specifically, PKCS11 >>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>> different in the text than an ASN1 ECPoint). >>>> >>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>> format described in? ?X9.62, where the first octet indicates the encoding and >>>> there are either N or 2N octets following)? ?being the expected value, but >>>> with PKCS11 providers allowed - legacy - to accept either. >>>> >>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>> interpreted the issue and implemented its code. >>>> >>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>> of the problem.? ?The other half is related to encoding the value.? ?Also, >>>> changing the code at decodePoint seems further into the stack than needed >>>> and may affect other uses of that method. >>>> >>> >>>That's really too vague to be of much help in improving the patch. >>>You seem to be saying little more than 'I don't like it'. >> >> Sorry about that. ?My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >> >> >>>> There's an existing JDK bug on this coming at it from a different direction >>>> - 6763530 ... and there may be considerations at >>>> >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>> >>> >>>It seems likely that's the NSS change that causes the current failure. >>> The fix I submitted here is based on the way this is handle in NSS. >>>In fact, the code is similar enough to suggest that one was developed >>>from the other. >>> >>>> ? that should be looked at. >>> >>>The JDK bug is not really 'from a different direction', it's reporting >>>exactly the same error but from a less trivial example (I get the same >>>failure while trying to create an example key, while this seems to >>>require specific hardware if I'm reading it correctly). >> >> Not exactly. ?You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >> >> >>>Also see 6779460 which is mostly a duplicate of >>>> 6763530. >>>> >>> >>>The patch on 6779460 seems wrong. ?It means that the method will >>>return a DER-encoded value where it would either have returned an >>>uncompressed value before or failed. >> >> My point exactly as I mentioned in the comments. ?:-) >> >> >>>> >>>> It's probable that the fix I suggested at 6763530? ?(in comments submitted 29 >>>> Nov 08) may be a better approach given the NSS fixes.? ?I believe it will fix >>>> the keytool problem noted in the original message. >>>> >>> >>>Ok, I can see the logic in the fix and it would appear to work, though >>>I haven't tested it. >>>Given the patch was written nine months ago, why has it not been >>>applied? ?If it had, it would have saved me hours having to debug this >>>same issue again. >> >> Yup. ?I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >> >>>Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>patch and we can finally get this fixed. ?Without it, NSS support is >>>completely broken in OpenJDK6 which makes me wonder why this is a low >>>priority bug! >> >> I do have an SCA on file. ?Note that the recommendation from the NSS guys was to raise the priority. >> >> The reason I haven't submitted this is because I submitted a different EC fix ?https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >> ?and was waiting on progress there before continuing. ?I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. ?And then I got busy with some other things... >> >> Mike >> >> >> >> >> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>> >>>> Andrew John Hughes wrote: >>>> >>>> 2009/8/28 Andrew John Hughes : >>>> >>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>> if the PKCS11 provider is configured to point to NSS. See: >>>> >>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>> >>>> If NSS is configured as specified in this blog, keytool can be used to >>>> generate a key as follows: >>>> >>>> Hello. >>>> >>>> Allowing keytool and friends to work in more cases if the provider is >>>> capable seems fine to me. >>>> >>>> Security team, do you have concerns about this patch? >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>> >>> >>> >>>-- >>>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 >> >> >> > > Ok here is a new webrev: > > http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ > > with a slightly revised version of your change (you can't throw a > PKCS11Exception which only takes a long ID from the native code, so I > changed this to an IllegalArgumentException). > > Security team, does this look ok to push? > -- > 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 > Ping! Security developers, any thoughts on this patch: http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ Does it look ok to push? Thanks, -- 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 Tue Sep 22 06:51:10 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 22 Sep 2009 13:51:10 +0000 Subject: [security-dev 01245]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090922135200.99A751275B@hg.openjdk.java.net> Changeset: 023063a403ed Author: chegar Date: 2009-09-22 14:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/023063a403ed 6882654: Remove dependency on java.util.concurrent from KeepAlive implementaion Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java Changeset: 44ccaa4bb8a0 Author: chegar Date: 2009-09-22 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44ccaa4bb8a0 6882384: Update http protocol handler to use PlatformLogger Reviewed-by: jccollet, alanb ! src/share/classes/sun/net/www/http/HttpCapture.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/util/logging/PlatformLogger.java From kevin.walls at sun.com Tue Sep 22 09:17:22 2009 From: kevin.walls at sun.com (kevin.walls at sun.com) Date: Tue, 22 Sep 2009 16:17:22 +0000 Subject: [security-dev 01246]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090922161810.7485412766@hg.openjdk.java.net> Changeset: b8004f6f4812 Author: kevinw Date: 2009-09-22 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8004f6f4812 6882768: (launcher) test for 6842838 is broken Summary: Testcase correction. Reviewed-by: ksrini ! test/tools/launcher/6842838/Test6842838.sh Changeset: f708138c9aca Author: kevinw Date: 2009-09-22 17:16 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f708138c9aca Merge From joe.darcy at sun.com Tue Sep 22 16:11:07 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 22 Sep 2009 23:11:07 +0000 Subject: [security-dev 01247]: hg: jdk7/tl/jdk: 6468534: (reflect) Exception types cannot be parameterized, rephrase getGenericExceptionTypes. Message-ID: <20090922231202.85783127D6@hg.openjdk.java.net> Changeset: c715b68cdcaf Author: darcy Date: 2009-09-22 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c715b68cdcaf 6468534: (reflect) Exception types cannot be parameterized, rephrase getGenericExceptionTypes. Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java From martinrb at google.com Tue Sep 22 18:40:37 2009 From: martinrb at google.com (martinrb at google.com) Date: Wed, 23 Sep 2009 01:40:37 +0000 Subject: [security-dev 01248]: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090923014109.01775127ED@hg.openjdk.java.net> Changeset: bbb543254c63 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bbb543254c63 4245470: algorithm of java.lang.Byte.hashCode() is not specified Summary: Specify some hashCode methods are equivalent to intValue Reviewed-by: darcy ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Short.java + test/java/lang/HashCode.java Changeset: eb92c939b8a7 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb92c939b8a7 6582946: Add suite of compare(T, T) methods for ints, longs etc Reviewed-by: darcy Contributed-by: kevinb at google.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Compare.java From joe.darcy at sun.com Wed Sep 23 18:30:26 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 24 Sep 2009 01:30:26 +0000 Subject: [security-dev 01249]: hg: jdk7/tl/langtools: 6517779: javax.lang.model.util.Elements.getConstantExpression() doesn't throw any exception; ... Message-ID: <20090924013028.87B1512856@hg.openjdk.java.net> Changeset: e992e602788e Author: darcy Date: 2009-09-23 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e992e602788e 6517779: javax.lang.model.util.Elements.getConstantExpression() doesn't throw any exception 6517907: javax.lang.model.util.Elements.getConstantExpression() with negative byte value fails Summary: Fix various problems with Elements.getConstantExpression() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/Convert.java + test/tools/javac/processing/model/util/elements/Foo.java + test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java From jonathan.gibbons at sun.com Wed Sep 23 18:49:47 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 24 Sep 2009 01:49:47 +0000 Subject: [security-dev 01250]: hg: jdk7/tl/langtools: 6410637: Make decision on deprecated methods in DefaultFileManager and BaseFileObject.; ... Message-ID: <20090924014949.1C3811285D@hg.openjdk.java.net> Changeset: 49359d0e6a9c Author: jjg Date: 2009-09-23 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/49359d0e6a9c 6410637: Make decision on deprecated methods in DefaultFileManager and BaseFileObject. 6747645: ZipFileObject.getName is incorrectly deprecated 6885123: JavaFileObject getName issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/javax/tools/SimpleJavaFileObject.java + test/tools/javac/4241573/T4241573.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T6705935.java ! test/tools/javac/api/6411310/T6411310.java + test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/6733837/T6733837.java From jonathan.gibbons at sun.com Wed Sep 23 19:16:34 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 24 Sep 2009 02:16:34 +0000 Subject: [security-dev 01251]: hg: jdk7/tl/langtools: 6572945: javah should be written as an annotation processor, not a doclet Message-ID: <20090924021636.53D0D12862@hg.openjdk.java.net> Changeset: c287d51c57da Author: jjg Date: 2009-09-23 19:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c287d51c57da 6572945: javah should be written as an annotation processor, not a doclet Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/tools/javah/Gen.java + src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java + src/share/classes/com/sun/tools/javah/JavahFileManager.java + src/share/classes/com/sun/tools/javah/JavahTask.java + src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java - src/share/classes/com/sun/tools/javah/MainDoclet.java ! src/share/classes/com/sun/tools/javah/Mangle.java + src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties ! src/share/classes/com/sun/tools/javah/resources/l10n.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java + test/tools/javah/6572945/T6572945.java + test/tools/javah/6572945/TestClass1.java + test/tools/javah/6572945/TestClass2.java + test/tools/javah/6572945/TestClass3.java + test/tools/javah/6572945/gold/jni.dir.1/TestClass1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner2.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass2.h + test/tools/javah/6572945/gold/jni.file.1 + test/tools/javah/6572945/gold/jni.file.2 + test/tools/javah/6572945/gold/jni.file.3 ! test/tools/javah/MissingParamClassTest.sh + test/tools/javah/compareTest/CompareTest.java + test/tools/javah/compareTest/CompareTest.sh + test/tools/javah/compareTest/FindNativeFiles.java + test/tools/javah/compareTest/README From weijun.wang at sun.com Thu Sep 24 06:38:25 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 24 Sep 2009 13:38:25 +0000 Subject: [security-dev 01252]: hg: jdk7/tl/jdk: 6885166: regression test for 6877357 (IPv6 address does not work) error (timed out) Message-ID: <20090924133901.793EC12878@hg.openjdk.java.net> Changeset: bd928aefe692 Author: weijun Date: 2009-09-24 21:35 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd928aefe692 6885166: regression test for 6877357 (IPv6 address does not work) error (timed out) Reviewed-by: xuelei ! test/sun/security/krb5/IPv6.java From Vincent.Ryan at Sun.COM Thu Sep 24 10:33:09 2009 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Thu, 24 Sep 2009 18:33:09 +0100 Subject: [security-dev 01253]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> Message-ID: <4ABBAD55.7070206@sun.com> Hello Andrew, I'll need a little more time to come up to speed on this fix. I'm concerned that there may be interoperability or backwards compatibility issues. Andrew John Hughes wrote: > 2009/9/2 Andrew John Hughes : >> 2009/9/2 Michael StJohns : >>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>> 2009/9/2 Michael StJohns : >>>>> ? This appears to be related specifically to PKCS11.? Specifically, PKCS11 >>>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>>> different in the text than an ASN1 ECPoint). >>>>> >>>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>>> format described in? X9.62, where the first octet indicates the encoding and >>>>> there are either N or 2N octets following)? being the expected value, but >>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>> >>>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>>> interpreted the issue and implemented its code. >>>>> >>>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>>> of the problem.? The other half is related to encoding the value.? Also, >>>>> changing the code at decodePoint seems further into the stack than needed >>>>> and may affect other uses of that method. >>>>> >>>> That's really too vague to be of much help in improving the patch. >>>> You seem to be saying little more than 'I don't like it'. >>> Sorry about that. My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >>> >>> >>>>> There's an existing JDK bug on this coming at it from a different direction >>>>> - 6763530 ... and there may be considerations at >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>> >>>> It seems likely that's the NSS change that causes the current failure. >>>> The fix I submitted here is based on the way this is handle in NSS. >>>> In fact, the code is similar enough to suggest that one was developed >>> >from the other. >>>>> ? that should be looked at. >>>> The JDK bug is not really 'from a different direction', it's reporting >>>> exactly the same error but from a less trivial example (I get the same >>>> failure while trying to create an example key, while this seems to >>>> require specific hardware if I'm reading it correctly). >>> Not exactly. You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >>> >>> >>>> Also see 6779460 which is mostly a duplicate of >>>>> 6763530. >>>>> >>>> The patch on 6779460 seems wrong. It means that the method will >>>> return a DER-encoded value where it would either have returned an >>>> uncompressed value before or failed. >>> My point exactly as I mentioned in the comments. :-) >>> >>> >>>>> It's probable that the fix I suggested at 6763530? (in comments submitted 29 >>>>> Nov 08) may be a better approach given the NSS fixes.? I believe it will fix >>>>> the keytool problem noted in the original message. >>>>> >>>> Ok, I can see the logic in the fix and it would appear to work, though >>>> I haven't tested it. >>>> Given the patch was written nine months ago, why has it not been >>>> applied? If it had, it would have saved me hours having to debug this >>>> same issue again. >>> Yup. I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >>> >>>> Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>> patch and we can finally get this fixed. Without it, NSS support is >>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>> priority bug! >>> I do have an SCA on file. Note that the recommendation from the NSS guys was to raise the priority. >>> >>> The reason I haven't submitted this is because I submitted a different EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >>> and was waiting on progress there before continuing. I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. And then I got busy with some other things... >>> >>> Mike >>> >>> >>> >>> >>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> 2009/8/28 Andrew John Hughes : >>>>> >>>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>> >>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>> >>>>> If NSS is configured as specified in this blog, keytool can be used to >>>>> generate a key as follows: >>>>> >>>>> Hello. >>>>> >>>>> Allowing keytool and friends to work in more cases if the provider is >>>>> capable seems fine to me. >>>>> >>>>> Security team, do you have concerns about this patch? >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> >> Ok here is a new webrev: >> >> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >> >> with a slightly revised version of your change (you can't throw a >> PKCS11Exception which only takes a long ID from the native code, so I >> changed this to an IllegalArgumentException). >> >> Security team, does this look ok to push? >> -- >> 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 >> > > Ping! Security developers, any thoughts on this patch: > > http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ > > Does it look ok to push? > > Thanks, From gnu_andrew at member.fsf.org Thu Sep 24 12:58:36 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 24 Sep 2009 20:58:36 +0100 Subject: [security-dev 01254]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4ABBAD55.7070206@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> Message-ID: <17c6771e0909241258w49131220lba7363fc30a3e5f5@mail.gmail.com> 2009/9/24 Vincent Ryan : > Hello Andrew, > > I'll need a little more time to come up to speed on this fix. I'm concerned that > there may be interoperability or backwards compatibility issues. > Hi Vincent, Let me know if there's anything to do to help. The original version I proposed: http://cr.openjdk.java.net/~andrew/6763530/webrev.01/ was less intrusive, only causing a change in behaviour if the value had already been judged unusable by the previous code. Michael's response suggested this wasn't the correct way to fix it, but both do work. > > > Andrew John Hughes wrote: >> 2009/9/2 Andrew John Hughes : >>> 2009/9/2 Michael StJohns : >>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>> 2009/9/2 Michael StJohns : >>>>>> ? This appears to be related specifically to PKCS11.? ?Specifically, PKCS11 >>>>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>>>> different in the text than an ASN1 ECPoint). >>>>>> >>>>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>>>> format described in? ?X9.62, where the first octet indicates the encoding and >>>>>> there are either N or 2N octets following)? ?being the expected value, but >>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>> >>>>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>>>> interpreted the issue and implemented its code. >>>>>> >>>>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>>>> of the problem.? ?The other half is related to encoding the value.? ?Also, >>>>>> changing the code at decodePoint seems further into the stack than needed >>>>>> and may affect other uses of that method. >>>>>> >>>>> That's really too vague to be of much help in improving the patch. >>>>> You seem to be saying little more than 'I don't like it'. >>>> Sorry about that. ?My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >>>> >>>> >>>>>> There's an existing JDK bug on this coming at it from a different direction >>>>>> - 6763530 ... and there may be considerations at >>>>>> >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>> >>>>> It seems likely that's the NSS change that causes the current failure. >>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>> In fact, the code is similar enough to suggest that one was developed >>>> >from the other. >>>>>> ? that should be looked at. >>>>> The JDK bug is not really 'from a different direction', it's reporting >>>>> exactly the same error but from a less trivial example (I get the same >>>>> failure while trying to create an example key, while this seems to >>>>> require specific hardware if I'm reading it correctly). >>>> Not exactly. ?You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >>>> >>>> >>>>> Also see 6779460 which is mostly a duplicate of >>>>>> 6763530. >>>>>> >>>>> The patch on 6779460 seems wrong. ?It means that the method will >>>>> return a DER-encoded value where it would either have returned an >>>>> uncompressed value before or failed. >>>> My point exactly as I mentioned in the comments. ?:-) >>>> >>>> >>>>>> It's probable that the fix I suggested at 6763530? ?(in comments submitted 29 >>>>>> Nov 08) may be a better approach given the NSS fixes.? ?I believe it will fix >>>>>> the keytool problem noted in the original message. >>>>>> >>>>> Ok, I can see the logic in the fix and it would appear to work, though >>>>> I haven't tested it. >>>>> Given the patch was written nine months ago, why has it not been >>>>> applied? ?If it had, it would have saved me hours having to debug this >>>>> same issue again. >>>> Yup. ?I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >>>> >>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>>> patch and we can finally get this fixed. ?Without it, NSS support is >>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>> priority bug! >>>> I do have an SCA on file. ?Note that the recommendation from the NSS guys was to raise the priority. >>>> >>>> The reason I haven't submitted this is because I submitted a different EC fix ?https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >>>> ?and was waiting on progress there before continuing. ?I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. ?And then I got busy with some other things... >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2009/8/28 Andrew John Hughes : >>>>>> >>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>> >>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>> >>>>>> If NSS is configured as specified in this blog, keytool can be used to >>>>>> generate a key as follows: >>>>>> >>>>>> Hello. >>>>>> >>>>>> Allowing keytool and friends to work in more cases if the provider is >>>>>> capable seems fine to me. >>>>>> >>>>>> Security team, do you have concerns about this patch? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> >>> Ok here is a new webrev: >>> >>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >>> with a slightly revised version of your change (you can't throw a >>> PKCS11Exception which only takes a long ID from the native code, so I >>> changed this to an IllegalArgumentException). >>> >>> Security team, does this look ok to push? >>> -- >>> 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 >>> >> >> Ping! Security developers, any thoughts on this patch: >> >> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >> >> Does it look ok to push? >> >> Thanks, > -- 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 joe.darcy at sun.com Thu Sep 24 15:59:21 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 24 Sep 2009 22:59:21 +0000 Subject: [security-dev 01255]: hg: jdk7/tl/langtools: 6337964: should ignore last comma in annotation array Message-ID: <20090924225924.367B1128BB@hg.openjdk.java.net> Changeset: d0f541480556 Author: darcy Date: 2009-09-24 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d0f541480556 6337964: should ignore last comma in annotation array Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/annotations/pos/TrailingComma.java From mstjohns at comcast.net Fri Sep 25 13:53:13 2009 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 25 Sep 2009 16:53:13 -0400 Subject: [security-dev 01256]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4ABBAD55.7070206@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> Message-ID: <20090925205316.060D211B0CD@mail.openjdk.java.net> Hi Vincent - The original code was not compliant with PKCS11. It basically confused the X9.62 format for the public key with the ECPoint ASN1 format for the public key - the latter being the one needed in both files. The changes described in the webrev only affect in/out from a PKCS11 module and shouldn't have any other side effects - I spent a bit of time looking around to ensure this was the case. I may have missed something, but its unlikely. The backwards compatibility issues would be with PKCS11 modules that mis-implemented the PKCS11 standard - I don't know of any that have this issue. It would be relatively easy to deal with the decode of a broken returned key in P11Key, but since you would have to know a priori whether or not the PKCS11 module was broken or not, the fix for P11ECKeyFactory (where it currently has a broken encoding method) would need to depend on some configuration option from the PKCS11 class - and that's a much bigger change. Mike At 01:33 PM 9/24/2009, Vincent Ryan wrote: >Hello Andrew, > >I'll need a little more time to come up to speed on this fix. I'm concerned that >there may be interoperability or backwards compatibility issues. > > > >Andrew John Hughes wrote: >> 2009/9/2 Andrew John Hughes : >>> 2009/9/2 Michael StJohns : >>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>> 2009/9/2 Michael StJohns : >>>>>> ?? This appears to be related specifically to PKCS11.?? Specifically, PKCS11 >>>>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>>>> different in the text than an ASN1 ECPoint). >>>>>> >>>>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>>>> format described in?? X9.62, where the first octet indicates the encoding and >>>>>> there are either N or 2N octets following)?? being the expected value, but >>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>> >>>>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>>>> interpreted the issue and implemented its code. >>>>>> >>>>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>>>> of the problem.?? The other half is related to encoding the value.?? Also, >>>>>> changing the code at decodePoint seems further into the stack than needed >>>>>> and may affect other uses of that method. >>>>>> >>>>> That's really too vague to be of much help in improving the patch. >>>>> You seem to be saying little more than 'I don't like it'. >>>> Sorry about that. My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >>>> >>>> >>>>>> There's an existing JDK bug on this coming at it from a different direction >>>>>> - 6763530 ... and there may be considerations at >>>>>> >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>> >>>>> It seems likely that's the NSS change that causes the current failure. >>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>> In fact, the code is similar enough to suggest that one was developed >>>> >from the other. >>>>>> ?? that should be looked at. >>>>> The JDK bug is not really 'from a different direction', it's reporting >>>>> exactly the same error but from a less trivial example (I get the same >>>>> failure while trying to create an example key, while this seems to >>>>> require specific hardware if I'm reading it correctly). >>>> Not exactly. You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >>>> >>>> >>>>> Also see 6779460 which is mostly a duplicate of >>>>>> 6763530. >>>>>> >>>>> The patch on 6779460 seems wrong. It means that the method will >>>>> return a DER-encoded value where it would either have returned an >>>>> uncompressed value before or failed. >>>> My point exactly as I mentioned in the comments. :-) >>>> >>>> >>>>>> It's probable that the fix I suggested at 6763530?? (in comments submitted 29 >>>>>> Nov 08) may be a better approach given the NSS fixes.?? I believe it will fix >>>>>> the keytool problem noted in the original message. >>>>>> >>>>> Ok, I can see the logic in the fix and it would appear to work, though >>>>> I haven't tested it. >>>>> Given the patch was written nine months ago, why has it not been >>>>> applied? If it had, it would have saved me hours having to debug this >>>>> same issue again. >>>> Yup. I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >>>> >>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>>> patch and we can finally get this fixed. Without it, NSS support is >>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>> priority bug! >>>> I do have an SCA on file. Note that the recommendation from the NSS guys was to raise the priority. >>>> >>>> The reason I haven't submitted this is because I submitted a different EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >>>> and was waiting on progress there before continuing. I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. And then I got busy with some other things... >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2009/8/28 Andrew John Hughes : >>>>>> >>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>> >>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>> >>>>>> If NSS is configured as specified in this blog, keytool can be used to >>>>>> generate a key as follows: >>>>>> >>>>>> Hello. >>>>>> >>>>>> Allowing keytool and friends to work in more cases if the provider is >>>>>> capable seems fine to me. >>>>>> >>>>>> Security team, do you have concerns about this patch? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> >>> Ok here is a new webrev: >>> >>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >>> with a slightly revised version of your change (you can't throw a >>> PKCS11Exception which only takes a long ID from the native code, so I >>> changed this to an IllegalArgumentException). >>> >>> Security team, does this look ok to push? >>> -- >>> 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 >>> >> >> Ping! Security developers, any thoughts on this patch: >> >> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >> >> Does it look ok to push? >> >> Thanks, From tim.bell at sun.com Sat Sep 26 10:02:51 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 26 Sep 2009 17:02:51 +0000 Subject: [security-dev 01257]: hg: jdk7/tl: 5 new changesets Message-ID: <20090926170251.6D485129C0@hg.openjdk.java.net> Changeset: e76b72562a98 Author: ohair Date: 2009-09-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e76b72562a98 6855174: Improve log output when builds transition from one workspace to another Reviewed-by: jjg ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 931f7f7501da Author: ohair Date: 2009-09-17 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/931f7f7501da Merge Changeset: 76f6380ac0b4 Author: xdono Date: 2009-09-18 09:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/76f6380ac0b4 Merge Changeset: d70b157f6407 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d70b157f6407 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! make/corba-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 3ac6dcf78232 Author: robilad Date: 2009-09-23 20:06 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3ac6dcf78232 6872735: Further update build readme for new platforms 6641691: Bring build readme's up-to-date Summary: Added build instructions for Debian, Ubuntu 8.04, 8.10, 9.04, Fedora 10, 11, OpenSolaris 2009.06, OpenSUSE and Mandriva Reviewed-by: ohair, andrew ! README-builds.html From tim.bell at sun.com Sat Sep 26 10:03:27 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 26 Sep 2009 17:03:27 +0000 Subject: [security-dev 01258]: hg: jdk7/tl/corba: 6 new changesets Message-ID: <20090926170332.B0A93129C5@hg.openjdk.java.net> Changeset: 1c130e7b7a2e Author: ohair Date: 2009-09-02 09:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/1c130e7b7a2e 6875240: Reduce Makefile build time by limiting repeated exec's (mostly for cygwin building) Reviewed-by: jjg, iris ! make/Makefile ! make/common/BuildToolJar.gmk ! make/common/CancelImplicits.gmk ! make/common/Defs.gmk ! make/common/Rules.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/jprt.properties Changeset: 085333867e39 Author: xdono Date: 2009-09-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/085333867e39 Merge Changeset: 546970b224ca Author: xdono Date: 2009-09-18 09:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/546970b224ca Merge Changeset: 31ce3cac3cc1 Author: ohair Date: 2009-09-18 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/31ce3cac3cc1 6883790: corba build problem related to wildcard and vpath, regression Reviewed-by: tbell ! make/common/Rules.gmk Changeset: 2aa5665d86a5 Author: ohair Date: 2009-09-18 17:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2aa5665d86a5 6883816: corba fix for missing javax/transaction/xa classes (the real fix) Reviewed-by: tbell ! make/common/Rules.gmk Changeset: b751c528c555 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/b751c528c555 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! make/common/CancelImplicits.gmk From tim.bell at sun.com Sat Sep 26 10:04:11 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 26 Sep 2009 17:04:11 +0000 Subject: [security-dev 01259]: hg: jdk7/tl/hotspot: 6884624: Update copyright year Message-ID: <20090926170417.C8DE0129CA@hg.openjdk.java.net> Changeset: 89e0543e1737 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/89e0543e1737 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp From tim.bell at sun.com Sat Sep 26 10:04:59 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 26 Sep 2009 17:04:59 +0000 Subject: [security-dev 01260]: hg: jdk7/tl/jaxp: 3 new changesets Message-ID: <20090926170504.82C27129CF@hg.openjdk.java.net> Changeset: 534e23823a1b Author: ohair Date: 2009-09-21 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/534e23823a1b 6856630: Restructure jaxp/jaxws repositories Reviewed-by: darcy, tbell ! .hgignore ! README + build-defs.xml + build-drop-template.xml + build.properties + build.xml + jaxp.properties ! make/Makefile - make/build.properties - make/build.xml ! make/jprt.properties - make/tools/StripProperties/StripProperties.java - make/tools/StripProperties/StripPropertiesTask.java + nbproject/findbugs.settings + nbproject/project.xml + nbproject/sqe.properties + patches/jaxp_src/README Changeset: 0748962aa825 Author: ohair Date: 2009-09-21 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/0748962aa825 6884220: Have drop sources ignore the output.dir property Reviewed-by: xdono ! build.properties Changeset: ee9c7578aca5 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ee9c7578aca5 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java From tim.bell at sun.com Sat Sep 26 10:05:41 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 26 Sep 2009 17:05:41 +0000 Subject: [security-dev 01261]: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20090926170544.D63A2129D4@hg.openjdk.java.net> Changeset: ae2bec597586 Author: ohair Date: 2009-09-21 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ae2bec597586 6856630: Restructure jaxp/jaxws repositories Reviewed-by: darcy, tbell ! .hgignore ! README + build-defs.xml + build-drop-template.xml + build.properties + build.xml + jaxws.properties ! make/Makefile - make/build.properties - make/build.xml ! make/jprt.properties - make/tools/StripProperties/StripProperties.java - make/tools/StripProperties/StripPropertiesTask.java + nbproject/findbugs.settings + nbproject/project.xml + nbproject/sqe.properties + patches/jaxws_src/README Changeset: 77708e68db52 Author: ohair Date: 2009-09-21 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/77708e68db52 6884220: Have drop sources ignore the output.dir property Reviewed-by: xdono ! build.properties From tim.bell at sun.com Sat Sep 26 10:07:21 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 26 Sep 2009 17:07:21 +0000 Subject: [security-dev 01262]: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20090926170729.882AB129DB@hg.openjdk.java.net> Changeset: 14735c7932d7 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/14735c7932d7 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/MissingInclude.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/quid/MakeNegTests.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh ! test/tools/javap/T4975569.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.sh Changeset: 9596dff46093 Author: tbell Date: 2009-09-25 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9596dff46093 Merge Changeset: 4776a869fdfa Author: tbell Date: 2009-09-25 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4776a869fdfa Merge ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! test/tools/javah/MissingParamClassTest.sh From jonathan.gibbons at sun.com Mon Sep 28 16:50:50 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Mon, 28 Sep 2009 23:50:50 +0000 Subject: [security-dev 01263]: hg: jdk7/tl/langtools: 6886348: apt incorrectly uses Scope.table Message-ID: <20090928235055.B343712A1B@hg.openjdk.java.net> Changeset: c6d0c55b1aba Author: jjg Date: 2009-09-28 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c6d0c55b1aba 6886348: apt incorrectly uses Scope.table Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/comp/Apt.java From ptisnovs at redhat.com Wed Sep 30 02:49:39 2009 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Wed, 30 Sep 2009 09:49:39 +0000 Subject: [security-dev 01264]: hg: jdk7/tl/jdk: 6884837: JTReg test SetOutgoingIf is not correct Message-ID: <20090930094959.2F52441574@hg.openjdk.java.net> Changeset: 5b1aaf2d7504 Author: ptisnovs Date: 2009-09-30 11:49 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b1aaf2d7504 6884837: JTReg test SetOutgoingIf is not correct Summary: Added check of network interfaces status Reviewed-by: alanb, chegar ! test/java/net/MulticastSocket/SetOutgoingIf.java