Description
Many of VS Code Go settings are defined as resource or machine-overridable scope configuration, which means they can be specified in the workspace or folder levels. Some of the settings, for example, "go.goroot", "go.alternateTools", "go.gopath", "go.toolsGopath", "go.inferGopath", ... can affect the location of tools and binaries the extension runs. While this is convenient (*), it also can be exploited to run any binaries on users' machines once if the users are tricked to check out a random repository with workspace settings and open it with vscode.
This vulnerability issue around workspace/folder level settings is not new:
typescript.tsdkhas been switched to ignore the workspace-level setting by default in 2017 (typescript.tsdk "must be a user setting" microsoft/vscode#19451)- Python has been transitioning out of
python.pythonPath - 'git.path', 'terminal.external.*' as explained in the vscode doc
While hoping to have a unified approach for this class of issues eventually, we want to address this issue from our extension now.
When opening workspace/folder-level configuration for those settings, the extension will ignore them by default and warn users. If users trust the workspace, they can explicitly tell the extension by running a command.
The affected settings (**) are:
- go.goroot
- go.gopath
- go.toolsGopath
- go.inferGopath
- go.alternateTools
- go.toolsEnvVars
cc @FiloSottile @rsc @suzmue @pjweinb @stamblerre
*: when we previously tried to convert some of those settings to machine scope ones for different reasons, the change broke many users' workflow and had to be reverted.
**: should we include all the settings by default to be safe? (there could be more settings that can be potentially exploitable...)
We will consider adding restrictions to additional settings like go.testOnSave.