On Sun, Mar 16, 2008 at 09:21:05PM -0700, Michael Sierchio wrote: > It is *so* difficult to critique something without seeming to > criticize the work of others, so the following disclaimer applies. > MUCH is owed to the developers and maintainers of OpenSSL -- > Mark, Ralf, Stephen, Ben, Lutz, Nils, Richard, Bodo, Ulf, Andy, > Geoff -- and a host of others. OpenSSL is ubiquitous, thanks in > large part to them. 108 bows to each of you.
Indeed; for myself, I was trying very hard *not* to critique, or at least voice any value judgements, but instead to try to describe the current status of the codebase. Having once been a steward of such a codebase (MIT Kerberos v5, from circa 1993 to 1999), and I know how much work it is to maintain backwards compatibility, even at an API level, while worrying about trying to make it more maintainable going forward. We were also under-resourced for most of my time there --- sound familiar? :-) > If one were really serious, it calls for a rewrite -- one that replaces > the dreadful BIO-stuff, develops a strictly modular separation of crypto > libraries (which are used so many places other than for SSL/TLS), etc. > and is written in C++. Well, there *are* other SSL libraries out there, and in fact some people have suggested that the LSB standardize one of the alternate libraries. But, all aside from the licensing issues, the fact of the matter is that for better or for worse, the vast majority of the applications out there are using OpenSSL; it *is* the defacto standard. A rewrite wouldn't help all of the exsting applications which are using the current API. And where are we going to find the resources to do a rewrite? I have talked to one a developer from one ISV (which I won't name pending getting permission from him that it's OK) that the ABI situation has gotten painful enough that he was thinking about creating a wrapper library that would provide a stable ABI, and push the distro's to ship that so that his (fairly widely downloaded and used) binary application could link against a stable library that he knew was guaranteed to work across multiple Linux distro's. So this is not just an theoretical problem, or something which is LSB-specific, but it is something that is affecting OpenSSL client applications. So the question is what's the lowest cost method, which is still maintainable in the long run, for providing this compatibility? 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. Does that make sense? - Ted ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]