Can we at least post this somewhere visibly, along with recommendations
to ISVs on how to work around this particular problem?  (Such as by
linking statically against OpenSSL or somesuch.)

So much of the rest of the system "just works" that its a shame to take
the blame for OpenSSL for what is really just OpenSSL brain-damage.

Of course, OpenSSL has never even claimed to be 1.0, so maybe that is a
strong clue as well. :-)

    -- Garrett

Thor Lancelot Simon wrote:
> 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
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191