Community Notice on npm dependencies in your projects
As most of you are likely aware by now, a potentially dangerous security vulnerability was highlighted recently in the use of npm modules in your projects. In general, the jQuery Foundation still believes this is a safe and very powerful practice and in no way are we saying you should no longer use npm for package management in your JavaScript projects. What we would like to advocate is caution for our community of jQuery plugin developers and users of the many projects in the foundation who distribute packages on npm when installing a package and its dependencies.
A Quick Recap
Rather than rewrite the story, go ahead and check out the full recap and summary from npm on their blog.
The Concern
What happened next is the reason we are writing this post. Azer Koçulu published a number of packages on npm, one of which was the left-pad package which is a simple bit of code that is depended upon by many other packages. After the package was unpublished, many popular projects began having build failures due to the missing package. This is concerning in itself that anyone could unpublish a dependency you have, or a dependency of a dependency of a dependency and cause you or your team real headaches. Shortly after left-pad was unpublished, the npm team decided to un-unpublish it with a new owner to fix the many breaking builds around the internet. What is more concerning though, is the fact that once a package is unpublished, anyone can grab those package names you depend on somewhere in your dependency tree and push new, potentially malicious code into your project. In general, this wouldn’t be too bad because your package likely relies on a version that was unpublished and the new published version would not be pulled in. However, many people when installing dependencies use the commands npm i --save <package-name> or npm i --save-dev <package-name> which by default installs the latest version published at the time preceded by a ^ like ^1.0.0 which tells npm to install any updated version through minor releases the next time dependencies are updated. This means that if you reinstall or update your project and someone has pushed malicious code into a patch (1.0.1) or minor (1.1.0) release from our example, it will automatically be installed in your project.
Recommendations
Our primary recommendation is to be careful. Know what you are installing and know what your dependencies and their dependencies down the tree are installing. You should definitely go through your projects now and see if any of the modules you depend on have been unpublished as well as if any of them are on this list and have recently published new versions that you may want to avoid until you verify it is safe. Though we haven’t spoken with them directly, we are sure the folks at npm, inc. are working hard on a way to address these concerns but until then, be vigilant and keep your projects and plugins safe. We have believed for a while and continue to believe that JavaScript has been and will continue to be one of the strongest options for developing everything from your personal blog to enterprise class applications. With any technology, we will have hiccups along the way but as long as we learn from them and retain that knowledge as we continue on, JavaScript will prevail.
NPM needs to simply require scopes (namespaces) for each package. You should not be able to do this:
npm install somepackage
You should be REQUIRED to use a namespace
npm install @someone/somepackage
This would solve all conflicting name issues as well as the security issues because someone would have to actually take over someone’s scope/namespace/account in order to push malicious code to it.
Or, we could just switch to github where namespacing is already structural. I’m already overriding npm dependencies for everything in my jspm based builds.
IMO, NPM should not just handover project to any random lawyers just based on patent(it should in fact be trademark) claim.
If NPM had not been done so, Azer would not be pissed off and decided to unpublish everything because he would no longer trust NPM as redistribute channel with credit, and would not cause all the trouble afterward.
The fact the NPM allow someone to take over projects soled based on C&D letters without account holder’s consent is truely scary. This means anyone with the aid of lawyers can take over random project and plant malicious in it.
This is the much much bigger problem.