I stand partially corrected. Apparently, pinentry-efl also sets close_button. For Gpg4win that's irrelevant because we ship pinentry-qt (and pinentry-w32) which doesn't have this IMHO contra-intuitive behavior.

Upstream MR for reading system config files before user config files: https://invent.kde.org/frameworks/kconfig/-/merge_requests/436

pinentry-tty and pinentry-curses support GPG_ERR_FULLY_CANCELED by Ctrl-C. But other pinentry implementations have no support (only GPG_ERR_CANCELED).

I'd also like to point out that changing the error code from GPG_ERR_CANCELED to GPG_ERR_FULLY_CANCELED could cause regressions in applications.

Merge request for KMessageBox: https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/339

How do you want to decide whether to show two "Cancel" buttons? How would you call those two "Cancel" buttons? For decryption I can imagine that for example "Try Next Key" and "Cancel Decryption" (or even just "Cancel") would make clear what happens.

Q3 is T7650: Kleopatra: Limit width of KMessageBoxes

Any further improvements will have to go in a new ticket when we have a plan. I'll close this one.

ok, lets go with the message box.

Q1 stays like it is, for Q3 @tfry made a merge request to wrap after 120 characters. Please add a link to this.

Follow up for Q1 is T8166: Kleopatra: Add "Save Secret Team Key" button to success message after creation of "Team Key"

Relevant part from T6793: Cleanup temporary files / dirs with decrypted content:

If this definition is OK

@bernhard Thank you for the link.

In T8076#215372, @werner wrote:

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

What is an "incomplete team key" - a standard offline secret key (i.e. one with only secret subkeys)?

It would be used for key creation just like the legacy options PGPKeyType and RSAKeySizes were used (and still can be used but only for RSA with different key sizes).

If you specify a primary key the primary key shall be deleted. If there is only an offline or token based primary it can't be deleted. This is what the user requested. We can't change this because otherwise subkeys might be unintentionally deleted.

I guess the behavior changed with gpg 2.4, i.e. "With gpg 2.4 (or later), ..."

Shall that be used for key creation or shall a warning be displayed when a non-allowed key is used (receive or send)?

why gpg 2.4? Don't you mean 2.6? I'll add the proper 2.6 tag for avoiding confusion

FYI: We had a VSD support case today where the user complained that they thought the Admin PIN would work because of the tooltip text but it was not accepted. They needed to give the PUK, which is consistent with the state given in this ticket.

Hi @gniibe,
thanks for making progress on the issue.

I was wrong. gpg (scdaemon) needed to be fixed with more changes for the interaction with pinentry.

I pushed my patch for gpg, since it does not break anything, just allow empty passphrase input (to skip).
I also pushed my patch for gpgme. I believe that it's correct.

gpg 2.2 does: when it sees PKT_PUBKEY_ENC it asks a user to try decrypting the session key. when it sees PKT_SYMKEY_ENC it asks a user to try decrypting the encrypted session key by passphrase. When one of tries successes, it use the result (the session key) to decrypt PKT_ENCRYPTED_* packet. When there are multiple PKT_PUBKEY_ENC and PKT_SYMKEY_ENC, gpg 2.2 handles sequentially.

And *.pub is used for Microsoft Publisher documents

From the support angle, the worst of these issues is that the default will not be restored for VS-NfD. But then: nobody has inquired about that yet…

What is fixed, what needs still needs to be done and should go into another ticket?

There is already a hint in the "1st steps" web page and already a ticket to add a hint on incompatible Add-Ons in the documentation.

We need tests to reproduce this.

We need a test $GNUPGHOME with different secret keys to test this scenario:

• expired key
• 2 usable keys (not expired)

I don't understand how to reproduce this. When a key is deleted then nothing referencing this key should remain in the key ring. I don't see why it should matter whether the deleted key was a card key or not.

Marcus suggestion: offer the HTML mail content as attachment.

I've added *.pub and *.sec (since we have test keys with those suffixes even in gpgme).