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.
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.
-
-
-
-
@sten @lcamtuf sorry, it's been literally years since the last time I cared enough about this, so I don't have the links at hand. From what I remember, the dev(s) that got the project started claimed to not care about the license and that they would consider relicensing if the community showed an interest, but shot down all proposals to switch to GPL with no discussion.
Officially t's explicitly NOT about that:
«It is not primarily […] about license debates.»
-
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 It's even sillier because the Rust rewrite was just someones hobby project to learn Rust, it wasn't engineered from the start to be the "Canonical" implementation, so picking it off the Internet and shoving it into Ubuntu is an engineering decision that the professional Ubuntu engineers should be accountable for, not the original developer who just shared their work with the world.
-
@darkuncle @ChuckMcManis @lcamtuf Sure, but perhaps don't do your learning in production?
@sten @darkuncle The old joke that _everyone_ has a testing environment, some are fortunate enough to have a separate Production environment
-
@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.
@miss_rodent @lcamtuf If that was all they wanted, the BSD toolset is just sitting there….
-
@lcamtuf See this all the time - people storm in trying to change things before trying to understand how the current things work. People who don't learn from what's been done before. Society doesn't progress from efforts like theirs. You only make progress by learning from and building on top of what came before.
-
@miss_rodent @lcamtuf If that was all they wanted, the BSD toolset is just sitting there….
@grumpybozo @lcamtuf afaik the BSD core utils aren't entirely compatible with the gnu core utils, still?
But yeah, there are more permissively licensed versions of the *nix coreutils already; rust uutils is aiming to be a drop-in replacement for the gnu coreutils specifically, though, which means all the gnu-specific extensions and peculiarities. Which, previously, were basically only under the gpl (and some scripts and such can break if you don't have those, so, it's a meaningful difference.) -
@grumpybozo @lcamtuf afaik the BSD core utils aren't entirely compatible with the gnu core utils, still?
But yeah, there are more permissively licensed versions of the *nix coreutils already; rust uutils is aiming to be a drop-in replacement for the gnu coreutils specifically, though, which means all the gnu-specific extensions and peculiarities. Which, previously, were basically only under the gpl (and some scripts and such can break if you don't have those, so, it's a meaningful difference.)@miss_rodent @lcamtuf Right, there are some variances in command line options, usually in areas not covered by POSIX.
-
-
@lcamtuf very much a Chesterton's Fence kind of situation
@darkuncle tysm for pointing me to this amazing parable, amigos.
️
-
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.
@david_chisnall @lcamtuf Well people have opinions: https://mastodon.social/@pid_eins/116459585811044061
-
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 Amusingly, I recently did some work in Rust and wanted safe file operations that avoided race conditions. I couldn't find anything good and wrote my own opinionated helper.
Though, a large part of it is that O_TMPFILE is awesome and underused.
-
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@infosec.exchange Also quite few are noticeably fails in implementing POSIX, which makes me wonder if they’re only caring about coreutils testsuite and
--help/help2manoutput.Like CVE-2026-35367 (
nohup(1)permissions) as Colin Funk noted, but also CVE-2026-35369 (kill -1), CVE-2026-35370 & CVE-2026-35371 (real vs. effective inid(1)), and CVE-2026-35379 (wrong character classes intr(1)) -
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've heard a lot of funny stories like this in previous years. Like for example a startup trying to rewrite the TCP stack by their own from scratch because they can do it more efficient.
Soon they learned how a real environment, or better said, the real life really is. -
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 it's frustrating because in some sense we all had the opportunity to learn this lesson, a long time ago
we remember when we were kids, after Netscape went bankrupt trying to re-write their software from scratch, there were some good essays analyzing what went wrong and advocating for refactoring instead so as not to lose the knowledge that's in the code
and then there's the ATC system
like... there's so many past instances to learn from
-
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 mean, not a single one of the issues were memory-safety-related, which is noteworthy, cause GNU/BSD coreutils still regularly get memory-related issues
-
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 Dang, that is a wild ride of a thread.
And it kinda lines up with my experiences as well-- coreutils is battle tested and a load bearing feature of Linux.
Uutils is just too new to get all of the behavior exactly the same. I've tested it on my nix machine in the past, and alothough I never pushed uutils quite as far as it could have gone in order to discover any of these bugs, I kind of shudder to think what would have happened if I had.
Very interesting to think that the concept of C isn't exactly bad-- but it just needs a long time to mature and get it right, just like any program. The fact that the Rust compiler prevents you from making memory errors doesn't also prevent you from misunderstanding CPU clocks or buffer overflows or race conditions and other low level stuff.
