> Given that you were responding to a critique of what seems to be fully conjecture with the argument that we don't know
for sure that it's not feasible,
But wait, that isn't what's on the table. Inserting malware into a build script itself is absolutely feasible; you can demonstrate that part locally. Gaining sufficient access to a developer or CI machine that has credentials to publish such malware to package repositories is also, well, feasible. If you are using GitHub Actions, all it would take is literally any action you run in any CI script in a job leading up to publishing getting pwned, a task that is easy if you can compromise any one of them due to the lack of a real way to pin actions, and because of vectors like the ever-enduring pwn request.
The unknown quantity is how easy it is. That part is hard to say, and also inherently relative. For me pulling off such an attack would probably be hard. For the folks behind the XZ backdoor? Well, I do not wield a crystal ball, but it sure seems like what they accomplished for that was significantly more than what would've been needed to pwn the Rust ecosystem. They didn't even need temporary access to publish a crate, they flat-out took over an upstream the old fashioned way; found a weak link and worked their way up the chain with social engineering and good old hard work.
What exactly makes you think the feasibility of pwning a crate is somehow up for debate?
> it's not clear to me why that wouldn't be a sufficient defense of any claim of a potential vulnerability without regard for merit.
You have inverted my logic. What I said was that the absence of an attack is not evidence of difficulty (or infeasibility).
> You don't propose any alternative than ignoring the only hard evidence we have,
What you have isn't "hard evidence" at all. It's not evidence in the first place. It is the literal lack of evidence.
This shouldn't be comforting. I suggest it shouldn't be comforting, because there is a period of time from whence a package repository goes online to its first major supply chain attack attempt, and you never really know when it will be. Crates.io is currently vastly smaller and lower traffic than NPM for example, so if you are looking for a vast number of potentially easy targets it is the wrong place to look. That may not always be true and to some attacker it may not matter as much. It isn't just inherently safe.
> so although you might not have intended it this way, it's not clear to me what discussion you could expect to happen with that standard of evidence other than throwing up our hands and saying everything is screwed.
The main takeaway is that hope is not a strategy. Will crates.io get pwned like NPM does periodically now? Probably. Can we do anything about this? Sure, lots of things, although I'm not sure people will love them.
- You could abandon a unified namespace/central repository and mimic Go's approach. Doesn't prevent compromise, but it helps avoid issues like typosquatting.
- You could require secure attestation of the build process. Don't mistake this suggestion as me vouching for it, but Bazel has implemented this for BCR.
- You could... Have moderated, curated repositories, possibly with graduated release channels like Linux distros do. Again... Could, not should, but it absolutely helps enable more scrutiny and time for things to bake. It's feasible.
- You could enforce reproducible builds with provenance information. This would stop someone from publishing releases that don't match the actual source repo, a technique often used in these supply chain compromises.
As for what Crates.io should do, I don't know. All I know is it would be a huge mistake to just do nothing and assume it won't get pwned due to the absence of attacks. Security will never be perfect. Best we can do is acknowledge this and continue to iterate.