Thank you @werner ! I can confirm that the patches that have landed on STABLE-BRANCH-2-4 do clear up the DoS i was seeing for signature verification.

The patch below fixes the master branch to be compliant with the standards for CSF message generation and verification.

Also fixed for 2.4

This has been fixed in master with rG48978ccb4e:

Right when you use a different homedir you also need to pass --homedir to gpgconf or set GNUPGHOME before invoking gpgconf. If you call gpgconf via GPGME the --homedir option is passed; afaics we don't have a kill option gpgme.

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.

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

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.

Can now be tested after the release of libassuan 3.0.2 (T6163)

As I am delving a bit into cryptocurrencies and since i have a ledger security token and a bip32 24 word mnemonic now backed up as stamped metal.

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

I was referring to your comment earlier in this very issue:

Where do you find a statement that --keyring is deprecated? I planned to to remove it with 2.1 but there were too many requests to keep it and live with the problems of multiple keyrings. Thus the option stayed, it is just so that in addition to pubring.gpg and pubring.gpg we now also have the option for keyboxd - which is the default for new installations.

Looks the same in VSD 3.3.0 ans in Gpg4win:

I'm not going to keep re-opening a ticket that you keep closing. So i'm just going to state here what i believe to be the upstream intent is. If you think this is wrong, i'd love a clarification. I believe that "deprecated" means that the GnuPG project believes that an option or configuration choice should not be used, and will eventually go away.

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.

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

As usual use ./deadbeef.... as the filename to distinguish it from a fingerprint.

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.

I understand you as saying you won't fix the fact that the warning is not emitted during initial homedir setup. I'm not sure why that scenario is not worthy of a warning when a post-setup scenario is, but okay.

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

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

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.

Removed extraneous space.

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:

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

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

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.