On 2020-04-12 Niels Möller <[email protected]> wrote:
> Andreas Metzler <[email protected]> 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

> 1. 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". :-(

> 2. 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.)
00000000001d3a58 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3a60 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3ab0 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3ab8 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3b78 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3b80 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3bd0 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3bd8 R_X86_64_64       _nettle_ecc_mod@HOGWEED_INTERNAL_5_0
00000000001d3a68 R_X86_64_64       _nettle_ecc_mod_inv@HOGWEED_INTERNAL_5_0
00000000001d3ac0 R_X86_64_64       _nettle_ecc_mod_inv@HOGWEED_INTERNAL_5_0
00000000001d3b88 R_X86_64_64       _nettle_ecc_mod_inv@HOGWEED_INTERNAL_5_0
00000000001d3be0 R_X86_64_64       _nettle_ecc_mod_inv@HOGWEED_INTERNAL_5_0
00000000001d3ae0 R_X86_64_64       _nettle_ecc_add_jjj@HOGWEED_INTERNAL_5_0
00000000001d3c00 R_X86_64_64       _nettle_ecc_add_jjj@HOGWEED_INTERNAL_5_0
00000000001d3ae8 R_X86_64_64       _nettle_ecc_mul_a@HOGWEED_INTERNAL_5_0
00000000001d3c08 R_X86_64_64       _nettle_ecc_mul_a@HOGWEED_INTERNAL_5_0
00000000001d3af0 R_X86_64_64       _nettle_ecc_mul_g@HOGWEED_INTERNAL_5_0
00000000001d3c10 R_X86_64_64       _nettle_ecc_mul_g@HOGWEED_INTERNAL_5_0
00000000001d3af8 R_X86_64_64       _nettle_ecc_j_to_a@HOGWEED_INTERNAL_5_0
00000000001d3c18 R_X86_64_64       _nettle_ecc_j_to_a@HOGWEED_INTERNAL_5_0
00000000001d4328 R_X86_64_JUMP_SLOT  
_nettle_mpn_set_base256_le@HOGWEED_INTERNAL_5_0
00000000001d4668 R_X86_64_JUMP_SLOT  _nettle_write_le64@NETTLE_INTERNAL_7_0
00000000001d4698 R_X86_64_JUMP_SLOT  _nettle_write_le32@NETTLE_INTERNAL_7_0
00000000001d48f8 R_X86_64_JUMP_SLOT  _nettle_poly1305_block@NETTLE_INTERNAL_7_0
00000000001d4940 R_X86_64_JUMP_SLOT  _nettle_gmp_free_limbs@HOGWEED_INTERNAL_5_0
00000000001d4a88 R_X86_64_JUMP_SLOT  _nettle_ecc_mod_mul@HOGWEED_INTERNAL_5_0
00000000001d4d68 R_X86_64_JUMP_SLOT  _nettle_cnd_copy@HOGWEED_INTERNAL_5_0
00000000001d4e90 R_X86_64_JUMP_SLOT  
_nettle_gmp_alloc_limbs@HOGWEED_INTERNAL_5_0
00000000001d5690 R_X86_64_JUMP_SLOT  _nettle_mpz_limbs_copy@HOGWEED_INTERNAL_5_0
00000000001d5958 R_X86_64_JUMP_SLOT  _nettle_ecc_mod_random@HOGWEED_INTERNAL_5_0
00000000001d5a40 R_X86_64_JUMP_SLOT  _nettle_ecc_mod_add@HOGWEED_INTERNAL_5_0
00000000001d5b40 R_X86_64_JUMP_SLOT  
_nettle_mpn_get_base256_le@HOGWEED_INTERNAL_5_0
00000000001bf310 R_X86_64_JUMP_SLOT  
_nettle_gmp_alloc_limbs@HOGWEED_INTERNAL_6_0
00000000001bfb48 R_X86_64_JUMP_SLOT  
_nettle_mpn_get_base256_le@HOGWEED_INTERNAL_6_0
00000000001c0450 R_X86_64_JUMP_SLOT  _nettle_gmp_free_limbs@HOGWEED_INTERNAL_6_0
00000000001c0680 R_X86_64_JUMP_SLOT  
_nettle_mpn_set_base256_le@HOGWEED_INTERNAL_6_0
00000000001c0840 R_X86_64_JUMP_SLOT  _nettle_write_le32@NETTLE_INTERNAL_8_0
00000000001c0bb0 R_X86_64_JUMP_SLOT  _nettle_ecc_mod_mul@HOGWEED_INTERNAL_6_0
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to