Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Npm operational incident, 6 Jan 2018

blog.npmjs.org

Post reply on HN
Print view View original

171–180 of 197 posts

Re: Npm operational incident, 6 Jan 2018

#171

Post by t3rmi »

yoodenvranx wrote: post #99
flavio81 wrote: post #74

It is really another embarrasment for NPM, considering that this is not the first time something similar happens (see: left-pad issue, 23 march 2016) So they learnt zero from it. Then, WHEN ARE THEY GOING TO SIGN THOSE PACKAGES? Zero, nothing. They didn't learn from mistakes, they don't listen. NPM is still open to all sorts of malicious use. Besides NPM problems, yesterday many packages won't work because package "p…

Someone should grab the 100 most used packages which contain less than 30 lines of code, merge it into one package and call it 'npm standard library'.

The problem would be maintaining and versioning this standard library.

Re: Npm operational incident, 6 Jan 2018

#172

Post by INTPenis »

Since everything uses HTTP these days I think they could use one of the 20x codes to signal when a package has been affected by spam management or suspension.

That way the official clients would support it but you could easily ignore it if you wanted to.

Re: Npm operational incident, 6 Jan 2018

#173

Post by y0ghur7_xxx »

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?

Publish you package on an http reachable git server and use that as location for your package.

Re: Npm operational incident, 6 Jan 2018

#174

Post by [deleted] »

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…

[deleted]

Re: Npm operational incident, 6 Jan 2018

#175

Post by Jare »

krapp wrote: post #127
Jare wrote: post #122

Earlier quoted context omitted.

In theory, deleted packages can't be taken over, their name remains reserved unless the company assigns it manually via some administrative process. That is, unless there are bugs which can actually delete packages, which seems to be the case here. Namespaced packages/repos have their own problems (figuring out which is the "good" one after some time and a few forks happen)

>Namespaced packages/repos have their own problems (figuring out which is the "good" one after some time and a few forks happen) Most if not all of these packages are hosted somewhere like Github. It's not hard to tell which repo has the most stars, fewest issues or most recent commit, that work's already done for you. But, we're talking about Node packages here - many of which seem to be trivial, or single line func…

> How many forks of left-pad could one expect to find?

Javascript github repos: 70 of left-pad and 29 of leftpad. Some are jokes, but still...

If you try the C++ package manager conan.io you will likely run into similar troubles. See for example https://github.com/lasote/conan-zlib/issues/23

Re: Npm operational incident, 6 Jan 2018

#176

Post by tragic »

ubernostrum wrote: post #169
micaksica wrote: post #131

Earlier quoted context omitted.

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…

This is your occasional reminder that package signing is not a panacea, and as typically proposed for community package repositories like npm, PyPI, etc. would likely do absolutely nothing. For example, people often insist in the Python world that PyPI should support package signing. But it already does -- you can generate a signature for a package and upload the signature with the package. Django does this, and has…

This is a very important point. I work for a company that publishes client libs for many different package indexes (although not npm). This is a fairly well automated process, but it takes minutes (if that) to push a new version to pypi, rubygems etc, but at least a few hours of fiddling about to get something on maven, which of course has this security infrastructure.

An analogy might be drawn with the app stores. We all know it is massively easier to get stuff in the play store than the iOS store. We all know there is a shit ton of spam, malware etc on the play store and not really in the other. But it's also much easier to contribute to. It's a trade off. Security is important, but sometimes I feel that people are unwilling to treat it as an input in a basic cost benefit analysis, instead turning it into a kind of absolute value. I accept that it is not treated seriously enough by many in the community, but overcorrection is not the answer.

Of course, other relatively 'open' package indexes exist that do not have npm's typo squatting issues, so there are other design issues at work in this particular case.

Re: Npm operational incident, 6 Jan 2018

#177

Post by Kliment »

mcny wrote: post #143
allover wrote: post #86

Earlier quoted context omitted.

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

Trouble is, if they do that, someone else will quickly replace them, take over the same function, and users will likely not notice that they are now trusting a different unverifiable entity to ensure package integrity

Re: Npm operational incident, 6 Jan 2018

#180

Post by mcny »

Kliment wrote: post #177
mcny wrote: post #143

Earlier quoted context omitted.

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.

Trouble is, if they do that, someone else will quickly replace them, take over the same function, and users will likely not notice that they are now trusting a different unverifiable entity to ensure package integrity

Users will continue to trust what comes packages with node. Nothing needs to change from a user's perspective. They will still type npm ... But it will point to a new infrastructure (and more importantly led by nobody currently leading npm).

If node wants to do this, I think they totally can. There just needs to be the will to cut off and blacklist the current npm team.

Post reply on HN