Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2
Hi,
[I have trimmed the cc list a bit]
On Wednesday, 16 November 2016 20:36:49 CET Kurt Roeckx wrote:
> On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> > Stefan Fritsch <sf@debian.org> writes:
> > > I must admit that I did not think of php when doing that change, sorry.
> > >
> > > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and
> > > there have been some indications that shibboleth won't be switching to
> > > openssl 1.1 for stretch. See
> > > https://lists.debian.org/debian-release/2016/11/msg00024.html>
> > It turns out that Shibboleth will be okay if Apache goes to 1.1. The
> > Shibboleth code that goes into Apache is isolated from the OpenSSL use
> > inside Shibboleth, so we can keep building Shibboleth against 1.0 and
> > Apache can go to 1.1 and all the pieces are happy. (The OpenSSL work is
> > done in a separate daemon, shibd, that the Apache module talks to.)
>
> So I looked at apache2-dev to see why it depends on libssl-dev.
> The only thing I can find is that mod_ssl_openssl.h provides some
> hooks, and you actually get SSL_CTX * and SSL * in there. But
> nothing in Debian seems to include that file.
That header was created for mod_ssl_ct which provides support for certificate
transparency. It's quite new and likely that nothing else uses the header. It
would probably be acceptable to remove the dependency in apache2-dev on
libssl-dev and add a caveat to the README.Debian. I could also not install the
header, or put it into a separate new package that depends on libssl-dev.
That would be one alternative. Another would be to switch apache2 to openssl
1.1. I have explained why I don't want to this. But it's not impossible. The
release team has announced that they will decide soon if they want the
transition to go ahead or not. I will reconsider depending on what they write.
BTW, I am pretty sure that support for enhanced master secret and chacha20
will appear for openssl 1.0.2 before the release of stretch+1, if only because
redhat needs it for its long support cycles. Back-porting that to stretch in a
year or so in a stable-point-release would IMHO be the best option. When
Apache httpd 2.4 came out, I was also quite disappointed that it could not be
included in squeeze, but mod_perl was not ready at the time and it would not
have made any sense to include an inofficial forward-port of mod_perl to 2.4 in
Debian. In the same way, I don't think it is a good idea to include lots of
patches for openssl 1.1, with little testing.
Cheers,
Stefan
Reply to: