[ashishb]

> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.

Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier?

  - Switch all projects to `pnpm`? That means switching CI, and deployment processes as well
  - Change the way *you* run `npm` on your machine and let your colleagues know to do the same

I find the second to be a lot easier.

[larusso]

I don’t get your argument here. 10 isn’t a huge number in my book but I don’t know of course what else that entails. I would opt for a secure process change over a soft local workflow restriction that may or may not be followed by all individuals. And I would definitely protect my CI system in the same way than local machines. Depending on the nature of CI these machines can have easy access rights. This really depends how you do CI and how lacks security is.

[ashishb]

I'll do soft local workflow restriction right away.

The secure process change might take anywhere from a day to months.

[afavour]

There are a great many extra perks to switching to pnpm though. We switched on our projects a while back and haven’t looked back.

[alt227]

Yeah, id just take the time to convert the 10 projects rather than try to get 50 people to chnage their working habots, plus new staff coming in etc.

Switch your projects once, done for all.

[ashishb]

So, switching to pnpm does not entail any work habit changes?

[fragmede]

Am I missing something? Don't you also need to change how CI and deployment processes call npm? If my CI server and then also my deployment scripts are calling npm the old insecure way, and running infected install scripts/whatever, haven't I just still fucked myself, just on my CI server and whatever deployment system(s) are involved? That seems bad.

[ashishb]

Your machine has more projects, data, and credentials than your CI machine, as you normally don't log into Gmail on your CI. So, just protecting your machine is great.

Further, you are welcome to use this alias on your CI as well to enhance the protection.

[arghwhat]

Attacking your CI machines means to poison your artifacts you ship and systems they get deployed to, get access to all source it builds and can access (often more than you have locally) and all infrastructure it can reach.

CI machines are very much high-value targets of interest.

[fragmede]

> Further, you are welcome to use this alias on your CI as well to enhance the protection.

Yes, but if I've got to configure that across the CI fleet as well as in my deploy system(s) in order to not get, and also be distributing malware, what's the difference between having to do that vs switching to pnpm in all the same places?

Or more explicitly, your first point is invalid. Whether you ultimately choose to use docker to run npm or switch to pnpm, it doesn't count to half-ass the fix and only tell your one friend on the team to switch, you have to get all developers to switch AND fix your CI system, AND also your deployment system (s) (if they are exposed).

This comment proffers no option on which of the two solutions should be preferred, just that the fix needs to made everywhere.

[jve]

You do the backward logic here. I would go for a single person to deal with pnpm migration and CI rather than instruct other 10 for everyone to hopefully do the right thing. And think about it when the next person comes in... so I'd go for the first option for sure.

And npm can be configured to prevent install scripts to be run anyways:

> Consider adding ignore-scripts to your .npmrc project file, or to your global npm configuration.

But I do like your option to isolate npm for local development purposes.

[azangru]

> which one is easier?

> Switch all projects to `pnpm`?

Sorry; I am out of touch. Does pnpm not have these security problems? Do they only exist for npm?

[joshkel]

pnpm doesn't execute lifecycle scripts by default, so it avoids the particular attack vector of "simply downloading and installing an NPM package allows it to execute malicious code."

As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.

[ashishb]

Exactly so you should still execute all JS code in a container.