Status of OpenSSL 1.1 support

Colin Watson cjwatson at debian.org
Mon Oct 16 20:26:03 AEDT 2017


On Mon, Oct 16, 2017 at 12:40:54AM +0200, Ingo Schwarze wrote:
> Colin Watson wrote on Sun, Oct 15, 2017 at 10:51:46PM +0100:
> > Is it actually a requirement that an API compatibility layer be
> > maintained by the OpenSSL team, or could a hypothetical group of
> > external developers interested in breaking this stalemate fork
> > openssl-compat.tar.gz, stick it in a git repository somewhere, and start
> > making versioned releases and trying to address the other problems you
> > describe?
> 
> At the risk of telling you something that you already know, OpenSSL
> is both a large and a complicated library, and even though some
> parts of the compatibility layer may seem relatively simple on first
> sight, that doesn't imply there are no non-obvious pitfalls, and
> if somebody who is only partly qualified or only understands parts
> of the code makes seemingly simple changes in code related to
> cryptography, that's exactly how some serious vulnerabilities in
> both OpenSSL and in some non-OpenBSD ports of OpenSSH were caused
> in the past.
> 
> So the hypothetical group you wish for would also have to be
> qualified, and there are not very many people in the world who
> would qualify to lead such a group, i fear.  There are certainly
> some inside the OpenSSL project; at least they are likely to
> know the code, to know how they changed it and what that implies,
> and likely already aware of some of the potential pitfalls.

OK.  So that still basically leaves us at an impasse, because OpenSSH
will only use a compatibility layer with a sufficiently good maintenance
team, and the OpenSSL team (as far as I can tell from public statements)
don't want to be on the hook for that.

Which leads me back to my previous question: what conversations have
there been between the OpenSSH and OpenSSL developers about this
problem?  Has OpenSSL upstream actually been told directly by OpenSSH
that this is a problem, or are they only hearing about this from users
trying to compile OpenSSH against 1.1?  I've only found evidence of the
latter in public mailing list posts so far.

> [ about the option of building OpenSSH against LibreSSL on Debian ]
> 
> > This would be a pretty bad option for me as a distributor - it'd
> > mean I'd have to keep track of LibreSSL security updates.
> 
> In the past, that has proven noticeably less stressful than keeping
> track of OpenSSL security updates, and i think it is safe to say
> that it would be orders of magnitude less stressful and less dangerous
> *for an outside party* than engineering and maintaining a compatibility
> library.

That's as may be, but (a) I don't have to keep track of *either* OpenSSL
or LibreSSL updates right now in general, (b) our distribution policy is
generally that we strenuously avoid using bundled copies of code.
Fedora has the same policy, and so far has opted to ship a ~3600-line
patch to OpenSSH to use the 1.1 API.  That patch will surely get
substantially smaller once they're on 7.6p1 and can drop all the
protocol 1 bits, but even so, I *really* dislike the option of using a
non-upstreamed patch for that, which is why I'm trying to find a better
option that's compatible with our policies before my hand is forced by
OpenSSL 1.0 build support being removed from Debian, which is likely to
be before the end of the year.

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.

-- 
Colin Watson                                       [cjwatson at debian.org]


More information about the openssh-unix-dev mailing list