4 ms·

But attackers are not dumb. They would circumvent whether loose checks the package manager may have. Just considering your suggestion, the obvious immediate exp

But attackers are not dumb. They would circumvent whether loose checks the package manager may have. Just considering your suggestion, the obvious immediate exploit is to not deploy the attack payload right away. Nothing you will think of will evade defeat.

schemescape 5y ago
I agree that it is an unending arms race, but if NPM doesn't even plug obvious holes (like running install scripts by default), then they've lost my trust. Edit: if anyone knows of a way to disable NPM from running install scripts automatically (without having to remember to specify --ignore-scripts on each invocation), while still allowing me to use "npm run" to manually run scripts (e.g. test scripts for my own packages), I'd love to hear about it.
- Ginden 5y ago
  npm ci --ignore-scripts
  - schemescape 5y ago
    Ah, sorry, I meant a way to automatically do that (both so I don't have to type as much and so that I can't accidentally forget to add that argument). Edited my comment to reflect this.
    - jffry 5y ago
      You can run this npm config set ignore-scripts true which will update ~/.npmrc (you can also create project-specific .npmrc files if you prefer) You can see how NPM has been configured by running npm config list
      - schemescape 5y ago
        That breaks “npm run” (violating the second part of my request).
        jffry 5y ago
        The manpage says that directly invoking a script from package.json with `npm run X` aka `npm run-script X` will still work with this preference set to true, but that it will not run pre/post scripts. Perhaps that is good enough for your use-case? npm help run-script [...] ignore-scripts o Default: false o Type: Boolean If true, npm does not run scripts specified in package.json files. Note that commands explicitly intended to run a particular script, such as npm start, npm stop, npm restart, npm test, and npm run-script will still run their intended script if ignore-scripts is set, but they will not run any pre- or post-scripts.
        schemescape 5y ago
        Edit: That doesn't work as described on NPM 6.14.14 (the version I had), but it does work on NPM 8.1.0 (the version I just upgraded to). Thanks!
        jffry 5y ago
        Ah, looks like it was introduced in v7.0 - https://github.com/npm/rfcs/pull/185 https://github.com/npm/rfcs/pull/185
yardstick 5y ago
“Don’t let perfect be the enemy of good”
matheusmoreira 5y ago
> Nothing you will think of will evade defeat. Trust. Why is it that random people can submit packages? Make it so they can't. Only trustworthy people should be able to do that. People who care, so that we don't have to. People we can trust. This is how Linux distributions work and you just don't see malware randomly making its way into official repositories.
- peteatphylum 5y ago
  I wish it worked that way. I just peeked into how python packages in debian-based distros work. They are most frequently PyPI packages with some debian wrapping, so we're back at the same problem.
  - matheusmoreira 5y ago
    PyPI allowed me to make an account and just push packages there like it was nothing. Great for me, not so great for users. These Debian wrappers, however minimal, imply the existence of a maintainer trusted by the Debian community. It's assumed that this maintainer has read the source code and determined it is safe.
    - djbusby 5y ago
      Or at least pinned a version that is known good
- nijave 5y ago
  You can DIY. There's also plenty of reputation dependency scanners out there (especially in the corporate world) that will look at license, commit rate, number of committers, release frequency, transitive dependencies, etc and generate "safety" score for you E.g. "This is maintained by a huge network of contributors who contribute to other huge projects" vs "This is a single developer with a couple commits a year"

schemescape 5y ago

I agree that it is an unending arms race, but if NPM doesn't even plug obvious holes (like running install scripts by default), then they've lost my trust. Edit: if anyone knows of a way to disable NPM from running install scripts automatically (without having to remember to specify --ignore-scripts on each invocation), while still allowing me to use "npm run" to manually run scripts (e.g. test scripts for my own packages), I'd love to hear about it.

Ginden 5y ago
npm ci --ignore-scripts
- schemescape 5y ago
  Ah, sorry, I meant a way to automatically do that (both so I don't have to type as much and so that I can't accidentally forget to add that argument). Edited my comment to reflect this.
  - jffry 5y ago
    You can run this npm config set ignore-scripts true which will update ~/.npmrc (you can also create project-specific .npmrc files if you prefer) You can see how NPM has been configured by running npm config list
    - schemescape 5y ago
      That breaks “npm run” (violating the second part of my request).
      - jffry 5y ago
        The manpage says that directly invoking a script from package.json with `npm run X` aka `npm run-script X` will still work with this preference set to true, but that it will not run pre/post scripts. Perhaps that is good enough for your use-case? npm help run-script [...] ignore-scripts o Default: false o Type: Boolean If true, npm does not run scripts specified in package.json files. Note that commands explicitly intended to run a particular script, such as npm start, npm stop, npm restart, npm test, and npm run-script will still run their intended script if ignore-scripts is set, but they will not run any pre- or post-scripts.
        schemescape 5y ago
        Edit: That doesn't work as described on NPM 6.14.14 (the version I had), but it does work on NPM 8.1.0 (the version I just upgraded to). Thanks!
        jffry 5y ago
        Ah, looks like it was introduced in v7.0 - https://github.com/npm/rfcs/pull/185 https://github.com/npm/rfcs/pull/185

yardstick 5y ago

“Don’t let perfect be the enemy of good”

matheusmoreira 5y ago

> Nothing you will think of will evade defeat. Trust. Why is it that random people can submit packages? Make it so they can't. Only trustworthy people should be able to do that. People who care, so that we don't have to. People we can trust. This is how Linux distributions work and you just don't see malware randomly making its way into official repositories.

peteatphylum 5y ago
I wish it worked that way. I just peeked into how python packages in debian-based distros work. They are most frequently PyPI packages with some debian wrapping, so we're back at the same problem.
- matheusmoreira 5y ago
  PyPI allowed me to make an account and just push packages there like it was nothing. Great for me, not so great for users. These Debian wrappers, however minimal, imply the existence of a maintainer trusted by the Debian community. It's assumed that this maintainer has read the source code and determined it is safe.
  - djbusby 5y ago
    Or at least pinned a version that is known good
nijave 5y ago
You can DIY. There's also plenty of reputation dependency scanners out there (especially in the corporate world) that will look at license, commit rate, number of committers, release frequency, transitive dependencies, etc and generate "safety" score for you E.g. "This is maintained by a huge network of contributors who contribute to other huge projects" vs "This is a single developer with a couple commits a year"