4 ms·

GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1] The bad package version has also just disappe

• qwertox 2mo ago
  > 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.
• landr0id 2mo ago
  [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-crate-update/ 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 2mo ago
    > 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-arrayref/#what-you-need-to-do https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... [2]: https://rust-lang.zulipchat.com/#narrow/channel/318791-t-crates-io/topic/arrayref.20hacked/near/617626315 https://rust-lang.zulipchat.com/#narrow/channel/318791-t-cra...
    • thayne 2mo ago
      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 2mo ago
        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 ?
        • thayne 2mo ago
          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?
          • cube00 2mo ago
            > 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 https://crates.io/crates/arrayref/versions
    • eminence32 2mo ago
      > 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
• deathanatos 2mo ago
  > 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 https://crates.io/crates/aes/versions
  • derefr 2mo ago
    > 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.”
    • 2mo ago
• einrealist 2mo ago
  If anyone wants to create a revision to RFC 9110 :) HTTP/1.1 309 Security Advisory Location: https://acme/aaargh-another-advisory
  • yencabulator 2mo ago
    410 Gone seems sufficient to differentiate from "this never existed".
    • einrealist 2mo ago
      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.
      • yencabulator 2mo ago
        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.
        • einrealist 1mo ago
          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.
• acje 2mo ago
  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/ https://acje.github.io/systems/arrayref_incident_record/
  • hbcdbff 2mo ago
    Slop
    • acje 2mo ago
      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.
    • benj111 2mo ago
      I don't want to read AI articles, but this isn't an article, this is one step up from a log file.
• Manishearth 2mo ago
  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.
  • survirtual 2mo ago
    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.
    • Manishearth 2mo ago
      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.