Hello,
I'm building an application that configures smart cards (currently Yubikeys) as
OpenPGP cards using GPGME and the gpgme_op_interact() API. In order to provide
the functions needed at the user level, I need to engage in several different
interactions, most notably some that emulate --card-edit and others with
--edit-key. Because the first has no key associated with it, while the second
requires a key, the second argument to gpgme_op_interact() is either NULL or a
pointer to a gpgme_key_t, respectively.
This seems to be the origin of a problem I am seeing. While the first
operations (--card-edit) work fine, when I try to perform the second set of
operations (--edit-key), I get an error. At the API level, this manifests as a
CARDCTRL 4 response to the gpgme_op_interact() session, meaning that no card is
available, though clearly the card is there. If I follow the chain of
operations to find out why GNUPG thinks the card is not available, the ultimate
source seems to be that, when the initial set of (--card-edit) operations were
done, an instance of scdaemon was spawned, and that daemon continues to run
even after the operations have finished. Later, when the second set of
(--edit-key) operations begin, because the arguments are different (I'm
guessing), a second instance of scdaemon is spawned. But this second instance
cannot access the card because the first instance still holds some kind of
exclusive lock on access to the card. As a result what I get from the second
(newer) instance of scdaemon is a message "pcsc_connect failed: sharing
violation (0x8010000b).
As a result of this, the only current way to use the API to configure the card
is to have the user remove and re-insert the card, and unfortunately depending
on the series of operations they want to perform (which could include reading
cards, erasing them, configuring them, etc), this can be required multiple
times, which obviously isn't ideal, so I wonder if there is a solution?
One possibility would be to arrange things so that the different instances of
scdaemon could effectively share access to the card. I see in
scd/apdu.c:connect_pcsc_card() that there is an option to pcsc_connect() which
is currently set to PCSC_SHARE_EXCLUSIVE, but there are alternatives
(PCSC_SHARE_SHARED and PSCS_SHARE_DIRECT).
Another more "violent" option would be if there is some way to force the
termination of the first scdaemon instance before begining the next one, say, a
call like gpgme_op_interact_cleanup() or something like that.
Or perhaps there is another way that I just haven't seen yet. Do you have any
suggestions?
Thanks very much!
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
