This is how this looks in the qml viewer, in the qtwidget viewer there is no support for this yet. Do you want something similar for the qtwidget view?

Fix is here: https://invent.kde.org/pim/mimetreeparser/-/merge_requests/5

Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.

I mostly used ed25519 keys and thus I do the avove command pretty often without problems. Can you please add

-v --debug lookup

to the command line show us the log (send privately to my standard mail address (wk@gnu...) if you feel that data is too sensitive for the public).

I would like it if we could show the result list widgets above or below the message contents in the message viewer. Maybe shortened to a single line and then you can expand it to see the details.

Thank you! Closed by https://github.com/gpg/npth/commit/bd356d82394447b51b2505756094d6475e160a4b

The sign/encrypt archive jobs now also take care of removing the output file if the operation was canceled or failed.

A bit related: T6656 when I look at the web interface of an account that uses GpgOL I see these files everywhere. And they should then also be handled by kleopatra but for that they need some file extension that I can link to kleopatra.

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.