proposal: Securing Go vendor packaging

[rbucker]

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]

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]

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]

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]

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

[rsc]

Marking this obsoleted by Go modules.

[rsc]

This proposal has been declined as obsolete.
— rsc for the proposal review group