Re: OpenSSL 1.1.0
On Wed, Nov 16, 2016 at 10:53:18PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-16 19:49:44 [+0200], Adrian Bunk wrote:
> > The problem are not specific bugs, the problem is the whole size of the
> > problem:
> >
> > 1. Sorting out what packages have to stay at 1.0.2
> > The majority of OpenSSL-using packages in stretch might end up
> > using 1.0.2 - sorting this out is part of the ongoing OpenSSL
> > transition.
>
> You have two choices: either port it to 1.1.0 and stay with 1.0.2.
60 packages got removed from testing since there was only a 10 day
window between openssl1.0 being available and autoremoval of these
packages.
And after submitting patches to switch packages to 1.0.2, it was you who
said "Adrian, seriously? This is not a patch."
This is your transition, and it should actually be you who is working on
getting all ~ 200 RC bugs in sid related to your transition resolved.
And this is only about the simple cases.
A huge problem is the unknown number of small and big clusters of
packages that have to use the same OpenSSL version.
Noone from you OpenSSL developers seems to be working on sorting these
clusters out.
Like I do not understand why Kurt is trying to switch Apache to 1.1
As far as I can see, Apache is part of the libcurl3 cluster where
all packages anyway have to stay at 1.0.2 for stretch.
> > 2. OpenSSL 1.1 support is often only build-tested
> > We are currently at 650 packages in unstable depending on libssl1.0.2,
> > and when binNMUs will happen we might get a three-digit number of
> > new RC bugs like #843988 and #843532.
>
> stunnel was prepared upstream to work with 1.1.0 and it wasn't perfect.
> We would also face the same problem if openssl 1.0.2 decided to do a
> realloc() at some point. Lucky it did not yet.
>...
Every non-trivial piece of software has bugs.
The relevant part here is "works with 1.0.2, but did not work with 1.1".
These are regressions when switching from 1.0.2 to 1.1, no matter where
the actual bug is.
> > 3. Another Debian OpenSSL security fiasco?
> > Bugs like #843988 are only about problems that show up immediately.
> > This is often code where mistakes can be CVEs, and bug #843988 or
> > the comment "With Kurt's patch, apache2 crashes on startup" don't
> > make me optimistic regarding silent new security holes.
> > Depending on how/if this was applied upstream, these might become
> > Debian-specific CVEs.
>
> I forwaded (or tried) my 1.1.0 fixups to upstream. I didn't find alive
> upstream for the two perl patches I made and had hope that the debian
> maintainer knows how to forwarded them.
You are not the only one patching these, and surely not the least
knowledgable person making such patches.
And noone seems to be systematically tracking for all patches what
happens in the end - even cherry-picking an upstream patch might
miss critical later upstream fixes.
The problem here is the huge amount of packages that need changes due to
the OpenSSL API breakage.
> > People will remember the last time Debian screwed up badly in the area
> > of OpenSSL, so this could really harm the reputation of Debian.
> >
> > 4. Schedule
> > The transition freeze was 11 days ago, and the soft freeze is only
> > 1.5 months ahead.
> > If the work on points 1 and 2 above is not mostly finished
> > by December 5th (mandatory 10-day migrations will start, only
> > 1 month until the soft freeze), either the OpenSSL transition
> > or the release schedule have to be scrapped.
>
> So people still can choose to go for 1.1.0 or 1.0.2. They may work on
> 1.1.0.
Is everyone aware that this choice is per-cluster and not per-package?
One single leaf package that chooses to stay at 1.0.2 and is part
of a cluster implies that you must force all other packages in the
cluster to also stay at 1.0.2
> Sebastian
cu
Adrian
--
"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
Reply to: