Hi On Sun, Mar 15, 2020 at 12:16 PM Christian Rebischke via arch-dev-public <arch-dev-public@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@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