Thank you for your report.

This was tested by me against the actual sample and the sample is now part of our internal regression test suite.

I ran the test AES.OCB encrypt only, no compression test with the same GnuPG 2.4 version on Linux.

Another request for this would be that the for expired keys a --locate-key might be triggered. GpgOL currently does this in internal logic and this causes GnuPG to refetch the key e.g. from WKD if the key came originally from WKD. https://bugs.kde.org/show_bug.cgi?id=471911 I am not sure if the expiry checker already does this, but someone pointed me to the KDE bug and I will point back here because it makes little sense to fix this in the kmail resolver when we want to replace it.

This has a serious usability issue. If you cancel the password entry when exporting it reports success and creates an apparently valid secret key file but without the subkey you intended to export. So worst case the user thinks he has a backup but instead has no backup :/

with the new gpg.exe you gave me for testing it looks good now:

related to T6528

No. Missing mapping in iobuf.

But yeah, General Error is never good :)

For what its worth, GnuPG keeps the timeout value this way for some reason with server usecases if I remember correctly so that other keys are tried when one times out. In GnuPG VS-Desktop we configured a 10 Minute timeout as a compromise.

gpgrt version?

I get a failure status, but a different one.
Seems to be an other issue? But wasn't (ec=112) disk full?
And the disk of the Windows VM must have been running full with that file, before the start there were ~2,6 GB free:

Followup on this is: T6574

I noticed this recently, too. Should be fixed. Especially if we want to use this in KMail, too.

I changed the title accordingly. I think when we call the option "restart background processes" we should not implicitly rely on a non empty keylist to start the gpg-agent but instead trigger it explicitly

I think the priority is low because the optional columns are not really that useful for most users and were mostly added as a "nice to have" feature. The details are in doubt available e.g. through the certificatedetails widget.

works as described

This works.

OK. I'll take the signing part (possible performance improvement).

No, it doesn't do even that. Sorry, I only tested that with 3.1.26 which is older than your fix.
No encrypt-only key is offered or selectable for signing any more in Gpg4win-4.2.0-beta360

I looked through the code. What I observed is:

• By jussi's improvements, AEAD code is optimized with AEAD_ENC_BUFFER_SIZE of 64KiB
  • this contributes much for better performance
• If we invoke gpg --sign | gpg --encrypt then we can take advantage of multiple CPUs (but gpg is currently not automatically threaded in that way)
  • signing could be improved likewise, using larger buffer like 64KiB
• CFB+MDC, it uses two functions together; encryption and hashing, and not with larger buffer like 64KiB
  • when signed, it also does hashing for signing, so three functions

The case in check_special_filename is fixed. So, there is no cases in GnuPG where the value of out of range is silently converted to wrong value.

Remaining places are:

• common/sysutil.c debug output to format HANDLE --> T6597
• common/sysutil.c iobuf_get_fd and its use cases --> T6580
• agent, kbx, scdaemon, dirmngr: socket and FD2INT/INT2FD --> T6598

I don't think that Kleopatra allows to select an encrypt-only key for signing because I have fixed exactly this issue a couple of months: T6456: Kleopatra: Offers encryption-only OpenPGP keys as signing key.

This works, when sign is selected and no standard OpenPGP key for the mail address exists.