PSA: If you think that people use Rust because it lets you write without bugs do yourself a favor and don’t comment on anything Rust related. You will avoid sounding stupid.
I think the criticism is more about deciding to try to re-implement a long standing facility in rust that has, by all accounts, been ‘finished’ for a long time.
About the only argument for those sorts of projects is the resistance to the sorts of bugs that can become security vulnerabilities, and this example highlights that rewrites in general (rust or otherwise) carry a risk of introducing all new security issues on their own, and that should be weighed against the presumed risks of not bothering to rewrite in the first place.
New projects, heavy feature development, ok, fine, Rust to make that easier. Trying to start over to get to the same place you already are, needs a bit more careful consideration, especially if the codebase in question has been scrutinized to death, even after an earlier reputation of worrisome CVEs that had since all been addressed.
In other comment I linked two vulnerabilities in sudo discovered in 2025, one of which was “hiding” for 12 years. So yeah, “finished” for a long time…
Finished means it’s feature complete according to the specification and feature frozen. It says nothing of bugs. Bugs are ethereal qualities, subject to opinion and criteria chosen for triage. Sudo is finished, it does what is meant to do. Does it do it bug free? For the most part it does. Doesn’t mean there aren’t any bugs left. But no new bugs are expected to be introduced by active development. Any bugs that arise, and it has been the case for a long time, will be old bugs that haven’t been discovered yet.
Is it feature complete? Sudo is still getting 10-30 commits a month. If those are all bug fixes, maybe it’s buggier than we thought. Otherwise it would seem that many of them are new features.
From the project’s website:
The sudo 1.8 branch is considered the legacy version. It receives no new features, only critical bug fixes. Users are highly encouraged to migrate to the sudo stable branch.
This implies that 1.9 may still get new features. And there may one day be a 1.10.
Here are the latest things fixed in the current patch version of 1.9 branch, 1.9.17p2
Fixed a bug introduced in sudo 1.9.16 that could result in sudo sending SIGHUP to all processes on the system in certain rare cases.
Fixed a bug introduced in sudo 1.9.12 that caused sudo to abort when … [some very specific cases]
Fixed a bug in sudo’s configure script introduced in sudo 1.9.17 that prevented mdoc-format man pages from being used on systems without the mandoc utility.
These are all recently introduced bugs that are results of either previous bug fixes or new features. The oldest mentioned version, 1.9.12 is from 2022, but 1.9.16 and .17 are newer.
This is not meant to be a criticism of the sudo project or Todd. He’s done an excellent job on the security front. But clearly sudo is not feature-frozen and new bugs are still being introduced. Sometimes they’re memory bugs and Rust helps with those (obviously it doesn’t completely eliminate them). Rust is also much nicer to learn than C, meaning it’s going to get easier and easier to find help in a Rust project as opposed to a C one.
Also Todd Miller, the author of sudo, has a submitted a pull request to sudo-rs at one point so I suspect he’s also excited about the project to some degree and wanted to help symbolically
no, I think people who write comments along the lines of “C bad, Rust good, why use C” are idiots. And if that makes me sound stupid - oh, well. Like I ever cared
Both things can be true and I’ve seen way way more comments along the lines of “there are bugs in Rust so it’s pointless” then “don’t use C”.
True. How dares anyone touch holy graal of C :)
Mozilla, where Rust was originally conceived, have already talked about this risk factor ages ago when they were still working on Servo. Reimplementing battle-tested software in a different language can result in logic bugs being introduced, which no programming language can really prevent. Many times they will actually reintroduce bugs that have already been historically fixed in the original implementation. This doesn’t invalidate the benefits of moving to a very memory safe language, it just needs to be taken into consideration when determining whether it’s worth the risk or the effort.
Honestly I have no idea whether sudo-rs is a good idea or not, but I have my doubts that any of the other people (especially the very vocal kind) chiming in on this do. Any time Rust is involved in the Linux community, a lot of vocal critics with very little knowledge of the language or programming in general seem to appear.
It’s a generally applicable lesson in why it’s NOT a good idea to change things for the sake of it though (chesterton’s fence, but where most of the actual bits of fence are invisible).
I think a key difference is that firefox is a eternally evolving codebase that has to do new stuff frequently. It may have been painful but it’s worth it to bite the bullet for the sake of the large volume of ongoing changes.
For sudo/coreutils, I feel like those projects are more ‘settled’ and unlikely to need a lot of ongoing work, so the risk/benefit analysis cuts a different way.
This is why its generally better to only write new code in more memory safe langs instead of rewriting everything
The counterpoint is that, especially with FOSS that does not receive much (if any) corporate backing, developer retention and interest is an important factor.
If I’m donating some of my free time to a FOSS project I’d rather not slug through awful build systems, arcane mailing lists, and memory unsafe languages which may or may not use halfway decent - often homebrew - manual memory management patterns. If the project is written in Rust, it’s a pretty clear indicator that the code will be easily readable, compilable, and safer to modify.
But why the rust? there are quite a large variety of languages with memory protection (for example Java), and freely compiled (for example golang), but for some reason they persistently try to rewrite the whole “world” into rust. I’m not against rust, I’m really curious.
For systems programming it makes the most sense out of the languages you mentioned. Languages requiring a runtime (Java/Python) do not fill the bill for system tools IMO. Golang is more arguable, but its memory safety comes through GC which many systems programmers aren’t fans of for a variety of technical and personal reasons.
Rust is meant to be what C++ would be if it were designed today by opiniated system developers and didn’t have to be backwards-compatible.
Those are the technical arguments I would use in a corporate setting.
All that aside, there’s personal preference, and my point is that for FOSS projects that matters too. Rust is fun in a brain-teasy kind of way in the same way that writing C is fun, but without nearly as many footguns. Golang is practical but arguably not as fun. That’s the same logic that draws many programmers to write Haskell projects.
The story of the Fish shell illustrates it quite well; the project gained a lot of development attention and contributions when they decided to rewrite from C++ to Rust, where they achieved a stable release with feature-parity a few months ago. It would have been a remarkably dumb decision for a private company to make, but makes perfect sense when you are trying to attract free talent.
Many things do use go, the issue with Java lies in its massive runtime burden (also not a great language IMO)
Java isn’t an exciting language, sure.
Kotlin is, though.
Agreed, Kotlin’s a lot nicer.
Both java and go seem excessively complex at runtime for fundamental system utilities, featuring garbage collection. Rust, on the other hand, keeps the complexity in the compiler and source, keeping the runtime code simpler. And of course it’s doing that while trying to make it easier to manage memory and harder to make mistakes, without forcing extra runtime logic on you.
Contrary to popular belief, it is possible to write software in C that is very secure. It takes thought but C has the edge with its small footprint and system integration
At this point I think the “thoughtful” C programmer is a myth and I don’t mean this as an insult. Even the most careful and experienced C gurus still make mistakes that would be much harder to make, if not categorically prevented in something like Rust. A lot of very secure C software is small in footprint, has had stable requirements for years, experienced thousands of hours of real world testing by users and the scrutiny of security experts. What I’m saying is: it should be easier to write secure software, especially with complex requirements or large attack surfaces.
I disagree that C has a notably smaller footprint than Rust for most purposes and system integration is in some cases harder in Rust precisely because of the notorious upfront implementation cost that prevents a lot of potential bugs.
Contrary to popular belief, it is possible to write software in assembly that is very readable. It takes thought but assembly has the edge with its miniscule footprint and zero-dependency runtime.
I wouldn’t go that far
The problem with assembly is that it is almost impossible to optimize it as a human. Way back in the day instruction sets were written for humans but these days it is highly unlikely that you will be able to write assembly that can outperform a compiler. The reason primary has to do with pipelining and caching since modern CPUs are extremely complex.
That’s btw. also a good argument for Rust. Due to the strictness of the language the compiler os able to do optimizations that just aren’t possible (safely) in C or C++
Yea I mean it’s possible, but the sooner you bite the bullet and use a more modern language, the sooner you’ll get back to the same level of maturity and start having productivity dividends being paid out thanks to things like being able to get your compiler to prevent use after free bugs and the like.
Not sure how much sudo specifically needs this, maybe new commits are rare. As long as it stays out of LTS for the time being I’m all for it though.
Also not quite sure what you mean by “footprint”
Are you talking about the binary size or the fact that C has a tiny and straightforward language spec?
Any time Rust is involved in the Linux community, a lot of vocal critics with very little knowledge of the language or programming in general seem to appear
I swear to god sometime last week in a conversation about Rust here, there was one commenter whose entire point was “OK admittedly i don’t code and don’t know much about programming but i got this feeling that memory safety isn’t all what’ it’s cracked up to be”. A confederacy of dunces indeed…
Inb4 the same bug also exists on the original
Sometimes an old legacy project have things that are dated but also years and years of bug fixes, improvements many not really documented. Starting a new project to replace it, will have regressions it’s impossible to not
Not to shit on Rust devs but they are more of the C++ type (fix things by adding more putty and let the compiler sort things out) while i’m more of the “system programmer” type (keep codebase and dependencies lean and comprehensible) so i guess i should rather look into Go for my planned big-ish GUI project?
I don’t see what you are talking about with the whole putty thing, do you have an exemple in mind?
Uh, code. I thought about “fixing a hole in a wall” while writing it but adding more makes more sense there.
There’s a lot of other alternatives, such as Zig, Odin, Nim, D…
Thanks for the names, i’ll look into them.
And it was a memory bug even. Just not a very common one.
I don’t think I’ve seen more vocal sponsors of any language except Rust. With the high barrier to entry and relatively greater developer effort to achieve, I am curious to see what place it occupies in over the long term.
“It’s just programming errors, nothing to do with Rust”, aka the language that they’ve been acting like will solve all programming errors
Nobody has been acting like rust solves all programming errors, it solves a specific subset of them: the one responsible for the vast majority of vulnerabilities
The real problem is not Rust, or that somebody decided to rewrite sudo in Rust. These are both good things.
The actual real problem is that Ubuntu adopts these in their mainline distribution when the release version is 0.something. I mean sure, this will get the worst bugs noticed and fixed sooner but come on. Have a little empathy for your dumb users. They didn’t choose to be that way.
Canonical wouldn’t have anything to do if they didn’t push software prematurely without testing it properly or making sure anyone actually wants it. See also:
- Mir
- Snap
- Core utils in Rust
- Netplan
- Their shitty installer
- CloudInit
Sometimes, their stuff end up getting popular and sometimes even usable. Most of the time though…
I would argue a rewrite of sudo in rust is not necessarily a good thing.
Sure, if you are starting from scratch, Rust is likely to mitigate mistakes that C would make into vulnerabilities.
When you rewrite anything, there’s just a lot of various sorts of risks. For sudo and coreutils, I’m skeptical that there are sufficient unknown, unaddressed problems in the C codebases of such long lived, extremely scrutinized projects to be worth the risks of a rewrite.
A rust rewrite may be indicated for projects that are less well scrutinized due to no one bothering or not being that old anyway. Just the coreutils and sudo are in my mind the prime examples of bad ideas of rewrite just for the sake of rust rewrite.
I think the people doing the rewrites genuinely believe it will be an improvement, and they could be correct. I get the instinct to “don’t fix what ain’t broken”, but that is what staging is for. There is no need to make sacred cows, and this seems like a perfect opportunity to improve security and integration testing as well.
There’s still nothing wrong with reimplementations. It’s like saying don’t build houses because you’ll have to make repairs.
It’s more like saying “why tear down that house and try to build one just like it in the same spot?”
So the conversation goes:
“when it was first built, it had asbestos and lead paint and all sorts of things we wouldn’t do today”
“but all that was already fixed 20 years ago, there’s nothing about it’s construction that’s really known to be problematic anymore”
“But maybe one day they’ll decide copper plumbing is bad for you, and boy it’ll be great that it was rebuilt with polybutylene plumbing!”
Then after the house is built it turns out that actually polybutylene was a problem, and copper was just fine".
I feel like that comparison is a bit skewed, given that the original house (sudo, without the rs) was never torn down.
Furthermore, rather than something easily replaceable or shallow, the language used is pretty integral to the software. Rather than paint, it would be like the building is made with untreated timber for framing. There might be termites that threaten the integrity of the building.
If the building is unimportant you may not bother with the cost. But if it is somewhat important, reconstructing with better materials could be worth it even if new mistakes could be made during construction.
I don’t know.
Where can I download a house?
You wouldn’t…
in other news: software has bugs
Not my software.
No tests, no users, no bugs.
see Ivan? Dead code cannot have bugs
The other day o spent a bunch of time carefully dissecting and then rewriting some code from the guy before me.
Turns out that code was never used, he just didn’t remove it or comment it out.
That was a good use of a couple hours.
One of the new devs spent a week refactoring some code that was removed from main the same day he checked out. We told him to focus on a specific set of scripts, but he wanted to go there extra mile. Poor soul
helloworld(“print”)
Ah, we have a senior developer here!
It’s not a bug, it’s in production so it’s a feature
Changelog version 0.15.2
- Fixed typo
- Addressed excessive memory usage
- Introduced the ability to retrieve password from memory
Admirable.
Me? No software, no bugs.
What? New software doesn’t have the same level of battle testing that 30 year old software, with billions of deployments had? What does that matter? It’s memory safe, guys! That means it can’t have any bugs!
You exude vibes of someone who would’ve opposed the move from assembly to C …
Developers are well aware of the risks of re-writting, and I have seen no one say Rust is bug or cve free on compile time. But you do have higher guarantees that a certain class of vulnerabilities do not exist or it is easier to narrow down where they might be. Stop spreading FUD
And before you try: nop I’m not a Rust developer
But, maybe, just maybe, replacing one of the most important coreutils with an immature Rust product isn’t a good idea
sudoisn’t a coreutil. It’s also got a number of replacements that do pretty much the same thing (doas,run0, etc.), so I wouldn’t even call it one of the most important.Can someone explain to me why Rust enthusiasts are so evangelical about it? I get that it’s memory safe, OK - super great. But rewriting a stable, small-but-important legacy tool doesn’t seem like a good place to prove its worth. Surely there are a million better places? And yet when I heard about this, it totally seemed to track. I’ve never touched Rust but I already find its proponents to be strangely focused on it. I never felt such religious zeal with regard to a programming language.
Firstly, Rust doesn’t need to “prove its worth.” It’s been in use in prod in other contexts for years.
Secondly,
sudois still actively getting a decent number of commits every month and has been riddled with bugs. For instance, just a few months ago there was a critical privilege escalation vuln. This rewrite is stripping out functionality that is deemed unnecessary.Not sure. Some enthusiasm is understandable, but Go and Swift don’t draw out evangelists the way Rust does.
If you had an ancient utility in assembly that did exactly what you wanted and no particular issues, then it would have been a dubious decision to rewrite in C.
Of course, the relative likelyhood of assembly code actually continuing to function across the evolution of processor instruction sets is lower than C, so the scenario is a bit trickier to show in that example.
However, there are two much more striking examples: COBOL continues to be used in a lot of applications. Because the COBOL implementations work and while it would be insane to choose COBOL for them now if they were to start today, it’s also insane to rewrite them and incur the risks when they work fine and will continue working.
Similarly, in scientific computing there’s still a good share of Fortran code. Again, an insane choice for a new project, but if the implementation is good, it’s a stupid idea to rewrite.
There’s not a lot of reason to criticisize the technical merits of Rust here, nor even to criticize people for choosing Rust as the path forward on their project. However the culture of ‘every thing must be rewritten in Rust’ is something worthy of criticism.
Chiming in for something unrelated. Fortran is actually pretty cool and if you need to do a lot of number crunching for scientific calculations starting a project in Fortran is not that bad. I started working on Fortran04 and back then I really couldn’t see any advantage of c++ if we’re talking computations. Now with Fortran23 we’re talking about quite a modern language.
I mean, if you’re considering Fortran for a project your only other likely choice is c++, and I tell you Fortran feels much smoother and easy to work with if you have to do calculations. I guess if you don’t worry about it being new you could consider Julia, but for many applications Fortran still has its well deserved spot.
Canonical should really wake up and stop thinking that rewriting in rust is a magical way to remove bugs.
Sure the rust rewrite will surely be easier to maintain and less error prone (Assuming the code is idiomatic), but you can’t rewrite software maturity.
They should put it behind a checkbox instead of shoving it down anyone’s throat. They are literally testing in prod
It is probably more of an act of desperation to stay relevant
But that is literally what the 25.10 is for, to test in prod. So that those bugs are fixed in the upcoming LTS
They really should not be testing it at all. It’s not even feature complete, let alone mature.
I take it you’ve never done any serious software development.
No matter how much they try, the in-house testing environment will never be as diverse as the “wild”. Running the software in production, where it will encounter a vastly greater range of system configurations, and users who will report issues, is often the only way to catch the more elusive bugs. Like xz. And let me point it out because people seem to have completely missed it: they caught the bug and fixed it.
I’m not saying it should not be tested, I’m saying Ubuntu should not be testing it.
We have yet to see if they’ll stick to the Rust implementations for 26.04. If you’re running non-LTS Ubuntu in prod, that’s not on Canonical…
If we expect software like sudo to stick around for decades to come, a transition phase like this might very well be worth the investment.
IMO if you’re running Ubuntu at all in prod you already fucked up.
Real professionals use LFS, obvs
Oh dear god I think you are joking but I know people who seriously do LFS as their production setup and get pissy anytime people say they are doing it wrong if they want to work with anyone else in the industry.
I didn’t know I could simultaneously feel fear, respect, and revulsion for one person, but those people running LFS for prod certainly have earned that
Fedora hasn’t really had this issue and it is on the edge.
why try to recreate the bloat of sudo when doas exists?
Probably because thing expect sudo to exist
doas mv /usr/bin/doas /usr/bin/sudo
Problem solved!
alpine doesn’t have sudo. hell, neither does debian, by default
Yes and how many people daily-drive those?
debian is one of the most common distros
Completely anecdotal but I’m the only person I know who has a stock Debian install that isn’t a server, and it’s on a laptop that hasn’t been connected to the internet for the better part of a decade. I know people who use debian-based distros or use it occasionally for one thing or another (dev, testing, temporary,…) but at least in my experience, the numbers are approaching gentoo in terms of actual dailydriver desktop usage. I’m sure my experience is probably abnormal, but still…
distrowatch puts debian at number 4 or 5 consistently in its popularity graphs. which is also a rather flimsy number, but it’s something.
That’s just based on how many people open that page on Distro watch, it has pretty much nothing to do with the actual use or popularity of a distro. You didn’t really think MX Linux spent a few years as the most popular distro, right?
run0
I am not one of those weird anti-systemD guys(ok, maybe a little bit) but run0 just feels weird to me. What is the usecase? why would I choose this over doas? what are we doing here?
~150 loc in C is enough for the things sudo is used on a single-user machine. doas is for multiuser.
okay, but the version of sudo everyone uses is over 130 000 lines of C.
