[3] is no longer true. They're definitely not unprepared for an incident like this. It's not the first time they've done it and they published an update to their process in Feb:

https://blog.rust-lang.org/2026/02/13/crates.io-malicious-cr...

Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill.

▲

cube00 an hour ago | parent [-]

> They're definitely not unprepared for an incident like this.

We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.

`cargo audit` should be reporting if these packages have been downloaded. The "What you need to do" section of the blog should be run `cargo audit`

> Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill.

The GitHub issue was opened 8 hours ago. The cargo.io team also acknowledged it 8 hours ago. [2]

> [3] is no longer true.

Previously published versions shouldn't just disappear from the list. There's still nothing there to indicate a version was yanked.

[1]: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...

[2]: https://rust-lang.zulipchat.com/#narrow/channel/318791-t-cra...

▲

eminence32 10 minutes ago | parent | next [-]

> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.

I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache?

I personally appreciated having the `find` command:

* It very clearly indicates where to look (my cargo registry cache)

* It very clearly indicates what files to look for (a list of wildcards)

* It's something that I can easily review and then copy/paste into my terminal

* I can very easily adapt it to my particular environment (perhaps into a `fd` invocation if I'm on Windows, or perhaps adapt it to scan all home directories on my system), or feed these file names into some other vulnerability scanner

▲

thayne an hour ago | parent | prev [-]

It wasn't yanked, it was fully removed.

They did that because a yanked package can still be used. And in this case there weren't any downloads, so it is unlikely the malicious package was actually used.

	▲	maximegarcia 14 minutes ago \| parent [-]
		Call it how you want, the point is that it should not disappear like this. Maybe yanked has the meaning you said, but in Ruby yanked has the meaning OP said and that is what we want. How to call it then : Yanked hard vs yanked soft ?