-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debian packages must also be build as PIE #120
Comments
Why does it "must be"? What problem do you have? |
Current linux distributions have at least all the network-exposed services completely built as PIE. |
Is it probably more relevant to C/C++ than Go? Ian Lance Taylor seems to think building Go programs in PIE mode doesn't add much advantage given the memory safety promises Go offers out of the box: |
The upstream go compiler may also generate TEXTRELs on this default mode..(non-pic) even in code you do not directly control (at least it did the last time checked) and this does not play well with selinux and other security frameworks. |
Why would that matter for Debian-based distros? I don't understand what benefit we'd get here. We've never had complaints about this before. |
You will not hear complains because distributions are gonna build their stuff by themselves with the appropiate flags.. -buildmode=pie is the default on arch, alpine, fedora, rhel, opensuse, sle.. |
Fair enough. But I don't feel comfortable making this change without understanding the implications. We need a good reason to do it, not "just because". What practical benefits would this have? Is there an actual problem this would solve for you? Why are you bringing this up? You must have had a reason to have looked into it. |
I, too, would like more information. I don't know the pros/cons, the actual need for this, etc etc. |
I'm not an expert on this topic, but the Fedora packaging guidelines do have a short explanation of the value of PIE. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie Based on the discussion that @mohammed90 linked, while it does sound like this is more beneficial for languages like C, it "is not completely useless for Go". If there are no known drawbacks, this sounds like a reasonable change to me. |
After some research, I prefer to not go down that road. Go's internal linker does not support PIE on all platforms (code). On platforms where the internal linker does not support PIE, it requires usage of external linker, bringing CGO into the table (golang/go#64875). We disable CGO in our build process. Others who went down this route opted to internalize the logic of the linker's supported platform into their own build process (elastic/beats#24964, k8s enables CGO kubernetes/kubernetes#102323). I don't find it desirable to chase the moving target of Go's internal linker support of PIE. Debian does not enable PIE by default due to reported build failures, though that may be due to C/C++ ecosystem. The Go team has defaulted to building PIE binaries on Windows (and I believe on darwin/arm64 as well) because its guaranteed to not fail, matching general expectations, and argument for them were well-reasoned to be a default for Go executables. I prefer deferring such default to them for when the linker is capable of handling it across all supported (or non-exotic) platforms. |
Given the additional complexity to our build process the unknowns of the potential failure modes (there's at least one reported to the Go repo on mips), we prefer to stick to our current build mode. Those who feel strongly about PIE mode can build their own custom binaries using xcaddy with the env var We may revisit this in the future if the UX of PIE mode in the Go linker improves. |
Hi:
RPMs are correctly built using -buildmode=pie but not the debs, I couldn't find the debian package files on this repository to fix them by myself.
The text was updated successfully, but these errors were encountered: