I could argue that caching the information about the card and reusing it is pointless and dangerous if such cache is not invalidated when the card is removed. Next time the information is needed, there may be a different card lying on the NFC reader. And it certainly does not make sense to keep the card reserved for exclusive use when the card is physically long gone.

No way to fix, itself. Better warning/error message can be done.

I am interested in this, and can look into any needed polishing. Can someone please attach the patches to this bug or a link to where they can be downloaded. Unfortunately mailing list archives strip attachments. I spoke with Mike in IRC who informed me he made a EFL port of pinentry. I was working on that, and still have my code going in case I cannot get a copy of Mikes work. I am willing to do what ever is necessary to get this into pinentry sooner than later. Though I understand it can take some time. Hopefully not the 1yr it took the FLTK based pinentry to be added.

This has been fixed quite some time ago.

I have noced that you added the C++ interface. Thanks.

Duplicate of T1060

2.1 has the option --unwrap to just this.

Implemented in 2.1.19

Sorry, the test case code is here: https://github.com/rethab/h-
gpgme/blob/master/test/KeyTest.hs#L91

The removeKey function code is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64

I hope the attached log helps. The log is a test of this command:
GPGME_DEBUG=9:/home/dmp1ce/Projects/DMSS/h-gpgme/mygpgme.log ./runtests remove_alice_key_prompt

The test is creating a GPG context directory, creating a temporary key and then deleting it. The
log should show me manually confirming to delete the key. I would like the delete prompt to be
suppressed with an automatic deletion of the key. I didn't see any way of suppressing the
confirmation in the documentation here:
https://www.gnupg.org/documentation/manuals/gpgme/Deleting-Keys.html#Deleting-Keys

The code to the test case is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64

The test is running the function c'gpgme_op_delete which is a binding to the c function
gpgme_op_delete. Source code for the binding is here: https://github.com/jwiegley/bindings-
dsl/blob/master/bindings-gpgme/src/Bindings/Gpgme.hsc#L534

Can you provide a plain C test program to show the effect or, maybe easier a
GPGME trace file running your program?

GPGME_DEBUG=9:gpgme.trace: YOURTESTPGM

See tests/run-genkey --set-primary on how to use it.

commit 421ddd1 implements that for 1.9.0.

I'm maintaining a language binding. https://github.com/rethab/h-gpgme

What do you mean by "maintainig a GPGME library"? A language binding or an
implementaion similar to GPGME?

I close this one. An implementation is already in master.

Duplicate of T2819

Done with commit 35023f3.

I modified the patch slighly, added docs and a --from-file to run-keylist.
You may want to add a C== and Qt interface.

Merged in 6c45eed62214b44fcc11e642b19df7b6ca0da0bd.

Let's keep this one open to track missing options.

Finally fixed in 2.0.11
(restored T1001 (wk on Mar 03 2009, 04:58 PM / Roundup))

Simple workaround is having multiple readers...

Most card readers only support a single card.
(This is the reason why it is not yet implemented.)
Could you please let us know the reader which supports multiple cards?

I was actually surprised to find out this doesn't already work...

I would like to be able to have two or more GnuPG cards inserted at the same
time, and have gnupg/gpg-agent/scdaemon notice all of them and use whichever one
was appropriate for the operation at hand, without my having to switch them in
and out.

My personal application for this is that I have a personal key and a work key,
and I want to be able to sign with either of them without having to swap
hardware around. It's pretty easy to set up all the other parts of this to be
seamless with Thunderbird/Enigmail/gnupg2... it works fine until you move the
keys to cards, at which point gnupg's inability to automatically choose the card
it needs really shows up.

In an ideal world, this would also work with gpg-agent as a backend for ssh.

As of d379a0174cca595204b32da9a66c513a1304e6d0 auto-key-retrieve is configurable.

As of ebeccd73eb85f9027f0985d77dfe901266c6ddef the trust model is configurable
via gpgconf.

D409: 954_0001_gnupg-2.1.18_allow-original-timestamp-on-keysig-update.patch

Testing this I noticed that the curses fallback did not work at all for Qt5
versions of pinentry-qt even if display was unset. This i fixed with cd7b35e

But the DISPLAY=:noexist case is more complicated. The GTK pinentry does a
gtk_init_check which Qt does not have. I don't want to mess with X directly and
would have to look into this more how to do this then only when X is used etc.

There is a similar question on stackoverflow and I don't find any answers there
acceptable:
http://stackoverflow.com/questions/28525435/qt-equivalent-to-gtk-init-check

I've changed the topic to reflect that this is a feature currently not available
in pinentry-qt but I don't see it as a high priority issue.

Andre, can you look at it?

Using a socket conenction would require new code. We use the standard ports
instead. Sometimes the socks5 code (and I assume also the Unix domain socket
code) takes some time to figure out whether Tor is actually running, Thus this
is not done at every request.

Doing a check for every request would also require a lot of new code because we
need to restart a connection attempt at a higher layer. Similar to HTTP 301
handling.

The whole point of a daemon is that is idling in the background to wait for work.

A more useful feature would be to flush the passphrase cache when the user is
not anymore logged in. But for Debian this has already been done by --supervised.

I agree about that race condition being an important thing to consider, but i
think it's orthogonal to whether the process is self-terminating.

That is: we need to consider that race condition even in the case of deliberate
shutdown too, right?

Do we have a test case that involves two concurrent processes, one that tries to
stop the agent, and the other that tries to access it?

One thing to look out for is a race condition between the agent deciding to shut
down, and a client trying to connect at that time, and that might lead to
intermittent failures. It may be doable correctly, but it is something to look
out for.

The other point being raised in the bug report about older daemons hanging
around over package upgrades should be discussed in a different bug. Yes,
shutting down the daemon when idle may work around this issue sometimes, but
clearly this is not a robust solution.

anyone skilled in qt want to fix this outstanding issue?

I've tested Simon's patch against 2.1.18, and i think it's the right thing. I
posted it to the mailing list in git-format-patch form here:

https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032547.html

Any progress on this?

A reproducer, even without smartcards (please ensure that GNUPGHOME is
explicitly set):

ARGS="--pinentry-mode loopback --passphrase abc123"
ARGS="$ARGS --batch --with-colons --with-keygrip --status-fd 3"

gpg $ARGS --quick-gen test@example.org rsa cert 3>genkey.status
FPR=$(awk '/KEY_CREATED/{ print $4 }' < genkey.status)
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-1.status
sleep 5
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-2.status
GRIP=$(gpg $ARGS --list-keys | grep ^grp: | cut -f10 -d: | tail -n1)
mv $GNUPGHOME/private-keys-v1.d/$GRIP.,bak
gpg-connect-agent killagent /bye
echo test | gpg $ARGS -u "$FPR" --clear-sign

This was included in 2.0.30, but somehow was missing from the 2.1.x branch.
I've included it in master as of 8a9d4b55b09d04482b46055f0a60f01b86738df3

Thanks for this work (and sorry to have just blindly/wrongly assumed that
--no-use-tor already existed without checking it).

On modern debian systems, the default tor daemon will always be listening on
unix domain socket /run/tor/socks. So a simple attempt to connect to that
socket should be sufficient -- it should fail immediately if the socket isn't
present or if no one is listening on it.

This seems cheap and fast enough to be able to do it on every query to me,
rather than introducing additional runtime state to dirmngr. just try to
connect, and if it doesn't work, fall back to a normal connection (you'd want to
do that anyway in case the tor daemon goes away after dirmngr had been launched).

justus: we recently talked about this. Would you like to work on this. I am in
particular interested to use it for Windows statically linked.

Okay, that first part has been pushed. Now need to figure out how to test for
Tor in a clean way.

I will do some rework to make testing for tor easier ....

I think this is a good idea. If Tor is already running we can expect that the
user wants to use Tor as much as possible and thus tehre should be no need for
any configuration.

I do not think that we need a new option (except for making --no-use-tor). To
avoid checking for tor with every new connection to Dirmngr, I would do a test
at startup and after each reload.