[security-dev 01171]: Re: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6
Andrew John Hughes
gnu_andrew at member.fsf.org
Thu Sep 3 10:39:03 PDT 2009
2009/9/3 Michael StJohns <mstjohns at comcast.net>:
> At 03:14 PM 9/2/2009, Andrew John Hughes wrote:
>>Ok here is a new webrev:
>>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.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the security-dev