[Pkg-openssl-devel] Re: Packages which may need new uploads after versioned libssl0.9.8

[Steve Langasek]

On Sat, Oct 15, 2005 at 04:30:28PM -0400, Nathanael Nerode wrote:
> kurt at roeckx.be wrote:
> > Please note that libssl0.9.7 and libssl0.9.8 have a different
> > SONAME.  There can only be a problem when a program (indirectly)
> > links to both of them.  In that case, there isn't even an option
> > not to install both of them.

> > If a program is linked to both of them, and it was not linked to
> > a lib with versioned symbols, there really isn't much you can
> > tell about which symbols it's going to pick.
> Right.  Thanks for being clearer than me.  

> Consider the fate of a binary built against libssl0.9.8 with unversioned 
> symbols, once libssl0.9.8 with versioned symbols is installed.  Suppose also 
> that libssl0.9.7 -- with unversioned symbols -- is indirectly linked in (very 
> likely in complicated situations like KDE, and because libssl may be 
> dlopened).

> The dynamic linker will resolve the unversioned symbols from the binary -- 
> supposed to be, at least in some cases, libssl0.9.8 symbols -- to the 
> unversioned symbols it finds, namely, the ones in libssl0.9.7.  This is bad 
> if the ABI has actually changed between 0.9.7 and 0.9.8, as it will lead to 
> tricky-to-track-down bugs at runtime.

This is true, but building against a symbol-versioned libssl0.9.8, without
also rebuilding old packages against a symbol-versioned libssl0.9.7, only
helps when both libssl0.9.7 and libssl0.9.8 are loaded into memory and
libssl0.9.7 is *before* libssl0.9.8 in the search path.  If libssl0.9.8 is
loaded first, then when the 0.9.7-linked code tries to look up symbols it
will get the 0.9.8 symbols for any symbols that are common to both versions
and the 0.9.7 symbols for any symbols that are specific to 0.9.7.  This will
be the most likely source of segfaults and other failures... and is
especially an issue with libssl and libcrypto, because both libraries carry
a lot of global state that won't be shared properly between the two
versions.

So there's no point in fretting over packages linked against an unversioned
libssl0.9.8 if it's not clear that linking them to a versioned libssl0.9.8
would improve matters.

> It would be best, therefore, if nothing were built against libssl0.9.8 until 
> the libssl0.9.8 with versioned symbols is available

It might be best, but that's not going to happen; the only libssl-dev in
unstable right now is the 0.9.8 one, and there's too much that links against
libssl to put a moratorium on related uploads (at least, effectively...)  We
should focus on getting libssl0.9.8 built with symbols first, and afterwards
we can regroup and see about fixing binaries for any packages where there's
a definite need for building against the symbol-versioned lib.

On Sat, Oct 15, 2005 at 04:07:54PM -0400, Nathanael Nerode wrote:
> The following packages appear to have been built against openssl 0.9.8
> without versioned symbols, and libraries or programs from them will
> accordingly misbehave if libssl0.9.7 ever ends up linked into the same
> program as one of them:

Hmm, a list of binary packages would probably be more useful for purposes of
checking out what warrants a rebuild.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20051015/bcc2db73/attachment-0001.pgp