libgnutls-openssl and real openssl conflict

[Andrew Bartlett]

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 at 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?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080826/8bcfb3e2/attachment.sig>