[gnutls-devel] Symbol versioning in gnutls broken -> crashes
Andreas Metzler
ametzler at bebt.de
Sat May 24 08:58:07 CEST 2014
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'
More information about the Gnutls-devel
mailing list