gmane.comp.misc.xvendor

OpenSSL soname

Hi,

We're about to move from OpenSSL 0.9.6* to 0.9.7* (finally), and the
previously postponed question of what soname's to use for OpenSSL's
shared libraries arises again.

Please correct me if I am wrong about any of the following:

As far as I understand, OpenSSL did not officially support building of
shared libraries until not so long ago (until 0.9.6?), yet there were
packages of OpenSSL for particular Linux distributions already in the
0.9.5 days which built shared libraries.

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?)

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

(Continue reading)

headers

Michael Tokarev | 1 Mar 07:13

Re: OpenSSL soname

Solar Designer wrote:
...
[2 openssl soname naming schemes - libssl.so.N vs libssl.so.X.Y.Z]

> 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).

The above does not seems to be true.  That is, it is very simple
to support both schemes, by providing both RH-style libssl.so.N
and openssl-style libssl.so.X.Y.Z libraries, where libssl.so.N is
a symlink to libssl.so.X.Y.Z, since both are really the same (not
just "compatbile", but exactly the same).  This looks a bit messy,
and may break if openssl folks descides to use redhat-style naming
scheme after 1.0 release (as their libssl.so.1 will definitely NOT
be compatible with redhat libssl.so.1 which correspond to 0.9.6.

Either way, the question remains open - someone (either redhat or
the rest of the world ;) should change naming scheme at some point.

/mjt

headers

Andreas | 1 Mar 15:44

Re: OpenSSL soname

On Sun, Feb 29, 2004 at 12:34:21AM +0300, Solar Designer wrote:
> As far as I understand, OpenSSL did not officially support building of
> shared libraries until not so long ago (until 0.9.6?), yet there were
> packages of OpenSSL for particular Linux distributions already in the
> 0.9.5 days which built shared libraries.

Right, distributions do not like static-only libraries, specially those
prone to security updates. uw-imap/c-client has the same problem, it
doesn't build shared libraries.

> 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?)

This is how we ship it since that day.

> My guess is that it's this old decision which continues to cause Red Hat
> to stick to their own versioning scheme rather than including all three
> components of the OpenSSL version number like the official OpenSSL does.

This is going to bite them in the future... Or openssl will start using RH's
scheme.

> 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

Perhaps in order to avoid possible problems. I remember that once a patchlevel

(Continue reading)

headers

Nalin Dahyabhai | 15 Mar 22:40

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

(Continue reading)