Canonical security audit of rust-coreutils reveals 113 CVEs
Posted by nukem996@reddit | linux | View on Reddit | 152 comments
While it's great that Canonical did the audit and is working to fix these CVEs this shows that Rust isnt some magic language where CVEs dont happen.
It brings up the question, is a Rust rewrite worth it? These CVEs were not found in the C version coreutils and were only found due to a paid audit.
0riginal-Syn@reddit
First, I am not a fan of the whole re-write or even Canonical for that matter, but your post is either disingenious, you have poor reading comprehension, or you just don't understand what you are reading.
There were NOT 113 CVEs, there were 44. There were 113 issues found over the 2 rounds. The whole point of the audit process is to find these so they can fix them. It was a commisioned multi-phase independent audit to patch every possible bug before it gets rolled into LTS. If anything, they should be applauded for taking this step to fix. This is a much younger project than coreutils, so it has not had as much real-world exposure yet.
If you want to argue against the rewrite or the licensing, etc. go for it. I would likely agree with some of that. But bringing this argument up is pretty weak and shows a general lack of understanding. Especially for a commissioned test to find and fix before going into their LTS branch.
Perokside@reddit
That's the biggest point of concern, MIT licensing rewrites of critical bricks in a gnu/linux distrib to slowly strip the gnu out of it, ATP it just looks like some big actors are happy to use the Rust hype to do so.
Can't wait for distributions to bait and switch to closed sources env and only redistribute a kernel source code tarball to comply with what's left of free and open. /s
FriendlyProblem1234@reddit
BSD coreutils and Toybox have existed for at least 20 years. Why are permissive licenses only a problem now with uutils? What changes with uutils, compared to the previous situation with BSD coreutils and Toybox?
Perokside@reddit
What made you think I only meant "it's only a problem now with uutils" ? Toybox only exists to avoid GPL because massive Android OEMs can't be arsed to put a copy of the Busybox code they used online. BB is deemed "toxic" by corps even (which tbf the whole 'patent' trolling at the time didn't help).
BSD coreutils (or even musl used in Alpine Linux iirc) doesn't have the same reach as Canonical willingly replacing brick after brick in a large, popular, mainstream distrib and if you look at AOSP and the recent rug pulls by Google, that's a stretch but where I see *buntu headed in the future.
If Google can lockdown AOSP and maim the aftermarket roms, that's not because of permissive licensing per-se but it allows them to. Canonical is a large enough actor to hurt the whole ecosystem, so is RH amongst others.
My biggest grief/concern is not Rust rewrites or permissive licensing, it's how this could/will be used by corporations to retain control and fragment the ecosystem. re: Snap, mir, etc.. Canonical isn't the most trustworthy company out there already.
FriendlyProblem1234@reddit
Just a few days ago, in this sub, there was a post about version 4 of OpenSSL. A pervasive, fundamental component of Linux distributions, released for ages under a permissive license. Nobody even mentioned its license in the discussion.
Yet, in this thread, and in the sudo-rs one, half of the replies are about MIT dooming the Linux ecosystem to ruin.
Can you find a similar anger about licensing for any other software? Python? Go? Wayland? I could not, therefore my observation is that this is only a problem now with uutils (and maybe sudo-rs).
Perokside@reddit
AOSP?
I don't think the "lack of anger/concerns" aimed at other projects is valid, the recent news made people realize how much of the Linux ecosystem has become corporate‑backed, with Red Hat and Canonical (and SUSE to a lesser extent) spearheading changes that trickle down and impact most of the ecosystem.
What you observe (and I agree), is misguided concerns (as "it feels aimed at some projects but not others") toward what looks like a long-term play from Canonical becoming a threat, and if it backfires, they can always eat the loss and rewind with a heartfelt apology about "losing track of what makes Linux Linux", yadi yada.
It’s (imo) about the structural risk that a large enough actor can reshape the ecosystem over time by controlling the implementations everyone ends up depending upon. The perception that the use of Rust rewrites of key components by Canonical or their fork of Grub has a deeper intent, technically it makes sense, morally-speaking, it's not unreasonable to be skeptical.
Systemd is under the same heat and it's LGPL, which further decouples "the concern(s)" from "the licence(s)".
FriendlyProblem1234@reddit
Every single thread about uutils, sudo-rs, or even Rust in Linux kernel, has half of the posts about their licenses. This does not happen in threads about Android, and neither with any thread about other major components released under permissive licenses. It just does not.
Why do you say "controlling the implementations everyone ends up depending upon"? This is Canonical deciding about a component used by Ubuntu, their own distribution. They cannot control what components Gentoo, Debian, OpenWRT... use. And who would you suggest should decide about components used by Ubuntu, if not Ubuntu's creator and maintainer Canonical?
Which kinda proves my point. Who is complaining about OpenRC's permissive license? Nobody.
Perokside@reddit
Canonical is free to decide for themselves about components used by Ubuntu, I never said they're not free to or their technical decisions are dumb or invalid, shrinking GRUB to reduce its surface of attack is a valid take, replacing key components for memory-safe Rust rewrites makes sense.
When you're a big enough actor and you take 'radical' decisions about the technological foundation of your OS used by millions, it comes with an implicit influence, with great power comes great responsibilities.
Once they ship some polished, well-funded tools, libs, that they mainly maintain, it puts a strong draw for others (big or small) to use and makes alternative less attractive. It's not a prophecy, it's a concern that "slowly stripping the gnu out of gnu/linux" may lead to weakening the ecosystem.
Devs start to target Canonical implementations, it becomes a standard because it's the one with momentum, documentation and corporate backing.
That's how systemd became the standard (infrastructure gravity), corp-backed, technically sound, it crept everywhere, why would people be angry about OpenRC's perm license if nobody knows it exists? (same goes for Runit).
Whoever gets to build a dam, controls the valley kind of thing.
guri256@reddit
This isn’t a beaten switch. You are basically saying “Oh no! Someone might run closed source software on top of the Linux Kernel!”
Yeah. This happens often. Do you remember the TiVo? that’s one of the things that prompted the GPL3, and the AGPL. But there’s no way the Linux Kernel is going to end up under those licenses. Both because there are too many contributors to get the permission from, and because Linus is against the GPL3.
And then there are Netgear routers. The WRT54G for example. That used the GPL kernel, with their own software on top. And that story turned out well. Because users had the modified colonel source, they were able to build an ecosystem that runs on these routers.
TL;DR: this already happens. There are already proprietary operating systems. There will still be proprietary operating systems whether or not this happens.
mistahspecs@reddit
I feel like your takeaway is a bit misguided. Nobody thinks rust can't have bugs, and a security audit 1) being paid for 2) yielding actionable moderate to low risk results, is a good thing.
This type of post happens any time a rust project has a non-memory-safety bug
nukem996@reddit (OP)
So why do it it? I've been an active maintainer on multiple distros and coreutils had very few bugs. I can't remember a single critical CVE.
Indolent_Bard@reddit
Core utilities is a very old mature project.
LordAlfredo@reddit
Xorg is also a very old mature project. Just because something is established doesn't mean it can't be improved upon.
Indolent_Bard@reddit
I was explaining why the rewrite would have more bugs than the old one.
KaMaFour@reddit
That's your memory issue, no?
https://www.cve.org/CVERecord?id=CVE-2015-4042
This one is more serious than the entire list you posted
Manic5PA@reddit
How many of those vulnerabilities are a result of memory unsafety in either rust-coreutils or rustc/rust stdlib?
If that number is "zero", you have your answer.
2rad0@reddit
Does exhausting all disk resources and possibly crashing the system because it tries to copy a block device in /dev/ as a file stream count as a memory safety bug?
Manic5PA@reddit
That would be a logic bug
2rad0@reddit
A logic bug that leads to exhausing RAM if I were copying to a ramfs or maybe even a tmpfs filesystem.
Manic5PA@reddit
I get that it's counter-intuitive, but leaking memory (whether in or out of process) is not a memory safety issue.
stevecrox0914@reddit
Java has always benchmarked 10% slower than C/C++, yet my first job had teams rewriting everything from C++ to Java and getting massive performance increases. Why?
It was the cognitive complexity of memory management and development tooling.
You would get similar time to spend on a task, but much of that time on a C/C++ project was spent dealing with getting out of a situation of a pointer to an address of a pointer or worrying about the stack or heap. Java devs didn't have to spend that mental effort, they had more time on the problem and fun stuff.
At the time C++ static analysers were rubbish, Java had free ones (findbugs) and they were better than paid C++ solutions like Coverity. Java had Junit and cobertura for code coverage, we had cppunit... Java had Yourkit for performance profiling that let you find every bottleneck quickly, C++ had .. nothing.
So why Rust today?
C/C++ developers have really fought evolving their tools, Rust tools are significantly better. Rust also means your not spending hours staring at pointer to address of pointer problems.
Its pretty obvious why devs interested in the problem would rather deal with Rust over C/C++ and why they would try to rewrite it.
If your issue is the license, if you work in industry 95% of the open source projects you deal with will be Apache, MIT or BSD licensed. Is it a wonder developera choose licenses they use?
Zaphoidx@reddit
Because why write in a language that might have memory safety issues when you could use a language that doesn't have those issues?
Rust isn't a silver bullet for all bugs. But it sure is for memory safety (if you don't use unsafe)
AnsibleAnswers@reddit
You have to be thinking long term to get why a total rewrite in a memory safe language makes sense.
Here’s the rationale:
https://www.cisa.gov/resources-tools/resources/memory-safe-languages-reducing-vulnerabilities-modern-software-development
pftbest@reddit
They hate the GPLv3 license I assume. That's the only logical reason for doing all of this.
Wyciorek@reddit
Bingo. Every single of those rust rewrites seem to be about downgrading the license. I expect the trend will accelerate greatly - chardet debacle shown that you can just use AI to do “rewrite” and slap a license of your choice on it
Secret_Conclusion_93@reddit
People who paid them hate the license.
UltraPoci@reddit
"Rust isnt some magic language where CVEs dont happen"
Who ever said that. I don't know why some people think that Rust claims to be completely bug free. It tries to prevent a specific class of bugs at compile time. Everyone who works with Rust knows this.
laffer1@reddit
It’s not rust maintainers that say this. It’s misguided IT folks who hear about the memory safety and are clueless about software development.
The marketing behind rust is partially to blame because it should have mentioned more clearly it’s just memory safety and not everything. They did get better about this over time.
UltraPoci@reddit
What marketing? "Rust is memory safe" is literally the first thing you hear about Rust. If people don't know what memory safe is not Rust's fault.
laffer1@reddit
People don’t know outside of programming circles!
The marketing is that it’s safe. That was how it was pushed early on. Not memory safe, just safe. That was a mistake
UltraPoci@reddit
Again, what marketing?
laffer1@reddit
https://blog.rust-lang.org/2015/05/15/Rust-1.0/#:~:text=Announcing%20Rust%201.0%20%7C%20Rust%20Blog,2015%20%C2%B7%20The%20Rust%20Core%20Team
Note it says safety not memory safety
UltraPoci@reddit
First of all, it says "safety guarantees", which does not imply that it is 100% safe, but that it guarantees some level of safety.
Also, it's pretty fucking funny that this phantom marketing machine that lied to us about Rust is a post from 11 years ago.
laffer1@reddit
That's when people got confused about Rust. The initial push from articles online. I get that you may not remember or be too young to remember the push. People ran with things they did say and didn't understand them. That still happens today with tech streamers. Consider lunduke's incorrect statements about various projects with age verification or his classic claim that https was bad.
Folks run with things without understanding them all the time. This isn't new.
UltraPoci@reddit
And that's the folks' fault, not "marketing" from an 11 years old post. I have learnt in 5 years ago, and I have never been confused about its claims.
The only times I have heard Rust being "the silver bullet" is from people like you claiming that some shadow cabal is forcing us to use Rust.
Also, lunduke is a fucking idiot, a moron, I wouldn't trust water to be wet if he says so.
laffer1@reddit
Not sure why you think I’m a rust hater. I’m not a fanboy of it. Is that why?
I do not love technology with all my heart. I use the right tool for the job. We seem to agree that people don’t all love rust and that there is misinformation. You don’t like how I worded it. That’s the issue here. We won’t agree because you want me to hate rust and I don’t. I wish it was more portable. All of my rust objections which is not what this is about, are based in that problem.
My entire point was there is misinformation and people with bad takes. You now assume I’m one of the people with the bad takes that hate rust. Don’t be that guy.
RendererOblige@reddit
I don't really see a problem with that statement. That doesn't claim that Rust is 100% safe, just that it has "safety guarantees", which is accurate. Nowhwere in that post does it say "Rust is safe".
laffer1@reddit
I agree the post doesn't say that, but it also doesn't explain the safety guarantee, which led to a lot of people jumping to conclusions with the initial push for rust. It's not the projects fault, but it happened.
You guys are bending over backward to ignore how the internet works.
UltraPoci@reddit
So you're saying every single person on this planet got Rust wrong due to a post from 11 years ago? Which has never claimed what you think it claimed, but it did corrupt mainds anyway? And we are bending backwards?
Just admit that for some, godforsaken reason it grinds your gears when Rust is mentioned and you have to absolutely do you worst to make sure it gets a bad reputation, all of fhis because you're attaching your ego to a programing language.
laffer1@reddit
No. I think some idiots in IT think they won’t have to deal with CVEs anymore if everyone rewrites every piece of software on the planet.
I have two issues with rust. First, I think they need to slow down on releases and put effort in getting the gcc port caught up. Second, I think they need to put pressure on llvm to support more operating systems so they in turn get wider support. The os and cpu architecture limitations are what hold it back from any chance of ever “replacing c” like some want. I don’t hate rust. I hate the effort of having to port it over and over again to my os. It’s quite time consuming and folks in that community adopt new features quickly which is a problem for including in base os or using rust apps. Linux folks don’t care about this part since you get it for free as a primary target.
araujoms@reddit
What marketing? I have never seen an ad for Rust, can you show me one? It's not as if Rust is backed by a for-profit company that advertises it.
Seriously, what have you heard about Rust solving everything, and who said it?
Gositi@reddit
I met a contributor to the Rust compiler a while back. He almost said this, at least it was clear he meant it. It was interesting to chat with him at first but after a while I didn't really enjoy his company. Mostly because he couldn't shut the fuck up about how Rust was the best.
Lower-Limit3695@reddit
One thing I can say about Rust is that is has tendency of separating the wheat from the chaffe because of its steep upfront learning curve and also the tendency of forcing developers to better reason about their code in order to get past compile time checks.
mrtruthiness@reddit
Interestingly, I've never heard anyone say this.
And even more interestingly, I would say I've heard the oppose (that "memory safety" doesn't mean "no exploits") maybe 1000 times.
And in that context, the OP makes it 1001 ... and some of us are tired of that.
laffer1@reddit
I'm tired of getting asked to rewrite everything for my project in rust by these people.
I suggest you look at other Reddit communities, X/twitter, and Slashdot posts about Rust over time. Lots of idiots out there are thinking it's invincible.
mrtruthiness@reddit
I don't read slashdot anymore. I don't have a twitter account.
I haven't seen these comments on the "programming" subreddit or the "rust" subreddit. I haven't seen such comments on Hacker News ( https://news.ycombinator.com/ ).
Certainly a lot of people are jazzed up about Rust, but I just haven't seen people say its invincible.
danbuter@reddit
Rust is only being implemented so companies can get rid of the GPL.
MatchingTurret@reddit
Huh? All Rust code in the kernel is GPLv2. The language has nothing to do with the license of code written in that language. BSD is (mostly) C and under the BSD License.
AWonderingWizard@reddit
Right now Rust code for the kernel is being compiled via a non-GPL compiler. GCCRS is not ready and who knows when it will be able to compile the standard lib.
FriendlyProblem1234@reddit
The license of a compiler is not related in any way to the license of what it compiles.
Also, it is still a free software compiler. GPL-2 is not the only free software license. And Rust compiler's license is compatible with GPL-2, so you (and I literally mean *you*, not the Rust maintainers) can get a GPL-2 Rust compiler today if you wanted: just relicense it.
What are you afraid it will happen? That someone forked the Rust compiler and created a new proprietary version? How would that affect you? You could still use the free software compiler to compile Linux.
Are you afraid that the Rust maintainer abandon the compiler and work on a proprietary project? They could do even if it used a copyleft license. You would still have the source of the free software compiler, so someone else could take over maintenance and development.
By the way, Linux kernel build system has a number of Python scripts (not to mention the countless components in the general Linux ecosystem implemented in Python). Guess what license does Python use? It is permissive, like MIT.
EdgiiLord@reddit
I think they meant that the Rust rewrites are done specifically because they can excuse launching non-GPL code by reimplementing in Rust for safer code. Language is not relevant, but jist the crutch which these companies use.
mistahspecs@reddit
You can already use bsd core utils silly
KnowZeroX@reddit
That makes no sense, is there some law or license that prevents C/C++ code from being non-GPL?
nukem996@reddit (OP)
The Rust coreutil developers are actively against GPL. It was requested early on to license GPL and even work with GNU but they denied both - https://github.com/uutils/coreutils/issues/834
FriendlyProblem1234@reddit
MIT can be relicensed to any GPL-X.
What could you do with a GPL-X version that you cannot do with MIT?
JustBadPlaya@reddit
Friendly reminder that for YEARS uutils was a project meant for learning and exploring Rust, and it mostly blew up into being a real thing like three years ago :)
KnowZeroX@reddit
If you want to argue that some companies are using the opportunity that while they are rewriting in Rust, they will also change the license, that is one thing.
But arguing that adoption of Rust is only for the sake of getting rid of the GPL is nonsense.
MatchingTurret@reddit
And? Their code, their license choice. You are free to write your own re-implementation and release it under the GPL or whatever you fancy.
nukem996@reddit (OP)
This is what I'm feeling as well. There is no real technical advantage to a rewrite of GNU utils.
MatchingTurret@reddit
So? Is there an advantage when people collect stamps? I mean, there are curated collections in museums. There is no advantage for someone spending their time doing it at home.
MatchingTurret@reddit
That's a question for the developers of rust-coreutils to decide. Since they are doing it, they obviously think so. Case closed.
tsammons@reddit
That's some gatekeeping garbage
KnowZeroX@reddit
I think you have things backwards, someone doing what they want with their time isn't gatekeeping. You deciding what someone else can't do a rewrite with their own time is gatekeeping.
tsammons@reddit
And someone erecting a barrier to anyone possibly impugning these developers isn't gatekeeping... but lemme guess, free speech?
kreuzouvert@reddit
Is that barrier in the room with us right now?
Nobody is keeping you from saying anything, as you yourself are demonstrating. What some people are doing is disagreeing with your takes.
Those people are right. If someone wants to rewrite something in Rust, they are free to do so. And it might come as a shock, they are free to do so even if you don't like it. You could rewrite coreutils in PHP if you want to. I'd find that odd, but you could.
tsammons@reddit
It'd be a poor choice for the job much like rewriting fundamental utilities than existed for decades in Rust is likewise a poor solution, but no one is really stopping this yet.
FriendlyProblem1234@reddit
In 1991 we had working kernels for decades. Was creating a new one in C a poor solution?
tsammons@reddit
Reinventing is not the same caliber as reimplementing. At least when one reimplements standards there is expectation of keeping vulnerabilities pristine, not introducing.
FriendlyProblem1234@reddit
Linux was originally just a hobby project. It caught momentum over time, but at the beginning it was really nothing special.
Not really. Everybody knows that a new project comes with many bugs.
Apparently Ubuntu's opinion is that those many initial bugs are a good tradeoff for when the project matures.
Do you disagree? No problem. Still, it is their choice of what to include in their distribution.
tsammons@reddit
It's a matter of shoehorning an incomplete project into critical binaries. 26 is a LTS FFS. At least do a separate channel like Rawhide if you want to compete on those merits.
This is why you reserve integration for terra incognita projects, dope.
Vehemently. This isn't how you steal market share from Redhat.
FriendlyProblem1234@reddit
"Shoehorning"?
Someone created this software, because they wanted, because they thought it was interesting, because they thought their choice of technology was a good fit... A distribution decided to include it as a default component (while keeping every other alternatives viable).
If you do not like it, there are at least a couple dozen other major distributions that chose differently. You cannot seriously demand that every single distribution picks the same set of components. Distributions do not and have never worked like that.
Nobody is "shoehorning" anything. There is no worldwide conspiracy.
I am not entirely sure what you mean here. I assume you meant that you do not pick a component as default choice before it reaches maturity.
Ubuntu deemed uutils mature enough. It is as simple as that.
kreuzouvert@reddit
I repeat, is that barrier in the room with us right now?
KnowZeroX@reddit
gatekeeping
the activity of trying to control who gets particular resources, power, or opportunities, and who does not
https://dictionary.cambridge.org/us/dictionary/english/gatekeepinghttps://dictionary.cambridge.org/us/dictionary/english/gatekeepinghttps://dictionary.cambridge.org/us/dictionary/english/gatekeeping
So them using their own time to do their own stuff isn't gatekeeping, you deciding what others do with their time or who can do this or that is gatekeeping.
tsammons@reddit
Stymying conversation isn't gatekeeping; got it.
KnowZeroX@reddit
Which brings back the question of why you felt someone doing things with their own time is gatekeeping?
tsammons@reddit
Matter of shutting down open discussion by matter-of-factly stating how a members of a group spend their time on a project for a business trying to compete with Redhat that has all the three letter agencies nested is somehow good for Canonical.
You reap what you sow.
MatchingTurret@reddit
Are you suggesting you can decide what others do in their spare time?
tsammons@reddit
I'm stating folks have a right to be skeptical of how these cathedrals operate and ask questions germane to the topic at hand without getting broadsided as you've so unskillfully attempted.
I'm a dev. I've been for 25+, focus is in PHP and C. It's right to ask questions and interrogate in these situations when multiple flags are raised. I'd expect the same for my line of work if this happens.
0riginal-Syn@reddit
You do have the right to be skeptical and ask questions. The devs and project leaders of a project also have the right to disagree with them and continue down the path they choose as it is their project. I have my skepticisms about uutils no doubt, but they do not have to listen or agree with my views, and that does not take away my right to have my view on it. If you don't like it, fork it or use something else. No one is gatekeeping or saying you don't have a voice.
tsammons@reddit
Outside of u/MatchingTurret and sycophants et cetera, I'm inclined to agree.
MatchingTurret@reddit
No, you don't. What someone does in their time is absolutely their decision. It's solely up to them whether they go hiking or rewrite code in Rust.
tsammons@reddit
There's an implied responsibility to public ownership. Don't build a product if you're going to half-ass it, slob.
Tireseas@reddit
id you materially contribute code or funds? No? You don't own shit son. You're just being allowed to benefit from the work of others.
boukensha15@reddit
This is the stupidest comment in this thread. I am not forcing them to do anything but giving a feedback on something that they are building. It actually benefits them.
Tireseas@reddit
Was I even speaking to you?
tsammons@reddit
I did quite a bit of work on the PHP D-Bus extension then submitted it back. Prior work was mod_evasive work; rewrote it as mod_shield. I share and share alike.
Tireseas@reddit
That's a fine thing to do. Thank you for the work you've contributed. Doesn't change anything stated though.
tsammons@reddit
It doesn't and this thematic snark will result in rust-coreutils decoupled.
MatchingTurret@reddit
What "public ownership"?
tsammons@reddit
Released under MIT slammed into Linux. Packaged under an Ubuntu distro. The public has free will to do with it as it would; stewardship is under Ubuntu. Anything else I can help you with?
dvtyrsnp@reddit
It's literally the opposite of gatekeeping
nukem996@reddit (OP)
Rust rewrites are being pushed onto users. Ubuntu 26.04 changes your default from GNU coreutils/sudo to Rust. Why automatically change the default on something that has worked for decades without even asking the user?
0riginal-Syn@reddit
Ubuntu is a corporate distro, far more so than the likes of Fedora. Ubuntu is used both by the community and by the companies where they make their profit. They are going to build it to the standard that makes them money, as Canonical is a for-profit corporation. If you don't want a corporate-backed distro that will make choices based on their business, not users, then I suggest not using one.
FriendlyProblem1234@reddit
By whom? This is just a distribution choosing a particular implementation. There are countless other distributions that choose other implementations.
Do you suggest every single distribution should use exactly the same set of components?
Yeah, that is literally what distributions are and do. They are collections of third-party components.
AnsibleAnswers@reddit
Just install debian bro.
MatchingTurret@reddit
Because it's their distro and users are free to use something else.
boukensha15@reddit
Users are also free to voice their opinion and discuss issues.
Lower-Limit3695@reddit
If you don't want it, nothing stops a user from uninstalling it and reinstalling gnu coreutils. The point of linux is the freedom to make any change you want and that same freedom is applied to the distro maintainers.
st945@reddit
He's basically saying it's not worth it and Ubuntu shouldn't push it because he doesn't like it.
Li0n-H3art@reddit
But a rewrite of something that is battle tested and works is almost always never a good idea. Unless you want to change the implementation or your current implementation no longer supports your needs.
LordAlfredo@reddit
By that argument we should not have started Wayland.
MatchingTurret@reddit
Imagine Linus had this attitude when he started Linux. BSD was out there and Hurd supposedly just around the corner...
Li0n-H3art@reddit
I fail to see your point? Linus created something different. He didn't just rewrite the BSD kernel in a new language. What he did was similar to initd vs systemd. So how exactly is that the same?
gmes78@reddit
uutils isn't also exactly the same as coreutils. It has additional features.
boukensha15@reddit
No. BSD wasn't available for free.
mrtruthiness@reddit
I believe it was. Linux was first announced Aug 1991.
BSD was first made available for free in June 1989 with the release of Networking Release 1. This version included Berkeley’s networking code and utilities, which were independent of proprietary AT&T code. Later, the more comprehensive Networking Release 2 was released in 1991. There were, some legal issues to settle ... but that was completely settled with the 4.4BSD-Lite in 1994.
MatchingTurret@reddit
https://gunkies.org/wiki/Net/2
AutoModerator@reddit
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
Xoph-is-Fire@reddit
OP can't even properly read the results.
FlukyS@reddit
To be clear no one has ever said that there aren't CVEs in Rust, people confuse memory safety with safety in general, developers still make mistakes in logical flow which can cause issues. The CVE score of all of these are mostly 7 and below, usually scores that low are very low probability issues that usually involve having access to the hardware itself.
For example the worst one was https://github.com/uutils/coreutils/pull/10033/changes
It was just a mistake which allowed a pretty hilarious chmod -R 000 to brick their install either accidentally or on purpose. There was the preserve root flag which disallows doing that or like a recursive rm on root but there was a way around it. It technically is a DOS risk but you would need access to the machine and access to the sudo password to do it. This is though not a Rust problem, it is a bug.
TheBendit@reddit
Coreurils fundamentally cannot have bugs of severity 8 or higher. They cannot be run unless you are logged into the system.
Local root escalation is as bad as it can get, and there are two of those.
Serialk@reddit
Lol, that is the worst bug? If anything this makes me trust uutils even more now.
SummerOftime@reddit
Rust code is safe as long you do not use
unsafewhich is a must when calling system callsLaerson123@reddit
That's not true at all.
The only thing Rust prevents is a specific class of bugs related to reading invalid memory addresses, and unexpecting overwriting values that are going to be used somewhere else.
It is still 100% possible to write vulnerable code. Not every vulnerability is caused by buffer overflows and data races. Rust doesn't magically get rid of poorly written logic, memory leaks and injection attacks.
FlukyS@reddit
unsafe in Rust is specifically where you wish in certain situations to use unsafe memory handling like how it is in other languages like C and C++ this has nothing to do with unsafe, these are logical bugs. I'm not sure anywhere in the Rust Coreutils or Sudo products use unsafe memory handling.
SummerOftime@reddit
Watch and learn - https://x.com/filpizlo/status/1984366437390303265
FlukyS@reddit
What does that have to do with my response, you incorrectly brought up about memory safety when my comment was talking about how people confuse memory safety with just logical issues causing security issues. Like you basically proved my point and then linked some random video about something I don't want to watch and don't care about. I like the syntax of Rust too not just the memory safety.
SummerOftime@reddit
So you wrote all that shit without watching the source. Two-digit IQ move right there.
FlukyS@reddit
Wait what? Literally a 1 second google answers it, either you are actually an idiot or just a poor troll either way I don’t care.
SummerOftime@reddit
Cool story Claude, I need to write a python code to reverse a list. Can you help me?
FlukyS@reddit
OK that answers my question on if you are a poor troll I guess, have a nice evening
EzeNoob@reddit
We learned about garbage collectors a couple of decades ago already.
Hopeful-Ad-607@reddit
But its pretty nice to have the strict borrow checking everywhere else that you're not, and you may write unsafe blocks in modules that are tested and reuse them.
LordAlfredo@reddit
113 issues, 44 CVEs, 4 High sounds like they did a pretty effective audit. Curious to see what they'll find in other projects by the same techniques.
itsbakuretsutimeuwu@reddit
113 Issues, not cves, there are much fewer cves, and there is a list in the very post you're referring to
ChrisTX4@reddit
The article says it even, it's 44 CVEs and 69 other issues. Still, 44 CVEs is quite a lot. You can find the CVEs including their CVSS score here. In total, there's 4 high severity CVEs (CVSS >= 7), 25 medium severity CVEs and 15 low severity ones.
LordAlfredo@reddit
Speaking as someone working on an enterprise distro, that's actually a pretty normal CVE volume for a large major package. E.g. GoLang 1.25.8 -> 1.25.9, a minor point release, closed 10.
itsbakuretsutimeuwu@reddit
> 4 high severity
Okay, so we have:
mkfifo changes permissions to default where it wasn't supposed to (sucks, but if you can run mkfifo with this bug, you can run chmod from the current user too; doesn't matter for new files which is what it is used for).
mkfifo again has race conditions that allows someone to change permissions to an arbitrary file via symlink (literally chmod is right there, buddy).
chmod can be messed with /../ when it wasn't supposed to (but for it to really matter you need to be root)
chroot has arbitrary code execution (but to use chroot you need to be root)
What a meme
juicebox1156@reddit
You seem to be misunderstanding how to exploit these bugs. Do you think Canonical assigned these severity ratings? They are evaluated by NIST, an external 3rd party.
> mkfifo changes permissions to default where it wasn't supposed to (sucks, but if you can run mkfifo with this bug, you can run chmod from the current user too; doesn't matter for new files which is what it is used for).
The issue is if mkfifo is being run as root, you can stick a file at the target of the mkfifo and inadvertently gain root privileges. It has nothing to do with running mkfifo with the user you already have.
> mkfifo again has race conditions that allows someone to change permissions to an arbitrary file via symlink (literally chmod is right there, buddy).
Same thing, the issue is if mkfifo is being run by root. If you have write privileges to the directory, you can then replace the target of mkfifo with a symlink and give anything root privileges.
> chmod can be messed with /../ when it wasn't supposed to (but for it to really matter you need to be root)
Yeah bro, root users often run chmod, and an attacker can setup ../.. to make root users accidentally fuck up directories they didn't intend to.
> chroot has arbitrary code execution (but to use chroot you need to be root)
Administrators often use chroot to run a program in an isolated environment. The programs aren't meant to have root privileges, so this is a real issue.
ChrisTX4@reddit
Well, the point of these vulnerabilities is more that an elevated user could run commands and then have unintended side effects.
For example,
chrootis commonly used for Postfix, where it would be invoked by root. If one could mess with the way the chroot is set up, it might be possible to elevate privileges.It should be noted as well that other than CVE-2026-35338 the remaining high severity CVEs all have "high" attack complexity in their CVSS vector.
laffer1@reddit
Someone people try to make a cve for every bug. It’s crazy
Personal_Breakfast49@reddit
As a neophyte, how is it categorized?
AnsibleAnswers@reddit
ELI5: A CVE is a record of a vulnerability, which is a flaw in code (bug) that has security implications. All vulnerabilities are bugs, but not all bugs are vulnerabilities.
k-phi@reddit
If you say so
itsbakuretsutimeuwu@reddit
Was it submitted as a 'vulnerability' (that is, yes, that's thing is broken, but does it let somebody do something interesting that they're not supposed to be able to do?) and deemed so by some cve authority? Then it gets a cve number and is a cve.
But just because something is a cve doesn't mean it's actually practical to exploit or important, especially if it's low severity.
Ignisami@reddit
IIRC it's Kernel policy to treat every bug as a CVE because of how foundational it is to the Linux ecosystem
dddd0@reddit
No
laffer1@reddit
this is userland
Ignisami@reddit
I'm aware. Was just responding to the obviously exasperated 'some people' with a situation where it makes sense to do so.
mrtruthiness@reddit
Thanks!
FYI: wc says 44.
reveil@reddit
Rust give you memory safety. Memory safety related CVE's are 70% of the total CVE's. This does not mean you can ignore security as you are just as susceptible to the other 30% if you were using any other language.
AmarildoJr@reddit
Yes, because this push is primarily about replacing the GPL with the MIT license, not about security.
23Link89@reddit
I really do not believe this has anything to do with Rust as a technology. Also no Rust does not prevent CVEs, there's no such tool that exists.
This just sounds like shit software development practices, this project is ridden with tons of bugs and issues. It just sounds like its being mismanaged or not properly tested, which is stupid because Rust has a very nice unit testing system and tons of tooling for advanced unit testing harnesses.
TL;DR Rust doesn't necessarily make you a good engineer
MatchingTurret@reddit
Sashiko has already prevented a few from landing in the kernel.
IshYume@reddit
It just shows you don’t understand how CVEs work, memory safety doesn’t mean your program doesn’t have security vulnerabilities, people make mistakes while writing code resulting in vulnerabilities.
Whether you write it in C, Rust or Java logical errors or edge cases will lead to a vulnerability in your program.
fellipec@reddit
People are saying that. And saying that is inevitable that those new tools to be worse than the battle tested ones, and will take a long time to catch up. Also people are saying that the change is more about the license than the language.
rumbleran@reddit
No, it's definitely not worth it. The Rust version is also much slower than the original GNU coreutils.
KnowZeroX@reddit
No one claimed Rust is some magic where CVEs don't happen, all Rust does is significantly reduce memory issues, helps with error handling, and makes it easier to refactor and maintain.
That said, it goes without saying that ubuntu may have rushed too quickly to use it, especially in their LTS branch.
mistahspecs@reddit
Ooo very valid critique in that 2nd sentence. Glad they're funding an audit, but yeah maybe that should have happened first, esp for LTS
TheBrokenRail-Dev@reddit
Well, duh?
Rust is designed to be memory-safe by default. Of course, it can still have vulnerabilities! It can even still have memory-related vulnerabilities if you write
unsafecode!Rust never claimed to completely eliminate vulnerabilities. It just claimed to make it far easier to write memory-safe code without worrying.
RoomyRoots@reddit
What a wast of resources.
mistahspecs@reddit
How so? I see you have freebsd flair, I'm also a big freebsd user. Linux is overwhelming dominant in virtually every use case that freebsd could be used for, yet you and I presumably both believe that work on it is still valuable.