Hacker News Reader

Comment by orenlindsey | Hacker News Reader

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)

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.

I'm still sad the lesson learned from this was "don't allow people to unpublish packages" and not "you should vendor your dependencies".

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

Just to be clear: I'm not planning on running an NPM mirror. My point is that if you're not sure you want your code to be publicly available, you should perhaps consider not publishing it to a public registry in the first place. Everything published to the internet can be downloaded and archived. If I publish a blog post I assume it might be cached by a search engine, or snapshotted by archive.today or the wayback machine.

Oh, I agree you shouldn't publish if you aren't sure your code should be public! On the flip side, a package manager could easily address this by requiring code to be published under a limited selection of licenses that actually ensconce those rights, rather than treating it like the wild west as NPM chooses to do.

Weird downvotes! From the source: "Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others."[0]

I'm not a lawyer, but in my best judgment I see no reason to assume an NPM package can continue being used after it is taken down -- you need to actually evaluate the license it's published under to determine that. If I'm mistaken, I'd love to see a source establishing the contrary.

[0]: https://docs.npmjs.com/policies/open-source-terms

Sure, that's true, but good luck suing a Chinese NPM mirror or a Russian NPM mirror.

When you upload something to the internet it's there forever. The only way to ensure something is not on the internet is if you don't post it (and even then...). People are destined to learn this lesson over and over again.

It works both ways, if you want something gone, it will remain forever. If you spend hours searching for something and finally finding a post on a forum from 2007 where someone goes "this fixed it for me: <link>", that link will never work and won't be archived by archive.org.

Are you really excited to use a Russian NPM mirror that is providing tarballs and ignoring copyright as your dependency vendor?

> As far as I can tell, NPM does not enforce any limitations on the license of published packages

I once saw a package on NPM that had a commercial license. It even had a link to its source on GH.

And a note that if you used the package you needed to pay up.

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.

So just make a new package per dependency then. And have each version of that package depend on each version of the original package.

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.

The JS ecosystem is deeply unserious.

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

PyPi, but yes. 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-rustde...

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.

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

> We stand by our package name dispute resolution policy, and the decision to which it led us.

npm deserves to die.

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.

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

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

Perl way back had a package in CPAN, Acme::All or something like that, which caused some issues until it was removed.

Loads of attack vectors via pip.

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.

Reply on news.ycombinator.com