5 ms·

I wrote a [similar post](https://btao.org/2021/09/09/npm-install-is-curl-bash/ https://btao.org/2021/09/09/npm-install-is-curl-bash/) recently, and I think it's

I wrote a [similar post](https://btao.org/2021/09/09/npm-install-is-curl-bash/ https://btao.org/2021/09/09/npm-install-is-curl-bash/) recently, and I think it's worth sharing this part: > When installing an untrusted package, run `npm install` or `yarn add` with the `--ignore-scripts flag`. If, like me, you tend to forget this, you can set npm/yarn to never run scripts with `{npm,yarn} config set ignore-scripts true`. This disables install scripts, which is a primary attack vector for malware on npm. It also breaks some packages, though, but I've had this setting on for a while with no major problems.

bin_bash 5y ago
You'll presumably be executing the code which could trivially include `childProcess.spawn()`. I think energy would be better spent vetting the author of the package. If you're concerned, install it in a VM. It's never safe to run code in any language if you think it might be suspect.
- roblabla 5y ago
  The problem is rarely the author going rogue, but rather their accounts getting hacked, and the hacker pushing a malicious update to an existing package. Vetting the author won't really help, you need to vet the updates.
- bloodyvalentine 5y ago
  Vetting the author of the package is neither very realistic in a lot of cases, nor a great solution to this problem unfortunately. A lot of people got impacted by this issue through Karma, which is extremely popular and trusted by the community. In this case, the bad actor also managed to access ua-parser-js author's NPM account and push the bad version directly, so not really the case of an author going rogue.
whymarrh 5y ago
Small plug for LavaMoat (https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat) which includes tools to more granularly disable dependency lifecycle scripts via @lavamoat/allow-scripts.
Buttsite 5y ago
Yeah this person clearly stole your article.
loo 5y ago
You don't just have to trust the package, but all of its transitive dependencies as well. Node apps should be developed in isolated containers or VMs. We need peer review of every update, imo. Starting to think checking node_modules into an app repo, so you get update diffs, is sane.

bin_bash 5y ago

You'll presumably be executing the code which could trivially include `childProcess.spawn()`. I think energy would be better spent vetting the author of the package. If you're concerned, install it in a VM. It's never safe to run code in any language if you think it might be suspect.

roblabla 5y ago
The problem is rarely the author going rogue, but rather their accounts getting hacked, and the hacker pushing a malicious update to an existing package. Vetting the author won't really help, you need to vet the updates.
bloodyvalentine 5y ago
Vetting the author of the package is neither very realistic in a lot of cases, nor a great solution to this problem unfortunately. A lot of people got impacted by this issue through Karma, which is extremely popular and trusted by the community. In this case, the bad actor also managed to access ua-parser-js author's NPM account and push the bad version directly, so not really the case of an author going rogue.

whymarrh 5y ago

Small plug for LavaMoat (https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat) which includes tools to more granularly disable dependency lifecycle scripts via @lavamoat/allow-scripts.

Buttsite 5y ago

Yeah this person clearly stole your article.

loo 5y ago

You don't just have to trust the package, but all of its transitive dependencies as well. Node apps should be developed in isolated containers or VMs. We need peer review of every update, imo. Starting to think checking node_modules into an app repo, so you get update diffs, is sane.