Reproducibility
The problem cannot be confirmed generic on domain level. I can reproduce the effect with keys shipped from my domain, i.e. email addresses @shimps.de, but the issue vanishes when I try to reproduce it with email addresses @gnupg.org as e.g. Werner's address.

Well, the different outcome depends on the order of the certificates or the string comparision in keyboxd. So it is not a keyboxd vs. pubring.kbx thing.

Okay, I can reproduce it when not using keyboxd.

This is very similar to T5780 except that it concerns a different operation and thus a different window. The fix is likely the same as for T5780.

I can't remember that we ever had support this. It is also not easy to come up with the good way to present the status for all files in a folder. We would need to define a format similar to what sha1sum uses: A list of file with they signature file or so. Note that kleopatra has support for running sha256sum in such a way.

Sorry. I can't reproduce this. Neither with master nor with the 2.4 repo version.

We don't have this exact action on windows, but the normal "Decrypt & Verify" action shows up for folders there (and doesn't work either).

All changes are pushed to master.

the reproducer is:

I don't think this is fixed. With this patch in place, if i import blocker.cert first, and then import distsigkey.gpg, it looks to me like i still can't verify signatures made from any of the GnuPG signing keys.

Use of mpi_cmp is now being fixed, by providing _gcry_mpih_cmp_lli function.
Along with that, we need to fix use of mpi_cmp_ui, since it's skips earlier depending its limbs.

diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c
index 170dce12..e010e182 100644
--- a/cipher/dsa-common.c
+++ b/cipher/dsa-common.c
@@ -25,6 +25,7 @@

Just a note that i've tested this and --clearsign appears to be problematic for 2.4.7 as well as 2.2.40.

a demonstration:

Here we go:

Thanks.

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

The actual cause here was that right before storing the imported key we need to decide whether to insert or update a keyblock. For this we need to lookup the key in our database and the lookup function does the usual thing by looking at any fingerprint. This is wrong: Here we need to lookup only by primary fingerprint. This is what the above patches do.

That is not a new issue. We have the very same issue since ever. However, without keyboxd you had random results depending on the order of the keys in the keyring.

To be clear about what's going on here, blocker.cert has simply adopted the primary keys of each certificate found in /usr/share/gnupg/distsigkey.gpg -- i think GnuPG requires each component key in its keystore to have a unique fingerprint across all component keys in the keystore. so when one certificate claims those fingerprints as subkeys, any certificate that has a primary key with a matching fingerprint gets rejected with doesn't match our copy.

thanks for correcting that, @ikloecker. i've corrected the initial report.

What about deleting the environment variable in gpg-agent:

gpg-connect-agent 'OPTION putenv=DBUS_SESSION_BUS_ADDRESS' /bye

or to use a pinentry-wrapper?

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

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.

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.

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

$ 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.

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?

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

I think there's some confusion.

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

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.

changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.

i see two forms of an initial resolution here: one is to have set_compliance_option always explicitly set opt.def_newkey_algo. The other is to check opt.compliance in get_default_pubkey_algo.

Thanks for the followup. As a downstream maintainer, it would help me a lot to know why this won't be fixed for 2.4. Do you forsee a specific problem with it? Does the subtle change in semantics of previously unspecified combinations/permutations of options represent something you're trying to avoid on the stable release channel? Are there bugs that users should be worried about?

Okay, thanks!

Fixed in master and the new gpgme-1.24-branch. Thus this fix will be in 2.0.0 and 1.24.2

Sorry, this will not be fixed for 2.4.

please prefer the patch here over the one on the mailing list. my followups to the mailing list are not going through due to some kind of intermittent IPv4/IPv6 deliverability issue. Sorry for the confusion.

Thanks for the fix, @werner ! Here's a comparable patch for the 2.4 branch as well, but without the change to de-vs as i think the comment in rGc2ff47d5bcd2953fc2095ef2242af2c7e9cd4420 indicated that you only wanted to rebase de-vs to --gnupg in the 2.5.x series.

I am pretty sure this was my fault: rM62b6c1f16 is the culprit.

@werner Thank you for the response. Is there a nightly build or similar that I can grab from somewhere to see if using the latest master branch solves the issue?

@gouttegd: Good idea. I did this with the above patches.

Thanks. I applied all 4 patches to master and did one additional change to get --allow-old-cipher-algos straight.

I never tested the WSL stuff with gpg-agent but I use the standard OpenSSH based ssh server on Windows on a daily base. It is actually part of our release build chain. A recent problem I encountered was fixed in master with rG2469dc5aae and should be backported to 2.4. Might be related to your problem but I need to read your detailed bug report more closely.

Here's all of the above patches squashed into a single patch:

attached here is a series of 4 patches that reinforce that the last --compliance policy option (or equivalent option, like --rfc4880 or --gnupg) supercedes any earlier one.

sorry for the confusion in the initial report -- the policy compliance option is of course --compliance, and not --policy, and i just miswrote it in one line of the description above. I've corrected it now, and all the rest of the report is still as it was.