5 ms·

The JS ecosystem is so goofy. Stuff like this, leftpad, and dozens more happen. Doesn't happen to literally any other programming language (or maybe I just hav

The JS ecosystem is so goofy. Stuff like this, leftpad, and dozens more happen. Doesn't happen to literally any other programming language (or maybe I just haven't paid attention to others)

infotainment 3y ago
I'm curious if this type of issue is unique to NPM. Does PIP (Python) have this issue?
- fragmede 3y ago
  PyPi, but yes. https://securitylabs.datadoghq.com/articles/guarddog-identify-malicious-pypi-packages/#:~:text=Malicious%20PyPI%20packages%20have%20enabled,and%20perform%20cryptojacking%20(colourama) https://securitylabs.datadoghq.com/articles/guarddog-identif.... The link also mentions that PHP has been attacked in this way. As has rust. https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde...
  - kibwen 3y ago
    Malicious packages and typosquatting are very different from what's being talked about here. The problem in this case is a clash of policies: NPM historically allowed people to delete their packages after they published them, and then after left-pad they realized that was a terrible idea from an ecosystem reliability perspective so they made it so that you can't unpublish packages that are listed as dependencies of other packages, and so someone took this to the logical conclusion and a made a package that was dependent on all other packages. NPM wants to have its cake and eat it too, which is the problem here. The solution is just to say that if you publish a package to NPM you give it the perpetual right to distribute it as-is, and then remove the ability for users to delete their packages at-will.
    - wruza 3y ago
      When authors want to remove a package, realistically there are two main reasons: (a) they don’t need it anymore or (b) there’s a serious issue with it in general, like deprecation or unfitness. Why not just (a) hide it in ui or (b) flag it, explain the reason and give everyone enough time to migrate away. So many issues arise from the fact that our UIs can’t do simple things on lists like folders (e.g. archive) and tags/notes.
    - minot 3y ago
      > NPM wants to have its cake and eat it too, which is the problem here. The solution is just to say that if you publish a package to NPM you give it the perpetual right to distribute it as-is, and then remove the ability for users to delete their packages at-will. Yes, exactly! Kind of unrelated, but I think it is important to remember that the left-pad was also ENTIRELY npm team's fault. You can't just take away a namespace from someone just because some startup like kik comes knocking. Toyota does not have a right to my domain dot tld slash toyota The correct answer would have been npm to tell kik to pound sand. npm has never fixed this grave error. https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm https://blog.npmjs.org/post/141577284765/kik-left-pad-and-np... > We stand by our package name dispute resolution policy, and the decision to which it led us. npm deserves to die.
  - woodruffw 3y ago
    Your linked article does not show that PyPI has been attacked in this way (I don't think this is really an attack, but putting that aside for a second). The way PyPI does deletions is through "yanking," which is really a soft-delete mechanism. Yanking prevents usage of a particular package version for new resolutions, but allows fully-resolved versions to be downloaded. As a result, PyPI doesn't have the specific behavior that caused this (forbidding people from removing their packages because removal means hard-deletion).
- chuckadams 3y ago
  Perl way back had a package in CPAN, Acme::All or something like that, which caused some issues until it was removed.
- wavemode 3y ago
  Haskell's acme-everything[1] is an old running joke. A few people called for its removal due to annoyance but it seems to still be around. [1]: https://hackage.haskell.org/package/acme-everything https://hackage.haskell.org/package/acme-everything
- gumballindie 3y ago
  Loads of attack vectors via pip.
throwitaway1123 3y ago
Ironically, this happened because of a mitigation put in place to prevent the leftpad disaster from happening again. To recap: the developer of leftpad removed his package, which broke packages that depended on it. To prevent this from happening again NPM decided that you can't unpublish a package that has dependents, which I think is a sensible policy. The result of this is that you can prevent anyone's package from being unpublished by depending on it. This 'everything' package simply took this concept to its extreme conclusion. Personally, I think if you're not sure you want a package to be available publicly in perpetuity, you should maybe consider publishing it to a private registry. Even if NPM did allow developers to unpublish any package, there's nothing stopping me from downloading a tarball of your package as soon as you publish it, and hosting a mirror of it somewhere else.
- stjohnswarts 3y ago
  Maybe something like this should put up big siren noises that it has so many dependencies. Can -anything- have that many dependencies? seems like a check they could build in and not let it go into the npm packages without a review.
  - charcircuit 3y ago
    So just make a new package per dependency then. And have each version of that package depend on each version of the original package.
- clipsy 3y ago
  > Even if NPM did allow developers to unpublish any package, there's nothing stopping me from downloading a tarball of your package as soon as you publish it, and hosting a mirror of it somewhere else. As far as I can tell, NPM does not enforce any limitations on the license of published packages; I would not assume you can legally do this unless you have verified the package has been published under a license which permits such actions and which you are certain you understand.
  - clipsy 3y ago
sgarland 3y ago
The JS ecosystem is deeply unserious.
userbinator 3y ago
It's a combination of low barrier to entry and dogmatic adherence to "not reinventing anything" resulting in quantity over quality and massively deep dependency graphs.
bob1029 3y ago
When we say "js ecosystem", npm and node are not what come to my mind in 2024. I don't see these as serious contenders anymore.

The JS ecosystem is so goofy. Stuff like this, leftpad, and dozens more happen. Doesn't happen to literally any other programming language (or maybe I just haven't paid attention to others)

infotainment 3y ago

I'm curious if this type of issue is unique to NPM. Does PIP (Python) have this issue?

fragmede 3y ago
PyPi, but yes. https://securitylabs.datadoghq.com/articles/guarddog-identify-malicious-pypi-packages/#:~:text=Malicious%20PyPI%20packages%20have%20enabled,and%20perform%20cryptojacking%20(colourama) https://securitylabs.datadoghq.com/articles/guarddog-identif.... The link also mentions that PHP has been attacked in this way. As has rust. https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde...
- kibwen 3y ago
  Malicious packages and typosquatting are very different from what's being talked about here. The problem in this case is a clash of policies: NPM historically allowed people to delete their packages after they published them, and then after left-pad they realized that was a terrible idea from an ecosystem reliability perspective so they made it so that you can't unpublish packages that are listed as dependencies of other packages, and so someone took this to the logical conclusion and a made a package that was dependent on all other packages. NPM wants to have its cake and eat it too, which is the problem here. The solution is just to say that if you publish a package to NPM you give it the perpetual right to distribute it as-is, and then remove the ability for users to delete their packages at-will.
  - wruza 3y ago
    When authors want to remove a package, realistically there are two main reasons: (a) they don’t need it anymore or (b) there’s a serious issue with it in general, like deprecation or unfitness. Why not just (a) hide it in ui or (b) flag it, explain the reason and give everyone enough time to migrate away. So many issues arise from the fact that our UIs can’t do simple things on lists like folders (e.g. archive) and tags/notes.
  - minot 3y ago
    > NPM wants to have its cake and eat it too, which is the problem here. The solution is just to say that if you publish a package to NPM you give it the perpetual right to distribute it as-is, and then remove the ability for users to delete their packages at-will. Yes, exactly! Kind of unrelated, but I think it is important to remember that the left-pad was also ENTIRELY npm team's fault. You can't just take away a namespace from someone just because some startup like kik comes knocking. Toyota does not have a right to my domain dot tld slash toyota The correct answer would have been npm to tell kik to pound sand. npm has never fixed this grave error. https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm https://blog.npmjs.org/post/141577284765/kik-left-pad-and-np... > We stand by our package name dispute resolution policy, and the decision to which it led us. npm deserves to die.
- woodruffw 3y ago
  Your linked article does not show that PyPI has been attacked in this way (I don't think this is really an attack, but putting that aside for a second). The way PyPI does deletions is through "yanking," which is really a soft-delete mechanism. Yanking prevents usage of a particular package version for new resolutions, but allows fully-resolved versions to be downloaded. As a result, PyPI doesn't have the specific behavior that caused this (forbidding people from removing their packages because removal means hard-deletion).
chuckadams 3y ago
Perl way back had a package in CPAN, Acme::All or something like that, which caused some issues until it was removed.
wavemode 3y ago
Haskell's acme-everything[1] is an old running joke. A few people called for its removal due to annoyance but it seems to still be around. [1]: https://hackage.haskell.org/package/acme-everything https://hackage.haskell.org/package/acme-everything
gumballindie 3y ago
Loads of attack vectors via pip.

throwitaway1123 3y ago

Ironically, this happened because of a mitigation put in place to prevent the leftpad disaster from happening again. To recap: the developer of leftpad removed his package, which broke packages that depended on it. To prevent this from happening again NPM decided that you can't unpublish a package that has dependents, which I think is a sensible policy. The result of this is that you can prevent anyone's package from being unpublished by depending on it. This 'everything' package simply took this concept to its extreme conclusion. Personally, I think if you're not sure you want a package to be available publicly in perpetuity, you should maybe consider publishing it to a private registry. Even if NPM did allow developers to unpublish any package, there's nothing stopping me from downloading a tarball of your package as soon as you publish it, and hosting a mirror of it somewhere else.

stjohnswarts 3y ago
Maybe something like this should put up big siren noises that it has so many dependencies. Can -anything- have that many dependencies? seems like a check they could build in and not let it go into the npm packages without a review.
- charcircuit 3y ago
  So just make a new package per dependency then. And have each version of that package depend on each version of the original package.
clipsy 3y ago
> Even if NPM did allow developers to unpublish any package, there's nothing stopping me from downloading a tarball of your package as soon as you publish it, and hosting a mirror of it somewhere else. As far as I can tell, NPM does not enforce any limitations on the license of published packages; I would not assume you can legally do this unless you have verified the package has been published under a license which permits such actions and which you are certain you understand.
- clipsy 3y ago

sgarland 3y ago

The JS ecosystem is deeply unserious.

userbinator 3y ago

It's a combination of low barrier to entry and dogmatic adherence to "not reinventing anything" resulting in quantity over quality and massively deep dependency graphs.

bob1029 3y ago

When we say "js ecosystem", npm and node are not what come to my mind in 2024. I don't see these as serious contenders anymore.