In T5444#146395, @werner wrote:

You should anyway use --quick-gen-key.

This is still broken on 2.5.5.

Done

Re-opening because I think rGaa36f6ae8bae needs to be backported to GnuPG 2.4 (see T7568). The fix for T7309 which introduced the regression has been backported to GnuPG 2.4.

I've offered https://github.com/bestpractical/gnupg-interface/pull/16 to GnuPG::Interface, and am testing it out in debian unstable.

I'll work on making a patch to offer a flexible test suite.

Alternately, i suppose we could ask GnuPG::Interface to drop the variant parts of that test entirely. @werner, If you have a preference for what they test, it would be good to know. I suspect your opinion would carry weight with the maintainer there.

Well, we also have the gpgme test suite which tests a couple of other things and for obvious reasons we need to keep this stable. Granted, sometimes we had to change the gpgme test suite as well. My personal preference would be your second choice.

Thanks for the fix for the double-free on --no-sig-cache, that appears to be an issue on all released gpg versions, as i can crash them directly when i --no-sig-cache.

Interestingly, from this i'm learning that the patch actually *normalizes* the output so that we see the same thing regardless of ordering. the different output based on certificate order happens only in the unpatched version.

Please test without the --import keys.pgp -- just import filtered.pgp or filtered2.pgp.

I can't replicate your findings here . In a test directory w/o a gpg.conf:

Uihhh

with --no-sig-cache --check-sigs i get the following error with the patch applied:

Did you also tried with --no-sig-cache ? That could help to get a better insight into the reason for that difference.

OK, now i really don't know what the issue is on the 2.4 branch. trying to replicate it with and without this patch, the --with-colons output of --check-sigs appears to depend on the order in which the certificates were ingested.

hm, digging a bit further, i think the above changes have to do with third-party signatures using SHA1, *not* with expired certifiers. in 2.4.7, i see a change from % to ! for these certifications. (2.2.x, which i know is EOL) shows the difference between ? and !. I'm trying to make a simpler replicator now.

With the patch "gpg: Fix regression for the recent malicious subkey DoS fix", there is a change in how gpg --check-sigs reports certifications from expired keys.