[arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
Chris.Rebischke at archlinux.org
Sun Mar 15 19:16:10 UTC 2020
On Sun, Mar 15, 2020 at 12:09:07PM -0700, Public mailing list for Arch Linux development wrote:
> Hello Morten
> On Sun, Mar 15, 2020 at 5:38 AM Morten Linderud via arch-dev-public
> <arch-dev-public at archlinux.org> wrote:
> > # Introduction
> > To enable PIE compilation, we have relied on a patched version of the go
> > compiler which has been distributed as `go-pie` since around 2017. However, full
> > RELRO support for go binaries has been a bit back and forth the past years. With
> > some thing working, and other things don't.
> > With the release of Go 1.11 there was support for a general `GOFLAGS` variable
> > that lets us pass flags directly to the compiler. This email details what these
> > flags should be going forward.
> Big +1 for removing go-pie in favor of using GOFLAGS. It makes the
> go-based packages management more straightforward and cleaner.
+1 from me to for this step.
> > # Flags
> > Expected environment variables in PKGBUILDs:
> > export CGO_LDFLAGS="$LDFLAGS"
> > export GOFLAGS="-buildmode=pie -trimpath -mod=vendor -modcacherw"
> > Explanation:
> > * `CGO_LDFLAGS` passes the proper `LDFLAGS` to the linker. This should enable
> > full RELRO when used in conjunction with `GOFLAGS`.
> > * `-buildmode=pie` is the proper way to enable PIE and replaces the `go-pie`
> > patch.
> > * `-trimpath` this is to achieve reproducible builds and remove PWD from the
> > binary.
> > * `-modcacherw` modules are downloaded to `$GOPATH/pkg/mod` and by default have
> > the permissions 444 for god knows why. If we want to run `makepkg -c` or `git
> > clean` we won't have the correct permissions. This is probably not a big
> > problem for repository packages, but it's a nice addition so they work as
> > expected.
> > Notice that `-mod=vendor` is also added to `GOFLAGS`.
> Most of the Go projects do not vendorize their dependencies to avoid
> polluting the source tree.
> And there is no point to force vendorizing in the PKGBUILD neither. go
> modules are doing a great job with pinning dependencies to a specific
> version thus eliminating the main reason for vendor'ization existence
> (i.e. reproducible builds).
> Thus following YAGNI principle I propose to drop this "-mod=vendor" flag.
Correct me if I am wrong, but wouldn't that mean that, if you have a
package with vendor directory you would download the same content twice?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the arch-dev-public