[RFC] Switching back to OpenSSL

[Johnnynator]

OpenSSL nowadays doesn't have the issues anymore it had back in 2015 and significantly more Contributors watching and improving it. LibreSSL usually lacks behind in terms of supported algorithms and doesn't support the same API. Libs like Qt dropping support for OpenSSL 1.0 makes it significantly harder to maintain a (correct) patchset for LibreSSL support.

OpenSSL Pros

• Not that many (potentially wrong) patches needed, proper upstream support for nearly ever lib/program
• Potentially faster on non x86_64 platforms
• Access to newer Algorithms earlier
• No ABI breakage every 6 month

LibreSSL Pros

• Potentially safer by default (?)

[travankor]

Another advantage: OpenSSL is switching to a license OpenBSD considers non-free (Apache-2.0, which Void considers free). This means the codebase between openssl and libressl is more likely to diverge.

I think having better software (ie: haskell ssl library keeps breaking with libressl) and hardware support (ie: aarch64 crypto acceleration) is more useful for Void than security (not that openssl is super insecure these days).

[q66]

I'd argue that OpenSSL is safer, since it just gets a lot more attention and audit nowadays. Since heartbleed a lot of attention has gone to OpenSSL, it's probably one of the better-audited projects nowadays.

The performance increase on non-x86_64 platforms is not "potential", it's there; OpenSSL has optimized assembly code for most architectures, in addition to plain C fallbacks - LibreSSL does not have them, they all got dropped with the exception of the x86_64 ones.

So, +1 from me.

Perl being required for build is a non-problem, it's already required for build in several other bootstrap packages, including coreutils, gcc and glibc.

[pullmoll]

I had myself several times where it was difficult to see in which way patching a source for libressl would be correct. This is because I do not know every detail of the differences between the openssl versions 1.0.x and 1.1.x, and the libressl API lies somewhere in between the two.

So from my point of view using openssl could save us lots of work, and if a majority thinks that openssl is audited well enough nowadays, I'm pro switching.

[Hoshpak]

Are you talking about xbps as a project or the Void Linux xbps package? Switching all packages to openssl and still forcing every Void system to still install libressl in parallel through xbps would make it kind of pointless to switch in the first place.

I generally agree that we should switch to openssl. Libressl not supporting the openssl 1.1 API is increasingly holding packages back (I think I had issues when trying to update postfix in the past) and cannot be trivially patched. The slow movement of libressl development also bothers me and led me to not use it on my server. I am now able to connect to this server via TLS 1.3, just not from any of my Void machines.

[Johnnynator]

Simply don't switch xbps.

This would also imply to build libarchive against LibreSSL, but nevertheless I dislike having both LibreSSL and OpenSSL at the same time in the base system.

[Johnnynator]

We do have already multiple implementations at the same time, see mbedtls, gnutls, libressl, etc.

But not in the base system, there we only have LibreSSL as of now.

[Johnnynator]

E.g. I need to decide if ca-certificates depends on LibreSSL or OpenSSL (in theory I might be able to patch update-ca-certificates to work with both)

[travankor]

Anyway I've been thinking about it and maybe I'll switch xbps to use mbedtls. Not sure yet. So go ahead!

@xtraeme What about bearssl? In the link you provided above, it resists the attacks.

[travankor]

no, i meant for xbps, as an alternative backend

[Johnnynator]

@Johnnynator hmm I would not do this way. Each ssl implementation must depend on ca-certificates.

Yes, all ssl implementation depend on ca-certs but ca-certs depends on only one SSL implementation.
But the update-ca-certificates script right now ONLY works with libressl. And the openssl command does not have a proper way of querying whether it is OpenSSL or LibreSSL. (It always exits with 0, even when the command was not found..., so I need to judge it by what is print to stdout, argh...).

Edit: correction, OpenSSL exits with 1 on invalid commands, LibreSSL is the one that always exits with 0.

[Johnnynator]

in fact I haven't tried with openssl >= 1.1, but I think it would need minimal changes...

XBPS did compile and run fine for me locally.

[Johnnynator]

@Johnnynator we could use alternatives for the openssl command, and then use the specific impl cmd, i.e for openssl "openssl", for libressl "openssl-libressl" or whatever.

Probably the most sane way, I will prepare it like that.

@Johnnynator cool! I'll update the README then.

So I'm not against it, but what bothers me about openssl is the perl build dependency... it DOES matter while bootstrapping. I would take the alpine patch to get rid of it.

Alpine also needs perl for bootstraping, and the perl c_rehash runtime script is not needed in our case, since our ca-certifcates package is not using it, so we can simply ignore it. Also as q66 pointed out, we already have a few packages that need perl for bootstrapping (e.g. glibc, gcc), so I don't see an issue with OpenSSL needing it.

[Johnnynator]

Anyways, stick with libressl 3.1 for now, it's about to get released and adds more compatibility for openssl 1.1.

There are still significant gaps in the API.

[travankor]

stuff that uses libtls will need libressl, too