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...

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"

That's optimistic. Use a search engine to find:

   JWZ CADT

Not this particular kind. This is a race between separate processes, and the target is the file system, not a location in memory.

No. Race conditions are a normal part of our world, in the same way it's not a memory error if you coded the discount feature so that people can apply more than one 10% off coupon to an order and as a result the nine different "10% off" offers that marketing seeded have summed to a 90% discount which bankrupts you.

An example race condition would be Mike and Sarah both wake up, notice there's no milk and decide to grab milk on the way home that evening, they both work a full day, drop past the store and arrive home with a carton of milk. But, now there are two cartons of milk, which is too much milk. Oops. This is called a "Time of Check versus Time of Use" race or ToCToU race.

(Safe) Rust does prevent Data Races which can be seen as a specific very weird type of Race Condition, unlike other race conditions a Data Race reflects a difference between how humans understand computers in order to write computer software and how the machine actually works.

Humans are used to experiencing a world in which things happen in order. We write software for that intuitive world, this is called "Sequential consistency". A happens before B, or B happens before A, one of these must be true. Mustn't it? But actually a modern multi-core CPU cannot afford sequential consistency, we give that up for more speed, so any appearance of sequential consistency in concurrent software is an illusion for our comfort. (Safe) Rust promises the illusion is maintained, if you try to shatter it the compiler is going to say "No", languages like C or C++ just say well, if you accidentally destroy the illusion your program might do absolutely anything at all, good luck with that.

It can be about any resource. You get it when two concurrent functions access the resource without a queue, atomic operation or wait, and one of them modifies it.