Thanks. Fixed in: rEd14c69a7f256: Avoid use of 'nullptr' for an identifier.

I found fd resource leak in gpg-agent.

• gpg-connect-agent "scd killscd" /bye seems not release a file descriptor somewhere

For the second case, I think that gcry_kdf_defive should not be called with pw="". The result of FAILURE gpg-exit 33554433 comes from the log_error after failure of gcry_kdf_derive.

Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html

Good catch, @ikloecker !
I located the bug in GnuPG, and the fix is: rG71840b57f486: common: Fix a race condition in creating socketdir.

With the change, T7169 is fixed (by side-effect).

Pushed the change: rE1860f6407f83: spawn: Add new function to modify environment.

Replacing gpgrt_spawn_actions_set_environ by gpgrt_spawn_actions_set_envchange is not good, as it's exported and already used.

Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.

The OID is used for fingerprint computation, which complicates things.

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

Here is my attempt:

It is reproducible bug even with master branch.

I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.

Fixed in pinentry 1.3, when using GnuPG 2.4 or later.

Fixed in libassuan 3.0.0.

Done in GnuPG 2.5.0.

The change of spawn functions (basically, it was factored out to libgpg-error) results more possibilities to have blocked scdaemon, since the implementation in libgpg-error introduced context switch points when it spawns a child process.

Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.

Do you have scd-event script in your GNUPGHOME?

I applied rGb804378f183f: kbx: Fix a race condition on DATABASE_HD. in master. Let us see how behavior changes.

I found one problem. This problem may result lock-up on Windows, I suppose.

I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Single scdaemon, two threads handling DEVINFO --watch simultaneously, by pselect + read.
Two threads waken up, but it was only one thread which can read(2), another was blocked (before the fix).

For POSIX, I found an issue of T7151.
If you are using multiple clients which invoke SCD DEVINFO --watch, the problem should be fixed.
If it's not the case, let us locate a bug (or two).

Fixed in rGfc30f7059650: scd: Fix DEVINFO to allow multiple clients.

I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).

Pushed the change in: rC38742196c04c: cipher:kyber: Add gcry_kem_genkey to support deterministic op.
rC4876a1a45c25: tests:kyber: Add genkey and encap KAT tests.

Fixed GnuPG 2.4 in: rG730593affa91: common:w32: Don't expose unused functions.

For now, I'm using this to avoid failure of make check (invoking gpg-agent by gpg-connect-agent).

diff --git a/common/stringhelp.c b/common/stringhelp.c
index 9a2265258..6596c65cd 100644
--- a/common/stringhelp.c
+++ b/common/stringhelp.c
@@ -70,6 +70,22 @@ change_slashes (char *name)
 {
 #ifdef HAVE_DOSISH_SYSTEM
   char *p;
+  /* 0: don't know yet, 1: it's under wine, -1: no */
+  static int semihosted_by_wine;
+
+  /* Under wine, no change.  */
+  if (!semihosted_by_wine)
+    {
+      HMODULE hntdll = GetModuleHandle ("ntdll.dll");
+      if (hntdll
+          && GetProcAddress (hntdll, "wine_get_version"))
+        semihosted_by_wine = 1;
+      else
+        semihosted_by_wine = -1;
+    }
+
+  if (semihosted_by_wine > 0)
+    return name;

libgpg-error fix is done in: rEc2a713fe11e3: w32:spawn: Remove unused function get_max_fds.

Since CreateProcessW allows two ways for lpEnvironment (one is ANSI environment block, another is Unicode environment block), if we want to support these two ways for users' of gpgrt spawn API, we would offer either:

I'm talking about CreateProcessW and how a user of gpgrt spawn API can specify lpEnvironment (when needed).

Thank you. Applied.

Thank you for the bug report and your patch.

Please note that gpgrt_spawn_actions_set_envvars is W32 specific API in libgpg-error. Currently, the behavior with ASCII string is defined.
The patch is an answer in future if we want to extend the semantics supporting UTF-8.

Here is my attempt:

Use of execve is better (avoiding use of environ).

Fixed in: rA69069bc63e6b: Remove an declaration for an unused function

I re-consider. Adding arguments to existing gcry_kem_keypair is not good since it introduces API break.
Instead, I add gcry_kem_genkey with additional arguments (which can be used for deterministic key generation).