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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ