Package Status Indicators in Visual Studio Solution Explorer #11838
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,120 @@ | ||
| # Package Status Indicators | ||
|
|
||
| - [Jon Douglas](https://github.com/JonDouglas), [Tim Heuer](https://github.com/timheuer), McKenna Barlow | ||
| - Start Date (2022-05-26) | ||
| - [#11547](https://github.com/NuGet/Home/issues/11547) | ||
|
|
||
| ## Summary | ||
|
|
||
| <!-- One-paragraph description of the proposal. --> | ||
| Providing developers important information about their package dependencies is one of NuGet's top priorities to secure development environments and encourage the ecosystem to shift left. While NuGet currently provides important information regarding security vulnerabilities, deprecations, and outdated packages in the NuGet package manager inside Visual Studio, there is an opportunity to provide this data in a more common and visible location inside of the solution explorer in Visual Studio, also known as the [common project system](https://github.com/dotnet/project-system). | ||
|
|
||
| This proposal introduces package affordances in the solution explorer to help developers take regular action on their dependencies. | ||
|
|
||
| ## Motivation | ||
|
|
||
| <!-- Why are we doing this? What pain points does this solve? What is the expected outcome? --> | ||
| An experience in which developers can quickly glance at the various nodes in the solution explorer (dependencies, packages) to understand if there is an issue that needs their attention can assist them in making quicker resolutions to common problems like security vulnerabilities, deprecated packages, and outdated dependencies. | ||
|
|
||
| According to GitHub's "Securing the world's software" report in 2020, there is a 59% chance of getting a security alert in the next year on any active repository with supported package ecosystems including NuGet. Developers today frequent the use of open source dependencies in active public repositories of .NET totaling 90%. In many ecosystems, 80% or more of the application's code comes from dependencies in the respective package ecosystem. | ||
|
|
||
| When a security vulnerability is disclosed, it is important that it is addressed as soon as possible to [protect against potential cyberattacks](https://www.whitehouse.gov/briefing-room/statements-releases/2022/03/21/fact-sheet-act-now-to-protect-against-potential-cyberattacks/). | ||
|
|
||
| While majority of software vulnerabilities are mistakes, there is an increasingly amount of malicious attacks throughout them. Of a given sample of over 500 advisories across all package ecosystems, up to 17% of the advisories are related to explicit malicious behavior including popular attack vectors and attack tactics that can lead to significant disruption or loss of some kind. | ||
|
|
||
| Currently a vulnerability takes approximately 4.4 weeks for the community to identify and release a fix for a vulnerability. It then takes 10 weeks to alert on the vulnerability of a security update to when a fix is applied. The fix will take one week to resolve. We want to reduce the total time that a developer is aware of a security update and for them to remediate it. | ||
|
|
||
| To take regular action, we want to ensure that dependencies are checked for vulnerabilities, deprecations, and outdated statuses regularly and can be remediated within Visual Studio to keep codebases current. | ||
|
|
||
| **Further reading:** https://octoverse.github.com/static/github-octoverse-2020-security-report.pdf | ||
|
|
||
| One of the top themes from both the NuGet (Visual Studio) and NuGet.org surveys include "warnings for known package security vulnerabilities and suggested fixes" and "deprecation and vulnerability indicators" averaging 18 points being spent on the feature areas out of 100 total points (7,403pts over 418 responses and 4,405pts 247 responses respectfully). These are two of the top areas that developers would love improvements to. We have confidence that security is on top of developer's minds and they would like to see these experiences in more locations. | ||
|
|
||
| ## Explanation | ||
|
|
||
| ### Functional explanation | ||
|
|
||
| <!-- Explain the proposal as if it were already implemented and you're teaching it to another person. --> | ||
| <!-- Introduce new concepts, functional designs with real life examples, and low-fidelity mockups or pseudocode to show how this proposal would look. --> | ||
|
|
||
| When a developer is working within Visual Studio, they may regularly check their "Dependencies" node within the solution explorer. When expanded, a "Packages" node is available to show the hierarchy of top-level and transitive packages included in a project. | ||
|
|
||
| NuGet uses three main words to describe these status of a package, the TL;DR are: | ||
|
|
||
| - **Deprecated** - Please don't use this for a disclosed reason and please use a suggested alternative(if any). | ||
| - **Vulnerable** - Please don't use this due to a known vulnerability and update/replace/remove/do nothing accordingly. | ||
| - **Outdated** - Please consider using a newer version. | ||
|
|
||
| Building upon Tim's initial mockup, there should be a UI affordance that demonstrates the truth of each package's status in the solution explorer representing these three words. | ||
|
|
||
|  | ||
|
|
||
| For the sake of not annoying developers, we should only bubble up a warning affordance to the top-level node (Packages and Dependencies) if there is a known top-level vulnerability or deprecated package in their package graph. | ||
|
|
||
| Outdated packages would still show the indicators if the packages node is expanded however. | ||
|
|
||
| Currently, NuGet only uses two icons to display status indicators: | ||
|
|
||
| - A warning triangle (vulnerability and deprecation). | ||
|  | ||
| - An up arrow (outdated). | ||
|  | ||
|
|
||
| Hovering over the package and icon will display the respective information for the status. | ||
|
There was a problem hiding this comment. Supporting tool tips in Solution Explorer would require work across three teams: in Solution Explorer (in its hierarchy provider), in CPS and in the .NET Project System. Currently only tool tip text is displayable for source control provider status. The APIs would need to be extended to allow other kinds of data to be included in tool tips. |
||
|
|
||
| - Deprecated - "This package has been deprecated as it is `<deprecation category>`." | ||
| - Vulnerable - "This package has at least one vulnerability with `<severity category>` severity." | ||
| - Outdated - "This package has version `<latest version>` available. | ||
|
|
||
| When right clicking a package, a developer should be able to get to the "Manager NuGet Packages..." context menu action like they can with the "Packages" and "Dependencies" nodes. | ||
|
There was a problem hiding this comment. It would be great if we could have more targeted gestures in these menus for packages. "Manage" is vaguer than "See updates" or "See vulnerabilities". There was a problem hiding this comment. I see you've called this out under "Future Possibilities" below. There was a problem hiding this comment. Is this where we'd want to open on the There was a problem hiding this comment. That's the kind of thing I was thinking, yeah. It'd be useful regardless of the status indicators. Today, right clicking on a package node doesn't provide any way to get to the package manager. If you click on "Packages" you get "Manage NuGet packages". It'd be great to have a command on individual package nodes that opens the package manager with the package pre-selected. |
||
|
|
||
| Because this feature may need some experimentation to get the right signal from the noise and the potential for exponential transitive-level vulnerabilities, developers will need a way to opt-out from the experience as a whole, and options to opt-in to varying levels of information. | ||
|
There was a problem hiding this comment. This sounds like a perfect candidate to add in the preview features in VS. |
||
|
|
||
| This may need to include a new options panel inside the `Projects and Solutions > SDK-Style Projects` regarding the Package Settings where there's a top-level checkbox for the feature, and either a drop-down indicating a package status level or multiple checkboxes for each status mentioned above. | ||
|
There was a problem hiding this comment. We receive regular requests to make the Dependencies tree general purpose for other kinds of projects, so I try to not think of it as belonging to SDK-style projects, despite the .NET Project System team owning the feature. That said, I don't know offhand of a better options page for such a setting, nor do I think we want to add another page for just a single option. |
||
|
|
||
| <!-- ### Technical explanation --> | ||
|
There was a problem hiding this comment. I'd love to see a technical explanation that focuses on the feasibility of some of these asks. That might allow to define the stages for this work. Vulnerabilities are going to always be up to date. What happens with deprecation & update, which are expensive to calculate for example. Things I'm curious about.
There was a problem hiding this comment. Data about deprecations/vulnerabilities/updates/etc could be handled async relative to the currently project data flow. In VS, the total set of packages in the solution could be gathered and this information queried. Once available, it could be pushed to projects, which could then update project state. If the data was cached, then solution-load could efficiently load the data during solution load so that we show that state immediately. The component that manages that state could also be responsible for keeping it updated via whatever means makes sense, such as polling a remote server. One area I'm curious about is vulnerable transitive dependencies. The project references A which references B, and B is vulnerable. We would want to show A as vulnerable too. Therefore this component would need to model dependencies between packages and push any such state back up the graph to referencing packages, recursively. There was a problem hiding this comment.
Transitive dependencies is definitely an area where we need lots of work. There was a problem hiding this comment. Given there are commonly many more indirect dependencies than direct dependencies, I wouldn't be surprised if the majority of exposure to vulnerable packages occurs through indirect dependencies. |
||
|
|
||
| <!-- Explain the proposal in sufficient detail with implementation details, interaction models, and clarification of corner cases. --> | ||
|
|
||
| ## Drawbacks | ||
|
|
||
| <!-- Why should we not do this? --> | ||
| While developers continue to seek this information in more locations, it can also be quite a bit of noise towards the general development experience. Developers tend to compare visual issues in the solution explorer akin to ["DLL Hell"](https://en.wikipedia.org/wiki/DLL_Hell) which we would like to avoid the perception as much as possible while providing valuable information about dependencies. | ||
|
|
||
| This feature can potentially collide with existing experiences in which package dependencies may not exist on disk and/or assets file are incorrect and require a restore to resolve. There can also be false positives/negatives with the current state of the project system and the need to reload projects to refresh the package status in realtime. | ||
|
There was a problem hiding this comment. Could you explain more about false positives that would require reloading projects? I'm not aware of such a situation, for projects opened by the .NET Project System at least. |
||
|
|
||
| ## Rationale and alternatives | ||
|
|
||
| <!-- Why is this the best design compared to other designs? --> | ||
| <!-- What other designs have been considered and why weren't they chosen? --> | ||
| <!-- What is the impact of not doing this? --> | ||
|
|
||
| - [Dependabot](https://github.com/dependabot) provides vulnerability information at the repository level through PRs. | ||
| - NuGet.org, dotnet CLI, and NuGet Package Manager inside Visual Studio provide much of this functionality already, but they are multiple clicks and commands away from developers seeing them. | ||
|
|
||
| ## Prior Art | ||
|
|
||
| <!-- What prior art, both good and bad are related to this proposal? --> | ||
| <!-- Do other features exist in other ecosystems and what experience have their community had? --> | ||
| <!-- What lessons from other communities can we learn from? --> | ||
| <!-- Are there any resources that are relevant to this proposal? --> | ||
| - NuGet provides status indicators in the NuGet Package manager experience in Visual Studio. | ||
| - Visual Studio for Mac provides "outdated" status indicators in the solution explorer. | ||
|
There was a problem hiding this comment. Can we include a screenshot of how this looks in VS Mac? |
||
|
|
||
| ## Stakeholders | ||
|
|
||
| - NuGet | ||
| - .NET Project System | ||
| - Visual Studio (.NET Tooling) | ||
|
|
||
| ## Unresolved Questions | ||
|
|
||
| <!-- What parts of the proposal do you expect to resolve before this gets accepted? --> | ||
| <!-- What parts of the proposal need to be resolved before the proposal is stabilized? --> | ||
| <!-- What related issues would you consider out of scope for this proposal but can be addressed in the future? --> | ||
| - Should NuGet consider a third icon metaphor for vulnerabilities? Previously we were not successful in doing so, but we can reconsider. | ||
|
|
||
| ## Future Possibilities | ||
|
|
||
| <!-- What future possibilities can you think of that this proposal would help with? --> | ||
| - In the future, we hope to streamline context menu actions to resolve individual package issues with a single click without having to open the NuGet Package Manager. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current bubble-up logic is based on priority. At each level, the "maximum" level's icon is shown. The order is: error, warning, none. Doing something different here would require some rewriting within the dependencies tree.