Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Securing Go vendor packaging #20885
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
The Go compiler does not have warnings, only errors.
I don't think this is possible to implement reliably. I can make syscalls from assembly, after all.
Why would you vendor code you haven't audited, including transitive dependencies? You are ultimately responsible for the correctness and robustness of the source upon which your code depends.
The only thing vendoring tools can provide is a guarantee of authenticity for the code. (And, if you're using Git, you do get most of that guarantee "for free," recent vulnerabilities of SHA1 notwithstanding.) You can even use git to check for code that doesn't have PGP signatures on tags and/or commits, if you're particularly concerned about authenticity.
I had not considered embedded assembly although I have not seen those references in the language definition which does not mean that it does not exist. As for syscalls, I would expect those to generate warnings too.... as syscalls are i/o. (conditional build based on OS ir ARCH not withstanding)
I'm making the point that without code reviews of vendor code and the dependency tree there are any number of challenges. Just because the tree is safe today does not mean it's going to be safe tomorrow. GIT makes no promise implied or other...
The point I'm making is that while I have an implied contract with the 3rd party vendor I'm using I'm also obligated to accept the nested contract that vendor has engaged. I am further asserting that the golang compiler should warn as I indicated. AGAIN, any of those deeply nested vendors could become compromised and so would everyone above.