Arch Linux

If the latest version of Go respects GOFLAGS, I like that idea that we could have a good default value for GOFLAGS in /etc/makepkg.conf, and then perhaps only have one single "go" package. But I'm open to any solution.

Yes, one Go package should be enough, and people should override `no-pie` in the failing PKGBUILD. We don’t need to wait for a makepkg update though if that would take too long, we can already merge go-pie into go and tell people to override in their PKGBUILD if required. Then when makepkg is patched, we can revert go(-pie) to the normal go.

Hmm, as mentioned by Barthalion on IRC, enabling PIE on all systems by default if it sometimes does not work, is not quite comparable to gcc.

"ssp/pie enforced by gcc at worst exposes badly written makefiles"

At the same time, we want to enforce this (where it works) on a distribution level, as a default. This is primarily targeted at packaging, which is an environment we can control...

As I understand it, GOFLAGS are read by the go compiler itself, whereas CFLAGS/LDFLAGS are a convention read by Makefiles and passed as arguments *to* gcc... so there's more benefit to sneaking around the environment variable for gcc and badly written Makefiles than there is for golang.

...

This being the case, maybe it does make more sense to add first-class support for GOFLAGS in makepkg itself, then set this as a distribution packaging default. Benefits: Enabling PIE, enabling debug support via OPTIONS=(), possibly configuring optimization levels, etc.

I can put in the work to push this into makepkg.

How this works:

- makepkg.conf will contain $FOO and $FOO_DEBUG settings for a given type of flag

-- $FOO (or GOFLAGS) contains the default flags passed for all packages

-- $FOO_DEBUG (or GOFLAGS_DEBUG) contains additional flags appended as GOFLAGS="$GOFLAGS $GOFLAGS_DEBUG", iff the user has debug packages enabled. The flags are cumulative and can override the default flags, but both will be passed.

- makepkg will handle the process of exporting the $FOO (or GOFLAGS) variable.

-- If options=(!buildflags) is set in the PKGBUILD, all build flags will be unset instead. More fine-grained control can be achieved by the PKGBUILD itself setting: `export GOFLAGS="${GOFLAGS/--bad-flag/}"` to filter out bad flags.

-- If the package is debug-enabled, gcc's CFLAGS will also receive the (not configurable) flag -fdebug-prefix-map=$srcdir=${DBGSRCDIR:-/usr/src/debug} which ensures that debug data references to source code files will point to source code packaged in /usr/src/debug/. This assumes that makepkg's "strip" routine can find the source files referenced via the keywords "DW_AT_name"/"DW_AT_comp_dir" (from readelf --debug-dump). I can find DW_AT_name in a sample golang binary, but it points to e.g. "github.com/keybase/client/go/vendor/github.com/keybase/go-crypto/ssh/terminal.keyCtrlC" which appears to be a ${GOPATH}-relative import path for a symbol contained inside .../ssh/terminal/terminal.go, which is not at all similar. So, how does golang work instead?

...

So the question becomes, what should go inside those variables in order to ensure the best out-of-the-box experience from a distribution packaging perspective?

Sorry for not putting my thoughts here yesterday.

As I said on IRC, in my opinion we should ditch go-pie completely, as it's just too simplistic attempt to fix everything, as shown by snapd, containerd or gopass that segfault; instead, just as Eli said, we should make GOFLAGS first class citizen in makepkg.conf and then think about fixing packages that ignore it somehow.

Foxboron said he has figured out what should be in GOFLAGS to make PIE default without breaking projects above.

(Other story is that go-pie is just unsupported upstream as is, which is not what we aim for.)

Correction:

I know the GOFLAGS for PIE and relro, along with having a default value for trimpath. I can't make any promises regarding breakage.

For documentation:
export GOFLAGS="-buildmode=pie -gcflags=all=-trimpath=${PWD} -asmflags=all=-trimpath=${PWD} -ldflags=-extldflags=-zrelro -ldflags=-extldflags=-znow"

Shouldn’t we export all our LDFLAGS that way though?

Yes. But I'm a bit unsure about the GOFLAGS parser as `-extdlflags=${LDFLAGS}` work if you pass it into `go build` or `go install`. But passing the flags individually trips up things.

Yes I know, I meant something like:
GOFLAGS="-buildmode=pie -gcflags=all=-trimpath=${PWD} -asmflags=all=-trimpath=${PWD} -ldflags=-extldflags=-zrelro -ldflags=-extldflags=-znow -ldflags=-extldflags=-Wl -ldflags=-extldflags=-O1 -ldflags=-extldflags=--sort-common -ldflags=-extldflags=--as-needed"

LDFLAGS are passed to gcc and gcc knows to pass them to /usr/bin/ld because of the -Wl -- so -Wl is not itself an ldflag...
(-Wl,comma,separated,values where "comma" and "separated" and "values" are three flags that /usr/bin/ld will receive.)

@Foxboron, does trimpath do something w.r.t. debugging symbols? If I understand correctly, golang does not recommend using gdb to debug code, but recommends something called "delve" instead. Is there anything we need to do in order to get that to work nicely OOTB, like packaging detached debugging source files for the debugger alongside the detached debugging symbols?

OK, seems we will have a hard time passing the last three then…

(Just to expand on my previous comment, as explained on IRC you cannot have commas or spaces in the arg of `-ldflags=-extldflags=arg`, even if you quote it)

Would it be feasible to patch Go so that we can pass the ldflags we need, either through GOFLAGS or through LDFLAGS? Upstream might even want to accept the patch, if we found a relatively clean solution.

I assume other Linux distros will face the same challenge as well.

I tried adding line posted by Morten to containerd's build(), and it did absolutely nothing:

containerd W: ELF file ('usr/bin/containerd-shim') lacks FULL RELRO, check LDFLAGS.
containerd W: ELF file ('usr/bin/containerd-shim-runc-v1') lacks FULL RELRO, check LDFLAGS.
containerd W: ELF file ('usr/bin/containerd-shim') lacks PIE.
containerd W: ELF file ('usr/bin/containerd-shim-runc-v1') lacks PIE.
containerd W: Dependency included and not needed ('runc')

Also test suite fails but I assume that Makefile is doing something stupid:

==> Starting check()...
🇩 test
go test: ldflags flag may be set only once
run "go help test" or "go help testflag" for more information
make: *** [Makefile:150: test] Error 2

I have tried it with "hub".

hub W: ELF file ('usr/bin/hub') lacks FULL RELRO, check LDFLAGS.

But at least no warnings about PIE.

As the bottom line is getting rid of go-pie package, GOFLAGS set to -buildmode=pie would be enough for that. From there we could experiment with getting RELRO.

@Barthalion

GO for it!

Please submit your homonym jokes to a joke website, and don't spam the bugtracker. Thanks.