auto refresh-keys

[Sonja Michelle L. Thomas]

This can also be done using Task Scheduler for folks using a Windows PC.

In my particular instance using 64bit Windows 7 my gpg.exe was installed with GPG4Win and can be found in C:\Program Files (x86)\GNU\GnuPG\pub\

I also put that path in my list system path variables as well to make command line gpg actions easier.

The task I set up runs weekly with the following command "C:\Program Files (x86)\GNU\GnuPG\pub\gpg.exe --refresh-keys"

Note the use of quotes.

When this task runs a command window opens and you can see the output. You can add > null to the command to kill the window output if you prefer.

*************************************************
Sonja Michelle Lina Thomas
sonja at sdf.lonestar.org

Oregano - The ancient art of pizza folding. 


-----Original Message-----
From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Micah Anderson
Sent: Friday, June 04, 2010 12:35
To: gnupg-users at gnupg.org
Subject: auto refresh-keys


I filed this today at https://bugs.g10code.com/gnupg/issue1235 but I
wanted to send it to the list to get wider discussion about the idea. 

If you do not regularly refresh your public keys from keyservers, you do not get
timely expiration updates or revocations, both of which are very important to
have available to your local keyring as soon as possible. If you do not refresh
your keys from the keyserver, and I have revoked my key because it has been
compromised, then you will continue to use my key without knowing that I've
revoked it. That can lead to bad situations. For proper functioning of a
distributed web of trust, this needs to happen, and until it does the breakages
in those links are too fragile and frequent.

I did an experiment recently where I set my key expiration to be short and then
one week before it was to expire, I extended the expiration and sent that to the
keyservers. What I found was that one week later, virtually everyone that I
communicate with using that key thought that my key had expired, because none of
them have a process to regularly refresh their keys in their keyring. I had to
contact them individually and explain the situation and then advise them to
setup a personal cronjob to do a regular refresh, typically I suggest something
like:

0 1 * * * /usr/bin/gpg --refresh-keys > /dev/null 2>&1

This is annoying for every gnupg user to have to setup on their own. It is also
problematic for people who do not understand cron. In my experience, asking
every user to do this is problematic, as very few actually end up doing it. I've
been begging people to setup cronjobs like this for the last 2 years as I've
been going through various key transitions, and very few of them actually do it,
even those that I have urged 3-4 times to do so.

It also cannot be done in a reasonable way automatically by distro packagers due
to the fact that package maintainers cannot know how the local admin needs to
have things setup (such as a system-wide cronjob, or a adduser hook). For
example, home directories are not necessarily local to a machine, and having a
system-wide cronjob to scan all user's home directories and then modify them is
not a good idea; or they don't use adduser and instead use automated tools for
account creation. 

It seems like the best solution would be to build into gnupg the functionality
that is similar to the automatic trust database operation: have gpg auto-refresh
From the configured keyserver periodically. There are some considerations that
should be made here, such as how frequent should this refresh operation happen?
Should it happen on every use, before the key is used? Should it happen just on
the key(s) that the current operation is going to act on? What about network
problems, such as no network at all, keyserver down, or slow? There should
probably be a low timeout to not cause user annoyance, but also some sort of
indication/warning that when a keyserver update could not be performed that the
key is potentially out of date. Users should have the capability to configure in
their gpg.conf a 'no-auto-refresh-keys' variable if they do not want this
functionality. Perhaps even some sanity checking on the data that is coming in
would be good to guard against gigabytes of data coming down.

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: </pipermail/attachments/20100604/7f7c20f7/attachment.pgp>