Project

General

Profile

Feature #166

Cancel support for long running PCSC commands

Added by Tobias Wich about 6 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Start date:
01/18/2013
Due date:
% Done:

0%

Reviewer:
Build Version:

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.


Related issues

Related to Feature #181: Remove Threading from GUI Executor Closed 03/13/2013

History

#1 Updated by Tobias Wich about 6 years ago

In order to reproduce the faulty behaviour perform the following steps:
  1. Connect a PACE capable terminal (standard reader)
  2. Start the richclient and trigger the activation for the nPA
  3. Walk through the dialogs until the PACE is performed with the terminal
  4. 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.

#2 Updated by Tobias Wich almost 5 years ago

  • Target version set to 1.3.0

#3 Updated by Tobias Wich over 3 years ago

  • Tracker changed from Bug to Feature
  • Priority changed from High to Normal

Also available in: Atom PDF