Public service announcement: Golang leaks your private informations
I just found out that the binaries produced by `go build` contain, in plaintext, paths of source files (and thus your login name, project structure, names of libraries used, ...). Apparently the authors think it is a good thing because it helps with debugging (or something). More information here:
https://www.reddit.com/r/golang/comments/50xv61/linux_trojan_written_in_go/
https://www.reddit.com/r/golang/comments/50xv61/linux_trojan_written_in_go/d78cape
https://github.com/golang/go/issues/9206
https://github.com/golang/go/issues/16860
3 comments
[ 5.6 ms ] story [ 23.9 ms ] threadOn windows / MSVC, this will be contained in seperate .pdb files. On 'nix systems or their toolchains, this will often be embedded directly into your elf binaries, which can be a little more convenient. There are tools to "strip" symbols (or you can just not ship the .pdbs if your compiler generates those instead), although I think of this as a tool to (slightly) complicate reverse engineering, not a tool to protect login names or project structures very much. If you keep a copy of the original unstripped binaries around, you can use e.g. symbolicator for iOS to reassociate crash dumps with symbol, file, and line information - very useful for debugging production crashes you can't replicate in-house.
Investigate obfuscators if you really want to hide that stuff, as mere symbol stripping is unlikely to hide e.g. what libraries you're using well, if at all. I know people sometimes analyze binaries to search for GPL violations, if you wanted a thread to follow up on if that's legitimately information you have a vested interest in hiding. I assume this will probably destroy your ability to get proper stack traces for production crashes, even with the original bins.
EDIT: Another culprit for this to be aware of - asserts and logging. In C or C++ you'll see e.g. the __FILE__ and __LINE__ macros used to make these more developer friendly. Some of these systems may still be enabled in release builds. Different mechanisms to achieve the same results in other programming languages. Also, just because .pdb s are separate, doesn't mean they won't get accidentally packaged into the builds you release, as I've found out twice. It also doesn't prevent you from accidentally shipping a full blown debug build by accident. All things to be careful of, if you care about these things.
Microsoft has an entire symbol server dedicated to sharing their symbols: https://msdn.microsoft.com/en-us/library/windows/hardware/ff... . It's very handy. Multiple people in my local dev chatrooms that it was acting up and being slow this weekend.