[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20040301144421.GE31356@conectiva.com.br>
Date: Mon, 1 Mar 2004 11:44:21 -0300
From: Andreas <andreas@...ectiva.com.br>
To: xvendor@...ts.openwall.com
Subject: 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
upgrade introduced incompatibilities, was one of those big security patches
many months (years?) ago.
> 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.
Because of that I added this jewel in openssh's spec, but I think they relaxed
that requirement a bit:
%define opensslver %(LC_ALL="C" rpm -q --queryformat '%{VERSION}' openssl-devel )
PreReq: openssl = %{opensslver}
> 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.
An assumption which may break at any moment, there is no guarantee from the openssl
folks about this as I recall. It's not exclusive to openssl, c-client has this
issue and even openldap once removed an exported cache function from their libraries without
bumping the soname.
> 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).
You can provide both dependencies if you want to.
> 3. What soname's other distribution vendors, besides Red Hat, are
> using or planning to use?
We try to stick with what upstream is doing. In this case, using the full version
as the soname worked for us. We may add RH-style provides, I don't know yet.
Powered by blists - more mailing lists
Please check out the
xvendor mailing list charter.
