Hacker News Reader

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

Hasn't this been an ongoing issue with npm since pretty much its inception? I remember reading articles about this vulnerability and the hijacking of packages that were taken down temporarily years ago.

How has this not been dealt with systematically yet?

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.

Afterwords NPM came out with a blog post[2] where they went out of their way to take as little blame as possible and basically said it was the developers fault. They said they "stand by [their] package name dispute resolution policy, and the decision to which it led"- basically ensuring that no developer should ever trust their repository in the long term, as they'll happily hand over any package name to a corporate entity if that entity asks for it.

The weird thing is that they claimed to make it impossible to "unpublish" packages, so that developers could no longer rage quit their site, but apparently they didn't extend that new requirement to their own "security" systems.

[1] http://azer.bike/journal/i-ve-just-liberated-my-modules/ [2] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

This is exactly the incident I was thinking of, thank you.

It is bizarre that npm hasn't resolved these kinds of situations by now. Makes me glad I've continued to stay away from that ecosystem.

I don't think the dispute resolution process makes them untrustworthy. It's an annoyance. It's the unpublishing that's a huge security flaw vector, and the fact that they didn't actually fix what they claimed is pretty bad.

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 claimed to have solved the unpublishing problem when they apparently hadn't is pretty huge, as is the fact that the flaw exists to begin with. Unfortunately NPM is just not a trustworthy company.

I agree as well. The guy published his kik package well before Kik was even a company. There was no reason for the npm team to resolve the situation they way they did. If someone already owns your Twitter ID or Facebook page name, well they're closed private services. Same if someone buy's your domain name (see the case of Nissan).

You don't have a right to a name on every service on the planet just because you trademark it somehow.

> 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 fairly sure npm won't blindly hand over a package that is depended upon, to another entity. When they handed over 'kik' it wasn't in the same league as 'left-pad' which was widely depended upon.

> What you say is also a problem. The fact that they claimed to have solved the unpublishing problem when they apparently hadn't is pretty huge

I agree it sucks, but the fact is they 'prevented unpublishing' to bug-fix one vector for this problem, but then introduced a bug in process that appears very similar to unpublishing. If you've never had this sort of thing happen to you as a software dev, (had some stakeholder question 'but I thought you'd fixed X') you're very very lucky.

> as is the fact that the flaw exists to begin with.

Easy to criticise in hindsight. At the time of left-pad, several other package registries (e.g. PyPI) also allowed unpublishing.

>> 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 makes you trust them in this matter? They haven't displayed such behaviour, and their behaviour up until now slightly suggests the opposite.

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

And, if I recall correctly, trademarked when? Wasn't leftpad.js's author using the name kik well before the company Kik existed? So you don't just need a name that's not trademarked _now_, you need to pick one that no-one else trademarks sometime in the future (in whatever jurisdictions the npm people care about)...

> 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

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.

How many times does it have to happen to warrant concern?

Trust, once broken, isn't quickly restored.

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?

Pretty sure "allover" isn't "significantly depended upon" - how would you feel if YC gave that account here to me just because I went and paid for a trademark on it?

I have no investment in this username, so I wouldn't care.

And "significantly depended upon" doesn't make sense in your example, but is relevant in terms of a package in a registry.

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.

I'm not arguing what's legal. If your package name is a trademark, thinking you're entitled to hang on to it is naive. This is well understand with domains, so why do you think a package registry should be different?

Just had a quick look - the "kik" package isn't in even use anymore - the whole thing was just drama theatre from by a messaging app I've never heard of. Despite it having 200 million users. Apparently.

> a messaging app I've never heard of. Despite it having 200 million users. Apparently.

Yeah it's tough for me to keep track of which apps are/aren't significant because I'm not in the loop with every community out there.

I'm guessing the users are distributed among small pockets in a network of people who all know each other -- like how in the 1990s there were pockets of "MSN Messenger" and pockets of "Yahoo Instant Messenger" and pockets of "AOL Instant Messenger" users randomly scattered around various schools. OR like how Orkut grew so precipitously in Brazil.

Or it's a generational thing -- I think there is a certain age group of people in the US who used Yik Yak, another who uses tbh and co, and so on.

I would generally trust Facebook employees to tell me which apps are "real" / growing since they have Onavo surveillance and other sources (https://www.wsj.com/articles/facebooks-onavo-gives-social-me...). But aside from those data, I'm not sure how else to keep track of which apps are "real" / big.

Kik is mostly popular outside the west, it is pretty popular in South East Asia.

In the US Kik has a pretty active userbase; but it's demographics skew older, poorer and more female and more rural. So that might be why you haven't heard of it.

Are you sure? This wasn't my impression and what I'm seeing from a quick Google is pretty different on multiple counts:

"Quite surprisingly, close to 70% of Kik’s users are men. It is most popular among young men between ages 20-24. Vine and Flickr are popular among men too, though their users tend to be a little older: 25-29 and 35-39, respectively. Not so surprisingly, Instagram and Pinterest are more popular among women than men. Women also prefer Facebook Messenger over WhatsApp and Kik"

http://www.vertoanalytics.com/the-demographics-of-social-med...

Kik is pretty popular among camgirls. Usually paying for a subscription to them gets you added to their contents on Kik so you can chat with them.

I wouldn't associate that with older, rural people. More female, sure... but then you've also got their male followers.

Older?! Kik’s demographic is far younger than anything.

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.

IIRC, Tuomo was also dissatisfied with the state of Linux on the desktop in general.

A huge chunk of that was that he was fed up with stable distributions shipping older versions of his software, so he'd get inundated by bug reports from users who were reporting things he'd already fixed. He argued that distros like Debian Stable and RHEL were actually more prone to bugs because of this. He wanted distros to use either rolling release or the Microsoft/Apple model, where the OS vendor only ships the base OS and all other software is acquired from third parties.

Because of this, he ended up putting in a termination clause in his license:

> 3. Redistributions of this software accessible plainly with a name

> of this software ("ion", "ion3", etc.), must provide the latest

> release with a reasonable delay from its release (normally 28 days).

> Older releases may be distributed, if the full version, or some

> other explicit indicator, such as the word "ancient", is part of

> the name that the package is accessed with, or if this identifier

> is completely unrelated to a name of this software.

+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

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

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 been doing it for years. You can also get package download/install tools that will check the signature. But then what?

What people really mean when they say there should be "signed packages" is that there should be a whole bunch of invisible infrastructure (set up by... who, exactly? Maintained by... who, exactly?) to decide which PGP keys are authorized to sign releases of which packages. And that's close to an intractable problem for an anyone-can-contribute community repository like npm or PyPI.

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.

Do you suppose FB+Yarn is in a position to compete? Yarn can implement support for optional package signing. From the consumer's perspective, one can choose to be alerted whenever the "main" package signer (usu. developer) changes, or simply to accept only packages verified and signed by a group of trusted third parties.

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?

"Those who cannot remember the past are condemned to repeat it" -- George Santayana

Now, it is easy enough to lob an aphorism but an event like this means that lessons previously learnt have been ignored (for whatever reason).

If you are going to build something that replicates or advances on previous systems the least you can do is study those systems to see what they did right and what they did wrong. In my opinion the Javascript ecosystem has produced some wonderful new systems that do things that have never been done before but in doing so they have wilfully ignored the past and didn't learn some basic lessons. In doing so they muddy the waters and in the end bring down the reputation of the whole ecosystem. I guess then it is not a huge surprise that a sizeable number of people feel that an unusually large number, as a percentage, of Javascript projects come and go and keep reinventing the wheel.