# 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.
# 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`. This will make sure we are using the vendored dependencies in the project. If they are not present, please ensure they are downloaded in the `prepare` function:
prepare(){ cd $pkgname-$pkgver go mod vendor }
If the project is *not* using Go 1.11 modules, missing `go.mod` and/or `go.sum` in the project root, then disable it with `export GO111MODULE=off` and continue with symlink hacks.
Some upstreams override these values for strange reasons in their `Makefile` and build systems. You *need* to read over them and ensure this does not happen!
# Pacman
Clearly we shouldn't have to specify this in every PKGBUILD, so I have been playing with a `pacman` patch that passes all of the variables. However I have been struggling with debug support and figuring out that part of the flags, so nothing have been upstreamed yet.
However this is only applicable to around 126 packages, so I guess it's fine? ¯_(ツ)_/¯
# In conclusion...
If there are no objections to the New Way Of Doing Things™, I'll be updating the package guidelines within the next week or two and drop the `go-pie` package containing the patch. For the sake of compatibility, the `go` package will contain a `replaces=('go-pie')`. I also expect people packaging go packages to follow the guidelines!
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.
# 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.
This will make sure we are using the vendored dependencies in the project. If they are not present, please ensure they are downloaded in the `prepare` function:
prepare(){ cd $pkgname-$pkgver go mod vendor }If the project is *not* using Go 1.11 modules, missing `go.mod` and/or `go.sum` in the project root, then disable it with `export GO111MODULE=off` and continue with symlink hacks.
Some upstreams override these values for strange reasons in their `Makefile` and build systems. You *need* to read over them and ensure this does not happen!
# Pacman
Clearly we shouldn't have to specify this in every PKGBUILD, so I have been playing with a `pacman` patch that passes all of the variables. However I have been struggling with debug support and figuring out that part of the flags, so nothing have been upstreamed yet.
However this is only applicable to around 126 packages, so I guess it's fine? ¯_(ツ)_/¯
# In conclusion...
If there are no objections to the New Way Of Doing Things™, I'll be updating the package guidelines within the next week or two and drop the `go-pie` package containing the patch. For the sake of compatibility, the `go` package will contain a `replaces=('go-pie')`. I also expect people packaging go packages to follow the guidelines!
-- Morten Linderud PGP: 9C02FF419FECBE16
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?
Chris
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."
On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via arch-dev-public wrote:
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.
`-mod=vendor` is implicit as of go 1.14. We are forcing this to ensure we are not running into new implicit behaviour in the future, such as updating pinned versions or what not. They have changed this once before already.
What upstream thinks in terms of polluting the source tree is irrelevant in this case. We need to fetch the dependencies before over the wire before build() and check().
Hello
On Sun, Mar 15, 2020 at 12:24 PM Morten Linderud via arch-dev-public arch-dev-public@archlinux.org wrote:
On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via arch-dev-public wrote:
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.
`-mod=vendor` is implicit as of go 1.14.
-mod=vendor is neither implicit nor required. -mod=vendor flag is enabled by default only if upstream project uses vendorized project structure so the build scripts do not have to add this flag manually.
The decisions whether to use a vendor directory structure or not should be up to upstream developers.
We are forcing this to ensure we are not running into new implicit behaviour in the future, such as updating pinned versions or what not. They have changed this once before already.
I do not quite follow this argument. Could you please expand more on it?
We need to fetch the dependencies before over the wire before build() and check().
go modules will fetch the dependencies using the information from go.sum. I have go packages with dependencies, and following build()
build() { cd $dir go build }
works great, including chroot environment.
On Sun, Mar 15, 2020 at 01:09:19PM -0700, Anatol Pomozov via arch-dev-public wrote:
Hello
On Sun, Mar 15, 2020 at 12:24 PM Morten Linderud via arch-dev-public arch-dev-public@archlinux.org wrote:
On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via arch-dev-public wrote:
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.
`-mod=vendor` is implicit as of go 1.14.
-mod=vendor is neither implicit nor required. -mod=vendor flag is enabled by default only if upstream project uses vendorized project structure so the build scripts do not have to add this flag manually.
I fail to see how this isn't implicit if it's enabled on the fly. This behaviour has changed before and we really want to ensure we not downloading dependencies during building.
We can discuss the merits of replacing `go mod vendor` with `go mod download` and thus drop the vendor flag. However this requires packagers to realize they don't need `prepare()` if vendor is present in the release tarballs/upstreams.
But I'd rather have this as streamlined as possible across upstreams and having packagers think about less implicit behaviour from go.
The decisions whether to use a vendor directory structure or not should be up to upstream developers.
Strictly speaking, but this is offtopic, this is up to downstream. And no, we shouldn't be using vendored dependencies. But this is another discussion and a issue at large in several ecosystems.
We need to fetch the dependencies before over the wire before build() and check().
go modules will fetch the dependencies using the information from go.sum. I have go packages with dependencies, and following build()
build() { cd $dir go build }
works great, including chroot environment.
I'm aware that go {list,build,test} fetches dependencies on the fly.
And let me reiterate again; *This shouldn't happen*.
We should be capable of performing complete software builds without internet connection. If we can't have the sources downloaded in the source array, they need to be fetched in prepare.
This is why I'm also bringing up the prepare function in the first place.
On 3/15/20 4:40 PM, Morten Linderud via arch-dev-public wrote:
I'm aware that go {list,build,test} fetches dependencies on the fly.
And let me reiterate again; *This shouldn't happen*.
We should be capable of performing complete software builds without internet connection. If we can't have the sources downloaded in the source array, they need to be fetched in prepare.
This is why I'm also bringing up the prepare function in the first place.
But once you're in prepare(), you're no longer in $SRCDEST and you've already failed, no caching is taking place.
You're also already inside the chroot, which means you cannot disable the internet connection for the chroot (not that we have been able to do so in the past, but fetching sources in prepare() certainly doesn't get us closer to offline builds.)
Yo!
After being lazy for a few weeks, I got around to writing the new guidelines for Go packages. Currently it's a draft and I'd love if people read through it and ack/nacked
https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines
The current changes is dropping anything pre-1.11 completely. I don't see the need to detail the GOPATH hacks as new packages should be using go modules, and existing packages is moving to go modules.
The other changes is explicitly listing up the needed CGO_* variables needed. Levente pointed out CGO_CFLAGS is still needed for FORTIFY_SOURCE, so for the sake of completeness it's all listed.
I have also removed `-mod=vendor` from the default listing in `prepare()` as Anatol wasn't fond of the idea. I'm still unsure if we really want this as we would be willynilly downloading sources in `build()` and `check()` during packaging. Opinions welcome.
If anything is confusing or missing, do tell.
On 20/04/2020 00.32, Morten Linderud via arch-dev-public wrote:
I have also removed `-mod=vendor` from the default listing in `prepare()` as Anatol wasn't fond of the idea. I'm still unsure if we really want this as we would be willynilly downloading sources in `build()` and `check()` during packaging. Opinions welcome.
Ideally we don't, but practically it's irrelevant as long as devtools run builds with network access.
Bart
On Mon, Apr 20, 2020 at 12:32:18AM +0200, Public mailing list for Arch Linux development wrote:
I have also removed `-mod=vendor` from the default listing in `prepare()` as Anatol wasn't fond of the idea. I'm still unsure if we really want this as we would be willynilly downloading sources in `build()` and `check()` during packaging. Opinions welcome.
Hi, I think we should use `-mod=vendor`, It's bad practice to download sources in `build()` and/or `check()`. A build should work in isolation.
Chris
Hi Morten
On Sun, Apr 19, 2020 at 3:32 PM Morten Linderud via arch-dev-public arch-dev-public@archlinux.org wrote:
Yo!
After being lazy for a few weeks, I got around to writing the new guidelines for Go packages. Currently it's a draft and I'd love if people read through it and ack/nacked
https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines
Thank you for coming up with this document.
Go is a fantastic language and I would love to see more people using it. Having things documented will help our users to get more comfortable with the golang packaging.
The current changes is dropping anything pre-1.11 completely. I don't see the need to detail the GOPATH hacks as new packages should be using go modules, and existing packages is moving to go modules.
+1. The current "go modules" implementation is so much more superior to what Golang had before. "go modules" is the default option nowadays.
The other changes is explicitly listing up the needed CGO_* variables needed. Levente pointed out CGO_CFLAGS is still needed for FORTIFY_SOURCE, so for the sake of completeness it's all listed.
I have also removed `-mod=vendor` from the default listing in `prepare()` as Anatol wasn't fond of the idea. I'm still unsure if we really want this as we would be willynilly downloading sources in `build()` and `check()` during packaging.
My concern was related to use of vendorized sources. "-vendor" was not created for the cache management. If one wants to warmup the gomodules download cache then "go mod download" should be used. See more info about this tool here https://github.com/golang/go/issues/26610
And if we plan to encourage adding the cache warmup to all golang PKGBUILD (that's gonna be thousands of packages) then this extra complexity need be justified. Anyone who wants to follow our advise needs to have clear answers to following questions: Is this feature solely to avoid the download during the build() step or there is something else? Why downloading in build() is bad, does it hurt the users? What use-cases does show an advantage of the cache warmup.. etc..
On 4/30/20 3:56 AM, Anatol Pomozov via arch-dev-public wrote:
Thank you for coming up with this document.
Go is a fantastic language and I would love to see more people using it. Having things documented will help our users to get more comfortable with the golang packaging.
This RFC is about packaging code, not encouraging people to use a particular language when writing their next big project. :p Let's focus on that.
My concern was related to use of vendorized sources. "-vendor" was not created for the cache management. If one wants to warmup the gomodules download cache then "go mod download" should be used. See more info about this tool here https://github.com/golang/go/issues/26610
And if we plan to encourage adding the cache warmup to all golang PKGBUILD (that's gonna be thousands of packages) then this extra complexity need be justified. Anyone who wants to follow our advise needs to have clear answers to following questions: Is this feature solely to avoid the download during the build() step or there is something else? Why downloading in build() is bad, does it hurt the users? What use-cases does show an advantage of the cache warmup.. etc..
I'd like to elaborate on this again. Because I don't either understand what the initial purpose of this RFC suggestion was.
Why does it matter to makepkg how the go compiler downloads source code, or using which options? Any download that is done outside the source=() array is violating the PKGBUILD contract, and is not cached in $SRCDEST. It is therefore not persisted between successive clean chroot builds since those use a temporary $HOME and $BUILDDIR which is deleted between uses. And regardless of any other factors, it will not be able to work if the makepkg tool is executed in an environment where the network has been disabled.
So, we don't get caching and we don't get offline builds. That's beyond question.
What is the intended goal anyone intends to solve by warming up the gomodules download cache, precisely?
On Thu, Apr 30, 2020 at 04:58:01PM -0400, Eli Schwartz via arch-dev-public wrote:
Why does it matter to makepkg how the go compiler downloads source code, or using which options? Any download that is done outside the source=() array is violating the PKGBUILD contract, and is not cached in $SRCDEST. It is therefore not persisted between successive clean chroot builds since those use a temporary $HOME and $BUILDDIR which is deleted between uses. And regardless of any other factors, it will not be able to work if the makepkg tool is executed in an environment where the network has been disabled.
Sure, any code downloaded outside of source violates the farily vague PKGBUILD contract. However, if TU candidate starts using `patch` or `git submodule` in either `build` or `check` you are going to raise an eyebrow. And you are most likely going to say they need to go into `prepare`.
Source code modification doesn't belong in pkgver, build, nor check, nor package. So why is Go, and it's silly compiler, an exception?
So, we don't get caching and we don't get offline builds. That's beyond question.
One ecosystem gets closer to the goal. That is good enough, isn't it?
On Thu, Apr 30, 2020 at 12:56:30AM -0700, Anatol Pomozov via arch-dev-public wrote:
And if we plan to encourage adding the cache warmup to all golang PKGBUILD (that's gonna be thousands of packages) then this extra complexity need be justified. Anyone who wants to follow our advise needs to have clear answers to following questions: Is this feature solely to avoid the download during the build() step or there is something else? Why downloading in build() is bad, does it hurt the users? What use-cases does show an advantage of the cache warmup.. etc..
There are something like 140 packages using go today in our repositories today, there is no need for some grand justification. The justification, if anything is needed, is this RFC alone and the fact we should strive to follow the packaging guidelines when applicable.
Yo!
After another few lazy weeks I have finished up the new Go packaging guidelines.
https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines#F...
The changes that has been done since last time is some structing of the page, added a list explaining all the flags that have been added to `GOFLAGS`, and the addition of `-mod=readonly`.
The intention of adding this flag is to prevent Makefiles or build systems to silently modify the lockfile of the source code after checkout. This is to ensure reproducible build.
If there are no objections, I'll probably merge the guidelines this weekend section-by-section to make the wiki admins happy. The new package should land sometime nextweek.
At the end of the month I'll make a todo with the remaining packages depending on `go-pie`.
The complete future Go PKGBUILD is attached to this email below.
On 5/13/20 4:16 PM, Morten Linderud via arch-dev-public wrote:
The complete future Go PKGBUILD is attached to this email below.
``` replaces=(go-pie) provides=(go-pie) ```
Should this provide it too? Anything that explicitly expected go-pie cannot assume the new package is a drop-in replacement, it will need changes for the flags and can, at the same time, swap out the requirement for go-pie.
Yes, this would mean any PKGBUILD which makedepends on it needs to be updated immediately or fail to rebuild.
On Wed, May 13, 2020 at 04:35:11PM -0400, Eli Schwartz via arch-dev-public wrote:
On 5/13/20 4:16 PM, Morten Linderud via arch-dev-public wrote:
The complete future Go PKGBUILD is attached to this email below.
replaces=(go-pie) provides=(go-pie)Should this provide it too? Anything that explicitly expected go-pie cannot assume the new package is a drop-in replacement, it will need changes for the flags and can, at the same time, swap out the requirement for go-pie.
Yes, this would mean any PKGBUILD which makedepends on it needs to be updated immediately or fail to rebuild.
`go-pie` never provided PIE nor Full RELRO without the appropriate flags. Nothing is really lost by simply replacing and providing it.
On 5/13/20 10:16 PM, Morten Linderud via arch-dev-public wrote:
If there are no objections, I'll probably merge the guidelines this weekend section-by-section to make the wiki admins happy. The new package should land sometime nextweek.
Awesome, thanks a lot this is a great step to improve the security of Go applications on a binary level.
At the end of the month I'll make a todo with the remaining packages depending on `go-pie`.
The complete future Go PKGBUILD is attached to this email below.
PS: shouldn't we look into Go getting those flags as well? The Go compiler itself doesn't have RELRO and fortified sources :)
cheers, Levente
On Thu, May 14, 2020 at 09:39:58AM +0200, Levente Polyak via arch-dev-public wrote:
At the end of the month I'll make a todo with the remaining packages depending on `go-pie`.
The complete future Go PKGBUILD is attached to this email below.
PS: shouldn't we look into Go getting those flags as well? The Go compiler itself doesn't have RELRO and fortified sources :)
Because everything, sadly, breaks. I'd much rather try look into reproducibility before actually caring about binary hardening.
If we PIE compile the test suite upstream fails quite badly. Evidently upstream doesn't test the go compiler with PIE/RELRO enabled. Unsure if they care at all even. If we also try define `CGO_CFLAGS` we end up with errors like:
/usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
`-buildmode=pie` is also going to land you in trouble with the race detection in their test suite.
So not quite there yet for the compiler itself.
On 5/14/20 9:46 AM, Morten Linderud wrote:
On Thu, May 14, 2020 at 09:39:58AM +0200, Levente Polyak via arch-dev-public wrote:
At the end of the month I'll make a todo with the remaining packages depending on `go-pie`.
The complete future Go PKGBUILD is attached to this email below.
PS: shouldn't we look into Go getting those flags as well? The Go compiler itself doesn't have RELRO and fortified sources :)
Because everything, sadly, breaks. I'd much rather try look into reproducibility before actually caring about binary hardening.
If we PIE compile the test suite upstream fails quite badly. Evidently upstream doesn't test the go compiler with PIE/RELRO enabled. Unsure if they care at all even. If we also try define `CGO_CFLAGS` we end up with errors like:
/usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
`-buildmode=pie` is also going to land you in trouble with the race detection in their test suite.
So not quite there yet for the compiler itself.
/o\ @ upstream
not sure what else to say :P
If you wanna take an adventure in the future, feel invited to ping me for the ultimate quest to explore the rabbit hole in detail and maybe at least get RELRO or something.
cheers, Levente
On Wed, May 13, 2020 at 10:16:38PM +0200, Public mailing list for Arch Linux development wrote:
Yo!
After another few lazy weeks I have finished up the new Go packaging guidelines.
https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines#F...
The changes that has been done since last time is some structing of the page, added a list explaining all the flags that have been added to `GOFLAGS`, and the addition of `-mod=readonly`.
The intention of adding this flag is to prevent Makefiles or build systems to silently modify the lockfile of the source code after checkout. This is to ensure reproducible build.
If there are no objections, I'll probably merge the guidelines this weekend section-by-section to make the wiki admins happy. The new package should land sometime nextweek.
At the end of the month I'll make a todo with the remaining packages depending on `go-pie`.
The complete future Go PKGBUILD is attached to this email below.
-- Morten Linderud PGP: 9C02FF419FECBE16
Awesome! Thank you so much for your effort Morten.
Chris
On Wed, May 13, 2020 at 10:16:43PM +0200, Morten Linderud wrote:
If there are no objections, I'll probably merge the guidelines this weekend section-by-section to make the wiki admins happy. The new package should land sometime nextweek.
It's been done. `go-pie` is no more.
Please look over the new guidelines when you are packaging new stuff and do update your packages before the todo arrives at the end of the month.
https://wiki.archlinux.org/index.php/Go_package_guidelines
arch-dev-public@lists.archlinux.org