[gnutls-devel] Symbol versioning in gnutls broken -> crashes

Yann Rouillard yann at pleiades.fr.eu.org
Sat May 24 23:15:38 CEST 2014


Hi,

Thanks for the information.

I think that direct binding should save us for this kind of nightmare, even
if symbol versioning was done wrong as it is the case here.

Yann



2014-05-24 11:46 GMT+02:00 Dagobert Michelsen <dam at opencsw.org>:

> Hi folks,
>
> Looks like other distros suffer the same pain /-)
>
> Best regards -- Dago
>
>
> Anfang der weitergeleiteten E‑Mail:
>
> *Von:* Andreas Metzler <ametzler at bebt.de>
> *Datum:* 24. Mai 2014 08:58:07 MESZ
> *An:* gnutls-devel at lists.gnutls.org
> *Betreff:* *[gnutls-devel] Symbol versioning in gnutls broken -> crashes*
>
> Hello,
>
> GnuTLS symbol versioning apparently does not fullfill its main
> purpose, to allow a binary to link against gnutls 2.x and gnutls 3.x
> without crashing.
>
> This is a pretty common screnario for distributions in a transition
> period, where you go from:
>
> scenario1
> application --depends_on--> libgnutls.so.26
>            `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.26
>
> to
>
> scenario2
> application --depends_on--> libgnutls.so.26
>            `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.28
>
> at some point of time, since you cannot switch the whole distro at one
> point. Especially for the GnuTLS transition, since this is not just a
> straight rebuild but involves checking the source's gcrypt related
> code.
>
> Usually symbol-versioning would cause any references to gnutls to be
> resolved to GnuTLS 2.x in both of the abovementioned cases, libbar's
> to GnuTLS 2.x or 3.x respectively. However e.g. gnutls_init() is
> versioned as @1.4 in both gnutls versions, therefore in scenario2
> application could also get gnutls_init() from GnuTLS 3.x.
>
> Another function where it is obvious this breaks is
> gnutls_priority_set_direct(), where 3.x accepts more priority strings.
>
> ------
>
> Anyway, this causes hard crashes like in
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746641#37> or
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748742#37>.
>
> Fixing this in gnutls' source is pretty easy: In gnutls.map move the
> contents of GNUTLS_1_4, GNUTLS_2_8, GNUTLS_2_10 and GNUTLS_2_12 to
> GNUTLS_3_0_0. However it breaks the ABI, everything linking against
> gnutls3 will need to be rebuilt after the change. Afaiu a soname bump
> would therefore be the correct thing.
>
> cu Andreas
>
> See also:
> <https://lists.debian.org/debian-release/2014/05/msg00262.html>
>
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20140524/4b3d5958/attachment.html>


More information about the maintainers mailing list