New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate obsolete, vulnerable or legacy packages #2867

Open
daveaglick opened this Issue May 31, 2016 · 30 comments

Comments

Projects
None yet
@daveaglick

daveaglick commented May 31, 2016

As NuGet gets older, I've noticed a pattern where some packages have a description along the lines of "This package is old and shouldn't be used, use XYZ instead". It seems reasonable that as projects age, their packages may change names, split, combine, etc. over time. In fact, I'm faced with doing this for a number of packages myself soon.

I propose a feature where we can mark packages as deprecated or obsolete. This would be different from marking them as unlisted in that they would still be available on the gallery and would still show up in search results (perhaps with an additional GUI element to indicate the deprecated state). It would also be nice to specify which package(s) replace them and show that in the gallery and also when installing a deprecated package.

@rrelyea rrelyea added this to the Future milestone May 31, 2016

@yishaigalatzer

This comment has been minimized.

yishaigalatzer commented May 31, 2016

@rrelyea this issue was logged before as far as I recall, please dedup

@daveaglick

This comment has been minimized.

daveaglick commented May 31, 2016

@yishaigalatzer @rrelyea I searched the GitHub repo and didn't find anything similar - perhaps it was in the old CodePlex site (I didn't search there), or maybe I just missed it.

@yishaigalatzer

This comment has been minimized.

yishaigalatzer commented May 31, 2016

Its a good ask, I just recall seeing it before :) You might be right, we just need to spend a few more minutes trying to find the dup

@rrelyea rrelyea added the Type:Feature label Jun 9, 2016

@lilith

This comment has been minimized.

lilith commented Dec 31, 2016

I cannot find the duplicate. I also cannot find any issue which offers a workflow for dealing with package vulnerabilities. Or information on whether floating versions are supported in .nuspec files.

Oldest-possible + no deprecation/version flagging = scary context for security process. Hoping I'm just missing something obvious.

@Richiban

This comment has been minimized.

Richiban commented Mar 31, 2017

I agree; this would be a seriously useful feature.

In particular I would also like to be able to deprecate specific versions of a package to indicate to anyone trying to install / restore this package that it no longer works (this situation normally arises when you write a client for an API and then the API itself gets deprecated or breaking changes are made). In this case the user should get a warning prompting them to upgrade their version.

@rjso

This comment has been minimized.

rjso commented Jun 30, 2017

It's a real shame this feature does not exist. I can come up with multiple reasons why we would like to discontinue a certain project and at least give a warning to whoever is using, in a similar fashion to the deprecated attribute in C#. Is this being considered? From my naivety, I suppose this is more of a strategic decision for the nuget team as opposed to amount of code needed.

@ChrisMaddock

This comment has been minimized.

ChrisMaddock commented Jul 2, 2017

I was surprise to hear that chocolatey now has a deprecation feature, which NuGet still doesn't. We'd also have use for this feature - we're currently maintaining duplicate packages, as we don't feel we can remove old packages without causing mass disruption to our users. And automatic upgrade path to a new package, like choco has would be a great solution for this.

@CharliePoole

This comment has been minimized.

CharliePoole commented Jul 2, 2017

I think chocolatey's "feature" is more a matter of convention. I might be wrong, but I"m pretty sure you can do the same thing in nuget:

  1. Change title to say "Deprecated something" (so people notice it)
  2. Advance the version - perhaps some convention like x.y.9999.
  3. Remove files and add a reference to the new package

That only works if you choose to no longer have the old package available. I think this issue is about keeping the package but also deprecating it and having nuget know it's deprecated. I don't think that's possible using a convention - you need an extra bit somewhere.

@PeteX

This comment has been minimized.

PeteX commented Sep 11, 2017

If this feature gets implemented, please can we also have a flag saying, 'This package has a vulnerability.'

Our deployed applications have to be reviewed periodically to make sure they are still secure. Part of this process involves checking dependencies to make sure none of them have released security patches. At the moment it's almost impossible to distinguish between feature releases, releases that fix normal bugs, and security releases. This wastes a lot of time for us, and presumably for other people who are trying to take security seriously.

@anangaur

This comment has been minimized.

Member

anangaur commented Oct 19, 2017

Seems like a good feature to have as NuGet.org grows and packages become obsolete. I am trying to summarize the scenarios for deprecation here. Please add to the list (and I will add to this list so that it would be easier to design a feature that solves the most of the issues):

  1. I released a pre-release version of the package but I would like developers to move to stable version that I released later
  2. I released a package version that had serious bugs in it and I would like to recommend developers using this version to move to the latest version. I would also like the packages taking dependency on this version of my package to move off this version to a newer version.
  3. I had released a package that made use of currently deprecated/discontinued set of APIs and hence I would like developers to move to a newer version of this package.
  4. I have a newer package (with different ID) on NuGet.org that should now be used instead of the given package and I would like developers to somehow not taken dependency on this package.
@PeteX

This comment has been minimized.

PeteX commented Oct 20, 2017

@anangaur By far the most important thing for me is 'This package has a vulnerability, so users need to upgrade to maintain their systems' security.'

The big prize here, IMO, is being able to construct an automated system that tells you about important package upgrades you should be doing. If you're not bothered about automating things, you don't need to build anything extra. You can just release a new version of the package, and put something in the release notes saying why.

Incidentally, I think people uploading a new version of a package to Nuget should be asked whether there are security fixes, and forced to say 'yes' or 'no'. That's the only way to make sure that this essential information is captured, because otherwise some people will fix security exposures while not bothering to set the flag (perhaps because they just don't know about it).

@anangaur anangaur self-assigned this Nov 9, 2017

@StefanBertels

This comment has been minimized.

StefanBertels commented Dec 7, 2017

I miss "deprecated" flag, too. Maybe this issue isn't already implemented because we make scope too large?
"vulnerable" might be technically similar (flag), but this flag is not that easy.

"deprecated" is quite simple: If something is deprecated without follow-up this means "no longer maintained / think about removing it". With a follow-up this means "please upgrade by switching to package xyz".

If you search for deprecated packages, you should have to enable some switch (similar to "include prerelease"). If you restore deprecated packages a warning should occur.

It's not easy to define semantics (why is it deprecated) and we should let users decide how to handle the warning/flag. Maybe package is useless (incompatible API), maybe not, maybe partially.

Security is more difficult: Who defines "is vulnerable"? Package owner, only? There are different levels of vulnerability. Is it only a problem when used in ASP.NET (world accessable)? Only a special feature has a flaw? If you have some openssh like library which support unsecure methode (RC4) is this a vulnerability of the package? Are unflagged packages secure?

I see limited use for a "vulnerable" flag. Only useful aspect I could see: This might open a way to let package owners (or NuGet.Org) send security warnings to users. A common (existing) alternative for many projects is a security-announcement mailing list...

@anangaur

This comment has been minimized.

Member

anangaur commented Dec 7, 2017

"deprecated" is quite simple: If something is deprecated without follow-up this means "no longer maintained / think about removing it". With a follow-up this means "please upgrade by switching to package xyz".

Today one can de-list the package and such a package has the following information:
image

Summarizing the missing pieces:

  1. Ability to label an unlisted package with special tag/reason with separate meanings:
  • Deprecated: 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.
  • 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.
    * Each of the above takes an optional recommended package.
  1. Client warning when an unlisted package is installed/restored with one of the reasons specified above. If an additional recommended package+version is specified, clients should be able to show that information as well.
@PeteX

This comment has been minimized.

PeteX commented Dec 7, 2017

@StefanBertels I would settle for a vulnerable flag that is yes or no, and set by the package owner. Our approach is that we update any vulnerable package, rather than trying to determine whether the vulnerability applies to us. It generally ends up being quicker, and it reduces the likelihood of making errors which allow vulnerable code to stay in production.

For people who don't do that, a vulnerable marker would still be useful because it would flag up the package for investigation. One way to make things a bit smoother, I suppose, would be a way for someone to specify on the client side that they have investigated CVE-1234 and decided that it's not relevant to them. Conceptually it would be a bit like suppressing a warning in some source code.

The reason people aren't screaming for a vulnerable flag, I think, is that most people just ignore security until it bites them. They deploy code with packages that were believed secure at the time, and then they just forget about it. This is very poor practice and people who do it should be shouted at by the tooling. :)

@StefanBertels

This comment has been minimized.

StefanBertels commented Dec 12, 2017

@PeteX:
I agree, but what motivates package owners not to be ignorant?

(Package) users don't care, too. What happens if you "scare" your users with security warnings?

There is a long way to go.

@petertiedemann

This comment has been minimized.

petertiedemann commented Jan 26, 2018

@anangaur I am very interested in the Legacy option. Without it, changing package ids (Which is frequently tied to assembly namespaces) become a major pain for users. I would very much like to see NuGet automatically ask the user whether to upgrade to the new package id, and then apply that change without having to mess around with manually uninstall/install.

@ChrisMcKee

This comment has been minimized.

ChrisMcKee commented Mar 29, 2018

I'd request this is extended to packages that are abandoned.

  • Nuget should automatically label projects where there have been no updates in 4 years as abandoned and bump them down the search listings
  • Or at implement a deadmans handle; email once a year "Are you still maintaining this package" no response in 90 days, de-rank in search.
@ghuntley

This comment has been minimized.

ghuntley commented May 6, 2018

These three indicators are highly 👍 from me:

  • Deprecated
  • Vulnerable
  • Legacy

If client warning can be customised display to the user the migration path/new package name then it's a solid ⛵ it omg plz.

See https://twitter.com/GeoffreyHuntley/status/993096801552031744?s=09

@anangaur anangaur removed the Priority:2 label Jun 4, 2018

@anangaur anangaur changed the title from Feature request: deprecated/obsolete packages to Deprecate obsolete, vulnerable or legacy packages Jun 4, 2018

@tmds

This comment has been minimized.

tmds commented Jun 6, 2018

It would also be nice to specify which package(s) replace them

the user the migration path/new package

@daveaglick @ghuntley ptal at #6848 which is about a package being able to declare it has patch releases (with semver semantics). That metadata can be used to automatically roll-forward patch versions, e.g. during the restore operation.

@MaximRouiller

This comment has been minimized.

MaximRouiller commented Jun 21, 2018

Any updates?

@ReubenBond

This comment has been minimized.

ReubenBond commented Jul 2, 2018

Happy to see that this issue is included in the NuGet Summer 2018 Roadmap 😊

@PeteX

This comment has been minimized.

PeteX commented Jul 2, 2018

Incidentally npm has rolled out a feature which warns about insecure packages. This is the kind of functionality I think would be useful in Nuget.

@MaximRouiller

This comment has been minimized.

MaximRouiller commented Jul 4, 2018

@ReubenBond love from Canada to Australia! Thanks for pointing that out! 😁😁

@tmds

This comment has been minimized.

tmds commented Jul 5, 2018

From the NuGet Summer 2018 Roadmap

We also want to add the ability for package authors to suggest alternatives to consumers.

I hope this closely matches with metadata needed to enable #6848.

@rrelyea

This comment has been minimized.

Contributor

rrelyea commented Oct 12, 2018

there has been some early thinking/design here:
https://github.com/NuGet/Home/wiki/Deprecate-packages
(note: @anangaur is on vacation, so don't expect much response right now)

@chwarr

This comment has been minimized.

chwarr commented Oct 12, 2018

Some quick thoughts about the current design:

  1. Should there be a way to suppress the deprecated warning during restore? Does this need to be scoped to a specific package? How does this manifest with nuget.exe, MSBuild <PackageReference> items, the PowerShell cmdlets, ...?
  2. On the flip side, should there be a way to opt-in to fail restore for deprecated packages? (The "no one reads warnings" argument.) E.g., --fail-when-older=14d --fail-when-older=7d,Contoso.* --fail-when-older=48h,System.*
  3. When the author is specifying a fixed-in package and the fixed-in package is the same package, the UX flows should strongly encourage that a fixed-in version be included as well.
  4. Does it make sense for a fixed-in version to be older than the version being flagged? I think yes: there are cases when the introduction of a vulnerability can be tracked down to a specific version.
  5. Are versions newer than the flagged version assumed to be fixed implicitly? For the sake of simplicity, I think that this flagging should only apply to one package+version at a time and not have range support.
  6. I'd like to see a discussion of how--if at all--the fixed-in version is used during package version resolution. The design currently says "Once a package has been deprecated, they are (sic) hidden in search results." If this results in the same behavior as unlisting, please explicitly reference that behavior.
  7. Discuss whether there needs to be a UX flow for applying one of these flags to an entire package and all its known versions in one shot. E.g., all of Contoso.Foo is legacy: use Contoso.Bar instead.
  8. When the protocol-level design has been sketched, those details/links to them would be nice as well.
@PeteX

This comment has been minimized.

PeteX commented Oct 13, 2018

@chwarr, interesting that you mention ranges of versions. Imagine a package that has been around for a long time, published a lot of releases, and then a security hole is found. It could be very tedious having to go through fifty releases marking them all as vulnerable, and urging users to update to one of a few fixed ones. Is there a need to capture the idea that all 2.x.y users should update to 2.8.9, all 3.a.b users to 3.9.8, and so on?

Is there an expectation that already deprecated packages will have additional vulnerabilities attached to them? For example Contoso.Foo is deprecated because of CVE-2018-1234, but then CVE-2018-4321 is found as well. It's potentially useful to know all of a package's vulnerabilities, in case a particular user is not vulnerable to some of them, owing to the way the package is being used.

@MaximRouiller

This comment has been minimized.

MaximRouiller commented Oct 15, 2018

@PeteX There is a project called dotnet-retire which is currently community driven that allows a check on Microsoft packages with declared CVE on them. Not to expand the scope but something along those lines would need to be baked in in my personal opinion.

https://www.nuget.org/packages/dotnet-retire

@dotMorten

This comment has been minimized.

dotMorten commented Oct 27, 2018

Will I be able to update the deprecation description? A package might be deprecated because it's out of support so it will tell you to minimum use version X. At some point version X also goes out of support so need to be able to go change it to version Y etc.

@anangaur

This comment has been minimized.

Member

anangaur commented Oct 28, 2018

I think this should all be automatic. I am in the process of updating the spec in this respect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment