So I did a bit more reading on smartcard PIN caching, and took a better look at the debug logging of gnupg 2.2, and learned that, indeed, the PIN is cached by the card and not by any one gnupg component.

I am testing with rGccfb5e0a7dc6: scd: Use SCardStatus for pcsc_get_status. on GNU/Linux.

Yes, I already linked to T5415, but that breaks YubiKey completely, and I fixed it with disable-ccid.

The pincache is actually not what you think it is. It is only used to allow switching between different application on a Yubikey which reqieres a new VERIFY command after switching back to the first application the card. What you feel as caching is the state of the card, which usually keeps its verification state until the card is powered down.

Frankly, I am pretty sure that the new base64 encoding of the fingerprint leads to less diligent comparison of the fingerprint by the user. I don't understand why they did not used a truncated hex output or zBase32 .

Thanks for using GPA. Unfortunately, I have to tell you that GPA development has been stopped and I can't say whether we will fix that bug any time soon. Please consider to switch to Kleopatra which is the standard key manager included in gpg4win.

FWIW, we can and should run our test suite under valgrind from time to time

Sorry, it's my fault.
Fixed in rGac731dbbbd21: gpg: Fix allocation for EXTRAHASH..

On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.

Applied in rG32baa9acfb15: scd: Serialize READER_TABLE access for PC/SC..

Please note that we don't use lock in apdu_dev_list_start/finish any more.
Use of lock is narrowed, only within apdu_open_reader function.

(I disabled the account of this boor)

(I disabled this boor and restored the state)

GnuPG (more precisely gpg-agent) does cache the password for some time in memory. The default is 10 minutes. Add

default-cache-ttl n

where n is the number of seconds to cache the password, to ~/.gnupg/gpg-agent.conf.

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

We should add a comment at the caller side, that this takes a lock in apdu.c.

Make the lock holding narrower, and it allows no exposing reader_table_lock.

Exposing reader_table_lock would be better.
I found a dead-lock condition when apdu_close_reader is called during apdu_dev_list_start/finish.

I wonder if PCSC_SHARE_SHARED is related or not.

And if the coding style of hiding mutex_lock/mutex_unlock inside different functions matters, we can expose the mutex to its user.

Last commit will be:

The second commit is replacing a use case of close_pcsc_reader by clearing pcsc.rdrname and calling release_pcsc_context.
This makes the use of close_pcsc_reader to its original purpose only (== closing PC/SC reader as a method of close_reader).

OK. As I pointed out a commit having multiple things may make analysis difficult, I should have been careful.
So, let me fix the problem by multiple commits.