Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

141–150 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#141
post #90
post #13

How can they claim no malicious actors were involved when packages such as duplexer3 were apparently replaced with undesirable code as reported in https://news.ycombinator.com/item?id=16087126 ?

This is not a claim or a fact, that's probably an uneducated guess, npm is broken on so many levels they can't say anything for sure. [1] npm is full of fundamental bugs in their software, workflows, architecture, and community. We learnt this in March 2016 when one developers got a copyright claim and had to remove their package. [2] Why is it even possible to remove a package? Why is it possible to create new packa…

We learnt this in March 2016 when one developers got a copyright claim and had to remove their package. [2] Why is it even possible to remove a package?

The earlier problem you mentioned didn't seem to be about copyright. But if it had been, the answer to why it's even possible to remove a package is: because if you don't and you knowingly continue to host copyright-infringing content you can expect a very large penalty in court.

Re: Npm operational incident, 6 Jan 2018

#142

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

I've been using gitpkg (https://github.com/ramasilveyra/gitpkg) lately; it works pretty well. Basically lets you use a git repo as a package repo, instead of npm.

Very little about how I use npm requires it to be centralized; I don't ever search npm looking for a package to install; I find a package I want and then look to install it.

Re: Npm operational incident, 6 Jan 2018

#143
post #86
post #68

Earlier quoted context omitted.

>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. > You can as long as your package name isn't trademarked or likely to confuse users installing the package. Trademarked where exactly? You know, there's quite a lot of world beside US. > I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. What m…

> and their behaviour up until now slightly suggests the opposite. Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpublished it), and that is the only example I'm aware of of npm handing over a package name. [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

I cannot believe anyone will defend npm over it.

There is no scenario where it is OK to hand over a namespace to someone else. At worst, it is acceptable to make a namespace unavailable to anyone.

I think npm is completely unable to exist as an organization and should disband immediately.

Re: Npm operational incident, 6 Jan 2018

#144
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…

Nit: leftpad was not the issue. Kik was the issue. Npm incredibly mishandled the situation. I agree with the rest of your analysis.

I think the community should fork npm repository. Anything of value is free and open source anyways. Why does node continue to support npm people?

Re: Npm operational incident, 6 Jan 2018

#145
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…

> Anyone know why they did it that way instead of

Root causes wise, my impression is that software language engineering has a knowledge integration and communication problem. Lambda the Ultimate doesn't have a wiki. :) Academic papers provide a foundation, but a lot of practical professional knowledge is scattered, siloed in language communities, and time-consuming to access. Gathering best practices for language design and implementation isn't something we do well. So language creation projects often look like team and/or community "learn by doing" education exercises. Even with good people at leading companies... I had a conversation at redacted once, "why did you make (disappointing) design decision X?", "mumble mumble", " that's a (widespread) misconception, a misinterpretation of paper P (which admittedly could have been clearer), that's been kicking around for several decades now".

My fuzzy impression is the npm repo was not originally a mission focus, but rather a "don't be python" add on goal. Absent organized best practices, low-priority design decisions are often not made well. Perhaps Ruby, Perl5, and/or Python were copied, without attending to those communities experiences, and the implications for an even more fine-grained code sharing community.

Re: Npm operational incident, 6 Jan 2018

#146

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?

I've mentioned this elsewhere in this discussion, but: https://github.com/ramasilveyra/gitpkg

I've been using it a bit, and it's really nice. Yarn (and the npm command line tool) already provide nice methods to install packages from arbitrary locations, including git repos; this provides a nice mechanism for publishing to git repos. It's a super simple solution, but then, it's not really a hard problem.

Re: Npm operational incident, 6 Jan 2018

#147
post #86
post #68

Earlier quoted context omitted.

>> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. > You can as long as your package name isn't trademarked or likely to confuse users installing the package. Trademarked where exactly? You know, there's quite a lot of world beside US. > I'm actually fairly sure npm won't blindly hand over a package that is depended upon, to another entity. What m…

> and their behaviour up until now slightly suggests the opposite. Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpublished it), and that is the only example I'm aware of of npm handing over a package name. [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

Hypothetically, even if it's just the author of kik (I don't know if it is), isn't that still unfair to them? They might have used it on client projects. Why would I want to use your registry if you're going to break all of my software because a corporation wants a my package name?

Re: Npm operational incident, 6 Jan 2018

#148
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.

It's kind of unbelievable that NPM is a for-profit company that serves the node community for free. You can't possibly expect them to make the right choices when the community isn't whom they are directly responsible to. NPM should be a nonprofit foundation, a coop, or some other organization that has its operations funded by the community and has elected positions.

Their lack of financial or other interests in the community directly explains their policies.

Re: Npm operational incident, 6 Jan 2018

#150
post #59
post #32

Earlier quoted context omitted.

To me it's a trust issue. Their dispute policy breaks trust in two ways- 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. What you say is also a problem. The fact that they…

> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. You can as long as your package name isn't trademarked or likely to confuse users installing the package. > 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. I'm actually f…

Trademarks only apply within a common industry. Kik the company isn't in the business of creating NPM packages. It's perfectly legal to use the same name for something unrelated to messaging even after the founding date of the commercial entity.
Post reply on HN