The Sudo Crisis: When Foundational Tools Start to Crumble
Let's be honest—most of us take sudo for granted. You type those four letters dozens of times a day, maybe hundreds if you're managing servers. It's just there, like oxygen or gravity. But what happens when the person keeping that oxygen flowing says they can't keep doing it alone?
That's exactly where we find ourselves in 2026. Todd Miller, sudo's lead maintainer for over three decades, dropped a bombshell that should make every system administrator sit up straight: "Without some form of assistance it is untenable." Those eight words carry the weight of an entire ecosystem. They're not just a complaint—they're a warning siren for one of the most critical pieces of infrastructure in computing.
I've been working with Linux systems since the late 90s, and I can tell you this isn't just another open source maintainer burning out. This is different. Sudo isn't some niche library or trendy framework—it's the gatekeeper to root access on millions of systems worldwide. When its maintainer says the situation is untenable, we should all be listening.
What Sudo Actually Does (And Why It's So Damn Important)
Most people think they understand sudo. "It lets you run commands as root," they say. And sure, that's the elevator pitch. But the reality is so much more complex—and that complexity is exactly why maintaining it has become such a burden.
Sudo isn't just a simple wrapper. It's a sophisticated policy engine that determines who can do what, when, and how. It handles authentication, authorization, logging, and session management. It integrates with PAM (Pluggable Authentication Modules), supports LDAP and other directory services, manages environment variables, and provides detailed auditing capabilities.
Think about it this way: every time you use sudo, you're not just getting root access. You're triggering a chain of decisions about:
- Whether you're allowed to run this specific command
- What arguments you can pass to it
- Which environment variables get preserved or sanitized
- How the action gets logged (and where)
- Whether you need to re-authenticate
- What happens to your session after the command completes
And here's the kicker—all of this has to work perfectly across dozens of Unix-like operating systems, with different kernels, different libc implementations, different security models. It's a miracle it works as well as it does. But miracles don't maintain themselves.
The Maintenance Burden: What "Untenable" Really Means
When Miller says the situation is untenable, he's not talking about being tired of answering emails. He's describing a structural problem that's been building for years. Let me break down what this actually looks like in practice.
First, there's the sheer volume of code. Sudo has grown organically over 30+ years. It's not some clean, modern codebase—it's a living document of Unix history, with all the quirks and complexities that implies. Maintaining backward compatibility while adding new features is like performing surgery on a patient who's running a marathon.
Then there's the security aspect. Every line of code in sudo is potentially security-critical. A bug isn't just a bug—it could be a privilege escalation vulnerability affecting millions of systems. The pressure to get everything right is immense, and the review process has to be meticulous.
But here's what really makes it untenable: the maintainer-to-user ratio. Miller is essentially one person (with occasional help) responsible for a tool used by what? Tens of millions of systems? Hundreds of millions? The numbers are staggering. Every major corporation, government agency, and cloud provider depends on his work, but the support structure doesn't reflect that reality.
The Funding Problem: Why Corporate Users Don't Pay
This is where things get frustrating. Sudo is what economists call a "public good"—everyone benefits from it, but no one has sufficient incentive to pay for its maintenance. Companies worth billions run their infrastructure on sudo, but how many actually contribute back?
I've talked to CTOs at mid-sized companies who spend six figures on proprietary security tools but balk at contributing five figures to sudo's maintenance. The reasoning usually goes something like: "It's open source, so someone else will maintain it." Or worse: "If it breaks, we'll just hire someone to fix our specific problem."
This creates what I call the "free rider" problem on steroids. Every company assumes someone else will shoulder the burden. But when you're dealing with infrastructure software, there often isn't a "someone else." There's just Todd Miller, working nights and weekends to keep the lights on.
And let's be clear—this isn't about Miller wanting to get rich. This is about sustainable maintenance. He needs resources for:
- Dedicated development time (not just evenings and weekends)
- Security audits and code reviews
- Testing infrastructure across all supported platforms
- Documentation updates (which are crucial for security)
- Responding to vulnerability reports in a timely manner
These aren't luxuries. They're the minimum requirements for maintaining critical security infrastructure in 2026.
What Happens If Sudo Fails? Real-World Consequences
People ask me: "How bad could it really be?" Let me paint you a picture.
First, imagine a critical vulnerability in sudo that doesn't get patched quickly. We're not talking about a theoretical scenario—we've seen this happen with other infrastructure tools when maintainers burn out. The Log4Shell vulnerability in 2021 showed us how dependencies can create cascading failures. But sudo is worse because it's not a dependency—it's the foundation.
Without timely security updates, every Linux server becomes a potential target. And we're not just talking about web servers—we're talking about DNS servers, database servers, authentication servers, cloud infrastructure. The entire internet runs on this stuff.
Second, consider what happens to innovation. Sudo needs to evolve to handle new security models, new authentication methods, new deployment patterns. If maintenance is just about keeping the lights on, new features don't get added. Security doesn't improve. The tool stagnates while the threat landscape evolves around it.
Third—and this is the subtle one—there's the knowledge loss. Miller has been maintaining sudo for longer than some of today's sysadmins have been alive. He understands not just the code, but the design decisions, the trade-offs, the historical context. If he steps away without a proper transition, that knowledge disappears. You can't just hire a new maintainer off the street for something this complex.
Possible Solutions: How We Actually Fix This
Okay, enough doom and gloom. Let's talk solutions. Because this problem is solvable—if we're willing to put in the work.
The most obvious solution is direct funding. Companies that depend on sudo should contribute financially to its maintenance. This isn't charity—it's insurance. A few thousand dollars per company would add up to a sustainable maintenance budget. Some organizations are already doing this through Open Source Collective or similar platforms, but we need more.
Second, we need more hands on deck. Miller shouldn't be doing this alone. We need a team of maintainers, not just one person. This means companies contributing developer time, not just money. Imagine if Red Hat, Canonical, Amazon, and Google each dedicated one engineer to sudo maintenance. The problem would be solved overnight.
Third, we need better tooling for maintainers. This is where automation can help. For instance, maintaining test infrastructure across dozens of platforms is a perfect candidate for automation. While not directly related, tools like Apify show how complex tasks can be automated at scale—imagine applying that philosophy to testing infrastructure software across hundreds of configurations.
Fourth—and this is controversial—we might need to consider a more sustainable license. What if commercial users had to pay a license fee? I know, I know. It goes against the open source ethos. But we're talking about survival here. If the choice is between a slightly less open sudo and no sudo at all, which would you pick?
What You Can Do Right Now (Yes, You)
Feeling helpless? Don't. There are concrete actions you can take, whether you're an individual developer or part of a large organization.
If you work for a company that uses Linux servers (and let's be real, who doesn't?), start the conversation internally. Talk to your security team about sudo's importance. Calculate what a sudo vulnerability would cost your organization in downtime and remediation. Then compare that to what it would cost to contribute to its maintenance. The numbers usually speak for themselves.
For individual sysadmins and developers: contribute in non-code ways. Test new releases. Report bugs clearly and helpfully. Write documentation. Answer questions on forums. Every bit helps reduce the maintainer's burden.
Also, educate yourself and others. Most people don't realize how precarious our infrastructure is. Share articles like this one. Talk about it at conferences. Make sustainability part of the conversation when choosing tools and dependencies.
And if you have the skills, consider contributing code. But here's my advice: start small. Don't try to rewrite the authentication system on your first commit. Fix a documentation typo. Add a test case. Build trust gradually. The sudo codebase can be intimidating, but everyone starts somewhere.
Common Questions (And Straight Answers)
I've been getting a lot of questions about this situation. Let me address the most common ones directly.
"Why doesn't Miller just hand it off to someone else?" It's not that simple. You can't just transfer 30+ years of institutional knowledge. And finding someone with both the technical skills and the willingness to take on this responsibility is incredibly difficult.
"Can't we just fork it?" Technically yes, but practically no. A fork would create fragmentation, confusion, and security risks. Different organizations would patch different vulnerabilities. Compatibility would suffer. Forks work for some projects, but for infrastructure this critical, they're a last resort.
"What about alternatives like doas or polkit?" They exist, but they're not drop-in replacements. Migrating millions of systems would be a monumental task. And guess what? Those projects have maintenance challenges too. We'd just be shifting the problem, not solving it.
"Is this really that urgent?" Yes. Maintainer burnout doesn't happen overnight—it builds up gradually until it reaches a breaking point. By the time we see obvious signs of trouble, it might be too late to prevent a crisis.
The Bigger Picture: This Isn't Just About Sudo
Here's what keeps me up at night: sudo is just the tip of the iceberg. The same unsustainable model affects dozens of critical infrastructure projects. OpenSSL, BIND, sendmail, the Linux kernel itself—they all face similar challenges.
We've built the digital world on a foundation of volunteer labor, and that foundation is starting to crack. The sudo situation is a symptom of a larger disease: our collective failure to value maintenance over novelty.
Think about it. When was the last time you got excited about a maintenance release? When did you last celebrate a bug fix? Our industry rewards shiny new features, not the unglamorous work of keeping existing systems secure and stable.
This needs to change. We need to start valuing maintainers as much as we value innovators. We need to fund maintenance as seriously as we fund development. We need to recognize that the most critical code isn't always the newest—it's often the oldest, the most battle-tested, the stuff that everything else depends on.
Where Do We Go From Here?
Miller's warning isn't just a cry for help—it's a wake-up call for our entire industry. We have a choice to make: continue taking our infrastructure for granted, or start treating it with the seriousness it deserves.
The solution starts with recognition. Recognize that tools like sudo don't maintain themselves. Recognize that the people who maintain them are performing essential work. Recognize that this work deserves support—financial, technical, and moral.
Then comes action. If you're in a position to contribute, contribute. If you're in a position to allocate resources, allocate them. If you're in a position to influence decisions, influence them.
We've built an incredible digital ecosystem on open source software. Now we need to build an equally incredible support system to sustain it. The alternative—well, Miller already told us what the alternative looks like. Untenable.
So here's my question to you: what are you going to do about it? Because sitting on the sidelines isn't an option anymore. Not if we want our systems to still be running in 2027.
