Conflict Due to Multiple Instances of Smart Card Daemon

[muredanta]

Regarding this, more significant than the Key parameter to gpgme_op_interact() in the two example that I gave being different may be the fact that the home directory set for the underlying gpgme_ctx_t (via the home_dir argument to gpgme_ctx_set_engine_info()) is different. In the case of the --edit-key operations, home_dir points where you would expect, to the home_dir containing the key of interest, and the flags parameter of gpgme_op_interact() is NULL. In the case of --card-edit operations, the home_dir is NULL and the flags parameter is, of course, GPGME_INTERACT_CARD.

In any case, the root issue seems to be that multiple instances of scdaemon are spawned, and that the first one takes, and holds, exclusive access to the card. I've confirmed that after patching scd/apdu.c:connect_pcsc_card() to use PCSC_SHARE_SHARED instead of PCSC_SHARE_EXCLUSIVE, the operations (or at least the ones I've tried) work without requring removal/re-insertion of the card, but presumably such a change has security implications or the original developers would not have used PCSC_SHARE_EXCLUSIVE. So... I don't know if such a change is advisable. Any feedback on that? I'm thinking that it may depend on usage. For example, if there is a dedicated, single-user, air-gapped system used to manage tokens, then perhaps SHARED is not a problem?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190522/d2c20325/attachment.html>