5 ms·
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 ac
by TheDong 10y 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 10y agoThat 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 10y agoDo 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 10y agoI 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 10y agoThis. 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 10y agoAre 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.).
- ejcx 10y agoMy point is there are thousands of pieces to how computers work that people don't understand. If you RELY on privacy you should have better opsec than just using your daily driver to build your go binaries. Compartmentalizing your life is important if you NEED the privacy.
- laumars 10y agoThe reason people are defending Go is because this isn't a new phenomena in AOT compiled languages. Popular compilers for a whole plethora of different programming languages have been leaking environmental information into their binaries for as long as I've been a developer (~30 years). It's actually pretty normal practice - particularly if you want to provide debugging data (as this is used for). It's also the kind of analysis security researchers use to establish where malware originates. This is also a non-issue because if you're compiling binaries for redistribution you'd disable the debugging references (via compiler flags) and be building your source in a separate environment to your development environment (eg using Jenkins). Heck, even just a docker container on the dev machine would work. So to recap: 1) not a problem with Go; a problem with debugging references in all AOT compiled languages. 2) not a new issue; I've been observing this in other languages for at least 2 decades. 3) it's easily fixed by implementing any or all of the follow solutions: i) build automation / CI pipeline (your build environment becomes separate from your dev environment) ii) docker or other build container or VM (same reason as above) iii) just disabling the debug references at compile time