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 [email protected] Oregano - The ancient art of pizza folding. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Micah Anderson Sent: Friday, June 04, 2010 12:35 To: [email protected] 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
pgpvNChgWywh2.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
