On Wed, 2 Aug 2023 at 21:39, Shengjing Zhu <[email protected]> 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
