RFE: --update-before-use

[David Shaw]

On Jun 14, 2012, at 1:48 PM, Robert J. Hansen wrote:

> Currently, users have a public keyring containing certificates acquired from many different sources.  These certificates are often out of date, sometimes in minor ways, sometimes in large ones.  Since many users now have always-on and fairly reliable internet connectivity, perhaps it makes sense to add a new option: "update-before-use" (and its  "no-update-before-use").
> 
> This option would only be effective if a --keyserver option is also in use.
> 
> When the update-before-use option is in effect, GnuPG will, before any encryption or verification, attempt to download the latest version of that certificate from the keyserver.  If one cannot be downloaded, GnuPG will display a warning message and continue to encrypt and/or verify using the certificate on the local keyring.
> 
> We already have something similar to this in --auto-key-retrieve, and the same warnings about that option probably also apply here.  The principal difference would seem to be that auto-key-retrieve only fetches certificates that are not on the local keyring, while update-before-use would always fetch certificates.

This comes up every now and then.  A recent go-round on the subject is at http://www.gossamer-threads.com/lists/gnupg/users/50850  See also bug https://bugs.g10code.com/gnupg/issue1235

I actually started down this road once (when I was doing auto-key-locate, as it happens - they share a lot of similar backend concepts).  I didn't pursue it for a few reasons:

1) If the keyserver (of whatever type) isn't reachable at that moment, simple GPG operations can take a long time (multiple minutes) to allow for the fetch to fail and fall back to the current copy of the key.
2) Concern that enough people turning this feature on would add significant load to the keyserver network, which is run as a public service.  I was hoping to get some keyserver operators to weigh in on the subject.
3) It leaks information more than auto-key-retrieve or auto-key-locate does.  AKR only fires when verifying signatures, and only fires once (if you have the key, it isn't re-fetched).  AKL only fires when trying to communicate with someone who you do not have a key for, and it also only fires once.  An auto-key-refresh would refresh on every use, which essentially tells the keyserver operator every time you communicate with someone, and who.

#1 can be handled by configuration - a "how long am I willing to wait for automatic updates" variable that can be set lower than the current keyserver-option "timeout".
#2 can be handled by asking ;)
#3 is a problem… obviously documenting the leakage is a start, and having the feature off by default is important.

If someone wants to pick this up again, it would be nice if this could be done on particular keys, rather than globally.  That helps with all three problems, to varying degrees.  It would also be nice if the basic concept could be used to refresh at different intervals (i.e. "refresh on every use" vs "refresh on every use but not more than once a week", etc).

David