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