On Sun, 2019-03-17 at 12:56 +0300, Yuriy M. Kaminskiy wrote:
On 14.03.2019 00:31, Simo Sorce wrote:
On Thu, 2019-03-14 at 00:25 +0300, Yuriy M. Kaminskiy wrote:
On 12.03.2019 15:02, Yuriy M. Kaminskiy wrote: And it is embedded in struct chacha_poly1305_ctx and poly1305_aes_ctx, which looks like part of public (and used) low-level ABI.
(nettle-meta.h interface would be safe wrt struct size changes, but so far everything I've looked at - including gnutls - was not using it :-()
FWIW, I wouldn't feel blocked by an ABI break in Nettle.
Breaking ABI in the library that is used in another libraries is always problematic.
Scenario: $app links to libgnutls.so.1 and libnettle.so.1 (and libgnutls.so.1 linked against libnettle.so.1; then libnettle.so.2 installed and libgnutls.so.1 rebuilt against new nettle; what will happen with $app?
(Especially since nettle does not use versioned symbols)
Hi, Actually it does (see libnettle.map.in and libhogweed.map.in), and they were added (recently) mainly for the scenario you describe above. That is, the versioned symbols name contain to soname and thus any previous or newer version of the library don't conflict.
(And both renders new libnettle unusable for stable-backports.)
When you are forced to break ABI, it is good point to think: can it be avoided, and how can this be prevented in the future?
The nature of nettle (very low-level with structures exposed) brings often the need for abi breakage. The approach gnutls follows is to keep the gnutls abi stable and expose crypto algorithms in a more high level and stable ABI for applications to use. On certain cases it also overrides nettle code with Andy Polyakov's assembly implementation (e.g., aes-gcm on aarch64 and x86-64) for performance.
Having all crypto in nettle and optimized would be the ideal scenario for gnutls.
regards, Nikos