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).
(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?
(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.
(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).
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
