Comment by compootr
2 years ago
> I don't really see the big deal here
Here's an idea: someone sends a dev at some company, or even a freelancer, some code. Code references a module with a malicious npm package (say, with a postinstall script). Dev opens it in zed
Now, my untrusted code is running on your machine, probably without your knowledge
>someone sends a dev at some company, or even a freelancer, some code
The code itself could be malicious and have backdoors. Really you shouldn't run anything untrusted outside a sandbox or some other form of isolation
Why the hell does npm support a postinstall script? There really shouldn't be a need to run arbitrary code provided by the package for something like this.
The package itself is arbitrary code. You're running arbitrary code either way whether it's preinstall, install, post install, or when the package code gets ran.
It's common to need to setup tool chains for code that gets compiled (i.e. a node module that adds language bindings to a C library)
It also supports preinstall and install scripts, for more obvious reasons.
I don't really think thats more obvious. It's expected to install dev libraries, not system services, it shouldn't have that need.
3 replies →
How is that any different from the VS Code extensions that have one star and are just copies of other extensions… waiting to get high stars and then switch-a-roo? Same goes for browser extensions.
Unless you’re auditing everything while taking Trusting Trust into account, you’re drawing the line somewhere saying “ok I can’t be bothered past this point verifying”.
… everyone has a line somewhere on the trust-but-verify spectrum
> … everyone has a line somewhere on the trust-but-verify spectrum
Sure, and by making the automatic downloads optional, users are given the choice of where they want to draw that line.