gpg 1.0.5: unusable secret key

[David Champion]

On 2001.06.14, in <87hexjchoj.fsf@alberti.gnupg.de>,
	"Werner Koch" <wk@gnupg.org> wrote:
> 
>  dc> don't sign that message with my old key.  Can I force gpg to sign a
>  dc> message using an expired key, or do I need to use an older version?
> 
> An expired key is an expired key is an expired ...
>
> You can use an expired key for decrupting a message but you won't be
> able to sign something (if there are no more bugs).  So the workaround

This is strange.  I know it's expired, and I don't want to continue
using it -- but it's all I have to validate new key information
electronically.  Are you saying that I should simply step back to the
beginning, with no credentials, because gpg previously allowed me to
think that my key was still valid, and because the situation involves
some slight ambiguity about whether the key still belongs to me?

I agree that gpg should not use such a key per default, but it seems
that a force option is very useful here.  Would you consider
implementing it, or no?


> is to set the wall clock of your box back before the expiration time
> (bad idea) or  change it in the source:  It should be easy to find in
> g10/getkey.c, function finsih_lookup().  At two places there are tests
> on the expire time which will to a "continue" for expired keys - just
> comment the 2 continues out and print a warning.

If I have to recompile, I might as well use an old (buggy?) version for
this step.  I just think it's a bit silly to need two separate builds
of the program in order to make a key transition under these
circumstances.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago