It looks to me like it's marginally more common to *not* use the lib prefix for pkgconfig files:

@dvratil cool, I'm looking forward to it!

I think the problem is that SignEncryptTask is destroyed before the canceled job reports the result. Therefore the clean-up code never runs. The added logging should confirm this.

Debugview shows:

[8412] org.kde.pim.kleopatra: Collection Progress:  48  total:  1000
[8412] org.kde.pim.kleopatra: 
[8412] org.kde.pim.kleopatra: 0x9cfca58 slotWizardCanceled
[8412] org.kde.pim.kleopatra: Kleo::Crypto::SignEncryptFilesController(0x64c97a8) cancel
[8412] org.kde.pim.kleopatra: Kleo::Crypto::SignEncryptTask(0xeee73c0) cancel
[8412] org.kde.pim.kleopatra: Error:  "Abbruch durch Benutzer"
[8412] org.kde.pim.kleopatra:

Kleopatra should (try to) delete the file: rKLEOPATRA59652a394662: Remove the output file if job was canceled or an error occurred. The attempt to delete the file is logged, so you should see the logs in the debug output. If nothing is logged, then something weird is happening. Or the QFile::exists() check does not work for some reason.

So far only the dev branch of Craft supports this. Also there are still some platforms where it doesn't work.

Oh, then its back to the backlog

It is present in gpg4win 4.2.0. I do not have a later testversion.

In T6085#162923, @ikloecker wrote:

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

Autogeneration isn't viable if an organization has stupid password constraints that the autogenerated passwords do not satisfy. In particular, the autogenerated passwords do not contain any non-alphanumeric characters, but many password policies require such a character.

Eva this was still in the backlog. But I think it is fixed. Can you check please?

Shouldn't this be ok to merge now that our GnuPG builds on CI are fine?

I think that might have been some idea we had before we added --require-compliance and proper display of non compliant signatures in KMail and Kleopatra and wanted to ensure that non compliant signatures are not "Green".
But since this is not a regression we might even consider not changing this in 2.2 anymore but instead do some relaxation how we treat non compliant signatures both for creation and verification in 2.4 I see T6644 as related.

Done. This can be tested with the run-import test runner (which I did).

I added my script to find icons, used in our packaging file. It is extremely stupid as it just greps the source for each icon and takes quite a while but it works for me and I can simply run it in the background. This was just a hacky "worksforme" solution, and we probably want to do it differently. Using a single expression for all the icons would already be a large improvement but I just did not care about that. It also does not really generate the -inst files and requires manual work. But since we probably will do it differently in the future anyway I just commited what I have right now. It does not take care of icon removals and so on. So we might need something with a bit more development put into it.

On a related note in T6645 it was raised that it is currently impossible for the user to see if an exported group only contains local signatures which might decrease the value of the export and not be the intention of the person doing the export. Maybe we should combine a check for that with this feature so that you are asked when exporting a group if you really want to confirm all these identities.

Thinking about this, I don't think offering the information exportable or not will help users much. The concept of "exportable or local signatures" should be a technical details that we should not require our users to understand. The intention of defaulting to local signatures and hiding the export under "Advanced" was to give users a way to basically use "Trust on first use" to certify a key for their personal use and honestly without checking the fingerprint. Even though they "should" not do that. If this makes sense for GnuPG VSD is arguable since we have now better spelled it out what "certification trust (ownertrust)" means. So maybe exportable signatures should become the default for GnuPG VS-D? With the classical SKS style keyservers in Gpg4win I tend to keep local signatures the default.

Well better to wishlist this. As a user might still import a bulk of S/MIME certificates.

Yes this is no longer required since we use a script now.

The changes have been merged and will be part of KDE Gear 23.12.

I thought about adding support for deleting multiple attachments via the Message Structure view, but as Ingo said, it's marked as an "Expert" tool and it is not enabled by default so most users are not even aware of it, and it would actually be difficult to do it with a proper UX so I decided against it, unless it's explicitly requested by someone again.

Closing. For now, all that's needed has been added to GpgME. Additional changes in Kleopatra are tracked in T5903: Kleopatra: Add refresh button in certificatedetails . If further changes in GpgME are needed, then a new task will be opened.

We have no dedicated error to tell that the verification failed due to an non-compliant algorithm. Thus we return invalid public key algorithms as best approximation. You could use --override-compliance-check, though. We discussed things thing once at the Gutenbergweg.

In T5903#157763, @ikloecker wrote:

Please add a separate task for an automatic refresh.

Mmh, ok this does not seem like a regression, at least if I go back to one of my oldest appimages with 3.1.21 I still get ERRSIG.

Since I am not sure if this was really a problem in the first place I resolve it directly.

Yes, I remembered that too when I encountered it in a different place.