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.

In T5395#145417, @gniibe wrote:

I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?

I applied 1,2,3, and 5 in rKfbb1f303198b: Fixes for static analysis reports.

I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?

IIUC, with libgcrypt in LIBGCRYPT-1.8-BRANCH (not yet released) and libgcrypt 1.9.3, the build process works well (the problem with SIP has been handled).

In T5401#145379, @werner wrote:

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority.

Yes, this is an edge case very unlikely to be encountered. The odd thing is the generated "ed25519" subkey does somehow encrypt and decrypt without issue.

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority. I would anyway suggest to use

Thanks, that was right in time for this weeks 2.3.1.

This has been fixed in version 2.2.16.

Fixed in rP7f7fd8bcfd74: tty: Fix error return paths and its resource leaks.

Actually, calling do_touch_file when some error(s) are not good.
Let me fix all the things.

Ok, thank you. I think task can be closed.

I hope last amendment is the following, which can happen if the tty can be opened only for reading but not for writing:

--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -583,7 +583,8 @@ tty_cmd_handler (pinentry_t pinentry)
   if (pinentry->ttyname)
     {
       fclose (ttyfi);
-      fclose (ttyfo);
+      if (ttyfo)
+        fclose (ttyfo);
     }

gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.

Thank you.
We also need to release memory for points.

Please tell us more details on how we can replicate your problem. Which Windows version, any non-standard software installed, non-standard installation direcories etc. You may also provide the output of

mkheader has CFLAGS_FOR_BUILD since libassuan 2.5.4.
gost-s-box has so since libgcrypt 1.9.0.

Done for gpa.
Please test.

Done for pinentry.

This task includes multiple issues: two sub-tasks and how-to-use remotely.
Two tasks had been fixed already.
The last one was documented here.
So, closing.