GnuPG 2.1.23 released | Hacker News Reader

GnuPG 2.1.23 released

lists.gnupg.org

82 pointsjwilk22 comments

> 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.

AIUI, this doesn't use key servers; it's a different protocol.

https://wiki.gnupg.org/WKD

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.

Technical details from the RFC:

> For example the URI to lookup the key for Joe.Doe@Example.ORG is: https://example.org/.well-known/openpgpkey/ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q

(local part is SHA-1 encoded)

Source: https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic...

It is a security problem for the recipient.

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.

No, it's the other way around.

GPG is extremely wide-spread for code signing (pretty much any Linux distro uses it), but it's barely used for email encryption.

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.

What pointy haired boss named that option? Just reading that sentence tells us it should not be named "disable-dirmngr".

Would be nice if the .gnupgrc would let you enable that, leaving the default to staying off the network.

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.

"gpg: "gpg" is now installed as "gpg" and not anymore as "gpg2". If needed, the new configure option --enable-gpg-is-gpg2 can be used to revert this."

Aha. I was wondering if this would be deemed a mere sequel to GPG 1 forever.

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.

Curious if that still happens with gpg2.

Thank goodness for this. I keeping having to symlink gpg2 to gpg on new servers to keep myself from going bonkers.

Wouldn't recommend a symlink since it could break scripts that expect a particular version.

A bash alias is safer:

    alias gpg=gpg2

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.

For those concerned about the auto key retrieval mechanism, add the following to your gpg.conf:

  no-auto-key-retrieve
  auto-key-locate local

> Options --auto-key-retrieve and --auto-key-locate "local,wkd" are now used by default.

Sounds like a security hole to me, especially for systems that automatically verify signatures against a curated keyring.

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"

I wonder if they have any plan to support chacha20/poly1305 for encryption and sha2/keccak/blake for fingerprints.

Reply on news.ycombinator.com