5 ms·

I'm more of a back-end dev who doesn't know all the ins and outs of the actual software used - can someone explain to me why this is an npm problem, and not an

I'm more of a back-end dev who doesn't know all the ins and outs of the actual software used - can someone explain to me why this is an npm problem, and not an excessive dependencies problem? I thought npm was simply a package manager - I don't see anything in the article that is specific to npm, except he happens to say that word.

ufmace 9y ago
It's kind of an excessive dependencies problem, except exacerbated by two things. One is Javascript's poor stdlib. This means that not only are you tempted to include lots of little packages to do basic things, but so are all of the big packages that you include to do big things for you, and all of the packages they include, etc. Often there are a bunch of different packages for doing the same basic things, and nobody agrees on which one, so you may end up with 5 different packages that do the same thing required by various packages you use. Two is that much of it is expected to be served to the browser, so it's minified. Who audits that the minified code is actually the same as the published Github code? At least in Ruby and Python, the code from Rubygems/Pip should exactly match that version on Github. Not that anyone necessarily audits that either, but at least it's easier.
- alceta 9y ago
  In Ruby, the exact same problem applies since you can publish gems in one version and tag them in another - in the very same fashion as the article describes.
agumonkey 9y ago
I guess it's not npm per se, but js crowdsourcing factor multiplies the attack surface by large powers of ten. In other languages, having the security libs centralized and vetted "might" (you'd need an decent amount of work to ensure that it is safe) avoid getting MITM'd so easily.
mundungus_a 9y ago
The root of the problem is that a dependency can be downloaded and installed from only it's minified/obfuscated form, and without any verification that the code matches what is in the non-minified/obfuscated codebase. This is just exploited through people being dependency-happy and that no one really verifies that a package isn't doing more than what is advertised. This same problem would exist if any server-side dependency repositories allow for code to be delivered in a pre-compiled form without any verification, similar to npmjs.
downandout 9y ago
It's not specific to npm. It's a problem that generally applies to all of these package managers that introduce code that you have not personally reviewed into your site.
milesvp 9y ago
What makes npm particularly bad, is that JS has such a teribad stdlib. When you need to write your own lpad() at some point its easier to include a stupid little package that has dealt with all the edge cases you don't want to care about. So you end up with way more third party deps than a kitchen sink type language. Otherwise, yes this is a fundamental dependency issue.
- chmln 9y ago
  You can actually pad your strings now https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- swyx 9y ago
  could we actually take a snapshot of npm’s top used but relatively inert libraries every 6 months or so and freeze them? (call it UserlandJS 2018a, 2018b, etc) and then have a separate dependency manager that only downloads those frozen libraries we include. Userland Package Manager or something. this would approach a stdlib without much effort and we would have more of a chance to catch up on malicious security stuff since there are commonly agreed upon frozen versions that everyone can pore over. im a total noob at security, please attack/modify this idea if it has any value?
  - swyx 9y ago
    discussing on twitter here https://twitter.com/swyx/status/949946224043610112 https://twitter.com/swyx/status/949946224043610112
- jmadsen 9y ago
  but that has nothing to do with npm. that's the same for any javascript package manager - yarn or bower would be the same.
  - Gaelan 9y ago
    npmjs.com is the repository both yarn and npm use—this is about npmjs.com the repository, not npm the package manager per se.
drdrey 9y ago
You could arguably come up with something similar for backends. It's just a story of a malicious and sneaky dependency.
- jmadsen 9y ago
  exactly. I question all these comments by people singling out npm as the root of the problem. doesn't sound to me like they fully understand the issue.
  - rdiddly 9y ago
    npm isn't the root of the problem, it's just a particularly popular example of it. Sort of like how Intel isn't really the root of that other problem, just the implementer of speculative execution with the biggest market share.
  - IshKebab 9y ago
    Nobody is singling out NPM. The issue is the current JavaScript ecosystem and that happens to be provided through NPM, so you can use "NPM" as a shorthand for "the way JavaScript developers these days use NPM to depend on a gazillion trivial packages with totally unknown provenance".
    - jmadsen 9y ago
      why not just say "excessive dependencies" and be correct, succinct and perfectly clear?
      - IshKebab 9y ago
        Because that is the symptom. The problem is that the ecosystem encourages excessive dependencies. You can say "the way the ecosystem encourages huge dependency trees" if you like.
      - fps_doug 9y ago
        The first problem is excessive dependencies. Just one word: Left-pad. That is a library on its own, for that one simple problem. The JS ecosystem encourages that for any problem, no matter how small it is, you import some existing lib. So at the end of the day you have 100+ dependencies on a project that is only slightly larger than a "hello world" page. The next problem is that npmjs is "free for all". Imagine anyone could easily add new packages to the debian repo. Sure, I don't expect the debian folks to audit every new addition or update to existing packages, but there is at least some chain of trust, plus there is some incentive to not have malware ridden packages in your distro because it hurts your credibility. A distro is both, an infrastructure and content provider. npmjs is just the infrastructure, so it takes some more messups for people to consider moving away from it.
dbattaglia 9y ago
I think the important part is that it’s a package manager commonly used for front end development, so the malicious code runs directly in the browser. It could have been bower or something else but npm is the probably the most popular choice these days.

ufmace 9y ago

It's kind of an excessive dependencies problem, except exacerbated by two things. One is Javascript's poor stdlib. This means that not only are you tempted to include lots of little packages to do basic things, but so are all of the big packages that you include to do big things for you, and all of the packages they include, etc. Often there are a bunch of different packages for doing the same basic things, and nobody agrees on which one, so you may end up with 5 different packages that do the same thing required by various packages you use. Two is that much of it is expected to be served to the browser, so it's minified. Who audits that the minified code is actually the same as the published Github code? At least in Ruby and Python, the code from Rubygems/Pip should exactly match that version on Github. Not that anyone necessarily audits that either, but at least it's easier.

alceta 9y ago
In Ruby, the exact same problem applies since you can publish gems in one version and tag them in another - in the very same fashion as the article describes.

agumonkey 9y ago

I guess it's not npm per se, but js crowdsourcing factor multiplies the attack surface by large powers of ten. In other languages, having the security libs centralized and vetted "might" (you'd need an decent amount of work to ensure that it is safe) avoid getting MITM'd so easily.

mundungus_a 9y ago

The root of the problem is that a dependency can be downloaded and installed from only it's minified/obfuscated form, and without any verification that the code matches what is in the non-minified/obfuscated codebase. This is just exploited through people being dependency-happy and that no one really verifies that a package isn't doing more than what is advertised. This same problem would exist if any server-side dependency repositories allow for code to be delivered in a pre-compiled form without any verification, similar to npmjs.

downandout 9y ago

It's not specific to npm. It's a problem that generally applies to all of these package managers that introduce code that you have not personally reviewed into your site.

milesvp 9y ago

What makes npm particularly bad, is that JS has such a teribad stdlib. When you need to write your own lpad() at some point its easier to include a stupid little package that has dealt with all the edge cases you don't want to care about. So you end up with way more third party deps than a kitchen sink type language. Otherwise, yes this is a fundamental dependency issue.

chmln 9y ago
You can actually pad your strings now https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
swyx 9y ago
could we actually take a snapshot of npm’s top used but relatively inert libraries every 6 months or so and freeze them? (call it UserlandJS 2018a, 2018b, etc) and then have a separate dependency manager that only downloads those frozen libraries we include. Userland Package Manager or something. this would approach a stdlib without much effort and we would have more of a chance to catch up on malicious security stuff since there are commonly agreed upon frozen versions that everyone can pore over. im a total noob at security, please attack/modify this idea if it has any value?
- swyx 9y ago
  discussing on twitter here https://twitter.com/swyx/status/949946224043610112 https://twitter.com/swyx/status/949946224043610112
jmadsen 9y ago
but that has nothing to do with npm. that's the same for any javascript package manager - yarn or bower would be the same.
- Gaelan 9y ago
  npmjs.com is the repository both yarn and npm use—this is about npmjs.com the repository, not npm the package manager per se.

drdrey 9y ago

You could arguably come up with something similar for backends. It's just a story of a malicious and sneaky dependency.

jmadsen 9y ago
exactly. I question all these comments by people singling out npm as the root of the problem. doesn't sound to me like they fully understand the issue.
- rdiddly 9y ago
  npm isn't the root of the problem, it's just a particularly popular example of it. Sort of like how Intel isn't really the root of that other problem, just the implementer of speculative execution with the biggest market share.
- IshKebab 9y ago
  Nobody is singling out NPM. The issue is the current JavaScript ecosystem and that happens to be provided through NPM, so you can use "NPM" as a shorthand for "the way JavaScript developers these days use NPM to depend on a gazillion trivial packages with totally unknown provenance".
  - jmadsen 9y ago
    why not just say "excessive dependencies" and be correct, succinct and perfectly clear?
    - IshKebab 9y ago
      Because that is the symptom. The problem is that the ecosystem encourages excessive dependencies. You can say "the way the ecosystem encourages huge dependency trees" if you like.
    - fps_doug 9y ago
      The first problem is excessive dependencies. Just one word: Left-pad. That is a library on its own, for that one simple problem. The JS ecosystem encourages that for any problem, no matter how small it is, you import some existing lib. So at the end of the day you have 100+ dependencies on a project that is only slightly larger than a "hello world" page. The next problem is that npmjs is "free for all". Imagine anyone could easily add new packages to the debian repo. Sure, I don't expect the debian folks to audit every new addition or update to existing packages, but there is at least some chain of trust, plus there is some incentive to not have malware ridden packages in your distro because it hurts your credibility. A distro is both, an infrastructure and content provider. npmjs is just the infrastructure, so it takes some more messups for people to consider moving away from it.

dbattaglia 9y ago

I think the important part is that it’s a package manager commonly used for front end development, so the malicious code runs directly in the browser. It could have been bower or something else but npm is the probably the most popular choice these days.