Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL
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
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
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".