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

proposal: Securing Go vendor packaging #20885

Open
rbucker opened this issue Jul 2, 2017 · 4 comments

Comments

@rbucker
Copy link

commented Jul 2, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.7.x and 1.8.x

What operating system and processor architecture are you using (go env)?

Linux / Alpine / CoreOS / RancherOS / Ubuntu and CentOS

What did you do?

system architect

What is the problem?

While there are vendoring tools and strategies out there they fail to secure enterprise. Another related issue is init() in vendor packages

Examples

most vendoring tools copy the vendor packages and their dep tree to the project folder. Making you responsible for maintaining them as part of the actual project instead of a fork.

forking projects to not include forking of the dep tree. So if your favorite package also includes a 3rd party lib [a] the namespace is corrupt [b] the forked package is broken.

And as evidenced by the NodeJS project that was part of the dependency tree of 80-90% of all node projects where the developer removed his code in protest.

Once your favorite package imports from another vendor and that code is corrupted with an init() function that launches a thread that deletes your HDD or encrypts it. It's a perfect trojan.

Possible fix

First of all I would like to see a compiler error/warning generated when a package imports from anyplace other than the core golang packages. And an accompanying pragma as to whether this is a warning or a compiler error. But it should NEVER be silenced.

First of all I would like to see an error/warning if a vendor package implements an init(). And we should see even more errors/warnings if the vendor package does any sort of i/o without some sort of pragma in the import statement.

@philhofer

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2017

First of all I would like to see a compiler error/warning generated when a package imports from anyplace other than the core golang packages. And an accompanying pragma as to whether this is a warning or a compiler error. But it should NEVER be silenced.

The Go compiler does not have warnings, only errors.

And we should see even more errors/warnings if the vendor package does any sort of i/o without some sort of pragma in the import statement.

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.

@rbucker

This comment has been minimized.

Copy link
Author

commented Jul 2, 2017

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

I'll give you another example... I have been testing a javascript sip client. It's loaded in my browser from a local apache server. In order to get the client to connect I need to provide credentials. The library is a professional/commercial product and makes no claim or configuration option for a TUN or STUN proxy, yet they took my credentials and sent them to their proxy service. Since this was a commercial product they obfuscated the code so a code review was not possible.

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.

@bradfitz bradfitz changed the title Securing Go vendor packaging proposal: Securing Go vendor packaging Jul 2, 2017

@gopherbot gopherbot added this to the Proposal milestone Jul 2, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 2, 2017

On hold until package management work progresses.

But any validation checks or restrictions like this will probably be part of a vendoring tool and not a Go change, though.

@rbucker

This comment has been minimized.

Copy link
Author

commented Jul 2, 2017

@bradfitz that's reasonable and works for me. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.