Golang cmd/go: defensively unset dangerous VCS configuration options

Related to #74380.

The Go toolchain will invoke VCS commands in some situations in order to learn about the current state of a module, and in some circumstances embed information about said state in binaries.

In https://go.dev/cl/686515 we protected against the scenario where multiple VCS appeared to be present in order to prevent attacks wherein one VCS was used to retrieve a module which contained configuration metadata for another VCS. This change doesn't protect against the scenario where a module is retrieved using another non-VCS, non-toolchain method, such as downloading an archive file, which may contain malicious VCS configuration information.

There is no way for the toolchain to know if the VCS metadata in a module directory is safe or unsafe, and we currently assume that the user controls, and trusts, said directory for the purposes of invoking VCS commands.

One possible solution to this is to attempt to defensively unset certain VCS configuration options when invoking VCS commands (such as the Git core.fsmonitor option), in order to prevent the toolchain for executing unexpected commands when operating in untrusted directories.

Enumerating the list of dangerous VCS configuration options is likely to be a significant amount of work, and keeping it up to date is equally complex (not all that dissimilar to the dangerous CGO compiler/linker option disallow list we maintain.) Additionally, in trusted directories, unsetting some of these options may result in performance degradations, or other unwanted behavior. Because of this we'd likely want to introduce a GODEBUG that allows disabling this behavior.

cc @golang/command-line @golang/security

Comment From: ianlancetaylor

Enumerating the list of dangerous VCS configuration options is likely to be a significant amount of work, and keeping it up to date is equally complex (not all that dissimilar to the dangerous CGO compiler/linker option disallow list we maintain.)

Note that we don't maintain a compiler/linker disallow list, which would indeed be quite complex. We maintain an allow list, which is much simpler. We only list options that we know are safe. We add more safe options as people complain. We support a workaround for users via the CGO_CFLAGS_ALLOW environment variable, which permits adding additional options to the allow list.

Comment From: rolandshoemaker

Ah yes, that is correct. My memory of the list was reversed. I don't think we can do the same (an allow list) without parsing out the VCS configuration, which I don't think we want to do, so we'd be forced to do the inverse (a disallow list), which seems like a very daunting task.