> -----Original Message----- > From: Geoff Thorpe [mailto:[EMAIL PROTECTED] On Behalf > Of Geoff Thorpe > Sent: Wednesday, June 29, 2005 5:45 PM > To: openssl-dev@openssl.org > Cc: Banginwar, Rajesh > Subject: Re: Considering SSL and Cryto libraries for LSB > > On June 29, 2005 05:50 pm, Banginwar, Rajesh wrote: > > As part of LSB standardization process, we look at the > interfaces and > > corresponding data types and make it part of the > specification. If the > > data types are expected to change and the interfaces do not > hide them, > > then that part of the library may not be a candidate for LSB. > > Well there are two things that spring to mind. > > 1. Most "use" of openssl, at least as might be considered > useful from an > LSB-perspective, is of the SSL layer itself (libssl). This > requires the > direct use of certain APIs in the underlying libcrypto layer too, but > AFAICT these would be easier to standardise on than the full > set of APIs > and are probably more ABI-friendly (ie. loading and > initialising RSA/X509 > objects, etc). NB, that's a cursory thought, I've not > attempted to dig > terribly far on this.
So far from the preliminary analysis that we have done (by looking at some of the OSS applications) we see both libssl and libcrypto being used. E.g. from libcrypto I find functions in EVP, RSA, MD5 and DSA sets more commonly used than others. Unfortunately this is not an exhaustive study. Do you or anyone on this project have data suggesting which APIs are candidates for LSB inclusion both from demand and stability point of view? > > 2. This is a refined variation on the issues distributions > already face > when distributing openssl in shared-library form and > maintaining classes > of applications that have dependencies on these libs. The > consensus seems > to be to use versioning to manage this, where a system can > have multiple > openssl libraries installed of differing version levels. Eg. 0.9.6, > 0.9.7, etc. Bugfix releases to individual versions are expected to > maintain binary compatibility, or distributors at least Q/A > this at their > end and patch around any issues as/where necessary. You'd > have to check > with the distributions themselves to know more though, that's > out of our > hands. Mark, any comments from a Redhat perspective? > > The reasons Steve outlined cover why we can't provide > assurances about > full ABI compatibility (nor even API compatibility) in a > long-term sense. > To do so would take a lot of undesirable but legacy aspects of the > toolkit and fix them in place. However, the unwritten rule is > to ensure > that each incremental(/"bugfix") release of a given stable > branch does > preserve binary compatibility, and incorporation into LSB definitions > would obviously go a long way turning this into a firmer > commitment. Note > also that major releases, which we freely admit can break ABI > and/or API > compatibility where required, are made far less frequently - > as a perusal > of release history will aptly demonstrate. I should also mention that > we're not making vast overhauls of APIs on a regular basis, > nor for the > mere fun of it, so if adaptations are required long-term to > allow future > LSB revisions to incorporate newer release levels, this would hardly > involve major surgery. Perhaps that's an avenue until such time as > openssl does get to some kind of 1.0 plateau. Hope springs eternal. > I just checked the release history for openssl and it is encouraging to see the major releases are years apart. I see that with some efforts it may be possible to hide some of the data structure dependencies (as Steve pointed out in other emails on this thread) and get some sets of APIs to a "stable" level and push for LSB inclusion. There was at least one comment from application developer encouraging this even though it will require major changes. > [ Or people wanting LSB compliancy can always statically link > any version > of openssl they like, but I guess that's not what you're after :-) ] > > Cheers, > Geoff > > -- > Geoff Thorpe > [EMAIL PROTECTED] > http://www.openssl.org/ > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
