On July 26, a developer named Daniel Fox Franke did something that thousands of engineers do every day: he filed a bug report. GitHub issue #3494, opened against the ripgrep repository, documented a segmentation fault in the tool’s statically linked musl binaries. The crash triggers during very large searches — think 1.8 million files across 20 gigabytes — when musl’s memory allocator, mallocng, fails a heap integrity check inside a calloc call. A week later, the issue sits open. No patch. No advisory from the musl project. Just a growing thread of “me too” replies and a Hacker News discussion that has, as of this writing, racked up 254 points and 168 comments.
The bug itself is fascinating in a narrow, systems-programming way. Reproducing it requires a dedicated script, a machine with enough cores and RAM to cache the entire file tree, and a looped search for a nonexistent string. It is, by any reasonable measure, an edge case. But edge cases have a way of becoming central when the tool in question is ripgrep — a program that has quietly become as essential to the modern developer’s toolkit as grep ever was, and arguably more so. When ripgrep segfaults, someone’s CI pipeline goes red. Someone’s incident response slows down. Someone misses a deployment window.
The Bug Is in musl, and musl Is a Handful of People
Here is where the story pivots from a routine bug report to something more uncomfortable. The crash is not in ripgrep’s code. It is in musl’s mallocng, the memory allocator inside musl libc — the lightweight C library that ripgrep’s maintainer, Andrew Gallant, statically links into the official release binaries. Gallant is, by all accounts, a responsive and meticulous maintainer. But he cannot fix a bug in someone else’s libc. And the someone else, in this case, is a project maintained by a tiny number of volunteers, none of whom appear to have issued a public statement about issue #3494 in the week since it was filed.
This is not a criticism of musl’s maintainers. They owe nobody anything. musl is free software, distributed under the MIT license, and its authors have made exactly zero promises about response times, bug fixes, or even continued development. That is the deal. But it is worth noticing that the deal has changed underneath us. musl is no longer a niche alternative for Alpine Linux containers and embedded systems. It is the foundation that ripgrep — a tool with 66,000 GitHub stars and an install base in the millions — ships to every user who downloads the official binary. When that foundation cracks, the people standing on it discover, often for the first time, that there is no phone number to call.
We Secured the Supply Chain Against the Wrong Threat
The software industry has spent the better part of a decade obsessing over supply-chain security. We have SBOMs, SLSA frameworks, signed attestations, and an entire subgenre of venture-backed startups promising to verify that every byte in your binary came from where it says it came from. All of this infrastructure is designed to answer one question: did someone malicious sneak something into the pipeline?
Issue #3494 poses a different question, one that our entire security apparatus is unequipped to handle: what happens when the thing that breaks is exactly what it claims to be, written by exactly who it claims to be written by, and nobody is paid to fix it on any particular timeline? The segfault in mallocng is not a supply-chain attack. It is supply-chain entropy — the slow, unglamorous accumulation of bugs in under-resourced libraries that have become load-bearing without anyone formally acknowledging the load.
One engineer at a mid-sized observability startup, who spent a Thursday afternoon debugging a CI pipeline that suddenly started dumping core, described the experience over Slack: “I didn’t even know what mallocng was until it ate my afternoon. Then I found the GitHub issue and realized the fix depends on a project whose last release was nine months ago.” He is not alone. The HN thread is full of similar stories — people who built critical workflows on top of a tool whose reliability they had simply assumed.
The Static-Linking Bet Has a Downside We Don’t Talk About
For years, the conventional wisdom among performance-conscious developers has been: statically link against musl, ship a single binary, and never worry about glibc version incompatibilities again. It is good advice, most of the time. A statically linked ripgrep binary is a marvel of portability — drop it on any Linux kernel and it runs. But static linking also means that when a bug like #3494 surfaces, the end user cannot swap in a patched libc. They cannot rely on their distribution’s package manager to push an update. They wait for a new ripgrep release, which waits for a musl fix, which waits for a volunteer to find the time.
This is not an argument against static linking or against musl. It is an argument for seeing the trade-off clearly. The glibc ecosystem is messy, complex, and occasionally maddening, but it has something musl does not: institutional backstops. Red Hat, SUSE, and Canonical employ people whose job is to ensure that a segfault in glibc gets triaged, patched, and shipped. musl has Rich Felker and a small circle of contributors. They do extraordinary work. But extraordinary work does not scale by force of will alone.
The ripgrep segfault will eventually get fixed. Someone will bisect the mallocng code, identify the faulty heap-metadata assertion, and submit a patch. The bug is not existential. But the pattern is. We are building more and more of our tools on foundations maintained by people who never asked to be infrastructure. And we are doing it without any mechanism — social, financial, or institutional — for ensuring that when those foundations crack, the crack gets filled before it becomes a crater.
The 254 points on Hacker News are, in their way, a kind of attention. But attention is not maintenance. And maintenance, as issue #3494 quietly reminds us, is not something you can star on GitHub.