Re: Bug#1040507: Default GOTOOLCHAIN value in Go1.21
On Wed, 2 Aug 2023 at 21:39, Shengjing Zhu <zhsj@debian.org> wrote:
> 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
Reply to: