OpenSSL and LSB

[Camp, TracyX E]

I’d like to re-start some discussion about including OpenSSL in LSB (acronym expansion: Linux Standards Base see: http://www.freestandards.org).  There is apparently general interest in seeing OpenSSL in LSB both for its SSL functionality as well as its utility as a general cryptographic library.  In particular applications that wish to be LSB compliant would benefit from security bug fixes.  Currently applications that use OpenSSL and wish to be LSB compliant are forced to statically link OpenSSL and in theory at least, may need to re-release binaries for each OpenSSL release (or at least evaluate if a re-release is necessary), something that is typically just not practical for most LSB applications.   The general issues with incorporating OpenSSL into LSB are ABI stability since the magic 1.0.0 release (while closer) has not happened yet, and just the shear size of the OpenSSL API.   I spent quiet a bit of time conducting an analysis of 0.7.x-0.9.8d OpenSSL releases. (documented at http://www.freestandards.org/en/OpenSSL_stability_analysis)  The analysis attempted to determine three things: What APIs are actually used by released applications and can a sub-set of the total OpenSSL API be created that is functionally useful and finally is that API subset ABI stable across many releases of OpenSSL.   The answers are generally, yes it is possible to determine an API subset that will work for most applications that make use of OpenSSL (language bindings and the like are ignored here), and more-or-less yes that subset is ABI stable.  Further experiments attempted to determine if by treating all or most OpenSSL structure types as opaque types (i.e. no stack allocations or direct structure manipulations) would give ABI stability.  The quick answer there again is yes this provided almost perfect ABI stability, but with a loss of functionality.   The loss of functionality was because a fairly large portion of the OpenSSL API is implemented as macros that perform trivial manipulations on OpenSSL data types.  However since these are macros, it is not also possible to force the data types they manipulate to be opaque.  In almost all cases it is fairly trivial to convert the macros into functions and remove the dependency on fully typed data types.  Which brings me to my questions for the OpenSSL developer community:   1)       First and most fundamentally: Is the general idea of attempting to only incorporate an API subset into the LSB ABI a good or acceptable one?  LSB ABIs typically do not include every last interface of most libraries that are standardized either because the non-included APIs are really library internals, the API is not stable or is only useful in specialized cases.  In this case the APIs I didn’t include are as far as I can tell only useful in specialized cases, or have higher level APIs that provide the same functionality (EVP vs. DES). 2)       Is my concern about API stability going forward using fully typed structures unfounded? 3)       Are there concerns about converting large numbers of macros into functions? (Performance etc.)   Thanks,   Tracy Camp