cmd/go: no way to omit package information from binary #50501
Comments
ianlancetaylor
changed the title
ianlancetaylor
changed the title
ianlancetaylor
added
the
NeedsInvestigation
|
I still can not figure out where to position these arguments in the go/build command. |
|
|
|
I don't think |
|
Mmmm these flags maybe added in go 1.18. |
|
afaik module dependency information can't be stripped. As a note, requiring the package/module names to not be present in the final executable seems unreasonable as it would break things like reflect and stacktraces. |
|
I understand. Thank you @seankhliao and @ianlancetaylor. |
|
I think the only thing that is a release-blocker here is a decision about whether the new (Setting |
bcmills
added
the
NeedsDecision
gopherbot
removed
the
NeedsInvestigation
|
I'm inclined to think that there should be some way to tell the go tool to not add all the module info to the binary. If that is @seankhliao is quite correct in pointing out that the package names are going to remain in the binary in all the cases for stack trace purposes. But we can at least omit the details of the package versions. |
|
Change https://golang.org/cl/376674 mentions this issue: |
|
I took a stab at it because it seemed trivial. If that CL is fundamentally flawed, which it might be because I don't really know this part of the codebase, feel free to just disregard it and send a better one. |
|
It sounds like the right answer is to remove the -buildinfo flag. -buildvcs is different, because that can produce spurious binary differences and can be slow. |
bcmills
added
the
NeedsFix
gopherbot
removed
the
NeedsDecision
It looks like the flag will be scrapped from Go 1.18. Stop using it before 1.18rc1 releases without it. See: golang/go#50501 (comment)
It looks like the flag will be scrapped from Go 1.18. Stop using it before 1.18rc1 releases without it. See: golang/go#50501 (comment)
I'm not a huge fan of that. From an info leak perspective, sometimes I'd prefer binaries have less information rather than more. Not everybody's use case involves something being built from google3 or whatever. I realize there are other ways of obtaining that info from a given binary, but from some perspectives, the less you have there, the better. I realize you might not share that perspective though. That's fine. Just thought I'd make record of my "aw shucks" before it's gone for good. |
Right, that's the thing: the |
|
Change https://golang.org/cl/378576 mentions this issue: |
|
@denimyftiu I want to be clear that the suggested resolution for this issue is to say that the tools are behaving as expected when they record package names in the binary. |
|
FYI the above CL removed the flag, but it's still mentioned in the release notes. |
|
@zikaeroh Thanks, sent https://go.dev/cl/379314. |
|
Change https://golang.org/cl/379314 mentions this issue: |
It was removed in CL 378576. For #50501 Change-Id: I26b8f0e99a40fa5c616aa4849a6ab15dd0d072f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/379314 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
* Remove unsupported flag see: golang/go#50501 * Sync general project structure from mp3binder * Introduce a simple health endpoint * Simple health service * Change permanent redirect to temporary * Fixes a known issue with httprouter * Fixes parameter access for httprouter * Updates inspiration references and golang 1.18b2 * Closed todo about other routers
|
My discord friend was reverseenginierd my exe file and stealed my real name from path information that was remained in exe file😢 |
|
Trying to pass some secret value with "-ldflags", with go 1.18, it's impossible to avoid someone getting that secret value simply find "ldflags" in an editor with the binary file. For me, it's definitely a regressing. |
Fixes golang#50501 (in a sense, by removing a flag that looks like it should do something it does not) Change-Id: I69ae4862706a6283cda4016fd43b361bb21557f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/378576 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
It was removed in CL 378576. For golang#50501 Change-Id: I26b8f0e99a40fa5c616aa4849a6ab15dd0d072f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/379314 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
After compiling and striping a binary it still has inside package information like:
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
go build -ldflags="-w -s" ./cmd/shortner.strings shortneri can read the following strings left inside the binary:What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: