Sorry - missed this before.
On 12/5/2024 4:50 PM, Sean Mullan wrote:
... clipped
On 11/30/24 8:11 PM, Michael StJohns wrote:
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
PCSC, PKCS11 and JDBC are all plugin provider style things and I didn't
think it made a lot of sense to twiddle all of the public APIs just for
this. But making a public interface available (and suggested) for the
various private Exception classes that get passed as causes seemed to
make a bit of sense as a way of avoiding that type of change.
If you were going to open up the SmartCard IO API I'd probably want to
add a few other things: ::cancel() methods for the various ::wait()
methods; the ability to detect card reader plugin when provided by the
native code.
Thanks - Mike
