Pushed the fix for SIGINT handling of pinentry-tty and pinentry-curses by: rPa6f63fe37dbf: tty,curses: Upon SIGINT, let pinentry exit gracefully.
This fix should improve the situation.

Thank you for the report.
I found a bug in pinentry-curses and pinentry-tty for handling SIGINT. I am going to fix this.

Pushed the change to:

• libgpg-error
• libassuan master
• libgcrypt master
• ntbtls
• npth
• libksba
• gpgme
• scute

Regarding PIN, they should be set first.

1. A temporary Admin / User PIN is be generated and stored in gpg-agent.
2. Then the keys are created as mentioned above.
3. The user is asked to set a new PIN and Admin PIN for the card.
4. Optionally set a RESET CODE

For generate new keys we see four use cases

1. Create card and backup card. -> Creates at least two cards with the same keys. Keys might be stored in ram: TODO: Add subtask
2. Full backup of all keys - Allows for copied cards at a later time.
3. Only backup encryption Key. - There is a backup of the encryption key on the computer.
4. No backup - Keys will be generated on the card.

Yes, gpgtar emits a SUCCESS status. gpgme should probably check for this.

[For bug reports please don't refer to some other site - at least a brief but useful description should always be included]

Yes i think we need something like that, maybe shorter like this message is (VS-NfD compliant) encrypted and this message was (VS-NfD compliant) signed by "user.name@foo.bar" as a single line each, with "Details" available. And then in details show some more information like who the message was also encrypted to, ideally with the user ids when we have the keys in the keyring already and not the fingerprints of the keys. Or maybe just a status indication icon like we have in GpgOL which provides more information when you click it or as a tooltip. At the very least we need to make sure that this cannot be faked by e.g. HTML Mails :) so it needs to be removed a bit from the actual mail body.

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).