Hacker News Reader

Comment by kevin_b_er | Hacker News Reader

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.

View on HN

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.

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.

The concept of code sharing—which is a good thing, this incident notwithstanding—goes all the way back to CPAN and Perl 5.

In case anyone is unfamiliar with Perl's version history like I was, Perl 5 and CPAN date to 1994.

> 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.)

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)

Would it be possible to put compromised package in Debian repository? Or has something like this happened in the past?

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.

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.

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.

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.

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.

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».

Reply on news.ycombinator.com