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)
So, you either bump libgnutls soname too (and you must rebuild all apps to take advantage of it) [also it triggers same problem with libraries that uses libgnutls], or you add Conflict/Breaks in libnettle2 (and you must rebuild all libraries and apps to be able to even install libnettle2).
No, if app is built against nettle all you need to do is bump nettle's so name and rebuild gnutls, the app will have to be rebuilt against the new nettle only as gnutls completely masks nettle behind it's apis and offers a stable ABI even when nettle ABI changes.
(And both renders new libnettle unusable for stable-backports.)
Yes, backports may be an issue, but nettle broke the ABI previously, and it offers no ABI guarntee.
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?
This is not possible with Nettle as it uses explicit structures exported to the caller, to have a stable ABI nettle would need to change how it deals with context structures by allocating them on the heap and making them opaque. I do not see this happening.
(poly1305 is not only algo that may require altering context structure for optimized implementation [e.g. bitsliced or vectorized aes]).
E.g. openssl made all structures opaque, and I believe it is correct long-term solution.
Openssl is a higher level library. We can discuss a wrapper library around nettle that offers a stable API/ABI and could be used by GnuTLS perhaps.
(Well, I've thought about a way, although not very nice: keep old version internally, add separate {chacha,aes}_poly1305_encrypt_v2, #define $foo $foo_v2 in headers; you'll need to rebuild all directly dependent libraries and apps to take advantage of new implementation, but not necessarily whole system; also it is not 146% safe [lib$a built against old version, lib$b built against new version, lib$a allocates struct chacha20_poly13_ctx and passes pointer to lib$b; libb calls $foo_v2, BOOM], but I doubt anyone uses libnettle this way in practice).
Yes, as you described this method is broken, you would have to have explicit different APIs or introduce symbol versioning.
Simo.