[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2


[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.


Reply to: