On 2017-10-16 17:29:09 [+0100], Colin Watson wrote: > [I won't quote everything, but people replying to this should probably > read the bug log in the BTS first.]
It was a lot to read and "they" stumbled over details. > While there does exist a skeletal compatibility layer linked from the > upstream wiki [1], the OpenSSL developers explicitly don't want to > maintain this properly [2], and the OpenSSH developers say that it is > "unversioned, incomplete, barely documented, and seems to be > unmaintained" [3]. Kurt Roeckx proposed a patch to add a compatibility > shim [4], and a number of other projects have done something similar, > but the OpenSSH developers have explicitly said that they do not want to > take that approach [5]. It has never been explained what it is that upstream wants. I get the impression, that they want a compat/shim layer and things have to work https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035497.html I didn't even figure out if they want to alter their code or not. > It's not currently clear to me whether anyone has explicitly talked with > the OpenSSL developers about this problem from the point of view of the > OpenSSH developers, rather than just as users trying to get OpenSSH to > compile against the new version. Kurt is aware of the situation, he is part of upstream. It might be that OpenSSH is playing hard to get. > At the moment I can see the following somewhat realistic paths forward: > > * Accept an upstream bundling of LibreSSL (still hypothetical, but > plausible). I'm sure this would also not be the security team's > favourite outcome, although presumably only a subset of LibreSSL CVEs > would apply to OpenSSH, and it wouldn't be making it available as a > general-purpose library. 4.13. Convenience copies of code > I have heard suggested or thought of some other plans that I don't think > are viable and I will not pursue: > > * Switch to PKIX-SSH, an OpenSSH fork with 1.1 support. This fork adds > new features, making it a one-way transition. With all due respect, > as far as I can tell it's a one-person fork with very limited uptake > compared to OpenSSH, and I don't think it would be wise to switch > Debian over to it. I am somehow in favour of that as I expressed it in #828475. It looks like a one man show, yes, but it looks maintained for more than a decade. Maybe we could check with Fedora/Red Hat what they think about switching to that fork. However a larger user basis does not solve the problem what should be done if PKIX-SSH dies / becomes unmaintained two weeks after the Buster release. And this seems to be your only concern. > (If somebody wants to package it separately for > the extra features, that's their affair, but it wouldn't solve the > problem at hand.) I don't see a reason to package PKIX-SSH if OpenSSH (the root problem) remains. > * Start a team to maintain an OpenSSL 1.1 compatibility layer myself. > Ingo Schwarze persuaded me on openssl-unix-dev that this was a bad > idea. I would be happy if the OpenSSL developers carried this > forward as a proper project rather than just as an unversioned > tarball dump, but I'm not in a position to tell them what to do. this unversioned tar file provides a handful accessors. Instead of accessing ctx->keylength there is a function to be used. That function's content is the direct access to the struct. I don't know what could be there maintained except to add new functions now and then. You can't have it as a .so library and it makes no sense to update that header file because two helpers were added which you don't need. And I assume that most project will drop that header file around 2020 once 1.0.2 gets end of life (like a lot project dropped their 1.0.0 and earlier compat layer while preparing for 1.1). > * Configure OpenSSH using --without-openssl, and use only its internal > crypto functions. I mention this mainly for completeness, but if you > do this you only get a very limited feature set (e.g. only ED25519 > keys); it's a long way off being viable. So no RSA key authentification and probably no gssapi. Sebastian
