On Wed, Apr 01, 2009 at 03:03:44PM -0400, Geoff Thorpe wrote:
> Fair comment, I'll respond to this as best I can, but this is not any
> kind of official statement.
>
> On Wednesday 01 April 2009 14:01:18 Kurt Roeckx wrote:
> > Hi,
> >
> > I was under the impression that for the 1.0 version you would
> > change the API so that the ABI doesn't break all the time, and
> > I see no changed related to that.
>
> No, and please don't expect it to happen for v1.0. I speak only for
> myself, the others can agree/disagree as they please, but I think ABI
> compatibility is a fairly unrealistic dream when you take into account
> the SSLeay and OpenSSL legacy interfaces, current release management
> mechanisms, and community expectations (specifically souce
> compatibility, and in the case of stable-releases, even
> binary/shared-lib compatibility).
The shared-lib is actually one of my main problems. Once I upload
a version to Debian, I basicly can not change any compile time
options anymore, and I'm stuck with those options until the next
major release of openssl. This also means that if you add options,
I always have to disable them.
> The problem is circular - to get to ABI compatibility (and other
> desirable but far-away goals) would first require a large number of
> significant breaks in API compatibility. Resistance to the latter has
> historically been more evident, and certainly more immediate, than
> support for the former.
>
> However, we have been mulling over a new way of managing versions that
> would allow openssl to deliberately engage in API breakages across major
> releases (in ways that can be tracked, and which allow dependent
> libs/apps to prepare, etc), and to hopefully combine this with a more
> orderly/predictable release time-frame. The idea then is that working
> towards goals like ABI-stability would be possible in iterations that
> explicitly "break" certain legacy interfaces and behaviours, but do so
> in a clearly-defined manner. There would also be appropriate assurances
> for continued support of prior versions + adequate lead times to prepare
> for interface changes prior to major releases. The whole point is that
> there are types of progress we can't make by purely incremental and
> backwards-compatible steps, so this would be an attempt to address that
> without raising the ire of disgruntled users.
You could start by adding new interfaces and not removing /
changing the existing interfaces. If you add interfaces so that
there is no need for applications to directly make use of the
structs, we could start migrating those applications to to use
that new API.
Note that there is no need to change the current API, they can
perfectly use the structs. But applications should not know
what the members of those structs are. This works perfectly
as long as you always pass it as pointers.
The following example compiles without any problems:
typedef struct ssl_ctx_st SSL_CTX;
typedef struct ssl_method_st SSL_METHOD;
SSL_METHOD *TLSv1_method(void);
SSL_CTX *SSL_CTX_new(SSL_METHOD *meth);
void foo()
{
SSL_CTX *ctx = SSL_CTX_new(TLSv1_method());
}
In the end, I would like to get a situation were things like
"struct ssl_ctx_st" are not in the public ssl.h, but are only used
internally. And the first step for that would be make sure that
applications do not need to use any members of the structs directly,
but have a function to access it if they need to.
If those functions existed, I could start providing patches
for all software in Debian that makes use of openssl to use
the functions.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
