LibreSSL languishes on Linux

Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!

Free trial subscription

Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.

The LibreSSL project has been developing a fork of the OpenSSL package since 2014; it is supported as part of OpenBSD. Adoption of LibreSSL on the Linux side has been slow from the start, though, and it would appear that the situation is about to get worse. LibreSSL is starting to look like an idea whose time may never come in the Linux world.

OpenSSL provides the low-level plumbing for a number of important cryptographic functions; it provides TLS and SSL implementations and a number of utilities for functions like key generation and signing. Most programs that need to communicate securely over the network end up linking to OpenSSL for that functionality. OpenSSL has always had a bit of a strange position in the Linux world due to its special license, which contains an advertising requirement that is deemed to be incompatible with the GNU General Public License. To get around this problem, many GPL-licensed programs include a special exception allowing linking to OpenSSL.

Our systems are built upon a frightening number of crucial components that everybody uses, but which nobody maintains. In 2014, the disclosure of the Heartbleed vulnerability made it clear that OpenSSL was one of those components; it had languished with minimal development effort for years. As a result, the OpenSSL code base had filled up with unmaintained cruft — and catastrophic vulnerabilities. Heartbleed was seen as being bad enough that Something Had To Be Done to improve that situation.

One of the things that was done was the establishment of the Core Infrastructure Initiative (CII) by the Linux Foundation; its goal was to direct resources to crucial components that were insufficiently supported. The CII has faded somewhat over the years, but it did succeed in bringing developers to projects like OpenSSL and patching over many of our worst problems with unsupported infrastructure.

The OpenBSD project, as is its wont, took its own approach; the result was the LibreSSL fork. Within a couple weeks of the Heartbleed announcement, the LibreSSL developers claimed to have removed about half of the code forked from OpenSSL. The OpenBSD distribution switched over to the new library, and the project seemed to be off to a running start.

Over nearly six years, LibreSSL has remained a viable project, producing regular releases as it goes. Since the 2.9.0 release at the end of 2018, the project has merged 1,554 patches from 36 developers, showing that it is definitely alive and getting work done.

The OpenSSL project, though, has merged over 5,000 patches during approximately the same time period; that work came from 276 developers. Just as importantly, much of that work is supported by organizations that depend on OpenSSL; large contributors include Oracle, Siemens, Akamai, Red Hat, IBM, VMware, Intel, and Arm — along with the OpenSSL Software Foundation itself. This level of support has enabled the OpenSSL project to address many of its longstanding problems; by 2016, the project was on a much more stable footing. Security problems still exist, of course — this is software we are talking about, after all — but they are dealt with in a coordinated way and people don't worry about OpenSSL as they once did.

One result of all this work is that Linux distributions have, in general, not shifted away from OpenSSL. Two distributions that did attempt to provide LibreSSL support were Alpine Linux and Gentoo. Alpine Linux supported LibreSSL as its primary TLS library for a while, but switched back to OpenSSL with the 3.9.0 release in January 2019. Gentoo never tried to switch over completely, but it supports LibreSSL as an alternative.

That support will end in February, though. Gentoo developer Michał Górny first suggested this change at the end of December, saying that LibreSSL offers no benefit over OpenSSL at this point while imposing a lot of costs. In particular, he complained about the large number of packages that require patches to work with LibreSSL and the constant stream of regressions that the project must deal with.

Various other developers were quick to support this change. Hanno Böck, who claimed to be the first to have built Gentoo with LibreSSL, said:

Anthony Basile, who is the current lead for LibreSSL on Gentoo, agreed, saying that LibreSSL is "more of a hassle than it's worth".

The primary opposition came from Peter Stuge, who asserted that "Gentoo is about choice and this particular component is one of the most important in a system". He also made the point that monocultures are not healthy in any part of the system, so it is good to support alternatives like LibreSSL. Even Stuge seemed to agree, though, that supporting LibreSSL at its current level was not sustainable and didn't seem to make sense. But he thought LibreSSL should remain part of the distribution for those who want to go to the trouble to try to use it.

Even that may be a bit challenging, since it is not possible to install both OpenSSL and LibreSSL on the same system. But that is the approach that is being taken; LibreSSL will remain in the Gentoo repository — for now — but it will be "masked" to prevent its installation by users who have not taken extra action to enable it. As noted in the announcement, the Gentoo project will also stop carrying patches to make other packages work with LibreSSL:

It has now become difficult indeed to find a Linux distribution that is still trying to support LibreSSL over OpenSSL.

One might try to argue that the LibreSSL fork has failed, but that is clearly not the case; it is under active development and is used by at least a couple BSD variants. One could argue, though, that this fork was done too soon. This project was created only a couple of weeks after the disclosure of Heartbleed, which seems rather too early to conclude that the problems with OpenSSL itself could not be addressed without a fork. OpenSSL turned out not to be as unfixable as it seemed, and OpenBSD is saddled with the cost of carrying its own fork rather than benefiting from the rejuvenated OpenSSL effort.

Perhaps, someday, OpenSSL will run aground again and the world will be glad that there is a LibreSSL project out there to fall back to. Alternatives are good, and the ability to create those alternatives is one of the great strengths of free software. But alternatives can also be expensive to support, and it would appear that the Linux community has decided that this particular alternative is not worth the price.

Did you like this article? Please accept our trial subscription offer to be able to see more content like it and to participate in the discussion.