If the backdoor relies on IFUNC then it would not work on distributions using musl. Like the one I use. Always amusing when HN commenters try to belittle use of musl and promote use of glibc. I like musl. I like choice.
I've watched release-optimized builds with musl run orders of magnitude slower than unoptimized builds with mimalloc, and this was on only 20 cores, it wasn't exactly pushing the envelope of big iron scaling.
Even after waiting years for its mallocng, which is better, it is still the slowest. It's no longer just that it wasn't a priority, it's inherent fallout from musl's practice of reinventing everything without learning nearly enough about why other implementations were built that way in the first place.
With memory allocators there were several legendary implementations to learn from. My pick would be mimalloc because it's not just fast, it's also hardened, which seems relevant in a thread about security.
At least once you know this, you can substitute the allocator for your program even if you otherwise use musl. That's common practice when producing static binaries from Rust code.
The problem remains that far too many people just use musl without actually benchmarking their program under a real workload to see just how much they've sacrificed in return for, well, what exactly, because it also wasn't hardening.
If I had to pick something, it'd be that glibc is behind musl on supporting 64-bit timestamps on 32-bit targets; and at least for my targets, that's a stretch.
In return, musl's (past?) problems with domain resolution alone seem like more than enough of a downside to avoid it on all targets.
https://twitter.com/RichFelker/status/994629795551031296 vs https://datatracker.ietf.org/doc/html/rfc7766#section-5
Disclaimer: I'm targeting these from Rust, not C or C++ directly.
One might conclude from reading this question that someone has already made up their mind. Why would someone framing a question in this way have any interest in what I prefer and why. I am not a "developer". I am an "end user" that compiles programs for own use. Is this a "good faith" question.
"Bait" indeed.
The difficulty with compiling static binaries using glibc is the deal-killer for me. Coming to Linux from NetBSD, I never experienced any difficulty compiling static binaries using NetSBD's libc.
Rarely do I encounter software I want to use that does not compile easily with musl. Instead I encounter software authors that have made the effort, if any is required, to be musl-compatible or that use musl exclusively (see spitbol), including Linux distributions that have adopted musl as their libc (see Alpine Linux) or offer a musl option (see VoidLinux). If others prefer glibc, then I have no problem with that. What I do not understand is why HN commenters want to jump on every comment where I mention using musl myself and try to disparage it. Why would they care what libc I use.
If anything, these snarky comments only make me more skeptical of glibc.