[paulirish]

NPM could take a few actions. The original disclosure PDF[1] suggests these:

● Automatically expire login tokens

● Require 2 factor auth for publish operations

● Help users be logged out during install operations

vjeux mentioned a few others on HN a few days back[2]:

● pre-install/post-install scripts should require user to accept or refuse.

● make shrinkwrap by default (and fix all the issues with it) so that running npm install doesn't use different versions when used over time.

● make updating a version an explicit decision via npm upgrade

[1] https://www.kb.cert.org/CERT_WEB/services/vul-notes.nsf/6eac... [2] https://news.ycombinator.com/item?id=11341145

In the meantime, users may want to consider one of the following:

    npm config set ignore-scripts true
    npm logout

[mayank]

It's definitely a nuanced issue.

> ● Automatically expire login tokens

I don't see how this helps the issue at hand; a worm could spread very quickly, requiring just a single publish from each freshly infected user.

> ● Require 2 factor auth for publish operations

This seems very reasonable, and the easiest to implement. It also has the nice effect of being a captcha to the publish operation, which gives it some of the gravitas it deserves in an open ecosystem like npm.

> ● Help users be logged out during install operations

This may break far more packages than might be considered acceptable.

> ● pre-install/post-install scripts should require user to accept or refuse.

Presumably this would be unnecessary with 2FA for each publish operation.

> ● make shrinkwrap by default (and fix all the issues with it) so that running npm install doesn't use different versions when used over time.

Doesn't do much to address the issue at hand. A static dependency tree doesn't mean benevolent dependencies.

> ● make updating a version an explicit decision via npm upgrade

Same issues as shrinkwrap.

[johannes1234321]

> > ● pre-install/post-install scripts should require user to accept or refuse. > > Presumably this would be unnecessary with 2FA for each publish operation.

2FA still doesn't mean you can trust the install script. Not running scripts automatically gives a chance to audit before they run.

And even with 2FA a worm could spread: It could manipulate the local npm installation so whenever you want to upload a package it will modify it during the publishing process giving you a 2nd-factor-request right when you expect it.

The only way to prevent that I can come up quickly is to over a chance to verify the package between signing (which npm doesn't support) and publishing.

[pfooti]

While I agree that giving people a chance to disable install scripts in order to audit them before / after running is a good idea, I also think it's somewhat optimistic of you to think that this would actually help.

There's plenty of npm packages that release updates weekly. I may not update them every time (I tend to wait until I see a need), but the rate of update is high enough that most people would just blindly click through after the fiftieth time they installed that package.

[wycats]

>> ● Require 2 factor auth for publish operations

> This seems very reasonable, and the easiest to implement. It also has the nice effect of being a captcha to the publish operation, which gives it some of the gravitas it deserves in an open ecosystem like npm.

I agree, especially since Google Authenticator makes this pretty easy to implement.

[nawitus]

"This may break far more packages than might be considered acceptable."

Can you elaborate?

[mayank]

I thought about this a bit more, and I can't think of a single legitimate reason to be logged into npm during a third-party package install. Of course, that doesn't mean packages won't break if anyone was depending on this behavior, but you're right -- perhaps those packages should break.

[STRML]

> ● pre-install/post-install scripts should require user to accept or refuse.

Unfortunately this wouldn't fix the issue. A malicious package could simply require() a JS script that does the same thing upon its first require(). There's no dependency on postinstall hooks for this worm to spread. Presumably, if you're installing packages, you intend to run them.