diff options
author | Daniel Kahn Gillmor <[email protected]> | 2017-08-11 06:26:52 +0000 |
---|---|---|
committer | Daniel Kahn Gillmor <[email protected]> | 2017-08-11 06:26:52 +0000 |
commit | e6f84116abca2ed49bf14b2e28c3c811a3717227 (patch) | |
tree | df568252f8decc0b54772c93c3c369566d9cee9e /tests/gpgscm/scheme.c | |
parent | po: Update Russian translation (diff) | |
download | gnupg-e6f84116abca2ed49bf14b2e28c3c811a3717227.tar.gz gnupg-e6f84116abca2ed49bf14b2e28c3c811a3717227.zip |
gpg: default to --no-auto-key-retrieve.
* g10/gpg.c (main): remove KEYSERVER_AUTO_KEY_RETRIEVE from the
default keyserver options.
* doc/gpg.texi: document this change.
--
This is a partial reversion of
7e1fe791d188b078398bf83c9af992cb1bd2a4b3. Werner and i discussed it
earlier today, and came to the conclusion that:
* the risk of metadata leakage represented by a default
--auto-key-retrieve, both in e-mail (as a "web bug") and in other
contexts where GnuPG is used to verified signatures, is quite high.
* the advantages of --auto-key-retrieve (in terms of signature
verification) can sometimes be achieved in other ways, such as when
a signed message includes a copy of its own key.
* when those other ways are not useful, a graphical, user-facing
application can still offer the user the opportunity to choose to
fetch the key; or it can apply its own policy about when to set
--auto-key-retrieve, without needing to affect the defaults.
Note that --auto-key-retrieve is specifically about signature
verification. Decisions about how and whether to look up a key during
message encryption are governed by --auto-key-locate. This change
does not touch the --auto-key-locate default of "local,wkd". The user
deliberately asking gpg to encrypt to an e-mail address is a different
scenario than having an incoming e-mail trigger a potentially unique
network request.
Signed-off-by: Daniel Kahn Gillmor <[email protected]>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions