Rust cannot help you if race condition crosses API boundary. No matter what language you use, you have to think about system as a whole. Failure to do that results in bugs like this
It's not even about API boundaries, it's about logic and the language isn't really responsible for that.
Expecting it to prevent it would be as gullible as expecting it to prevent a toctou or any other type of non trivial vulnerability.
That's why even though I appreciate the role of these slightly safer languages I still have a bit of a knee-jerk reaction to the exagerated claims of their benefits and how much of a piece of crap C is.
Spoiler, crappy programmers write crappy code regardless of the language so maybe we should focus on teaching students to think of the code they're writing from a different perspective and focus safety and maintainability rather than "flashiness"
You wasted your generational revolution capital into creating an interesting new language with a concept of ownership, but you didn't think of applying it past the program boundary?
There's a class of developers that think that the program they are writing is the whole world. Didn't think rustaceans would be in that space. Maybe the Rust variant is that their program will go down the stack until everything is part of Rust, rather than being based on ignorance and naivety.
The bigger problem here is it seems like the rust utilities were rushed to be released without extensive testing or security analysis because simply because they are written in rust. And this isn't the first serious flaw because of that.
Doesn't surprise me coming from Canonical though.
At least that's the vibe I'm getting from [1] and definitely [2]
[1] https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys... [2] https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...