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.

In the past this was done by --set-filename in libkleopatrarc-win32.desktop. But I am happy if we close this and focus on T6530.

I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.

Yeah no progress for files larger then 32 bit o.O... But this used to work 😭

On 64 bit linux this works btw. so I think it comes down to the difference between 32 bit off_t and 64 bit off_t

Yeah, its the ugly off_t again. I am just testing how this works with single files above that threshold we worked quite a bit on this back in the days https://dev.gnupg.org/T2368

Well staying at 0 is imo worse then knight rider because that looks "stuck" and knight rider looks "working".

So we basically let gpgtar pick the folder name again.

Yes. I think for now we should ifdef the directory change to Linux, must be done in GPGME I think. I know its ugly to have it differently on both plattforms but while extracting in a subfolder might be more uncomfortable our users are used to this and this resolves the issue until we have better options with KIO.

Ok

Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.

ingo may have tested on linux where we never actually used gpgtar.

Left is the old behavior after "save all" right is the new behavior after "save all"

Mh, let me check where the size hint should come from and why it might be missing in my windows test. That is indeed strange then.

btw. this does not work on the decrypting side because kleopatra there apparently does not provide a size hint. So it goes:

As I already had my testsetup open I recompiled with your change and I tested manually cancelling and letting it run into the disk full error. In both cases the temporary file was deleted and the job was cancelled :)

Oh my, so I have not really tested this for nearly three months and had my head in the send when reviewing it. I really need to apologize for that. The performance improvement is _not_ what I hoped for if it is even there.