[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: libgnutls-openssl and real openssl conflict



On Tue, 2008-08-26 at 20:31 +0200, Hans de Goede wrote:
> 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
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]