This has long been implemented due to the backport of the P12 parser and the recent rewrite of it.

gpg --export-secret-subkeys --armor 704769B8D5C15319A27C74BBB47052506607DA6E confirms that gpg 2.4.1-beta21 outputs nothing if the password entry is canceled.

Of course, it's about right clicking the encryption subkey. That's what I tested. Anyway, cancel wasn't handled properly. Now it is.

In T5755#172514, @ikloecker wrote:

I cannot reproduce the problem with Cancel. When I try this, I get the error "The result of the export is empty." and nothing is written to disk. I'm using GnuPG 2.4.

Anyway, handling of cancel was indeed missing.

Just a quick caveat: Save all attachments works really bad with complex message structures. If we now offer the option to delete all attachments after saving them this could have desastrous effects, i.e. the user could end up with unusable MIME-parts on their disk. I don't remember when I noticed this. Maybe with attached email messages, maybe with signed/encrypted messages, maybe with a combination of both.

The expiry checker checks for expiry. It doesn't and shouldn't do anything else.

I cannot reproduce the problem with Cancel. When I try this, I get the error "The result of the export is empty." and nothing is written to disk. I'm using GnuPG 2.4.

We should make building with LDAP mandatory.

It seemed I was wrong that it is due to buffering.
In the use case of --sign and --encrypt, hashing is done with IOBUF's 64KiB buffer (already).

I observed the benchmark by libgcrypt (Windows emulation 32-bit on Debian):

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