Live data from Hacker News

70% of new NPM packages in last 6 months were spam

blog.phylum.io

21–30 of 116 posts

Re: 70% of new NPM packages in last 6 months were spam

#21

I am really interested if that really matters. Package managers often comes with rating system. npmjs has weekly downloads, pull requests, and other popularity scores. I am layman in AI, but why would anyone think that this would affect anything, like AI? Why would anyone train on noname package, that noone uses? Stats for spam packages can have higher-than-none stats, but that also makes them vulnerable for sweep re…

> why would anyone think that this would affect anything, like AI? Why would anyone train on noname package, that noone uses?

…almost certainly for the same reason that any “train AI using only good data, reduce hallucinations!” suggestion is in the “daydream” rather than “great idea” category.

Creating high quality filtered datasets is enormously more time consuming and expensive than just dumping everything you can get you hands on in.

It seems obvious to ignore packages that are obviously unused and spam, but tldr; no idiot is going to be pouring spam into npm unless there’s some kind of benefit from it; people accidentally using it, mixing it into the dependency tree of legit packages, etc.

It’s more likely that the successful folk doing this aren’t being caught, and the ones being caught are “me too” idiots. Or, the spam is working and people are actually (for whatever incomprehensible reason) actually using at least some of the packages.

TLDR; if dependency auditing and supply chain attack were trivial to solve, it wouldn’t be a problem.

…but based on the fact that we continue endlessly to see these issues, you can assume that it’s probably more diff to solve than it trivially appears.

Re: 70% of new NPM packages in last 6 months were spam

#22
post #2

> Contrary to what npm states, this package actually depends on one of our aforementioned spam packages. This is a by-product of how npm handles and displays dependencies to users on its website. For me personally, this is the biggest surprise and takeaway here. By simply having a key inside package.json's dependencies reference an existing NPM package, the NPM website links it up and counts it as a dependency, regar…

This feels like the more important takeaway (and feels like an actual security bug), I'm surprised this so buried in the article...

Re: 70% of new NPM packages in last 6 months were spam

#23

> Next, because the AI hype train is at full steam, we must point out the obvious. AI models that are trained on these packages will almost certainly skew the outputs in unintended directions. These packages are ultimately garbage, and the mantra of “garbage in, garbage out” holds true. hmm, inspiring thoughts. An answer to "AI is going to replace software developers in the next 10 years" is to create 234876238562856…

That's not what "hallucination" is. Hallucinations in LLMs are when they unexpectedly and confidently extrapolate outside of their training set when you expected them to generate something interpolated from their training set.

In your example that's just a pollution of the training set by spam, but that's not that much of an issue in practice, as AI has been better than humans at classifying spam for over a decade now.

Re: 70% of new NPM packages in last 6 months were spam

#24
post #8

How about removing the incentive? Take down every package with tea.yaml in it, after say 1 month's warning, so legitimate packages trying to use it don't leave their users in the lurch. The tea protocol is clearly not going to accomplish what it set out to (see below), and is instead incentivising malicious behaviour and damaging the system it set out to support. From https://docs.tea.xyz/tea/i-want-to.../faqs : "tea…

That would be a clear violation of the npm Unpublish Policy[0]. If all it takes is some spam and pissing people off to walk away from principles, they never meant anything. A proper response needs to not break expectations like this.

[0]: https://docs.npmjs.com/policies/unpublish

Re: 70% of new NPM packages in last 6 months were spam

#25
post #2

> Contrary to what npm states, this package actually depends on one of our aforementioned spam packages. This is a by-product of how npm handles and displays dependencies to users on its website. For me personally, this is the biggest surprise and takeaway here. By simply having a key inside package.json's dependencies reference an existing NPM package, the NPM website links it up and counts it as a dependency, regar…

You should think of the package metadata as originating from the publisher, not from the registry. Aside from the name, version, and (generated) dist and maintainers fields, I don't think any of it is even supposed to be validated by the registry?

Agreed the website UX is confusing and could be better but in general package metadata is just whatever the publisher put there and it's up to you to verify if you care about veracity.

Re: 70% of new NPM packages in last 6 months were spam

#27

> Next, because the AI hype train is at full steam, we must point out the obvious. AI models that are trained on these packages will almost certainly skew the outputs in unintended directions. These packages are ultimately garbage, and the mantra of “garbage in, garbage out” holds true. hmm, inspiring thoughts. An answer to "AI is going to replace software developers in the next 10 years" is to create 234876238562856…

That's not what "hallucination" is. Hallucinations in LLMs are when they unexpectedly and confidently extrapolate outside of their training set when you expected them to generate something interpolated from their training set. In your example that's just a pollution of the training set by spam, but that's not that much of an issue in practice, as AI has been better than humans at classifying spam for over a decade no…

This is confusing to read

If I agree with your definition of hallucinations in the context of LLMs... Then isn't your second paragraph literally just a way to artificially increase the likelihood of them occurring?

You seem to differentiate between a hallucination caused by poisoning the dataset vs a hallucination caused by correct data, but can you honestly make such a distinction considering just how much data goes into these models?

Re: 70% of new NPM packages in last 6 months were spam

#28
post #20
post #12

Earlier quoted context omitted.

Hugely surprising that package.json and package-lock.json don't have to match. The way I would expect it to work is something like: for d in dependencies_from_package_json() get_package(d) if hash_package(d) != package_lock_hash(d) error() end end And not: use_package_lock_and_ignore_package_json_lol_fuck_you_haha_kthxbye() I also discovered that npm doesn't actually verify what's in node_modules when using "npm inst…

For situations when you care, go for `npm ci` instead of `npm install`. It will ensure lockfile consistency. https://docs.npmjs.com/cli/v9/commands/npm-ci

That's just "rm -r node_modules && npm install".

Aside from needlessly taking a long time, it also means we're back to "if something goes wrong we're left with an inconsistent node_modules".

Re: 70% of new NPM packages in last 6 months were spam

#29
post #28
post #20

Earlier quoted context omitted.

For situations when you care, go for `npm ci` instead of `npm install`. It will ensure lockfile consistency. https://docs.npmjs.com/cli/v9/commands/npm-ci

That's just "rm -r node_modules && npm install". Aside from needlessly taking a long time, it also means we're back to "if something goes wrong we're left with an inconsistent node_modules".

No, it's more than that. Did you read the documentation page linked in the comment you replied to?

> But what about after the command has run?

If you munge around in node_modules after a successful `npm ci`, that's on you. If you run scripts that do, that's on you. If you depend on packages that run such scripts, that's on you.

> What, you mean I'm supposed to audit my dependencies myself? That's too much work!

Yes, as part of code review we expect our devs to manually inspect every change in the lockfile for anything that matters or might start to, which includes most things. No, you can't outsource that task to an AI, regardless of how well-performing it appears.

Re: 70% of new NPM packages in last 6 months were spam

#30
post #24
post #8

How about removing the incentive? Take down every package with tea.yaml in it, after say 1 month's warning, so legitimate packages trying to use it don't leave their users in the lurch. The tea protocol is clearly not going to accomplish what it set out to (see below), and is instead incentivising malicious behaviour and damaging the system it set out to support. From https://docs.tea.xyz/tea/i-want-to.../faqs : "tea…

That would be a clear violation of the npm Unpublish Policy[0]. If all it takes is some spam and pissing people off to walk away from principles, they never meant anything. A proper response needs to not break expectations like this. [0]: https://docs.npmjs.com/policies/unpublish

The entire NPM ecosystem is a garbage fire. Who cares about whatever 'principles' it supposedly has? Other than avoiding malware I can't think of something I care about less than whatever principles NPM / JS developers in general have because they've mostly been bad so far.

I wouldn't be surprised if principles in this case leave us with thousands of spam packages degrading the node ecosystem forever. It'd be exactly what I expect. So I guess I should thank the principle of consistency.

Post reply on HN