Page MenuHome GnuPG

PC/SC detecting removal of card
Closed, ResolvedPublic

Description

On Windows, removed card is not detected correctly in some cases, and the status will be persistent (even if killed scdaemon).

Possibly, our use of PC/SC is not good. Workarounds would be:

  • Use PCSC_SCOPE_USER instead of PCSC_SCOPE_SYSTEM when establish the context.
  • Change the way to watch the removal:
    • Currently, we periodically calls SCardGetStatusChange with the PC/SC context for each reader, with timeout==0 for non-blocking
    • It may be a single blocking call for all readers, by having a dedicated thread
    • Or, we can use SCardStatus function, instead, with per connection handle (instead of the PC/SC context)

Event Timeline

I wonder if PCSC_SHARE_SHARED is related or not.

I don't think that it is --pcsc-shared related; Andre reported that he noticed such a behaviour before we introduced this.

There is also the thing that we (i.e. Windows PC/SC subsystem) detects the removed-card state and reports it. However, there is no way to get rid of this state. Other programs (like the proprietary CardOS viewer) also don't get out of the sate even after having killed all GnuPG processes.

werner removed a subscriber: gillcovid19.

(I disabled the account of this boor)

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

gniibe added a project: Info Needed.

When we will find reproducible test case, please reopen.