I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This is mainly a bug fix release.
The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html.
NEWS for the Nettle 3.3 release
This release fixes a couple of bugs, and improves resistance to side-channel attacks on RSA and DSA private key operations.
Changes in behavoir:
* Invalid private RSA keys, with an even modulo, are now rejected by rsa_private_key_prepare. (Earlier versions allowed such keys, even if results of using them were bogus).
Nettle applications are required to call rsa_private_key_prepare and check the return value, before using any other RSA private key functions; failing to do so may result in crashes for invalid private keys. As a workaround for versions of Gnutls which don't use rsa_private_key_prepare, additional checks for even moduli are added to the rsa_*_tr functions which are used by all recent versions of Gnutls.
* Ignore bit 255 of the x coordinate of the input point to curve25519_mul, as required by RFC 7748. To differentiate at compile time, curve25519.h defines the constant NETTLE_CURVE25519_RFC7748.
Security:
* RSA and DSA now use side-channel silent modular exponentiation, to defend against attacks on the private key from evil processes sharing the same processor cache. This attack scenario is of particular relevance when running an HTTPS server on a virtual machine, where you don't know who you share the cache hardware with.
(Private key operations on elliptic curves were already side-channel silent).
Bug fixes:
* Fix sexp-conv crashes on invalid input. Reported by Hanno Böck.
* Fix out-of-bounds read in des_weak_p. Fixed by Nikos Mavrogiannopoulos.
* Fix a couple of formally undefined shift operations, reported by Nikos Mavrogiannopoulos.
* Fix compilation with c89. Reported by Henrik Grubbström.
New features:
* New function memeql_sec, for side-channel silent comparison of two memory areas.
Miscellaneous:
* Building the public key support of nettle now requires GMP version 5.0 or later (unless --enable-mini-gmp is used).
* Filenames of windows DLL libraries now include major number only. So the dll names change at the same time as the corresponding soname on ELF platforms. Fixed by Nikos Mavrogiannopoulos.
* Eliminate most pointer-signedness warnings. In the process, the strings representing expression type for sexp_interator functions were changed from const uint8_t * to const char *. These functions are undocumented, and it doesn't change the ABI on any platform I'm aware of.
The shared library names are libnettle.so.6.3 and libhogweed.so.4.3, with sonames still libnettle.so.6 and libhogweed.so.4. It is intended to be fully binary compatible with nettle-3.1.
https://ftp.gnu.org/gnu/nettle/nettle-3.3.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.3.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.3.tar.gz
Happy hacking, /Niels Möller
From: nisse@lysator.liu.se (Niels Möller) Date: Sat, 01 Oct 2016 21:51:05 +0200
I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This is mainly a bug fix release.
Thanks!
- Eliminate most pointer-signedness warnings. In the process, the strings representing expression type for sexp_interator functions were changed from const uint8_t * to const char *. These functions are undocumented, and it doesn't change the ABI on any platform I'm aware of.
Building with MinGW on MS-Windows, I still see a few warnings of this kind, like the ones below:
nettle-hash.c: In function 'digest_file': nettle-hash.c:123:25: warning: pointer targets in passing argument 1 of 'nettle_base16_encode_update' differ in signedness [-Wpointer-sign] base16_encode_update(hex, 8, digest + i); ^ In file included from nettle-hash.c:44:0: ../base16.h:46:30: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'char *' #define base16_encode_update nettle_base16_encode_update ^ ../base16.h:64:1: note: in expansion of macro 'base16_encode_update' base16_encode_update(uint8_t *dst, ^ nettle-hash.c:127:28: warning: pointer targets in passing argument 1 of 'nettle_base16_encode_update' differ in signedness [-Wpointer-sign] base16_encode_update(hex, digest_length - i, digest + i); ^ In file included from nettle-hash.c:44:0: ../base16.h:46:30: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'char *' #define base16_encode_update nettle_base16_encode_update ^ ../base16.h:64:1: note: in expansion of macro 'base16_encode_update' base16_encode_update(uint8_t *dst, ^
nettle-pbkdf2.c: In function 'main': nettle-pbkdf2.c:181:25: warning: pointer targets in passing argument 1 of 'nettle_base16_encode_update' differ in signedness [-Wpointer-sign] base16_encode_update(hex, 8, output + i); ^ In file included from nettle-pbkdf2.c:44:0: ../base16.h:46:30: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'char *' #define base16_encode_update nettle_base16_encode_update ^ ../base16.h:64:1: note: in expansion of macro 'base16_encode_update' base16_encode_update(uint8_t *dst, ^ nettle-pbkdf2.c:185:28: warning: pointer targets in passing argument 1 of 'nettle_base16_encode_update' differ in signedness [-Wpointer-sign] base16_encode_update(hex, output_length - i, output + i); ^ In file included from nettle-pbkdf2.c:44:0: ../base16.h:46:30: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'char *' #define base16_encode_update nettle_base16_encode_update ^ ../base16.h:64:1: note: in expansion of macro 'base16_encode_update' base16_encode_update(uint8_t *dst, ^
In file included from testutils.c:3:0: testutils.c: In function 'tstring_hex': testutils.c:82:13: warning: pointer targets in passing argument 5 of 'nettle_base16_decode_update' differ in signedness [-Wpointer-sign] length, hex)); ^ testutils.h:293:11: note: in definition of macro 'ASSERT' if (!(x)) \ ^ In file included from testutils.c:5:0: ../base16.h:49:30: note: expected 'const uint8_t * {aka const unsigned char *}' but argument is of type 'const char *' #define base16_decode_update nettle_base16_decode_update ^ ../base16.h:96:1: note: in expansion of macro 'base16_decode_update' base16_decode_update(struct base16_decode_ctx *ctx, ^
Date: Sun, 02 Oct 2016 09:14:12 +0300 From: Eli Zaretskii eliz@gnu.org
From: nisse@lysator.liu.se (Niels Möller) Date: Sat, 01 Oct 2016 21:51:05 +0200
I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This is mainly a bug fix release.
Thanks!
- Eliminate most pointer-signedness warnings. In the process, the strings representing expression type for sexp_interator functions were changed from const uint8_t * to const char *. These functions are undocumented, and it doesn't change the ABI on any platform I'm aware of.
Building with MinGW on MS-Windows, I still see a few warnings of this kind, like the ones below:
And one more gripe: why doesn't Nettle have the standard 'install-strip' target in its Makefile? Or did I miss something?
Eli Zaretskii eliz@gnu.org writes:
And one more gripe: why doesn't Nettle have the standard 'install-strip' target in its Makefile?
TL;DR: I guess that's an oversight, I'd need sme advice to get it right.
What's the simplest way to to that? Is it enough to patch the top-level Makefile.in like below? (Automake seems to produce something slightly more complicated).
And then exactly what is it that should be stripped? I see that the make targets for installing both shared and static libraries use $(INSTALL_DATA) rather than $(INSTALL_PROGRAM), so libraries won't be affected. Those targets are a decade old, but I think it followed GNU standards at the time.
When handling libraries, I imagine one need to be a little careful to use the right one of
strip strip -s strip --strip-debug strip --strip-unneded
and I'm not sure which is implied by install -s.
Regards, /Niels
diff --git a/Makefile.in b/Makefile.in index 135542f..2103665 100644 --- a/Makefile.in +++ b/Makefile.in @@ -50,6 +50,9 @@ all check install uninstall: set -e; for d in $(SUBDIRS); do \ echo "Making $@ in $$d" ; (cd $$d && $(MAKE) $@); done
+install-strip: + $(MAKE) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" install + clean distclean mostlyclean maintainer-clean tags: set -e; for d in $(SUBDIRS); do \ echo "Making $@ in $$d" ; (cd $$d && $(MAKE) $@); done
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sun, 02 Oct 2016 10:22:04 +0200
Eli Zaretskii eliz@gnu.org writes:
And one more gripe: why doesn't Nettle have the standard 'install-strip' target in its Makefile?
TL;DR: I guess that's an oversight, I'd need sme advice to get it right.
I'm not an expert, but I will try to tell what I know.
What's the simplest way to to that? Is it enough to patch the top-level Makefile.in like below?
That's a start, although libraries need extra care, as you suspect.
And then exactly what is it that should be stripped? I see that the make targets for installing both shared and static libraries use $(INSTALL_DATA) rather than $(INSTALL_PROGRAM), so libraries won't be affected. Those targets are a decade old, but I think it followed GNU standards at the time.
When handling libraries, I imagine one need to be a little careful to use the right one of
strip strip -s strip --strip-debug strip --strip-unneded
Shared libraries need --strip-unneded, static libraries need --strip-debug followed by ranlib.
and I'm not sure which is implied by install -s.
It's a synonym for --strip-all, so it's only pertinent to executable programs.
Eli Zaretskii eliz@gnu.org writes:
When handling libraries, I imagine one need to be a little careful to use the right one of
strip strip -s strip --strip-debug strip --strip-unneded
Shared libraries need --strip-unneded, static libraries need --strip-debug followed by ranlib.
Makes sense. Are you saying that for static libraries, one has to redo ranlib after strip?
and I'm not sure which is implied by install -s.
It's a synonym for --strip-all, so it's only pertinent to executable programs.
And you're also saying that a "default strip", invoking strip without any options, is the same as strip --strip-all?
I wonder if one can persuade the install program to do the right thing. It should be straightforward to use separate variables INSTALL_STATIC_LIB and INSTALL_SHARED_LIB, to override in the install-strip target. But it seems overriding the strip command, e.g., to use strip --strip-unneeded, is going to be messy.
For install-sh, is one can set STRIPPROG="strip --strip-unneeded". For GNU /usr/bin/install, one can set STRIPPROG="strip --strip-unneeded" in the environment (untested, not sure if it is passed to the shell to split into command and arguments). But that won't work with BSD install. Checking on freebsd, it seems it checks an environment named STRIPBIN, (not sure if there's also a BSD strip not accepting GNU options; on my closest freebsd system, /usr/bin/strip is an ancient GNU binutils).
Since install-strip is an optional thing, I think I'd be happy to support only the most mainstream cases here.
The alternative to using install -s would be to produce additional files in the build directory, e.g., libnettle.a.stripped and install that. But having that done as part of make install-strip breaks the expectation that install targets shouldn't create or modify any files in the build tree, and producing them in make all doesn't seem quite right either.
A third alternative is to have the install-strip target do things like
$(INSTALL_DATA) libnettle.a $(DESTDIR)$(libdir) strip --strip-debug $(DESTDIR)$(libdir)/libnettle.a ranlib $(DESTDIR)$(libdir)/libnettle.a # Rebuild index
and use install -s *only* for (non-script) executables.
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sun, 02 Oct 2016 12:01:35 +0200
Shared libraries need --strip-unneded, static libraries need --strip-debug followed by ranlib.
Makes sense. Are you saying that for static libraries, one has to redo ranlib after strip?
That's what libtool does, but I don't really know if that's needed. maybe it's needed with non-GNU 'strip'?
and I'm not sure which is implied by install -s.
It's a synonym for --strip-all, so it's only pertinent to executable programs.
And you're also saying that a "default strip", invoking strip without any options, is the same as strip --strip-all?
Sounds like that, although the documentation doesn't seem to say that explicitly. FWIW, I always use just "strip", without any options, when I need to strip an executable.
Eli Zaretskii eliz@gnu.org writes:
- Eliminate most pointer-signedness warnings. In the process, the strings representing expression type for sexp_interator functions were changed from const uint8_t * to const char *. These functions are undocumented, and it doesn't change the ABI on any platform I'm aware of.
Building with MinGW on MS-Windows, I still see a few warnings of this kind, like the ones below:
I see these on gnu/linux too, that's why I wrote "most"...
I'm considering changing the type of the ascii inputs and outputs for ascii armoring functions to use plain char, but I didn't get to that for this release. A few of the functions also support in-place conversion, making it somewhat messy to use different types for input and output.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Eli Zaretskii -
nisse＠lysator.liu.se