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: should go install/get blacklist common binary names, such as go, rm, cp? #16601
Comments
Are you proposing we hard-code a list of bad package names, or fail (since we don't do warnings) whenever the package being installed shadows something already in your path? Both seem kinda gross. Why did you install a binary named go? Were you tricked into it somehow? How? I'm trying to understand the problem more. |
I'm not sure where I stand, but I can possibly see a case for a very small hard-coded list of bad package names. go, rm, and cp all seem like good candidates. |
It seems to me that the bug is putting $GOPATH/bin on PATH before /bin:/usr/bin or for that matter $GOROOT/bin. Once you've done that you are in trouble and there is nothing reliable we can do to fix it--are we going to also block sed, awk, ls, all the programs that a Makefile might run? If we are going to do something here, the PATH is the thing to tackle, though I don't know how. I don't think we should be in the business of telling people that they can not write a "rm" program in Go. |
We have the following options (as I see it):
Personally, I am in favor of doing 1.i, 2., and 3.i. I was not tricked. It went unnoticed for months because my I've been playing with cockroachdb recently, and the problem re-appeared. See cockroachdb/cockroach#8325 for exact steps to reproduce (though I think it is clear what's going on). The problematic scenario (as I see it):
|
I don't think we should stop the user if they want to build "cp" with Go, nor do I think we should stop the user if they want to prefer that over their system cp. That's all up to the user. I'm fine with any form of warning, though. |
Go doesn't really do warnings, though. I don't think we'll do anything here. If you blindly compile & run a project from an upstream that's been hacked, all sorts of badness can happen. Shadowing something in your path is the least of your theoretical problems. Happy to reopen if I'm missing something. |
Maybe this could be addressed in go vet or golint by adding an error to them if they detect such cases. |
in my scenario I was blindly building from and upstream that's been hacked, but not running it. |
CL https://golang.org/cl/25509 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
go version
)?go version go1.7rc5 darwin/amd64
go env
)?GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
go install
a binary namedgo
.A warning.
go
binary was populated in$GOPATH/bin
.Since I have
$GOPATH/bin
at the end my$PATH
I have not noticed anything.Some make files/buildscripts add inferred
GOPATH/bin
in front of$PATH
, which leads to surprising behavior when they dogo build
later.It seems to be a security risk: my system becomes vulnerable if I do
go get
targeting a bad package (or a good package that got hacked), even if I do not run/test the code.Imagine malicious binary that intercepts regular
go
commands and injects some code.The text was updated successfully, but these errors were encountered: