[taeric]

Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application?

Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace.

More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)

[dns_snek]

How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it.

In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.

[taeric]

Honestly, I'm going off memory on python. In the olden days, it was not at all uncommon for devs to want the ability to "sudo pip install foo".

[Denvercoder9]

Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.

[taeric]

Right, my understanding is that this was not too uncommon for some older packages? Especially in early python, it was not too uncommon to accidentally install to the whole system, no?