On 27 June 2010 23:45, Michael StJohns <mstjo...@comcast.net> wrote: > PS - I know this is the openjdk list - but I thought this one was getting > back ported. > > Mike > > > At 05:37 PM 6/27/2010, Michael StJohns wrote: >>Hi guys - >> >>I see from the Mercurial logs that this went in to both the jdk6 and jdk7 >>repositories. For jdk6 - it's rev 302 which looks like this should have >>ended up in the _19 release >> >>But all the files in lib/ext/sunpkcs11.jar for _20 are all tagged as 1 >>September 2009.... >> >>Is the sunpkcs11.jar provider not getting regenerated and rebundled during >>the release process? >> >>Mike >> >> >> >>At 01:28 PM 1/21/2010, Michael StJohns wrote: >>>At 05:12 AM 1/21/2010, Vincent Ryan wrote: >>>>I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. >>> >>> >>> >>>>On 21/01/2010 07:44, Tomas Gustavsson wrote: >>>>> >>>>> Now it has one more vote. >>>>> >>>>> /Tomas >>>>> >>>>> Andrew John Hughes wrote: >>>>>> 2010/1/20 Tomas Gustavsson <to...@primekey.se>: >>>>>>> I'll second this request. This is a critical patch and many production >>>>>>> installations have to live with this manually patched now. >>>>>>> >>>>>>> I know of no pkcs11 implementation that works with the current code. >>>>>>> >>>>>> >>>>>> It has four votes: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >>>>>> I don't know how many they need to wake up and review the patch. >>>>>> >>>>>> The new release of IcedTea6 1.7 is imminent and will include the fix >>>>>> so it should at least be resolved on the next version shipping with >>>>>> most GNU/Linux distributions. >>>>>> >>>>>>> Regards, >>>>>>> Tomas Gustavsson >>>>>>> PrimeKey Solutions AB >>>>>>> >>>>>>> >>>>>>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>>>>>> >>>>>>>> Hi - this seems to have stalled out again. Any chance of revival? >>>>>>>> >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> At 12: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 <gnu_and...@member.fsf.org>: >>>>>>>>>>> 2009/9/2 Michael StJohns <mstjo...@comcast.net>: >>>>>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>>>>>> 2009/9/2 Michael StJohns <mstjo...@comcast.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. >>>>>>>>>>>>>> >>>>>>>>>>>>> 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 <gnu_and...@member.fsf.org>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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, >>>>>> >>>>>> >>>>>> > > >
It has been: $ hg log -R jdk -k 6763530 changeset: 302:82b80660cac3 user: vinnie date: Thu Jan 21 23:59:41 2010 +0000 summary: 6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1) and certainly is present on IcedTea6's builds. -- 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
