[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.
> 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...
> 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
I believe what's being suggested is that `cargo audit` should be a part of cargo rather than an add on.
You'd obviously already have cargo installed, which means you should be able to run a command against cargo to see if you are currently exposed to any security problems. Even if it's not the current "audit" add on.
Well, but as a system admin, I might not have cargo installed even if my users have it installed in their home directory. So a simple non-Cargo command (like find) has a lot of advantages for me
As someone using bazel at work, the find script was much more amenable to me trying to audit our usage - we don't use cargo, so no cargo cache or cargo audit, but I can still figure out whether a particular package was downloaded.
If you're using a different tool then it falls to that tool to address the same problem. The point is that I shouldn't have to already know that a compromise has occurred and then go looking for it manually. The tooling should automatically start shouting at me very loudly that something happened with one of the packages I'm using.
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.
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 ?
Crates.io currently says:
> A new version of the arrayref crate was published with a direct dependency on proc-macro1, which would execute a malicious build script.
> This compromised version was published on 2026-08-20 and removed approximately 86 minutes later, with no evidence of actual usage.
I don't know what more you want. Do you want the malicious version to continue to be available?
> I don't know what more you want.
The version page [1] should show that for 86 minutes there was a version 0.3.10, it was malicious and was deleted with a link to the advisory. I get this takes time so even a generic "deleted" entry until they have time to link in the advisory would also be fine so we know something is happening.
Presumably even "deleted" crate versions still have some metadata left behind in the backend so this should be surfaced.
[1]: https://crates.io/crates/arrayref/versions