New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: maintain a global go.sum #24117

Open
FiloSottile opened this Issue Feb 25, 2018 · 6 comments

Comments

Projects
None yet
6 participants
@FiloSottile
Member

FiloSottile commented Feb 25, 2018

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.)

@gopherbot gopherbot added this to the vgo milestone Feb 25, 2018

@sdboyer

This comment has been minimized.

Member

sdboyer commented Feb 25, 2018

Strong agree - the class of information being kept in go.modverify makes more sense in some kind of central location, rather than being split up across projects.

@FiloSottile

This comment has been minimized.

Member

FiloSottile commented Feb 25, 2018

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.

@airylinus

This comment has been minimized.

airylinus commented Mar 22, 2018

I agree with that.
For instance, package golang.org/x/net actually repo locates is github.com/golang/net. This is pretty creepy when you clone a new repo and stuck at a go build error.

@rsc

This comment has been minimized.

Contributor

rsc commented Mar 30, 2018

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.

@rsc

This comment has been minimized.

Contributor

rsc commented Apr 9, 2018

Brad asked me to kill uses of NeedsFixButNotYet, so I'm going to call this NeedsDecision.

@rsc rsc modified the milestones: vgo, vgo2 Jun 6, 2018

@rsc rsc modified the milestones: vgo2, Go1.12 Jul 12, 2018

@rsc rsc changed the title from x/vgo: maintain a global go.modverify to cmd/go: maintain a global go.modverify Jul 12, 2018

@rsc rsc added the modules label Jul 12, 2018

@FiloSottile FiloSottile changed the title from cmd/go: maintain a global go.modverify to cmd/go: maintain a global go.sum Aug 16, 2018

@bcmills bcmills modified the milestones: Go1.12, Go1.13 Nov 14, 2018

@bcmills

This comment has been minimized.

Member

bcmills commented Nov 14, 2018

I have a (non-global) counterproposal in #28802. I'll follow up with @FiloSottile to try to better understand how the differences play out under various possible threat models.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment