gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7

But the original patch rG1b4ac98de7db: agent: Accept a trustlist with a missing LF at the end. was not working to allow missing newlines in gpg4win-5.0.0 @ win11?

That change is too complex for just getting a proper error message. The original patch covers the most common case.

This should also be fixed in 2.2 and 2.4 (if neccessary)

we haven't seen this in a while…

I applied it to the 2.4 branch but please do not continue to translate for 2.4. 2.6 (master) is the new target.

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.