Thanks. Applied to 2.2 and master.

I still don't think that it is correct. We would also need to turn fd from an int to a gnupg_fd_t (ie. a HANDLE under Windows) which requires other changes and should be done in the other parts of the code as well. assuan_sock_close also delegates to the system specific function and on Windows removes the fd also from the cygwin table. This may trigger other bugs so I'd like to keep it as it is to go with the code which has been in active use for a long time - at least for 2.2

0.2.0 was just released with support for GCM. Tested against openpgpkeys.pm.me

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

It worked! You were right!

Thank you for your prompt help. It's much appreciated.

rG4c8d5eb0bdd3: agent: Allow TERM="".

I see. Thank you @werner . For clarity could you please link the patch that was not backported to 2.2.?

Mails crossed ;-)

But @werner what's the value $TERM *supposed* to have? When gpg is invoked straight by Gnome? I can run the command sh -c 'env | grep TERM > ~/gnome-term.env' in Gnome's "Run Command: interface and then the file ~/gnome-term.env says TERM is set to nothing (It is set, but the contents is a "" string).

Ah wait. This has been fixed in master a year ago but was not backported to 2.2; see T4137. I'll add it to the forthcoming 2.2.22. Thanks for the report.

The warning above is harmless. Both strings are actually the same but stem from different versions of the autotools helper scripts

Unfortunately I've had some trouble compiling the latest git version of GnuPG for NixOS - I got this warning which turned out to be a blocker:

Without really looking at your report: May it be that this is because Pinentry does not get the WAYLAND_DISPLAY variable as reported in T5016? This will be fixed in 2.2.22 which I hope to release this week.

I take some of my words back - using or not using MOZ_ENABLE_WAYLAND=1 doesn't make a difference eventually - If Firefox is launched by Gnome and not gnome-terminal, pinentry fails to launch with and without MOZ_ENABLE_WAYLAND.

The CRL states how long it is valid and we cache it for about that time.
OCSP responses are by definition not cachable but we allow for a clock skew of 10 minutes.

Was easier to fix than expected. Thanks for the report. Fix goes into 2.2.22.

[These damned typos in commit messages ;-)]

I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with

The keyserver options control how gpg imports or exports keys to the keyservers. Thus they indeed belong into gpg.conf.

It's pretty minor bug, it only matters for some strange scenario on Windows like:
(1) a user runs gpg --card-edit or gpg-card and keeps the user interaction for some reason (say, forgetting the terminal interaction), which keeps the pipe connection from gpg-agent to scdaemon
(2) While the pipe connection is used by the user interaction above, from another terminal, the user invokes gpg (say, gpg --decrypt) which uses socket connection from gpg-agent to scdaemon

I mean these uses of close:

diff --git a/scd/scdaemon.c b/scd/scdaemon.c
index b7bbc0361..a6925eaf9 100644
--- a/scd/scdaemon.c
+++ b/scd/scdaemon.c
@@ -797,8 +797,8 @@ main (int argc, char **argv )
       /* We run handle_connection to wait for the shutdown signal and
          to run the ticker stuff.  */
       handle_connections (fd);
-      if (fd != -1)
-        close (fd);
+      if (fd != GNUPG_INVALID_FD)
+        assuan_sock_close (fd);
     }
   else if (!is_daemon)
     {
@@ -932,7 +932,7 @@ main (int argc, char **argv )

I have a couple of keyserver-options statements in there, but no keyserver statement. Should the options be located in the dirmngr.conf file instead?

I guess you have a keyserver statement in your gpg.conf.
By using

Release done.