5 ms·

Move fast and break things. I view this as an endemic fault of how npm, and to a larger extent javascript, culture works and thinks. I believe npm to be a gia

Move fast and break things. I view this as an endemic fault of how npm, and to a larger extent javascript, culture works and thinks. I believe npm to be a giant landmine of untrustwothy packages thrown together. No package is trustyworthy as the dependency chain runs too wide and too deep. And having unwieldy dependency trees is considered a feature of npm.

raesene9 8y ago
Unfortuntely, whilst npm is the largest source of packages, it's not the only place where this problem exists. Most programming languages have this issue to one degree or another, which is that they have a package management repository where there is no curation of content, and generally no package signing (there are some cases where that exists, but the take-up isn't always great). The challenge is that this now seems to be embedded in the culture of a lot of development, and changing that culture would be very challenging, I'd imagine.
- kevin_b_er 8y ago
  Yes. The fast moving package management dependency hell seems to be spreading, but I believe its root comes from npm/javascript. If we see it elsewhere it is because it is borrowed from javascript as it was seen as "the future" of software development.
  - pcwalton 8y ago
    The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5.
    - tomjakubowski 8y ago
      In case anyone is unfamiliar with Perl's version history like I was, Perl 5 and CPAN date to 1994.
    - dragonwriter 8y ago
      > The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5. The concept is significantly older, but the implementation of a systematic facility for it rather than more ad hoc mechanisms may date from then. (It's a lot harder to sneak in and use an exploit in books of source code used in the 1970s-80s, though; convenience comes with a price.)
stefan_ 8y ago
This must be the fifth incident that could have been readily prevented if npm simply required signing for it's packages. Just do the same thing we have for SSH: on first connection (installation), ask if you trust the other side. That goes into your authorized_keys (lock file). If you connect again (update) and the key changed, print a big scary warning. No blockchain needed.
- yuchi 8y ago
  This was, from the eyes of npm Inc. and everyone else a completely legitimate ownership transfer. There was a "human error" (Domenic trusting the wrong person) that was completely unpreventable by technological means. There was no hijacking involved.
  - stefan_ 8y ago
    There is also never hijacking involved when the SSH key of my server changes, but that doesn't mean I trust SSH Inc. to verify that for me.
    - yuchi 8y ago
      In your metaphor this would be not one of your servers, but a customer’s one. Then the customer says: «oh yes, we changed the keys, it’s all ok».
tschellenbach 8y ago
This exploit is not NPM specific, could be any programming language. (Though NPM is a bit easier to exploit since there are so many packages and a large tree of deps)
- dkns 8y ago
  Would it be possible to put compromised package in Debian repository? Or has something like this happened in the past?
  - flukus 8y ago
    It's certainly possible but to my knowledge hasn't happened. This case specifically where a random person got the authority to publish new versions would be prevented by debians organisational policies. Other distro's are much less stringent and open to this kind of attack though, arch/yaort for instance will happily install straight from github and this exact scenario could have played out there. The gatekeeper model is a proven one, be it an organisation like debian, a paid curator like redhat or a locked down ecosystem like iOS.
- trickstra 8y ago
  the mindset where handing over a package with 2 million weekly downloads to a complete stranger is a totally OK thing to do IS npm specific.

raesene9 8y ago

Unfortuntely, whilst npm is the largest source of packages, it's not the only place where this problem exists. Most programming languages have this issue to one degree or another, which is that they have a package management repository where there is no curation of content, and generally no package signing (there are some cases where that exists, but the take-up isn't always great). The challenge is that this now seems to be embedded in the culture of a lot of development, and changing that culture would be very challenging, I'd imagine.

kevin_b_er 8y ago
Yes. The fast moving package management dependency hell seems to be spreading, but I believe its root comes from npm/javascript. If we see it elsewhere it is because it is borrowed from javascript as it was seen as "the future" of software development.
- pcwalton 8y ago
  The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5.
  - tomjakubowski 8y ago
    In case anyone is unfamiliar with Perl's version history like I was, Perl 5 and CPAN date to 1994.
  - dragonwriter 8y ago
    > The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5. The concept is significantly older, but the implementation of a systematic facility for it rather than more ad hoc mechanisms may date from then. (It's a lot harder to sneak in and use an exploit in books of source code used in the 1970s-80s, though; convenience comes with a price.)

stefan_ 8y ago

This must be the fifth incident that could have been readily prevented if npm simply required signing for it's packages. Just do the same thing we have for SSH: on first connection (installation), ask if you trust the other side. That goes into your authorized_keys (lock file). If you connect again (update) and the key changed, print a big scary warning. No blockchain needed.

yuchi 8y ago
This was, from the eyes of npm Inc. and everyone else a completely legitimate ownership transfer. There was a "human error" (Domenic trusting the wrong person) that was completely unpreventable by technological means. There was no hijacking involved.
- stefan_ 8y ago
  There is also never hijacking involved when the SSH key of my server changes, but that doesn't mean I trust SSH Inc. to verify that for me.
  - yuchi 8y ago
    In your metaphor this would be not one of your servers, but a customer’s one. Then the customer says: «oh yes, we changed the keys, it’s all ok».

tschellenbach 8y ago

This exploit is not NPM specific, could be any programming language. (Though NPM is a bit easier to exploit since there are so many packages and a large tree of deps)

dkns 8y ago
Would it be possible to put compromised package in Debian repository? Or has something like this happened in the past?
- flukus 8y ago
  It's certainly possible but to my knowledge hasn't happened. This case specifically where a random person got the authority to publish new versions would be prevented by debians organisational policies. Other distro's are much less stringent and open to this kind of attack though, arch/yaort for instance will happily install straight from github and this exact scenario could have played out there. The gatekeeper model is a proven one, be it an organisation like debian, a paid curator like redhat or a locked down ecosystem like iOS.
trickstra 8y ago
the mindset where handing over a package with 2 million weekly downloads to a complete stranger is a totally OK thing to do IS npm specific.