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
> > ● 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.
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.
> 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.
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.
> ● 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.
>
>As a user who owns modules you should not stay logged into npm. (Easily enough, npm logout and npmlogin)
>Use npm shrinkwrap to lock down your dependencies
>Use npminstall someModule --ignore-scripts
>
I would add to toss a glance at the libraries you import every once in a while. Just to make sure they look sane.
--ignore-scripts won't help much. The act of using any npm module means you implicitly trust all the javascript code in the module and any of its dependencies. Has anyone taken the time to inspect every line of the dozens of modules that many common packages pull in? Not likely.
I've already written it in another comment: a different way of solving the problem would be to build a tool that allows developers to mark releases as safe. (public lgtm) Every package would have a safety score and you could decide yourself if that's good enough for you.
● 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: