On the issue of trusting crates on crates.io, how is trusting them different than trusting any set of open-source dependencies that come from anywhere? Say you didn’t have crates.io and instead were using libs downloaded from various upstream sources directly. What about if it were all in the standard lib?
I see absolutely no difference in these trust scenarios. In either case, the only way I can truly trust all the dependencies is to audit them and then vendor/lock them down into my build for that version of my build. If I upgrade any of those dependencies to a newer version, I must audit them. Every time. That is the ONLY way to have true trust in ANY scenario whether the dependencies come from standard lib, a repo like crates.io, or from 3rd party downloads directly from upstream. This even applies to commercial/close-source software with the added downside that, in most cases, I don’t even have the option to audit the source, I just simply have to trust that because I gave them money, they are doing their job properly and have my best interests at heart (which has been proven time and again to not always be the case unfortunately).
So, what I’m saying, is that way too much is being made of the whole, “I can’t trust crates.io” issue. It’s pretty much a non-issue if you really consider what “trust” in dependencies is.
That being said, things like adding signing or 2FA to crates.io are worthy of pursuing. Also, the notion of curated crates.io alternatives is not a bad idea as well. In fact, I can imagine a scenario where a company or consortium of companies create a curated alternative to crates.io that you can pay a membership to. This could possibly include certain “guarantees” around testing standards, documentation standards, auditing, chain-of-custody etc. that have had official audits etc. Perhaps adhering to things like FDA regulations or FIPS regulations, etc. My guess is this would be costly (as it should be). Seems like a business opportunity?