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!
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
