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