[QUESTION] --ignore-scripts for security only?

[goldingdamien]

Many places recommend setting ignore-scripts for the global config for security purposes.
This is to prevent third party packages from executing arbitrary code.

The problem is that setting this has resulted in no scripts running including from npm run ...
I also see no warnings when executing npm run ... with ignore-scripts enabled.

Is there any way to ignore scripts purely for the security concerns?

[ljharb]

How would npm differentiate between secure and insecure scripts?

If it could do that, why would a setting be required to ignore the insecure ones?

[goldingdamien]

It wouldn't differentiate between secure and insecure scripts.
It would simply allow scripts when using an npm command on the top module.
Since the owner is not a third party then it can be assumed to be trusted.

[ljharb]

Gotcha, that makes sense. I've never set that as a global config setting but breaking npm run would have been pretty frustrating.

[cician]

I've set ignore-scripts to true and was disappointed to discover that npm start on my project stopped working entirely with no output at all.

I'd like security of ignore-scripts, specifically to disable post-install scripts, but be able to execute my own scripts and third party scripts, only explicitly with npm start or npm run. Having to add --ignore-scripts each time i want to add a package is pretty fragile because all it takes is to forget it just one time and you can be silently compromised by a deeply hidden third party dependency.

In general I strongly believe the default behavior of npm cli is dangerous and needs to be changed in one way or another. For example npm could prompt me before executing any script, unless explicitly requested or whitelisted.

My employer is not willing to introduce npm into the stack with current behavior so my only option right now seems to rely on settubg the ignore-scripts flag on each workstation.

Also, I'd like to note I'm aware that adding a dependency have broader security consequences than scripts, but the scripts in my opinion are particularly dangerous for a few reasons. Having a malicious package in your project is as bad as it sounds, but at least there may be some more time before it gets to execute its payload, so there's slight hope it could be caught in time. Also, developers are more likely to see an extra fetch in devtools or something while debugging their code compared to the payload running directly on their computers and covering its traces. A single project with a malicious package could potentially compromise whole company IP not even related to the project. It could be hard to pinpoint a breach to the source of the problem or even detect there's a breach at all.

Sorry if I'm piggy backing on this specific issue with my paranoid thought overlflow, but I think the npm maintainers and the community should have a serious conversation on this topic. Possibly start thinking on how JavaScript and npm fits into things like the Bytecode Alliance.

[darcyclarke]

npm v6 is no longer in active development; We will continue to push security releases to v6 at our team's discretion as-per our Support Policy.

If your bug is preproducible on v7, please re-file this issue using our new issue template.

If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo

Closing: This is an automated message.

[ljharb]

This still seems relevant to v7, but it should probably be an RFC.