Skip to content
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

x/vgo: verify go.mod files somehow #25526

FiloSottile opened this issue May 23, 2018 · 2 comments

x/vgo: verify go.mod files somehow #25526

FiloSottile opened this issue May 23, 2018 · 2 comments


Copy link

@FiloSottile FiloSottile commented May 23, 2018

When using a proxy, it's useful for vgo to be able to fetch go.mod files without fetching the whole module. The go.mod file is needed for dependency resolution also when the specific package being built does not depend on the module. However, go.mod files are not verified by go.modverify, and we want proxies to be untrusted.

Following untrusted go.mod can turn out to be a bad idea in a number of ways. An attacker might for example downgrade the user to a known vulnerable version, or to an old version including an attacker controlled transitive dependency. In general, allowing an attacker to change behavior is recipe for disaster.

This is a proposal for a hashing scheme that will allow the efficient verification of go.mod files without extending the go.modverify entries, by building a poor man Merkle tree.

A Hash2 is defined as:

"h2:" || base64(sha256(sha256(go.mod) || "  go.mod\n" || Hash1 || "\n"))

And a new field ModVerifier is added to the .info JSON file, consisting of the module Hash1.

This way a client can verify a go.mod file with only the Hash1 from the .info file (effectively a Merkle tree inclusion proof) and the Hash2 from modverify, which did not get any bigger.

If a hash with version 1 is encountered in modverify, the whole package is fetched, and the hash is replaced with a version 2 hash. If the .info does not contain a ModVerifier, the whole package is fetched. Note that proxies can add ModVerifier on their own.

Alternatively, we can implement a full Merkle tree, which would allow us to verifiably fetch any file or directory from within a larger module, but I don't see this becoming necessary soon.

It is a bit unclear to me how much damage a proxy can do by faking .info responses, because those are going to be much harder to secure, but at least only affect the stage of adding dependencies, and not the reproducible build stage.

@gopherbot gopherbot added this to the vgo milestone May 23, 2018
@rsc rsc changed the title x/vgo: efficiently verify proxied go.mod files x/vgo: verify go.mod files somehow Jun 6, 2018

This comment has been minimized.

Copy link

@rsc rsc commented Jun 6, 2018

We need to do this somehow. The specific proposal doesn't work for me but we'll find a way.


This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jun 28, 2018

Change mentions this issue: cmd/go/internal/modfetch: check go.mod content using go.sum

@golang golang locked and limited conversation to collaborators Jun 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.