lcamtuf :verified: :verified: :verified: (@lcamtuf@infosec.exchange)
infosec.exchange
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.
  • NostraDavid@programming.dev
    3·
    2 days ago

    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.

    • FizzyOrange@programming.dev
      1·
      2 days ago

      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.