how and why Golang binary shows file and line info on the error

Question

i was playing around with go sync groups and i just tried what happens if i add more groups than i mark done . and i get the runtime error i posted below. So the question here is if go is compiled into true machine code unlike java or c# how come my file even line info can be shown in runtime errors .If file info is kept in the binary i think it can be easily decompiled . Am i doing something wrong do i need to add some kinda env variable for prod builds or its just like c# theres no true way to hide your code

Answer 1

So for fun, I wrote a trivial Go program that just panic()s and tried farting around with objdump and objcopy to see where this information is. On Linux (perhaps others), Go sticks the relevant info in the ELF section .gopclntab. If you remove it, the reference to the actual program source disappears, but the runtime crashes. And there are references to a ton more runtime.* things in that section (presumably for linkage and introspection). I'm thinking it's unlikely that you can realistically run a Go program with this information totally gone.

You can remove the DWARF info for some security as mentioned elsewhere on SO and a bunch of ELF sections vanish, but your best bet if you're really worried would probably be to preprocess your sources to obfuscate identifiers and filenames before compile. But there doesn't appear to be a ready-made tool to do so.

I'm not one of the Go designers, but I'm guessing going much farther is impractical due to things like introspection (something which e.g. C can't do). Compressors like upx will obfuscate the file at rest slightly (and seem to work OK with compiled Go--maybe a caveat or two in there), but it's trivial to undo if you know it's there (to the point that any security type would take away my developer's licence for my having even mentioned it).

The reality is that the best you can realistically do is speedbump people who are really interested in messing with your code. Obfuscating sources, if you're really that motivated to do it, would be your best bet (though ultimately still futile with sufficiently determined attackers).