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.

Sign up for GitHub

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

Jump to bottom

cmd/dist: build cmd with CGO_ENABLED=0, so cmd/go uses pure Go net resolver #57007

Closed
rsc opened this issue Nov 30, 2022 · 12 comments
Closed

cmd/dist: build cmd with CGO_ENABLED=0, so cmd/go uses pure Go net resolver #57007

rsc opened this issue Nov 30, 2022 · 12 comments
Assignees
@rsc
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Linux
Milestone
Go1.21

Comments

@rsc
Copy link
Contributor

rsc commented Nov 30, 2022

Now that we've removed the .a files from the distribution, the only possible leakage of the host build environment into Go Linux releases is the dynamic libc.so.6 path embedded in the command binaries that use the network (only bin/go and pkg/tool/goos_goarch/pprof, I believe).

I wonder whether we should build cmd with CGO_ENABLED=0 so that we end up with purely static cmd/go and cmd/pprof binaries. This would apply to all systems, but since we are planning to cross-compile non-Linux distributions and Mac and Windows don't use cgo anyway for net, the only effect would be on Linux.

We default to the cgo-based net so that people with strange /etc/resolv.conf can still resolve the names they need to resolve. But perhaps that is more for local names like mDNS and such rather than the standard internet names that cmd/go needs.

Does anyone see anything that would break if we made the go command always use the pure Go net resolver?
@rsc rsc changed the title cmd/dist: build cmd with CGO_ENABLED=0 cmd/dist: build cmd with CGO_ENABLED=0, so cmd/go uses pure Go net resolver Nov 30, 2022
@rsc rsc mentioned this issue Nov 30, 2022
Closed
@bcmills
Copy link
Contributor

bcmills commented Dec 1, 2022

Would this cause go install cmd to install a different cmd/go from what make.bash produces?
That might be ok, but we would probably at least have to update some tests that assume it is a no-op.

(But it also might provide a reasonable workaround for folks who want a cmd/go that uses the C resolver.)

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 1, 2022
@bcmills bcmills added this to the Backlog milestone Dec 1, 2022
@rsc
Copy link
Contributor Author

rsc commented Dec 2, 2022

Would this cause go install cmd to install a different cmd/go from what make.bash produces?
That might be ok, but we would probably at least have to update some tests that assume it is a no-op.

Yes, and agreed.

@rsc rsc self-assigned this Dec 2, 2022
@rsc rsc modified the milestones: Backlog, Go1.21 Dec 2, 2022
@rsc
Copy link
Contributor Author

rsc commented Dec 3, 2022

With a little more work this lets us build completely reproducible distributions, where it doesn't matter which OS the distribution was built on at all. In particular they could all be built on a single trusted system. CL 454836 does this.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/454836 mentions this issue: cmd/dist: make toolchain build reproducible

@mateusz834
Copy link
Member

mateusz834 commented Dec 4, 2022 •
edited
Loading

We default to the cgo-based net so that people with strange /etc/resolv.conf can still resolve the names they need to resolve. But perhaps that is more for local names like mDNS and such rather than the standard internet names that cmd/go needs.

I don't think that resolv.conf might be a problem, go 1.20 supports most options that are used in the wild.

Does anyone see anything that would break if we made the go command always use the pure Go net resolver?

Some users might have problem because of /etc/nsswitch.conf, when we compiled without cgo we default to files,dns order, we don't even parse that file.

Recently the nsswitch.conf (hosts database) on glibc-based linux systems becomes more and more bloated. We should be careful with this.

@rsc
Copy link
Contributor Author

rsc commented Dec 5, 2022

In what circumstances would nsswitch.conf be needed to resolve public internet names like github.com or proxy.golang.org?

@mateusz834
Copy link
Member

mateusz834 commented Dec 5, 2022 •
edited
Loading

In what circumstances would nsswitch.conf be needed to resolve public internet names like github.com or proxy.golang.org?

Glibc uses nsswitch.conf to resolve all names. Recently linux distros (desktop) started adopting systemd-resolve nss module, instead of a dns one, so that the dns module is not even used to resolve hostnames, the dns queries are send by the systemd-resolved deamon.
I mean if we change the go binary to use netgo by default, then probably nothing will break, but we don't know how the nsswitch.conf configurations might evolve in the future.

Edit: but on non-glibc systems (without nsswitch.conf support in libc) the go resolver will be fine, so for alpine and other musl based distros.

@rsc
Copy link
Contributor Author

rsc commented Dec 5, 2022

I guess we will find out - there are enough upsides to this change, including cross-compiled reproducible builds, that I think we owe it to ourselves to try it in Go 1.21 and find out whether there are any show-stoppers.

This was referenced Dec 6, 2022
Closed
Closed
@bcmills
Copy link
Contributor

bcmills commented Dec 15, 2022 •
edited
Loading

#57328 is an interesting data point here too. There, a user is reporting that building a cgo-enabled dynamically-linked binary on an Ubuntu with a newer glibc causes that binary to fail to run on a system with an older glibc.

That seems to imply that if we build a cgo-enabled cmd/go against a recent glibc and include it in a Go release, it will similarly fail to run on an older system. But we probably also don't want to build our releases on ancient versions of our supported platforms just to improve the glibc compatibility of the resulting binaries.

Building the release with CGO_ENABLED=0 nicely sidesteps that problem, allowing Go releases to be built on more up-to-date platforms.

@seankhliao
Copy link
Member

failures due to glibc versions were also seen a long time ago in #5203

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/461689 mentions this issue: cmd/go: do not attempt to install cmd/addr2line in TestScript/mod_outside

gopherbot pushed a commit that referenced this issue Jan 18, 2023
@gopherbot
cmd/go: do not attempt to install cmd/addr2line in TestScript/mod_out…
2e792a8 
…side

Tests must not write to GOROOT: it might not writable (for example, if
it is owned by root and the user is non-root), and in general we can't
assume that the configuration in which the test is run matches the
configuration with which the installed tools were built.

In this specific case, CL 454836 (for #57007) installs 'cmd' with
CGO_ENABLED=0, but most builders still run the tests with CGO_ENABLED
unset.

Updates #57007.

Change-Id: I2795fcd3ff61c164dc730b62f697f307ab3a167b
Reviewed-on: https://go-review.googlesource.com/c/go/+/461689
Reviewed-by: Cherry Mui <[email protected]>
Run-TryBot: Bryan Mills <[email protected]>
Auto-Submit: Bryan Mills <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/463739 mentions this issue: cmd/dist: leave cgo enabled if external linking is required

gopherbot pushed a commit that referenced this issue Jan 31, 2023
cmd/dist: leave cgo enabled if external linking is required
da0c375 
Certain ios and android configurations do not yet support internal
linking.

On ios, attempting to build without cgo causes tests to fail on
essentially every run (#57961).

On android, it produces a lot of warning spam from the linker,
obscuring real problems.

Since external linking makes the result of `go install` depend on the
installed C toolchain either way, the reproducibility benefit of
disabling cgo seems minimal on these platforms anyway.

Fixes #57961.
For #24904.
Updates #57007.

Change-Id: Ied2454804e958dd670467db3d5e9ab50a40bb899
Reviewed-on: https://go-review.googlesource.com/c/go/+/463739
Reviewed-by: Russ Cox <[email protected]>
Run-TryBot: Bryan Mills <[email protected]>
Auto-Submit: Bryan Mills <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
TryBot-Bypass: Bryan Mills <[email protected]>
johanbrandhorst pushed a commit to Pryz/go that referenced this issue Feb 12, 2023
@johanbrandhorst
cmd/dist: leave cgo enabled if external linking is required
2719f41 
Certain ios and android configurations do not yet support internal
linking.

On ios, attempting to build without cgo causes tests to fail on
essentially every run (golang#57961).

On android, it produces a lot of warning spam from the linker,
obscuring real problems.

Since external linking makes the result of `go install` depend on the
installed C toolchain either way, the reproducibility benefit of
disabling cgo seems minimal on these platforms anyway.

Fixes golang#57961.
For golang#24904.
Updates golang#57007.

Change-Id: Ied2454804e958dd670467db3d5e9ab50a40bb899
Reviewed-on: https://go-review.googlesource.com/c/go/+/463739
Reviewed-by: Russ Cox <[email protected]>
Run-TryBot: Bryan Mills <[email protected]>
Auto-Submit: Bryan Mills <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
TryBot-Bypass: Bryan Mills <[email protected]>
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 16, 2023
@eliasnaur eliasnaur mentioned this issue May 13, 2023
Closed
@mjl- mjl- mentioned this issue Jun 12, 2023
Closed
@tianon tianon mentioned this issue Jul 11, 2023
Merged
malt3 added a commit to edgelesssys/constellation that referenced this issue Jan 5, 2024
@malt3
bazel: use prebuilt Go toolchain (go.dev/dl)
853a455 
We had to switch to a Go toolchain from nixpkgs,
since prebuilt Go toolchain versions were not usable on NixOS.
Since Go 1.21, the prebuilt Go toolchain is statically linked
and works out of the box.

Reference: golang/go#57007
@malt3 malt3 mentioned this issue Jan 5, 2024
Merged
4 tasks
malt3 added a commit to edgelesssys/constellation that referenced this issue Jan 5, 2024
@malt3
bazel: use prebuilt Go toolchain (go.dev/dl) (#2796)
3a4f6ef 
We had to switch to a Go toolchain from nixpkgs,
since prebuilt Go toolchain versions were not usable on NixOS.
Since Go 1.21, the prebuilt Go toolchain is statically linked
and works out of the box.

Reference: golang/go#57007
@golang golang locked and limited conversation to collaborators Apr 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@rsc rsc

Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Linux
Projects
None yet
Milestone
Go1.21
Development

No branches or pull requests
6 participants
@rsc @dmitshur @bcmills @gopherbot @seankhliao @mateusz834