Possible changes to javax.smartcardio
Michael StJohns
mstjohns at comcast.net
Sun Feb 12 21:47:22 UTC 2012
Hi -
I've been looking javax.smartcardio with an eye to making two changes - one that can be handled completely within the sun.security.smartcard.SunPCSC provider, and one that will need an API change.
The first is adding support in the provider for the plug and play pseudo-terminal. Basically, I've seen a number of tokens that look like both smart cards and terminals - using the current code, I have to loop looking for a change in the set of connected terminals, rather than just waiting on CardTerminals.waitForChange().
The second is adding ".cancel()" methods to both CardTerminals and CardTerminal to cause any wait's to terminate cleanly. For PCSC, this would be calling SCardCancel and returning InteruptedException if the error code from the native SCardGetStatusChange is SCARD_E_CANCELLED. The reason for this one is to allow user input in another thread cause the smart card waiting to return cleanly.
The former I implemented and tested a while back, but didn't submit the changes. The functionality is enabled by calling TerminalFactory.getInstance() with a Properties object consisting of a trackterminals=yes mapping.
The latter looks pretty simple to implement, but is an API change to javax.smartcardio - albeit a backwards compatible one. The body of the cancel method isn't much more than the call to PCSC.ScardCancel (which will be needed to be added to the native code).
Is this a useful change?
And what's the best way to get this in? The process in http://openjdk.java.net/contribute/ doesn't actually seem to reflect reality as a previous patch I submitted using that process (https://bugs.openjdk.java.net/show_bug.cgi?id=100048) didn't seem to result in the desired change. Eventually, it was implemented, but not using this patch.
Thanks - Mike
More information about the security-dev
mailing list