Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

81–90 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#81
post #54

> who believed that a malicious actor or security breach was to blame This was a security breach. Their anti-spam system should block repos by freezing the module name and returning blank files, not by deleting the entire module and subsequently allowing anyone to upload new modules. This is leftpad all over again. Update: Woah, so I was checking out my old NPM namespaces and apparently someone took control over http…

It's not a "breach" technically. No malicious person caused the packages to be removed by circumventing authentication/authorization systems. It is a security issue though. A bug and serious security issue, yes, but not technically a breach.

A breach didn't cause the issue, but there absolutely was a breach in response to NPM's incompetence. https://news.ycombinator.com/item?id=16087126

Re: Npm operational incident, 6 Jan 2018

#82
post #2

As others have said countless times on the original thread: new packages from different users should never have been allowed to replace the missing packages. Even if a package is removed as malware, a user should never unexpectedly download the work of a totally new author that they haven't vetted. Some of the protections should be done on the user side, but that's no reason for NPM to have dangerous policies.

> but that's no reason for NPM to have dangerous policies.

Oversight != 'dangerous policies'. Seems like they thought they had this fixed.

Re: Npm operational incident, 6 Jan 2018

#83

Earlier quoted context omitted.

+1 I think it's shocking how NPM tries to subtly shift fault to "well-meaning members of the npm community" for costing NPM "additional steps and time". Shame on npm. This shouldn't have even been possible after the azer/kik issue a few years back.

I'm not a javascript dev, but isn't NPM volunteer run? It seems odd to be shaming people who do something for you as a volunteer free service.

It's a company: https://www.npmjs.com/about

Re: Npm operational incident, 6 Jan 2018

#84
post #22

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…

It's not surprising since the NPM CEO is a notorious "social justice warrior" who doesnt want white people to apply to talk at conferences: https://twitter.com/izs/status/911105515798720513

Its not hard to see why this preoccupation with regressive ideas leads to problems actually running the company and building a product. The downvotes will speak for themselves here though...

Re: Npm operational incident, 6 Jan 2018

#85

Earlier quoted context omitted.

the official node.js Docker image comes with yarn as well as npm. but this is an issue with the npm registry, not the package manager shipped with node. both yarn and npm use the npm registry. EDIT: it may be worth debating why npm (a binary produced by npm, Inc) is shipped with node.js at all, but that's upto the node foundation

I’m pretty sure npm is shipped as Javascript source by node.js

ah yes, you are correct. it isn't a binary

Re: Npm operational incident, 6 Jan 2018

#86
post #68
post #59

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

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

Re: Npm operational incident, 6 Jan 2018

#87
Such explanation looks misleading to me. Even having the module detected as potentially malicious, why was it put into a state that such module doesn't exist, letting others publish package with the same name. For me it looks like there is something wrong at the npm side internally with the processes.

Re: Npm operational incident, 6 Jan 2018

#89
post #78

> We don’t discuss all of our security processes and technologies in specific detail for what should be obvious reasons, but here is a high-level overview. Isn't that the opposite of good practice? You shouldn't rely on obscurity. It's better to have the security processes out in the open so that it can be audited and flaws pointed out.

I think it's

> We don’t discuss all of our security processes and technologies [with each other internally, so dumb stuff keeps happening]

Re: Npm operational incident, 6 Jan 2018

#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 package with the same name? Almost no software published there have unit tests, asking developers how they tested it in a GitHub issue leaves the issue open with no response. Everything is centralized on GitHub, which was proven to fail many times when GitHub was down in a region or globally due to a DDoS. Why is Node allowed to exist? We're not in 1998 anymore.

[1] https://news.ycombinator.com/item?id=16092584 (comment above)

[2] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

Post reply on HN