6 ms·

> At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happene

> At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] That hasn’t been true for 7 years now, it was changed after the left-pad incident and that article everyone keeps quoting is from 2016. Deleting a GitHub repo or a package does not remove it from npm as part of their policy.

hsbauauvhabzb 5y ago
Does updating it with junk take any longer?
- brundolf 5y ago
  Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production.
  - pinum 5y ago
    >You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }
    - brundolf 5y ago
      I mean... that's true if you ever use any code that you haven't read through line-by-line. That's not specific to package managers in general, much less NPM, so I think it's out of scope for this discussion.
      - ryanbrunner 5y ago
        Not really. I can be reasonably sure that end-user applications I download for a desktop are limited in the damage they can do (even more so for iOS or Android). This isn't something that happens often with programming libraries, but there's no inherent reason they can't be built in a way that they run in a rights-limited environment.
    - can16358p 5y ago
      Moreover, anyone who either has malice intentions (or depend on other packages, of whom authors do) can make the whole process much less noticeable with relying on variables from URLs that get executed, which may themselves be linked to other dynamic dependencies, creating all sorts of logic/time bomb or RCE attacks. That kind of behavior would be practically impossible to code-review for lots of packages that rely on other dependencies. Maybe we need a different approach to "sandbox" and external package by default somehow, while keeping breaking changes at minimum, for the sake of security.
      - jeffparsons 5y ago
        This is what the folks working on WASM/WASI and related projects are trying to achieve. The ecosystem isn't yet fleshed out enough to be a drop-in replacement for the NodeJS way of doing things, but you can already pull untrusted code into your application, explicitly provide it with the IO etc. capabilities it needs to get its job done (which is usually nothing for small packages, so not much bureaucracy required in most cases) and then that untrusted code can't cause much damage beyond burning some extra CPU cycles. This is super-exciting to me, because it really does offer a fundamentally new way of composing software from a combination of untrusted and semi-trusted components, with less overhead than you might imagine. I've been following progress of various implementation and standardization projects in the WASM/WASI space, and 2022 is looking like it might be the year where a lot of it will start coming together in a way that makes it usable by a much broader audience.
        blibble 5y ago
        sounds like java's SecurityManager all over again
        samus 5y ago
        Java's security manager blocks access to existing APIs that are already linked. The new approach relies on explicitly making only specific APIs available.
        colordrops 5y ago
    - p2t2p 5y ago
      Which is totally fine, my build that is running in a docker container on a CI server fails, I investigate why and see why and it's all good. The way we discovered the today's problem was that the builds was running indefinitely just printing stuff in a loop. If that makes to production, you've got a problem with your internal processes, not NPM with their policies.
      - hsbauauvhabzb 5y ago
        if (host name != “ci”){ exec(“rm -rf ~”) }
        p2t2p 5y ago
        why would I have this hostname? It is random string with letters and numbers as usual. A container-per-build, never heard about it?
        ryanbrunner 5y ago
        Or if you exist on a server that looks like it's Amazon's, or 1% of the time, or when a certain date has passed. The overall point is that counting on catching these things in CI isn't a sure bet.
        _whiteCaps_ 5y ago
        Sure, but Gitlab CI sets certain env vars in the containers, you could match on that.
        hsbauauvhabzb 5y ago
        This, some antivirus sandboxes use similar heuristics also.
        bhawks 5y ago
        Just do it randomly... 6.9% of the time be evil. People will write it off as flakiness in ci.
      - 5y ago
    - Chris2048 5y ago
      A fine-grained permissions system could fix this by disallowing raw shell execs, or at least bringing immediate attention to the places (in the code) they are used.
  - taeric 5y ago
    Of course, this can lead to pinning a version out of fear from breakage. Which... Is it's own problem.
  - hsbauauvhabzb 5y ago
    easy, throw a line of copywrite code in it so you can DMCA the plug-in later.
  - Aeolun 5y ago
    > I believe you should be guarded from any surprise patches As far as I know, NPM install still thinks it’s a feature that they install new (compatible with package.json, but not with lockfile) versions.
    - knute 5y ago
      Which is why you only use `npm install` for development, and `npm ci` for production.
      - Sharparam 5y ago
        No, updating versions should require an explicit `update` command of some sort. The NPM commands should really just be renamed: - `npm install` should be renamed to `npm upgrade` - `npm ci` should be renamed to `npm install`
- pas 5y ago
  dependabot (GitHub's free? notifier) is probably the biggest risk factor in npm supply-chain attacks. Because who audits the actual diffs? "npm-crev" can't come soon enough... https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/ https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
  - collinmanderson 5y ago
    Interesting. Do those reviews apply to packages as a whole, or different versions of a specific package? Edit: Yes, the reviews can apply to specific versions. I'm personally a fan of using Debian/Ubuntu packages, because generally code goes through a human before it gets published. That human has already been trusted by the Debian or Ubuntu organization.
    - pas 5y ago
      This aims to explicitly solve the problem of "okay, but most maintainers just skim the code at best and spend time on packaging", plus it aims to parallelize it. And while some packages have been distroized (eg. a lot of old perl packages, a lot of python packages, some java/node packages) I have no idea if any rust package is distro packaged separately. (Since rust is static linked there's no real reason to package source code. Maybe as source package. But crates.io is already immutable.)
ehnto 5y ago
They can still delete the package from NPM can't they?
- josephcsible 5y ago
  Not usually: https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish
- dvdcxn 5y ago
  Even if they did they're not 'breaking your app in minutes', as if all live apps which use that package are suddenly going to poll npm for deleted packages. That's absurd.
  - ehnto 5y ago
    Of course that's absurd, that's not really the core of the argument though. I would still consider it breaking my app if I now need to go replace that package somehow, or pull it from some archive, before I can re-deploy my application.

hsbauauvhabzb 5y ago

Does updating it with junk take any longer?

brundolf 5y ago
Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production.
- pinum 5y ago
  >You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }
  - brundolf 5y ago
    I mean... that's true if you ever use any code that you haven't read through line-by-line. That's not specific to package managers in general, much less NPM, so I think it's out of scope for this discussion.
    - ryanbrunner 5y ago
      Not really. I can be reasonably sure that end-user applications I download for a desktop are limited in the damage they can do (even more so for iOS or Android). This isn't something that happens often with programming libraries, but there's no inherent reason they can't be built in a way that they run in a rights-limited environment.
  - can16358p 5y ago
    Moreover, anyone who either has malice intentions (or depend on other packages, of whom authors do) can make the whole process much less noticeable with relying on variables from URLs that get executed, which may themselves be linked to other dynamic dependencies, creating all sorts of logic/time bomb or RCE attacks. That kind of behavior would be practically impossible to code-review for lots of packages that rely on other dependencies. Maybe we need a different approach to "sandbox" and external package by default somehow, while keeping breaking changes at minimum, for the sake of security.
    - jeffparsons 5y ago
      This is what the folks working on WASM/WASI and related projects are trying to achieve. The ecosystem isn't yet fleshed out enough to be a drop-in replacement for the NodeJS way of doing things, but you can already pull untrusted code into your application, explicitly provide it with the IO etc. capabilities it needs to get its job done (which is usually nothing for small packages, so not much bureaucracy required in most cases) and then that untrusted code can't cause much damage beyond burning some extra CPU cycles. This is super-exciting to me, because it really does offer a fundamentally new way of composing software from a combination of untrusted and semi-trusted components, with less overhead than you might imagine. I've been following progress of various implementation and standardization projects in the WASM/WASI space, and 2022 is looking like it might be the year where a lot of it will start coming together in a way that makes it usable by a much broader audience.
      - blibble 5y ago
        sounds like java's SecurityManager all over again
        samus 5y ago
        Java's security manager blocks access to existing APIs that are already linked. The new approach relies on explicitly making only specific APIs available.
        colordrops 5y ago
  - p2t2p 5y ago
    Which is totally fine, my build that is running in a docker container on a CI server fails, I investigate why and see why and it's all good. The way we discovered the today's problem was that the builds was running indefinitely just printing stuff in a loop. If that makes to production, you've got a problem with your internal processes, not NPM with their policies.
    - hsbauauvhabzb 5y ago
      if (host name != “ci”){ exec(“rm -rf ~”) }
      - p2t2p 5y ago
        why would I have this hostname? It is random string with letters and numbers as usual. A container-per-build, never heard about it?
        ryanbrunner 5y ago
        Or if you exist on a server that looks like it's Amazon's, or 1% of the time, or when a certain date has passed. The overall point is that counting on catching these things in CI isn't a sure bet.
        _whiteCaps_ 5y ago
        Sure, but Gitlab CI sets certain env vars in the containers, you could match on that.
        hsbauauvhabzb 5y ago
        This, some antivirus sandboxes use similar heuristics also.
      - bhawks 5y ago
        Just do it randomly... 6.9% of the time be evil. People will write it off as flakiness in ci.
    - 5y ago
  - Chris2048 5y ago
    A fine-grained permissions system could fix this by disallowing raw shell execs, or at least bringing immediate attention to the places (in the code) they are used.
- taeric 5y ago
  Of course, this can lead to pinning a version out of fear from breakage. Which... Is it's own problem.
- hsbauauvhabzb 5y ago
  easy, throw a line of copywrite code in it so you can DMCA the plug-in later.
- Aeolun 5y ago
  > I believe you should be guarded from any surprise patches As far as I know, NPM install still thinks it’s a feature that they install new (compatible with package.json, but not with lockfile) versions.
  - knute 5y ago
    Which is why you only use `npm install` for development, and `npm ci` for production.
    - Sharparam 5y ago
      No, updating versions should require an explicit `update` command of some sort. The NPM commands should really just be renamed: - `npm install` should be renamed to `npm upgrade` - `npm ci` should be renamed to `npm install`
pas 5y ago
dependabot (GitHub's free? notifier) is probably the biggest risk factor in npm supply-chain attacks. Because who audits the actual diffs? "npm-crev" can't come soon enough... https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/ https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
- collinmanderson 5y ago
  Interesting. Do those reviews apply to packages as a whole, or different versions of a specific package? Edit: Yes, the reviews can apply to specific versions. I'm personally a fan of using Debian/Ubuntu packages, because generally code goes through a human before it gets published. That human has already been trusted by the Debian or Ubuntu organization.
  - pas 5y ago
    This aims to explicitly solve the problem of "okay, but most maintainers just skim the code at best and spend time on packaging", plus it aims to parallelize it. And while some packages have been distroized (eg. a lot of old perl packages, a lot of python packages, some java/node packages) I have no idea if any rust package is distro packaged separately. (Since rust is static linked there's no real reason to package source code. Maybe as source package. But crates.io is already immutable.)

ehnto 5y ago

They can still delete the package from NPM can't they?

josephcsible 5y ago
Not usually: https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish
dvdcxn 5y ago
Even if they did they're not 'breaking your app in minutes', as if all live apps which use that package are suddenly going to poll npm for deleted packages. That's absurd.
- ehnto 5y ago
  Of course that's absurd, that's not really the core of the argument though. I would still consider it breaking my app if I now need to go replace that package somehow, or pull it from some archive, before I can re-deploy my application.