Protecting package dependencies from malicious code from npmjs.com

[Chris Hills]

As I understand it, a package author can un-publish their package on npmjs.com, and somebody else can publish a package with the same name. If I create a package depends on a package from npmjs.org, I have little protection against a "bait-and-switch" which could result in unwanted, even malicious code being deployed and run. Other software distribution methods usually involved signing with a private key to protect against this kind of behaviour. Is there something I can do today to protect against this without resorting to have to manually perform an audit every time I download a package from npmjs.org?

[Zlatko]

On Thursday, March 24, 2016 at 3:21:41 AM UTC+1, Chris Hills wrote:

As I understand it, a package author can un-publish their package on npmjs.com, and somebody else can publish a package with the same name. If I create a package depends on a package from npmjs.org, I have little protection against a "bait-and-switch" which could result in unwanted, even malicious code being deployed and run. Other software distribution methods usually involved signing with a private key to protect against this kind of behaviour. Is there something I can do today to protect against this without resorting to have to manually perform an audit every time I download a package from npmjs.org?

A very popular question these days :) I'm also interested in something like that.

I had two ideas in mind, I wonder what others say about this:

1. Scoping packages

I was thinking something which would be a bit manual in the beginning - as you install a package, clone it into your scoped package (@username/package). I'm thinking a script could be made to do that, perhaps even an npm wrapper. Perhaps smart enough to check if you already have such a package.

But this feels quite wrong. It would duplicate a crapload of packages. Furthermore, if the script becomes easy to use and transient (which is basically the only way it could be useful), it would get spread and get used massively, potentially requiring npm to scale beyond anything reasonable (instead of 300,000 packages, good deal of which get duplicated for each of a humble estimate of a few million users - that would mean a whole lot more stuff to handle. The actual content would get deduped, I guess, but still feels like unnecessary burden.

2. Include packages in source control.

Basically add node_modules to source control. Then there's nothing to be installed, everything is already there. Not sure if and how much more complicated it gets when the code gets deployed to hosted platforms.

What else, what are other _easy_ solutions we could have?

[Axel Kittenberger]

I wonder, do you want to include automatic version updates in the dependency? In that case you have already trust relationship with the package author, as any update could come with new malicious code anyway. If you have already such trust relationship that you trust updates to be OK, I don't see it as any stretch to also trust the package author not to suddendly unpublish their package.

If you do not want to go this update trust relationship with the package author, you'd have to fix to a specific version. In that case the simpler and more effective technique would be to be able to add an expected hashcode of the dependency to your package.json and npm checking if the hashcode of the package matches (wherever it comes from)

On Wed, Mar 23, 2016 at 3:39 PM, Chris Hills <ch...@chaz6.com> wrote:

As I understand it, a package author can un-publish their package on npmjs.com, and somebody else can publish a package with the same name. If I create a package depends on a package from npmjs.org, I have little protection against a "bait-and-switch" which could result in unwanted, even malicious code being deployed and run. Other software distribution methods usually involved signing with a private key to protect against this kind of behaviour. Is there something I can do today to protect against this without resorting to have to manually perform an audit every time I download a package from npmjs.org?

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/e60195a2-e615-4ead-a538-02edb44bf0cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.