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.

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.

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.

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

Marking this obsoleted by Go modules.

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