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.

it would be great to include a test in the test suite that ensures that the --status output behaves as expected in the face of expired or revoked keys.

Please use "unbreak now" only for *released* software with a criticial bug.

No real world bug reports for this and thus a backport has a small risk of a regression.

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?

Sorry, this will not be fixed for 2.4.

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, but without the change to de-vs as i think the comment in rGc2ff47d5bcd2953fc2095ef2242af2c7e9cd4420 indicated that you only wanted to rebase de-vs to --gnupg in the 2.5.x series.

@gouttegd: Good idea. I did this with the above patches.

Fixed in 2.5.2.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.

In T2169#196673, @werner wrote:

Shall we handle this with additional retry prompts, w/o a timeout? I think this makes sense because creating keys with a backup file and a passphrase is a manual task anyway.

There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:

Change the encryption code to only allow 256 bit session keys with Kyber regardless of the preferences, iff --require-pqc-encryption is set. […] We could as well also encforce AES-256 also without that option.

What if we encrypt to several recipients, only some of them having a Kyber encryption key? Should we still enforce AES-256 in that case regardless of the preferences, and assume that by now everybody should support AES-256?

Love it! I think I am going to use “post-heffalump crypto” from now on. :D

But keep https://www.cs.auckland.ac.nz/~pgut001/pubs/heffalump_crypto.pdf in mind ;-)

I wrote it with PQC security level in mind which requires AES256 for the session key as well.

That is what I expected. Meanwhile I re-read the code and history and can tell that the comment is not correct. I wrote it with PQC security level in mind which requires AES256 for the session key as well. However, during the migration phase and as long as --require-pqc-encryption is not enable we should allow an AES-128 session key. This is for the rare case that encryption is also done for non pqc keys which don't have the AES-256 capability set.

Here you are:

At gnupg/g10/pubkey-enc.c you will find

There is another customer request for this too.

A workaround exists with the new option --ignore-crl-extensions.

Done for 2.5.0.

Done in 2.5.0.

Fixed in 2.5.0.

Fixed in 2.5.0.

While reviewing this task I noticed that I wrote adding a -p option. This is non-sense, because -p is to preserve permissions at extract time; this is unrelated to the last modification time. Standard tar extract files and set the modification to the one given in the tarball - unless you use -m to use the current time. Thus this task is actually a bug and not a feature request. For backward compatibility this will be done only for gnupg26 for now.

You should use gpg-agent's integrated ssh-agent. It is anyway much more convenient. I'll move this task to gnupg26, though.

Backported to 2.4 to go into 2.4.6

Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.