Alright. We use utf-8 in our template files and switch to QP encoding when needed.

Another possible change will be use of KEM interface for gpgsm.
Not high priority, but for long term code maintenance.

Done by T7649: gnupg: Use KEM interface for encryption/decryption

@werner I think these changes caused an ASAN failure that I reported in T7664. I think it would be good to get that sorted before a release.

Clean up finished by rG681d75404300: gpg,agent: Clean up around using ECC KEM.
Tested by make check and decrypting tests/openpgp/samplemsgs/pqc-sample-*.enc.asc.

FYI: I'd like to get a new release out after these changes.

Pushed all changes needed. Actually, agent side too.
Clean up will be done.

Meanwhile we have some support for an empty subject but gpgsm still prints an error notice. See the T7171 for more.

(2) Update the documentation of default-cache-ttl zero value disabling caching.

I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remeber that untile a few years, Windows had the opinion that Germany is the the Westeuropäische Zeit, i.e. Portugal or the UK.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.

It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.

Lucas Mülling commented yesterday on gnupg-devel:

A brief update: This feature has not made it onto the roadmap of specific things to implement so far.

BTW, fingerprints for X.509 are not well defined because you get a different one when changing the *unsigned" attributes. Not a common case but one should be aware of it.

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.