x/vgo: unknown whether modules match the original commit #23992
Labels
Milestone
Comments
|
This is pretty much the only issue I've seen raised internally where I work when we've been discussing this new tooling. Git tags are mutable, and that's a huge problem for something like this, it's a huge problem that lock files help to mitigate easily for a lot of use-cases. |
|
The latest vgo article is on this topic: https://research.swtch.com/vgo-repro. tl;dr: Seems like creating an empty "go.modverify" in your repository will have vgo catch any instance where source changes underneath a given version. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
go version go1.10 linux/amd64 vgo:2018-02-20.1
vgo does not have enough info in go.mod to ensure the retrieved modules are the same that used when originally committed. There are several reasons why fetching modules for a particular tag might return something different (an updated tag, interference, bugs,..).
Ideally vgo should be able to confidently build the same modules in use when originally committed, or make it obvious if it has changed.
Some companies may partially mitigate this by providing their own source retrieval infrastructure to assist with reproducible builds, but this won't be an option for most Go users, and vgo would still need to trust the infrastructure and assume the build was correct. It also doesn't solve the problem with the initial fetch.
Perhaps a hash could be added for each module specified in go.mod, similar to existing vendoring tools? Eg:
require "github.com/foo/bar" v1.2.3 sha256:2dc84245...b18cca39The text was updated successfully, but these errors were encountered: