go: Force using current toolchain

[dan.mcgregor_usask.ca]

Summary

The go toolchain recently grew support for automatically downloading
the desired toolchain version. This hides go version requiremets when
they change on us between versions. Disable this functionality to
force using our preferred toolchain with no surprises.

As-is this absolutely will break things. The idea is to prevent a port
from automatically downloading and using a newer toolchain during the
build. Follow up commits will be required for multiple Go ports to set
the required version properly.

[dan.mcgregor_usask.ca]

This is mostly to show the issue. I think this is the right track, but a complete solution would support a minimum go version rather than setting an exact version.

[adamw]

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

But also, Go built a thing so that you can pick either of the two Go stable versions, and be confident that you will be able to compile software that depends on either's feature set. Go is now designed so that you only ever need one version of Go installed. I recognize that that's not the typical FreeBSD paradigm, but I'm also unsure why we should intentionally break a major feature of modern Go.

And I mean that literally: I am unsure why this is the better approach. You're definitely not the only person who's suggested it, so I'd really like to hear the arguments for it.

And yes, it's only addressing one component of what the end product will need to be to support that, but once the approach is ironed out the rest of the pieces will come together.

[ngie]

Supply chain attacks and repeatability seems like the biggest concerns I'd see with not using the locally provided toolchains.

[adamw]

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.

I guess what I'm suggesting here is that if the toolchain tarball is under attack, then so is the distfile we'd use to build the Go port. You're definitely NOT wrong about the risk there, but I'm not seeing how falling back to the Go port mitigates it.

[ngie]

In D53459#1221655, @adamw wrote:

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.

I guess what I'm suggesting here is that if the toolchain tarball is under attack, then so is the distfile we'd use to build the Go port. You're definitely NOT wrong about the risk there, but I'm not seeing how falling back to the Go port mitigates it.

The difference is the layer at which things can be mitigated against: if somehow the upstream go project is attacked, not using the local toolchain could result in compromised systems, whereas updating the distfile checksum by a human in the FreeBSD project could potentially help detect tampering and prevent a tampered payload from being used.

Also, not all sites allow downloading from external sources... if there isn't a way to disable or configure the host that one needs to download from, that would be a problem for those end-users of FreeBSD.

[ngie]

At the very least I think it's a good idea to either document what the variable does, or make it into a first-class customizable flag.