Colin Watson <cjwat...@debian.org> schrieb:
> 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].
Isn't that ultimately similar to the "portable ssh" efforts in general?
Realistically OpenSSL 1.0.2 will be gone from all major distros in at
least a year, so there will a practical need for this shim one way or the other.
> * Convince people to keep OpenSSL 1.0 on life support in Debian for a
> while longer. This probably only postpones the problem, but it might
> be helpful anyway. One possibility which might help would be to
> split libcrypto into separate runtime and development packages, and
> then drop just libssl 1.0; this would allow keeping around packages
> which only use libcrypto, while still being able to make progress on
> packages that use libssl, which AIUI is the more pressing problem.
Keeping libcrypto on life support for say another year is probably
the least bad option for now. I haven't done any exact research but the majority
of security issues surely affects libssl.
> * Convince people to package LibreSSL for Debian in parallel. As noted
> in the log of this bug, there are some problems to solve there, both
> technical and political, but they don't seem insurmountable. Of
> course it would mean another SSL implementation in the archive, which
> I realise is probably not the favourite outcome for the security
> team.
Ack. Michael Stone already discussed this to great extent and there's not
really much to add. I doubt LibreSSL is a suitable option for Debian in
general.
> * 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.
I doubt SLES or RHEL would accept this as a viable approach for sshd in their
next enterprise releases. If no officially maintained shim appears, we can
discuss this a one of the options in a year I'd say.
> * Take Kurt's patch to switch to the 1.1 API. Fedora have done this.
> I'm extremely reluctant to do this because it's a >3000-line patch
> touching most of OpenSSH's cryptographic internals, which is bound to
> produce lots of difficult conflicts on pretty much every new upstream
> release. We carry another patch of a similar size (GSS-API key
> exchange), but at least the bulk of that is a matter of plugging new
> mechanisms into relatively general interfaces, and I more or less
> understand how it all works; even so, that patch alone has delayed my
> uploads of some new upstream releases by weeks or more. The 1.1 API
> patch would probably be more than I can cope with maintaining for the
> long term.
I agree that's not something for Debian alone. But if there were a properly
maintained semi official shim use by all major distros (and this way ultimately
the vast majority of openssh users!), might be different though?
> 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. (If somebody wants to package it separately for
> the extra features, that's their affair, but it wouldn't solve the
> problem at hand.)
Certainly not :-)
Cheers,
Moritz
