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]
