GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1]

The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate."

I feel crates.io was unprepared for a security incident like this since they're managing the response [4]

[1]: https://web.archive.org/web/20260820145918/https://github.co...

[2]: https://crates.io/crates/arrayref/versions

[3]: https://crates.io/crates/arrayref/security (I'd give an Wayback link but that's also broken https://web.archive.org/web/20260820150747/https://crates.io...)

[4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomm...

▲

deathanatos an hour ago | parent | next [-]

> The bad package version has also just disappeared from crates.io with no indication its been yanked.

So, yanked crate versions do have an indication on crates.io. (Here's an example: [1]) The Rust blog post uses the word "deleted", and I'm guessing a bit here, but I think they mean that literally, and that the version here is deleted, not yanked. And I think that would be more appropriate: a yanked crate is still downloadable by cargo, if your lockfile is locked to it already; yanking only prevents lockfiles from newly automatically acquiring a lock on that version. That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all. The tradeoff of "break those with locks on the crate" tips to being worth it.

That said, I agree with you, though: I think this state (if it is "deleted" and not yanked) should be plainly indicated on the crate's versions page. (Even better would be if it came with a link to, e.g., the blog post or a RUSTSEC so that you could find out why.) (& I think perhaps the docs for yank should point out whether or not it is appropriate in the "compromised crate" scenario, and if not, what to do instead.)

[1]: https://crates.io/crates/aes/versions

▲

landr0id an hour ago | parent | prev | next [-]

[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 13 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 ?

▲

qwertox an hour ago | parent | prev [-]

> GitHub really needs something finer-grain then just pretending the repo never existed during these incidents.

Google should read this too. They simply remove Android apps and Chrome extensions without a single word. No page explaining why they removed it, if i was at risk.