This Time Self-Hosted
dark mode light mode Search

LibreSSL, OpenSSL, collisions and problems

Some time ago, on the gentoo-dev mailing list, there has been an interesting thread on the state of LibreSSL in Gentoo. In particular I repeated some of my previous concerns about ABI and API compatibility, especially when trying to keep both libraries on the same system.

While I hope that the problems I pointed out are well clear to the LibreSSL developers, I thought reiterating them again clearly in a blog post would give them a wider reach and thus hope that they can be addressed. Please feel free to reshare in response to people hand waving the idea that LibreSSL can be either a drop-in, or stand-aside replacement for OpenSSL.

Last year, when I first blogged about LibreSSL, I had to write a further clarification as my post was used to imply that you could just replace the OpenSSL binaries with LibreSSL and be done with it. This is not the case and I won’t even go back there. What I’m concerned about this time is whether you can install the two in the same system, and somehow decide which one you want to use on a per-package basis.

Let’s start with the first question: why would you want to do that? Everybody at this point knows that LibreSSL was forked from the OpenSSL code and started removing code that has been needed unnecessary or even dangerous – a very positive thing, given the amount of compatibility kludges around OpenSSL! – and as such it was a subset of the same interface as its parent, thus there would be no reason to wanting the two libraries on the same system.

But then again, LibreSSL never meant to be considered a drop-in replacement, so they haven’t cared as much for the evolution of OpenSSL, and just proceeded in their own direction; said direction included building a new library, libtls, that implements higher-level abstractions of TLS protocol. This vaguely matches the way NSS (the Netscape-now-Mozilla TLS library) is designed, and I think it makes sense: it reduces the amount of repetition that needs to be coded in multiple parts of the software stack to implement HTTPS for instance, reducing the chance of one of them making a stupid mistake.

Unfortunately, this library was originally tied firmly to LibreSSL and there was no way for it to be usable with OpenSSL — I think this has changed recently as a “portable” build of libtls should be available. Ironically, this wouldn’t have been a problem at all if it wasn’t that LibreSSL is not a superset of OpenSSL, as this is where the core of the issue lies.

By far, this is not the first time a problem like this happens in Open Source software communities: different people will want to implement the same concept in different ways. I like to describe this as software biodiversity and I find it generally a good thing. Having more people looking at the same concept from different angles can improve things substantially, especially in regard to finding safe implementations of network protocols.

But there is a problem when you apply parallel evolution to software: if you fork a project and then evolve it on your own agenda, but keep the same library names and a mostly compatible (thus conflicting) API/ABI, you’re going to make people suffer, whether they are developers, consumers, packagers or users.

LibreSSL, libav, Ghostscript, … there are plenty of examples. Since the features of the projects, their API and most definitely their ABIs are not the same, when you’re building a project on top of any of these (or their originators), you’ll end up at some point making a conscious decision on which one you want to rely on. Sometimes you can do that based only on your technical needs, but in most cases you end up with a compromise based on technical needs, licensing concerns and availability in the ecosystem.

These projects didn’t change the name of their libraries, that way they can be used as drop-rebuild replacement for consumers that keep to the greatest common divisor of the interface, but that also means you can’t easily install two of them in the same system. And since most distributions, with the exception of Gentoo, would not really provide the users with choice of multiple implementations, you end up with either a fractured ecosystem, or one that is very much non-diverse.

So if all distributions decide to standardize on one implementation, that’s what the developers will write for. And this is why OpenSSL will likely to stay the standard for a long while still. Of course in this case it’s not as bad as the situation with libav/ffmpeg, as the base featureset is going to be more or less the same, and the APIs that have been dropped up to now, such as the entropy-gathering daemon interface, have been considered A Bad Idea™ for a while, so there are not going to be OpenSSL-only source projects in the future.

What becomes an issue here is that software is built against OpenSSL right now, and you can’t really change this easily. I’ve been told before that this is not true, because OpenBSD switched, but there is a huge difference between all of the BSDs and your usual Linux distributions: the former have much more control on what they have to support.

In particular, the whole base system is released in a single scoop, and it generally includes all the binary packages you can possibly install. Very few third party software providers release binary packages for OpenBSD, and not many more do for NetBSD or FreeBSD. So as long as you either use the binaries provided by those projects or those built by you on the same system, switching the provider is fairly easy.

When you have to support third-party binaries, then you have a big problem, because a given binary may be built against one provider, but depend on a library that depends on the other. So unless you have full control of your system, with no binary packages at all, you’re going to have to provide the most likely provider — which right now is OpenSSL, for good or bad.

Gentoo Linux is, once again, in a more favourable position than many others. As long as you have a full source stack, you can easily choose your provider without considering its popularity. I have built similar stacks before, and my servers deploy stacks similarly, although I have not tried using LibreSSL for any of them yet. But on the desktop it might be trickier, especially if you want to do things like playing Steam games.

But here’s the harsh reality, even if you were to install the libraries in different directories, and you would provide a USE flag to choose between the two, it is not going to be easy to apply the right constraints between final executables and libraries all the way into the tree.

I’m not sure if I have an answer to balance the ability to just make the old software use the new library and the side-installation. I’m scared that a “solution” that can be found to solve this problem is bundling and you can probably figure out that doing so for software like OpenSSL or LibreSSL is a terrible idea, given how fast you should update in response to a security vulnerability.

Comments 9
  1. Any hope of the LibreSSL devs changing their mind and renaming all their functions to avoid collisions ? As it stands, the chances of LibreSSL making headways in the Linux ecosystem are close to zero, which is a real pity.

  2. That’s something you should ask the LibreSSL developers, but I guess the answer is “no chance.”They don’t particularly care about the Linux ecosystem, they are OpenBSD devs to the core and this is just one more thing for which they’ll say they are superior to Linux.

  3. Since the purpose is to be a drop in replacement for OpenSSL, no, zero chance.The idea is that if you give enough of a fuck to switch over, you do it.

  4. The problem is, that’s *not* its purpose according to its own developers. It is *not* a drop-in replacement, because it has different APIs now and has had different ABIs from day one, so “drop-in” is not an option.Other than that, insisting it is a drop-in replacement will only makes its adoption more difficult.

  5. Well, it’s a shame that it’s not a drop-in replacement, but at least it seems to be usable from a “compile it into your system from source” standpoint. So far, in using it on my day-to-day workstation, I’ve only run into a handful of packages that don’t work with it (yet). So I’m hopeful that OpenSSL will get used less and less and LibreSSL will get used more and more.

  6. It is worth noting that Exherbo has also considered this problem; They chose to use a ‘suboption’ called a ‘provider’ (…. Naturally, you have to make the providers:libressl and providers:openssl mutually exclusive, as you say.It works quite well, many users are indeed finding libressl works quite nicely. A few bad actors remain, notably mysql, but it works well.Since it works with Exherbo, should be fine on Gentoo too.

  7. Somebody clearly needs some text comprehension. Whatever your distribution does for its 50 users, it can’t solve the impossible co-presence of the two libraries, their conflicts or the fact that any random 3rd party binary package can of course only work with OpenSSL.But sure, keep thinking you’re better than others just because you thought about “new concepts”.

  8. Respectfully, I think you are taking a little too critical and hostile a tone towards someone simply echoing what others have found. Yes, the problem with binary packages still exists and he wasn’t contradicting anything you said. I agree, the 3rd party binary package problem is completely unsolved. Rather, he was saying what other people in the ecosystem have been doing, and that building real linux systems works very well with libressl.He never said that Exherbo was in any way better than Gentoo, nor that the new concepts in any way made Exherbo a better distribution.He was just joining the conversation to let others know what people have thought about. I think you may have been a little harsh, perhaps because of his chosen distro.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.