Continuing from here: The Zig subreddit has closed - #53 by gonzo
One big issue I worry about when it comes to a distributed package index model is security and more specifically, authentication of packages. In a totally de-centralized package management model, how can you be sure that the package you’re downloading is the real one and not a maliciously altered one?
First, I have not thought this through – it is totally possible that there are insurmountable obstacles for this sort of idea. I did call it “a crazy thought”… 
I think you would have to look at ideas such as how GPG ensures identity and credibility of people / resources. If enough credible people bless a given package as being what it purports to be, then you could trust it? Combine that with a clear signature that guarantees that the package has not been tampered with, and that should be enough, I think.
I have pretty much no knowledge of the technical details of GPG or other signing / checksum / authenticating / anti-tampering solutions, but it seems to me that they always depend on a centralized source of absolute truth. If not, I could tamper a package, resign it or re-checksum or whatever and how would the end user know that’s not the original signature / checksum? The package management tool would have to have a way to verify somewhere. This could be with other peers maybe? Let’s face it, when it comes to the user (myself included) , they would rarely if ever do this verification themselves.
Most of the time, you are downloading a specific, locked down version of a package. In that case, you compare its content hash with a checksum which you store with your own repository and bail if there’s a mismatch.
The hard case is when you update to a new version of a package, where you also update a checksum. How do you know that the new package is good?
I don’t think there’s a provably successful solution here, and it doesn’t seem that centralized registries help here much. If someone can tamper with code I put on GitHub, they are highly likely to be able to tamper with the code I put on crates.io (Rust centralized registry).
Two solutions which sprang here in the Rust space are cargo-crev, which creates a web-of-trust which essentially allows third parties to commit to statements like “I reviewed version X.Y.Z of library W, and it seems legit”. and cargo-vet which takes more project-centric view and allows developers of a single large project to share audit results.
For me personally, I don’t use any mitigation for this problem beyond minimizing the number of dependencies I use, and applying extra scrutiny on the margin for the projects with maintainers not yet familiar to me.
One relevant point wrt version changes is that Zig plans to do MVS so you’re always going to get a version of the package that somebody else has already tried. Not a complete solution to the problem, but IMO a real-world mitigation.
What is MVS? I tried searching but get a wild variety of results.
Minimal Version Selection, see research!rsc: Minimal Version Selection (Go & Versioning, Part 4)