x/tools/gopls: add conditional vulncheck IDE support
Introduction
There is an opportunity to provide proactive vulnerability scanning support via vulncheck in IDEs. Currently, this is disabled in gopls, but with advances in telemetry collection and intentional placement of tooling, we can create a pleasing and useful user experience.
Motivation
This initiative builds upon the findings presented in a UX study conducted to assess the usability of vulncheck within an IDE. It established the following:
- Participants highly valued having precise vulnerability scanning within their code editor.
- Participants expressed that there were points of confusion in the core workflow. Some level of automation and surfacing of vulnerabilities in the code could resolve these.
- A UI with too much information could distract users. Having reduced complexity is something that participants desired.
With this user feedback in mind, it would be advantageous to re-integrate vulncheck tooling into IDE workflows via gopls in an intentional way. Vulncheck should not be invoked without a user’s permission, but could be brought to users’ attention at key moments (such as when new dependencies are added). This will avoid frequent pop up notifications. Thus, we will be able to provide a minimally invasive solution to vulnerability scanning that meshes well with users’ expectation of an intuitive IDE workflow.
Design
IDE Integration
- The following components will need to be created (along with their respective telemetry):
- Create an initial pop-up notification for users to opt in to running vulncheck (Yes, No, Never)
- If Never is selected, then that choice should be written to .config/gopls.
- Add a vulncheckPrompt setting to gopls/internal/settings
- When vulncheck is run, store a hash of dependencies (perhaps in .config/gopls)
- When dependencies are updated (if
go.modchanges), decide based on the stored hash whether to prompt users again.- Whenever
go.modchanges on disk, the workspace is reloaded. When gopls calls packages.Load on the entire workspace, the payload of package information can be used to hash the changes in dependencies.
- Whenever
Telemetry
- Enable telemetry to see if users are opting into vulncheck analyses.
- Verify if users are pressing the button to run vulncheck as a code lens on a users’
go.modfile. - Add telemetry for this new feature to identify if users are opting in via gopls/internal/settings
Collaboration with @findleyr
Thanks @ethanalee-work!
I'll note that one of the major reasons we didn't do prompting before is that we considered it too invasive.
However, since we now persist some local information in ./gopls/config, we can make it very easy for users to opt-out of vulncheck scanning. I think this makes it acceptable to add a prompt that's on by default.
And to be clear, as a user I'd want to be prompted to run vulncheck whenever my dependencies change, so I think this is valuable.
Change https://go.dev/cl/726560 mentions this issue: gopls/internal/server: consolidate showMessageRequest in prompt.go
Change https://go.dev/cl/723943 mentions this issue: internal/server: enable module upgrade via vulncheck prompt
Change https://go.dev/cl/722100 mentions this issue: gopls/internal/server: trigger vulncheck prompt for go.mod changes
Change https://go.dev/cl/722120 mentions this issue: internal/server: store vulncheck prompt preference
Change https://go.dev/cl/722460 mentions this issue: internal/server: add vulncheck scanning after vulncheck prompt
Change https://go.dev/cl/724060 mentions this issue: internal/server: list vulnerabilities within vulncheck prompt
Change https://go.dev/cl/723944 mentions this issue: internal/server: add telemetry for vulncheck_prompt