Go 1.21 provides the `GOTOOLCHAIN` environment variable and associated
functionality[0].  As part of this code, if go.mod indicates that a
newer version of Go is required than the current toolchain supports, it
proceeds by default to attempt to download a toolchain from the Internet
and runs it without prompting the user.

It is unclear what, if any cryptographic verification it performs,
especially if the user has disabled GOPROXY and GOSUMDB for privacy
reasons.  As far as I know, the Go core team does not sign Linux
binaries cryptographically, so at best the data would be verified by a
hash, which is not sufficient.  Debian itself uses a strong
cryptographic signature for APT archives.

In addition, it's possible that a newer version of the toolchain might
contain some vulnerability which is not present in the current
toolchain, and therefore might expose the user to new vulnerabilities
that are not patched.  This is not at all far-fetched, since Go is known
to have regressions all the time, so security-based regressions are not
at all out of the question.

I don't believe this is an appropriate way for software distributed in
Debian to behave, especially by default, and I'd like to request that it
be patched out for security reasons.

Steps to reproduce:
1. Clone a Go project (e.g., Git LFS).
2. Update go.mod to state "go 1.22".
3. Run /usr/lib/go-1.21/bin/go build
4. Notice the following output:

go: downloading go1.22 (linux/amd64)
go: download go1.22 for linux/amd64: toolchain not available

[0] https://tip.golang.org/doc/toolchain

Thanks for filing this!  We'd discussed this on IRC a couple times,
but that's not terribly persistent.

I've filed an MR against the package on Salsa now that patches the
default from "auto" to "path" (which is like "local", but will accept
binaries like "goX.Y" in PATH, which IMO is a pretty reasonable
compromise for the original intent of the feature):

https://salsa.debian.org/go-team/compiler/golang/-/merge_requests/12

Ideally, I think we'd also couple this with including symlinks like
"/usr/bin/go1.21" in "golang-1.21-go", but I didn't go that far in
*this* MR.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Hi,

As Go1.21 is to be released recently, I'd like to know what value we
shall set for GOTOOLCHAIN env.

The default value is auto, which means it will download the newer
toolchain if go.mod ——_explicitly_ says so. See
https://go.dev/doc/toolchain for details.

Please be aware that it doesn't affect how we build Go packages, as
dh-golang will set GOTOOLCHAIN to local to prevent it from accessing
the network. So here we only discuss the user experience when using
the Go toolchain itself.

At #1040507, users are concerned if the downloaded binaries are
cryptographically verified. Yes, they are verified the same as Go
libraries. If you disable GOSUMDB, it will not be verified, but this
means all the Go libraries are not verified as well and we won't
disable that by default.

Users may have concerns about privacy, but there are already envs like
GOPROXY, which is set to https://proxy.golang.org. I don't see much
value to change GOPROXY to "off" or other values, as it really hurts
the development experience. So if users would change GOPROXY env for
privacy reason, I would expect them to change GOTOOLCHAIN as well.
(Actually if GOPROXY is set to off, go won't download newer
toolchains.)

Also I don't see much security concerns as if upstream does evil in
their binary releases I would be much concerned about their source
which is much harder to audit.

Another thought is we always release very old versions in Debian
stable. For example we just released Debian 12, which has Go1.19, but
Go1.19 is to be EOL in the next few weeks when Go1.21 is released.
Allowing Go to download a newer toolchain by default would just make
such an old version more useful...

I incline to leave the GOTOOLCHAIN value as is, any thoughts?

Now that we've had a couple years with the behavior, I'm *still* of
the opinion that we should be setting this value to either "local" or
"path" by default in our builds, as is suggested we might/will by
upstream in their documentation of the feature, and as I sent a Merge
Request implementing back in
https://salsa.debian.org/go-team/compiler/golang/-/merge_requests/12
-- whether we set it to "path" or not, we should probably also add the
GOTOOLCHAIN-satisfying aliases in each of our supported binary
packages in PATH ("go1.25.0", "go1.25", etc), which would be handy and
helpful regardless.

As additional justification, we have a number of Go packages in Debian
which do *not* use dh-golang for various reasons.

The behavior is invoked by an explicit choice, yes, but it's an
explicit choice by the author of "go.mod", *not* by the invoker of the
"go" toolchain, and that's really the crux of my disagreement with it.

I think we would all be justifiably up-in-arms if "gcc" grew some
behavior that when invoked would automatically download some newer
version of "gcc" that wasn't from Debian's builds / verified by
Debian's chain-of-trust based on the presence or value of some file
provided by whatever source was just checked out/extracted locally
without some explicit configuration from the operator/invoker as well.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4