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
cmd/go: load $GOROOT/go.env before loading user go.env #57179
Comments
naming it |
They could come to that wrong conclusion with any filename, I think :) Even with I personally think proper docs would be enough. This would realistically only appear in downstream Go distributions and packages, and in general, users wouldn't go look inside GOROOT directly. |
Perhaps we should accept a go.env in the work module or next to go.work as well. There have been various issues asking for per-module configuration in go.mod. Go.mod is not the right place for that, which is why those were declined, but if we already have the search order $GOROOT/go.env, $userconfigdir/go.env, it might make sense to insert $workdir/go.env between them, where $workdir is the directory containing the go.work (if any) or else the one containing the work module's go.mod. Of course, go.env would only apply in the work module and would be ignored in dependencies. There are security concerns to think through for people who clone other repos and then open them in editors. We'd also have to decide what GOENV means and especially what GOENV=off means. This would address:
In #57001, there is some complication due to having both the |
This proposal has been added to the active column of the proposals project |
The reactions here are uniformly positive. Does anyone object to accepting this proposal? |
Hi Russ, minor clarification -- is a module/workspace go.env as described above in #57179 (comment) currently considered part of this proposal, or is that just a possible future extension? |
I think the work module go.env #57179 (comment) should be a separate proposal. Introducing
|
Thanks @hyangah. I started answering these questions but there are too many significant problems with the per-module go.env that don't arise with the $GOROOT/go.env. Let's keep this proposal scoped to just the $GOROOT/go.env. The $GOROOT/go.env source is an alternative to editing the source code to change the hard-coded defaults, so that's less of a change. |
Marking this likely accept but only for $GOROOT/go.env, not a per-module go.env. |
Based on the discussion above, this proposal seems like a likely accept. |
Change https://go.dev/cl/462198 mentions this issue: |
I confused myself and submitted this before it was accepted. Reopening. |
No change in consensus, so accepted. 🎉 |
Done. |
Is there a write-up of the issues with a per-module or per-workspace go.env? That seems like it would be helpful in Kubernetes, especially once we adopt go workspaces fully. Our need for wrapper scripts will approach zero. |
Change https://go.dev/cl/497437 mentions this issue: |
As part of the work for #57179 we moved configurable defaults to GOROOT/go.env, so that packagers don't have to modify source code to change those defaults. Since packagers may want to modify GOTOOLCHAIN's default, move it to go.env too. This CL modifies 'go env' to print GOTOOLCHAIN by default. It also refines CL 496957 from yesterday to recognize any env var in either go.env or the user go/env, not just the user go/env. When I put GOTOOLCHAIN in go.env, but before I added it to the default printing list, 'go env GOTOOLCHAIN' was printing an empty string, and it was incredibly confusing. For #57001. Fixes #60361 while we're here. Also includes a fix for a review comment on CL 497079 that I forgot to mail. Change-Id: I7b904d9202f05af789aaa33aed93f903b515aa28 Reviewed-on: https://go-review.googlesource.com/c/go/+/497437 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Russ Cox <rsc@golang.org>
I was trying to integrate this new feature in Fedora when I found that vcs-test.golang.org rerouted to http://127.0.0.1:33295
https://vcs-test.golang.org rerouted to https://127.0.0.1:42771
go test proxy running at GOPROXY=http://127.0.0.1:32775/mod
--- FAIL: TestScript (0.18s)
--- FAIL: TestScript/mod_sumdb_golang (0.06s)
script_test.go:132: 2023-06-30T17:21:00Z
script_test.go:134: $WORK=/tmp/cmd-go-test-2792608462/tmpdir2295187342/mod_sumdb_golang511923858
script_test.go:156:
# Test default GOPROXY and GOSUMDB (0.056s)
> env GOPROXY=
> env GOSUMDB=
> go env GOPROXY
[stdout]
direct
> stdout '^https://proxy.golang.org,direct$'
script_test.go:156: FAIL: testdata/script/mod_sumdb_golang.txt:5: stdout ^https://proxy.golang.org,direct$: no match for `(?m)^https://proxy.golang.org,direct$` in stdout
FAIL
FAIL cmd/go 49.471s At first I thought it was something in the isolated Fedora's build environment but I was able to reproduce this in a fresh machine by just cloning go, setting Is this expected? Is this new feature not meant to be used during testing and only after everything has passed? |
See golang/go#57179 for context. Signed-off-by: Jon Johnson <jon.johnson@chainguard.dev>
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
How is directly downloading the binaries exposing users more than trusting |
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
What if the source repository had logic that looked (roughly) like this:
With With |
* New upstream release. * Include temporary fix for default environment variables[0]. [0]: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
fix build error: "GOPROXY list is not the empty string, but contains no entries" see: golang/go#57179
I've been looking at the patches that distributions apply to Go. We'd like to remove as many as possible, so that once reproducible builds land (#24904, #57007), Linux distributions that rebuild from source should still be shipping the identical binaries that are distributed on https://go.dev/dl.
Debian patches are here: https://sources.debian.org/patches/golang-1.15/1.15.15-1~deb11u4/
Fedora patches are here: https://src.fedoraproject.org/rpms/golang/tree/rawhide
Debian's are all test changes. Fedora has one non-test change in cmd/link that maybe we should pick up if gcc has been fixed. Fedora also changes the default values for GOPROXY and GOSUMDB. Setting aside the fact that they are opening their users to supply chain attacks, it would be good if they didn't have to modify the binaries to do it. We also expect over on #57001 that Fedora will want to default GOTOOLCHAIN=local, and perhaps Debian will too.
Today the default Go environment variables are modified using 'go env -w' which writes to filepath.Join(os.UserConfigDir(), "go/env"). On my Mac that's
$HOME/Library/Application Support/go/env
. On Linux that's$HOME/.config/go/env
.I propose that when the go command loads that file, it first loads $GOROOT/go.env and then the user file. Any setting in the user file overwrites an equivalent setting in the $GOROOT/go.env, and the environment overwrites both (as always).
Then distributions that want to modify the defaults do not need to edit source code and create non-standard binaries. They can just write a $GOROOT/go.env.
The text was updated successfully, but these errors were encountered: