The coreutils Rust rewrite story is pretty funny.
-
@Doomed_Daniel@mastodon.gamedev.place @lcamtuf@infosec.exchange @ireneista@adhd.irenes.space I think you mistook musl for BusyBox. I did the same thing in my head. (musl is an MIT-licensed C standard library implementation) It appears BusyBox (alternative to gnu coreutils) is also licensed under GPLv2, unfortunately.
-
@david_chisnall @lcamtuf Try to write to C++ ‚cout‘ concurrently. Complete clown fiesta!
using std::cout concurrently does not cause data races (no UB). If youvwant to get output readably together use std::osyncstream wrapper around the global object or any other shared ostream object.
-
@Seirdy@pleroma.envs.net @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space one of the things you notice when you're using MacOS, FreeBSD etc... they parse arguments differently. They don't rely on getopt_long (GNU's getopt shit) and so you end up with situations like
rm -rf ./shitass -v
not running because -v is an unknown file, and it expects the arguments before. -
@Seirdy@pleroma.envs.net @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space one of the things you notice when you're using MacOS, FreeBSD etc... they parse arguments differently. They don't rely on getopt_long (GNU's getopt shit) and so you end up with situations like
rm -rf ./shitass -v
not running because -v is an unknown file, and it expects the arguments before.@lcamtuf@infosec.exchange @Seirdy@pleroma.envs.net @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space like it's really kinda fascinating in a way, but also immensely frustrating if you were used to "gnuisms".
-
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 the only dumb thing I can see is that Canonical decided to switch before a comprehensive external audit had been performed.
-
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.
-
-
@ireneista@adhd.irenes.space @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place I thought it was entirely independent from gnu coreutils.
-
@lcamtuf@infosec.exchange @Seirdy@pleroma.envs.net @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space like it's really kinda fascinating in a way, but also immensely frustrating if you were used to "gnuisms".
@puppygirlhornypost2@transfem.social @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place @ireneista@irenes.space ShellCheck my beloved
-
@Seirdy @ireneista @lcamtuf @puppygirlhornypost2
but things like PCRE2 are probably not that critical here, at least if there is some PCRE2-compatible regex implementation for rust that can be used there.
At least looking at that posts about the CVEs, the critical knowledge is what system calls to use in what order with what arguments to avoid race conditions when creating files and such (and setting their permissions)
-
@lcamtuf@infosec.exchange @Seirdy@pleroma.envs.net @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space like it's really kinda fascinating in a way, but also immensely frustrating if you were used to "gnuisms".
@lcamtuf@infosec.exchange @Seirdy@pleroma.envs.net @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space i find it annoying because on GNU coreutil systems i am so used to being able to just append whatever flag i forgot to put in the front and then it's like
nah -
@darkuncle @ChuckMcManis @lcamtuf Sure, but perhaps don't do your learning in production?
@sten @darkuncle @ChuckMcManis @lcamtuf
you expect rare race conditions to occur anywhere but production?
-
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 Something something reinventing the wheel something.
Jokes aside, I guess that's a very real metaphor... Wheels started off with wood, which of course can break, rip apart at high speeds, etc. We have better treatments and such for wood today than in the olden days, but it still means most of the fundamental issues remain... If you reinvented from scratch, you have to relearn some of that stuff.
-
@Seirdy @ireneista @lcamtuf @puppygirlhornypost2
but things like PCRE2 are probably not that critical here, at least if there is some PCRE2-compatible regex implementation for rust that can be used there.
At least looking at that posts about the CVEs, the critical knowledge is what system calls to use in what order with what arguments to avoid race conditions when creating files and such (and setting their permissions)
@Doomed_Daniel@mastodon.gamedev.place @ireneista@irenes.space @lcamtuf@infosec.exchange @puppygirlhornypost2@transfem.social I’m just saying that slim POSIX implementations that prioritize small size aren’t the best references for a clean-room GNU coreutil rewrite. FreeBSD utils and GNU documentation would be better.
Given the different language, I’m not sure that lightly referencing the GNU source code would even pose a legal risk.
-
@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.
One thing that the Rust rewrite of coreutils tried to do was to prove that it was making steady progress by the number of test cases originating from GNU coreutils that it could pass.
I very much suspect that there's a whole host of race condition tests that made it into the test corpus late in the game.
Test-driven rewrite has its limits.
Note the uptick in failures at the very right edge of the graph, they are currently under 90% tests successful.
-
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 Or why crappy abstractions for POSIX APIs are worse. -
@Doomed_Daniel@mastodon.gamedev.place @ireneista@irenes.space @lcamtuf@infosec.exchange @puppygirlhornypost2@transfem.social I’m just saying that slim POSIX implementations that prioritize small size aren’t the best references for a clean-room GNU coreutil rewrite. FreeBSD utils and GNU documentation would be better.
Given the different language, I’m not sure that lightly referencing the GNU source code would even pose a legal risk.
@Seirdy@pleroma.envs.net @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space Also, BSD-Clause and MIT are compatible licenses. IANAL though, so I'm hesitant to discuss how this would actually impact "porting" BSD-Clause code from C to an MIT Licensed Rust codebase
-
@xerz @star @hypha @lcamtuf Switching to dependencies with a single non-replaceable toolchain is also irresponsible.
Core utilities should not rely on something that can believably be slopped into oblivion with no viable replacement (C compilers are a dime a dozen and comparatively much easier to implement, with many functional replacements readily available).
Proper specification of all the core toolchains should be a bare minimum. -
@lcamtuf@infosec.exchange @Seirdy@pleroma.envs.net @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space i find it annoying because on GNU coreutil systems i am so used to being able to just append whatever flag i forgot to put in the front and then it's like
nah@puppygirlhornypost2 @ireneista People talking about UX are often talking about GUIs but aside from GNU making clean copyleft license versions of the (at the time) proprietary Unix utils, GNU also spent a lot of effort in UX like long options and fewer arbitrary restrictions (which made sense on a PDP but not on the larger systems of the 90's and later) which is how they got to be so popular, before Linux was even created. It's too bad that some of the other systems keep looking back farther for inspiration rather than looking around and forward for what the UX of a Unix should be.
-
@puppygirlhornypost2 @ireneista People talking about UX are often talking about GUIs but aside from GNU making clean copyleft license versions of the (at the time) proprietary Unix utils, GNU also spent a lot of effort in UX like long options and fewer arbitrary restrictions (which made sense on a PDP but not on the larger systems of the 90's and later) which is how they got to be so popular, before Linux was even created. It's too bad that some of the other systems keep looking back farther for inspiration rather than looking around and forward for what the UX of a Unix should be.
@raven667 @puppygirlhornypost2 they did, yeah, you're right. they deserve credit for that work.
they did so in a time when UX wasn't yet a science (or rather, design was a science but had not been made rigorous in the domain of computing), so perhaps it's understandable that they still have a ton of UX problems... but you're right. still way better than earlier attempts.
