On 11/30/24 8:11 PM, Michael StJohns wrote:
Hi -
As Java has become more modularized and locked down, I've lost some easy
access to critical information in two places - PCSC and PKCS11. I
haven't gone back to dealing with JDBC recently, but I think I might
have the same problem there.
It is a valid concern.
To give you an example, java.smartcardio.CardException almost always
hassun.security.smartcardio.PCSCException as a "cause", and
PCSCException usually has a useful error code such as
SCARD_E_NO_READERS_AVAILABLE. The problem is that I can't coerce the
Throwable from getCause() to PCSCException post JDK8 without going
through a number of hoops to open up various modules. Parsing the return
from getMessage() on the cause sort of works for PCSC stuf, but could
break in weird ways since those formats aren't specified.
Similar stories exist on the PKCS11 side of things.
I'm wondering if it would make sense to create a public interface that
these closed off implementation or factory classes could implement that
would allow for the retrieval of the native codes and messages without
workarounds? E.g. something like:
package java.lang; // or maybe java.util?
public interface NativeException {
public Long getNativeErrorCode(); // Return null if not supported
public String getNativeErrorMessage(); // Return null if not supported
}
Obviously, this is more general than just the security stuff, but that's
where I've run into the related problems.
I would be more inclined to add new standard Exception subclasses with
the specific information, in other words expose PCSSCException as a
public subclass of CardException and something similar on the PKCS11
side. However, the SmartCard/IO API is externally specified in JSR so we
would have to do an MR of that JSR.
--Sean
