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

Andreas Metzler ametzler at bebt.de
Sat May 24 08:58:07 CEST 2014


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:

application --depends_on--> libgnutls.so.26
            `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.26

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

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

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:

`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