@jukivili Good to know.

My vote would be to invert the logic of the last patch and add "no-hashing-in-parallel" as a compatibility flag and make the other behavior default and then to push it at least to master or even to 2.4.

BTW. The icon is breeze "view-sidetree" which I found fitting to split a larger opaque MIME structure (e.g. an encrypted mail) into different parts.

I have added an observer repository for mimetreeparser here. So you can now use the keywords like "GnuPG-Bug-Id:" and your commits will be visible here on the platform. We can later switch the "upstream" URL to something else of course. https://dev.gnupg.org/source/mimetreeparser/

I am not really a fan of this. I can respect this as a wish but it is currently not my vision. What you are really asking is basically that we lead the private users into sending encrypted mails without knowing that they are doing it. This will lead to frustrated users who then blame KMail for their bad user experience.

Fix pushed to the 23/07 branch and master.

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

There are some more surprising results like on my windows test keyring it would always report "5 new signatures" regardless of how often I ran the script ;)

In T6379#172803, @ebo wrote:

Noticed in gpg4win 4.2.0-beta373:

For Brainpool and ed/cv25519 keys it is not possible to move a subkey to a smart card with Kleopatra. The error message is "invalid value".
Moving the main key works, though. The command line works for all keys types, of course.

😂 I literally laughed when I saw this. You are taking this so much further and faster then I expected. Great job!

Normal priority to get the _1_ removed when no folder with the same name already exists in that location.

Strangely enough this does not happen on linux. Maybe related to the KMime changes we have there?

For S/MIME archives the output for e.g. testfolder.tar.gz.p7m is now named "testfolder.tar.gz_1_/testfolder" with the "_1_" even added if there is no "archive.tar.gz"

So some more data from 2.4.3. Once unpatched and once with your patch.

I found this important to do because the SHA-256 results from your test looked extremly slow.

For comparison here are my benchmark results on the same system. Once on Linux 64 bit and once on W32 and once with W64. All runs are native to exclude any virtualization issues.

I also thought that it might be useful to set the subject as filename (not the mime filename but the encrypted PGP filename)

This does not seem to work as I understood it. Just naively adding a setEncoding(GPGME::MimeEncoding) on the output GPGME Data object resulted in an empty file. So this needs a bit more analysis.

In T6199#172571, @CarlSchwan wrote:

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

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).

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.

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.

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 :/

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.