Mailing List Archive

[Announce] Libgcrypt 1.8.4 released
Hi!

The GnuPG Project is pleased to announce the availability of Libgcrypt
versions 1.8.4. This is a maintenance release to fix a few minor bugs.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG. It does not provide any
implementation of OpenPGP or other protocols. Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes in version 1.8.4
===================================

* Bug fixes:

- Fix infinite loop due to applications using fork the wrong
way. [#3491]

- Fix possible leak of a few bits of secret primes to pageable
memory. [#3848]

- Fix possible hang in the RNG (1.8.3 only). [#4034]

- Several minor fixes. [#4102,#4208,#4209,#4210,#4211,#4212]

* Performance:

- On Linux always make use of getrandom if possible and then use
its /dev/urandom behaviour. [#3894]


Download
========

Source code is hosted at the GnuPG FTP server and its mirrors as listed
at <https://gnupg.org/download/mirrors.html>. On the primary server
the source tarball and its digital signature are:

https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.bz2
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.bz2.sig

or gzip compressed:

https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.gz
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
<https://gnupg.org/download/integrity_check.html>. In short, you may
use one of the following methods:

- Check the supplied OpenPGP signature. For example to check the
signature of the file libgcrypt-1.8.4.tar.bz2 you would use this
command:

gpg --verify libgcrypt-1.8.4.tar.bz2.sig libgcrypt-1.8.4.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 libgcrypt-1.8.4.tar.bz2, you run the command like this:

sha1sum libgcrypt-1.8.4.tar.bz2

and check that the output matches the first line from the
this list:

4a8ef9db6922f3a31992aca5640b4198a69b58fc libgcrypt-1.8.4.tar.bz2
211855f39f3bc3c4a4f444d4c09d743dfc5cb427 libgcrypt-1.8.4.tar.gz

You should also verify that the checksums above are authentic by
matching them with copies of this announcement. Those copies can be
found at other mailing lists, web sites, and search engines.


Copying
=======

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+). The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+). The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
=======

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4234 for updated information.

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1]. A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel
mailing list for discussion.


Thanks
======

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs one full-time developer and two
contractors. They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME, and GPA.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists. Thanks to Tomas Mraz for pointing out several smaller flaws.

Many thanks to our numerous financial supporters, both corporate and
individuals. Without you it would not be possible to keep GnuPG in a
good shape and address all the small and larger requests made by our
users. Thanks.


Happy hacking,

Your GnuPG hackers



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 four keys:

rsa2048 2011-01-12 [expires: 2019-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)

rsa2048 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 2014-10-29 [expires: 2020-10-30]
Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

rsa3072 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)

The keys are 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.
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Fri 2018-10-26 20:16:21 +0200, Werner Koch wrote:
> The GnuPG Project is pleased to announce the availability of Libgcrypt
> versions 1.8.4.

thanks for this release, Werner!

> * Performance:
>
> - On Linux always make use of getrandom if possible and then use
> its /dev/urandom behaviour. [#3894]

This characterization is unfortunate, since the getrandom() default
behavior is *not* the /dev/urandom behavior. In particular, the
getrandom() default behavior blocks until the kernel's internal pool has
been fully initialized, while /dev/urandom never blocks. This is one of
the main arguments for using getrandom() instead of /dev/urandom in the
first place.

I appreciate that the actual change landed in libgcrypt! This is a real
improvement for users of GNU/Linux systems. I just don't want people to
think that the change will cause them to possibly use an uninitialized
PRNG like /dev/urandom, because that is not the case with the change
that we made here.

--dkg
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
Hi,

I miss the tag labelling the version. I thought it would be the commit
in master that mentions the merge release (f1fe14 Fri Oct 26 20:04:44
2018 +0200) but after the "./autogen.sh", "libgcrypt-config --version"
says '1.9.0'.

Thanks

/Sergi.


On 10/26/18 20:16, Werner Koch wrote:
> Hi!
>
> The GnuPG Project is pleased to announce the availability of Libgcrypt
> versions 1.8.4. This is a maintenance release to fix a few minor bugs.
>
> Libgcrypt is a general purpose library of cryptographic building blocks.
> It is originally based on code used by GnuPG. It does not provide any
> implementation of OpenPGP or other protocols. Thorough understanding of
> applied cryptography is required to use Libgcrypt.
>
>
> Noteworthy changes in version 1.8.4
> ===================================
>
> * Bug fixes:
>
> - Fix infinite loop due to applications using fork the wrong
> way. [#3491]
>
> - Fix possible leak of a few bits of secret primes to pageable
> memory. [#3848]
>
> - Fix possible hang in the RNG (1.8.3 only). [#4034]
>
> - Several minor fixes. [#4102,#4208,#4209,#4210,#4211,#4212]
>
> * Performance:
>
> - On Linux always make use of getrandom if possible and then use
> its /dev/urandom behaviour. [#3894]
>
>
> Download
> ========
>
> Source code is hosted at the GnuPG FTP server and its mirrors as listed
> at <https://gnupg.org/download/mirrors.html>. On the primary server
> the source tarball and its digital signature are:
>
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.bz2
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.bz2.sig
>
> or gzip compressed:
>
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.gz
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.gz.sig
>
> In order to check that the version of Libgcrypt you downloaded is an
> original and unmodified file please follow the instructions found at
> <https://gnupg.org/download/integrity_check.html>. In short, you may
> use one of the following methods:
>
> - Check the supplied OpenPGP signature. For example to check the
> signature of the file libgcrypt-1.8.4.tar.bz2 you would use this
> command:
>
> gpg --verify libgcrypt-1.8.4.tar.bz2.sig libgcrypt-1.8.4.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 libgcrypt-1.8.4.tar.bz2, you run the command like this:
>
> sha1sum libgcrypt-1.8.4.tar.bz2
>
> and check that the output matches the first line from the
> this list:
>
> 4a8ef9db6922f3a31992aca5640b4198a69b58fc libgcrypt-1.8.4.tar.bz2
> 211855f39f3bc3c4a4f444d4c09d743dfc5cb427 libgcrypt-1.8.4.tar.gz
>
> You should also verify that the checksums above are authentic by
> matching them with copies of this announcement. Those copies can be
> found at other mailing lists, web sites, and search engines.
>
>
> Copying
> =======
>
> Libgcrypt is distributed under the terms of the GNU Lesser General
> Public License (LGPLv2.1+). The helper programs as well as the
> documentation are distributed under the terms of the GNU General Public
> License (GPLv2+). The file LICENSES has notices about contributions
> that require that these additional notices are distributed.
>
>
> Support
> =======
>
> In case of build problems specific to this release please first check
> https://dev.gnupg.org/T4234 for updated information.
>
> For help on developing with Libgcrypt you should read the included
> manual and optional ask on the gcrypt-devel mailing list [1]. A
> listing with commercial support offers for Libgcrypt and related
> software is available at the GnuPG web site [2].
>
> If you are a developer and you may need a certain feature for your
> project, please do not hesitate to bring it to the gcrypt-devel
> mailing list for discussion.
>
>
> Thanks
> ======
>
> Maintenance and development of GnuPG is mostly financed by donations.
> The GnuPG project currently employs one full-time developer and two
> contractors. They all work exclusively on GnuPG and closely related
> software like Libgcrypt, GPGME, and GPA.
>
> We have to thank all the people who helped the GnuPG project, be it
> testing, coding, translating, suggesting, auditing, administering the
> servers, spreading the word, and answering questions on the mailing
> lists. Thanks to Tomas Mraz for pointing out several smaller flaws.
>
> Many thanks to our numerous financial supporters, both corporate and
> individuals. Without you it would not be possible to keep GnuPG in a
> good shape and address all the small and larger requests made by our
> users. Thanks.
>
>
> Happy hacking,
>
> Your GnuPG hackers
>
>
>
> 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 four keys:
>
> rsa2048 2011-01-12 [expires: 2019-12-31]
> Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
> Werner Koch (dist sig)
>
> rsa2048 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 2014-10-29 [expires: 2020-10-30]
> Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
> NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>
>
> rsa3072 2017-03-17 [expires: 2027-03-15]
> Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
> Andre Heinecke (Release Signing Key)
>
> The keys are 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.
>
>
>
> _______________________________________________
> Gnupg-announce mailing list
> Gnupg-announce@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-announce
>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

--
Sergi Blanch-Torné
C797 490A C93E DB00 0615 680A FC1C 1CB6 8079 85E6
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Tue 2018-10-30 10:35:14 +0100, Sergi Blanch-Torné wrote:
> I miss the tag labelling the version. I thought it would be the commit
> in master that mentions the merge release (f1fe14 Fri Oct 26 20:04:44
> 2018 +0200) but after the "./autogen.sh", "libgcrypt-config --version"
> says '1.9.0'.

It looks to me that libgcrypt-1.8.4 should be tagged at
93775172713c00c363187b5d6a88895b04ac7c8e, which is on the branch named
LIBGCRYPT-1.8-BRANCH.

i think f1fe14 is on the master branch, and is not what you're looking
for.

I agree that the tag should have been published to
https://dev.gnupg.org/source/libgcrypt.git at the same time as the new
version was published and announced, though -- some step of the release
process probably isn't as automated as it should be.

--dkg
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
Hi,

Yes Daniel, I went to master instead of the 1.8 branch. By the way, the
commit you mention gives me version '1.8.4-beta14'. Perhaps there is
something else apart of the tagging.

/Sergi.

On 10/30/18 14:29, Daniel Kahn Gillmor wrote:
> On Tue 2018-10-30 10:35:14 +0100, Sergi Blanch-Torné wrote:
>> I miss the tag labelling the version. I thought it would be the commit
>> in master that mentions the merge release (f1fe14 Fri Oct 26 20:04:44
>> 2018 +0200) but after the "./autogen.sh", "libgcrypt-config --version"
>> says '1.9.0'.
>
> It looks to me that libgcrypt-1.8.4 should be tagged at
> 93775172713c00c363187b5d6a88895b04ac7c8e, which is on the branch named
> LIBGCRYPT-1.8-BRANCH.
>
> i think f1fe14 is on the master branch, and is not what you're looking
> for.
>
> I agree that the tag should have been published to
> https://dev.gnupg.org/source/libgcrypt.git at the same time as the new
> version was published and announced, though -- some step of the release
> process probably isn't as automated as it should be.
>
> --dkg
>
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Mon, 29 Oct 2018 18:22, dkg@fifthhorseman.net said:

> This characterization is unfortunate, since the getrandom() default
> behavior is *not* the /dev/urandom behavior. In particular, the

I used to explain that getrandom uses the urandom pool and not the
random pool. They are separate and have different properties. See
Stephan Müller's paper he wrote for the BSI.

> getrandom() default behavior blocks until the kernel's internal pool has
> been fully initialized, while /dev/urandom never blocks. This is one of

That is detail and could even be viewed as a bug fix for the
open("/dev/urandom") behaviour. Which in the early days of Linux was
also different.

> think that the change will cause them to possibly use an uninitialized
> PRNG like /dev/urandom, because that is not the case with the change

Those who are using Libgcrypt in the early boot phase should be aware of
the problem with modern Linux kernels. Again, see the paper.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Tue, 30 Oct 2018 14:29, dkg@fifthhorseman.net said:

> version was published and announced, though -- some step of the release
> process probably isn't as automated as it should be.

Right. This can't be automated because it requires to to find the token
plug it in and enter the PIN. This is mostly driven by a make target
but the pushing is done manually to allow for a final check.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Tue 2018-10-30 15:33:03 +0100, Werner Koch wrote:
> On Mon, 29 Oct 2018 18:22, dkg@fifthhorseman.net said:
>
>> This characterization is unfortunate, since the getrandom() default
>> behavior is *not* the /dev/urandom behavior. In particular, the
>
> I used to explain that getrandom uses the urandom pool and not the
> random pool. They are separate and have different properties. See
> Stephan Müller's paper he wrote for the BSI.

right, but the release notes say it uses the /dev/urandom *behavior*,
not the urandom *pool*. the /dev/urandom behavior is still:

a) whether the urandom pool is initialized or not, use it.

but what getrandom() does is:

b) wait for the urandom pool to be initialized, and then use it.

>> getrandom() default behavior blocks until the kernel's internal pool has
>> been fully initialized, while /dev/urandom never blocks. This is one of
>
> That is detail and could even be viewed as a bug fix for the
> open("/dev/urandom") behaviour. Which in the early days of Linux was
> also different.

that is certainly detail, but it is the relevant detail here :)

> Those who are using Libgcrypt in the early boot phase should be aware of
> the problem with modern Linux kernels. Again, see the paper.

I'm assuming that "the early boot phase" means "until the crng is
initialized". On minimalist virtual machines that use a modern system
supervisor that has relatively short boot times, it can be a
surprisingly long time after system boot that the crng is initialized.
I suspect that there are users of libgcrypt who don't know that their
code is being run in this sense of "in the early boot phase".

At any rate, the change in gcrypt 1.8.4 actually *helps* those users,
rather than harms them, because it removes unnecessary blocking while
avoiding exposing the user to use of an unintialized RNG. so as long as
they're running a modern kernel, they don't need to read the paper :)

thanks for making the change!

--dkg
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Tue 2018-10-30 15:21:56 +0100, Sergi Blanch-Torné wrote:
> Yes Daniel, I went to master instead of the 1.8 branch. By the way, the
> commit you mention gives me version '1.8.4-beta14'. Perhaps there is
> something else apart of the tagging.

until the tag is published (it has been made and published now), the
auto-versioning done by configure.ac will assume that you're working on
a beta release. Please try again after a "git remote update"!

--dkg

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Tue 2018-10-30 15:35:20 +0100, Werner Koch wrote:
> On Tue, 30 Oct 2018 14:29, dkg@fifthhorseman.net said:
>
>> version was published and announced, though -- some step of the release
>> process probably isn't as automated as it should be.
>
> Right. This can't be automated because it requires to to find the token
> plug it in and enter the PIN. This is mostly driven by a make target
> but the pushing is done manually to allow for a final check.

it sounds like the tag can't be created automatically. that makes
sense, thanks for explaining it! But perhaps whatever tools do an
automated push/publication of the release could refuse to run if no
signed tag is present and available to be pushed?

--dkg
Re: [Announce] Libgcrypt 1.8.4 released [ In reply to ]
On Tue, 30 Oct 2018 17:29, dkg@fifthhorseman.net said:

> right, but the release notes say it uses the /dev/urandom *behavior*,
> not the urandom *pool*. the /dev/urandom behavior is still:

Come on, why this nitpicking for release notes virtually nobody reads.
The use of the /dev/urandom (blocking or not) is the real change because
it changes the security properties we assume in certain use cases of
GnuPG (gpg4vs-nfd project). This is not a technical but a security
policy question.

> I'm assuming that "the early boot phase" means "until the crng is
> initialized". On minimalist virtual machines that use a modern system
> supervisor that has relatively short boot times, it can be a

Even with a full failing /dev/urandom we still have sufficient entropy
From RDRAND and the JitterRNG. In fact the JitterRNG is the only
measurable and thus valid entropy source we have on Windows. And we use
it on Linux as well for some fraction of the overall entropy fed into
Libgcrypt's pool.

> rather than harms them, because it removes unnecessary blocking while
> avoiding exposing the user to use of an unintialized RNG. so as long as

There won't be an uninitialized RNG just due to a failing /dev/random in
1.8.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.