Daniel confused --list-options with --dump-options. The linked completion script uses the latter.

Needs to be tested/verified by other developers. In short you do

./autogen.sh
cd packages
./download.sh
cd ..
./build.sh --appimage --builddir=...

If you omit the --builddir=... option then ~/b/SRCDIRNAME-appimage will be used.

Building an AppImage including Kleopatra and Okular works now (again) in the gpg4win-5-branch.

I'm glad that inotify is already in use, that's a reasonable thing on the Linux platform.

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.