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