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.
Still we need to tackle this before it does become a bigger problem, sofar I've
seen very little attention for this thread, which is sad as this is a *real*
issue. So far only gkrellm seems to have been used by people who also use
nss_ldap, but sooner or later slrn or one of the others will hit the same
problem, and if more and more apps are moved to these openssl compat libs then
the problem becomes really large!
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
