
GnuPG 2.1.23 released - jwilk
https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000412.html
======
lima
> _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.

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

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

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

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

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

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

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

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

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

