On Thu, Nov 17, 2016 at 10:43:53PM +0100, Moritz Mühlenhoff wrote: > Adrian Bunk <b...@stusta.de> schrieb: > > On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez > > Meyer wrote: > >> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote: > >> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> > >> > wrote: > >> > > And yes, I would step back and switch libssl-dev to provide > >> > > libssl1.0-dev > >> > > and have libssl1.1-dev around for anyone who can really do the switch. > >> > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very > >> > bad default for next year's release. > >> > Bad enough that I would have to use a different distribution for some > >> > web servers. > >> > >> That's why I wrote: > >> > >> And if we **really** need to switch to libssl1.1 then we **really** need > >> to > >> delay the release by 6 months as a very minimum, maybe 1 year. > >> > >> Yes, I also know that it sounds awful, but do we have another way out? > > > > Yes, patching the OpenSSL 1.1 features that are really needed into the > > Debian OpenSSL 1.0.2 package. > > > > For ChaCha20 that's existing patches that are already being used > > elsewhere. > > That's not an option, while there's an external patch for chacha20/poly > by cloudflare it hasn't been upstreamed and we cannot cover it with > security support in a meaningful manner.
1.1.0 will be out of upstream security support after August 2018, 1.0.2 after 2019. Debian is able and willing to provide security support for two OpenSSL releases in stretch, that will both be without upstream support in 2020. > And other features are not > backportable at all. > > Kurt has already asked who would do the backports and support them in > https://lists.debian.org/debian-release/2016/10/msg00609.html, so stop > pretending that's a genuine option. Dual 1.0.2/1.1 is the expected mess, and people have to stop pretending it would be a genuine option that most of the important packages in stretch would use 1.1, unless the release schedule is moved by 6-12 months. Trying to make all or a majority of OpenSSL-using packages in stretch use 1.1 might not even be much faster in delivering 1.1 features to stable users than making stretch 1.0.2-only[1], and release buster 1.1-only a year after stretch. As a bonus, "stretch 1.0.2-only and early buster" would imply providing security support for one OpenSSL version that will be upstream-supported during the whole (non-LTS) lifetime of stretch, instead of providing security support for two OpenSSL versions that will both get out of upstream support during the lifetime of a stretch without early buster. And/or get sponsorship from companies for supporting ChaCha20-patched 1.0.2 through Freexian - this would be an option that would not impact the release schedule.[2] OpenSSL upstream created this mess by only providing new features together with a huge API breakage, and there are no nice solutions for stretch. cu Adrian [1] shipping 1.1 as security-supported technology preview is an option [2] I am aware that this would be controversial -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
