Thanks. Wouldn't that require OpenLDAP on every system with gnupg?

Kleopatra should autodetect email messages if passed on the command line or opened via the file dialog. I think Kleopatra should accept any email even if not encrypted. I'm not so sure whether Kleopatra should become an application that offers its service for any email messages if there are proper MIME types for MIME-encrypted or MIME-signed emails.

In T6199#172571, @CarlSchwan wrote:

This will still more work to bring back the massive amount of unit tests. I'm also seriously considering to instead of moving this code to libkleo to instead create a new library with this and then have Kleopatra, kalendar, kube use it (and kmail too in the future but that would require a lot more work).

I started working on it. Current progress, I managed to move the mimetreeparser/partmodel from kalendar to libkleo and removed the few akonadi bits.

Ready for testing. I could view a signed PDF and verify the signature with the gpg backend, but other things may not work because of missing dependencies.

It turned out that my pinentry reported "fully canceled" on Cancel (see T6491: Pinentry-Qt: Password prompt for each subkey if password change is cancelled) which made gpg output nothing.

Tested and works now for me as expected. Thanks.

The original reporter mentioned that this only occurs when called from kleo. But let me recheck.

Also done for 2.2.

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

Same for the backport to 2.2 which uses the same test suite.

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.