This is a discussion on Re: OpenSSL and LSB - Openssl ; Theodore Tso wrote: > I would suggest that the best way to do this is to *add* new mutator > functions (and accessor functions, where necessary) which applications > who care about ABI stability can use, and then document a ...
Theodore Tso wrote:
> I would suggest that the best way to do this is to *add* new mutator
> functions (and accessor functions, where necessary) which applications
> who care about ABI stability can use, and then document a set of
> interfaces for which ABI stability is guaranteed. That could be a
> relatively small set initially --- enough for applications that aren't
> doing anything strange, and then this list can gradually be expanded
> out, with some new ABI stable functions getting added as necessary.
Possibly. There are (or have been) analogous developments that could
contribute to your thinking of how to address LSB concerns. Eg. the FIPS
work has certification, signature-checking, and other "fixed interface"
considerations (I think, I haven't been involved in this at all). Also,
OPENSSL_NO_DEPRECATED is used as a mechanism to "nudge" away from
backwards-compatible interfaces to their preferred replacements (more of
this coming to the cvs list in a day or three, BTW). If you define this
symbol when building your code against openssl, deprecated interfaces
will not be exposed from the headers. If you define this symbol when
building openssl itself, deprecated interfaces will not be compiled (I
know this doesn't address structures/macros/etc that are not
compiled/linkable interfaces, but you get the general idea).
There appear to be a few possible avenues to explore;
* define LSB-specific wrapper libraries/interfaces to implement a stable
* define only a small subset of functionality in LSB, with the intention
of openssl keeping *those* interfaces fixed,
* look for ways that a FIPS/NO_DEPRECATED-style pre-processor
configuration could compile openssl in some LSB-friendly manner,
* define LSB relative to an openssl "stable" branch.
The last point should perhaps not be scoffed at. This is how
compatibility is handled in the real world anyway - until openssl
reaches some kind of "v1.0" state, 0.9.7 is considered a different
library to 0.9.8, such that fixes and maintenance for each branch *do*
maintain ABI compatibility. Ie. distributions typically install distinct
shared-libraries for each, and track them with distinct packages.
Having said all that, I'll have to leave this issue to others who have
the motivation and time for it.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org