GnuPG 2.2.0 released
Note: this enables keyserver and Web Key Directory operators to notice when you intend to encrypt to a mail address without having the key locally. This new behaviour will eventually make key discovery much easier and mostly automatic."
| From: | Werner Koch <wk-AT-gnupg.org> | |
| To: | gnupg-announce-AT-gnupg.org, info-gnu-AT-gnu.org | |
| Subject: | GnuPG 2.2.0 released | |
| Date: | Mon, 28 Aug 2017 13:51:11 +0200 | |
| Message-ID: | <87r2vvkj0w.fsf__16675.3493519083$1503925976$gmane$org@wheatstone.g10code.de> |
Hello!
Arguing that you don't care about the right to privacy
because you have nothing to hide is no different from
saying you don't care about free speech because you have
nothing to say. - Edward Snowden
The GnuPG team is pleased to announce the availability of a new release
of GnuPG: version 2.2.0. See below for a list of new features and bug
fixes. This release marks the start of a new long term support series
to replace the 2.0.x series which will reach end-of-life on 2017-12-31.
About GnuPG
=============
The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.
GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories. GnuPG itself is a command line tool with features for easy
integration with other applications. A wealth of frontend applications
and libraries making use of GnuPG are available. As an Universal Crypto
Engine GnuPG provides support for S/MIME and Secure Shell in addition to
OpenPGP.
GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.
Noteworthy changes in version 2.2.0
===================================
This is the new long term stable branch. This branch will only see
bug fixes and no new features.
* gpg: Reverted change done in 2.1.23 so that --no-auto-key-retrieve
is again the default.
* Fixed a few minor bugs.
This release incorporates all changes from the 2.1 series including
these from the release candidate 2.1.23:
* 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.
* gpg: Option --auto-key-locate "local,wkd" is now used by default.
Note: this enables keyserver and Web Key Directory operators to
notice when you intend to encrypt to a mail address without having
the key locally. This new behaviour will eventually make key
discovery much easier and mostly automatic. Disable this by adding
auto-key-locate local
to your gpg.conf. [This description has been adjusted to include
the above mentioned change in 2.2.0]
* agent: Option --no-grab is now the default. The new option --grab
allows to revert this.
* gpg: New import option "show-only".
* gpg: New option --disable-dirmngr to entirely disable network
access for gpg.
* gpg,gpgsm: Tweaked DE-VS compliance behaviour.
* New configure flag --enable-all-tests to run more extensive tests
during "make check".
* gpgsm: The keygrip is now always printed in colon mode as
documented in the man page.
* Fixed connection timeout problem under Windows.
A detailed description of the changes in the 2.2 (formerly 2.1) branch
can be found at <https://gnupg.org/faq/whats-new-in-2.1.html>.
Getting the Software
====================
Please follow the instructions found at <https://gnupg.org/download/> or
read on:
GnuPG 2.2.0 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server. The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>. Note that GnuPG is not
available at ftp.gnu.org.
The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.0.tar.bz2 (6379k)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.0.tar.bz2.sig
An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.0_20170... (3797k)
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.0_20170...
The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix. A new release candidate for Gpg4win
featuring this version of GnuPG will be available in a few days.
Checking the Integrity
======================
In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:
* If you already have a version of GnuPG installed, you can simply
verify the supplied signature. For example to verify the signature
of the file gnupg-2.2.0.tar.bz2 you would use this command:
gpg --verify gnupg-2.2.0.tar.bz2.sig gnupg-2.2.0.tar.bz2
This checks whether the signature file matches the source file.
You should see a message indicating that the signature is good and
made by one or more of the release signing keys. Make sure that
this is a valid key, either by matching the shown fingerprint
against a trustworthy list of valid release signing keys or by
checking that the key has been signed by trustworthy other keys.
See the end of this mail for information on the signing keys.
* If you are not able to use an existing version of GnuPG, you have
to verify the SHA-1 checksum. On Unix systems the command to do
this is either "sha1sum" or "shasum". Assuming you downloaded the
file gnupg-2.2.0.tar.bz2, you run the command like this:
sha1sum gnupg-2.2.0.tar.bz2
and check that the output matches the next line:
36ee693d0b2ec529ecf53dd6d397cc38ba71c0a7 gnupg-2.2.0.tar.bz2
7b0cf3912b86a6bd7655026276984a34a248e625 gnupg-w32-2.2.0_20170828.exe
0997499bdc6edfa43e2ce3d2cda9de00ecbc369d gnupg-w32-2.2.0_20170828.tar.xz
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated.
Documentation
=============
If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at
https://gnupg.org/faq/whats-new-in-2.1.html
The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well but they have not all the
details available as are the manual. It is also possible to read the
complete manual online in HTML format at
https://gnupg.org/documentation/manuals/gnupg/
or in Portable Document Format at
https://gnupg.org/documentation/manuals/gnupg.pdf .
The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing. You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems. Many of the new features are around for
several years and thus enough public knowledge is already available.
You may also want to follow our postings at <https://gnupg.org/blob/>
and <https://twitter.com/gnupg>.
Support
========
Please consult the archive of the gnupg-users mailing list before
reporting a bug: <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>. If you need commercial
support check out <https://gnupg.org/service.html>.
If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.
Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project employs 4 full-time developers, one part-timer, and
one contractor. They all work exclusivly on GnuPG and closely related
software like Libgcrypt, GPGME, and GPA. Please consider to donate via:
https://gnupg.org/donate/
Thanks
======
We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, answering questions on the mailing lists,
and for financing the project. Special thanks to Neal and Justus for
all their valuable work.
Happy hacking,
Your GnuPG Team
p.s.
This is an announcement only mailing list. Please send replies only to
the gnupg-users'at'gnupg.org mailing list.
p.p.s
List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions. The keys are also signed by the long term keys of
their respective owners. Current releases are signed by one or more
of these five keys:
2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959
David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>
rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>
rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9
Werner Koch (Release Signing Key)
rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)
You may retrieve these keys from a keyserver using this command
gpg --keyserver hkp://keys.gnupg.net --recv-keys \
249B39D24F25E3B6 04376F3EE0856959 \
2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28
The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
--
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.
Posted Sep 2, 2017 12:26 UTC (Sat)
by wx (guest, #103979)
[Link] (10 responses)
This sound so inexplicably stupid that I'm having a hard time believing they're actually doing it. Anyone care to clarify?
If they really fetch keys from public key servers based on e-mail address (or even key ID) users might as well send plain text messages.
Posted Sep 2, 2017 12:49 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link]
Doing it this way brings GnuPG closer to e.g. OpenSSH, where when you first connect to a server, the server sends you its fingerprint. You're supposed to call up the administrator of that machine on the telephone or whatever, to ensure that the fingerprint matches, but hardly anybody does. If you later connect to that machine and it's fingerprint has changed, _then_ OpenSSH complains about a possible MITM attach.
So with automatic key fetching, the guarantee is now that the person you're talking to is the same person you've always been talking to, rather than the same person that you've met IRL. Of course, you can still use the web-of-trust if you like, just like you can phone up the admin of the server that you're connecting to to verify that it's truly the same machine.
Posted Sep 3, 2017 10:27 UTC (Sun)
by jwilk (subscriber, #63328)
[Link] (4 responses)
GnuPG 2.2.0 will fetch the key when you try to encrypt to an e-mail address, but you don't have the key locally.
It won't fetch keys when verifying signatures. (GnuPG 2.1.23 did that by default, which was inexplicably stupid; luckily the change has been reverted.)
See also: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August...
Posted Sep 3, 2017 12:24 UTC (Sun)
by wx (guest, #103979)
[Link] (3 responses)
Anyone can upload arbitrary keys to key servers. Forged keys are pretty commonly found. The problem isn't actually limited to look up by e-mail address. Collisions in short key IDs are extremely easy to take advantage of. Collisions in long key IDs take more computational effort but are also possible.
I would actually argue that outside of the package management use case fetching keys automatically when encrypting e-mail is even worse than when verifying signatures. The latter only compromises authentication while the earlier breaks confidentiality. Users who actually need gpg require confidentiality first and foremost. (Luckily I'm not one of those users.)
On a related note, considering how much fuss Werner Koch has made about parsing command line output being the only way to interact with gpg from other applications it's completely beyond me why he would now even consider talking to remote servers over the network from the same process by default. It was always my impression that it was a best practice to at least use a separate program or gpg with a different $GNUPGHOME or even a separate account/machine for that purpose.
If the authors of an encryption tool even remotely think that this new behavior is a sane option the only sensible thing to do is to stop trusting them. I guess we need a replacement for gpg.
Posted Sep 4, 2017 7:38 UTC (Mon)
by gouttegd (guest, #106484)
[Link]
With GnuPG 2.1 (and now 2.2), the gpg process never talks directly to remote servers. All network-related tasks (access to keyservers, to Web Key Directories, to keys published in the DNS...) are performed by a separate daemon called dirmngr. And as stated in the announce, if that is still not satisfying enough you can use the --disable-dirmngr to prevent gpg from starting the dirmngr daemon and thus completely forbid all network access.
In the same vein, the gpg process also never manipulates the private keys itself, this is delegated to the gpg-agent process.
It is true that the 1.x branch of GnuPG was monolithic (everything was in the gpg binary). But that's not true anymore.
Posted Sep 4, 2017 17:29 UTC (Mon)
by jwilk (subscriber, #63328)
[Link]
Do you have any particular attack scenario in mind? I'm confused.
One bad thing about --auto-key-locate is that is they facilitate phishing attacks.
Say I want to steal Alice's and Bob's secret plans to take over the world.
To do that, I could send the following mail to Alice:
Without automatic key retrieval, GnuPG would act like a safety net: even if Alice overlooked the fishy From header, it wouldn't be possible for her to send an encrypted mail to the attacker, because she wouldn't have the key.
But --auto-key-retrieve makes this kind of phishing as easy as --auto-key-locate, so you must have had something else in mind.
Posted Sep 8, 2017 21:32 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Sep 3, 2017 14:06 UTC (Sun)
by gouttegd (guest, #106484)
[Link] (3 responses)
It will not automatically fetch keys from keyservers, it will attempt to fetch them from Web Key Directories (WKD: https://gnupg.org/blog/20161027-hosting-a-web-key-directo...).
It's not as bad as fetching key from a keyserver, because while anyone can upload a key associated with any address to a keyserver, publishing a key in a Web Key Directory requires the cooperation of the domain owner (the key for for alice@example.org can only be published in the WKD of example.org). This is not perfect, but it still raises the bar for an attacker wishing to publish a fake key.
Posted Sep 3, 2017 17:14 UTC (Sun)
by wx (guest, #103979)
[Link] (2 responses)
Thanks. That makes a little more sense.
> publishing a key in a Web Key Directory requires the cooperation of the domain owner
No. It doesn't. When will people finally understand that neither DNS nor SSL certs are suitable for authentication?
> it still raises the bar for an attacker wishing to publish a fake key.
Ever so slightly, yes. The whole thing comes at a price though: It creates a false sense of security.
Posted Sep 4, 2017 11:50 UTC (Mon)
by gouttegd (guest, #106484)
[Link]
The aim is to make GnuPG suitable by default for users merely wanting to avoid mass surveillance ("pervasive monitoring" as the IETF calls it) without too much concern for targeted attacks. Facilitating the distribution and fetching of keys is one aspect of this new focus, as is the newly introduced "trust-on-first-use" trust model intended to replace the web of trust (theoretically great but actually too complicated to use for most people).
That does not mean that GnuPG will not be suitable anymore for people fearing targeted attacks. We are only speaking of the default configuration. Users who think they may be personally targeted will still be able to harden the configuration.
In other words, the idea is: be easy-to-use against mass surveillance for the majority of people and let the (presumably fewer) people more at risk tweak the knobs for higher security, instead of the other way around (be tailored for targeted users and let the more casual users tweak the knobs for more convenience).
Werner Koch expressed this idea (among other things) in a DebConf presentation two years ago (slides: https://gnupg.org/ftp/blurbs/debconf15_gnupg-past-present... ; video recording: http://meetings-archive.debian.net/pub/debian-meetings/20...).
> When will people finally understand that neither DNS nor SSL certs are suitable for authentication?
Well, I think originally it was intended that when fetching a key from the DNS (using, eg, DANE OPENPGPKEY records as per RFC 7929), the fetched key should be considered at least marginally valid (or even fully valid) if the DNS record was authentified by DNSSEC.
This idea has been abandoned (partly due to the slow deployment of DNSSEC) and GnuPG maintains a strict separation between fetching a key and validating a key: the method used to find a key (be it on a keyserver, in a WKD, in th DNS...) has no effect on that key's validity, which it always solely determined by the trust model in action (so if you stick with the classic web of trust model, any automatically fetched key will be regarded as being of unknown validity---you can still use it, but GnuPG will warn you that the key may not belong to its stated owner).
Posted Sep 6, 2017 0:59 UTC (Wed)
by davidstrauss (guest, #85867)
[Link]
When will people finally understand that authentication is about achieving a level of confidence suitable for what the authentication is being used for (and the means of people using the system)? There is no universal standard for what's suitable for authentication, only mechanisms that offer varying levels of assurance, cost, available implementations, and ease-of-use. If something requires effort to exploit, forge, or fraudulently obtain, then it provides authentication value commensurate with that difficulty. So, while attacks exist against domain control validation, approaches like multiple vantage points [1] make attacks difficult. The difficulty is high enough that domain validation is suitable for plenty of purposes, especially if the likely alternative users adopt is "nothing at all."
> Ever so slightly, yes. The whole thing comes at a price though: It creates a false sense of security.
Significant but less-than-perfect security is not "a false sense of security"; it is merely imperfect security. If you bother to lock the door to your home when you leave -- despite the wide availability of lock picks and the ease of breaking windows -- then you're already acknowledging that even flawed security has value versus nothing. DNS-based validation -- even without multiple vantage points or DNSSec -- is still better than nothing.
Besides, all security is imperfect. Even if GPG's own validation model is perfect, my use of it is vulnerable to other systems being exploited. I can fight those vulnerabilities with impractical measures like air-gapped machines, but then I'm going to use GPG for far fewer things by necessity. Striking the right balance of usability and security is hard, and absolutism doesn't help.
[1] https://community.letsencrypt.org/t/validating-challenges...
GnuPG 2.2.0 released
GnuPG 2.2.0 released
GnuPG 2.2.0 released
GnuPG 2.2.0 released
GnuPG 2.2.0 released
GnuPG 2.2.0 released
From: Bob Beaver <jwilk@jwilk.net>
To: Alice Antelope <alice@example.com>
Subject: Secret plans
Hi Alice!
It's me, Bob. (I promise!)
I accidentally deleted the file with our secret plans.
Could you send me a copy?
Thanks!
--
Bob Beaver <bob@example.net>
GnuPG 2.2.0 released
On a related note, considering how much fuss Werner Koch has made about parsing command line output being the only way to interact with gpg from other applications
Can't you use libassuan as well?
GnuPG 2.2.0 released
> This sound so inexplicably stupid that I'm having a hard time believing they're actually doing it. Anyone care to clarify?
GnuPG 2.2.0 released
GnuPG 2.2.0 released
GnuPG 2.2.0 released