Re: [Debconf-discuss] Last call for keys for keysigning in New York City, USA during DebConf10
On Tuesday 20 July 2010 07:37:11 Michael Fladerer wrote:
> Hi Lars,
>
> On Mon Jul 19, 2010 at 23:47:42 -0700, Lars Wirzenius wrote:
> > (I also hope that I've now verified that my new key is fine, except for
> > lacking an expiration date. But I hope I can fix that without generating
> > a new key.)
>
> yes, that's pretty simple:
>
> 1. execute the following command in a terminal:
>
> gpg --edit-key <your_key-ID>
>
> 2. select the subkey for which you want to set an expiration date (e.g. the
> first one)
>
> key 1
>
> or none to set the expiration date of your primary key.
>
> 3. now you can set the expiration date for the selected key (no
> selections = edit primary key) with:
>
> expire
>
> 4. set the expiration date to a reasonable date (recommended max is 5y):
>
> 5y
>
> 5. save the key and exit:
>
> save
>
> That's it, no more, no less. ;P
I believe if you want the expiration date on the key to be published it's also
necessary to re-send the key to the keyserver. Everybody else gets this
update when 'gpg --refresh-keys' is run, but if you have a primary key that is
kept purely offline, that isn't possible.
Besides adding an expiration date, during testing I was able to change the
expiration date of a newly formed key that had previously been given an one to
not having one at all. I have my doubts concerning whether gpg clients would
accept an expiration date extension for a key, though.
And concerning automated key refreshing, the suggestion from the OpenPGP Best
Practices of using the following cronjob has a snag:
0 1 * * * /usr/bin/gpg --refresh-keys > /dev/null 2>&1
... which is that your machine has to be on at 1am for this to run. I've been
trying to find a script that will locally email errors and changes to keys via
an anacron job.
-- Chris
Reply to: