5 ms·

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

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

tedivm 9y ago
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/ http://azer.bike/journal/i-ve-just-liberated-my-modules/ [2] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
- Dylan16807 9y ago
  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.
  - tedivm 9y ago
    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.
    - allover 9y ago
      > 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.
      - dozzie 9y ago
        >> 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.
- 5h 9y ago
  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.
  - erk__ 9y ago
    Kik is mostly popular outside the west, it is pretty popular in South East Asia.
  - mherdeg 9y ago
    > 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-media-firm-inside-peek-at-rivals-users-1502622003 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.
  - olefoo 9y ago
    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.
    - dannyw 9y ago
      Older?! Kik’s demographic is far younger than anything.
    - wutbrodo 9y ago
- ivraatiems 9y ago
  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.
- anon12345690 9y ago
  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 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...
- amyjess 9y ago
  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.
  - _pmf_ 9y ago
    IIRC, Tuomo was also dissatisfied with the state of Linux on the desktop in general.
    - amyjess 9y ago
      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.

tedivm 9y ago

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/ http://azer.bike/journal/i-ve-just-liberated-my-modules/ [2] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

Dylan16807 9y ago
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.
- tedivm 9y ago
  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.
  - allover 9y ago
    > 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.
    - dozzie 9y ago
      >> 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.
5h 9y ago
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.
- erk__ 9y ago
  Kik is mostly popular outside the west, it is pretty popular in South East Asia.
- mherdeg 9y ago
  > 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-media-firm-inside-peek-at-rivals-users-1502622003 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.
- olefoo 9y ago
  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.
  - dannyw 9y ago
    Older?! Kik’s demographic is far younger than anything.
  - wutbrodo 9y ago
ivraatiems 9y ago
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.
anon12345690 9y ago
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 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...
amyjess 9y ago
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.
- _pmf_ 9y ago
  IIRC, Tuomo was also dissatisfied with the state of Linux on the desktop in general.
  - amyjess 9y ago
    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.