Adding a proposal for the new CLI command to fix vulnerabilities #13961
Conversation
|
|
||
| - [Olia Gavrysh](https://github.com/OliaG/) | ||
| - Start Date (2024-11-11) | ||
| - [#8087](https://github.com/NuGet/Home/issues/8087) |
There was a problem hiding this comment.
We're overdue with some housekeeping here.
- We shouldn't link specs to massive epics like this. This is a very specific feature that's only a part of the whole auditing experience.
- This is a 2 in 1 spec. Adds
dotnet package updateanddotnet audit fix. We have some pre-existing specs on both that need tidied up/closed eventually when we think this is ready for the community to review. dotnet update package for NuGet packages. #11812 and dotnet audit & dotnet audit fix for NuGet packages. #11549.
There are 2 issues that in particular track audit fix & dotnet update package. #13372 and #4103.
I think those are the issues that this spec should be referring to.
| ## Motivation | ||
|
|
||
| <!-- Why are we doing this? What pain points does this solve? What is the expected outcome? --> | ||
| Even though .NET developers now have the opportunity to learn about vulnerabilities and deprecated dependencies in their NuGet packages, addressing these issues remains a significant challenge. It requires a lot of manual work and knowledge about newer versions, which can be quite daunting. When the solution to these problems takes time, developers are less likely to act on it immediately, leading to these upgrades being postponed or never addressed. Additionally, developers might not always use the most efficient ways of resolving these issues, especially when dealing with multiple nested transitive dependencies. This is why developers will benefit greatly from a single command that attempts to automate all the work and update all the packages, efficiently eliminating vulnerabilities and deprecated versions. |
There was a problem hiding this comment.
There's a bunch of capabilities already that may not be given enough credit in this description here.
VS
- Has a means to show outdated packages.
- Has a means to show deprecate/vulnerable packages.
- Has a means to update all packages to latest.
- Has a means to update a single package to latest (which can be challenging).
- Has a vulnerability filter, which in turn can allow you to update all vulnerable packages to latest.
dotnet
- Has a means to show outdated packages
- Has a means to show deprecated/vulnerable packages
- Has a means to update a single package
- Does not have means to update multiple packages at once.
The gaps that exsist are:
- No means to update to all latest packages on the CLI.
- No means for update heuristics, such as, update my vulnerable packages. This is essentially what the feature fka
audit fixwas intending to solve.
| C:\> dotnet package update | ||
|
|
||
| Fixing outdated packages in ContosoUniversity.sln | ||
| Updated UmbracoForms 8.4.1 to 8.7.1 |
There was a problem hiding this comment.
Packages are installed on a per project basis, so this would probably be updating projects.
Solution updates & project updates can be different.
There's some mechanics to work out potentially here, especially in non-CPM scenario.
For example, an update to package A from 1.0.0 to 2.0.0 in project 1 may succeed, but may fail in project 2.
|
|
||
| ### Fixing vulnerabilities | ||
|
|
||
| When users run `dotnet build` or `dotnet restore` commands in CLI, if they see any warnings related to vulnerabilities in their project’s NuGet dependencies, they can run `dotnet package update --vulnerable` CLI command to fix all the mentioned issues. |
There was a problem hiding this comment.
Does this address direct only or both direct & transitive?
Is the audit mode considered at all?
| <!-- 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. --> | ||
|
|
||
| #### dotnet audit |
There was a problem hiding this comment.
Reading this, not sure if this spec was quite ready for me to review.
There's some mentions about dotnet package update, but now it's talking about dotnet audit.
I'll continue my review, but just re-request review when the proposal is finalized.
| - [Vulnerability](https://docs.microsoft.com/en-us/nuget/api/registration-base-url-resource#vulnerabilities) | ||
| - Outdated - No existing endpoint, will need to call a source. | ||
|
|
||
| ##### dotnet audit --json |
There was a problem hiding this comment.
Our prior art is --format json.
dotnet list package and dotnet package search both. https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-search and https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-list-package
|
|
||
| ##### dotnet audit Exit Codes | ||
|
|
||
| - 0 - The command will exit with a 0 exit code if no vulnerabilities, deprecations, or outdated packages were found. |
There was a problem hiding this comment.
Based on some of the latest conversations, i think we should drop the exist codes.
The amount of information that can be communicated through exit codes is super low compared to the rich text we can communicate on the console or json output.
We should just do 0 or 1
| <!-- 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? --> | ||
| There already exists a dotnet CLI commands called `dotnet list package` with options such as `--vulnerable, --deprecated, --outdated` which will list any known vulnerabilities, deprecations, and outdated packages in a project or solution. These options currently cannot be combined. Although this provides valuable information to understand the state of your dependencies, there does not exist a tool that allows you to quickly audit a project/solution & provide a way to act further on. |
There was a problem hiding this comment.
Consider: dotnet list package --audit
| <!-- 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 the command be named `audit` or `check`? |
There was a problem hiding this comment.
audit matches the name of the NuGetAudit feature as well.
| ## Future Possibilities | ||
|
|
||
| <!-- What future possibilities can you think of that this proposal would help with? --> | ||
| - `dotnet audit` can be run on every `restore` which can throw warnings or errors to the user to take action against a vulnerable, deprecated, or outdated software supply chain. |
There was a problem hiding this comment.
That's exactly what NuGetAudit does today.
It warns when people have vulnerability.
No description provided.