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

[Christian Rebischke]

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?

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200315/ebd00d98/attachment.sig>