A bit funny, a software library focused on cryptography, where security is an afterthought rather than proactive effort.
I would consider the alternatives before going to OpenSSL.
I would consider the alternatives before going to OpenSSL.
Considering OpenBSD's reputation for proactive security, I'd say LibreSSL might be the best alternative out there.
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.
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).
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.
Otherwise, couldn't some openssl contributors just crib fixes from the forks?
> 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.
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.6Adoption 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.