I am one of the people that believe in the technical superiority of rust.
What differentiates me though, is that I also believe in the superiority of C, the superiority of Java, of Javascript, ALL WITHIN THEIR RELATIVE DOMAINS HAVE STRENGTHS AND WEAKNESSES.
I like my crypto libraries in C. I like my desktop applications in rust and I like my web pages with simple, hand-written javascript. Or none is fine too.
I think it’s an acceptable choice to use rust for core utilities, though not necessarily exclusively, but I think we’re a far way off, where we should widely adopt it. It’s not very mature yet.
Can anyone explain why do we need this rewrite? What I’m hearing is just that the language is memory safe and, honestly, it sounds like a weak argument. Unless the program is actively evolving or requires regular updates and it can be seen that a rewrite could genuinely improve things…
All I’ve seen in these media posts were just vague “what if” arguments. If that’s it, a rewrite seems pretty dumb.
Sudo is being actively developed and has several fairly recent CVEs, some of which are memory issues (at least recent compared to how old sudo is). Apart from being memory safe rust is also better at error handling than C.
IMO best would be to reduce attack surface by using a memory safe language and also reducing complex features like OpenBSD’s doas does.
https://www.cvedetails.com/vulnerability-list/vendor_id-15714/Sudo-Project.html?page=1&order=3
Well that’s the thing that I don’t see communicated. Is it actively developed? Bug fixes doesn’t count, it’s maintenance not active development. If I’m just doing maintenance then there must be a lot of issues to warrant a rewrite, especially in a different language.
Form what I keep seeing it looks like a rewrite for the sake of rewriting, which is at best misguided reasoning.
I can see an argument that the cost of failure is very high with something like sudo, but I don’t see it vocalized anywhere.
Image working in an old building, there is no coffee machine, there is no warm water and if you want to do something new, chances of you getting in trouble because you forgot to mess with CMake or free memory, are high. But the building works since it has been tested for 30 years.
Rust is a new building that you can move over to, there is a coffee machine that is a bit complicated at first but once you understand it it is that bad, there is warm water and you don’t have to mess with CMake or allocate/free memory for everything. But the building is new, there will be issues here and there and sometimes the promised warm water wont work since someone fucked it up, but in general it is just sooooo much more comfy to work in.
Rust is not about making Programming languages fast or memory safe. If you truly want to do that, I recommend doing crack and writing in assembly. It is about making programming easier without sacrificing speed.
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.
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.
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 :)
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
And it was a memory bug even. Just not a very common one.
There’s still nothing wrong with reimplementations. It’s like saying don’t build houses because you’ll have to make repairs.
I don’t know.
Where can I download a house?
You wouldn’t…
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.
Hey, I say that a lot when people ask me if I would buy a house instead of an appartment.
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
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.
But, maybe, just maybe, replacing one of the most important coreutils with an immature Rust product isn’t a good idea
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.
Can we declare a threadwinner?
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.
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.
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…
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.
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.
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.
I do think there are long-term benefits in many cases, it just depends on available resources. There are plenty of projects that desperately need a rewrite for maintenance reasons alone so you might as well examine if language switch is worth it. It’s not like there aren’t a lot of success stories, even if there’s projects like sudo-rs where we’re, at best, not sure if there’s tangible benefits.
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).
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.
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?
in other news: software has bugs
Not my software.
No tests, no users, no bugs.
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
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.
deleted by creator
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
I’ve spent days on trivial mistakes so a couple of hours mean nothing to me
helloworld(“print”)
Ah, we have a senior developer here!
Admirable.
Me? No software, no bugs.
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
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.
Fedora hasn’t really had this issue and it is on the edge.
It is probably more of an act of desperation to stay relevant
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, I am curious to see what place it occupies in over the long term.
why try to recreate the bloat of sudo when doas exists?
~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.
Probably because things expect sudo to exist
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.
Better than expected. Touché
doas mv /usr/bin/doas /usr/bin/sudo
Problem solved!
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?
The selling point is that it is simpler to get pid 0 to start your process as root than for sudo/doas to clean up your environment.
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.
I meant, what part of rust feels like
fix things by adding more putty and let the compiler sort things out
I’ve been using it for a while, and I don’t know what the compiler is sorting out. It’s blocking me from doing things, not making things work. Unless you’re talking about traits or macros? But then they mostly remove lines of code, not add some. Confusion ensues.
There’s a lot of other alternatives, such as Zig, Odin, Nim, D…
Thanks for the names, i’ll look into them.
Inb4 the same bug also exists on the original
