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.

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.

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

same with VSD 3.3.0 with gpg 2.2.46

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?

Gpg4win-5.0.0-beta32
Works!

Gpg4win-5.0.0-beta32:
The remaining attempts are listed:

You need to be asked this question when you restore the backup of all of your keys or when you migrate all your secret keys to a new computer.

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.

The situation seems to be even more complicated: If I click "yes" or "no" in this dialog, I *do* get asked for all certificates that are being imported. If I click "Cancel", no more dialogs show up.