Another advantage: OpenSSL is switching to a license OpenBSD considersnon-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).

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.

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.

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.

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.

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.

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

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.

no, i meant for xbps, as an alternative backend

@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 with1 on invalid commands, LibreSSL is the one that always exits with0.

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 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 perlc_rehash runtime script is not needed in our case, since ourca-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.

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.

stuff that uses libtls will need libressl, too

Perl doesnot matter while bootstrapping, stop insisting that it does. I still don't see any reason to package both of them either, as@Johnnynator said it would require libarchive to be built against it and complicate everything. The "just in case" argument doesn't make any sense,either of them could mess up something and you have no way to know which.

Does anything actually use libtls? Since it's a libressl specific api and most distros don't package it at all, I don't think we need to worry

It is, since coreutils needs it, as well as GCC.

Libcrypto contains the majority of the asm acceleration code, including for sha*. Wrt libtls: so... other openbsd projects (duh) - I doubt it'd required, as e.g. Debian packages openntpd without libressl, and s6-networking, which can also use bearssl, which is a better choice either way.

Anyway, openssl needs Perl for good reasons, it uses it to deal with processing the assembly code for different targets. Libressl was only able to rip it out because they ripped out the asm

C implementation of what?

They still have c implementation ofc_rehash but as I said, it is not really needed and we can ignore it, since we use the debian ca_certificates update script.

There are much worse bootstrap dependencies we could have than Perl anyway, as far as I know Perl has never been problematic on anything, has been around for decades and is completely portable. And pretty much every single distro out there ships it.

1. that doesn't even matter for this topic, since Perl is ahost dependency. 2) the cross-compiling logic at least for current Perl isn't even complicated. Past doesn't matter, at all. 3) I don't care how many commits you have

I'm no longer a package maintainer, but from an user perspectivelibressl is sometimes painful when specificopenssl options are needed and not included. There is an example here :libressl-portable/portable#544
If it can save maintainers time, go for it.

[juan@leysa ~]$ xbps-query -Rs libtls.so -p shlib-requiresacme-client-0.1.16_4: libtls.so.19 (/mnt/storage/hostdir/binpkgs)libressl-3.0.2_2: libtls.so.19 (/mnt/storage/hostdir/binpkgs)libressl-netcat-3.0.2_2: libtls.so.19 (/mnt/storage/hostdir/binpkgs)openntpd-6.2p3_5: libtls.so.19 (/mnt/storage/hostdir/binpkgs)s6-networking-2.3.1.2_1: libtls.so.19 (/mnt/storage/hostdir/binpkgs)[juan@leysa ~]$

s6-networking works with bearssl. Upstreammarks bearssl support as beta but bothAlpine andAdelie use it.

@Johnnynator you may want to update your package to 1.1.1g, versions d, e and f are affected bythis vulnerability. (Is this the right place to comment on this or should I have commented on the New package request? I'm still new to this).

The version remark would have been better in the PR however the vulnerability itself is highly relevant to this discussion since the number of vulnerabilities in each library is an important decision criterion for a TLS library.

All software has vulnerabilities. I seriously doubt libressl has fewer of them.

#21994: Is it related with libressl? Any comments?

@imrn probably not related.

Has any consensus been reached?
On a personal note, I am starting to struggle using Void Linux on a daily basis because more and more things rely on recent protocols/algorithms not provided by libressl. For example, i have to either build openssl/cURL myself or rely on a docker version of cURL.

What is the issue with cURL?

@marmeladema Since this issue was created:

• A vulnerability in OpenSSL's TLS 1.3 implementation was found
• A new release of LibreSSL with TLS 1.3 was released
• q66 enabled hardware accelerated cryptographic primitives for PowerPC and ARM systems

Those are the major changes to the situation from my perspective. I would be curious to know which algorithms and protocols are missing from LibreSSL. Many of the algorithms removed from LibreSSL were removed deliberately from what I have read.

umm... my halfassed assembly stuff is hardly a solution for anything, it was never meant to be anything more than a stopgap solution until this is solved

openssl still has much better performance in various things (e.g. chacha20 which is default for openssh), libressl is still missing things (e.g. python hashlib doesn't have bcrypt and other things when built with libressl), libressl-portable is still a second tier codebase (it's awfully clear that libressl is written by openbsd for openbsd, and the "portable" distribution has its own specific bugs) and the divergence is only going to get larger, since openbsd doesn't take apache 2.0 code, and all fixes, enhancements (including new assembly code etc) and so on going into openssl are apache 2.0

openssl also still gets significantly more auditing and has a larger testsuite, at least in the portable libressl distribution the testsuite is rather superficial and that's a red flag for security too

also, the tls 1.3 support in libressl is client only as far as i can tell

nothing has changed on my stance since starting this issue, i've only become more convinced

The Apache 2.0 licensing issue is going to come with an entire host of problems. LibreSSL will surely diverge further from OpenSSL and this will create more burden for package maintainers.

If there is one reason apart from the portable libressl distribution's issues, including the lack of a test suite, strange feature detection, often poor coding style, and poor performance, I think that the burden on maintainers is the primary problem with libressl going forward.

I didn't think we should switch back to OpenSSL at the beginning of the issue but I am quite convinced now.

i wouldn't call libressl poor, it's a good project and i appreciate the effort, but for openbsd - portable seems to be getting attention/maintenance mostly from... 3 people overall as far as i can see, and I'm not super comfortable sticking with it in long term - especially if we want to take portability seriously - and "but heartbleed" doesn't sound like very convincing argument to me anymore, considering how much attention openssl has been getting the last half a decade...

OpenSSL has a lot of legacy OS discontinued, quantity of developers in OpenSSL does not mean quality in the code, OpenSSL has a design problem, it is susceptible to serious flaws, not that LibreSSL has no vulnerabilities, but it has cleaner code and with a focus on safety. This link shows that LibreSSL has more development thanhttps://cpp.libhunt.com/compare-openssl-vs-libressl

Here on this Gentoo link that has a LibreSSL port project, which has patches and fixes to ensure software compatibility with LibreSSL.https://gitweb.gentoo.org/repo/proj/libressl.git

In this old link, it compares OpenSSL vs LibreSSL, showing how security is applied in LibreSSL code.
https://resources.infosecinstitute.com/libressl-the-secure-openssl-alternative/

This link shows that LibreSSL has more development thanhttps://cpp.libhunt.com/compare-openssl-vs-libressl

https://github.com/openssl/openssl/graphs/commit-activity
https://github.com/libressl-portable/portable/graphs/commit-activity

Here on this Gentoo link that has a LibreSSL port project, which has patches and fixes to ensure software compatibility with LibreSSL.https://gitweb.gentoo.org/repo/proj/libressl.git

Those are 3 people with like 30 commits this year.
They do exactly the same as the Void Team just at a smaller scale, they are not magically more competent or better. I would argue that their patches are a lot less used than Voids package repository.

This link shows that LibreSSL has more development thanhttps://cpp.libhunt.com/compare-openssl-vs-libressl

Untrue, look at commit histories.

In thisold link, it compares OpenSSL vs LibreSSL, showing how security is applied in LibreSSL code.
https://resources.infosecinstitute.com/libressl-the-secure-openssl-alternative/
OpenSSL has a design problem, it is susceptible to serious flaws

(emphasis mine); yes, it is old, and that's the problem. OpenSSL's codebase quality and security auditing has increased greatly in the last 5 years. I would have agreed with you some time ago. Nowdays, LibreSSL gets much less auditing, has much fewer developers working on LibreSSL-portable, and has far less architecture support.

quantity of developers in OpenSSL does not mean quality in the code

I agree, but it does mean that something has to lose attention. Often, this is performance, or architecture support, and even build support/code quality (especially in libressl-portable), as@q66 can attest to.

OpenSSL has a lot of legacy OS discontinued

Care to elaborate?

This link shows that LibreSSL has more development thanhttps://cpp.libhunt.com/compare-openssl-vs-libressl

Untrue, look at commit histories.

In thisold link, it compares OpenSSL vs LibreSSL, showing how security is applied in LibreSSL code.
https://resources.infosecinstitute.com/libressl-the-secure-openssl-alternative/
OpenSSL has a design problem, it is susceptible to serious flaws

(emphasis mine); yes, it is old, and that's the problem. OpenSSL's codebase quality and security auditing has increased greatly in the last 5 years. I would have agreed with you some time ago. Nowdays, LibreSSL gets much less auditing, has much fewer developers working on LibreSSL-portable, and has far less architecture support.

quantity of developers in OpenSSL does not mean quality in the code

I agree, but it does mean that something has to lose attention. Often, this is performance, or architecture support, and even build support/code quality (especially in libressl-portable), as@q66 can attest to.

OpenSSL has a lot of legacy OS discontinued

Care to elaborate?

LibreSSL has an independent audit, which can be seen on this link, with a report by a member of Void Linux.
https://blog.doyensec.com/2020/04/08/libressl-fuzzer.html

This academic thesis "Analysis of software vunerabilities through historical data" shows comparative graphs of CVEs.http://lup.lub.lu.se/student-papers/record/8923711/file/8923713.pdf

OpenSSlL has a bad design, which favors serious vulnerabilities, this has not been fixed, as this is part of the structural code of OpenSSL, over the years, it has maintained serious vulnerabilities that affect linking software.

https://news.ycombinator.com/item?id=22935221

openssl/openssl#4729

openssl/openssl#4733

https://hownot2code.com/2016/06/03/evaluate-the-string-literal-length-automatically/#more-172

https://www.viva64.com/en/b/0183/

In these links you can compare the number of CVEs between OpneSSL and LibreSSL.

https://www.cvedetails.com/vulnerability-list/vendor_id-217/Openssl.html

https://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-30688/Openbsd-Libressl.html

CVEs are an interesting thing, and actually a point I brought up much earlier, I think on IRC, when I wasn't convinced of moving back to OpenSSL. Basically, OpenSSL is a far more audited codebase and receives more auditing attention than LibreSSL.

I don't see linters/static analysis code checking tools, alone, as evidence of poor coding practices. An OpenSSL dev said in one of those threads that many are false positives.

In addition, each of the articles you linked above (excluding the recent vuln, which was discussed earlier in this thread) are 3+ years old. Again, I am of the opinion that the code quality has improved in that time.

Anyway, I don't think I'll go back and forth, let others lay down their opinions on your data if they would like.

Thanks for the threads, btw, interesting reads, which do reinforce Void's position for originally changing to LibreSSL... at the time.

I would recommend:

1. changing xbps to bearssl. It has really straight API. One downside is that it does not support TLS 1.3yet. It’s really easy to build/bootstrap, no perl nor cmake, just pure make.
2. replace LibreSSL by OpenSSL 1.1
3. drop all packages that require OpenSSL 1.0

LibreSSL is intended to be used in OpenBSD. I don’t even know if LibreSSL follows OpenSSL 1.0 or 1.1 API. I had a bug with OCSP in Nginx and it took them 8 months to fix it. Seelibressl-portable/portable#532. LibreSSL is not a bad project at all, it’s just that it’s meant for OpenBSD.

well, ideally we'd go straight with openssl 3.0; it should be out soon, AFAIK.

changing xbps to bearssl

Two ssl's is probably a recipe for disaster.

replace LibreSSL by OpenSSL 1.1
drop all packages that require OpenSSL 1.0

Agreed.

LibreSSL is not a bad project at all, it’s just that it’s meant for OpenBSD.

100% agree

i think they meant making xbps useonly bearssl, which would be fine - you already have multiple TLS implementations in your system (there's openssl/libressl, but also nss, gnutls, etc.)

bearssl is nice, small, and explicitly geared towards security (it performs no dynamic memory allocations for example, AFAIK)

Ah, I see.

FYI Gentoo is discontinuing support in LibreSSL in February — however, in our case it's easier because LibreSSL was always the alternative option.

Nice read about this:https://lwn.net/SubscriberLink/841664/0ba4265680b9dadf/

Another (Gentoo) read ishere.

P.S. Sorry, it can be already mentioned via link in the comment above.

I don't really know too much about the fine details, but all I hope is that VOID might at least keep LibreSLL as an option? For me at least, LibreSLL was one of the main selling points of VOID.

There's no such thing as keeping it as an option. Every application that links to the ssl libraries needs to either link to one or the other. It's possible to have both, and for some programs to link to one and some to link to the other, but you cannot just swap them out.

If you want to have a version of Void Linux that uses libressl while the main version of Void uses openssl, then it does indeed need to be a version of the entire OS. It would be like the musl/glibc split.

There's no such thing as keeping it as an option. Every application that links to the ssl libraries needs to either link to one or the other. It's possible to have both, and for some programs to link to one and some to link to the other, but you cannot just swap them out.

If you want to have a version of Void Linux that uses libressl while the main version of Void uses openssl, then it does indeed need to be a version of the entire OS. It would be like the musl/glibc split.

I see. It would increase the things to maintain to:
VOID
VOID-musl
VOID-LibreSSL
VOID-LibreSSL-musl
then.

More or less.

Some packages could be shared between openssl and libressl spins (if they don't link to libssl.so and friends) but it would be less effort to rebuild everything anyway I'm guessing.

Most of the listed pros in the top post lead to a decrease in the maintenance burden related to the library that provides the "OpenSSL API" (LibreSSL's ABI breaks, patching external software, etc). If someone wishes to maintain avoid-libressl distro after such a switch has happened, I can't see it being anything but a Void fork.

It's possible to have both, and for some programs to link to one and some to link to the other

Only for some. It will lead to mixture of 2 different libssls in one runtime in many cases.