-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: allow verifying vendored code #27348
Comments
This is still on our radar, but probably not happening for 1.13. (We have a lot to do this cycle!) I'm hoping to get to it in 1.14, but we don't have a 1.14 milestone defined yet. |
While we move to go modules, perform the dep check for repos that still use dep. Run `go mod verify` instead for go modules. Note, this just verifies the integrity of modules in the local cache. We would have instead wanted to verify the vendored code here, but that is still not supported. golang/go#27348 Fixes #1879 Signed-off-by: Archana Shinde <[email protected]>
`go mod verify` does not verify the vendored copies of dependencies: golang/go#27348 As such, it seems that this change snuck in. This commit is the result of commit the all changes produced by `make revendor` on master. Signed-off-by: Steven Danna <[email protected]>
`go mod verify` does not verify the vendored copies of dependencies: golang/go#27348 As such, it seems that this change snuck in. This commit is the result of commit the all changes produced by `make revendor` on master. Signed-off-by: Steven Danna <[email protected]>
No, it's definitely not happening for 1.15. |
Moving milestone to Backlog. |
This is indeed valuable! Projects that choose to vendor their modules usually do not want to count on every package to be available 100% of the time, therefore validation that enforces re-downloading the package is problematic. Would be happy to see this implemented. |
There seems to be a fundamental issue here, vendor directories exclude many files not used in the actual build. Verifying against go.sum partially becomes impossible. I'd like to automatically generate vendored tarballs from sources, while being able to verify them, so this issue becomes relevant to me. Is there any discussed solution that went unrecorded in this thread? Thanks in advance |
@ArsenArsen, the plan at the moment is to have Then we can demonstrate the integrity of the |
(However, note that |
@bcmills Hm, while that works and will produce valid results, the thing we're implementing requires us to be able to do so without the network. Would it be possible to create a vendor archive that contains all the code required for building and verification to run in this constrained environment? I was considering shipping a tarred up version of Thanks in advance, and for the quick response. |
In theory you could checksum each package, but the
Actually, that would work (once we implement |
A problem we recently hit is that due to some recursive patterns in .gitignore some files under |
@bcmills what if The downside is that the |
I guess a |
Since this has been open for almost 5 years, maybe recommend a mitigation? Kubernetes performs this check with https://github.com/kubernetes/kubernetes/blob/master/hack/verify-vendor.sh. I'm looking to do the same for github.com/google/cel-go, and having a recipe would be a huge time saver. |
@jpbetz, you can run the following:
|
Thanks @bcmills In cel-go we ended up using this script: https://github.com/google/cel-go/blob/master/scripts/verify-vendor.sh |
This is a security concern. An attacker lying about the contents of |
go mod verify
is extremely useful for validating the integrity of modules in the local cache.It would be great if projects that choose to vendor their modules (then presumably building with
go build -mod vendor ...
) had a similar command to verify the integrity of modules in that directory.This would satisfy a major requirement that many projects need to account for in their CI process-- ensuring that vendored code hasn't been tampered with.
The text was updated successfully, but these errors were encountered: