Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: no way to omit package information from binary #50501

Closed
denimyftiu opened this issue Jan 7, 2022 · 21 comments
Closed

cmd/go: no way to omit package information from binary #50501

denimyftiu opened this issue Jan 7, 2022 · 21 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@denimyftiu
Copy link

What version of Go are you using (go version)?

go version go1.17.5 linux/amd64

Does this issue reproduce with the latest release?

After compiling and striping a binary it still has inside package information like:

  • Full system paths of packages.
  • Package versions.
  • Data structure information.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/d3ni/.cache/go-build"
GOENV="/home/d3ni/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/d3ni/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/d3ni/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/d3ni/go/src/github.com/denimyftiu/lilurl/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build258303585=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.17.5 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.5
uname -sr: Linux 5.10.0-1053-oem
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.2) stable release version 2.31.
gdb --version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2

What did you do?

  • I tried to compile https://github.com/denimyftiu/lilurl .
  • Command: go build -ldflags="-w -s" ./cmd/shortner.
  • The binary functions fine but still has some information that i might not want inside it. And could lead to later problems if it falls into the wrong hands.
  • When i run strings shortner i can read the following strings left inside the binary:
// Go modules compiled inside the binary
github.com/jackc/pgconn
github.com/jackc/pgtype
github.com/jackc/pgx/v4
github.com/jackc/puddle
golang.org/x/text/cases
golang.org/x/text/runes
golang.org/x/text/width

// My github repo which might be a problem if my repo is private (maybe a problem)
github.com/denimyftiu/lilurl/pkg/config

// And all my go.mod info
path    github.com/denimyftiu/lilurl/cmd/shortner                               
mod github.com/denimyftiu/lilurl    (devel)                                     
dep github.com/cespare/xxhash/v2    v2.1.2  h1:YRXhKfTDauu4ajMg1TPgFO5jnlC2HCbmLXMcTG5cbYE=
dep github.com/dgryski/go-rendezvous    v0.0.0-20200823014737-9f7001d12a5f  h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78=
dep github.com/go-redis/redis/v8    v8.11.4 h1:kHoYkfZP6+pe04aFTnhDH6GDROa5yJdHJVNxV3F46Tg=
dep github.com/gorilla/mux  v1.8.0  h1:i40aqfkR1h2SlN9hojwV5ZA91wcXFOvkdNIeFDP5koI=
dep github.com/jackc/chunkreader/v2 v2.0.1  h1:i+RDz65UE+mmpjTfyz0MoVTnzeYxroil2G82ki7MGG8=
dep github.com/jackc/pgconn v1.10.1 h1:DzdIHIjG1AxGwoEEqS+mGsURyjt4enSmqzACXvVzOT8=
dep github.com/jackc/pgio   v1.0.0  h1:g12B9UwVnzGhueNavwioyEEpAmqMe1E/BN9ES+8ovkE=
dep github.com/jackc/pgpassfile v1.0.0  h1:/6Hmqy13Ss2zCq62VdNG8tM1wchn8zjSGOBJ6icpsIM=
dep github.com/jackc/pgproto3/v2    v2.2.0  h1:r7JypeP2D3onoQTCxWdTpCtJ4D+qpKr0TxvoyMhZ5ns=
dep github.com/jackc/pgservicefile  v0.0.0-20200714003250-2b9c44734f2b  h1:C8S2+VttkHFdOOCXJe+YGfa4vHYwlt4Zx+IVXQ97jYg=
dep github.com/jackc/pgtype v1.9.1  h1:MJc2s0MFS8C3ok1wQTdQxWuXQcB6+HwAm5x1CzW7mf0=
dep github.com/jackc/pgx/v4 v4.14.1 h1:71oo1KAGI6mXhLiTMn6iDFcp3e7+zon/capWjl2OEFU=
dep github.com/jackc/puddle v1.2.0  h1:DNDKdn/pDrWvDWyT2FYvpZVE81OAhWrjCv19I9n108Q=
dep github.com/teris-io/shortid v0.0.0-20201117134242-e59966efd125  h1:3SNcvBmEPE1YlB1JpVZouslJpI3GBNoiqW7+wb0Rz7w=
dep golang.org/x/crypto v0.0.0-20210711020723-a769d52b0f97  h1:/UOmuWzQfxxo9UtlXMwuQU8CMgg1eZXqTRwkSQJWKOI=
dep golang.org/x/text   v0.3.6  h1:aRYxNxv6iGQlyVaZmk6ZgYEDa+Jg18DxebPSrd6bg1M= 
  • All of these are not static/constant strings i have used inside my binary.

What did you expect to see?

  • I wanted to just have compiled code inside the binary and not additional information.
  • This information i guess is there for debugging and profiling reasons.
  • Is there a compiler flag for this??

What did you see instead?

  • Additional information that i don't want someone else with access to the binary to read.
@ianlancetaylor ianlancetaylor changed the title Compiled binary still has package information inside. cmd/go: no way to remove package information from binary Jan 7, 2022
@ianlancetaylor ianlancetaylor changed the title cmd/go: no way to remove package information from binary cmd/go: no way to omit package information from binary Jan 7, 2022
@ianlancetaylor
Copy link
Contributor

At least on tip that information does seem to be there even when using -buildinfo=false -buildvcs=false. Perhaps I'm misunderstanding something, but my reading of #37475 is that there is supposed to be a way to not emit this information.

CC @bcmills @matloob @rsc

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 7, 2022
@ianlancetaylor ianlancetaylor added this to the Go1.18 milestone Jan 7, 2022
@denimyftiu
Copy link
Author

denimyftiu commented Jan 7, 2022

I still can not figure out where to position these arguments in the go/build command.
And i think everything here #37475 is about adding that information to the binary.

@ianlancetaylor
Copy link
Contributor

go build -buildinfo=false -buildvcs-false PACKAGE

@denimyftiu
Copy link
Author

denimyftiu commented Jan 7, 2022

I don't think -buildinfo=false -buildvcs=false are flags that go build supports in go 1.17.5 .

@denimyftiu
Copy link
Author

denimyftiu commented Jan 7, 2022

Mmmm these flags maybe added in go 1.18.
https://tip.golang.org/doc/go1.18#go-command

@seankhliao
Copy link
Member

-buildinfo and -buildvcs affects this part (added in 1.18)

	build	-compiler=gc
	build	CGO_ENABLED=1
	build	CGO_CFLAGS=
	build	CGO_CPPFLAGS=
	build	CGO_CXXFLAGS=
	build	CGO_LDFLAGS=
	build	GOARCH=amd64
	build	GOOS=linux
	build	GOAMD64=v1
	build	vcs=git
	build	vcs.revision=7295d66255e394de962154f806066c611c7b9b87
	build	vcs.time=2022-01-04T22:01:22Z
	build	vcs.modified=true

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.

@denimyftiu
Copy link
Author

I understand. Thank you @seankhliao and @ianlancetaylor.

@bcmills
Copy link
Contributor

bcmills commented Jan 7, 2022

I think the only thing that is a release-blocker here is a decision about whether the new -buildinfo=false flag should also strip module version information.

(Setting -buildinfo=false at tip today gives the same behavior as go1.17.6 without flags, so this is not really a regression so much as a usability/documentation issue for the new flag.)

$ go1.17.6 build -o a.out .

$ go1.17.6 version -m a.out
a.out: go1.17.6
        path    example
        mod     example (devel)

$ gotip build -o a.out -buildinfo=false .

$ gotip version -m a.out
a.out: devel go1.18-11b28e7e9 Fri Jan 7 06:34:04 2022 +0000
        path    example
        mod     example (devel)

@bcmills bcmills added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 7, 2022
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 7, 2022
@ianlancetaylor
Copy link
Contributor

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 -buildinfo=false, that seems reasonable.

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

@gopherbot
Copy link

Change https://golang.org/cl/376674 mentions this issue: cmd/go: do not include module info when -buildinfo=false

@zx2c4
Copy link
Contributor

zx2c4 commented Jan 7, 2022

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.

@rsc
Copy link
Contributor

rsc commented Jan 11, 2022

It sounds like the right answer is to remove the -buildinfo flag.
It is intentional that it is impossible to omit package information from the binary.
It's very small compared to the rest of the binary, and we don't need the long-term complexity of the second mode.
And removing the information makes things like 'go version -m' much less useful.

-buildvcs is different, because that can produce spurious binary differences and can be slow.
That should stay.

@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 11, 2022
@bcmills bcmills self-assigned this Jan 11, 2022
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 11, 2022
mvdan added a commit to mvdan/garble-fork that referenced this issue Jan 11, 2022
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)
lu4p pushed a commit to burrowers/garble that referenced this issue Jan 12, 2022
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)
@zx2c4
Copy link
Contributor

zx2c4 commented Jan 12, 2022

It sounds like the right answer is to remove the -buildinfo flag.

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.

@bcmills
Copy link
Contributor

bcmills commented Jan 12, 2022

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.

Right, that's the thing: the -buildinfo=false flag suggests that we're omitting information, but that information may well still be present in the binary (for example, embedded in file-and-line debug information). Obfuscating a Go binary for deployment to a hostile environment is a whole other can of worms, and one that we certainly cannot address for Go 1.18 (if ever!).

@gopherbot
Copy link

Change https://golang.org/cl/378576 mentions this issue: cmd/go: remove the -buildinfo flag

@ianlancetaylor
Copy link
Contributor

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

@zikaeroh
Copy link
Contributor

FYI the above CL removed the flag, but it's still mentioned in the release notes.

@ianlancetaylor
Copy link
Contributor

@zikaeroh Thanks, sent https://go.dev/cl/379314.

@gopherbot
Copy link

Change https://golang.org/cl/379314 mentions this issue: doc/go1.18: don't mention -buildinfo flag

gopherbot pushed a commit that referenced this issue Jan 19, 2022
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>
crra added a commit to crra/hex-microservice that referenced this issue Feb 9, 2022
crra added a commit to crra/hex-microservice that referenced this issue Feb 10, 2022
* 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
@ghost
Copy link

ghost commented Mar 20, 2022

My discord friend was reverseenginierd my exe file and stealed my real name from path information that was remained in exe file😢

@ken-wizhodl
Copy link

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.

jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
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>
jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
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>
@rsc rsc unassigned bcmills Jun 22, 2022
@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

9 participants