[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 15 Mar 2004 16:40:45 -0500
From: Nalin Dahyabhai <nalin@...hat.com>
To: xvendor@...ts.openwall.com
Subject: Re: OpenSSL soname
On Sun, Feb 29, 2004 at 12:34:21AM +0300, Solar Designer wrote:
> Those 0.9.5 and early 0.9.6 packages happened to use soname's ending
> in ".0", essentially permitting the dynamic linker to use the same
> shared libraries for applications linked against any 0.* version of
> OpenSSL, up to the moment when...
>
> OpenSSL 0.9.6-with-some-letter (don't remember which exactly) changed
> the default soname to include all three components of the version
> number, to emphasize that the OpenSSL team does not guarantee binary
> compatibility between OpenSSL releases. (What about patchlevels?)
There's an earnest effort to not break the ABI between patch levels, but
it has happened despite their best intentions. The recent fix for
blinding, for example, added a field to a structure which is defined in
a public header (BN_BLINDING gained the thread_id field).
> Red Hat was using their own scheme for soname's in their OpenSSL
> packages (in Red Hat Linux), as described in openssl.spec:
>
> # 0.9.5a soversion = 0
> # 0.9.6 soversion = 1
> # 0.9.6a soversion = 2
> # 0.9.6c soversion = 3
> # 0.9.7a soversion = 4
>
> Although Red Hat Linux first included OpenSSL only in the 0.9.6* days(?),
Actually, we shipped a release with 0.9.5a (RHL 6.2).
> However, there is the question about patchlevels which by the official
> OpenSSL's scheme would be declared to be binary compatible throughout
> each OpenSSL branch. Are they? If yes, then why does Red Hat use
> different soname's for 0.9.6, 0.9.6a, and 0.9.6c? If no, then is OpenSSL
> planning to address this, and how (by making sure all future patchlevels
> don't break binary compatibility, or by switching to a different scheme
> for soname's)?
Each time we noticed a change between versions which we had shipped and
versions to which we were upgrading, bumps were made so that we could
provide compat libraries when we upgraded in the development tree. Not
a perfect solution, to be sure, but there were only so many options.
> It doesn't appear that we can be binary-compatible with application
> software packages built for both Red Hat Linux and official OpenSSL.
> So we have to choose one of those (either make it *.4 or *.0.9.7).
A heads-up: in 0.9.7, SSL and SSL_SESSION change size depending on
whether or not you compile with Kerberos support. Similar things
happened to EVP_CIPHER_CTX when you enabled or disabled particular
ciphers, though that appears to have been resolved in 0.9.7.
> To make the best choice, I am interested in answers to the following
> three questions:
>
> 1. What are the plans of Red Hat with regard to soname's for their
> future OpenSSL packages?
Ah. Continue bumping whole numbers until the OpenSSL team releases a
1.0 which they commit to keeping ABI stable. At that point, I don't
expect we'll still have any releases with lib....so.1 in them, so a
conflict will hopefully be moot. Else we suck it up and do some serious
rebuilding.
Despite all of my gloom and doom, I want to make it very clear that I
have no problem with the OpenSSL team numbering things as they do --
it's their prerogative as the upstream maintainers to set expectations,
and they have on numerous occasions said that they won't guarantee ABI
stability until 1.0.
HTH,
Nalin
Powered by blists - more mailing lists
Please check out the
xvendor mailing list charter.
