On 8/25/11 9:36 AM, Daniel Kahn Gillmor wrote: > Yes, i do this myself, but with a large keyring, a full --refresh-keys > takes ages and thrashes my machine.
Define 'large keyring', please: I mean no offense, but that's a pretty vague word. proverbs:~ rjh$ gpg --list-keys|grep "^pub"|wc -l 288 proverbs:~ rjh$ time gpg --refresh-keys [output snipped] real 2m0.274s user 0m40.273s sys 0m0.972s Now, maybe you have thousands of keys on your keyring and it takes a ridiculous amount of time, but I suspect you're a bit of an outlier. At almost 300 keys I suspect I'm still well beyond the average user's use-case. (Note these are suspicions: I haven't polled users.) The problem for any system of automated certificate refreshment is making it general enough to accommodate power users with thousands of certificates, and yet simple enough for the 95% of users who have X-or-fewer certificates (where I suspect X < 50). That's a very difficult problem and I'm happy for GnuPG to kick this one to the users and say "refreshing the keyrings is your problem." Alternately, it might be a good thing to add certificate refreshment into GPGME. That way GnuPG, instead of forcing a One True Way on the end users, could make it possible for other people to write their own certificate refreshment utilities, with whatever policies and actions they want. Absent hooks in GPGME, I don't think there's much opportunity for third parties to write certificate refreshers. Doing so would require support from GnuPG (adding a "last refreshed field" to each certificate on the keyring) and some way to parse the GnuPG keyring independently of GnuPG/GPGME, which is ... problematic.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users