The coreutils Rust rewrite story is pretty funny.
-
@ireneista @q @erincandescent @pinskia @lcamtuf hrm, we've seen the "engage with OSes" perspective quite a bit recently, but we're personally much closer to the attitude of "OSes have dragged their feet so much that everyone making applications decided they're just not going to play that game anymore (and hence finding better and better ways to bypass the OS)"
@r @ireneista @q @pinskia @lcamtuf i think the unix desktop (collectively) has certainly dragged its feet on a lot of things just through lack of a forcing function. the only common way of doing X is often the way it was done in 1996. if you need things you couldn’t do in 1996, well…
-
@r @q @erincandescent @pinskia @lcamtuf the web platform's governing bodies, and the ungoverned steering that browser vendors do without engaging with the official processes, are also perfectly capable of making bad decisions, becoming frozen in time, etc
it's in a slightly more community-focused place than most OSes right now, but that doesn't make it immune to those social problems
@r @q @erincandescent @pinskia @lcamtuf one way or another
a platform that is worth our time personally is one that is community-driven
we have high standards for that. we do not accept governance processes that are merely for show, without true accountability. we do not accept processes that prioritize the interests of capital and states above the interests of people.
-
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 well at least it's larger and slower
-
@r @ireneista @q @pinskia @lcamtuf i think the unix desktop (collectively) has certainly dragged its feet on a lot of things just through lack of a forcing function. the only common way of doing X is often the way it was done in 1996. if you need things you couldn’t do in 1996, well…
@erincandescent @q @r @pinskia @lcamtuf yes, certainly. it's a different pathological niche than the web platform, but no less pathological.
-
@lcamtuf I legitimately wonder what it is about Rust that inspires people to start questionable porting projects in the first place. Like, who asked for coreutils in Rust?
@BalooUriza People who hate the GPL and wanted to get rid of it, from what I heard.
-
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.
-
@ireneista @lcamtuf I think in this case it would've been possible to properly rewrite hem one by one, but the metric appears to be more a quantity-over-quality "lets get this out of the door quickly", i.e. the incentives weren't placed right.
@fogti @ireneista @lcamtuf but why do it at all? I'm usually among the first to advocate beating with blunt objects as punishment for using C in any serious context, but these are some of the most extensively stress-tested pieces of software known to mankind and, as the OT states, not to be expected to be plagued by hideous hidden memory bugs anyway.
-
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
$ mkfafo --version -
@fogti @ireneista @lcamtuf but why do it at all? I'm usually among the first to advocate beating with blunt objects as punishment for using C in any serious context, but these are some of the most extensively stress-tested pieces of software known to mankind and, as the OT states, not to be expected to be plagued by hideous hidden memory bugs anyway.
-
-
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.
-
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 original code accounted for decades of hard-learned lessons in that space."
Yeah, that was in a textbook - sorry, forget which one - I read decades ago. Not news.
(The general message as described in that sentence, not this specific case.)
-
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 Tiobe index still gives Rust very low percentages: it will take some years to rise as Java did before, or to go where Python is now. Someone ignites faster, some slower, but in the end they all live in the hope to burn C. Which doesn't take fire, and looks at all these fireballs passing.
Or maybe not, and suddenly C will disappear. I bet my five cents it won't happen in my lifetime. In any case, I voluntary plan to be cremated
And to not be listed on Tiobe index! 
-
@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.@puppygirlhornypost2@transfem.social @Seirdy@pleroma.envs.net @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space
(dnf, redhat's package manager, doesn't either🫠) -
@q @ireneista @erincandescent @pinskia @lcamtuf we know *for sure* that browsers get involved in "emoji presentation" because we reported a bug in that area
Firefox also has a hack workaround to ignore "Segoe UI Emoji" for country flags, specifically to fix Mastodon (and some other sites of this nature which use a "OS font stack" philosophy)
@q @ireneista @erincandescent @pinskia @lcamtuf
y'know, with how much advanced typography browsers actually do support....we've seen an extremely stale and unimaginative set of UI/UX paradigms that take advantage of basically none of it
-
@q @ireneista @erincandescent @pinskia @lcamtuf
y'know, with how much advanced typography browsers actually do support....we've seen an extremely stale and unimaginative set of UI/UX paradigms that take advantage of basically none of it
@r @q @erincandescent @pinskia @lcamtuf yeah exactly.... it's no longer a generative process, in the social sense. new features no longer fire up public excitement to see what people can make with them.
-
@ChuckMcManis @lcamtuf came to say this, you beat me to it, well done
-
@r @q @erincandescent @pinskia @lcamtuf yeah exactly.... it's no longer a generative process, in the social sense. new features no longer fire up public excitement to see what people can make with them.
@r @q @erincandescent @pinskia @lcamtuf ouch.... we just realized, the last time we saw people excited to be creative with a new browser feature
it was JPEG XL
-
@r @q @erincandescent @pinskia @lcamtuf ouch.... we just realized, the last time we saw people excited to be creative with a new browser feature
it was JPEG XL
@ireneista @q @erincandescent @pinskia @lcamtuf oh, that's way more recent than the last time we were excited: the long painful drawn-out process of rolling out ES6 modules (which apparently "everybody else" gave up on, because bundlers)
-
Deus forbid if they create a functional specification of how the existing utilities work, before converting / rewriting them in a new language
️@simonzerafa
But the question is also where the responsibility lies for the lack of documentation and (much more importantly) unit tests. If the learning curve was so steep when it came to eliminating all race conditions, where are the tests that verified precisely these issues? Of course, it’s clear that the bug-fixing culture at the time didn’t have a “must-have 100% test coverage” requirement. But it’s also not easy to implement these tests now through reverse engineering.I don't think a lack of documentation and testing is necessarily the main obstacle to a new development. In fact, they might even be a reason for it.
However, you shouldn't put such newly developed software into production right away.
@lcamtuf
🥰
️
