[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Feb 2004 00:34:21 +0300
From: Solar Designer <solar@...nwall.com>
To: xvendor@...ts.openwall.com
Subject: 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
# 0.9.7a soversion = 4
Although Red Hat Linux first included OpenSSL only in the 0.9.6* days(?),
they chose to use a scheme which would be compatible with older 0.9.5*
packages:
* Fri Mar 2 2001 Nalin Dahyabhai <nalin@...hat.com>
- update to 0.9.6
[...]
- bump the soversion to 1 because we're no longer compatible with any of
the various 0.9.5a packages circulating around, which provide lib*.so.0
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.
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)?
Also somewhat related is OpenSSH's check to make sure its binaries
only run with the same version of OpenSSL that they were built with.
That check ignores differences in patchlevel, but not differences in
"status" (snapshot vs. release?) In Owl, we're currently patching it
to check just the main three version components, but not patchlevel or
status. This assumes that different patchlevels _will_ be binary
compatible.
Now, back to the dilemma we're facing:
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).
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?
2. What are the plans of the OpenSSL team?
3. What soname's other distribution vendors, besides Red Hat, are
using or planning to use?
Thanks, and with hope that this discussion will be useful to others on
the list,
--
Alexander Peslyak <solar@...nwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Please check out the
xvendor mailing list charter.
