[arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

[Anatol Pomozov]

Hi

On Sun, Mar 15, 2020 at 12:16 PM Christian Rebischke via
arch-dev-public <arch-dev-public at archlinux.org> wrote:
>
> 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?

No, it will not download twice. If upstream provides top-level
"vendor" directory  then go 1.14 modules will use these sources
instead of the one from cache.

Quoting the Go 1.14 release notes: "When the main module contains a
top-level vendor directory and its go.mod file specifies go 1.14 or
higher, the go command now defaults to -mod=vendor for operations that
accept that flag."

https://golang.org/doc/go1.14#go-command