bug: gpg fails to allow update of OpenPGP certification after expiration
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue May 17 19:36:39 CEST 2011
My certification on a key+userID recently expired. I went to re-certify
it, and gpg failed to allow the re-certification, with the following
> "foo (redacted)" was already signed by key D21739E9
> Your current signature on "foo (redacted)"
> has expired.
> Do you want to issue a new signature to replace the expired one? (y/N) y
> Nothing to sign with key D21739E9
> Key not changed so no update needed.
Note that no additional certification was added.
There were two certifications by D21739E9 on the key in question already:
A) one certification from 2008 with no expiration date
B) a certification from 2010 with an expiration date in early 2011
Given the OpenPGP standard, B should supercede A.
It appears that what happens is that when the user says "y" to the
prompt, gpg effectively deletes signature B from the temporary view of
local keyring, leaving it with A. It then decides that A is sufficient,
and declines to do anything. Since no changes have been made, it
doesn't even save the updated local keyring.
I have two workarounds:
0) manually delete A from my local keyring first, with something like:
gpg --edit-key $KEYID
1) use gpg's --expert flag to force my way through.
I note that if i use either of these methods to create a new
certification, then my local keyring ends up without (B) at all (though
it is of course re-fetchable from the public keyservers). I consider
this is surprising behavior, though given that i'm in workaround
territory, i suppose any surprises should be expected.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1030 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users