Won't be fixed for the creation thing.

This is the old code from gnupg-2.0/agent/gpg-agent.c:

inotify is already used used on Linux to check for a lost homedir. The once-in-a-minute check should be the same as with the other daemons and has proved to be very useful. The whole thing has been discussed over and over again a long time ago and - as with other system daemon - we agreed on scheduling at the full second.

And then, we need to use less leaky version of mpi_cmp (because mpi_cmp calls mpi_normalize, it's not good).

And this is for less leak for _gcry_dsa_modify_k:

This is needed before we remove leaks by mpi_add in _gcry_dsa_modify_k :

Commit rC35a6a6feb9dc: Fix _gcry_dsa_modify_k. is related, but it doesn't matter for usual compilers (it's an issue for MSVC).

it seems more sensible to me to not pass DBUS_SESSION_BUS_ADDRESS unless explicitly configured with an option

It's pretty ironic that we added DBUS_SESSION_BUS_ADDRESS because of pinentry-gnome3 and now we need to add an option to remove it because of pinentry-gnome3.

Removed extraneous space.

Added pkg-config modules for all previously manually linked libraries, which seems to be required for dynamic builds.

If you say so, i won't press this. I will just leave this ticket with an observation that even for someone who reads the source code this is not intelligible. At the top of gpgconf_list in g10/gpg.c, the comment says:

My proposed solution is to add a config variable pinentry-ignored-env to gpg-agent which specifies a comma-separated list of environment variables which should not be passed from the client to pinentry.

This warning doesn't seem to be complete; no such warning is produced on the first run of gpg. For example (with no ~/.gnupg):

Thank you Daniel for forwarding this. To get the attribution right: I did not find the issue, Todd Zullinger reported it on https://lists.gnupg.org/pipermail/gnupg-devel/2024-October/035661.html

aheinecke: Yeah, but I did quite some changes to build.sh for a real out-of-source build (w/o copying files)

$ man gpg
       --gpgconf-list
              This command is similar to --list-config but in general only internally used by the gpgconf tool.

In general, "only internally used" means: Don't use this yourself or accept what it does.

This is needed for RFC6979 flag support.

Just so that its not overlooked and you are meaning something different. But I had the Qt6 / KF6 branch working with the --appimage parameter.

in combination with this patch it should be easy to modify gpgconf_list() (in g10/gpg,c) to emit compliance from the settings/cli options.

Please see the 5-patch series posted on gnupg-devel for a fix for this.

Maybe we have a different understanding of what "backward compatibility" means. if someone needs backward compatibility to communicate with someone using an RFC 4880 client, then surely they don't want to use a pubkey algorithm that isn't specified in RFC 4880, right?

Fixed.

In T7515#197774, @TobiasFella wrote:

I'd suggest removing:

I'd suggest removing:

Patch sent to gnupg-devel. I think this can be applied to the 2.4 series as well.

If a single OpenPGP certificate is updated then we now show the same detailed information for the update from WKD as for the update from a keyserver, i.e. if the certificate didn't change via WKD then we say so.

I think there's some confusion.

No real world bug reports for this and thus a backport has a small risk of a regression.

Thanks for that info. I tag it as FAQ and change the subject in case someone searches for such a problem.

The compliance mode likes 4880 or 2440 are only here for backward compatibility in case that is needed. New keys shall always be generated using the current default algorithms. Note that a mode like de-vs is different in that it is used to comply with certain regulatory demands and not as a backward compatibility hack.

After a lot of digging I finally found the problem. It's actually not Gpg4win/GnuPG, but it's the Bitwarden desktop app. They recently added support for it to function as an SSH agent, and even though I have not enabled that feature, it's hijacking the socket anyways. When I close Bitwarden the issue disappears. The issue is logged in bitwarden/clients#13150.