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

Closed
gopherbot opened this Issue Apr 4, 2012 · 10 comments

Comments

Projects
None yet
6 participants
@gopherbot

gopherbot commented Apr 4, 2012

by awreece:

This is a feature request for an additional flag for compilation to create a sanitized
or hardened binary. 

This binary could include a number of features, espescially including:
- fake paths (ala /go/root/<pkgname> instead of the real filename) 
- doesn't have stack tracing on panic
- doesn't print faulting instruction, address on segfault

The existing pack tool allows you to strip prefixes from paths, but there's no option to
pass that through the go build tool chain. Furthermore, this doesn't disable printing
stack traces, etc.
@alberts

This comment has been minimized.

Show comment
Hide comment
@alberts

alberts Apr 4, 2012

Contributor

Comment 1:

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

alberts commented Apr 4, 2012

Comment 1:

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

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Apr 4, 2012

Comment 2 by awreece:

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.

gopherbot commented Apr 4, 2012

Comment 2 by awreece:

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

This comment has been minimized.

Show comment
Hide comment
@dsymonds

dsymonds Apr 4, 2012

Member

Comment 3:

Labels changed: added priority-later, removed priority-triage.

Member

dsymonds commented Apr 4, 2012

Comment 3:

Labels changed: added priority-later, removed priority-triage.

@minux

This comment has been minimized.

Show comment
Hide comment
@minux

minux Apr 4, 2012

Member

Comment 4:

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

minux commented Apr 4, 2012

Comment 4:

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

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Sep 12, 2012

Contributor

Comment 5:

Status changed to Accepted.

Contributor

rsc commented Sep 12, 2012

Comment 5:

Status changed to Accepted.

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Nov 27, 2013

Contributor

Comment 6:

Labels changed: added go1.3maybe.

Contributor

rsc commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Dec 4, 2013

Contributor

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

Contributor

rsc commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Dec 4, 2013

Contributor

Comment 8:

Labels changed: added repo-main.

Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@odeke-em odeke-em changed the title from build: Compiler option for hardened binary to proposal: cmd/compile: option for building hardened/obfuscated binary Dec 23, 2017

@odeke-em

This comment has been minimized.

Show comment
Hide comment
@odeke-em

odeke-em Dec 23, 2017

Member

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.

Member

odeke-em commented Dec 23, 2017

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.

@odeke-em odeke-em added the Proposal label Dec 23, 2017

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Jan 23, 2018

Contributor

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.

Contributor

rsc commented Jan 23, 2018

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.

@rsc rsc closed this Jan 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment