The first two patch sets are now applied with the exception of
the gpgsplit fix; I did not applied that patch to add a free() in case of write errors.

In T5393#145098, @gniibe wrote:

Please note that *_error-from_syserror accesses system's errno which may be cleared by xfree.

Please read also the report T5442 which is basically the same.

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.

Then let's get it in there. It's pretty easy to traverse a directory.

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 have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"

Note: I believe this issue might affect multiple other GnuPG projects.

In T5436#146148, @ikloecker wrote:

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

Just got around to testing this on Linux, and I can confirm the same behavior: decryption PIN caching works on 2.2 and doesn't work on 2.3.

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

@znull You can also fix the detection issue by building with ./configure --disable-ccid-driver, in which case you won't need the disable-ccid setting anymore.

@ikloecker Sorry for not being clear, I was not aware different operations have different behaviors in regard to entering / caching the PIN.

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

I just wanted to chime in that I've had exactly the same experience as @lbogdan: gnupg 2.3 stopped recognizing my yubikey entirely on MacOS until the T5415 workaround (disable-ccid). After that, pin caching was broken until I applied his patch to call-scd.c:548, which makes it work as before. Without these two changes the experience with gnupg 2.3 is degraded relative to 2.2.

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.

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.

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

(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.

I wonder if PCSC_SHARE_SHARED is related or not.

Ah, great. Thanks!

You are welcome.

run-genkey is working fine in my test environment as well.

Technical commentary on smartcard operation and/or Windows is going to be over my head, so I can't help (just in case you're looking for anything from me). But always happy to drive-test another build. (I've still had no issues, personally, with the build above.) I'll assume you don't need me unless you link another binary build to test or tag me. Thanks again, all.

The problem is accesses to reader_table by
(1) scanning reader(s) to open new one
(2) closing reader

I'm testing D531: Keep holding READER_LOCK_TABLE and make clear distinction among close/releasing_PCSC_context/nullify_rdrname, but I'm not sure about the impact on Windows.

The commit rGbb8e3996e44f: scd: Fix problem with reader list becoming empty. removed READER_TABLE_LOCK holding between apdu_dev_list_start and apdu_dev_list_finish, that opens possible stale resource access for CCID driver: reader_table[slot].ccid.handle

Thank you for your report.

Well, all I can say is that
./run-genkey --loopback "elektra testkey (gen-gpg-testkey)"
creates a key without any problems and without asking for a passphrase. Even, if I add the GPGME_CREATE_NOEXPIRE flag to the call of gpgme_op_createkey. At least, from a terminal.

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

Or... we could add --disable-ccid-driver as default for macOS.

If it is built with LIBUSB enabled, please try adding the following to your scdaemon.conf:

disable-ccid

Thank you for your response! I tried out all variants of gpgme_pinentry_mode_t and implemented a passphrase callback (using gpgme_set_passphrase_cb as suggested). It turns out that the callback is not invoked at all. However, if I switch back to gnupg 2.2.27, the callback is being invoked and the key is being generated (using the passphrase specified by the callback, as expected).

The problem might be that gpg tries to ask for a passphrase which fails on the CI. Try setting a passphrase callback and setting the pinentry mode to loopback. See https://dev.gnupg.org/source/gpgme/browse/master/tests/run-genkey.c$435.

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

After upgrade:

Thank you for taking time to look into that. There are couple of issues in the CAcert bug tracker talking about the same issue but if, (I see right), the certs still miss the usage flags:

RFC-5280 states in 4.2.1.3 for Key Usage:

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

I had a similar issue in Windows 10 too. In my case, the issue occurs only when my home path has non-ASCII characters. After I changed home path it works well.

Any chance looking into this @werner?

To note, this is in contrast to my experience with gpg-2.2 (provided by gpg4win). With gpg-2.2, I was reliably using my Yubikey for a variety of things, and it handled hotplugging perfectly, as one would expect.

Also let me know if there are any daemons I have to kill/restart when switching between GnuPG versions by changing the $PATH. Whenever I have problems with my YubiKey, I run gpgconf --kill gpg-agent, which I also executed when I switched from version 2.2.27 back to 2.3.1 but I have no idea whether this is required or sufficient.

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

Can you help me, please?

when I insert: gpg --verify -v Bisq-64bit-1.6.2.exe.asc at the command line (at windows), I get the answer:
gpg: cannot open "Bisq-64bit-1.6.2.exe.asc": No such file or directory
gpg: verify signatures failed: No such file or directory

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

I do have the same Problem.
It started about 2 weeks ago.

You are right. The problem is that in a development version we use an envvar to locate the programs, so there is usually no problem because the software has already been installed and the final test doesn't catch this. We should add a version check to all components to catch such problems.

Given that we don't yet support TPM for Windows you should go ahead and apply this patch. tpm should also be removed from the list of components.

Apparently only one of the secret keys is actually imported: the decryption key, but not the signing key.

Thank you for your confirmation. Closing.

Fixed in GnuPG 2.3.1, so, add the tag for GnuPG 2.2.