On 2020-04-12 Niels Möller nisse@lysator.liu.se wrote:
Andreas Metzler ametzler@bebt.de writes:
According to objdump -R GnuTLS uses internal symbols of both libhogweed and libnettle (e.g. _nettle_mpn_set_base256_le@HOGWEED_INTERNAL_5_0 and _nettle_write_le64@NETTLE_INTERNAL_7_0). These nettle *internal* symbols seem to be incompatible in 3.6, at least they are versioned differently (@NETTLE_INTERNAL_7_1).
Can you post a complete list of the references to internal symbols?
Hello Niels,
I am attaching
objdump -R path/to/so | grep INTERNAL
for x86_64-linux-gnu gnutls builds against nettle 3.5 and 3.6 (the latter patched to bump nettle soname, too). I am not an expert in this area - I think this generates the correct list.
Having non-working gnutls is quite a big issue, since e.g. apt depends on it.
Indeed. What options do we have? The ones I see are
- Simply bump the soname of libnettle too. I think that's ok in this case, since there are no major fixes or improvements to old features in this release. But I wouldn't want to make it a habit.
I agree that this "less than optimal". :-(
- Fix GnuTLS to not refer to internal libnettle symbols. Mark the nettle-3.6 package including libnettle.so.7 as conflicting with the non-fixed GnuTLS package.
I don't know how practical option (2) is. But for the example of nettle_write_le64, it would be a simple improvement to just include a copy in GnuTLS if it needs it. The nettle implementation is not particularly clever, and it's not intended to be part of the ABI. E.g, one todo item is to replace it with a macro expanding to memcpy, on platforms that are natively little-endian, in which case the symbol would simply disappear from the library.
I do not know either how feasible this is but the current situation, where GnuTLS relies on functions not part of the API, that could break anytime *IMHO* is not feasible either. [1]
In the medium term nettle might start enforcing saner usage by not exporting *INTERNAL* in libraries shipped in "make install"
cu Andreas
[1] (The current trigger, changing LIBNETTLE_MINOR which in turn breaks the ABI could be undone, if the affected internal symbols were compatible. But this does not solve the deeper problem.)