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@xxxxxxxxxx] _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
