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.

The OID is used for fingerprint computation, which complicates things.

Using the shorter OID for v5 is on purpose; thus we need to fix the export.

I don't think it makes sense to add such a feature/bug fix to the old versions.

Please go ahead and apply to master. I'll take then care of backporting.

Done in GnuPG 2.5.0.

This fix has the problem that for a signed message where the signing key is not available gpg emits the decryption_failed status line and prints "WARNING: encrypted message has been manipulated". This is because we use log_error to show that the signature could not be verified due to a missing key. The extra check we introduced with rG50e81ad38d2b lloked at the error counter and thus triggered the decryptio failed.

See new subtask T7290 for smartcards and the link entries mentioned above.

So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).