> gpg: Options --auto-key-retrieve and --auto-key-locate "local,wkd" are now used by default.
> Note: this enables keyserver and Web Key Directory operators to notice when a signature from a locally non-available key is being verified for the first time [...]
I'm not sure if I agree with that decision. Many people intentionally keep their keys off the key servers, and GPG is used by many internal signing applications (internal repos, etc.) where the keys aren't public, and enabling this by default would leak lots of metadata about the internal infrastructure. Last time I checked, the key server protocol was unencrypted, I hope this is no longer the case.
On the other hand, it will improve usability for "normal" usage and you'll still be prompted to verify the fingerprint for unknown keys.
Exactly. It uses the same host as uid's email. So if one have key "John Doe <jd@example.com>" it'd query example.com for reference to the key. It's not a security problem unless one considers their own company's servers untrustworthy.
Imagine a dissident / whistle blower / journalistic source using gpg. I could send her a message, signed with a new key, and just wait until her gpg executable contacts my server.
Then I have her IP address, and if I am lucky, I can plant an exploit into the very first request response.
I imagine this kind of people do not run with default configuration just as they use Tails and not your regular Ubuntu install. If not they can be traced with even less obvious means, just like PGP comments: http://www.csoonline.com/article/2904395/microsoft-subnet/mi...
The many people you're talking about are still a minority. GPG direly needs better usability and this was one of the pain points, good to see it fixed.
As mentioned in the linked announcement, they also added a complementary option to completely prevent gpg from talking to the network. It should address the use case you describe:
* gpg: New option --disable-dirmngr to entirely disable network access for gpg.
This is subtlety riskier for people whom don't fully grasp WoT model or whom blindly trust an external source, ie keybase, without in-person key id validation. GPG/GNU/FOSS and tech meetups need to vigilantly promote GPG key-signing/sharing events more and underscore its importance.
PS: I wish GPG had better marketing / public multicast/broadcast communication.
I was under the mistaken impression for the longest time that gpg 2 was a fork (maybe a GUI fork?) or otherwise unofficial successor to gpg, and I should continue sticking to gpg 1.x. I figured that gpg2 must have a more complex relationship to gpg than just being the next version of it because otherwise they'd just call it gpg instead of going through the effort to let people keep using gpg 1.x by default.
That was my impression also. A couple of years ago I put gpg2 in a script and whatever option I used would spawn a GUI window asking for information. I could not stop that from happening so I have stuck with gpg v1.x since.
Now any reference to /usr/bin/gpg2 is broken. Every wiki that told people they had to specify gpg2 to use XYZ feature is lying. Every script and environment variable that depends on /usr/bin/gpg2 existing is now broken, depending on if your packager decides to --enable-gpg-is-gpg2.
Do a search for '"gpg2" inurl:wiki' to see a bunch of now-broken documentation.
This is something I really dislike about the use of 3rd-party wikis for documenting software.
They always seem like a good idea at first, but then they slowly become misleading as contributors move on. You can't even call them "irrelevant" at that point because readers don't know they've become irrelevant.
And, by spending energy on the wiki, people don't try improving the upstream documentation. I assume they were motivated to make the wiki due to some problem with the upstream doc but, in the end, the upstream docs don't get improved, and you have a confusing wiki.
Please work with the upstream project on documentation instead. And if you are the upstream, consider a policy of rejecting patches that don't amend the docs appropriately.
I like that it will automatically try to download missing public keys.
HOWEVER, a very useful feature (which it might have but wasn't mentioned in the upgrade notes; my own local manpage only has --list-public-keys (and shorter versions) and --locate-keys (which has wording that makes me think it'll also check online)) would be to search, local only, for any key (public or private) matching a given fingerprint hex or other field string. The changelog makes me think that to get that behavior I'd presently have to use: gpg --auto-key-locate local --locate-keys "example@example.com"
> Note: this enables keyserver and Web Key Directory operators to notice when a signature from a locally non-available key is being verified for the first time [...]
I'm not sure if I agree with that decision. Many people intentionally keep their keys off the key servers, and GPG is used by many internal signing applications (internal repos, etc.) where the keys aren't public, and enabling this by default would leak lots of metadata about the internal infrastructure. Last time I checked, the key server protocol was unencrypted, I hope this is no longer the case.
On the other hand, it will improve usability for "normal" usage and you'll still be prompted to verify the fingerprint for unknown keys.