Skip to content

Deprecate packages

Anand Gaurav edited this page Aug 6, 2018 · 40 revisions

Issue

Deprecate obsolete, vulnerable or legacy packages #2867

Problem

  1. 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).

  1. 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.

Evidence

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.

Solution

Marking a package as vulnerable (Server)

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.

Flagging vulnerable packages used in a project (Client)

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:

  1. Flagged during restore: image

  2. With list --deprecated:

<<TBD>>
  1. On Visual Studio Updates tab of the Package Manager UI: image

Publisher experience

nuget.org

  1. Package authors goes to the Edit package page: image

  2. Checks Unlist package: image

  3. Is prompted to select a reason: image

  4. Reason = Vulnerable image

  5. Provides the optional details: image

  6. Reason = Legacy image

  7. Reason = Deprecated (for any other reason): image

  8. Upon save, the setting reflects the unlisted status: image

CLI command experience:

image

Contributing

What's Being Worked On?

Check out the proposals in the accepted & proposed folders on the repository, and active PRs for proposals being discussed today.

Common Problems

Clone this wiki locally