On Sat, Oct 14, 2017 at 11:40:30AM +1100, Damien Miller wrote:> On Fri, 13 Oct 2017, Sebastian Andrzej Siewior wrote: > > more or less a year ago Kurt Roeckx provided an initial port towards the > > OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has > > been complained about a missing compat layer of the new vs the old API > > within the OpenSSL library [2]. > > This is how I reconstructed the situation as of today and I am not > > aware of any progress in regard to the newer library within the OpenSSH > > project. Did I miss any significant development? > > > > In the `meantime', OpenSSL provides a kind of compat layer [3] which > > (they suggested) should be included in the downstream projects [4]. > > The compatibility layer is unversioned, incomplete, barely documented > and seems to be unmaintained. Because it isn't a library, they require > it to be added to downstream projects directly. This isn't even close > to a solution.Fair enough; but at the risk of telling you something you already know, the situation where distributions that want to get off old versions of OpenSSL have to choose between packaging LibreSSL (and thus, in practice, ending up maintaining multiple SSL library versions, which is exactly what our security teams tend to want to keep to a minimum) or passing around samizdat versions of an enormous patch is not exactly ideal either. It's kind of an unedifying stalemate. https://mta.openssl.org/pipermail/openssl-users/2017-April/005540.html suggests that the OpenSSL folks want an external contributor to maintain such a layer. I've been trawling back through OpenSSL mailing lists and not found much else in the way of discussion about this, although of course I could have missed something. Has there been any discussion between the two sets of developers about all this, or is it all sort of arm's length? 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? Of course that's only really a worthwhile exercise if OpenSSH would be willing to use it, and it would be good to limit the scope of the problem to "things needed by the handful of projects that really need this" rather than "the entire OpenSSL 1.0 API". (I am not at all sure I want to be one of such a hypothetical group of developers, and I definitely don't want to be in it on my own, but it might be better than the alternatives. At the moment it seems clear that neither the OpenSSL nor OpenSSH developers want the task.)> In the absence of any progress, I'm considering adding some build sugar > to simplify the process of building (and possibly fetching) LibreSSL as > port of the OpenSSH build process. AFAIK Apple's OpenSSH distribution is > already linked against LibreSSL (and of course, OpenBSD does too), so > IMO it's had enough road-testing for general use.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. -- Colin Watson [cjwatson at debian.org]
Hi Colin, 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. [ 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. Yours, Ingo
Hi, On Sun, Oct 15, 2017 at 10:51:46PM +0100, Colin Watson wrote:> https://mta.openssl.org/pipermail/openssl-users/2017-April/005540.html > suggests that the OpenSSL folks want an external contributor to maintain > such a layer. I've been trawling back through OpenSSL mailing lists and > not found much else in the way of discussion about this, although of > course I could have missed something. Has there been any discussion > between the two sets of developers about all this, or is it all sort of > arm's length?Speaking for Open*VPN*, we have done that change, and it was fairly painless. All the code has been converted to use OpenSSL 1.1 accessor functions, and when compiling against OpenSSL 1.0 or LibreSSL, a set of compat accessor functions is used (configure tells what is needed). Our shim is here: https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/openssl_compat.h and it's really very straightforward. The commits in question if you want to see what was changed in the code are commit 8d00afae88b626c9cf14170a943b33a7ed378070 commit c828ffc648eebda20e2f9087248944fa0f52a582 commit 09776c5b52df13121504e07894a26d5cd1883317 commit 47191f49890ee5c53fa78a8ce9bf96b9c8d27a82 commit f05665df4150c6a345eec5432a02fd799bea0f2c commit 6554ac9fed9c5680f22aa4722e6e07ebf3aa3441 commit 88046ad9e8e333259ae6fb4a295a9931a1a0e47f commit 6ddc43d1bf9b3ea3ee5db8c50d56a98fe4db4c97 (I was about to offer the shim to OpenSSH, but license collision - ours is GPLed, which is a bit annoying. OTOH it is from a single author, so if there is interest here, maybe we can ask Emmanuel Deloget whether he's fine with dual-licensing this piece of code)> 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? Of course that's only really a worthwhile exercise if OpenSSH > would be willing to use it, and it would be good to limit the scope of > the problem to "things needed by the handful of projects that really > need this" rather than "the entire OpenSSL 1.0 API".The catch here is: the shim does not provide "the OpenSSL 1.0 API" - it provides the OpenSSL *1.1* API to projects being compiled against 1.0. In other words: the compat libary alone won't help, the code needs to be converted to use the accessor functions, and everything needs to be very well tested. So even having the compat library/shim around does not make this trivial. Note: I'm no way trying to tell either folk what to do. I'm just explaining what we did over at OpenVPN, and stating that while it was quite a bit of work, we're happy that we got it done. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
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]
On Mon, Oct 16, 2017 at 09:35:52AM +0200, Gert Doering wrote:> On Sun, Oct 15, 2017 at 10:51:46PM +0100, Colin Watson wrote: > > 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? Of course that's only really a worthwhile exercise if OpenSSH > > would be willing to use it, and it would be good to limit the scope of > > the problem to "things needed by the handful of projects that really > > need this" rather than "the entire OpenSSL 1.0 API". > > The catch here is: the shim does not provide "the OpenSSL 1.0 API" - it > provides the OpenSSL *1.1* API to projects being compiled against 1.0.Right, I realise that but I put it badly. What I meant to say was something like "1.1 equivalents for the API provided by 1.0". Anyway, this is probably moot given Ingo's reply. -- Colin Watson [cjwatson at debian.org]