Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: maintain a global go.sum #24117
vgo keeps a global cache. In the same way it should keep a global go.modverify file, reminiscent of ssh's known_hosts.
This reduces the TOFU window of attack to just the first time a developer machine fetches a repository, which combined with the repository's go.modverify provides a strong trust waterfall.
When developers maintain multiple projects it will also make the risk of detection propagate to multiple communities, making targeted attacks even more different.
Finally, it could eventually be compared against and merged with any new go.modverify encountered, making verification automatic and making trust also flow from users back to the developer.
Aside from security, it will also provide more pressure against changing tag values, because it will be harder to remove a pin.
While the cache might need size management and/or expiration features, the global go.modverify should not reach meaningful size issues, preventing eviction attack and providing permanent pinning. (And maybe the base for future gossiping features.)
To clarify, I think it's important for it to be both in the repository (#24116) and in a global location, possibly with cross-pollination.
The go.modverify in the repository is critical to ensure users have only a single well-understood point of security failure: fetching the source.
Not yet. We're fixing one thing at a time. The first thing to fix is management of versions at all. The second thing is verification. There's no need to do both at once. We've gotten by this long with "go get" with no modverify. Let's get versions into go first, and then turn our attention to verifying.