On 08/25/2011 10:04 AM, Robert J. Hansen wrote: > 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.
Yes, it's true, and yes, i'm an outlier. At the moment. > 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." Except that, quite clearly, most users have no idea it is their problem and the problem remains unsolved. Why not try to solve the problem, or at least enable users to choose one of a pre-defined set of reasonable refresh heuristics for gpg to implement on their behalf? Please read https://bugs.g10code.com/gnupg/issue1235 for decent arguments about why this is the right thing to do. > 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. I agree that handling it within gpg is the best option -- gpg is in the best position to do key management. However, tools like parcimonie show that it's possible for a third-party to handle certificate refresh. It's just a lot of overhead and tracking outside of gpg itself. --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
