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!

Thanks for looking into this, @gniibe! over on https://bugs.debian.org/1003313 Helmut is asking for a re-consideration because he wanted to match arm-linux-musleabihf. Would you be ok with a change like my proposal rE371d1c952297f781277b979a4662859ec80fe836 (on branch dkg/expand-musl), that expands *-*-linux-musl to *-*-linux-musl* ?

Thank you, @gniibe ! i'm applying your change to the debian packaging as 1.43-2. i'll let you know if it doesn't satisfy the folks trying to crossbuild debian on top of musl.