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.

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.

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:

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

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.

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.

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

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):

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 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?

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.

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.

i see the tag has been published now, thanks! Given that this is an ELTS release, I'm assuming that the lack of a gnupg-2.2.46.tar.bz2 file on https://gnupg.org/ftp/gcrypt/gnupg/ is deliberate.

glad it was useful!

will you tag 2.2.46 in git as well? it appears to be on rG7e48331afb611a2b39e5ae74b8806b84e54db924 but i don't see any tags.

Hm, this might also be relevant in GnuPG's codebase in common/exechelp-posix.c, which contains a copy of the same code (licensed differently).

thanks for the clarification. i was not objecting to the workflow, i was trying to understand so that i can interact with the bug tracker appropriately. I was unaware of the difference between "milestones" and other project tags. I'll try to get that right in the future.

@ebo i'm not sure i understand why you removed the gnupg24 (gnupg-2.4.5) project label. the report indicates that GnuPG 2.4.6 at least (other versions untested, but i didn't see a gnupg24 (gnupg-2.4.6) label in this system) produces MPI artifacts for EdDSA/Ed25519 signatures that are non-compliant with all the known specifications. the 2.2 series appears to retain compatible MPI formats.

after a bit more testing, it looks to me like 2.2.45 will revise the signature packet to use 0x00ed as the MPI header for r, if it receives input from 2.4.6. And 2.4.6 will revise the signature packet to use 0x0100 as the MPI header for r. So the same OpenPGP self-sig will change shape each time it is passed back and forth between the different versions.

Interesting. i'm also not sure this is a good feature. I also still don't think the gpgv man page explains this clearly, but if you don't want to clarify it, i won't bother re-opening this issue.

Thanks for this prompt fix! but they're still not aligned. with this fix, the Synopsis is:

All applied and more fun with cherry picking in the future ;-)

fwiw, i've just shipped a patch to correct this change in behavior in the 2.2 branch debian. Many thanks to @gniibe , on whose work in the 2.4 branch this is based, and to @ametzler1, who did the backporting to 2.2. I've also written a test which tries to tickle this bug. It fails with unpatched 2.2.43 as emacs times out signing and encrypting mail as epg.el deadlocks with gpg.

that looks like it was a problem in the original text, not something i introduced. If you find anything else that needs fixing, please go ahead and fix it to! no need to wait for me.

It seems too late to reject on import, given that people might already have such a secret key in their ~/.gnupg/private-keys-v1.d/ They might have had it for years without knowing it, because the failure is so intermittent. They might just think that they did something wrong, and when they try again it works. It would be great to be more robust than that.

Maybe there's a 4th possible option that's better than the three i identified?

So i see a range of ways that any OpenPGP software could deal with this:

Are you saying that concern about "risking a regression" is the reason to not fix this bug, which is itself a regression, and was introduced into the a point release in the current "long term support" branch?

Thanks! please consider adding it to 2.2 and master as well. I suspect it's more outdated than it would be if it had been shipping in the upstream tarball.

I note that @DemiMarie offered a patch for this over a year ago. It doesn't appear to have had any review. If it's good, maybe apply it? If it's problematic, can we identify the problem?

by all means, please proofread it! thanks for the attention to detail. what was the grammar glitch?

I understand the desire for stable behavior, and i agree that a change here might affect verification of existing signatures (and might mean producing signatures that will be misinterpreted by older versions).

I have also not found a straightforward way to correct a cross-signature that was made with a weak digest algorithm using GnuPG.

The patch supplied here should apply to STABLE-BRANCH-2-4, but it should also be easy enough to backport to STABLE-BRANCH-2-2 and STABLE-BRANCH-1-4. For GnuPG master, i recommend actually removing the option.

One use case that seems sensible to me is to try to convince a long-running operation (e.g. a sequence of key generations) to all use a single timestamp. In this scenario, there's no interest in setting the clock to be some variant of the current time, just an interest in it remaining fixed across all the operations.

It looks to me like it's marginally more common to *not* use the lib prefix for pkgconfig files:

Note the relationship to T4195, T4826, and T4766

@werner i'm not sure i understand what "easy to enclose them in angle brackets just for comparison" means.

I recommend, when making a User ID with only an e-mail address, to populate the User IDs by wrapping it in an angle bracket, rather than just leaving the raw e-mail address. It's not just the regexp matcher -- there are other pieces of OpenPGP software that won't recognize a raw e-mail address in a user ID as an e-mail address. It also makes it easy to distinguish such a User ID from a User ID that is not at all an e-mail address.

Thanks, @gniibe -- i agree that this change to put_cert should be helpful, when encountering a certificate that is already invalid.

Thanks for the followup about R3, @mpilgrem! Looking at your logs in more details, and the source code for find_cert_bysubject in dirmngr/certcache.c, i think i see what the issue is. It's slightly more subtle than not terminating early if a known trusted root can validate a truncated chain.

@mpilgrem, i'm glad that removing the DST Root CA X3 from your windows control panel worked for you, but it still doesn't seem to be a reasonable fix from a GnuPG user perspective

@mpilgrem: in the meantime, for connecting to keys.openpgp.org, which *has* cleaned up its certificate chain, you might also want to try killing your dirmngr process, and/or cleaning up the data in .gnupg/dirmngr-cache.d/.

Basically, the website in question (e.g. https://openpgpkey.gnupg.org/, which exhibits this problem) serves up three certificates:

I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.

Debian requires all builds to use software that we have local copies of in the archive, which appears to rule out the use of speedo (it fetches source over the internet during build). So i've modified debian packaging to annotate that the Windows builds need a different version of libgpg-error than that defined in configure.ac.

this looks similar to https://dev.gnupg.org/T5935 and https://bugs.debian.org/1008573

Thanks for working on this, @gniibe! Maybe it would be useful to add a test to the test suite that tries to import and use a secret key of this particular structure.

thanks, looks good!