Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Sun, Jul 13, 2014 at 08:36:30PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Mike Hommey:
> > Well, it kind of is. Because those versioned symbols in openssl come
> > from a debian patch, afaict. So while debian may be fine (as long as all
> > build-rdeps have been rebuilt since openssl got those versioned
> > symbols), other distros aren't covered, as well as binaries not
> > compiled on debian.
> >
> I am, frankly, not at all concerned with binaries not compiled on Debian
> at this point. Data point: Fedora uses a different symbol versioning
> scheme for openssl, so openssl-linked binaries from there won't run on
> Debian anyway.
>
> It's far more imperative to educate upstream (in general, not just openssl
> - but them in particular) about the fact that adding versioning to their
> libraries is a Very Good Idea which will save them (and, more to the point,
> anybody using their code) a whole lot of hassle - as well as potential
> security holes - if/when their ABI changes.
I plan to try and get them to use symbol versioning, at least on
those platforms that support it. This will probably be just like
the patch currently in Debian. I don't plan to add multiple
versions of a symbol to try and keep the same soname since that
probably won't work on all platforms.
We also plan to reduce the risk of breaking the ABI. Now a lot of
structs are public and we would like to make them private and
provide functions for those things that people want to access.
This will all probably take some time.
PS: If you use dlopen()/dlsym() to load functions, symbol
versioning doesn't help unless you use dlvsym() which is a
glibc extension.
Kurt
Reply to: