-
Notifications
You must be signed in to change notification settings - Fork 252
Deprecate packages
- Status: Incubation
- Author(s): Anand Gaurav (@adgrv)
Deprecate obsolete, vulnerable or legacy packages #2867
- There are certain cases when a package author or NuGet repository Admin (nuget.org admin) should be able to let the package consumers know that a certain package (version) should no longer be used i.e. deprecated. As summarized in one of the comments on the issue, following are the most important cases for package deprecation:
-
Vulnerable
: When the package version contains a security vulnerability and the author recommends not using the package and instead a newer patched version is recommended.- Authors should optionally be able to provide a CVE number
-
Legacy
: When the package is no longer maintained by the author and author may have published another package (ID) instead. -
Deprecated
: (other reasons like performance, critical bugs, etc.)When a version of the package is deprecated by the author and the author recommends either not using the package+version or using a newer non-deprecated version.
Today, this is partially possible by un-listing the package but there is no explicit feedback to the package consumers that a certain package version should no longer be used once its already in the project's list of packages (direct of full closure including transitive packages).
- In addition to the above, there is no mechanism for the package authors to suggest a new package or a new version to the package consumers where the issue (due to which the package was deprecated) has been fixed.
Being able to flag the security vulnerabilities in the packages is the primary reason behind taking up this feature. GitHub already flags the repos that depend on vulnerable packages. Today this is not enabled for NuGet packages as we do not have this feature. Similarly, npm also has the ability to flag vulnerable packages.
Package publishers should be able to mark a given package (and version) as deprecated with one of the 3 reasons:
- Vulnerable
- Legacy
- Deprecated
and optionally provide additional information like CVE#(vulnerable packages), recommended package and version.
Detailed publisher experience storyboard can be found here. The same experience should be possible for a nuget.org admin.
Once a package has been deprecated, they are hidden in search results. If any deprecated package is already being used in a project, it should be:
-
Flagged during
restore
: -
With
list --deprecated
:
<<TBD>>
- On Visual Studio Updates tab of the Package Manager UI:
-
Package authors goes to the Edit package page:
-
Checks Unlist package:
-
Is prompted to select a reason:
-
Reason = Vulnerable
-
Provides the optional details:
-
Reason = Legacy
-
Reason = Deprecated (for any other reason):
-
Upon save, the setting reflects the unlisted status:
Check out the proposals in the accepted
& proposed
folders on the repository, and active PRs for proposals being discussed today.