3 ms·

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.

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.