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.
Canonical should have a look at https://antithesis.com/ - They’ll basically run your application in a deterministic VM, where hardware errors are simulated, so you can re-play certain scenarios, not just the happy-path. It should be able to surface bugs way faster than just running into them.
Deterministic simulation testing is what they should be doing.
Tbh while DST (or just “testing” as hardware people would call it) is very obviously a great idea, I’m not sure it would have helped here - in order to detect these TOCTOU bugs you would need stimulus that triggers it and some kind of checker/model that has the correct behaviour.
That’s totally possible but it’s pretty hardcore testing for a software project and it’s difficult to imagine doing that without realising that you have a TOCTOU issue just by inspection.
Canonical should have a look at https://antithesis.com/ - They’ll basically run your application in a deterministic VM, where hardware errors are simulated, so you can re-play certain scenarios, not just the happy-path. It should be able to surface bugs way faster than just running into them.
Deterministic simulation testing is what they should be doing.
edit: If you want a demo from the CEO, where he shows off how he tested Super Mario (yes, the NES game): https://www.youtube.com/watch?v=zc4cqtibTzs
Note: These are some guys from FoundationDB, if that means something to you.
Tbh while DST (or just “testing” as hardware people would call it) is very obviously a great idea, I’m not sure it would have helped here - in order to detect these TOCTOU bugs you would need stimulus that triggers it and some kind of checker/model that has the correct behaviour.
That’s totally possible but it’s pretty hardcore testing for a software project and it’s difficult to imagine doing that without realising that you have a TOCTOU issue just by inspection.