Robert Relyea wrote:
> Hans de Goede wrote:
>> Nils Philippsen wrote:
>>> On Tue, 2008-08-26 at 08:39 +1000, Andrew Bartlett wrote:
>>>> On Mon, 2008-08-25 at 20:04 +0200, Hans de Goede wrote:
>>>>> Hi All,
>>>>>
>>>>> The story begins here:
>>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=446860
>>>>>
>>>>> The problem is, or I believe it to be, that when an application
>>>>> uses libgnutls-openssl (meant for easy use of porting openssl
>>>>> programs to gnutls) for example because of the openssl license
>>>>> issues, and then a library uses the real openssl (for example glibc
>>>>> through nss_ldap) then in the nss_ldap example, the layer
dlopen's
>>>>> nss_ldap starts using the openssl symbols from gnutls instead of
>>>>> those from openssl, but they are not ABI compatible -> boom.
>>>>>
>>>>> Luckily the list of libgnutls-openssl users seems small:
>>>>>
>>>>> [hans@localhost src]$ repoquery -q --whatrequires
>>>>> 'libgnutls-openssl.so.26()(64bit)'
>>>>> mcabber-0:0.9.7-1.fc10.x86_64
>>>>> gnutls-0:2.4.1-1.fc10.x86_64
>>>>> gnutls-devel-0:2.4.1-1.fc10.x86_64
>>>>> zoneminder-0:1.23.3-1.fc10.x86_64
>>>>> gkrellm-0:2.3.1-4.fc10.x86_64
>>>>>
>>>>> So only 3 programs are affected, given that the same may happen
>>>>> when any used library uses the real openssl and the application or
>>>>> any other library uses gnutls-openssl, I would like to suggest the
>>>>> removal of libgnutls-openssl from Fedora, as long as we have this
>>>>> openssl libraries mess (which we unfortunately do) we should make
>>>>> sure that the various ssl libraries do not have symbol clashes, as
>>>>> changes are that through a mix of libraries an application may be
>>>>> using 2 (or even 3) different ssl libs.
>>>>>
>>>>> So whats your 2 cents on this?
>>>> How does the NSS (Mozilla SSL) OpenSSL wrapper avoid this problem?
>>>
>>> Completely uninformed guess: by using macros or other techniques to add
>>> a prefix to the symbols that end up in the binary?
>>>
>>
>> I didn't know nss has an openssl compatibility sub lib too, I just
>> checked and it doesn't do any symbol magic, iow it has the same
>> problems as the gnutls openssl compatibility sublib.
> Some of the symbols are renamed, but not enough of them. I think
> nsscompatossl has not run into the problem because it hasn't had cases
> where it was linked with openssl apps.
I hate to bring you bad news, but as nss_ldap, which is a glibc plugin used on
any site which uses ldap, uses openssl any application can be linked to openssl
(through /etc/nssswitch.conf).
So we do have an issue here, it does seem we are lucky sofar (just as with
gnutls) because sofar only slrn seems to use libnss_compat_ossl.
Isn't this what symbol versions are meant to solve? (and has solved for
example having Heimdal and MIT kerberos on Debian, for many years).
Andrew Bartlett
--
Andrew Bartlett