Pinning Tools Versions #1850
Comments
|
Tools used by this extension also can't be tracked by systems such as GitHub's Vulnerable Dependencies Alerts since the tools aren't listed in a format that GitHub understands. Adding support for this (and/or other similar solutions) would partially alleviate this problem, then you maintainers would at least get notifications if something's gone wrong. |
|
The only tools that vscode-go auto-updates are gopls and dlv, and this can be turned off by setting: The updates that the extension prompts for are not required. We are also planning to remove the dependency on many of the third party tools to reduce this risk, replacing the functionality using |
|
That's good to know, thanks! I'll definitely be turning on that setting. I'm less but still slightly concerned that we can potentially pull compromised versions of the tools when installing this extension/first use. If a tool become compromised, any new installations would be compromised until this extension can respond, pin the version, and push the update to users. It seems unlikely, but our team uses containers that semi-often get blown away and require VSCode to re-install itself.
Is there any overarching tracking ticket for this that I can follow? |
|
In the mean time, feel free to pin the versions from the containers. As long as the container is reasonably updated (e.g. at least once a month :-) I think it should be ok. That's how major dev containers + web-based editor services host this extension. Except rare occasions like #1300, this extension does not actively break old tool users or assume the latest versions of tools. |
|
Change https://golang.org/cl/370414 mentions this issue: |
This reverts commit a1cc5e5 (https://go-review.googlesource.com/c/vscode-go/+/344789) and pins dlv-dap at go-delve/delve@2f13672 We removed pinning in a1cc5e5 because we were still actively developing Delve DAP and the pinning made it difficult for users to pick up the latest bug fixes. Now Delve DAP is stable and most critical features are ready. Let's pin the version again and prevent breakages. We don't update the latestVersion in this change - currently dlv-dap uses this as the minimum required version. Updates #1850 Updates #1661 Change-Id: Ib8af635f3ee431bffa1fc505f85c9a87604f8323 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/370414 Trust: Hyang-Ah Hana Kim <[email protected]> Reviewed-by: Polina Sokolova <[email protected]>
|
Change https://go.dev/cl/442786 mentions this issue: |
There is no v1.0.0 version. The tagging of go-outline project doesn't follow go modules versioning convention, so the release tag version is not recognized. Since we pinned the 3rd party tools versions after https://go-review.googlesource.com/c/vscode-go/+/435375 we also need to adjust the code path that pick the version of tools whose latest versions require go 1.18+ to build. Use Tool.defaultVersion only if we are handling these special cases. (gofumpt, golangci-lint, staticcheck) Also, set GOMODCACHE explicitly when interacting with the fake local proxy. When the test runs in an environment with GOMODCACHE is set, the test ends up polluting the specified GOMODCACHE with fake data from the local test proxy. Our intention was to use GOPATH[0]/pkg/mod as module cache during the test. Fixes #2485 Updates #1850 Change-Id: Iad6cb662f637d444b9a8047db2aa166965144db8 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/442786 Reviewed-by: Jamal Carvalho <[email protected]> Run-TryBot: Hyang-Ah Hana Kim <[email protected]> TryBot-Result: kokoro <[email protected]>
|
This is implemented. Closing. |
This extension uses multiple external tools which aren't managed by the Golang organization, which introduces a potential security vulnerability. If one of those tools gets compromised, everyone using the Go extension is at risk. Hijacking one of these tools could expose a LOT of private code to a potential supply chain attack or sensitive data exfiltration.
I understand the desire to leave tool version unpinned to fix bugs quickly, but would there be support for some kind of "safe mode" which explicitly pins the versions of tools not under Golang's direct control? This would come with the understanding that bugs are fixed more slowly and that the first suggestion to any bug report would be "try to repro using latest".
Unfortunately, even if VSCode supported pinning the Go extension, Go will still pull the latest tools from Github.
Users could manually install the required tools in their dev environment, pinning their version there, but then an update to the Go extension could break stuff. That would also shift the responsibility of matching versions to individual orgs who lack relevant context and would be unable to keep pace. This is especially true since we cannot pin the Go extension to a specific version through VSCode.
The text was updated successfully, but these errors were encountered: