4 ms·

GnuPG 2.1.23 released

82 points by jwilk 9y ago

wonks 9y ago
"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.
- client4 9y ago
  Thank goodness for this. I keeping having to symlink gpg2 to gpg on new servers to keep myself from going bonkers.
  - lima 9y ago
    Wouldn't recommend a symlink since it could break scripts that expect a particular version. A bash alias is safer: alias gpg=gpg2
- nickysielicki 9y ago
  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.
  - lfam 9y ago
    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.
- AgentME 9y ago
  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.
  - jmclnx 9y ago
    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.
lima 9y ago
> 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.
- scrollaway 9y ago
  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.
  - lima 9y ago
    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.
- jwilk 9y ago
  AIUI, this doesn't use key servers; it's a different protocol. https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD
  - hdhzy 9y ago
    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/ https://example.org/.well-known/openpgpkey/ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q (local part is SHA-1 encoded) Source: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-04 https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic...
mjevans 9y ago
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"
jwilk 9y ago
> 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.
eklitzke 9y ago
For those concerned about the auto key retrieval mechanism, add the following to your gpg.conf: no-auto-key-retrieve auto-key-locate local
snakeanus 9y ago
I wonder if they have any plan to support chacha20/poly1305 for encryption and sha2/keccak/blake for fingerprints.

82 points by jwilk 9y ago

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

client4 9y ago
Thank goodness for this. I keeping having to symlink gpg2 to gpg on new servers to keep myself from going bonkers.
- lima 9y ago
  Wouldn't recommend a symlink since it could break scripts that expect a particular version. A bash alias is safer: alias gpg=gpg2
nickysielicki 9y ago
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.
- lfam 9y ago
  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.
AgentME 9y ago
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.
- jmclnx 9y ago
  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.

lima 9y ago

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

scrollaway 9y ago
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.
- lima 9y ago
  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.
jwilk 9y ago
AIUI, this doesn't use key servers; it's a different protocol. https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD
- hdhzy 9y ago
  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/ https://example.org/.well-known/openpgpkey/ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q (local part is SHA-1 encoded) Source: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-04 https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic...

mjevans 9y ago

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"

jwilk 9y ago

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

eklitzke 9y ago

For those concerned about the auto key retrieval mechanism, add the following to your gpg.conf: no-auto-key-retrieve auto-key-locate local

snakeanus 9y ago

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