Hacker News Reader

Comment by cube00 | Hacker News Reader

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

View on HN

> 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

> That wouldn't be desirable in the case of a compromised crate: you don't want a download occurring at all.

Sure you do; you just don’t want the crate to be made available to people trying to make use of the crate as regular downstream consumers. You still want the crate available for download for analysis. You especially want to be able to deterministically reproduce the vulnerable version of your software that you already built.

I would posit that most package ecosystems should treat “contains an exploit” as its own package state; mostly ignore them; but still be aware of their existence.

In other words, if there’s any other non-exploited option under your version constraints, the dep should resolve to the nearest non-exploited version, even if older. But if it’s the only version, or if you have pinned the exploited version, then the packager should see it, but normally refuse to interact with it—i.e. refuse to lock to it if it’s the only version; or refuse to fetch it if it’s the locked version.

I say “normally” because you should be able to bypass this with a flag / env-var to the packager that basically means “I’m building this for forensic analysis, not for running.”

I agree but think the problem is slightly more general. Consider that a package could be redacted not just due to exploit but also (among other things) for legal reasons, and that such reasons could be region specific. So a redacted package might or might not be available to manually download and some other metadata is desirable so that "audit" can notify you that you were compromised.

A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence!

I would suggest that such packages should simply require authenticated access + manual “write an email to ask to have your account be put on a whitelist”-driven authorization. Such a package would still be there (in its redacted state); but attempts to download it would be a 401 (if unauthenticated) or 403 (if not on the whitelist) error response, which the packaging tooling would need to know how to handle.

(In any case, this “redacted” package state and my “exploited” package state could be two variants of the same logic, both following the same approach to locking/resolution, both requiring the flag to indicate that you understand what you’re doing and aren’t just going to run the resulting program. The only difference is that once you pass that flag, an “exploited” package would then just work, for anyone; while a “redacted” package would still have one more gate standing (server-side AAA) in the way.

I think maybe you're missing the significance of legally mandated redaction - continuing to provide access could well constitute a criminal offense depending on the specifics. And there may be many other reasons for redaction - as a sibling comment notes you certainly don't want to continue serving a package that contains sensitive private information.

I see the "exploit" case as a strict subset of redaction in which you do want to continue serving downloads to parties that explicitly acknowledge that they understand the classification of the artifact in question.

(Amusingly this exchange has led me to realize that as things currently stand a piece of malware can trivially be made illegal to distribute and thus extremely difficult to develop countermeasures for provided that the malware authors are willing to violate an additional law or three.)

> A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence!

This doesn't make sense if the legal reason is accidental release of secrets or PI, in which case you absolutely do not want to leave it up.

I'm not talking about things like github tokens here, those can be revoked. But actual secrets or PI where that isn't possible.

I mean, unless the party you’re concerned about having your secret is the maintainers of the package store itself, what’s the functional difference between “it’s deleted from our servers” and “it’s marked private so only the author [or admins of the author’s org, insofar as user accounts are org-bound] can still download it”?

If I inadvertently committed (arbitrary example) my tax returns to a repo I'd hope that the operators of the package repository would promptly destroy all copies in their possession.

I think "deleted" is still always going to have to be a package state, realistically. A package could contain spam, abuse, copyright infringement and/or illegal content.

I don't mind malware being lumped in to that - the place to look up code for historical or analysis reasons ought to be version control, not crates.io

What about the place to look up packaged binary releases for historical or analysis reasons, esp. when the packaging system either builds such releases itself, or where it allows the submission of arbitrary build artifacts (where the build process that produced said artifact can be compromised in ways that have nothing to do with the source repo)?

> the place to look up code for historical or analysis reasons ought to be version control, not crates.io

The build infrastructure should make security incidents easier to respond to, not harder. I shouldn't be sent on a wild goose chase at a time when I'm potentially already dealing with a major incident. The tools need to "just work".

Sure, I'm using "deleted" here to mean a third state more unvisible than "yanked"; I'm not trying to specify exact semantics about said third state, simply that it (a.) isn't yanked, and (b.) yanked's semantics are probably undesirable here and a third state has merit.

Yes, I agree with you that analysis is good.

I mean, we have the crates available for analysis. We take snapshots before deleting them.

We would probably be open to sharing files with those who ask. Probably, I don't know what other team members would think about that. This roughly matches the workflow you propose below where people can ask for access to these things, just a bit more manual.

Any way of keeping it around on the server in a way that is fetchable by cargo is a complete non-starter. Bright red lines are useful in security: _the file is gone_ is way easier to keep secure than "the file is still there in a way that might be fetched if you have the right flags set" now means that that flags mechanism is now security sensitive.

If you'd like us to have a nice page that shows deleted-for-security crates, that's probably a proposal we'd welcome, but it is not really something anyone has time to work on themselves. Right now we just remove them from the db after taking a backup.

[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

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

If anyone wants to create a revision to RFC 9110 :)

  HTTP/1.1 309 Security Advisory
  Location: https://acme/aaargh-another-advisory

410 Gone seems sufficient to differentiate from "this never existed".

But I want to specifically signal a security concern to the requesting party. For example, a artifact proxy (like Artifactory or CodeArtifact) can use this response to warn developers.

Structured data in body or HTTP header is plenty for that, no need for a HTTP status.

For example, if we were talking about a human-readable /crates/* page, returning 410 Gone with a HTML page explaining the situation to a human, that page could have a JSON-LD snippet explaining the same to a computer.

A dedicated status code + Location header allows to decouple the way an advisory is presented completely. At that location, there can be any representation, HTML or structured data like JSON-LD. The RFC extension would be small and clean.

I have generated a report based on my own exposure to this attack today. The report was updated as the attack unfolded; https://acje.github.io/systems/arrayref_incident_record/

Slop

It is ok that you feel this way. As explicitly stated the report is _generated_ and id does require a different mindset to read AI generated reports. It contains quite a bit of information about attacker behavior and details of the timeline. It also linkes to a story that is now largely human narrated and I´ll keep improving on that as I find time. Having to juggle three separate issues yesterday did not leave much time for manual writeups.

I don't want to read AI articles, but this isn't an article, this is one step up from a log file.

The response was managed by the security-response team working with the infra team and the Rust Foundation's Security engineer. Tobias from the crates.io team was also involved but on vacation so it was not as active. This is normal.

What makes you say we were unprepared? We have been deleting malicious crates for a while. This is the first time those crates have wormed their way into an actual real crate that people use, but most of the playbook here was the usual one. We take a snapshot copy of the crate and then purge it from the system.

The security page thing is because the rustsec maintainers were not around or a part of the response as it was occurring. It's pretty normal for a security advisory on rustsec to take some time to merge. We should probably get everyone on the same page about when people not on the rustsec team can merge security advisories, because I do agree that getting them merged quickly is important sometimes.

The crates.io page and version history should have an entry, like red with an ! and a cross through with an advisory note explaining the security issue, accessible via the api as well so it is clear what happened.

The main crate entry should also contain a security advisory at top. I looked at the crate and it just looked normal; I had to dig to find the exact impact surface, and if I wasn't informed via secondary means (hackernews) I would not have known. This is unacceptable for a mature package management system.

Luckily I was unaffected in this case.

cargo-audit is the automated mechanism you are looking for

The crate does have an advisories/"security" page on crates.io.

We could try and show the existence of a security-deleted crate on the page. This is not a priority for anyone, and I remain unconvinced that it needs to be (not that that is my decision anyway). File an issue and make your case to the crates.io team.

Reply on news.ycombinator.com