[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Colin Watson <cjwatson@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

>  * 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 :-)


Reply to: