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

[Moritz Mühlenhoff]

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

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

[Adam Borowski]

On Tue, Oct 17, 2017 at 10:26:06PM +0200, Guus Sliepen wrote:
> I see two main forces determining which fork of a library will be used:
> either distributions themselves will choose based on technical and other
> merits, or important applications will favor one of the forks, forcing
> the decision for distributions. OpenSSH is now applying some force, I
> have no idea what programs are out there that can only work with
> OpenSSL. I assume those that moved to OpenSSL 1.1 and ditched OpenSSL
> 1.0 compatibility, but I wonder how many there are.
> 
> It would be interesting to recompile all packages that Build-Depend:
> libssl-dev with LibreSSL, and see what actually breaks...

It occured to me that I can provide data on how much such a rebuild would
take.  Of course, a fat elebenty-core machine with gobs of RAM can do the
whole archive in hours, while a shit ARM SoC takes over two months, but
proportions should be roughly same.

Packages with an OpenSSL build-dependency are pretty heavy: there are 714
ones depending on libssl-dev, taking 7.7% of total archive rebuild time.
As for libssl1.0-dev, it's 271 packages taking 2.5% of time.

On said shit SoC that's 5 and 1.6 days respectively.  I don't know what's
under your desk, but I don't suspect you of using a machine that can't do
such a rebuild under a day.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

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

[Michael Stone]

On Tue, Oct 17, 2017 at 10:26:06PM +0200, Guus Sliepen wrote:

On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:

On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
> despite fears of OpenBSD only caring about themselves, I have found that
> it is easier to compile LibreSSL for various platforms (even non-POSIX
> ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
> is ridiculous, as it is OpenSSL iself that has changed its API in a
> non-backwards compatible way that is now causing this discussion.

It is not ridiculous to point out that LibreSSL is released every six months
and supported for one year after release, while OpenSSL is supported for at
least 2 years, and 5 years for LTS releases.


That is certainly not ridiculous. But, I had a look at the release plan
for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
it seems there only is one LTS release, namely 1.0.2, which will be
supported until the very end of 2019. 1.1.0 is only supported until
September 2018. In that context it is strange that we switched to 1.1.0
in stretch already. Let's hope there is an LTS for 1.1.x in time for
buster.


I'd expect a 1.1.1 release with a relatively small delta (no major API 
changes, and a relatively straightforward backporting effort) from 1.1. 
The LTS is most valuable for an API branch no longer being actively 
developed, and if 1.1.1 was followed by 1.2, I'd expect LTS for 1.1.1.



It's not unrealistic to think
that a Debian stable could release with a LibreSSL that's already
unsupported upstream. It is also not ridiculous to point out that a number
of distributions have an interest in long term maintenance of released
versions of OpenSSL, while there is no such community around LibreSSL.


Maybe not currently for Debian or Fedora derivatives, but some
distributions (Alpine, OpenELEC amongst others) have switched to
LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
option.


Without getting into a discussion of various distributions, suffice it 
to say that these are not ones known for long term binary support.



As I continue to think about it, it may actually end up being better to
embed a constrained subset of LibreSSL in OpenSSH than worry about either
maintaining the entire LibreSSL package over a period of years, or fork.


I don't see why it couldn't be in its own package even if OpenSSH was
the only user. It doesn't change the maintenance burden.


Because the parts of libressl used in openssh (a subset of libcrypto) 
historically have had fewer problems then the mess of stuff in libssl.  
The attack surface of that subset of functions in ssh is a lot lower 
than "any package that uses ssl and happens to link to libressl".


Mike Stone

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

[Sebastian Andrzej Siewior]

On 2017-10-17 11:51:19 [+0100], Colin Watson wrote:
> > I didn't even figure out if they want to alter their code or not.
> 
>   
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036370.html

let me check.

> I don't see any benefit in conducting a discussion in which we assume
> bad faith.  There are different opinions on what makes for a good API
> transition, and pressures coming from different choices upstream
> (remembering that Debian's immediate upstream for OpenSSH is OpenSSH
> Portable, which itself has OpenBSD as an upstream) and from available
> development and review time, but simplifying that as "playing hard to
> get" isn't particularly helpful.

I'm sorry.

Sebastian

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

[Guus Sliepen]

On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:

> On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
> > despite fears of OpenBSD only caring about themselves, I have found that
> > it is easier to compile LibreSSL for various platforms (even non-POSIX
> > ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
> > is ridiculous, as it is OpenSSL iself that has changed its API in a
> > non-backwards compatible way that is now causing this discussion.
> 
> It is not ridiculous to point out that LibreSSL is released every six months
> and supported for one year after release, while OpenSSL is supported for at
> least 2 years, and 5 years for LTS releases.

That is certainly not ridiculous. But, I had a look at the release plan
for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
it seems there only is one LTS release, namely 1.0.2, which will be
supported until the very end of 2019. 1.1.0 is only supported until
September 2018. In that context it is strange that we switched to 1.1.0
in stretch already. Let's hope there is an LTS for 1.1.x in time for
buster.

> It's not unrealistic to think
> that a Debian stable could release with a LibreSSL that's already
> unsupported upstream. It is also not ridiculous to point out that a number
> of distributions have an interest in long term maintenance of released
> versions of OpenSSL, while there is no such community around LibreSSL.

Maybe not currently for Debian or Fedora derivatives, but some
distributions (Alpine, OpenELEC amongst others) have switched to
LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
option.

I see two main forces determining which fork of a library will be used:
either distributions themselves will choose based on technical and other
merits, or important applications will favor one of the forks, forcing
the decision for distributions. OpenSSH is now applying some force, I
have no idea what programs are out there that can only work with
OpenSSL. I assume those that moved to OpenSSL 1.1 and ditched OpenSSL
1.0 compatibility, but I wonder how many there are.

It would be interesting to recompile all packages that Build-Depend:
libssl-dev with LibreSSL, and see what actually breaks...

> As I continue to think about it, it may actually end up being better to
> embed a constrained subset of LibreSSL in OpenSSH than worry about either
> maintaining the entire LibreSSL package over a period of years, or fork.

I don't see why it couldn't be in its own package even if OpenSSH was
the only user. It doesn't change the maintenance burden.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

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

[Colin Watson]

On Mon, Oct 16, 2017 at 01:07:43PM -0400, Michael Stone wrote:
> My understanding is that the libressl project does not support a release for
> the length of a debian release cycle, and does not commit to API stability
> for debian-cycle periods.

The LibreSSL website currently says one year.

One relevant data point is that OpenSSH 7.6p1 seems to build and run
fine against LibreSSL 2.0.0 (the first public release, from July 2014),
so I'm not very concerned about API stability from the point of view of
OpenSSH.  Your wider concerns may well be reasonable for an
externally-packaged library though; I don't have enough experience with
SSL library maintenance to be able to say.

-- 
Colin Watson   [cjwat...@debian.org]

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

[Colin Watson]

On Mon, Oct 16, 2017 at 10:00:50PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-16 17:29:09 [+0100], Colin Watson wrote:
> > 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

Ingo replied to me privately (but giving me permission to use the
information any way I saw fit) with this:

  Here is one example of a posting where it is explained
  in a comment:
  
https://plus.google.com/u/0/+IngoSchwarze/posts/WQ9ouupTVgx
  
  In other words, an officially maintained library that *uses* the
  OpenSSL-1.0 API (i.e. links against existing existing libcrypto
  lbraries) and that *exports* the OpenSSL-1.1 API for application
  programs to link against, such that application programs using the
  OpenSSL-1.1 API can run on systems providing an OpenSSL-1.0 library.

> I didn't even figure out if they want to alter their code or not.

  https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036370.html

> > 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.

I don't see any benefit in conducting a discussion in which we assume
bad faith.  There are different opinions on what makes for a good API
transition, and pressures coming from different choices upstream
(remembering that Debian's immediate upstream for OpenSSH is OpenSSH
Portable, which itself has OpenBSD as an upstream) and from available
development and review time, but simplifying that as "playing hard to
get" isn't particularly helpful.

> > 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 helped to draft that section, so I'm aware of what it says.  Note that
it's a "should", and that it's not currently in the list of release
standards for packages in buster
(https://release.debian.org/buster/rc_policy.txt).  According to our
current policy standards, it would certainly be a bug to have an
embedded copy, it might well make various people cross with me, but it's
something we're allowed to trade off against other considerations if
they're sufficiently compelling.

We could, for example, reasonably embed LibreSSL for a while and then
switch to an externally-packaged library if it looks like API stability
will be good enough for our needs.

-- 
Colin Watson   [cjwat...@debian.org]

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

[Michael Stone]

On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:

despite fears of OpenBSD only caring about themselves, I have found that
it is easier to compile LibreSSL for various platforms (even non-POSIX
ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
is ridiculous, as it is OpenSSL iself that has changed its API in a
non-backwards compatible way that is now causing this discussion.


It is not ridiculous to point out that LibreSSL is released every six 
months and supported for one year after release, while OpenSSL is 
supported for at least 2 years, and 5 years for LTS releases. It's not 
unrealistic to think that a Debian stable could release with a LibreSSL 
that's already unsupported upstream. It is also not ridiculous to point 
out that a number of distributions have an interest in long term 
maintenance of released versions of OpenSSL, while there is no such 
community around LibreSSL.


You are correct, though, that the OpenSSL and LibreSSL code bases will 
continue to diverge, from both directions. I think that's the biggest 
impediment to creating an OpenSSL 1.0 compatability layer for 
OpenSSH--over time, neither OpenSSL nor LibreSSL have any interest in 
confining themselves to that API, and it's clear that OpenSSH will track 
LibreSSL's API rather than the old OpenSSL API in the long term.


As I continue to think about it, it may actually end up being better to 
embed a constrained subset of LibreSSL in OpenSSH than worry about 
either maintaining the entire LibreSSL package over a period of years, 
or fork.


Mike Stone

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

[Guus Sliepen]

On Mon, Oct 16, 2017 at 05:29:09PM +0100, Colin Watson wrote:

> > * Package name: libressl
[...]
> Furthermore, the OpenSSL maintainers in Debian now want to drop their
> 1.0 compatibility packages, which the Debian OpenSSH packages rely on.
> I can't exactly fault them for wanting to reduce their maintenance
> burden, but it is going to put me in a very difficult position soon; and
> I assume that they don't actually want to break OpenSSH either.

Sounds like a great opportunity: the libressl package can fill the 1.0
API void left behind without libressl and openssl packages having to
conflict with each other (except possibly for the -dev packages).

Personally I think LibreSSL is in a much better shape than OpenSSL, and
despite fears of OpenBSD only caring about themselves, I have found that
it is easier to compile LibreSSL for various platforms (even non-POSIX
ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
is ridiculous, as it is OpenSSL iself that has changed its API in a
non-backwards compatible way that is now causing this discussion.

> The OpenSSH developers are starting to talk about bundling LibreSSL to
> avoid this problem [3], noting that OpenBSD and Apple already link
> OpenSSH against LibreSSL.  (Note that OpenSSH only uses libcrypto, not
> libssl, so while this has all the usual problems of bundling, the
> exposure isn't quite as horrific as it might first seem.)

I'd strongly favor having proper packages for LibreSSL. I'd happily
switch tinc over to depending on them instead of on OpenSSL packages.

>  * 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.

If it was only needed temporarily until OpenSSH implemented OpenSSL 1.1
compatibility, I'd say fine, but if that's not going to happen, then I'd
avoid going down this road.

>  * 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 agree.

>  * 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.

That sounds just as bad as maintaining a patch for OpenSSH to support
OpenSSL 1.1.

> Out of all of these, I think the option that I think has the fewest
> downsides overall is to convince people to package LibreSSL, but I'm not
> myself in a position to contribute to that effort.
> 
> Does anyone have thoughts or other options, or want to help?

Since I'd be a user of it I'd be willing to help.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

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

[Sebastian Andrzej Siewior]

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

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

[Michael Stone]

On Mon, Oct 16, 2017 at 05:29:09PM +0100, Colin Watson wrote:

Out of all of these, I think the option that I think has the fewest
downsides overall is to convince people to package LibreSSL, but I'm not
myself in a position to contribute to that effort.

Does anyone have thoughts or other options, or want to help?


My understanding is that the libressl project does not support a release 
for the length of a debian release cycle, and does not commit to API 
stability for debian-cycle periods. (The openbsd model historically is 
to break ABI and even API between releases, in order to minimize 
compatability code, which works with their rebuild-the-world release 
model.) Is there any sign that if debian packages libressl in order to 
use openssh, debian would not end up being the de facto maintainers of 
an unsupported years-old libressl release by the end of a debian 
stable release cycle (not to mention debian LTS)? I think that in 
practical terms that would leave us worse off than settling on a 
compatability layer that's shared with other distributions.


Mike Stone

Re: [Pkg-openssl-devel] Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

[Kurt Roeckx]

On Mon, Oct 16, 2017 at 05:29:09PM +0100, Colin Watson wrote:
> 
> 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].

My understanding is they would only be happy if we turn that file
into a library they can link to. It would require that all the
functions get renamed, which should be easy to do in a header
file.

> 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.

The question we got asked is to add that compatibility in the
openssl 1.0 package, which really doesn't solve anything.



Kurt

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

[Colin Watson]

On Sat, Jul 12, 2014 at 12:06:27AM +0200, Toni Mueller wrote:
> * Package name: libressl
>   Version : 2.0.0
>   Upstream Author : The OpenBSD project, the OpenSSL project et al.
> * URL : http://www.libressl.org/
> * License : BSD, OpenSSL, SSLeay, Public Domain.
>   Programming Lang: C
>   Description : SSL library, forked from OpenSSL
> 
> 
> LibreSSL strives to maintain API compatibility with OpenSSL, but
> do away with all the cruft.
> 
> After a long series of OpenSSL problems, recently highlighted by
> the infamous Heartbleed bug, a group inside OpenBSD decided to
> fork OpenSSL and adapt the code to modern coding standards.
> Along the way, a lot of compatibility with older architectures
> and toolchains was discarded.

[I won't quote everything, but people replying to this should probably
read the bug log in the BTS first.]

This was some years ago, and in the meantime Toni said it was too much
for them at the moment and retitled the bug to RFP.


In the meantime, the situation with OpenSSH is becoming critical.
OpenSSL has moved to a new API in version 1.1 which does a much better
job of making internal data structures opaque, but requires significant
changes to application code.  (LibreSSL has not yet adopted this API.)
OpenSSH needs to continue working on OSes that only have OpenSSL 1.0,
not to mention with LibreSSL.

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'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.

Furthermore, the OpenSSL maintainers in Debian now want to drop their
1.0 compatibility packages, which the Debian OpenSSH packages rely on.
I can't exactly fault them for wanting to reduce their maintenance
burden, but it is going to put me in a very difficult position soon; and
I assume that they don't actually want to break OpenSSH either.

The OpenSSH developers are starting to talk about bundling LibreSSL to
avoid this problem [3], noting that OpenBSD and Apple already link
OpenSSH against LibreSSL.  (Note that OpenSSH only uses libcrypto, not
libssl, so while this has all the usual problems of bundling, the
exposure isn't quite as horrific as it might first seem.)


At the moment I can see the following somewhat realistic paths forward:

 * 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.

 * 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.

 * 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.

 * 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 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,