Feature #166
closed
Cancel support for long running PCSC commands
Added by Tobias Wich over 11 years ago.
Updated almost 5 years ago.
Description
The GUI's ExecutionEngine executes actions, which are in most cases IFD or other SAL commands, in a Future.
As it turns out, at least the Smartcard IO's $Card#transmitControlCommand()$ function prevents thread control by blocking the close functionality. The result is that though the executing thread is cancelled, the PCSC command continues to run until a timeout occurs. Additionally even though cancel has been called, all code after the long running PCSC command is executed afterwards.
This problem must be solved in order to prevent false behaviour and possibly data leaks against the users will and strange behaviour by not continuing despite the cancel button has been pressed.
The main question is how to stop running PCSC commands in the Smartcard IO.
In order to reproduce the faulty behaviour perform the following steps:
- Connect a PACE capable terminal (standard reader)
- Start the richclient and trigger the activation for the nPA
- Walk through the dialogs until the PACE is performed with the terminal
- Break execution in the GUI, not in the Terminal
The terminal will then continue to display the PACE specific user consent. The process continues when a timeout occurs, the process is aborted on the terminal or the PACE protocol is performed successfully. In any case the thread will stop execution at its fork point, the ExecutionEngine.
Useful points for debug breakpoints are
org.openecard.ifd.scio.IFD#establishChannel() in the line after executing the control command.
org.openecard.gui.executor.ExecutionEngine#process() in the line where the CancellationException is caught after the step action is executed.
- Target version set to 1.3.0
- Tracker changed from Bug to Feature
- Priority changed from High to Normal
- Status changed from New to Closed
This should be handled correctly for a long time now.
Also available in: Atom
PDF