FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 08-25-2008, 06:04 PM
Hans de Goede
 
Default libgnutls-openssl and real openssl conflict

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?

Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-25-2008, 10:39 PM
Andrew Bartlett
 
Default libgnutls-openssl and real openssl conflict

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?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-25-2008, 10:49 PM
Nils Philippsen
 
Default libgnutls-openssl and real openssl conflict

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?

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 05:22 AM
Hans de Goede
 
Default libgnutls-openssl and real openssl conflict

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.


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 05:57 PM
Robert Relyea
 
Default libgnutls-openssl and real openssl conflict

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. Fortunately upstream for this is
pretty close to fedora, so I think this should be easy to fix.


bob


Regards,

Hans



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 06:31 PM
Hans de Goede
 
Default libgnutls-openssl and real openssl conflict

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 06:57 PM
Toshio Kuratomi
 
Default libgnutls-openssl and real openssl conflict

Hans de Goede wrote:


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!




+1

Especially since Fedora is supposed to drive adoption of nss and the nss
compat libs to aid in FIPS-140 compliance for downstream distros, this
problem will only get bigger.


-Toshio


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 10:30 PM
"David A. Wheeler"
 
Default libgnutls-openssl and real openssl conflict

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
...
> > I would like to suggest the removal of libgnutls-openssl from
> > Fedora,...

That will probably create many legal problems.
If there's a way to keep this package, we should.

As many of you know, the basic problem is that the OpenSSL license
is incompatible with the GPL:
http://www.fsf.org/licensing/licenses/
http://www.gnome.org/~markmc/openssl-and-the-gpl.html
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg426067.html
http://lists.debian.org/debian-legal/2002/10/msg00113.html

Any program that links to libgnutls-openssl that has GPL'ed components
probably CANNOT be legally linked to OpenSSL.

--- David A. Wheeler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 10:41 PM
"Tom "spot" Callaway"
 
Default libgnutls-openssl and real openssl conflict

On Tue, 2008-08-26 at 18:30 -0400, David A. Wheeler wrote:
> Any program that links to libgnutls-openssl that has GPL'ed components
> probably CANNOT be legally linked to OpenSSL.

For what it is worth, we consider OpenSSL a system library (aka, a
"major component"), as does the FSF.

>From GPLv2:

However, as a special exception, the source code distributed need not
include
anything that is normally distributed (in either source or binary form) with the
major components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies the
executable.

Thus, we're not concerned about OpenSSL and GPL incompatibility.

~spot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-26-2008, 11:34 PM
Andrew Bartlett
 
Default 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.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 11:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org