I see this accusation and characterization in basically every thread about Rust, but I really don't think it's true. On the contrary, I strongly believe it's less that these people didn't consider that, and more that they willfully chose to ignore it.
If you always keep praying to the same old bit of code to "reliably" chug along (which people clearly cannot actually ascertain, otherwise these reimplementations wouldn't be struggling), you're forever just rolling the dice that some Pandora's box will simply never open (which it absolutely does and keeps opening), while also giving up on modern capabilities. What you see as old reliable, I see as a buried lede. I'd imagine these folks see the same. [0]
It's frustrating to see the software world contend with the same pushback and counter-arguments the infra/ops world (my neck of the woods) has already figured out and went past long ago during the advent of IaC. Cattle > pets, easily, every time.
[0] It's also not a cost-benefit thing, but clearly a principled decision, so arguments that aim to contend the ROI of it all are off-base from the get-go. If ROI is the key thing for you, then all this philosophical nonsense shouldn't even be on the table. Calculate.
“battle tested for decades” just lost a lot of its value with Mythos and the likes unfortunately. Rewriting in a different language became much faster with Coding agents at the same time.
I do agree that the second system effect is real, it’s just that the balance of benefits and drawbacks significantly shifted when it comes to “rewrite in Rust” (not limited to Rust though).
https://www.cve.org/CVERecord?id=CVE-2026-35341 - `mkfifo` accidentally resets the permissions of files that already exist, so if you manage to do `sudo mkfifo /etc/shadow` then it becomes world readable.
Tbh I doubt if any of these would ever result in a real hack, unless your system is doing really mental things like running shell scripts with untrusted input.
I could only find a couple of CVEs that looked actually serious for GNU Coreutils too though. IMO if you're using these tools with untrusted input your system is janky enough that there are going to be serious flaws in it anyway. Probably though quoting mistakes.
Well the TOCTOU issues do not require you to run untrusted scripts to be exploited. Another user on your system can use a legitimate command that you may run to make changes to files they shouldn’t be able to, or further escalate privileges.
That was a lot of CVEs
Goes to show that not all security bugs are memory related bugs
Not aimed at you but... no sh*t. The "Rewrite it in Rust" community never heard of the second-system effect.
I'd rather use something written in a crappier language that has been battle-tested for decades, personally.
I see this accusation and characterization in basically every thread about Rust, but I really don't think it's true. On the contrary, I strongly believe it's less that these people didn't consider that, and more that they willfully chose to ignore it.
If you always keep praying to the same old bit of code to "reliably" chug along (which people clearly cannot actually ascertain, otherwise these reimplementations wouldn't be struggling), you're forever just rolling the dice that some Pandora's box will simply never open (which it absolutely does and keeps opening), while also giving up on modern capabilities. What you see as old reliable, I see as a buried lede. I'd imagine these folks see the same. [0]
It's frustrating to see the software world contend with the same pushback and counter-arguments the infra/ops world (my neck of the woods) has already figured out and went past long ago during the advent of IaC. Cattle > pets, easily, every time.
[0] It's also not a cost-benefit thing, but clearly a principled decision, so arguments that aim to contend the ROI of it all are off-base from the get-go. If ROI is the key thing for you, then all this philosophical nonsense shouldn't even be on the table. Calculate.
“battle tested for decades” just lost a lot of its value with Mythos and the likes unfortunately. Rewriting in a different language became much faster with Coding agents at the same time.
I do agree that the second system effect is real, it’s just that the balance of benefits and drawbacks significantly shifted when it comes to “rewrite in Rust” (not limited to Rust though).
2 replies →
Indeed, many bugs are API usage bugs, something that no language can verify. (The API is implemented in C anyway.)
No, but some languages make designing difficult-to-misuse APIs a lot easier than others.
I wish they'd put the severity. There are 4 highs, the rest are medium or low. Here are the high ones:
https://www.cve.org/CVERecord?id=CVE-2026-35338 - `chmod --preserve-root` can be bypassed. That doesn't seem that bad tbh.
https://www.cve.org/CVERecord?id=CVE-2026-35341 - `mkfifo` accidentally resets the permissions of files that already exist, so if you manage to do `sudo mkfifo /etc/shadow` then it becomes world readable.
https://www.cve.org/CVERecord?id=CVE-2026-35352 - TOCTOU in `mkfifo` lets you do the symlink trick to get it to change permissions on an unrelated file.
https://www.cve.org/CVERecord?id=CVE-2026-35368 - You might be able to get chroot to execute arbitrary code.
Tbh I doubt if any of these would ever result in a real hack, unless your system is doing really mental things like running shell scripts with untrusted input.
I could only find a couple of CVEs that looked actually serious for GNU Coreutils too though. IMO if you're using these tools with untrusted input your system is janky enough that there are going to be serious flaws in it anyway. Probably though quoting mistakes.
Well the TOCTOU issues do not require you to run untrusted scripts to be exploited. Another user on your system can use a legitimate command that you may run to make changes to files they shouldn’t be able to, or further escalate privileges.
2 replies →
Not to mention sudo-rs.
I think this should be the real news.