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.

Thank you for applying the provided changes!

Applied and pushed.

@werner No problem. Just go ahead.

In T5393#145158, @werner wrote:

Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.

Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.

@gniibe: If you don't mind I would like to steal task this from you. I have noticed a few things which could get a little code refresh in addition to the fixes.

There is couple of issues that I did not want to propose a patch for, but might require some attention:

Error: IDENTICAL_BRANCHES (CWE-398): [#def28] [important]
gnupg-2.3.0/common/tlv-builder.c:353: identical_branches: The same code is executed regardless of whether "tag < 31" is true, because the 'then' and 'else' branches are identical. Should one of the branches be modified, or the entire 'if' statement replaced?
#  351|     (void)constructed;  /* Not used, but passed for uniformity of such calls.  */
#  352|   
#  353|->   if (tag < 0x1f)
#  354|       {
#  355|         buflen++;

There are also couple of reports about the function default_homedir(), which is supposed to return const char * but in reality, it sometimes allocates memory while callers do not expect it so they do not free:

Error: RESOURCE_LEAK (CWE-772): [#def11]
gnupg-2.2.27/common/homedir.c:477: alloc_fn: Storage is returned from allocation function "default_homedir".
gnupg-2.2.27/common/homedir.c:477: var_assign: Assigning: "newdir" = storage returned from "default_homedir()".
gnupg-2.2.27/common/homedir.c:488: noescape: Resource "newdir" is not freed or pointed-to in "make_absfilename".
gnupg-2.2.27/common/homedir.c:490: leaked_storage: Returning without freeing "newdir" leaks the storage that it points to.
#  488|     the_gnupg_homedir = make_absfilename (newdir, NULL);;
#  489|     xfree (tmp);
#  490|-> }
#  491|   
#  492|

Thank you. The initial run was against olderer version of gnupg (and had one issue in g10/keyedit.c -- see the new patch with fixup). Now I ran it against the version 2.3 and there are couple of more issues to be fixed (rebased on top of already applied changes and the previous commits).

Ok.
But`CFLAGS_FOR_BUILD` not mentioned in build rule for mkheader

Thank you.

Thank you. Applied and pushed.

Thank you. I'll take care of this.