I hate this ping-pong, but, as I wrote in my previous comment, for me canceling decryption does work on Windows, i.e. the gpgtar process does not keep running for a long time. That the gpg process keeps running is nothing Kleopatra can do anything about.

I have tested this with a self-built installer from a few minutes ago in my Windows VM. Whenever I canceled decryption (I tried it about 5 times), then the gpgtar process went away very quickly. The gpg process keeps running, but that's a bug in gpgtar: T6558: gpgtar: Does not stop spawned gpg process when exiting.

Should be fixed.

When the output parameter is given it might even clean up a temporary file on error, but it might also not so we should make sure on a higher level that we check for that and remove it when gpgtar crashes or something like that.

Removed parent task because this issue doesn't really block T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

ready for testing

Done. Can be tested and closed with T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

I think that for VSD the Help action is disabled via the configuration because you have alternative documentation to the Kleopatra Handbook. @aheinecke?

I vote for (1). All other GnuPG projects put config.h[.in] in the top directory.

Move back to the backlog and trigger re-evalutation of priority (which was high).

Which only works if gpgtar actually knows the input file name (which it will once T6530: GPGME / QGpgME Extend Archivejobs to accept input / output from a filename is done and used).

Yeah, probably a Windows/MinGW 32-bit problem. GpgME::Data does

off_t size = seek(0, SEEK_END);
seek(0, SEEK_SET);
std::string sizestr = std::to_string(size);
// Ignore errors as this is optional
gpgme_data_set_flag(d->data, "size-hint", sizestr.c_str());

Well the progress is by file and type of import (OpenPGP, S/MIME, groups). Is importing a 38 MB keyring really a use case that is worth changing perfectly working behavior? People, rightfully, hate knight rider progress because it gives no indication at all when it's finished.

I wasn't aware of this behavior (on Windows), i.e. the behavior change wasn't intended.

There is already an additional handleExternalCMSImports which does

// For external CMS Imports we have to manually do a keylist
// with validation to get the intermediate and root ca imported
// automatically if trusted-certs and extra-certs are used.

For me this does work also when decrypting:

Of course, those are different controllers. :-)

The processes should now be killed properly.

Maybe there just shouldn't be an "encrypt to others" checkbox. I mean, either you add keys of others or you don't. What's the point of the checkbox? Okay. I guess now you could encrypt to others but not to yourself. But that would still be possible. What wouldn't be possible is to add keys of others and then decide "Nah. I'll just encrypt to myself/with password."

Gpg4win doesn't include libexpat anymore (since it doesn't include gpa and pinentry-gtk anymore).

Gpg4win doesn't include libexpat anymore (since it doesn't include gpa and pinentry-gtk anymore).

I had a brief look at this. I don't think there's a way currently to convey "CRL Error" via a keylist result to gpgme. The --with-colons format would probably need to be extended.

I just thought, that we should still show "not certified" if the primary user ID is not certified because Kleopatra always displays the primary user ID (except in the Certificate Details).

https://invent.kde.org/pim/messagelib/-/commit/f8373bc09b228cc88577ec88b285c58a06122575

Notes for testing:

• First certificates and groups are sorted by their "display name" (i.e. the part of the displayed text before the parenthesis with the other properties).
• Groups are sorted before certificates if both have the same "display name".
• Groups with identical name are sorted by their internal ID. (Probably doesn't make much sense to test this.)
• Certificates with identical "display name" are sorted by validity, then by creation of newest valid subkey, and finally by fingerprint.

When testing please note that the last changes (i.e. "Ignore expired subkeys when looking for newest subkey" and ""Sort by fingerprint as last resort for deterministic sort order") have not been merged to the gpg4win/3.1.27 branch.

I have set T6513: Kleopatra: Require GpgME 1.21 as blocker for this issue because, in my opinion, showing the above mentioned "Operation fully cancelled" error message is from a user perspective worse than showing multiple password prompts.

Fixed.