[Pkg-openssl-devel] Bug#462596: openssl: Please include support for tls extensions / server name indication

[Steve Langasek]

On Sun, Jan 27, 2008 at 03:03:14PM +0100, Kurt Roeckx wrote:
> On Sat, Jan 26, 2008 at 03:15:18PM +0100, Stefan Fritsch wrote:
> > Hi Kurt,

> > On Saturday 26 January 2008, Kurt Roeckx wrote:
> > > The problem with that option (and others) is that it changes struct
> > > layouts, which means ABI changes.  I'm afraid I can't do such a
> > > change without changing the soname.  It seems that only the end of
> > > struct's are changed so we might get away with it for some cases,
> > > but someone will need to take a good look before doing that.

> > IMNSHO we want this for lenny, even if it needs a soname change.

> If we're going to do that, I think we need to clear this with the release
> team in any case.

> I'm not really in favour of doing any change that requires us to rebuild
> everything against a new openssl version.  The last migration started
> with the upload of 0.9.8-1 which was uploaded on 2005-09-29, the latest
> package depending on 0.9.7 was removed from testing on 2008-01-05.
> I think the release team would like to see atleast 2 source packages
> again for such a migration.

Yes, for a library as core as openssl, a forklift soname change would be
very, very painful.

> Anyway, looking at the structs that changed, we have those structs:
> SSL_SESSION / struct ssl_session_st
> SSL_CTX / struct ssl_ctx_st
> SSL / struct ssl_st / ssl_crock_st

> They all add new members at the end of the struct.

> They all have functions to allocate/free them:
> SSL_SESSION_new / SSL_SESSION_free
> SSL_CTX_new / SSL_CTX_free
> SSL_new / SSL_free

> Those structs are always passed as pointers.

Well, that /should/ be sufficient to preserve ABI compatibility, but
unfortunately these aren't opaque pointers -- the struct internals are
exported in the openssl headers, so it's possible for an application to make
assumptions about the size of the structures (sizeof, etc) which will fail
if this option is enabled.

Yet another example of how making ABIs a compile-time option is a bad idea.
:/

> I think that it should be safe to turn on this feature without breaking
> something.

It should at least be possible to turn it on on a provisional basis, as the
most realistic way of finding out if anything *does* depend on the size of
these structs.  (Auditing the code of all reverse-deps is not very practical
in this case.)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org