Note for devs: In most places we can probably use Key::isBad() which excludes all kinds of keys that are not valid for use (revoked, expired, disabled, ...).

When working on filters the "disabled" flag should be considered as well, see T7089.

What is the current status of this issue?

+1 for Tobias proposal

I'd propose that we could:

• Always export the certificate and tell the user in the success dialog
• Have an extra button in the success dialog allowing the user to upload the certificate.

No, if you then find out that you cant reach anyone in the protocol you should be able to get back.

Yes I have pcsc-shared in my scdaemon.conf.
I've just tried removing both pcsc-shared and disable-application piv and PIN caching worked as expected.

Are you using PC/SC shared mode? If so, it may be the case of T7041.

I just wanted to report that I'm having this issue on Fedora 39, with GnuPG version 2.4.4.
I'm being asked for the PIN for every operation (Sign, Decrypt, Authenticate) I'm having this issue on 2 different laptops using YubiKey 5C NFC and YubiKey 5C Nano (Firmware version: 5.4.3).
I tried disabling PIV (disable-application piv) and then PIN caching started working again, so I just wanted to report this as it's marked as resolved.

Here comes a new test key along with its 3 secret parts (one for the primary and two for the composite Kyber subkey).

Backported to VSD 3.2

I think it would be the most logical solution to always clear the recipients after a switch of protocol. No restoration for other recipients necessary from my point of view.

So you want the other recipients to be cleared? What shall happen if the user switches the protocol again? Shall the previously selected other recipients be restored?

I like the suggestion to add a checkbox for the upload. That's also in line with certification which is very similar to revocation.

Well I expect to not get an error if I click on something which might be an unusual use case but is a valid operation.
I do not want Kleopatra to select an appropriate certificate, I expect it to not suggest any certificate for the recipients.

For your own certificates Kleopatra knows what to look for when you switch the protocol: Some suitable certificate with the correct protocol belonging to the user. In fact, Kleopatra remembers the last used own sign and encrypt certificates for both protocols.

@mwalle Thank you for your testing.
Applied to master.
After testing, I'll also apply to 2.4 branch.