6 ms·

It's insane that NPM allows anybody to just take over a module name if the original is unpublished, without even a warning to users.

henrikfr 11y ago
Insane, yes, but I guess it's just never really been that much of a problem until now. Hopefully something good will come out of this..
- smt88 11y ago
  > it's just never really been that much of a problem until now That's a reasonable excuse in the 90s, before automatic updates over HTTP were common. Our industry now has decades of experience securing HTTP updates and package managers, with various Linux solutions demonstrating good practices.
- CorpOverreach 11y ago
  You would think this is part of security 101 for these things... And people wonder why big enterprises are scared of touching open source stuff.
  - nyan4 11y ago
    > And people wonder why big enterprises are scared of touching open source stuff. some open source stuff. Most enterprises dig distributions, especially with LTS.
  - cyphar 11y ago
    Many big enterprises run on free software. Just because this particular free software project is a shit-show doesn't make all free software projects this bad.
- gst 11y ago
  Something similar is (or at least was) true for Github: I changed my username a couple of years ago and I recently found out that another user is now using my original username. Less of an issue due to the much longer timeframe, but I think not allowing username re-use would be a safer choice.
- FranOntanaya 11y ago
  Module repositories have been a thing for decades. Even a platform as crusty-old as WordPress doesn't allow repository take-overs for plugins. Surely someone had some experience outside npm to think about this.
na85 11y ago
Insane, yes, but not unexpected. This is the sort of amateur behaviour that is emblematic of the entire nodejs community.
- akerro 11y ago
  That's what happens when a language and framework have very low entry level, more and more not responsible people gather in one place. Yes, they make it popular and trendy, but they're dangerous for themselves and others.
  - petetnt 11y ago
    Amazingly shameful cheap shots and mudslinging against hundreds of people from both you and @na85. Bravo.
    - stonogo 11y ago
      Those people deserve criticism, because they're making bad decisions.
      - sangnoir 11y ago
        and by 'Those people', you mean the entire NodeJS community? > This is the sort of amateur behaviour that is emblematic of the entire nodejs community. This is pure mudslinging
        akerro 11y ago
        No, I'm sure he didn't meant whole community. There was a reason why njs became so popular, and there are great people behind it, but as everything that's easy to start with, it attracts people with no skills, no experience. When learning C one of the first things you learn is how operating systems work, what memory leaks are, why they are dangerous, C, C++ have higher entry level, people who stay longer with C/C++ have very good experience, they know more about security, risks, standards, systems... When you have low entry lever, you don't even bother reading on wiki what XSS is, what .ssh folder is. We just learnt the hard way that package manager for NJS is crap, just to compare it, take a look at crates of a language that has high entry level: https://www.reddit.com/r/rust/comments/4bm3rk/how_would_cratesio_react_in_a_case_similar_to_the/ https://www.reddit.com/r/rust/comments/4bm3rk/how_would_crat...
viperscape 11y ago
https://twitter.com/_scape/status/700453739182817281 https://twitter.com/_scape/status/700453739182817281 My semi relevant tweet, it's just asking for it with that warning
- irl_zebra 11y ago
  Why not just post the tweet here instead of spamming your Twitter feed?
  - viperscape 11y ago
    That's a perma link to the direct tweet... why paste in the tweet when I can just link it...
    - prodigal_erik 11y ago
      HN would be unusable if everyone stopped writing comments and just pasted links to an ephemeral third-party service.
    - aw3c2 11y ago
      http://pastebin.com/XkPwwkUs http://pastebin.com/XkPwwkUs
    - douche 11y ago
      Bravo, you've illustrated the whole problem
drdaeman 11y ago
Link rot and domain squatting are a well-known decades-old issues. NPM identifiers can be considered as just another weird form of pseudo-URIs and aren't special here. It is insane that modules don't have signatures (that are actually verified, of course). Because npm can feed you basically anything. It's not a problem that something else gets published under the old address. It's perfectly natural. The real problem is the trust model - that new content's accepted without even warnings.
choward 11y ago
It's insane that NPM allows anybody to un-publish modules to begin with. Even if I have a dependency locked down in my NPM shrinkwrap file, it can change underneath me? That is pretty absurd and gives me zero confidence in my packages. It means I MUST commit them to source control or risk having my project completely broken some day. I thought for sure that since NPM removed the ability to re-publish the same version of a package with different content that they also wouldn't let you remove versions of a package. It also means you should never user the "^" version specifier or risk downloading some completely different project. They do have a "warning" at https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish: > WARNING > > It is generally considered bad behavior to remove versions of a library that others are depending on! Seriously, what good does that do? Nobody takes warnings seriously.
- Wintamute 11y ago
  A specific version of a package is immutable on npm. So if you depend on exactly foo@1.2.3 in your shrinkwrap you'll always get the same code. In other words, even if the package is unpublished, and picked up by a new user they can't re-publish new code to 1.2.3. If you depend on a version range like ^1.2.3 or ~1.2.3 its a different story, of course. Moral of the story is imo always pin to exact versions and use shrinkwrap for production apps. EDIT: This may not be true .. see below.
  - choward 11y ago
    > A specific version of a package is immutable on NPM. That's not true. I thought it was but it's not. That's the terrible part. To demonstrate with one of the packages that was removed, run: $ npm info andthen You'll see that versions 0.0.1 and 0.0.2 were published at one point. However, for "versions" it only mentions 2.0.0. And of course, if you run: $ npm install andthen@0.0.2 It blows up in your face.
    - Wintamute 11y ago
      :o

henrikfr 11y ago

Insane, yes, but I guess it's just never really been that much of a problem until now. Hopefully something good will come out of this..

smt88 11y ago
> it's just never really been that much of a problem until now That's a reasonable excuse in the 90s, before automatic updates over HTTP were common. Our industry now has decades of experience securing HTTP updates and package managers, with various Linux solutions demonstrating good practices.
CorpOverreach 11y ago
You would think this is part of security 101 for these things... And people wonder why big enterprises are scared of touching open source stuff.
- nyan4 11y ago
  > And people wonder why big enterprises are scared of touching open source stuff. some open source stuff. Most enterprises dig distributions, especially with LTS.
- cyphar 11y ago
  Many big enterprises run on free software. Just because this particular free software project is a shit-show doesn't make all free software projects this bad.
gst 11y ago
Something similar is (or at least was) true for Github: I changed my username a couple of years ago and I recently found out that another user is now using my original username. Less of an issue due to the much longer timeframe, but I think not allowing username re-use would be a safer choice.
FranOntanaya 11y ago
Module repositories have been a thing for decades. Even a platform as crusty-old as WordPress doesn't allow repository take-overs for plugins. Surely someone had some experience outside npm to think about this.

na85 11y ago

Insane, yes, but not unexpected. This is the sort of amateur behaviour that is emblematic of the entire nodejs community.

akerro 11y ago
That's what happens when a language and framework have very low entry level, more and more not responsible people gather in one place. Yes, they make it popular and trendy, but they're dangerous for themselves and others.
- petetnt 11y ago
  Amazingly shameful cheap shots and mudslinging against hundreds of people from both you and @na85. Bravo.
  - stonogo 11y ago
    Those people deserve criticism, because they're making bad decisions.
    - sangnoir 11y ago
      and by 'Those people', you mean the entire NodeJS community? > This is the sort of amateur behaviour that is emblematic of the entire nodejs community. This is pure mudslinging
      - akerro 11y ago
        No, I'm sure he didn't meant whole community. There was a reason why njs became so popular, and there are great people behind it, but as everything that's easy to start with, it attracts people with no skills, no experience. When learning C one of the first things you learn is how operating systems work, what memory leaks are, why they are dangerous, C, C++ have higher entry level, people who stay longer with C/C++ have very good experience, they know more about security, risks, standards, systems... When you have low entry lever, you don't even bother reading on wiki what XSS is, what .ssh folder is. We just learnt the hard way that package manager for NJS is crap, just to compare it, take a look at crates of a language that has high entry level: https://www.reddit.com/r/rust/comments/4bm3rk/how_would_cratesio_react_in_a_case_similar_to_the/ https://www.reddit.com/r/rust/comments/4bm3rk/how_would_crat...

viperscape 11y ago

https://twitter.com/_scape/status/700453739182817281 https://twitter.com/_scape/status/700453739182817281 My semi relevant tweet, it's just asking for it with that warning

irl_zebra 11y ago
Why not just post the tweet here instead of spamming your Twitter feed?
- viperscape 11y ago
  That's a perma link to the direct tweet... why paste in the tweet when I can just link it...
  - prodigal_erik 11y ago
    HN would be unusable if everyone stopped writing comments and just pasted links to an ephemeral third-party service.
  - aw3c2 11y ago
    http://pastebin.com/XkPwwkUs http://pastebin.com/XkPwwkUs
  - douche 11y ago
    Bravo, you've illustrated the whole problem

drdaeman 11y ago

Link rot and domain squatting are a well-known decades-old issues. NPM identifiers can be considered as just another weird form of pseudo-URIs and aren't special here. It is insane that modules don't have signatures (that are actually verified, of course). Because npm can feed you basically anything. It's not a problem that something else gets published under the old address. It's perfectly natural. The real problem is the trust model - that new content's accepted without even warnings.

choward 11y ago

It's insane that NPM allows anybody to un-publish modules to begin with. Even if I have a dependency locked down in my NPM shrinkwrap file, it can change underneath me? That is pretty absurd and gives me zero confidence in my packages. It means I MUST commit them to source control or risk having my project completely broken some day. I thought for sure that since NPM removed the ability to re-publish the same version of a package with different content that they also wouldn't let you remove versions of a package. It also means you should never user the "^" version specifier or risk downloading some completely different project. They do have a "warning" at https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish: > WARNING > > It is generally considered bad behavior to remove versions of a library that others are depending on! Seriously, what good does that do? Nobody takes warnings seriously.

Wintamute 11y ago
A specific version of a package is immutable on npm. So if you depend on exactly foo@1.2.3 in your shrinkwrap you'll always get the same code. In other words, even if the package is unpublished, and picked up by a new user they can't re-publish new code to 1.2.3. If you depend on a version range like ^1.2.3 or ~1.2.3 its a different story, of course. Moral of the story is imo always pin to exact versions and use shrinkwrap for production apps. EDIT: This may not be true .. see below.
- choward 11y ago
  > A specific version of a package is immutable on NPM. That's not true. I thought it was but it's not. That's the terrible part. To demonstrate with one of the packages that was removed, run: $ npm info andthen You'll see that versions 0.0.1 and 0.0.2 were published at one point. However, for "versions" it only mentions 2.0.0. And of course, if you run: $ npm install andthen@0.0.2 It blows up in your face.
  - Wintamute 11y ago
    :o