Page MenuHome GnuPG

GnuPG: Add quick-revsig
Closed, ResolvedPublic


For a workflow with a central OpenPGP CA it is important that the CA can revoke its certifications. Kleopatra currently offers no GUI for that. Mostly because it is difficult to do as it would need card-edit and an editinteractor.

Since we nowadays use --quick- commands for that and add a proper GPGME op for such things please add --quick-revsig to GnuPG Stable.

Event Timeline

werner raised the priority of this task from Normal to High.Oct 5 2020, 4:11 PM

Should not be too complicated.

I missed this one because I only searched for "revoke" ;-)

I am already working on it. The gpg command will be

gpg --quick-revoke-sig USER-ID  USER-ID-OF-SIGNING-KEY

in general the use of fingerprints for the USER-IDs is suggested. There will be an option third parameter to limit the revocation only to a certain user-id. But I have not yet implemented that. As it is now all non-selfsigs by the given signing key are revoked - no error if they are already revoked.

Minor remark: I would change this (in the documentation) to

gpg --quick-revoke-sig fpr fpr-of-signing-key [names]

as for --quick-sign-key, --quick-add-key, and --quick-set-expire, even if USER IDs can be used instead of fingerprints. We shouldn't advertise the usage of USER IDs, if we prefer the users to use the fingerprints. I suggest to also change user-id to fpr in the documentation of --quick-add-uid and --quick-revoke-uid. Using USER IDs for identifying keys is ambiguous and errorprone (e.g. if non-ASCII characters get involved, which, incidentally, is the reason why I started to work on KMail).

I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.

The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.

werner changed the task status from Open to Testing.Oct 28 2020, 6:26 PM

I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.


@item --quick-revoke-sig  @var{fpr} @var{signing-fpr} [@var{names}]


wrong_args ("--quick-revoke-sig USER-ID SIG-USER-ID [userids]");

For --quick-[l]sign-key the usage hint is --quick-[l]sign-key fingerprint [userids].

On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.

I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."

The following patch fixes this:

diff --git a/g10/keyedit.c b/g10/keyedit.c
index 9f4aad24a..596662dda 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -2880,7 +2880,7 @@ keyedit_quick_revsig (ctrl_t ctrl, const char *username, const char *sigtorev,
           sigcount = 0;
           for (n=node; n && n->pkt->pkttype == PKT_SIGNATURE; node=n, n=n->next)
-              sig = node->pkt->pkt.signature;
+              sig = n->pkt->pkt.signature;
               if (!keyid_cmp (primarykid, sig->keyid))
                 continue;  /* Ignore self-signatures.  */

The problem is/was that node points to the first node for the first two iterations.

By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584

I have added support for this to gpgme (and gpgme++/qgpgme). See T5094.

werner changed the task status from Testing to Open.Oct 29 2020, 4:36 PM

I recall that I had the same bug during development. Must have slipped in again - Good catch.

Yes, --quick-sign-key refuses this and I am already thinking on how to fix that. In --edit-key mode you must use --expert to allow re-certification. The way --sign-key is implemented is pretty different from my new code and thus I need to think on whether to rework the code or add some backward-compatibility hack. The new sorting approach is IMO better than the old nested state machines or however you will describe it.

werner claimed this task.