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 interaction:
> "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
delsig
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.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
