And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

I doubt that we will ever be able to use the flexible array thingy. The old pattern has been used for nearly 50 years and replacing it will just introduce bugs.
Do you use offsetof for that reason?

Thanks, we will take care of this.

Let's fix this in Libgcrypt (ignore setting of the handler)

This is related to T6511

I consider the entire idea of receiving a passphrase and data on the same channel to be a bad for security and robust coding. The whole thing is a historical oddity which we kept for the sake of mutt(1)'s legacy way of invoking pgp. Thus I won't consider 3) the best option.

With my fixes I now get this:

Actually two bugs. Easy to test on Unix with a small (e.g. 10MiB partition).

Seems to be gnupg 2.4. ec 112 is ERROR_DISK_FULL.

I don't think this is a regression or something we can do anything about. Note that we see the same thing also on the command line. Actually I have seen the very same thing pretty often with USB devices. Thus lowering priority.

We have seen this problem in the QA this week and could identify that this was a ERROR_FILE_INVALID (ec=1006,"The volume for a file has been externally altered so that the opened file is no longer valid"). We also noticed disk errors in the event logger but did not recorded them. The USB stick was not unplugged but merely used with VirtualBox.

High priority because I a fear that we will soon start to receive support questions related to this.

I guess kleo does a directory listing and then sorts hat listing the view Using the name by default but you can change this. Passing this list down to gpgtar is likely the original list as received from the OS. I also guess it will be easy to sort this but I'll give it a low priority.

Well, it Just Works(tm). You should make sure that a /run/user/NNNN direcory exists so GnuPG is able to create its subdir for the socket files.

To align the default expiration time with the BSI approval and other related software we change this now to 3 years.

Works in kleopatra; tested with gpg4win-4.2.0-beta339.

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

See also commit rG6fcc263c18 from 2020 where I switched to D-lines.

Let's schedule that for 2.6

Hmm, gcc used to figure out that attr is initialized by npth_mutexattr_init. One of these gcc warning regressions?