5 ms·

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 yo

by 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.).
- ejcx 9y ago
  My 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 9y 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 9y 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 9y ago
      [deleted]
      - deleted 9y ago
        [deleted]
      - deleted 9y ago
        [deleted]
    - laumars 9y 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 ejcx 9y ago

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.).

ejcx 9y ago
My 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 9y 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 9y 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 9y ago
    [deleted]
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
  - laumars 9y 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.