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.

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.

This will not translate into the new addon and is too large a change for the current one.

This no longer happens. It was a case of such inline signature images. Maybe if they are added through the clipboard they dont get a filename or something like that.

I do not agree that this will help much, but I am all for changing the string "Find more info on Wikipedia" into something like "See the Quickguide for a short introduction".

I give it the same prio as the parent task

Yes, this should be a fairly low hanging fruit and would improve UX for some users probably quite a bit. So while not very important I give it high priority because we should do it sooner.

I would give this normal priority still. In guess in most cases its not an issue but when it is an issue it will feel like a bug.

Yes this would be a bit more consistent. The idea was that when decrypting there is not much to see in the window so the only actionable item should be at the top. But consistency is better.

! In T6561#172087, @werner wrote:
FWIW, gpg shows the actual cipher and encryption mode with -v. For example

In T6561#172083, @werner wrote:

s/CBC/CFB+MDC/

Strange though, it appears that it is cancelled before finishing the job, no result file is created. But maybe that is when finalize or something would be called in Kleo.

When testing this I noticed that the cancel does not seem to have an effect on normal file jobs run directly through Kleo either: T6560 This is probably not a regression as you fixed here that the cancel is even propagated to the jobs but still I find that disturbing and buggy.

Yes, that was the intention eva reminded me that I had not done this yet, but the next releases of GnuPG VSD will have action/help_contents=false in their action restrictions.

rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.

For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.