jchw
3 hours ago
People keep replying seeming to miss what makes Go's solution so good. I think it deserves more attention.
In many cases I think it's impossible to avoid the pain that comes with decentralization without defeating the point. It's challenging because certain things are hard to do decentralized so it's easier to just give up and rely on central authorities and components.
When you install Go, it does just that, to some approximation; it will try to fetch from the module proxy first and fall back after that fails. But what makes Go different and more interesting is that you can just turn that off with no consequence. As long as all of the Git hosts are up, you can still use Go just fine with no proxy. I'm pretty sure Nix builds do this by default with Go so I believe most dependencies are usually online. That means the proxy approach and the decentralized approach are both fully redundant with eachother, while allowing the decentralized VCS hosts to remain the source of truth.
Go also separately has the sumdb to enforce immutability, so you can know that when you go grab a specific package that the tag name corresponds to one and only one exact source code. This is also optional, and even without it you get the benefit of local sum checking via your own cache and go.sum files in source checkouts. But having this be separate is great because it also means you could use another third party module proxy or a third party sumdb, or use just the sumdb and no proxy. It gives you many options to not have to rely on a single party while still getting some of the benefits of centralization.
Systems like this are rare. Many systems try very hard to have the cake and eat it too, but it usually fails somewhere. For me Go's approach works, and that is worth some attention.
throwaway27448
an hour ago
All package managers I've used allow specifying where the package is pulled from. What am I missing? What ecosystems are you comparing go to?
jchw
24 minutes ago
Sure, you can tell your other package managers to pull a module from VCS, usually with some limitations and negative side effects. The Go module syste is not the same model. You can, for example, run an NPM proxy that caches locally, but what you're missing is that with Go, the proxy part is the centralized part. There is no NPM. There is no crates.io, no PyPI, no RubyGems, no Packigist, no PECL, no CPAN. The proxy's entire job is just to stand in for requests that would be made to individual VCSes using their original source repositories. The sumdb's entire job is to ensure that whether proxied or not, the source code you get isn't tampered with. The source of truth remains decentralized, in the individual VCSes.
With NPM, uv, composer, Cargo, etc. you can indeed choose to make your dependencies pull from VCS, but:
- Not having universal module proxies with caching means you will run into the usual problems. Repos can disappear, history can be rewritten, hosts can go down. Even if you invented an equivalent caching service, without making it an ecosystem default it won't achieve the same effectiveness as Go because less would be in the cache.
- Because it isn't an ecosystem standard, dependencies you pull would then still reference dependencies from centralized repos anyways, more or less defeating the point. You'd have to go and override every recursive dependency to really make it decentralized.
(And again, it usually comes with other downsides depending on the specific ecosystem. Performance is a big one, the module cache definitely helps make fetching dependencies in Go faster.)
Not having centralized package repos comes with its ups and downs, but the lack of one existing means there are a limited number of interesting attacks you can really pull in the Go ecosystem and they are heavily tamper-evident. You can try to poison the module cache with a given revision for a dependency with malicious code then overwrite it with an inoccuous commit, but this will probably be detected when someone (possibly in Nixpkgs or another packaging system) runs GOPROXY=direct and the sumdb doesn't line up. So the least noticeable thing you can really do is just leave your malicious code in the repo. Go also has the kind of nice property that fetching and building modules is supposed to be safe with untrusted code. That's pretty good, it would be hard to do better than that.
It also means there really isn't any central namespace to poison. You can still trick someone into downloading and using malicious software but you're mostly limited to doing it the old fashioned way. Again, hard to do much better than that.
While everyone has been losing their minds over supply chain issues, the Go ecosystem has been concerned but less so. It's still a huge risk still, dependencies can get compromised still, but attackers have no real central target to go after and get a bunch of damage at once. Nothing realistical, anyway. So, it's back to just trying to pwn individual GitHub repos.
zer00eyz
an hour ago
> When you install Go, it does just that, to some approximation; it will try to fetch from the module proxy first and fall back after that fails.
Go is telling you that your VCS has a deficiency, without saying it out loud.
That proxy should be your own repo... but git sub modules, sub trees, sub directories are non starters for 99 percent of cases...
Git is an amazing tool, and if you want to manage your development like the linux kernel its dam near perfect. Most orgs dont work that way, and the tools and machinations that we have built around these shortcomings are rather burdensome.
I long for google to productize piper for the rest of us.