3 ms·

Not to excuse NPM and the entire "broken in new ways every time you look at it" javascript ecosystem, but any installation system that can run arbitrary scripts

by zdw 5y ago

Not to excuse NPM and the entire "broken in new ways every time you look at it" javascript ecosystem, but any installation system that can run arbitrary scripts/commands as a part of the install has this same problem. This anti-feature should be removed, and other safer workarounds provided.

ghuntley 5y ago
> any installation system that can run arbitrary scripts/commands as a part of the install has this same problem. This anti-feature should be removed, and other safer workarounds provided. 1000% agreed. I might need to refactor the article to remove the focus on NPM. It was cited for two reasons: - awareness that an important RFC that people need to vote on - npm is related to ua-user agent-parser incident (mystery meat in a binary package)
ciupicri 5y ago
As bin_bash pointed out [1], removing scripts/commands from the installation process won't achieve too much. The code could trivially include `childProcess.spawn()`, so you're only postponing the issue until you'll use the module. [1]: https://news.ycombinator.com/item?id=29161298 https://news.ycombinator.com/item?id=29161298
- pionar 5y ago
  So we should just leave this security hole because there's others?
  - alerighi 5y ago
    It’s not a security hole. When you build whatever software on whatever language you execute build scripts. It’s a feature of every package manager that I know because, even for interpreted languages there is always the case of needing to compile some native code extensions and thus you need the possibility to run scripts. Just don’t run npm install (or pip install) on a production server but install things exclusively from the distro packages or if they are not available use a container. On your PC… keep a backup on hand and possibly don’t save the keys that you use to access production systems on a txt file.
alerighi 5y ago
Also, how many people copy/paste commands on the terminal that don’t understand without thinking about it? And do you review all the build scripts of software built from source? Let alone the proprietary driver that you install, who knows what they contain… Really npm is not that much of a deal. The problem is more for CI machines that can get compromised but for workstations… they are already insecure

by zdw 5y ago

ghuntley 5y ago

> any installation system that can run arbitrary scripts/commands as a part of the install has this same problem. This anti-feature should be removed, and other safer workarounds provided. 1000% agreed. I might need to refactor the article to remove the focus on NPM. It was cited for two reasons: - awareness that an important RFC that people need to vote on - npm is related to ua-user agent-parser incident (mystery meat in a binary package)

ciupicri 5y ago

As bin_bash pointed out [1], removing scripts/commands from the installation process won't achieve too much. The code could trivially include `childProcess.spawn()`, so you're only postponing the issue until you'll use the module. [1]: https://news.ycombinator.com/item?id=29161298 https://news.ycombinator.com/item?id=29161298

pionar 5y ago
So we should just leave this security hole because there's others?
- alerighi 5y ago
  It’s not a security hole. When you build whatever software on whatever language you execute build scripts. It’s a feature of every package manager that I know because, even for interpreted languages there is always the case of needing to compile some native code extensions and thus you need the possibility to run scripts. Just don’t run npm install (or pip install) on a production server but install things exclusively from the distro packages or if they are not available use a container. On your PC… keep a backup on hand and possibly don’t save the keys that you use to access production systems on a txt file.

alerighi 5y ago

Also, how many people copy/paste commands on the terminal that don’t understand without thinking about it? And do you review all the build scripts of software built from source? Let alone the proprietary driver that you install, who knows what they contain… Really npm is not that much of a deal. The problem is more for CI machines that can get compromised but for workstations… they are already insecure