8 ms·

LibreSSL Languishes on Linux

149 points by lukastyrychtr 6y ago

yjftsjthsd-h 6y ago
Curious; I wonder how Void Linux is managing.
- na85 6y ago
  There's a GitHub issue[0] acting as an RFC open since April 2020. Looks like no conclusion has been reached but a quick skim of the thread reveals lots of sentiments similar to those expressed in TFA. [0] https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935
Blikkentrekker 6y ago
I might as well switch back to OpenSSL on Gentoo reading this. 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.
- yjftsjthsd-h 6y ago
  > I agree with the choice argument, however, Gentoo supports things 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?
  - rapsey 6y ago
    Rustls, a company even developed an OpenSSL compatible API for it.
    - papaf 6y ago
      Just to add to your point. 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] [1] https://github.com/stepancheg/rust-tls-api https://github.com/stepancheg/rust-tls-api [2] https://mesalink.io/ https://mesalink.io/
    - MaxBarraclough 6y ago
      I realise this is a fuzzy question, but is rustls considered a production-strength TLS implementation, or just a curiosity? 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.
      - rapsey 6y ago
        Yes and it also has had a security audit.
      - papaf 6y ago
        Its being used in production [1]. I am also using it in Internet connected servers without any problems. 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_openssl_c_apis_done_with_rust_10m/ https://www.reddit.com/r/rust/comments/b9gd10/mesalink_10_op...
  - Elv13 6y ago
    Gentoo has USE flags to use gnutls+compat_layer rather than openssl. This is/was possible because they was a strong-ish push a decade ago by GNU aligned projects to force this down the throat of each package because OpenSSL had a problematic license exception deemed incompatible with GPL by some. The heathbleed fiasco helped this push. Then with LibreSSL, diversity survived a bit longer. 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.
ed25519FUUU 6y ago
> Anthony Basile, who is the current lead for LibreSSL on Gentoo, agreed, saying that LibreSSL is "more of a hassle than it's worth". 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?
- detaro 6y ago
  Bit hard to say that it couldn't have happened without the fork, given we don't have an alternate timeline to go back to and try. It would have gotten more attention and support without the fork too following Heartbleed.
- kevin_thibedeau 6y ago
  "cleaned up" still means an endless series of WTFs and gaping holes in the documentation. Session ticket caching is broken out of the box and you still have to implement a callback with arcane details.
vfclists 6y ago
Are there any test suites applied to both packages to see how compatible and reliable they are?
ruuda 6y ago
Nixpkgs supports LibreSSL, it can be used alongside OpenSSL due to the way Nix works, and it is usually a single-line change to compile an application against LibreSSL instead of OpenSSL.
- chalst 6y ago
  I thought of Nix when I read "it is not possible to install both OpenSSL and LibreSSL on the same system" - a call out in the article at this point would have been. 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.
- kazinator 6y ago
  ... and if it links, it must work, so ship it! Put it on an media streamer box or router and sell it to customers.
  - takeda 6y ago
    Typically that's how it works. If some functionality was removed, you will get linking errors.
- Foxboron 6y ago
  I think this ignores the reality of the libressl support in nixpkgs? 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)
  - RunningDroid 6y ago
    > …and I see some patches are fetched from Void Linux. The Void Linux developers have been discussing switching back to OpenSSL: https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935
mrweasel 6y ago
> OpenSSL turned out not to be as unfixable as it seemed 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.
- tptacek 6y ago
  The conventional wisdom in software security is that the answer to your question is "extensively"; that is, OpenSSL is in substantially better repair than it was in the Heartbleed era, and, of course, benefits from far more usage and thus attention than alternative libraries. By way of example: the OpenSSL team won the Levchin Prize at RWC 2 years ago, for the turnaround effort that went into it. I wouldn't go out of my way to use LibreSSL.
  - nopcode 6y ago
    >benefits from far more usage and thus attention than alternative libraries For me this theory was disproved by Heartbleed.
    - moomin 6y ago
      Indeed, OpenSSL was the premier SSL library for years and no-one noticed Heartbleed. Turns out not all bugs are shallow.
      - wglb 6y ago
        Yes, which is a misleading mantra. If nobody is looking, then it doesn’t matter
kelnos 6y ago
> Gentoo developer Michał Górny first suggested [dropping support for LibreSSL] 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. 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.
- hda111 6y ago
  It makes a lot sense that OpenBSD removed a lot of code from LibreSSL after forking it. There is only limited time and one can not maintain everything. This incompatibility is inevitable.
  - j16sdiz 6y ago
    To make it worse, they share lots of symbol / file path. Make it impossible to co-exist with openssl
- tottenhm 6y ago
  Yeah, in the long run, breaking compatibility is totally understandable for a fork. And generally... power-to-them in publishing a free/open/quality SSL implementation. 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.
StreamBright 6y ago
I would be interested in the other SSL implementations: - https://github.com/awslabs/s2n https://github.com/awslabs/s2n - https://boringssl.googlesource.com/boringssl https://boringssl.googlesource.com/boringssl - https://bearssl.org/ https://bearssl.org/ Are these subpar implementations or there are other reasons not to use these?
- l2dy 6y ago
  > Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability. 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.
Jnr 6y ago
Could someone please explain why the article lists OpenSSL license as problematic, while in-explicitly hinting that LibreSSL doesn't have that problem? How could that be the case if LibreSSL is just a fork of OpenSSL? Surely they can't just change the license without rewriting everything from scratch.
- Xylakant 6y ago
  > Surely they can't just change the license without rewriting everything from scratch. 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.
  - aflag 6y ago
    I thought GPL 3 was not compatible with GPL 2.
    - xoa 6y ago
      You're correct, the GPL v3 is not compatible with the GPL v2 simply as a matter of license [0]. GP might be confusing "compatibility" with specific grant of future version usage. The FSF default recommended notice boilerplate for the GPL v2 is: 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. So it includes an explicit "or any later version" clause. Since by far most projects just copy/paste standard language it's common to be able to combine v2 and v3. However, not all projects do that, with the most famous and impactful of course being the Linux kernel itself which is explicitly GPL-2.0 only. ---- 0: https://www.gnu.org/licenses/license-list.en.html https://www.gnu.org/licenses/license-list.en.html
      - 6y ago
nerdponx 6y ago
it is not possible to install both OpenSSL and LibreSSL on the same system. Why would this be the case? Do they use the same file names?
- rvp-x 6y ago
  The biggest problem you would have is that they share the function names, and if you have this tree (where a line means "links with dynamic library"): [my binary] / \ [___libA___] [___libB___] | | [libreSSL] [OpenSSL] 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.
  - jcelerier 6y ago
    > All of these can easily happen. 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/ https://nullprogram.com/blog/2018/05/27/) !
  - nerdponx 6y ago
    Thanks for the explanation. So even without the fix described in the sibling comment, I can still have programs that link to OpenSSL and programs that link to LibreSSL, but I can't use both (even if transitively) in the same application.
aninteger 6y ago
I don't know if it's still true in 2021 but it used to be kind of difficult to valgrind C and C++ code that linked with OpenSSL since it did some tricks that confused valgrind. You would usually have to recompile OpenSSL with a special preprocessor flag (-DPURIFY). 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.
- belgesel 6y ago
  I believe it is still true. OpenSSL uses dirty stack bytes for randomness and it causes valgrind to warn for invalid access.
The_rationalist 6y ago
What are some of the libressl improvements that would benefit from being backported to openSSL?
- takeda 6y ago
  LibreSSL, like many OpenBSD projects, puts security as the most important feature. Security is easier to do when code is simple. That's why LibreSSL actually removed many features. So I don't think there's much for OpenSSL to backport, unless they also want to trim some fat.
Wowfunhappy 6y ago
I'm somewhat embarrassed to say I didn't realize OpenSSL wasn't GPL compatible. 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?
- lights0123 6y ago
  It's Apache 2.0 so GPL3 compatible, but not GPL2.
  - Wowfunhappy 6y ago
    Ah, thank you! That does make more sense!
    - jabl 6y ago
      Note it's licensed under the Apache 2.0 license as of the still unreleased version 3.0. 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.
- joeyh 6y ago
  For values of "okay" that include wasted man-years overall spent chasing down many projects that depend on it, to get them to add an exception to their GPL license to allow linking their dependencies.
wott 6y ago
In my experience, the main hassle has been Gentoo maintainers of some packages who, for years, stubbornly refused to accept minor patches (and they were getting smaller as compatibility improved) for LibreSSL support (because always talking about risks has made people frightened about touching anything which relates to 'security', they prefer to shift responsibility on upstream, and you find the same kind of people upstream, afraid of putting two lines of #ifdef in their 500,000 lines bug-ridden project), thus users had to maintain their external overlays, and update them again each time a new version of the package appeared (if you consider that nowadays some projects publish releases every few weeks and that Gentoo is a rolling release...). 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.
einpoklum 6y ago
I find myself torn between the sympathy for protecting against patent betrayal with the Apache license, and supporting compatibility with the GNU ecosystem on the other. Difficult to form an opinion regarding what _should_ happen here.
- jabl 6y ago
  You can use Apache 2.0 license with the "LLVM exception", which was made to deal with the GPL2 compatibility issue (though the LLVM exception is relatively recent, maybe it didn't exist or openssl weren't aware of it at the time). See e.g. https://spdx.org/licenses/LLVM-exception.html https://spdx.org/licenses/LLVM-exception.html . Used by at least LLVM and CUPS.
peter_d_sherman 6y ago
>"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." https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month

149 points by lukastyrychtr 6y ago

yjftsjthsd-h 6y ago

Curious; I wonder how Void Linux is managing.

na85 6y ago
There's a GitHub issue[0] acting as an RFC open since April 2020. Looks like no conclusion has been reached but a quick skim of the thread reveals lots of sentiments similar to those expressed in TFA. [0] https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935

Blikkentrekker 6y ago

I might as well switch back to OpenSSL on Gentoo reading this. 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.

yjftsjthsd-h 6y ago
> I agree with the choice argument, however, Gentoo supports things 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?
- rapsey 6y ago
  Rustls, a company even developed an OpenSSL compatible API for it.
  - papaf 6y ago
    Just to add to your point. 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] [1] https://github.com/stepancheg/rust-tls-api https://github.com/stepancheg/rust-tls-api [2] https://mesalink.io/ https://mesalink.io/
  - MaxBarraclough 6y ago
    I realise this is a fuzzy question, but is rustls considered a production-strength TLS implementation, or just a curiosity? 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.
    - rapsey 6y ago
      Yes and it also has had a security audit.
    - papaf 6y ago
      Its being used in production [1]. I am also using it in Internet connected servers without any problems. 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_openssl_c_apis_done_with_rust_10m/ https://www.reddit.com/r/rust/comments/b9gd10/mesalink_10_op...
- Elv13 6y ago
  Gentoo has USE flags to use gnutls+compat_layer rather than openssl. This is/was possible because they was a strong-ish push a decade ago by GNU aligned projects to force this down the throat of each package because OpenSSL had a problematic license exception deemed incompatible with GPL by some. The heathbleed fiasco helped this push. Then with LibreSSL, diversity survived a bit longer. 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.

ed25519FUUU 6y ago

> Anthony Basile, who is the current lead for LibreSSL on Gentoo, agreed, saying that LibreSSL is "more of a hassle than it's worth". 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?

detaro 6y ago
Bit hard to say that it couldn't have happened without the fork, given we don't have an alternate timeline to go back to and try. It would have gotten more attention and support without the fork too following Heartbleed.
kevin_thibedeau 6y ago
"cleaned up" still means an endless series of WTFs and gaping holes in the documentation. Session ticket caching is broken out of the box and you still have to implement a callback with arcane details.

vfclists 6y ago

Are there any test suites applied to both packages to see how compatible and reliable they are?

ruuda 6y ago

Nixpkgs supports LibreSSL, it can be used alongside OpenSSL due to the way Nix works, and it is usually a single-line change to compile an application against LibreSSL instead of OpenSSL.

chalst 6y ago
I thought of Nix when I read "it is not possible to install both OpenSSL and LibreSSL on the same system" - a call out in the article at this point would have been. 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.
kazinator 6y ago
... and if it links, it must work, so ship it! Put it on an media streamer box or router and sell it to customers.
- takeda 6y ago
  Typically that's how it works. If some functionality was removed, you will get linking errors.
Foxboron 6y ago
I think this ignores the reality of the libressl support in nixpkgs? 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)
- RunningDroid 6y ago
  > …and I see some patches are fetched from Void Linux. The Void Linux developers have been discussing switching back to OpenSSL: https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935

mrweasel 6y ago

> OpenSSL turned out not to be as unfixable as it seemed 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.

tptacek 6y ago
The conventional wisdom in software security is that the answer to your question is "extensively"; that is, OpenSSL is in substantially better repair than it was in the Heartbleed era, and, of course, benefits from far more usage and thus attention than alternative libraries. By way of example: the OpenSSL team won the Levchin Prize at RWC 2 years ago, for the turnaround effort that went into it. I wouldn't go out of my way to use LibreSSL.
- nopcode 6y ago
  >benefits from far more usage and thus attention than alternative libraries For me this theory was disproved by Heartbleed.
  - moomin 6y ago
    Indeed, OpenSSL was the premier SSL library for years and no-one noticed Heartbleed. Turns out not all bugs are shallow.
    - wglb 6y ago
      Yes, which is a misleading mantra. If nobody is looking, then it doesn’t matter

kelnos 6y ago

> Gentoo developer Michał Górny first suggested [dropping support for LibreSSL] 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. 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.

hda111 6y ago
It makes a lot sense that OpenBSD removed a lot of code from LibreSSL after forking it. There is only limited time and one can not maintain everything. This incompatibility is inevitable.
- j16sdiz 6y ago
  To make it worse, they share lots of symbol / file path. Make it impossible to co-exist with openssl
tottenhm 6y ago
Yeah, in the long run, breaking compatibility is totally understandable for a fork. And generally... power-to-them in publishing a free/open/quality SSL implementation. 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.

StreamBright 6y ago

I would be interested in the other SSL implementations: - https://github.com/awslabs/s2n https://github.com/awslabs/s2n - https://boringssl.googlesource.com/boringssl https://boringssl.googlesource.com/boringssl - https://bearssl.org/ https://bearssl.org/ Are these subpar implementations or there are other reasons not to use these?

l2dy 6y ago
> Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability. 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.

Jnr 6y ago

Could someone please explain why the article lists OpenSSL license as problematic, while in-explicitly hinting that LibreSSL doesn't have that problem? How could that be the case if LibreSSL is just a fork of OpenSSL? Surely they can't just change the license without rewriting everything from scratch.

Xylakant 6y ago
> Surely they can't just change the license without rewriting everything from scratch. 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.
- aflag 6y ago
  I thought GPL 3 was not compatible with GPL 2.
  - xoa 6y ago
    You're correct, the GPL v3 is not compatible with the GPL v2 simply as a matter of license [0]. GP might be confusing "compatibility" with specific grant of future version usage. The FSF default recommended notice boilerplate for the GPL v2 is: 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. So it includes an explicit "or any later version" clause. Since by far most projects just copy/paste standard language it's common to be able to combine v2 and v3. However, not all projects do that, with the most famous and impactful of course being the Linux kernel itself which is explicitly GPL-2.0 only. ---- 0: https://www.gnu.org/licenses/license-list.en.html https://www.gnu.org/licenses/license-list.en.html
    - 6y ago

nerdponx 6y ago

it is not possible to install both OpenSSL and LibreSSL on the same system. Why would this be the case? Do they use the same file names?

rvp-x 6y ago
The biggest problem you would have is that they share the function names, and if you have this tree (where a line means "links with dynamic library"): [my binary] / \ [___libA___] [___libB___] | | [libreSSL] [OpenSSL] 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.
- jcelerier 6y ago
  > All of these can easily happen. 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/ https://nullprogram.com/blog/2018/05/27/) !
- nerdponx 6y ago
  Thanks for the explanation. So even without the fix described in the sibling comment, I can still have programs that link to OpenSSL and programs that link to LibreSSL, but I can't use both (even if transitively) in the same application.

aninteger 6y ago

I don't know if it's still true in 2021 but it used to be kind of difficult to valgrind C and C++ code that linked with OpenSSL since it did some tricks that confused valgrind. You would usually have to recompile OpenSSL with a special preprocessor flag (-DPURIFY). 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.

belgesel 6y ago
I believe it is still true. OpenSSL uses dirty stack bytes for randomness and it causes valgrind to warn for invalid access.

The_rationalist 6y ago

What are some of the libressl improvements that would benefit from being backported to openSSL?

takeda 6y ago
LibreSSL, like many OpenBSD projects, puts security as the most important feature. Security is easier to do when code is simple. That's why LibreSSL actually removed many features. So I don't think there's much for OpenSSL to backport, unless they also want to trim some fat.

Wowfunhappy 6y ago

I'm somewhat embarrassed to say I didn't realize OpenSSL wasn't GPL compatible. 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?

lights0123 6y ago
It's Apache 2.0 so GPL3 compatible, but not GPL2.
- Wowfunhappy 6y ago
  Ah, thank you! That does make more sense!
  - jabl 6y ago
    Note it's licensed under the Apache 2.0 license as of the still unreleased version 3.0. 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.
joeyh 6y ago
For values of "okay" that include wasted man-years overall spent chasing down many projects that depend on it, to get them to add an exception to their GPL license to allow linking their dependencies.

wott 6y ago

In my experience, the main hassle has been Gentoo maintainers of some packages who, for years, stubbornly refused to accept minor patches (and they were getting smaller as compatibility improved) for LibreSSL support (because always talking about risks has made people frightened about touching anything which relates to 'security', they prefer to shift responsibility on upstream, and you find the same kind of people upstream, afraid of putting two lines of #ifdef in their 500,000 lines bug-ridden project), thus users had to maintain their external overlays, and update them again each time a new version of the package appeared (if you consider that nowadays some projects publish releases every few weeks and that Gentoo is a rolling release...). 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.

einpoklum 6y ago

I find myself torn between the sympathy for protecting against patent betrayal with the Apache license, and supporting compatibility with the GNU ecosystem on the other. Difficult to form an opinion regarding what _should_ happen here.

jabl 6y ago
You can use Apache 2.0 license with the "LLVM exception", which was made to deal with the GPL2 compatibility issue (though the LLVM exception is relatively recent, maybe it didn't exist or openssl weren't aware of it at the time). See e.g. https://spdx.org/licenses/LLVM-exception.html https://spdx.org/licenses/LLVM-exception.html . Used by at least LLVM and CUPS.

peter_d_sherman 6y ago

>"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." https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month