Status of OpenSSL 1.1 support

[Colin Watson]

On Tue, Oct 17, 2017 at 09:39:50AM +1100, Damien Miller wrote:
> On Mon, 16 Oct 2017, Colin Watson wrote:
> > If my only other option is to use LibreSSL, then that will mean
> > packaging LibreSSL separately, and https://bugs.debian.org/754513 seems
> > to have petered out a couple of years ago, not to mention being a pile
> > of work I really don't have time for as well as requiring overcoming
> > non-trivial objections.  I realise that this is not the OpenSSH team's
> > problem as such, and that as a LibreSSL developer you may well not be
> > super-sympathetic to this argument; but nevertheless, I don't think this
> > is a viable option right now for us as a distributor.
> 
> I'm sorry to have put you in this situation, but we have an upstream who
> is LibreSSL exclusively, a need to support LibreSSL and BoringSSL in the
> portable version and limited time and resources of our own.
> 
> Even adopting the use of shims that give us the OpenSSL 1.1.x API means
> considerable additional work for us, because OpenBSD doesn't use that
> API. I'm willing to do it, but not if I'm going to be fighting the shims
> themselves along the way.

The discussion on debian-devel seemed to indicate that embedding a copy
of LibreSSL might actually end up being an approach we could live with
for now, since it would mean that we don't have to worry about whether
LibreSSL's support cycles align with Debian's.  I didn't get unanimity
on this, but there was more consensus than I expected.

Have you done any more work on
https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036346.html
as yet?  It's probably worth mentioning sooner rather than later that
anything that involved fetching something from the network at build time
wouldn't work for us; perhaps embedding a copy of (the relevant parts
of) LibreSSL would be possible though?


On a somewhat separate note, I still need to work out what to do about
openssh-ssh1, which is the copy of 7.5p1 that I split out to a separate
source package in Debian as described in
https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-May/035070.html.
We still need to be able to build that even after we stop supporting
OpenSSL 1.0.

My current thought, reversing my previous opinion, is that it may
actually be best to apply the patch set from Kurt and Fedora for OpenSSL
1.1 support *only* for openssh-ssh1.  My rationale is:

 * I can't imagine that there's any appetite among OpenSSH developers
   for issuing a 7.5p2 with an embedded LibreSSL just for the sake of
   the obsolete protocol that you explicitly want to stop spending time
   on.

 * Distro-patching 7.5p1 to add an embedded copy of LibreSSL would be an
   even more gigantic patch than the Fedora one, and not clearly less of
   a headache for me.  We could reasonably debate whether it would be
   more or less prone to failure.

 * I want to spend as little of my time as possible keeping openssh-ssh1
   on life support, and the Fedora patch exists today while other
   options require more (even if not necessarily much more) work.

 * The difficulty of accurately forward-porting Fedora's patch to newer
   upstream versions doesn't apply in the case of openssh-ssh1, as there
   will be no new upstream versions.

 * openssh-ssh1 is client-only, reducing the scope of possible problems.

 * Acknowledging Ingo's views on the Fedora patch in
   https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036365.html,
   nobody security-conscious is going to be using protocol 1 on a public
   network anyway, since it's already known to be broken.  The only
   reasonable way to use it is as a glorified telnet on something like a
   private management network to talk to devices that don't speak
   anything else and can't be upgraded.  In that context, an error in
   the OpenSSL 1.1 support patch is not going to have catastrophic
   consequences.

This is an opportunity for people to tell me why that line of reasoning
is wrong.

-- 
Colin Watson                                       [cjwatson at debian.org]