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.
Regards,
Hans