2 ms·

The 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 programm

by laumars 10y ago

The 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

BoorishBears 10y ago
The language used in the Google groups thread above strongly implies that release builds should have the same information embedded: > I think this approach sounds to be the cleanest. Using -ldflags -s is probably untenable for releases since people expect all of the normal reflection and debugging to work properly. GOROOT_FINAL gets around the privacy issue without making any other major changes. I'm no stranger to debugging symbols having personal info, that's why I specifically mention `release` builds no less than 3 times. They're even admitting it's a privacy issue but mentioning a fix that's non-default option, but I'll give them that having a fix period is good. And to this: > The reason people are defending Go is because this isn't a new phenomena in AOT compiled languages I'd correct that to the reason you're defending Go in that comment, plenty of people clearly don't think it's an issue not because they're used to debugging symbols having personal info, but because of what boils down to "What's the big deal you're using Docker right?". All of that aside, my comment about my experiences with Go on HN go well past this single thread...
- deleted 10y ago
  [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- laumars 10y ago
  > All of that aside, my comment about my experiences with Go on HN go well past this single thread... Honestly I see just as many people being highly critical of Go as well. Go is like the Apple of programming languages: it's opinionated, arguably spare in design and often polarises people opinions. But with regards to your main point, i was talking about production builds as well. I've lost count of the number of times I've pulled build data from a Windows PE or Linux / FreeBSD ELF. I went to college in the 90s and it was a hobby of mine to reverse engineer the build environment of Windows executables (a bit like in this article) because I wanted to know what technologies the professionals were using.

by laumars 10y ago

BoorishBears 10y ago

The language used in the Google groups thread above strongly implies that release builds should have the same information embedded: > I think this approach sounds to be the cleanest. Using -ldflags -s is probably untenable for releases since people expect all of the normal reflection and debugging to work properly. GOROOT_FINAL gets around the privacy issue without making any other major changes. I'm no stranger to debugging symbols having personal info, that's why I specifically mention `release` builds no less than 3 times. They're even admitting it's a privacy issue but mentioning a fix that's non-default option, but I'll give them that having a fix period is good. And to this: > The reason people are defending Go is because this isn't a new phenomena in AOT compiled languages I'd correct that to the reason you're defending Go in that comment, plenty of people clearly don't think it's an issue not because they're used to debugging symbols having personal info, but because of what boils down to "What's the big deal you're using Docker right?". All of that aside, my comment about my experiences with Go on HN go well past this single thread...

deleted 10y ago
[deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
laumars 10y ago
> All of that aside, my comment about my experiences with Go on HN go well past this single thread... Honestly I see just as many people being highly critical of Go as well. Go is like the Apple of programming languages: it's opinionated, arguably spare in design and often polarises people opinions. But with regards to your main point, i was talking about production builds as well. I've lost count of the number of times I've pulled build data from a Windows PE or Linux / FreeBSD ELF. I went to college in the 90s and it was a hobby of mine to reverse engineer the build environment of Windows executables (a bit like in this article) because I wanted to know what technologies the professionals were using.