The coreutils Rust rewrite story is pretty funny.
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf
Many of those seemingly trivial utilities are surprisingly complex: sort runs in multiple concurrent threads, "cp -a" must build a lookup table to detect hardlinks, and ps parses obscure files in /proc. There's plenty of ways to screw up that a type- and memory-safe language would catch.That said, the list of CVEs in the post is really impressive. Ditching the good old GNU coreutils might have been a tad overhasty.
-
https://www.lego.com/en-us/product/death-star-75419 would like a word.
-
@lcamtuf i do find that the crates dedicated to atomic file handling and temp files, in the interest of providing a uniform platform interface aren't as good as what's reachable in c.
it's not a fault of the rust language per se, but writing a safe interface at that level isn't easy, so it makes sense (and is in some sense a better default) to have high level, platform neutral access here.
@prozacchiwawa @lcamtuf yeah, but coreutils is an interface for shell languages. The shell doesn't care if underlying "util" was written in C or Rust
-
@darkuncle @ChuckMcManis @lcamtuf Sure, but perhaps don't do your learning in production?
@sten @darkuncle @ChuckMcManis @lcamtuf is it really production if it's not on my machine ?
-
@sten @darkuncle @ChuckMcManis @lcamtuf is it really production if it's not on my machine ?
@m33 @sten @darkuncle @ChuckMcManis @lcamtuf
yep, production is for debugging -
@lcamtuf Not only that, some of the utils were not command line-compatible with their non-Rust counterparts.
Honestly, I don't understand why these utils were rewritten. They didn't need rewriting.
-
@sten @darkuncle @ChuckMcManis @lcamtuf is it really production if it's not on my machine ?
@m33
I discovered at Google a tremendous laziness and lack of rigor because "well if it doesn't work or has problems we can roll it back." I came to think of it as The Google Principle and it can be more easily written as:The amount of care and thought that goes into a software change is proportional to the perceived difficulty of pushing that change into production.
-
@lcamtuf Not only that, some of the utils were not command line-compatible with their non-Rust counterparts.
Honestly, I don't understand why these utils were rewritten. They didn't need rewriting.
-
@lcamtuf a related observation would probably be: why did important, security-critical edge cases get handled without enough documentation to prevent them from reoccurring?
-
@lcamtuf There's also that human habit of getting complacent about all bugs when _some_ types of bugs are either impossible or very very hard to make because of language structure and tooling.
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf Yeah, but they got to license-wash the coreutils, the gnu coreutils are GPL3, the rust uutils use the much more corporate-overlord and user-abuse friendly MIT license.
-
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf I don't take this as a dunk on Rust, I take it as a (well-deserved) dunk on repositories that accept PRs that vibe-coded entire features that clearly no one understood. Which adds even more hidden costs.
-
@sten @darkuncle @ChuckMcManis @lcamtuf is it really production if it's not on my machine ?
@m33 @darkuncle @ChuckMcManis @lcamtuf An excellent point that I have to admit I hadn't considered.
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf coming in at #1 with a bullet on the Joel On Software 'things you never do' list
(know its common wisdom, but think Joel articulates it very well)
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf I always looked at this project as a sort of hobby, a learning exercise, maybe just a lark, or a "maybe one day we'll have a useful alternative"...and then Canonical went and adopted it before anyone could reasonably believe it was of production quality
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
It’s frustrating that POSIX took decades to get APIs that weren’t intrinsically racy, but then higher-level languages that post dated the improved ones implemented equivalents of the old racy APIs. C++ was annoying, they waited until pretty much every platform that supported C++ and had a filesystem implemented the newer APIs and then standardised the filesystem TS with racy ones. I believe Rust is similar, but at least it has cap-std which implements the non-racy versions as an alternative standard library.
-
-
-
