Hacker News Reader

Comment by mjhay | Hacker News Reader

Why hasn't LibreSSL taken off? I thought for sure it would after heartbleed. I assume it's mostly network effects/laziness, despite being fairly compatible (at least when it originally forked) and everyone already using OpenSSH from the openbsd as well.

View on HN

It has! It's on every iDevice out there.

Apple uses LibreSSL, not OpenSSL.

    @Ytterbium ~ % uname -a

    Darwin Ytterbium.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:15:52 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8112 arm64

    @Ytterbium ~ % openssl version

    LibreSSL 3.3.6

Isn't the builtin openssl lib a basic shim for LibreSSL, mostly only there for backwards compatibility and with limited functionality. IIRC Apple want you to use their Network framework https://developer.apple.com/documentation/network.

https://en.wikipedia.org/wiki/LibreSSL

Adoption is the default for a few BSDs, OpenSSH on Windows, macOS.

From a usage standpoint, you're probably correct (I honestly don't know) -- I only use it to generate web server certificates.

I'm guessing you're on macOS 13? The machine I'm on now is still on 12.6 (`Darwin Kernel Version 21.6.0`), and `openssl version` reports `OpenSSL 3.0.6`. Glad to see it if they made the switch in the new release, though.

Could it be that you have a different openssl in your PATH shadowing the system one? Because I could have sworn macOS 12 also used LibreSSL.

Derp, you're right - it was finding an OpenSSL binary that MacPorts installed. Explicitly doing `/usr/bin/openssl version` shows `LibreSSL 2.8.3`.

Compatibility seems to be a difficulty: https://voidlinux.org/news/2021/02/OpenSSL.html

Large web companies like Google implement their own encryption stack anyway.

On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.

> Large web companies like Google implement their own encryption stack anyway.

Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).

So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).

[1]: https://boringssl.googlesource.com/boringssl/

AWS maintains their own TLS stack: https://github.com/aws/s2n-tls

Is this an argument for GPL?

Seems like the big players came, saw, borrowed, and then did their own thing without contributing back.

If this were my project, I would be inclined to archive it and do a GPL fork.

None of what happened with OpenSSL or its forks is incompatible with the GPL.

Forgive my ignorance, but all of these forks are also still open source? My impression was that patches and improvements were made in closed source, private repositories to the benefit of the companies without paying anything back.

Otherwise, couldn't some openssl contributors just crib fixes from the forks?

As far as I know, all of the major ones are. I don't believe anybody has attempted to make a closed fork of OpenSSL, at least not one that has gained any real traction.

> Otherwise, couldn't some openssl contributors just crib fixes from the forks?

They do! But I assume it gets balanced with their own feature development time, and it becomes harder as the codebases drift. OpenSSL probably hasn't done itself many favors with the recent (3.x) "providers" refactor.

Reply on news.ycombinator.com