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? Chris
signature.asc
Description: PGP signature
