Fix some pkglint while here.
NEWS for the Nettle 3.2 release
Bug fixes:
* The SHA3 implementation is updated according to the FIPS 202
standard. It is not interoperable with earlier versions of
Nettle. Thanks to Nikos Mavrogiannopoulos. To easily
differentiate at compile time, sha3.h defines the constant
NETTLE_SHA3_FIPS202.
* Fix corner-case carry propagation bugs affecting elliptic
curve operations on the curves secp_256r1 and secp_384r1 on
certain platforms, including x86_64. Reported by Hanno Böck.
New features:
* New functions for RSA private key operations, identified by
the "_tr" suffix, with better resistance to side channel
attacks and to hardware or software failures which could
break the CRT optimization. See the Nettle manual for
details. Initial patch by Nikos Mavrogiannopoulos.
* New functions nettle_version_major, nettle_version_minor, as
a run-time variant of the compile-time constants
NETTLE_VERSION_MAJOR and NETTLE_VERSION_MINOR.
Optimizations:
* New ARM Neon implementation of the chacha stream cipher.
Miscellaneous:
* ABI detection on mips, with improved default libdir
location. Contributed by Klaus Ziegler.
* Fixes for ARM assembly syntax, to work better with the clang
assembler. Thanks to Jukka Ukkonen.
* Disabled use of ifunc relocations for fat builds, to fix
problems most easily triggered by using dlopen RTLD_NOW.
The shared library names are libnettle.so.6.2 and
libhogweed.so.4.2, with sonames still libnettle.so.6 and
libhogweed.so.4. It is intended to be fully binary compatible
with nettle-3.1.
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.
