We include the ISSUER_FPR subpacket since version 2.1.16 released 2016. Thus there is virtually always a fingerprint for all signatures available.

Upstream fix: https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/219

With Ingo's suggestions it could look like this.

Show Fingerprint instead of Key-ID of certifications (change the title correspondingly)

I don't like blowing up a task with loads of unrelated additional wishes after the original request was fulfilled. At most the first request can be considered part of the original request. The other requests should be handled in multiple separate tasks.

Optimization requests:

The check happens whenever the user selects or deselects one (or more) certificates. All actions that require conditions not met by the selected certificates are disabled. Some conditions are too complex/slow/special to check, e.g. the check if an empty smart card is inserted should happen when the user triggered the action.

The action shouldn't be enabled for keys not meeting the requirements.

This sounds good.
Will this checks be done on opening the context menu for a private key?

Regarding the requirements for a key: The action shouldn't be enabled for keys not meeting the requirements. (Just like most other actions are only enabled for a suitable selection of keys.) The info which keys are suitable belongs into the manual and not as wall of text into Kleopatra.

You forget that multiple OpenPGP smart cards might be plugged in. Although it's probably not likely that multiple empty cards are plugged in. (For comparison: The subkey action to move a key to a card allows the user to choose a suitable slot. I think it also offers non-empty slots, but I agree that for the "simple copy" it's better to offer only empty cards to prevent a disaster.)

To clarify: this works for "Restart background processes", as was the aim of this ticket

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

gpgme has a disabled flag (only set on the primary key) and taken from the --wwth-colon listing where it is the 'D' in the usage.

forgot to keep it open for test with gpg 2.4 branch versions...

restarting gpg-agent works in release version 3.2.2

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.

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

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

may be related to https://dev.gnupg.org/T5957#163468

Alexander suggested that we could avoid another window by putting check boxes in the revocation window for automatically uploading to the configured keyserver and creating a public key export with the revocation. That could then be configurable via the registry on windows, so that companies could adapt that according to their SOP.

That said I think we should then strive to use only one "next" window. Currently we already have on of those with the question if the revocation should be uploaded to a keyserver. Could we combine the 2 things in one window in a simple to understand way?

Revocations are an exceptional task and rarely needed. In this case ("help, help , my key is compromised, what shall I do now?") an extra dialog to help the user is imho appropriate. This different for the key generation process, becuase this needs to be done by every user at least once and thus should be UI-wise as simple as possible.

"Today" was already removed together with other changes for T6621: Kleopatra: Remove "in n days/weeks/months/years" input from Change Validity Period dialog.

I just want to point out that we have explicitly decided to remove confronting the user with five different "What next" options in the certificate creation workflow. One reason is that the choice overwhelms the users because some think they need to do everything. Another reason is that many options were completely wrong for some of our customers. Such workflows are much better documented in company-specific SOPs (standard operation procedures).

Fixed. This improves the first impression when users use the first smart card with Kleopatra.

Fixed. Two examples:

Fixed.

Oops. I closed the task accidentally.

We decided the latter is to small an issue, we'll close this ticket without opening another for the reverse case.
Tested only in VS-Desktop-3.1.92.39-Beta yet

I don't see a problem here. Of course Kleopatra could run a gpgconf -K all when it really exits but I doubt that we need to do that in this special elevated case

Fixed (for GnuPG 2.4). I hope 2.2 prints the same status messages.

The General Error happens also when the PIN is blocked and no Pinentry opens.
As in this case, where the indicated "Generate New Keys" button was used on a blocked card.