Earlier quoted context omitted.
This is basically what I was doing in the 80s and 90s, downloading compressed tarballs from ftp sites and compiling them. It takes quite a longer developer time than the package manager approach. That includes the time to learn which sites you can trust (probably none today) and which dependencies to use (usually listed in the README.) Furthermore there would be a big incentive to use very few libraries: this is both…
The registry-less dependency management is how Go works today, and doesn't have those problems. It's even less developer time than NPM. 1. No need to spend time publishing, just push a commit 2. No need to `npm i` or edit a file, modules can be inferred from imports because they use FQDN
50% of new NPM packages are spam
201–210 of 325 posts
Re: 50% of new NPM packages are spam
#202Was the joke creating JavaScript frameworks is way to get promoted in FANG / MANGA..
So, when I was younger, I used to frequent DEMF, the Detroit Electronic Music Festival. It's now called Movement or whatever.
It was a great time. And one of the favorite feel good moments was seeing Grandma Techno there: https://mixmag.net/feature/grandma-techno-shares-her-love
Looking back, this view might have been kind of ageist. It shouldn't be that surprising or weird to have older people there. Elders in the tribe. But at the time it was also just a happy recurring image during the event.
We were taught to love this woman through informal network stories and "whispers". Everybody had that friend who pointed her out pridefully, and maybe you became that friend pointing her out to another.
I can imagine another world where seeing Grandma Techno dancing among the younglings is creepy. At least make her wear a VR headset when she's within 1000 feet of the festival. It's nothing personal, it's just nature.
She has a book now. Whether that's because she wanted that sweet "FAANG" publishing deal or liked contributing to the scene. Well... who cares... both benefit us.
Fortunately, we were taught to accept people through informal support networks of friends.
Same goes with npm and cargo.
Yeah, this story seems disjointed and out-of-place. But it's important. And I'm naive, but I'd rather have an orderly migration to social and technical controls for packaging than drama. And I can still respect the people who want some other solution.
Because I'm that fucking old person now.
Re: 50% of new NPM packages are spam
#203I'll throw out another one: create an automated testing process for uploaded NPMs, such testing to be performed before allowing the new "package" to be visible to others.
If the testing process can't find any code or if it really is a real package, but can't be successfully tested, the upload can be rejected with (or without for obvious spam) an email to the "developer" letting them know their code doesn't work and won't be visible to the world until they fix their bugs.
The devil is, of course, in the details. I'm sure there are many edge cases and special circumstances that will likely require manual intervention, but I'd expect that such a solution would cover the vast majority of "spam" packages, with the added benefit of not allowing broken code on the site either.
Perhaps (likely even) there are other, better ways to handle this issue, but this idea would, presumably, significantly reduce the spam issue without negatively impacting honest/real developers.
Just a crazy thought.
[0] "Small" is relative, as a bunch of folks have pointed out.
Re: 50% of new NPM packages are spam
#204I'm afraid it can get worse. What happens when there will be a proliferation of "looking legit npm packages" thanks to AI, full with ransomware? Currently I can't really figure out a one size fits all solution to that. Any idea?
Deno’s model where code needs explicit permissions to use the network and file system is a good first step.
The PDF converter library you're using might not need filesystem or network access, but it can detect specific text in links and replace the URL with a phishing site. There are no technical shortcuts to trust.
You can sandbox all you want, use three layers of VMs and what not, but if you're allowing me to produce bytes for you and then expect to use them elsewhere in any nontrivial way, I've already won.
Re: 50% of new NPM packages are spam
#205I was expecting this article to be a promotion of their audit tool considering a thread about it was flagged as spam less than two weeks ago[1] Turns out it indeed is. Interesting article nonetheless, but it's quite ironic that it's about spam [1] https://news.ycombinator.com/item?id=35233877
Re: 50% of new NPM packages are spam
#206Re: 50% of new NPM packages are spam
#207Earlier quoted context omitted.
One of the first proposals for blockchain was a email with a minuscule, verifiable fee to make email spam uneconomical. Spamming emails is one of the cheapest things you can do with a network connection. Even $1 per 1,000 emails would make spam untenable.
And the first proposal for proof-of-work was having emails include a proof-of-work to make it computationally expensive to mass-send emails.
Re: 50% of new NPM packages are spam
#208Re: 50% of new NPM packages are spam
#209Earlier quoted context omitted.
I think the suggestion was that the revenue generated by NPM's commercial dealings should cover any cost associated with a review process for OSS submissions (which in itself would make such spam repositories ineffective)
So, let the spam happen, and remove it after the fact using humans? Or hold all submissions until a human reviews it?
Anyway, involving humans (funded by NPM's commercial revenue) doesn't reduce the options to "letting the spam happen and dealing it after the fact" or "holding all submissions until a human reviews [them]".
If I was trying to solve this problem, I'd be open to a solution that tried to automatically classify submissions as either legitimate or spammy, with an associated confidence level. If the confidence level fell below a given threshold then I'd involve a human.