Feedback from a customer was that revoking a certification is confusing because you can select keys and user ids which were not used for certification.
It would be better to show something like "there are no certifications to revoke" or automatically select the key for revocation based on the certification.
| rLIBKLEO Libkleo | |||
| rLIBKLEO2b4b07ca549e Add more convenience helpers for applying algorithms to a range | |||
| rLIBKLEO807d2eacd385 Add helper to check if all elements in a range satify a predicate | |||
| rKLEOPATRA Kleopatra | |||
| rKLEOPATRA61d79f5a440b Remove obsolete files | |||
| rKLEOPATRA6b6d314c367d Simplify the revocation of certifications | |||
| rKLEOPATRA19286cc1d152 Check if there are any certifications the user can revoke | |||
| rKLEOPATRAddaf31d30632 Log a warning if the signatures are not available | |||
| rKLEOPATRA82d5bbb89358 Add helper to check that a user ID belongs to a key | |||
| rKLEOPATRAe3bdb94add48 Modernize the check that the user IDs belong to the key | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6626 Kleopatra: Improve certification and revocation | ||
| Resolved | ebo | T6115 Kleopatra: On "revoke certification" do not offer keys which did not certify that certificate |
If the user cannot revoke any of the certifications of the selected key or user IDs, then we now inform the user about this instead of showing the dilaog.
Further plans for improving the workflow:
Note to self: T6100: Kleopatra: Make revocation of certifications accessible may be obsolete when the improvements are completed because then the dialog will most likely be gone.
Depending on what the user selected (key, one or more user IDs, a single certification) all certifications that the user can revoke are determined and, after confirmation, are revoked one after the other.
This is how the confirmation looks like for a single certification and for multiple certifications:
works as described. But If you already have revoked one or all certifications of that key, you still get the revocation dialog.
For the user it looks like they are revoked again. But in debug output you see:
4 - 2023-07-26 10:39:08 gpg[1776]: sig by 388C015DC9690FFC already revoked at 2023-07-26
Can't we check if the certifications are already revoked before the (pseudo) revocation goes forth?
And why is the action revocation not greyed out as we do with other actions, if they are not possible?
I could be wrong, but I think initially we load OpenPGP certificates without signatures, so that we don't know whether the user has certified or revoked a key. Therefore, in the certificate list we cannot decide whether offering the "Revoke" action makes sense. We load the signatures, when the details or the certification dialog is opened.
We might be able to check if revocation is possible when the dialog is opened. But I'm not sure whether Kleopatra could be fooled by forged signatures into believing that the user already revoked a key. Therefore, Kleopatra delegates this responsibility to gpg and let's gpg decide whether revocation makes sense. We do already duplicate too much logic better left to gpg in Kleopatra.
The user may also have certified a certificate with multiple of their own certificates.
Maybe with keyboxd we do now have the possibility to query the backend for the needed information in a performant way, i.e. without invoking many processes which is prohibitively expensive especially on Windows.
How about giving a notification in Kleopatra relaying gpgs message(s) "signature already revoked"? Instead of ~"3 certifications were successfully revoked, do you want to publish them?"
I had a quick look. gpg --quick-revoke-sig [...] doesn't emit a status message that would tell Kleopatra that the signatures had already been revoked. It just emits a status message telling Kleopatra which key was considered. (Run gpg with --status-fd 2 to see which status messages gpg emits.)
The Task from the description is solved in gpg4win 4.2.0. See follow up tickets for anything else.