LibreSSL Languishes on Linux
lwn.net
lwn.net
That about sums it up. The LibreSSL developers decided not to maintain even source compatibility, let alone binary compatibility. If application authors don't want the maintenance burden of supporting extra code paths for both, and distribution maintainers aren't happy keeping patchsets up to date, then that's about it.
And it sounds like OpenSSL is in much much better shape (both the code and the community around it) than when LibreSSL forked. This is a good thing! It means all the concern raised after Heartbleed actually functioned as intended, and turned OpenSSL into a healthy project.
I think it's also a good thing that LibreSSL continues to exist and that it is used in some of the BSDs. Having competing, well-maintained implementations is great, even if they're not drop-in replacements for each other. If OpenSSL falls into disrepair again, it means that an alternative is already available, even if there are switching costs.
But... the article also says:
> ... it is not possible to install both OpenSSL and LibreSSL on the same system.
That combination -- not-compatible and not-coexisting -- sounds rough.
Sure, in the long run, when you've overtaken the original and sent it into obsolescence. I.e. at approximately that point where even the original would have deviated from compatibility.
In the short run, drop-in replace, or perish.
Linux still follows POSIX. I can make a program that is source-code compatible with GNU/Linux, Solaris, Cygwin, MacOS, Android/Bionic, ...
If I can't do that between two SSL implementations, something is wrong.
Imagine you're maintaining some program that intensively uses OpenSSL. It's 2014-ish, and some LibreSSL people come to you and tell you that you're using deprecated API and you need to upgrade for compatibility with LibreSSL. Sure, it's an improvement and maintains compatibility with OpenSSL, so why not.
Then OpenSSL 1.1 comes with some more API changes. You end up adding #if conditions to support both OpenSSL versions. And the next thing you realize, you've just broken LibreSSL because it pretends to be OpenSSL 2.0.0.
And when you patch it, you realize you're adding another ticking time bomb because LibreSSL will probably support the new API at some point too and you will have to add yet another version check to the code.
I am not surprised that somewhere in middle of that process upstreams stop taking LibreSSL seriously.
Consider an analogy to shell-scripting -- there are different shells ("bash", "dash", "zsh") which have substantial overlap (insofar as they largely support traditional POSIX). Someone writing a script/program can target a specific flavor ("#!/usr/bin/env bash") and get more features, or they can write conservative code and let downstream policy determine the shell ("#!/bin/sh"). General-purpose distros (like Debian/Redhat) don't seem to have a problem with supporting them side-by-side.
I'm more than a little rusty on the mechanics of dependency-management in C... but shouldn't it allow some analogous arrangement where an app either (a) signals a requirement for a specific implementation or (b) signals ambivalence/deference (and limits itself to common APIs).
(This, of course, only makes sense if the developers of LibreSSL/OpenSSL and of the distros believe that it's better to coexist+compete than to consolidate. The tenor of the LWN article seems to convey a XOR mentality, but if both projects have independently healthy teams, then... maybe they prefer friendly coopetition...)
What there was no shortage of then or now is opinionated, well maintained maintained crypto libraries. There's nothing wrong with creating a new opinionated crypto library of course, that's how progress is made, but they are like weeds. By breaking backward compatibility that is what LibreSSL created, but in doing that they threw their hat into a highly competitive ring Darwin will sort out by killing almost all of the contestants.
But in the opinionated crypto library ring, LibreSSL is a weak entrant. Compared to some of it's competitors it's just a minor polish on OpenSSL, making hardly worth of effort of switching really. This outcome looked inevitable to me.
Well, clarly not, the LibreSSL developers seems to have managed.
I haven't been following OpenSSL, but to what extend have the library actually been cleaned up? One of the complaints the OpenBSD developers had was broken memory allocation (well, de-allocation really), heaps of spaghetti ifdefs, support for non-existing platforms, hardcoded randomness, exposed private APIs and other weirdness. If the LibreSSL team managed to yank out half of the code, wouldn't it be reasonable to assume that the OpenSSL developers have yanked out at least some code and rewritten thousands of lines?
Given the massive reworking of the OpenSSL code by the OpenBSD, I guess I just question whether or not the OpenSSL developers have been through a similar process.
I wouldn't go out of my way to use LibreSSL.
For me this theory was disproved by Heartbleed.
This was one of the advantages of just linking with LibreSSL on Linux.
While I don't test my software directly on OpenBSD, I do test it on both Debian stable and VoidLinux and using valgrind on Debian used to cause some pain.
This (as the article points out), may be true now but was definitely NOT true back when heartbleed was announced.
I understand that they've cleaned up the OpenSSL codebase significantly. I wish it could have happened without the threat of an alternative implementation, but maybe adversarial environment is just part of how open-source software gets better?
Until now, OpenSSL, LibreSSL and BoringSSL were using non-viral licenses and thus used different licenses for different source code files. (Eg Google would license their patches under ISC so it could be adopted by the LibreSSL team).
With OpenSSL becoming Apache 2 licensed, it is no longer "compatible" with the mindset of certain projects. For example OpenBSD does not distribute Apache 2 code. I bet that Apple will also stay on LibreSSL for the same reason.
Apple prefers Apache 2 for its own code (LLVM, CUPS, Swift).
They can. You can get a permission from all (or most) contributors and rewrite/remove all others . You can relicense to a compatible license (gpl2 -> GPL 3) You could license all new contributions under the new license and retain all old code under the previous license (for example moving from MIT to APL). There’s probably other options, it relicensing is not impossible, though sometimes painful.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
----
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/LICEN...
And this is likely the condition the article refers to
3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
"This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
Being able to switch much of your infrastructure to an infrastructure implementation even if it is not possible to switch everything to it is quite a valuable piece of flexibility.
I did a quick search and a few packages seems to depend on libressl, there are patches going into one or two python modules, qt4 and I see some patches are fetched from Void Linux. So my naive guess is that the nixos support for libressl depends on the efforts from Void Linux and possibly Gentoo. (I assume some self-written patches as well)
The Void Linux developers have been discussing switching back to OpenSSL: https://github.com/void-linux/void-packages/issues/20935
Am I wrong to be surprised that the Linux community is okay with this? I guess because it's still considered open source, and isn't a part of kernel?
Older versions still use the old license, which is the problematic one.
Some Linux distros have tried to use the "system library" exception in GPL to argue that it's fine.
I use LibreSSL and have been from early days when it was quite a bit better and there was no real reason not to but I read more and more that OpenSSL has fixed most of the issues that prompted the start of Libre and that the compatibility issues are causing some pains.
My use of Libre on Gentoo is completely seamless and simply required a USE flag change but if support end for it then it won't be a problem I suppose.
I agree with the choice argument, however; Gentoo supports configurations that are more esoteric and more of a hassle than this, some of which I do actually need, but as far as a TSL library goes, I personally do not notice any real difference between the two and it's a background library.
Actually, that raises an interesting point: Are there other libraries that could be used? That is, if the goal is diverse implementations, openssl and a fork of openssl are too little of a difference. There's bearssl which looks even more different (although then there's the question of being API-incompatible), and boringssl (which is... another openssl fork...). Or is this going to end up like browser engines where if you want to be compatible enough to swap in you have to implement 30 years of features which is to say that nobody will ever do it?
Rustls is excellent, but has a Rust API and does not do I/O. Its a great alternative for Rust applications but, for C/C++ applications, the API wrappers are needed [1][2]
A TLS implementation in the safe subset of Rust, with the guarantees that brings, sounds like a great thing. If it can be used as a drop-in replacement for OpenSSL, even better.
You could argue that it is not mature, but its much more than a curiosity.
[1] https://www.reddit.com/r/rust/comments/b9gd10/mesalink_10_op...
However, now that OpenSSL work to solve "all the problems" is starting to get into releases distribution actually can use (OpenSSL 1.1.1*) and will eventually be able use after extensive effort (OpenSSL 3), I don't think this support for TLS diversity will survive very long. The technical and licensing being solved, only the philosophical/political ones remain, which isn't enough for the large effort required to support multiple TLS libs.
Was easy to use and compiled fairly effortlessly on Windows, so I didn't look much further.
- https://github.com/awslabs/s2n
- https://boringssl.googlesource.com/boringssl
Are these subpar implementations or there are other reasons not to use these?
BearSSL is still beta-quality, s2n has not reached 1.0 (weekly releases are likely to break things), and BoringSSL has no guarantees of API or ABI stability.
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."
That's a small part of the reasons I don't use Gentoo on my main box any more, I got tired on fighting with maintainers who will spend their time writing 50 messages to deny people's requests and yet refuse a 5 lines patch pretending it is too much work or they can't "analyse" it. That behaviour is unfortunately not specific to Gentoo maintainers, of course. So now, I build my software myself, I make or take patches myself: anyway that's how it always ended, having to do the work oneself, but at least it saves the time wasted arguing with maintainers and waiting for them to finally commit the ridiculously small needed patch for months to no avail, and it saves my nerves too.
And don't get me started about "packages not being tested against LibreSSL": it is not like they were being tested against anything; the number of times users have complained that some package was pulling a stream of unneeded dependencies, or conversely was not pulling an actually needed one... because the maintainer had just gone "oh, it worked on my machine" where all dependencies were pre-installed. I am talking about major stuff like web-browsers or toolkits, not some little rarely used piece of software.
Why would this be the case? Do they use the same file names?
[my binary]
/ \ | |then they will have some conflicts (some refer to this as "spewing nasal demons"). Suppose that they both have a function called mutex_lock that touches a global, but OpenSSL added an extra field. Now the behaviour is dependent on which one is picked first. Surprise segfaults? crashes only on strict alignment platforms? unlocked behaviour because the global is named something else? All of these can easily happen.
ELF doesn't have any builtin namespacing, and when compiled with C normally, the C compiler doesn't modify the names to create something like namespacing in the way other languages do.
If you make an extra effort to put them in different places (preferably not in the default linker lookup path and using something like a per-executable RUNPATH rather than a global ld.so.conf to find it), you can have conflicting libraries. But you are playing a dangerous game which wastes everyone's time and effort.
the fix is trivial though. If libA resp. libB load openssl resp. libressl with dlopen(..., RTLD_LOCAL) as they should, neither's symbols will conflict with the other.
In addition it's more performant that way (https://nullprogram.com/blog/2018/05/27/) !
[0] https://github.com/void-linux/void-packages/issues/20935