-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: cmd/compile: option for building hardened/obfuscated binary #3467
Comments
The "fake paths" one would be nice. Reading traces that contain filenames like /var/lib/jenkins/jobs/go/workspace/go/src/pkg/foo/bar.go is quite hard. In this particular case you could setup a custom workspace to build under /go, but as soon as you have people producing builds of other stuff in their home directories, you have the same problem. |
I tried to create a temp build dir in /tmp/build with /tmp/build/src symlinked to $GOPATH/src, but the full filenames were still included (I guess it did an path.Clean or equivalent). The solution I'm currently adopting is to just deep copy into the /tmp/build before compiling my production binary, but that is quite unsatisfactory. |
A workaround for fake path, move your pkgs under $GOROOT/src/pkg/, and set GOROOT_FINAL=/go/root then rerun all.bash and then rebuild your application. (Remember always point $GOROOT to correct place) Note that cmd/go by default normalize (path/filepath.EvalSymlinks) your path, so symlinks won't work. The other two points are also easy to achieve, but you need to patch runtime. |
I've retitled this as a cmd/compile proposal for what it is, for easy groking and perhaps for interested parties such as enterprise folks. |
Thanks for retitling and labeling, @odeke-em. We spend most of our time making programs more debuggable, not less. Doing this would require adding complexity to the runtime, compiler, linker, all things that are too complex already, and then carrying around those diffs, for no real benefit. Sorry, but no. Note that whatever flag we add to go build for #16860 will probably make file paths start with just the import path (strings/x.go instead of /home/you/go/src/strings/x.go), so at least the prefix leaking concern will be addressed. |
by awreece:
The text was updated successfully, but these errors were encountered: