Skip to content
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

Closed
crrodriguez opened this issue May 1, 2024 · 11 comments
Closed

Debian packages must also be build as PIE #120

crrodriguez opened this issue May 1, 2024 · 11 comments
Labels
wontfix This will not be worked on

Comments

@crrodriguez
Copy link

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.

@francislavoie
Copy link
Member

Why does it "must be"? What problem do you have?

@crrodriguez
Copy link
Author

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.

@mohammed90
Copy link
Member

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:
https://groups.google.com/g/golang-nuts/c/cXhRsmNsMwo?pli=1

@crrodriguez
Copy link
Author

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.

@francislavoie
Copy link
Member

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.

@crrodriguez
Copy link
Author

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..
It is just the debian package distributed from your site are not.

@francislavoie
Copy link
Member

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.

@mholt
Copy link
Member

mholt commented May 2, 2024

I, too, would like more information. I don't know the pros/cons, the actual need for this, etc etc.

@carlwgeorge
Copy link
Collaborator

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.

@mohammed90
Copy link
Member

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.

@mohammed90
Copy link
Member

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 XCADDY_GO_BUILD_FLAGS to pass the -buildmode pie flag. Follow the instructions at the bottom of the Build From Source page on our documentation site for how to use custom binary along with the apt package.

We may revisit this in the future if the UX of PIE mode in the Go linker improves.

@mohammed90 mohammed90 added the wontfix This will not be worked on label May 20, 2024
@mohammed90 mohammed90 closed this as not planned Won't fix, can't repro, duplicate, stale May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

5 participants