On Thu, Sep 02, 2010 at 11:02:21PM +0200, Dr. Stephen Henson wrote:
> On Thu, Sep 02, 2010, Victor Duchovni wrote:
>
> >
> > It is my impression that enabling tls extensions breaks binary
> > compatibility, so I cannot replace a "no-tlsext" shared library with
> > one that support extensions without re-compiling all the clients. So,
> > some legacy systems still get "no-tlsext" libraries until we move
> > everyone to 1.0.0.
> >
>
> A few fields are appended to some structures to support TLS extensions which
> means that some structures increase in size. These structures are only ever
> allocated and freed by library calls so binary compatibility *should* be
> maintained. However there is a slight risk that a highly broken application
> will allocate the structures itself and poke around in internals to set them
> up.
So no existing fields change size or position?
And the ABI is only broken when applications allocate SSL, SSL_CTX,
... structures directly rather than via SSL_new() or SSL_CTX_new()?
If so, I may take the plunge with 0.9.8p, if it is likely that the most
common applications (Apache, stunnel, curl, wget, ...) and high-level
language run-times (Perl, Python, ... SSL support) do not break when
tls extensions are enabled in an updated shared library.
Is there anywhere either a list of applications known to work or known
to not work with recompiled libraries?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
