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, >> >> >>