> That is good to know, assuming that the newer hypothetical toolchain is not vulnerable (e.g. a zero-day in the newer toolchain).

This would still be really difficult to explore:

    0. An undiscovered zero-day in the newest version of Go
    1. The only way to force users to use the newest toolchain is if your project has dependencies where the attacker has control, so e.g.: they can change their go.mod and set a `go` directive that upgrades to the later version
    2. You need to update to this new version, because this will make Go complain that your `go` directive inside your `go.mod` is out-of-date
    3. After all this, yes, Go will download the newest version of Go (that is vulnerable)

But I would argue if the attacker already has 2, they have better ways to attack you (e.g.: they can add code to `init()` that will run once the module is imported, and this could be explored once you build and run the binary).

Again, not saying that this is an impossible scenario, just find it highly unlikely.

> This could be a configuration setting that the developer has opted-in or a "This package requires toolchain version X. Install it? (y/n)" prompt.

I concur at this part though, however keep in mind that this `toolchain` feature is more akin to adding a module dependency, since it reuses the whole module system.

I think there is already lots of trust that is implicit when you are managing modules, and this new feature doesn't make it worse. If anything, considering that the binaries can only come from golang.org/toolchain and I assume Go already check the checksum of every module that it downloads (and also that Go is perfectly reproducible: https://go.dev/blog/rebuild), if anything this is probably more trusted than a random module that you add to your project.