nettle: update to 3.4.
NEWS for the Nettle 3.4 release
This release fixes bugs and adds a few new features. It also
addresses an ABI compatibility issue affecting Nettle-3.1 and
later, see below.
Bug fixes:
* Fixed an improper use of GMP mpn_mul, breaking curve2559 and
eddsa on certain platforms. Reported by Sergei Trofimovich.
* Fixed memory leak when handling invalid signatures in
ecdsa_verify. Fix contributed by Nikos Mavrogiannopoulos.
* Fix compilation error with --enable-fat om ARM. Fix
contributed by Andreas Schneider.
* Reorganized the way certain data items are made available.
Short version: Nettle header files now define the symbols
nettle_hashes, nettle_ciphers, and nettle_aeads, as
preprocessor macros invoking a corresponding accessor
function. For backwards ABI compatibility, the symbols are
still present in the compiled libraries, and with the same
sizes as in nettle-3.3.
New features:
* Support for RSA-PSS signatures, contributed by Daiki Ueno.
* Support for the HKDF key derivation function, defined by RFC
5869. Contributed by Nikos Mavrogiannopoulos.
* Support for the Cipher Feedback Mode (CFB), contributed by
Dmitry Eremin-Solenikov.
* New accessor functions: nettle_get_hashes,
nettle_get_ciphers, nettle_get_aeads, nettle_get_secp_192r1,
nettle_get_secp_224r1, nettle_get_secp_256r1,
nettle_get_secp_384r1, nettle_get_secp_521r1.
For source-level compatibility with future versions,
applications are encouraged to migrate to using these
functions instead of referring to the corresponding data
items directly.
Miscellaneous:
* The base16 and base64 functions now use the type char * for
ascii data, rather than uint8_t *. This eliminates the last
pointer-signedness warnings when building Nettle. This is a
minor API change, and applications may need to be adjusted,
but the ABI is unaffected on all platforms I'm aware of.
* The contents of the header file nettle/version.h is now
architecture independent, except in --enable-mini-gmp
configurations.
ABI issue:
Since the breakage was a bit subtle, let me document it
here. The nettle and hogweed libraries export a couple of
data symbols, and for some of these, the size was never
intended to be part of the ABI. E.g.,
extern const struct nettle_hash * const nettle_hashes[];
which is an NULL-terminated array.
It turns out the sizes nevertheless may leak into the ABI, and
that increasing the sizes can break old executables linked
with a newer version of the library.
When linking a classic non-PIE executable with a shared
library, we get ELF relocations of type R_X86_64_COPY for
references to data items. These mean that the linker allocates
space for the data item in the data segment of executable, at
a fixed address determined at link-time, and with size
extracted from the version of the .so-file seen when linking.
At load time, the run time linker then copies the contents of
the symbol from the .so file to that location, and uses the
copy instead of the version loaded with the .so-file. And if
the data item in the .so file used at load time is larger than
the data item seen at link time, it is silently truncated in
the process.
So when SHA3 hashes were was added to the nettle_hashes array
in the nettle-3.3 release, this way of linking produces a
truncated array at load time, no longer NULL-terminated.
We will get similar problems for planned extensions of the
internal struct ecc_curve, and exported data items like
extern const struct ecc_curve nettle_secp_256r1;
where the ecc_curve struct is only forward declared in the
public headers. To prepare, applications should migrate to
using the new function nettle_get_secp_256r1, and similarly
for the other curves.
In some future version, the plan is to add a leading
underscore to the name of the actual data items. E.g.,
nettle_hashes --> _nettle_hashes, breaking the ABI, while
keeping the nettle_get_hashes function and the nettle_hashes
macro as the supported ways to access it. We will also
rename nettle_secp_256r1 --> _nettle_secp_256r1, breaking
both ABI and API.
Note that data items like nettle_sha256 are *not* affected,
since the size and layout of this struct is considered part
of the ABI, and R_X86_64_COPY-relocations then work fine.
2017-11-28 15:06:12 +01:00
|
|
|
$NetBSD: distinfo,v 1.16 2017/11/28 14:06:12 wiz Exp $
|
Nettle is a cryptographic library that is designed to fit easily in more
or less any context: In crypto toolkits for object-oriented languages
(C++, Python, Pike, ...), in applications like LSH or GNUPG, or even in
kernel space. In most contexts, you need more than the basic
cryptographic algorithms, you also need some way to keep track of available
algorithms, their properties and variants. You often have some algorithm
selection process, often dictated by a protocol you want to implement.
And as the requirements of applications differ in subtle and not so
subtle ways, an API that fits one application well can be a pain to use
in a different context. And that is why there are so many different
cryptographic libraries around.
Nettle tries to avoid this problem by doing one thing, the low-level
crypto stuff, and providing a simple but general interface to it.
In particular, Nettle doesn't do algorithm selection. It doesn't do
memory allocation. It doesn't do any I/O.
The idea is that one can build several application and context specific
interfaces on top of Nettle, and share the code, test cases, benchmarks,
documentation, etc. Examples are the Nettle module for the Pike
language, and LSH, which both use an object-oriented abstraction on top
of the library.
2011-04-26 10:59:33 +02:00
|
|
|
|
nettle: update to 3.4.
NEWS for the Nettle 3.4 release
This release fixes bugs and adds a few new features. It also
addresses an ABI compatibility issue affecting Nettle-3.1 and
later, see below.
Bug fixes:
* Fixed an improper use of GMP mpn_mul, breaking curve2559 and
eddsa on certain platforms. Reported by Sergei Trofimovich.
* Fixed memory leak when handling invalid signatures in
ecdsa_verify. Fix contributed by Nikos Mavrogiannopoulos.
* Fix compilation error with --enable-fat om ARM. Fix
contributed by Andreas Schneider.
* Reorganized the way certain data items are made available.
Short version: Nettle header files now define the symbols
nettle_hashes, nettle_ciphers, and nettle_aeads, as
preprocessor macros invoking a corresponding accessor
function. For backwards ABI compatibility, the symbols are
still present in the compiled libraries, and with the same
sizes as in nettle-3.3.
New features:
* Support for RSA-PSS signatures, contributed by Daiki Ueno.
* Support for the HKDF key derivation function, defined by RFC
5869. Contributed by Nikos Mavrogiannopoulos.
* Support for the Cipher Feedback Mode (CFB), contributed by
Dmitry Eremin-Solenikov.
* New accessor functions: nettle_get_hashes,
nettle_get_ciphers, nettle_get_aeads, nettle_get_secp_192r1,
nettle_get_secp_224r1, nettle_get_secp_256r1,
nettle_get_secp_384r1, nettle_get_secp_521r1.
For source-level compatibility with future versions,
applications are encouraged to migrate to using these
functions instead of referring to the corresponding data
items directly.
Miscellaneous:
* The base16 and base64 functions now use the type char * for
ascii data, rather than uint8_t *. This eliminates the last
pointer-signedness warnings when building Nettle. This is a
minor API change, and applications may need to be adjusted,
but the ABI is unaffected on all platforms I'm aware of.
* The contents of the header file nettle/version.h is now
architecture independent, except in --enable-mini-gmp
configurations.
ABI issue:
Since the breakage was a bit subtle, let me document it
here. The nettle and hogweed libraries export a couple of
data symbols, and for some of these, the size was never
intended to be part of the ABI. E.g.,
extern const struct nettle_hash * const nettle_hashes[];
which is an NULL-terminated array.
It turns out the sizes nevertheless may leak into the ABI, and
that increasing the sizes can break old executables linked
with a newer version of the library.
When linking a classic non-PIE executable with a shared
library, we get ELF relocations of type R_X86_64_COPY for
references to data items. These mean that the linker allocates
space for the data item in the data segment of executable, at
a fixed address determined at link-time, and with size
extracted from the version of the .so-file seen when linking.
At load time, the run time linker then copies the contents of
the symbol from the .so file to that location, and uses the
copy instead of the version loaded with the .so-file. And if
the data item in the .so file used at load time is larger than
the data item seen at link time, it is silently truncated in
the process.
So when SHA3 hashes were was added to the nettle_hashes array
in the nettle-3.3 release, this way of linking produces a
truncated array at load time, no longer NULL-terminated.
We will get similar problems for planned extensions of the
internal struct ecc_curve, and exported data items like
extern const struct ecc_curve nettle_secp_256r1;
where the ecc_curve struct is only forward declared in the
public headers. To prepare, applications should migrate to
using the new function nettle_get_secp_256r1, and similarly
for the other curves.
In some future version, the plan is to add a leading
underscore to the name of the actual data items. E.g.,
nettle_hashes --> _nettle_hashes, breaking the ABI, while
keeping the nettle_get_hashes function and the nettle_hashes
macro as the supported ways to access it. We will also
rename nettle_secp_256r1 --> _nettle_secp_256r1, breaking
both ABI and API.
Note that data items like nettle_sha256 are *not* affected,
since the size and layout of this struct is considered part
of the ABI, and R_X86_64_COPY-relocations then work fine.
2017-11-28 15:06:12 +01:00
|
|
|
SHA1 (nettle-3.4.tar.gz) = f3c8495b7c43cba9cdd19503e7567095c680b490
|
|
|
|
|
RMD160 (nettle-3.4.tar.gz) = 56c59906e4bec5c0859abdd96645d5d54a8f78c4
|
|
|
|
|
SHA512 (nettle-3.4.tar.gz) = 3bea3aabd2c99cc42d084a94fd6b0b5dbdb24cd6c7020271a6ee87a81a904b21b21756f590cb1afdf2e85fd1cb59e5c3651c5c4032e30204e7ea6f8801d1ea3b
|
|
|
|
|
Size (nettle-3.4.tar.gz) = 1935069 bytes
|
Update to 3.1.1, now that gnutls is fixed to build with it.
NEWS for the Nettle 3.1.1 release
This release fixes a couple of non-critical bugs.
Bug fixes:
* By accident, nettle-3.1 disabled the assembly code for the
secp_224r1 and secp_521r1 elliptic curves on all x86_64
configurations, making signature operations on those curves
10%-30% slower. This code is now re-enabled.
* The x86_64 assembly implementation of gcm hashing has been
fixed to work with the Sun/Oracle assembler.
The shared library names are libnettle.so.6.1 and
libhogweed.so.4.1, with sonames still libnettle.so.6 and
libhogweed.so.4. It is intended to be fully binary compatible
with nettle-3.1.
NEWS for the Nettle 3.1 release
This release adds a couple of new features.
The library is mostly source-level compatible with nettle-3.0.
It is however not binary compatible, due to the introduction
of versioned symbols, and extensions to the base64 context
structs. The shared library names are libnettle.so.6.0 and
libhogweed.so.4.0, with sonames libnettle.so.6 and
libhogweed.so.4.
Bug fixes:
* Fixed a missing include of <limits.h>, which made the
camellia implementation fail on all 64-bit non-x86
platforms.
* Eliminate out-of-bounds reads in the C implementation of
memxor (related to valgrind's --partial-loads-ok flag).
Interface changes:
* Declarations of many internal functions are moved from ecc.h
to ecc-internal.h. The functions are undocumented, and
luckily they're apparently also unused by applications, so I
don't expect any problems from this change.
New features:
* Support for curve25519 and for EdDSA25519 signatures.
* Support for "fat builds" on x86_64 and arm, where the
implementation of certain functions is selected at run-time
depending on available cpu features. Configure with
--enable-fat to try this out. If it turns out to work well
enough, it will likely be enabled by default in later
releases.
* Support for building the hogweed library (public key
support) using "mini-gmp", a small but slower implementation
of a subset of the GMP interfaces. Note that builds using
mini-gmp are *not* binary compatible with regular builds,
and more likely to leak side-channel information.
One intended use-case is for small embedded applications
which need to verify digital signatures.
* The shared libraries are now built with versioned symbols.
Should reduce problems in case a program links explicitly to
nettle and/or hogweed, and to gnutls, and the program and
gnutls expect different versions.
* Support for "URL-safe" base64 encoding and decoding, as
specified in RFC 4648. Contributed by Amos Jeffries.
Optimizations:
* New x86_64 implementation of AES, using the "aesni"
instructions. Autodetected in fat builds. In non-fat builds,
it has to be enabled explicitly with --enable-x86-aesni.
Build system:
* Use the same object files for both static and shared
libraries. This eliminates the *.po object files which were
confusing to some tools (as well as humans). Like before,
PIC code is used by default; to build a non-pic static
library, configure with --disable-pic --disable-shared.
Miscellaneous:
* Made type-checking hack in CBC_ENCRYPT and similar macros
stricter, to generate warnings if they are used with
functions which have a length argument smaller than size_t.
2015-08-23 16:22:10 +02:00
|
|
|
SHA1 (patch-Makefile.in) = 96771c1fb195603d108717970eb32767d2c26799
|
2013-11-26 10:22:19 +01:00
|
|
|
SHA1 (patch-aa) = 2332668b077a6e3a1add603c87f60167755554ec
|
Update to 3.1.1, now that gnutls is fixed to build with it.
NEWS for the Nettle 3.1.1 release
This release fixes a couple of non-critical bugs.
Bug fixes:
* By accident, nettle-3.1 disabled the assembly code for the
secp_224r1 and secp_521r1 elliptic curves on all x86_64
configurations, making signature operations on those curves
10%-30% slower. This code is now re-enabled.
* The x86_64 assembly implementation of gcm hashing has been
fixed to work with the Sun/Oracle assembler.
The shared library names are libnettle.so.6.1 and
libhogweed.so.4.1, with sonames still libnettle.so.6 and
libhogweed.so.4. It is intended to be fully binary compatible
with nettle-3.1.
NEWS for the Nettle 3.1 release
This release adds a couple of new features.
The library is mostly source-level compatible with nettle-3.0.
It is however not binary compatible, due to the introduction
of versioned symbols, and extensions to the base64 context
structs. The shared library names are libnettle.so.6.0 and
libhogweed.so.4.0, with sonames libnettle.so.6 and
libhogweed.so.4.
Bug fixes:
* Fixed a missing include of <limits.h>, which made the
camellia implementation fail on all 64-bit non-x86
platforms.
* Eliminate out-of-bounds reads in the C implementation of
memxor (related to valgrind's --partial-loads-ok flag).
Interface changes:
* Declarations of many internal functions are moved from ecc.h
to ecc-internal.h. The functions are undocumented, and
luckily they're apparently also unused by applications, so I
don't expect any problems from this change.
New features:
* Support for curve25519 and for EdDSA25519 signatures.
* Support for "fat builds" on x86_64 and arm, where the
implementation of certain functions is selected at run-time
depending on available cpu features. Configure with
--enable-fat to try this out. If it turns out to work well
enough, it will likely be enabled by default in later
releases.
* Support for building the hogweed library (public key
support) using "mini-gmp", a small but slower implementation
of a subset of the GMP interfaces. Note that builds using
mini-gmp are *not* binary compatible with regular builds,
and more likely to leak side-channel information.
One intended use-case is for small embedded applications
which need to verify digital signatures.
* The shared libraries are now built with versioned symbols.
Should reduce problems in case a program links explicitly to
nettle and/or hogweed, and to gnutls, and the program and
gnutls expect different versions.
* Support for "URL-safe" base64 encoding and decoding, as
specified in RFC 4648. Contributed by Amos Jeffries.
Optimizations:
* New x86_64 implementation of AES, using the "aesni"
instructions. Autodetected in fat builds. In non-fat builds,
it has to be enabled explicitly with --enable-x86-aesni.
Build system:
* Use the same object files for both static and shared
libraries. This eliminates the *.po object files which were
confusing to some tools (as well as humans). Like before,
PIC code is used by default; to build a non-pic static
library, configure with --disable-pic --disable-shared.
Miscellaneous:
* Made type-checking hack in CBC_ENCRYPT and similar macros
stricter, to generate warnings if they are used with
functions which have a length argument smaller than size_t.
2015-08-23 16:22:10 +02:00
|
|
|
SHA1 (patch-config.make.in) = 708fb3cac9c44825e0d231541cbecade2239c850
|
|
|
|
|
SHA1 (patch-testsuite_Makefile.in) = 98db291808e0db7c7ec1e64facf56a956b226bc1
|
|
|
|
|
SHA1 (patch-tools_Makefile.in) = 743d09935526cb783fe93ffc417c4153e13dcfac
|
