6 ms·

> Note: the default GOROOT, the one that the compiler will use if the environment variable is not set, must also match, since it will be copied into binaries T

> Note: the default GOROOT, the one that the compiler will use if the environment variable is not set, must also match, since it will be copied into binaries This seems worrisome for the privacy of builders. What if someone wishing to stay anonymous built and distributed a Go binary from a system where GOROOT included their home directory and revealed their identity? Am I misinterpreting something?

chrisper 9y ago
I believe in TraceBacks or whatever they are called, it will show the full path of the file that caused the issue. So yeah, it will reveal your name if your gopath is in your home directory.
stock_toaster 9y ago
GOROOT is the root directory of the Go installation itself. More about GOROOT here[1]. If you install Go into your home directory, then yes that path would show up in resultant binaries. [1]: https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goro...
JoshTriplett 9y ago
This is a bug that should be fixed. In the meantime, if you want to be anonymous, build in a non-specific path like /build. And perhaps more generally, you might want to use a generic username like "user".
TheDong 9y ago
The safest way to avoid leaking such information like that is to build inside of a docker container. Even if the goroot is not in a suspicious location, the actual location of each source file on disk is compiled in as well (which almost certainly will be in your home directory). Copying it into `/usr/app/src/$pkgPath` in a docker container makes the path generic and also ensures various other details of your environment are less likely to leak out due to the mount namespacing. Alternately, building it on a CI system like travis and ensuring those are the only binaries you ever distribute is marginally safer.
- giancarlostoro 9y ago
  That or try using a generic username such as "user" or "admin" on a system you control, that way the paths will show up as they should but will be too generic to be useful.
  - ori_b 9y ago
    Do you know enough about your environment to confidently say that this is all that could be leaked? I don't. Modern environments are to complex to manage safely with whitelists. Someone will always forget something.
    - giancarlostoro 9y ago
      I imagine people who really don't want to be identified digitally would do their research and likely use VM's that are stripped down, or whatever other options there are.
- ejcx 9y ago
  This. If you actually NEED to care about your privacy for whatever reason, you should have better opsec than building go binaries, a complicated process that you probably don't fully understand and may contain system artifacts, on your daily driver.
  - BoorishBears 9y ago
    Are you serious? I have a pretty unique name. On some of my PCs I use my name as my account name. I only care about my privacy as much as the next guy, but providing release binaries from my PC shouldn't mean I'm sharing my personal information. Honestly this thread is going in the same direction most other threads I see about any flaw in GO seem to take. Users popup to defend GO and try to downplay the issue or shift blame towards something else, like you not framing the issue in the "GO way" (I guess not wanting to expose your username in release binaries is just not the "GO way", if you're not using Docker for release builds your username showing up is your own fault.).
deleted 9y ago
[deleted]
niftich 9y ago
Yes, it's worrisome. An issue like this was brought up on golang-nuts in 2014 [1]; the response from the devs was that this behavior is intentional [2], and they note that this happens with other compilers as well. I'm attempting to say this without sounding facetious: it's generally bad for privacy if you install tools and compilers to a personally-identifiable path, compile programs from personally-identifiable directories, perhaps using personally-identifiable accounts. Using generic paths (which is in this case the Go default), generically-named work directories, and generic-sounding user accounts is a viable mitigation, that has been used by many programmers who get burned by this from various environments. As you suggest, perhaps there's an education gap here, because this is well-known by security professionals and intelligence services (like the CIA [3]), and less well-known by developers. Furthermore, most of these privacy-leaking behaviors are being (re-)discovered or discussed as a part of the 'reproducible builds' movement (like this one) to attempt to identify context-specific behavior, rather than a concentrated approach about privacy in particular. [1] https://groups.google.com/forum/#!topic/golang-nuts/oVDD8oPvDIY https://groups.google.com/forum/#!topic/golang-nuts/oVDD8oPv... [2] https://groups.google.com/d/msg/golang-nuts/oVDD8oPvDIY/fQ_r_gECFbUJ https://groups.google.com/d/msg/golang-nuts/oVDD8oPvDIY/fQ_r... [3] https://wikileaks.org/ciav7p1/cms/page_27721733.html https://wikileaks.org/ciav7p1/cms/page_27721733.html
- rainbowmverse 9y ago
  I used to enjoy digging into strings buried in binaries trying to find paths from the development environment.
- AdamJacobMuller 9y ago
  At least for Go, I feel like this should be quite obvious to most developers. The first time I saw a go stack trace I strings-d the binary to confirm, as I suspected, that they embedded this information in the binary. I filed it away and didn't think about it much since then (I'm not saying nobody could care, I just don't do things that require that kind of privacy)
- laumars 9y ago
  The devs were right that this does happen with other compilers as well and has been an issue with a great many compilers across a great many languages for as long as I can recall (I remember tearing Windows binaries apart in the 90s to glean information about the developers environment). Thankfully this is less of an issue these days due to the proliferation of containerisation technologies and automated build pipelines, meaning the build system can be completely separated from developers working environment (eg a Jenkins box)
jchw 9y ago
Practically speaking, I don't think it's a problem. You'd probably want to reproduce the builds in an environment that was, itself, reproducible and isolated, such as Docker or a chroot or a VM (Maybe for security reasons rkt would be a good candidate since it has signed images on top of normal cryptographic hashing.) That's my opinion anyway. It's also useful to do so for projects that use a CI pipeline.
- heavenlyhash 9y ago
  Another option to this is Repeatr [1]. Repeatr is for -- like it says on the tin -- repeating things; and hopefully, reproducing them. It's all the containment (runc, underneath), plus the ability to pull in various filesystems, specified by hash. For concrete examples, you can see Repeatr building Repeatr reproducibly here [2], for its own releases (it's a Go project, so this looks a lot like what's going on in Fillipo's blog here). Another example is this formula for reproducible builds of Runc [3] -- it uses cgo, and became reproducible with go1.7, which was very exciting! The big gain is Repeatr's syntax for multiple inputs and built-in hash verification means you can assemble reproducible environments like this out of multiple filesystems (say, busybox from one place, golang compiler separately), they all cache separately, they all download in parallel, you never have to write your own "tar -xcvf" boilerplate... and most importantly, you get built-in sanity-checking that the upstream tarballs you're using haven't changed either. No centralized "registry" server required, either. Give it a try! Disclaimer: author, of course :) --- [1] http://repeatr.io http://repeatr.io , https://github.com/polydawn/repeatr https://github.com/polydawn/repeatr [2] https://github.com/polydawn/repeatr/blob/master/meta/releases/repeatr-release-v0.14.frm https://github.com/polydawn/repeatr/blob/master/meta/release... [3] https://github.com/polydawn/formulary/blob/master/formulas/runc/runc.frm https://github.com/polydawn/formulary/blob/master/formulas/r...
  - rocqua 9y ago
    For getting true value from reproducible builds, the environment should be as free as possible. If a build requires a certain image to be used, you need to trust that image not to be backdoored. Ideally, the only binary dependency in the environmental requirements is the compiler itself. Everything else should be source-code or plain-text. Getting the compiler out of the chain would be even better, but trusting trust is a hard problem.
userbinator 9y ago
I can understand having full paths in binaries for the debug versions (which you shouldn't be distributing anyway), but if you're compiling a release version, does the path still get included? If so, that sounds like a bug.
sanbor 9y ago
This is why my username in every machine is "user".
- mirimir 9y ago
  user@host here :)
binarycrusader 9y ago
It's actually possible to workaround this by using the -trimpath option to the assembler via '-asmflags -trimpath'. I do this when I build Go for Solaris: https://github.com/oracle/solaris-userland/blob/master/components/golang-17/Makefile#L262 https://github.com/oracle/solaris-userland/blob/master/compo... https://github.com/golang/go/issues/13616 https://github.com/golang/go/issues/13616 See also: https://github.com/golang/go/issues/16860 https://github.com/golang/go/issues/16860
frik 9y ago
At least this one Interestingly, the build host architecture does not matter. In other words, builds are reproducible across cross- compiling. Is there a list of what compilers embed what identifier to binaries? Thinking about it compiler could embed CPU ID, MAC address, etc to make you traceable - but do they? (like color printer/photocopier embed almost invisible code on every age, to make you traceable).
- iand 9y ago
  I don't know of a list but people have been aware of the potential for decades: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
zkms 9y ago
> This seems worrisome for the privacy of builders. What if someone wishing to stay anonymous built and distributed a Go binary from a system where GOROOT included their home directory and revealed their identity? Am I misinterpreting something? Anyone who cares enough about this must be sure to use a nondescript username / path for creating binaries. Sniffing around for paths and filenames (and other compiler artifacts, like date/date formats/time zone/time of build, version numbers, locale/language markers, debug symbols, UUIDs, copyright strings, format strings) is an extremely well-known technique for investigating the origin of a suspect binary -- anyone who has ever heard of "malware attribution" is sure to know about this.
_pmf_ 9y ago
Note that builds with GCC and debug information are also potentially identifiable as they may contain full source paths (/home/my_actual_name/projects/my_project/src/my_module.c).

chrisper 9y ago

I believe in TraceBacks or whatever they are called, it will show the full path of the file that caused the issue. So yeah, it will reveal your name if your gopath is in your home directory.

stock_toaster 9y ago

GOROOT is the root directory of the Go installation itself. More about GOROOT here[1]. If you install Go into your home directory, then yes that path would show up in resultant binaries. [1]: https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goro...

JoshTriplett 9y ago

This is a bug that should be fixed. In the meantime, if you want to be anonymous, build in a non-specific path like /build. And perhaps more generally, you might want to use a generic username like "user".

TheDong 9y ago

The safest way to avoid leaking such information like that is to build inside of a docker container. Even if the goroot is not in a suspicious location, the actual location of each source file on disk is compiled in as well (which almost certainly will be in your home directory). Copying it into `/usr/app/src/$pkgPath` in a docker container makes the path generic and also ensures various other details of your environment are less likely to leak out due to the mount namespacing. Alternately, building it on a CI system like travis and ensuring those are the only binaries you ever distribute is marginally safer.

giancarlostoro 9y ago
That or try using a generic username such as "user" or "admin" on a system you control, that way the paths will show up as they should but will be too generic to be useful.
- ori_b 9y ago
  Do you know enough about your environment to confidently say that this is all that could be leaked? I don't. Modern environments are to complex to manage safely with whitelists. Someone will always forget something.
  - giancarlostoro 9y ago
    I imagine people who really don't want to be identified digitally would do their research and likely use VM's that are stripped down, or whatever other options there are.
ejcx 9y ago
This. If you actually NEED to care about your privacy for whatever reason, you should have better opsec than building go binaries, a complicated process that you probably don't fully understand and may contain system artifacts, on your daily driver.
- BoorishBears 9y ago
  Are you serious? I have a pretty unique name. On some of my PCs I use my name as my account name. I only care about my privacy as much as the next guy, but providing release binaries from my PC shouldn't mean I'm sharing my personal information. Honestly this thread is going in the same direction most other threads I see about any flaw in GO seem to take. Users popup to defend GO and try to downplay the issue or shift blame towards something else, like you not framing the issue in the "GO way" (I guess not wanting to expose your username in release binaries is just not the "GO way", if you're not using Docker for release builds your username showing up is your own fault.).

deleted 9y ago

[deleted]

niftich 9y ago

Yes, it's worrisome. An issue like this was brought up on golang-nuts in 2014 [1]; the response from the devs was that this behavior is intentional [2], and they note that this happens with other compilers as well. I'm attempting to say this without sounding facetious: it's generally bad for privacy if you install tools and compilers to a personally-identifiable path, compile programs from personally-identifiable directories, perhaps using personally-identifiable accounts. Using generic paths (which is in this case the Go default), generically-named work directories, and generic-sounding user accounts is a viable mitigation, that has been used by many programmers who get burned by this from various environments. As you suggest, perhaps there's an education gap here, because this is well-known by security professionals and intelligence services (like the CIA [3]), and less well-known by developers. Furthermore, most of these privacy-leaking behaviors are being (re-)discovered or discussed as a part of the 'reproducible builds' movement (like this one) to attempt to identify context-specific behavior, rather than a concentrated approach about privacy in particular. [1] https://groups.google.com/forum/#!topic/golang-nuts/oVDD8oPvDIY https://groups.google.com/forum/#!topic/golang-nuts/oVDD8oPv... [2] https://groups.google.com/d/msg/golang-nuts/oVDD8oPvDIY/fQ_r_gECFbUJ https://groups.google.com/d/msg/golang-nuts/oVDD8oPvDIY/fQ_r... [3] https://wikileaks.org/ciav7p1/cms/page_27721733.html https://wikileaks.org/ciav7p1/cms/page_27721733.html

rainbowmverse 9y ago
I used to enjoy digging into strings buried in binaries trying to find paths from the development environment.
AdamJacobMuller 9y ago
At least for Go, I feel like this should be quite obvious to most developers. The first time I saw a go stack trace I strings-d the binary to confirm, as I suspected, that they embedded this information in the binary. I filed it away and didn't think about it much since then (I'm not saying nobody could care, I just don't do things that require that kind of privacy)
laumars 9y ago
The devs were right that this does happen with other compilers as well and has been an issue with a great many compilers across a great many languages for as long as I can recall (I remember tearing Windows binaries apart in the 90s to glean information about the developers environment). Thankfully this is less of an issue these days due to the proliferation of containerisation technologies and automated build pipelines, meaning the build system can be completely separated from developers working environment (eg a Jenkins box)

jchw 9y ago

Practically speaking, I don't think it's a problem. You'd probably want to reproduce the builds in an environment that was, itself, reproducible and isolated, such as Docker or a chroot or a VM (Maybe for security reasons rkt would be a good candidate since it has signed images on top of normal cryptographic hashing.) That's my opinion anyway. It's also useful to do so for projects that use a CI pipeline.

heavenlyhash 9y ago
Another option to this is Repeatr [1]. Repeatr is for -- like it says on the tin -- repeating things; and hopefully, reproducing them. It's all the containment (runc, underneath), plus the ability to pull in various filesystems, specified by hash. For concrete examples, you can see Repeatr building Repeatr reproducibly here [2], for its own releases (it's a Go project, so this looks a lot like what's going on in Fillipo's blog here). Another example is this formula for reproducible builds of Runc [3] -- it uses cgo, and became reproducible with go1.7, which was very exciting! The big gain is Repeatr's syntax for multiple inputs and built-in hash verification means you can assemble reproducible environments like this out of multiple filesystems (say, busybox from one place, golang compiler separately), they all cache separately, they all download in parallel, you never have to write your own "tar -xcvf" boilerplate... and most importantly, you get built-in sanity-checking that the upstream tarballs you're using haven't changed either. No centralized "registry" server required, either. Give it a try! Disclaimer: author, of course :) --- [1] http://repeatr.io http://repeatr.io , https://github.com/polydawn/repeatr https://github.com/polydawn/repeatr [2] https://github.com/polydawn/repeatr/blob/master/meta/releases/repeatr-release-v0.14.frm https://github.com/polydawn/repeatr/blob/master/meta/release... [3] https://github.com/polydawn/formulary/blob/master/formulas/runc/runc.frm https://github.com/polydawn/formulary/blob/master/formulas/r...
- rocqua 9y ago
  For getting true value from reproducible builds, the environment should be as free as possible. If a build requires a certain image to be used, you need to trust that image not to be backdoored. Ideally, the only binary dependency in the environmental requirements is the compiler itself. Everything else should be source-code or plain-text. Getting the compiler out of the chain would be even better, but trusting trust is a hard problem.

userbinator 9y ago

I can understand having full paths in binaries for the debug versions (which you shouldn't be distributing anyway), but if you're compiling a release version, does the path still get included? If so, that sounds like a bug.

sanbor 9y ago

This is why my username in every machine is "user".

mirimir 9y ago
user@host here :)

binarycrusader 9y ago

It's actually possible to workaround this by using the -trimpath option to the assembler via '-asmflags -trimpath'. I do this when I build Go for Solaris: https://github.com/oracle/solaris-userland/blob/master/components/golang-17/Makefile#L262 https://github.com/oracle/solaris-userland/blob/master/compo... https://github.com/golang/go/issues/13616 https://github.com/golang/go/issues/13616 See also: https://github.com/golang/go/issues/16860 https://github.com/golang/go/issues/16860

frik 9y ago

At least this one Interestingly, the build host architecture does not matter. In other words, builds are reproducible across cross- compiling. Is there a list of what compilers embed what identifier to binaries? Thinking about it compiler could embed CPU ID, MAC address, etc to make you traceable - but do they? (like color printer/photocopier embed almost invisible code on every age, to make you traceable).

iand 9y ago
I don't know of a list but people have been aware of the potential for decades: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

zkms 9y ago

> This seems worrisome for the privacy of builders. What if someone wishing to stay anonymous built and distributed a Go binary from a system where GOROOT included their home directory and revealed their identity? Am I misinterpreting something? Anyone who cares enough about this must be sure to use a nondescript username / path for creating binaries. Sniffing around for paths and filenames (and other compiler artifacts, like date/date formats/time zone/time of build, version numbers, locale/language markers, debug symbols, UUIDs, copyright strings, format strings) is an extremely well-known technique for investigating the origin of a suspect binary -- anyone who has ever heard of "malware attribution" is sure to know about this.

_pmf_ 9y ago

Note that builds with GCC and debug information are also potentially identifiable as they may contain full source paths (/home/my_actual_name/projects/my_project/src/my_module.c).