[Pkg-openssl-devel] OpenSSL 1.1.0

[Pau Garcia i Quiles]

On Wed, Nov 16, 2016 at 1:26 PM, Ian Jackson
<ijackson at chiark.greenend.org.uk> wrote:

> A maintainer should be ready to explain, and if necessary change,
> decisions they have taken.  (Ideally wider consultation before taking
> such a decision would be better.)
>
> In the absence of input from the openssl maintainers, I would like to
> ask the Release Team's opinion.
>
> If we are going to wind back on this change we should do it ASAP.  We
> should not allow ourselves to make the decision to press on, simply by
> failing to decide otherwise.
>
> If we decide to wind back the transition and the openssl maintainers
> continue not to be available (within the short timeframes required),
> we have a lot of people who could competently prepare an NMU.

>From a project management point of view, I can see three alternatives

OpenSSL 1.0 only
=============

* All packages work fine
* No release delays
* We will be using an LTS version of OpenSSL
* Some obscure feature (e. g. BlaBla20) may be missing or be difficult
to support on a limited number of packages (e. g. apache2)


OpenSSL 1.1 only
=============

* Many packages do not support OpenSSL in upstream, therefore they
need patching from Debian maintainer (security risk). Some packages do
not have a maintainer volunteer that can provide this patch.
* Release delay between 6-12 months seems certain
* We will be using version of OpenSSL with support end date before
Stretch's support end date
* We will be providing all new features that come with OpenSSL


OpenSSL 1.0 + 1.1
==============

* Every package will be buildable but we can expect surprises on
runtime due to dlopen'ed libraries, indirect use, etc
* Release delay seems certain but difficult to determine
* Even with a release delay, we cannot be 100% sure all the rutnime
surprises will be gone
* We need to support 2 versions of OpenSSL and be prepared for
third-party applications (not included with Debian) to fail due to
runtime surprises
* Different support cycles upstream (one LTSL, one not)
* We will be providing both versions of OpenSSL for the end-user to
choose (when he has the knowledge)


If I were in charge of taking this decision:

* OpenSSL 1.0 + 1.1 would be out. It's the worst possible scenario:
even with a delay, I can expect problems
* OpenSSL 1.1 will delay the release and/or leave a lot of packages out
* OpenSSL 1.0 makes possible to release as planned and provides an LTS
release. The minor inconveniences for missing ciphers, etc do not
justify the negative impact of the other choices, IMO.

So I would release Stretch with OpenSSL 1.0 only, and then make a plan:
1. OpenSSL 1.1 is gone from sid effective immediately and move to experimental
2. On April 1st 2017 we replace OpenSSL 1.0 with OpenSSL 1.1 in sid.
All packages are expected to support OpenSSL 1.1 only by this date.
3. Stabilize and aim for a quick Debian release 1 year after Stretch.
Yes, that means 2 Debian versions supported for some time.

Of course, that's just my suggestion. Feel free to disagree.

-- 
Pau Garcia i Quiles
http://www.elpauer.org