Npm operational incident, 6 Jan 2018 • Hacker News Board

Re: Npm operational incident, 6 Jan 2018

#131

Post by micaksica » Mon, Jan 08, 2018, 1:20 AM UTC

tedivm wrote: post #14

> Unfortunately, the process was complicated by well-meaning members of the npm community who believed that a malicious actor or security breach was to blame and independently attempted to publish their own replacements for these packages. Ensuring the integrity of the affected packages required additional steps and time. That is such a bad response to this. The problem isn't that "well-meaning members of the communi…

It's been literally years since node-forward got its talk about signing packages [1] with a lot of pushback from the npm team. Every time a new typosquatting article shows up, there's some more waffling by npm. left-pad happened to much consternation. Now this.

I used to really care about trying to harden the Node ecosystem, and last year it was one of my main goals. I tried to send multiple vulnerability reports, do mass static analysis of npm packages, and wanted to contribute more to the ecosystem, but the consistent ambivalent reactions of much of the community that I talked to turned me off of the project entirely. If npm wants to continue to be a security dumpster fire, let it burn. Node is a waste of security researchers' time and an honest goldmine for black hats looking to compromise relatively powerful novice webdev hardware.

I don't see it changing anytime soon. npm is a business that isn't focused on security. These things keep coming up, and yet npm install metrics I'm sure aren't decreasing. Until they face meaningful competition and/or the rest of the Node community begins to give even half a care to security outside of this forum, there will be no incentive for anyone to do anything about it. It's easier to play PR, give a little lip service to it and dodge the problem than it is to add any friction to their potential growth.

[1] https://github.com/node-forward/discussions/issues/29

Re: Npm operational incident, 6 Jan 2018

#132

Post by toomanybeersies » Mon, Jan 08, 2018, 1:43 AM UTC

tzs wrote: post #110

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Anyone kno…

This person on reddit apparently suggested it back in 2013: https://www.reddit.com/r/webdev/comments/7oljbe/xpost_rjavas...

Relevant excerpt:

> I proposed required namespaces (@user/package) as a requirement in 2013 and the npm developers acted like I had 2 heads.

Re: Npm operational incident, 6 Jan 2018

#133

Post by kaikai » Mon, Jan 08, 2018, 1:51 AM UTC

tzs wrote: post #110

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Anyone kno…

Organizations on npm can publish "namespaced" modules, that look like `@orgName/moduleName`. It's just optional.

Re: Npm operational incident, 6 Jan 2018

#134

Post by kaikai » Mon, Jan 08, 2018, 1:59 AM UTC

A bunch of folks here are complaining that the explanation isn't good enough, doesn't go into enough detail, etc.

Literally the second sentence is:

> Early this coming week, we will share a full analysis and technical explanation of the incident.

I'm looking forward to reading the final post-mortem, but in the mean time I really appreciate their update.

Re: Npm operational incident, 6 Jan 2018

#135

Post by dzonga » Mon, Jan 08, 2018, 2:05 AM UTC

noob question : would using yarn have mitigated any of the risks of missing/broken packages ?

Re: Npm operational incident, 6 Jan 2018

#136

Post by amyjess » Mon, Jan 08, 2018, 2:10 AM UTC

tedivm wrote: post #22

ivraatiems wrote: post #18

Earlier quoted context omitted.

> The problem isn't that "well-meaning members of the community" decided to upload packages. The problem is that when their system decides that a package shouldn't be up it completely removes the package, as if it never existed, and allows the namespace to be reused immediately. Those "well-meaning members" should not even be able to hijack packages this way, as it means the people who aren't "well-meaning" can also…

Yeah, about two years ago NPM stole a package name from an existing user and gave it to a company to use. The user then said that if he can't trust NPM to actually treat package naming fairly then he was just going to delete all of his packages[1]. This broke a ton of packages on people (in part due to "left-pad" disappearing), so the community went ahead and registered/uploaded all of the packages to NPM again. Afte…

I hope this leads more developers to begin using restrictive trademark terms for their work, like Mozilla does with their software (e.g. you cannot fork Firefox and still call it "Firefox") or what Tuomo Valkonen did with ion3.

And for that matter, this sounds like a pretty strong disincentive for developers to make their code open-source at all. I'd rather just release proprietary software under a license that allows me to revoke individual entities' ability to distribute my work on a whim to prevent something like this from happening. And I mentioned Tuomo above for a reason--his experiences with ion3 and dealing with the open-source community drove him to a similar decision, and he quit writing open-source software and developing for Linux as a result. By the time he quit, he had become an active opponent of free software.

Re: Npm operational incident, 6 Jan 2018

#137

Post by jonny_eh » Mon, Jan 08, 2018, 2:13 AM UTC

noobermin wrote: post #109

pwaai wrote: post #33

Earlier quoted context omitted.

With all that money they've raised, it's puzzling why they don't take PR seriously. I guess they have a mentality of "where the fuck else are you gonna go, the node community is tightly coupled to our service"

It's almost as if the tech community has to learn once again centralized systems with a trusted authority at the top can't be trusted when that trusted authority makes mistakes.

Honest question: what's the alternative?

Re: Npm operational incident, 6 Jan 2018

#138

Post by u801e » Mon, Jan 08, 2018, 2:19 AM UTC

krainboltgreene wrote: post #130

tzs wrote: post #110

From what I've read (I've not yet worked on anything that used npm), it appears that npm uses a single shared flat namespace for all packages. If I publish a package named "order_pizza" nobody else can name a package "order_pizza", unless mine gets deleted first, and then they can...and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Anyone kno…

> and anyone who was using my "order_pizza" will now silently get the other developer's "order_pizza" the next time they build. Nope.

What if the project that requires order_pizza has no restriction on what version it pulls in?

Re: Npm operational incident, 6 Jan 2018

#139

Post by Silhouette » Mon, Jan 08, 2018, 2:28 AM UTC

jonny_eh wrote: post #137

noobermin wrote: post #109

Earlier quoted context omitted.

It's almost as if the tech community has to learn once again centralized systems with a trusted authority at the top can't be trusted when that trusted authority makes mistakes.

Honest question: what's the alternative?

Distributed systems. Mirrors. Tools that are agnostic about sources for packages.

There's no reason that we must have a single, centralised package repository for a language and the dominant tool chain for that language relying on it by default.

Re: Npm operational incident, 6 Jan 2018

#140

Post by swsieber » Mon, Jan 08, 2018, 2:29 AM UTC

Everybody is mad/disappointed at/by the NPM for their handling...

Does this have any real impact on the NPM package adoption though? There is no alternative node module package directory, is there?

It seems like any action they could have taken would have had exactly the same effect (well, maybe some prospective products don't adopt JS backends, but you have all webpack projects locked in pretty tight, right?)