Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

reading your report again: You clicked on a folder and expected that all encrypted files in this folder will be decrypted? That is unfortunately not supported.

I fully agree. That was actually my itention - not sure why the coded ended up as it is.

Due to tax issues, we can't accept a donation as return on service. However, we will fix bugs anyway if possible,

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

(I disabled the account of this boor)

(I disabled this boor and restored the state)

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.

Keeping the lock over the call to the function does not look very robust to me. This is why I removed it. And since then PC/SC worked on Windows for me. Modulo this:
All these changes don't tackle the real problem that windows gets struck in a removed-card state.

This is better name. My point was that if we ever use that to create such a field the developer should not assume that arbitrary REs can be used here. We need to have some practical value here and I would prefer to see only the domain name. However, OpenPGP allows for arbitrary REs and thus we may see them here. This is problematic but we can't do much about it.

That would required that we also add an option --enable-ccid-driver - better tell the macOS folks to put diable-ccid-driver into /etc/gnupg/scdaemon.conf

FWIW, I think that it is a Bad Thing to use unreleased stuff from 1.8 for Debian packages. Only released versions sshould be used or patches we explicitly made to fix a bug. At the very least Andreas should have asked upstream whether this commit should be used for Sid.

Thanks for testing. I hope to get 2.3.2 out in two weeks.

RFC-5280 states in 4.2.1.3 for Key Usage:

The error code is: No Readers Available. With the latest version you should have seen that string.

Meanwhile we did some more tests on Windows and so you many want to try our betas at

Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?

Run gpg --debug ipc --card-status to quickly see the communication with the scdaemon.

Please try to verify on the command line (cmd.exe):

The curve is not defined to be used for ECDH (encryption); in fact it should in general only be used with the EdDSA
algorithm. You need to use "Key-Type: eddsa". Note that the EdDSA signing algorithm is different than the commonly used ECDSA signing algorithm.

Can you please port this also to 1.8?

You can't use ecdh with ed25519.