They're the same toolchains. They're hashed and downloaded as part of do-fetch, from the same servers that Go itself is distributed, so theoretically they should carry the same risk as the Go ports.

Does this option also prevent it from behaving like an older version of the toolchain, or does it only affect forward behaviour?

Sorry about the really long silence there. I rolled this into today's updates to go124 and go123. I opted not to change anything lower than that because those ports are EOL upstream and shouldn't exist (it's my fault that they still do). Thank you for submitting this!

In D50595#1155305, @mengzhuo1203_gmail.com wrote:

Thanks for review,
This change only affect download source code and binary for go itself.
The https://golang.org/dl/*.src.tar.gz redirect (HTTP 301) to go.dev/dl then Google blob file server.

Other golang.org namespace library (golang.org/x) won't change AFAIK.

Good catch! I'm definitely in favor of switching, but:

In D49906#1153054, @kbowling wrote:

Is there a way to vendor the alt toolchains? It is imperative this doesn't start downloading from the internet outside of the fetch step, the same standards things like Cargo, Maven, etc have in ports. As long as that is addressed I think the overall concept is fine now -- it will be awkward if we have to patch Go but hopefully that is not common.

In D49906#1152227, @fuz wrote:

The best way would be to set GOTOOLCHAIN=local when building Go ports, which disables the “fetch the appropriate toolchain” mechanism. This makes it impossible to build Go ports requiring too new toolchains, but then perhaps there's more of an incentive to have them packaged quickly.

In D49906#1151683, @fuz wrote:

If the test build shows that none of the ports fail with a more recent toolchain, I'm okay with only providing it. But what we must disable in the ports tree is the mechanism where Go tries to download a newer toolchain if it considers itself outdated. Downloading random toolchains at fetch time is not what we should be doing.

So, I should have tagged this review in the commit, but I set go124 as the default as portmgr/pkgmgr seems to be swamped at the moment. Once we see how things build, we'll have a better picture of whether this will be a viable thing.

In D49906#1138522, @fuz wrote:

I disagree with this step.

We should instead disable the feature where Go tried to download a toolchain and have Go err out instead. This can be achieved by setting GOTOOLCHAIN=local in the environment. Packages should always be built with our own toolchain, not the one provided by Google. The downloaded toolchain has none of our site patches, is outside of our control and we don't do this sort of thing anywhere else.