CODEWITHSUNDEEP
nugetnuget-package
user593358
user593358

Reputation:

NuGet official package source: Should I be worried about the safety of the packages?

According to this page:

No central approval process for adding packages. When you upload a package to the NuGet Package Gallery (which doesn’t exist yet), you won’t have to wait around for days or weeks waiting for someone to review it and approve it. Instead, we’ll rely on the community to moderate and police itself when it comes to the feed. This is in the spirit of how CodePlex.com and RubyGems.org work.

This makes me feel uneasy. Before I download a Firefox add-on, I know it should not contain malicious code, because AFAIK all add-ons on addons.mozilla.org are reviewed by Mozilla. Before I download a open source project from codeplex.com or code.google.com, I know it should be safe because anyone can check it's source code. And I can also use WOT (web of trust) to check how other people think about the project.

But before I download a package from NuGet official package source. Take this one for example. I do no know who made this package, nor what is contained in the package. It seems to me that anyone can pack anything into a package, give it any name they want (like "Microsoft Prism", as long as the name is not taken), then upload it to the official package source.

Should I be worried about the safety of the packages on NuGet official package source?

Upvotes: 18

Views: 12721

Answers (2)

Timothy Gonzalez
Timothy Gonzalez

Reputation: 1908

NuGet doesn't manage trust. Even if it did, you would still have to be concerned about trusting what NuGet trusts.

You should absolutely be concerned about the safety of the code in a NuGet package. You should be concerned about the safety of any code you are not familiar with.

The approach I take to using packages, both personally and professionally, through NuGet and NPM are below:

  1. Lock in the semantic version number completely. Explicitly specify the major, minor, and patch numbers. Don't assume that new updates will be safe or that their semantic version will be accurate.
  2. Use only well known current versions for production.
  3. Experiment with anything in a test environment with limited access e.g. under an account which isn't a local administrator, no local access to highly privileged credentials, no access rights to privileged resources granted to the test machine's IP.
  4. Check the vendor. For example if the package is released by Amazon and it's an AWS SDK, then that package is probably safe to use if you trust Amazon.

For example the only packages I would trust right now to just go and add them in a production environment are Newtonsoft.Json and Nhibernate. My biggest concern with new open source packages that anyone can publish, is that they actually work as described before I buy-in and waste my time on something that doesn't meet my needs.

I feel as though if you did enough research on the package to see if it's suitable for a production environment, you probably have learned enough about the software and its community to determine if you can trust it's not doing anything maliciously. Researching the software and it's community really means more to me than NuGet's stamp of approval decided by one central authority that we all pray is perfect.

Upvotes: 3

James Webster
James Webster

Reputation: 4104

Your uneasyness should apply to software you obtain from any source:

  1. Binaries downloaded from Sourceforge.net, Codeplex.com, etc could feasibly contain malicious code (either planted by the original submitter or, more likely, inserted by a hacker into the website) that may pass unnoticed until someone (you?) gets bitten and raises the alarm.
  2. Even if you compile your own binaries from source downloaded from one of the former websites, it could still perform malicious acts unless you go over all the source code and understand what it does.
  3. Even software downloaded from 'app stores' (e.g. Apple iTunes, Android Market) could feasibly contain malicious code; some of these review processes are partially automated but are still not infallible, and the human review that also occurs is definitely not infallible!
  4. There have been examples in the past of boxed software containing malware!

Perhaps there is a continuum of trust that you can have in software (delivered as binaries or source code), and something like the Nuget Package Gallery (and CodePlex.com and RubyGems, etc) probably lies on the less-trustworthy end of the continuum.

There are potential solutions to this sort of problem, such as those proposed by the Trusted Computing Platform Alliance, however they come with huge restrictions on the freedoms that we currently enjoy in developing software and sharing the software we develop as we see fit, without the need for licenses or cryptographic keys obtained from central authorities at great expense.

I believe that the community will come up with conventions and mechanisms for ensuring that Nuget becomes a trustworthy source of software libraries for .Net developers, whilst retaining the agility it has with not requiring a formal review process. However, the ultimate responsibility rests with yourself as a user to ensure that your IT security isn't compromised, and the precautions you take are a function of the criticality of IT security in the context of the software you are writing (e.g. home projects; probably low. Banking, medical, process control projects; probably high!)

Upvotes: 13

Related Questions