Subject: Re: userland incompatibilities
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-userlevel
Date: 05/19/2006 15:04:01
On Fri, May 19, 2006 at 09:47:06AM -0700, Garrett D'Amore wrote:
> I had recently been cross-building a proprietary application using a
> version of headers and libraries dated from November and March.   One of
> the libraries that this application uses is OpenSSL.  (libcrypto in
> particular.)
> 
> When taking my application to a recent -current system, I find that it
> won't run due to "Shared object "libcrypto.so.2" not found"

Indeed.  This can't be helped -- the OpenSSL developers seem to go out
of their way to change user-visible structures, often in a pervasive
way, in even teeny releases of their library.  Some operating systems
then don't bump the shlib major number -- but that is wrong.  For
example, the formats of SSL contexts and of key data often change
between teeny versions of OpenSSL, even versions that supposedly only
fix security problems that have nothing to do with the datastructures
in question.

Some vendors don't change the libssl and libcrypto major numbers even
when there are incompatible changes of this kind.  That causes, of
course, the applications linked to the library to fail, sometimes
silently.  I don't think that's what you want a cryptographic application
to do.

If your application is linked to libcrypto.so.2, you need to provide
it with libcrypto.so.2, or rebuild whatever part of it has that
dependency.  You can get an appropriate libcrypto from an older
version of NetBSD.

FWIW, Sun is to be lauded for the lengths to which they go in maintaining
private changes to OpenSSL to mitigate this problem.  A Sun engineer
posted part of them to one of the OpenSSL development lists several
years ago after a particularly egregious API change bundled together
with a major security fix in, IIRC, OpeNSSL 0.95[some letter].  It was
many thousands of lines of code, versioning (by renaming) hundreds of
symbols.  Unfortunately, we don't have the manpower to do that every
time the OpenSSL project screws up this way, which is, unfortunately,
quite often.  So we do what we must, which is to bump the shared lib
major number so that if you want the old version, you have to provide
it explicitly.  In in imperfect world, that's about the only option
we have available.

Thor