> The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products.
The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.
tanepiper · 38m ago
Author of the article here - holistically this isn't just about NPM dependencies, it's the entire stacks we work with. Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts - this is dangerous - I have 25 years of experience and I wouldn't want to touch the depths of RBAC.
SaaS products don't enforce good security - I've seen some internally that don't have MFA or EntraID integration because they simply don't have those as features (mostly legacy systems these days, but they still exist).
I'm also an open-source author (I have the most used bit.ly library on npm - and have had demands and requests too), and I'm the only person you can publicly see on our [company github](https://github.com/ikea) - there's reasons for this - but not every company is leeching, rather there is simply no other alternative.
ants_everywhere · 22m ago
> Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts -
A lot of the spread of Shai-Hulud is due to s having overly broad credentials on NPM, GitHub and elsewhere. It's not that NPM doesn't support scoped credentials, it's that developers don't want to deal with it so it's not the default. There's no reason why, for example, a developer needs a live credential to publish their package when they're just hacking on code.
This is related to the `curl | bash` pattern. Projects like NPM want to make it easy to get started and hard to reach a failure case so they sacrifice well-known security practices during the growth phase.
pixl97 · 3m ago
I mean quite often access based errors are very opaque, I mean it is for good reason, but when you're new to something it's one of those things that leads you to give up. You want to write code, not spend 3 hours figuring out why your token doesn't work.
Security things will get hacked on later, but again it will cause all kinds of problems because the ecosystem wasn't built for it.
giantg2 · 1h ago
I remember joining my company right out of college. In the interview we started talking about open source since I had some open source Android apps. I asked if the company contributed back to the projects it used. The answer was no, but that they were planning to. Over a decade later... they finally created a policy to allow commits to open source projects. It's been used maybe 3 times in it's first year or so. Nobody has the time and the management culture doesnt want to waste budget on it.
bonoboTP · 4m ago
That's fine. There's no requirement to "contribute back". Respect the license terms and don't go demanding anything unless you have a support contract and don't expect that you can get a support contract. It's fine to just use something as long as you also don't harass the maintainer as if they owed you something.
rkagerer · 55m ago
That's such a self-harmful policy. I have a small business and I've been really supportive to both open source and small, paid-for commercial libraries and building blocks that I rely on. Also advocated this successfully at clients I've consulted with. We do a lot of technical vetting before adopting any particular dependency (vs. building out our own) and it just makes sense that we strive to foster the continued existence and excellence of our tools. Considering the incredible value companies get from open source, I have trouble understanding why they wouldn't throw some cash or idle cycles their way. Seemed to work out for the likes of Google while they were undergoing rapid growth.
MrGilbert · 53m ago
> Nobody has the time
I'd erase that part entirely, as it is not true, from my point of view. My day, as has every other person's day, has exactly 24 hours. As an employee, part of that time is dedicated to my employer. In return, I receive financial compensation. It's up to them to decide how they want to spend the resources they acquired. So yes, each and every company could, in theory, contribute back to Open Source.
But as there is no price tag attached to Open Source, there is also no incentive. In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible.
watwut · 17m ago
> In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible.
It is not just that. In a well functioning theoretical free market, no one is going to have time either. The margins are supposed to end up being tight and the competition is supposed to weed out economic inefficiency. Voluntary pro-social behavior is a competitive disadvantage and an economic inefficiency. So, by design, the companies end up not "having time for that".
You need a world that allows for inefficiency and rewards pro-social behavior. That is not the world where we are living in currently.
grafmax · 48m ago
Technology is insecure all the way down to the hardware. The structural cause of this is that companies aren’t held liable for insecure products, which are cheaper to build.
So companies’ profit motives contribute to this mess not just through the exploitation of open source labor (as you describe) but through externalizing security costs as well.
stingraycharles · 44m ago
Isn’t all this stuff with Secure Enclave supposed to address these kind of things?
It’s my take that over the past ~ decade a lot of these companies have been making things a lot better, Windows even requires secure boot these days as well.
acdha · 27m ago
They’re not the same problems. The Secure Enclave protects things like your biometrics, hardware-backed keys (e.g. on a Mac, WebAuthn and iCloud Keychain), and the integrity of the operating system but not every bit of code running as your account. That means that an NPM install can’t compromise your OS to the point that you can’t recover control, but it means the attacker can get everything you haven’t protected using sandbox features.
That’s the path out of this mess: not just trying to catch it on NPM but moving sensitive data into OS-enforced sandboxes (e.g. Mac containers) so every process you start can’t just read a file and get keys, and using sandboxing features in package managers themselves to restrict when new installs can run code and what they can do (e.g. changing the granularity from “can read any file accessible to the user” to “can read a configuration file at this location and data files selected by the user”), and tracking capability changes (“the leftpad update says it needs ~/.aws in this update?”).
We need to do that long-term but it’s a ton of work since it breaks the general model of how programs work we’ve used for most the last century.
snickerdoodle14 · 40m ago
Not really, those technologies are basically designed to be able to enforce DRM remotely.
Secure Enclave = store the encryption keys to media in a place where you can't get them
Secure Boot = first step towards remote attestation so they can remotely verify you haven't modified your system to bypass the above
Advertising rules the world.
brookst · 30m ago
How is that different?
Is there such a thing as secure hardware that can prevent supply chain attacks (by enabling higher layers to guarantee security) and secure hardware that prevents copying data (by enabling higher layers to guarantee security)?
snickerdoodle14 · 27m ago
Sure. Malware tends not to have physical hands that can touch the machine and any buttons attached to it. Physical ownership should be true ownership, but they're taking that away from you.
ants_everywhere · 29m ago
> More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.
People who work on permissively licensed software are donating their time to these Fortune 500 companies. It hardly seems fair to call the companies leeches for accepting these freely given donations.
raisaguys · 1m ago
I playing and win in jo777, search in google now
theknarf · 39m ago
Npm is owned by Github, which is owned by Microsoft. They could have put more tooling into making npm better. For example; pnpm require you to "approve-builds" so that its only running scripts from dependencies you decide on, and Deno have a bunch of security capabilities to restrict what scripts can and can't do. There is always going to be supply chain attacks, and the biggest package repositories are going to be hit the most. But that doesn't mean that Microsoft couldn't have spent more on building better tooling with better security settings on by default.
tcoff91 · 52m ago
20 of the packages were from Crowdstrike
ricardobeat · 1h ago
I find this perspective harmful to OSS as a whole. It is completely fine to release free software that other companies can use without restrictions, if you desire to do so. It is not meant to be a transaction. You share some, you take some.
It’s also ok to release paid free software, or closed software, restrictive licenses, commercial licenses, and sell support contracts. It’s a choice.
sarchertech · 1h ago
Just because you can do something doesn’t mean you should.
There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t open source and you have brought dishonor to your family.
ricardobeat · 1h ago
> Just because you can do something doesn’t mean you should.
This implies some kind of fairness/moral contract in a license like MIT. There is none. It’s the closest thing to donating code to the public domain, and entirely voluntary.
There are plenty of standard licenses with similar clauses restricting commercial use, no need to create a custom one.
But indeed, the truth is that a restrictive license will massively reduce the project’s audience. And that is a perfectly fine choice to make.
sarchertech · 54m ago
> This implies some kind of fairness/moral contract in a license like MIT.
The license tells you what you are legally allowed to do. It doesn’t supersede basic concepts of fairness.
The average person would say that if you directly make millions of someone else’s work, the fair thing to do is to pay that person back in some way.
Calling someone a leech is just saying that they aren’t following the the accusers model of fairness. That’s all. There’s no legal definition.
We say things like “my company screwed me over when they fired me right before my RSUs vested” despite that being perfectly legal.
ricardobeat · 48m ago
> someone else’s work
It is not “their” work anymore (IP rights discussions aside) once they published with an unrestricted license. That’s the point. You do it expecting nothing in return, and do it willingly. Expecting “fairness” is a misunderstanding of the whole spirit of it.
brookst · 26m ago
Semantic games with “their work”. An artist who sells a painting can still call it their work, even if someone else owns it. And I suppose the collector who bought it could also call it their work, though that phrasing isn’t usually used.
It comes about because “work” is overloaded to mean both the activity of creating and the product/result of that activity.
nemomarx · 1h ago
Sidestep this debate with one trick - use the GPLv3. No company large enough to have a legal team will be able to use it, you're still squarely within the various definitions, and the FSF basically has to approve.
As a bonus maybe you can get some proprietary software open sourced too.
watwut · 1h ago
Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth.
josephg · 43m ago
I’ve contributed a huge amount of opensource code over my career - almost all of it entirely unpaid. I don’t know the statistics, but I know many other people who have done the same.
I think there are a lot of high profile opensource projects which are either run by corpos (like React) or have a lot of full time employees submitting code (Linux). But there’s an insanely long tail of opensource projects on npm, cargo, homebrew etc which are created by volunteers. Or by people scraping by on the occasional donation.
watwut · 9m ago
npm was a company for years now. It was initially created as a volunteer one person project, then they create company 10 years ago and eventually sold to Github which was sold to Microsoft. It has spent more time being developed as a paid thing then by unpaid volunteers doing it on the side.
austin-cheney · 59m ago
I don’t think that is correct. VS Code developers and the TypeScript team is paid by MS. Core of React is paid by Meta, or was. Java language is paid by Oracle as is the LiberaSuite and MySQL.
Most of the Linux foundation projects, which includes Node are volunteers. Most of the Apache foundation software is from volunteers. Most NPM packages are from volunteers. OpenSSL is volunteers.
There is also a big difference between the developers who are employees on salary versus those that receive enough donations to work in open source full time.
izacus · 10m ago
Most of those "voluneers" are also developing those projects as part of their paid job in a form of company contribution back to OSS though.
watwut · 55m ago
> Linux foundation projects, which includes Node are volunteers.
The survey found that specifically linux code is dominated by people who are paid for it.
> Most of the Apache foundation software is from volunteers.
Large Apache project specifically are backed by companies per Apache rules. Each project must have at least three active backing companies. They contribute the most of the code.
throw-qqqqq · 38m ago
> The survey found that specifically linux code is dominated by people who are paid for it.
Yes the kernel code, but the Linux Foundation projects (mentioned in the comment you quote and reply to) are MUCH more than the kernel.
It depends on the domain. There are a lot of critical utilities in the systems space maintained by volunteers. The “xz” compression library was one recent infamous example where an exhausted volunteer maintainer was social engineered into a supply chain attack that briefly compromised OpenSSH.
Not a lot of applications being maintained by altruists, but look under the hood in Linux/GNU/BSD and you fill find a lot of volunteers motivated by something other than money.
Arch-TK · 38m ago
It briefly compromised the custom patched Debian version of OpenSSH. The issue had nothing to do with OpenSSH itself.
izacus · 59m ago
Yes, but even in those domains those projects are minorities and in many examples they make it effectively impossible to legally fund or contribute to them from the side of corporations.
graemep · 54m ago
Why is it legally impossible to fund or contribute? Do they turn down contributions from paid developers? Do they refuse donations or just have no no mechanism for accepting them? Do they not have any form of commercial services or licence?
I think there are very few projects that do not accept support in any form.
izacus · 5m ago
In most cases they need to be able to issue a commercial invoice in a region compatible with company accounting.
For a lot of single developers that's not a thing they're ready or able to do. Those that can, usually have companies established as a revenue source for their OSS project.
xrisk · 54m ago
Yeah I’m not buying it. If the corporations wanted to, they would.
cube00 · 1h ago
I'd be keen to see that survey given how many projects I see with so few GitHub sponsors that I can't see how you'd derive a full time wage.
graemep · 51m ago
A lot of FOSS is developed by people who do it as part of their paid employment, that is what the GP is referring to, not Github sponsorship (which is tiny by comparison).
davedx · 54m ago
Post the survey please, that's an extraordinary claim
delduca · 1h ago
This.
austin-cheney · 1h ago
Consider how many JavaScript developers are completely unemployable without that free software. It might be greater than 95%. That’s why business needs this stuff, because otherwise they might actually have to invest in training.
pavel_lishin · 1h ago
> Consider how many JavaScript developers are completely unemployable without that free software.
Can you say more about this?
austin-cheney · 46m ago
How many JavaScript developers in the workforce can write original applications without some colossal framework and an army of NPM packages? In 15 years of doing that work those people do not exist, at least statistically, and hiring does not encourage their selection.
Most people doing this work, both in person and online, are extremely sensitive about this. It’s a hard reality to accept that if this free software went away most people doing the work wouldn’t be able to qualify their income in any significant way to their employer.
tcoff91 · 11m ago
I think that ultimately it’s the fault of the web platform.
With just a bit of retraining those engineers that could not be productive without a ton of npm packages could ship an iPhone app written in Swift.
JS’ standard library is abysmal.
amiga386 · 1h ago
"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
acdha · 1m ago
This is mischaracterization of a popularity contest. Node culture is extreme–perhaps pathological–about using many dependencies to work around the limited standard library but the same kind of attacks happen everywhere people are releasing code. The underlying problem is that once you release something it takes only seconds before someone else can be running your code with full privileges to access their account.
andrewl-hn · 1h ago
TBF it does happen to other package managers, too. There were similar attacks on PyPI and Rubygems (and maybe others). However, since npm is the largest one and has the most packages released, updated, and downloaded, it became the primary target. Similar to how computer viruses used to target Windows first and foremost due to its popularity.
Also, smaller package managers tend to learn from these attacks on npm, and by the time the malware authors try to use similar types of attacks on them the registries already have mitigations in place.
shakna · 42m ago
PyPI is working towards attestation [0], and already has "Trusted Publisher" [1].
Ruby has had signed gems since v2 [2].
These aren't a panacea. But they do mean an effort has been made.
npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4]
I don't think it's fair to compare npm to the others.
It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm
a4isms · 1h ago
Deeply underrated comment. You can peel back the layers of sarcasm like... An onion.
No comments yet
2d8a875f-39a2-4 · 1h ago
It's a stretch to pin blame on Microsoft. They're probably the reason the service is still up at all (TFA admits as much). In hindsight it's likely that all they wanted from the purchase was AI training material. At worst they're guilty of apathy, but that's no worse than the majority of npm ecosystem participants.
righthand · 30m ago
It’s NOT a stretch to blame Microsoft. How many billions have we spent chasing “AI”? These issues could have been easily solved if we spent the consideration on them. This has been going on well over a decade.
Microsoft isn’t any better steward than the original teams.
This issue has happened Plenty under Microsoft’s ownership.
mr90210 · 38m ago
> It's a stretch to pin blame on Microsoft. They're probably the reason the service is still up at all.
I reckon that the ecosystem would have been much healthier if NPM had not been kept running without the care it requires.
raisaguys · 2m ago
I playing and win in jo777 guys, search in google now
apimade · 59m ago
Here’s a one-liner for node devs on MacOS, pin your versions and manually update your supply chain until your tooling supports supply chain vetting, or at least some level of protection against instantly-updated malicious upstream packages.
Would love to see some default-secure package management / repo options. Even a 24 hour delayed mirror would be better than than what we have today.
The expected secure workflow should not require an elaborate bash incantation, it should be the workflow the tools naturally encourage you to use organically. "You're holding it wrong" cannot be possible.
madeofpalk · 17m ago
? Package lock files from npm/yarn/pnpm automatically lock all your dependencies (including transitive deps)
What does this actually achieve?
aj_g · 1h ago
Anyone have a good solution to scan all code in our Github org for uses of the affected packages? Many of the methods we've tried have dead ended. Inability to reliably search branches is quite annoying here.
ozim · 50m ago
Have you tried Dependency Track from OWASP? Generate SBOM from each repo/projects and post it with API to DT and you have full overview. You have to hook it up so it is done automatically because of course stuff will always move.
tcoff91 · 36m ago
It seems to me like one obvious improvement is for npm to require 2fa to submit packages. The fact that malware can just automatically publish packages without a human having to go through an MFA step is crazy.
jamesnorden · 1h ago
I think the cooldown approach would make this type of attack have practically no impact anymore, if nobody ever updates to a newly published package version until, say, 2-3 days have gone by, surely there will be enough time for owner of the package to notice he got pwnd.
deevus · 1h ago
I've never heard of this. It sounds like a solid default to me. If you _really_ need an update you can override it, but it should remain the default and not allow opting out.
Here's a short recap of what you can do right now, because changing the ecosystem will take years, even if "we" bother to try doing it.
1. Switch to pnpm, it's not only faster and more space efficient, but also disables post-install scripts by default. Very few packages actually need those to function, most use it for spam and analytics. When you install packages into the project for the first time, it tells you what post-install scripts were skipped, and tells you how to whitelist only those you need. In most projects I don't enable any, and everything works fine. The "worst" projects required allowing two scripts, out of a couple dozen or so.
They also added this recently, which lets you introduce delays for new versions when updating packages. Combined with `pnpm audit`, I think it can replace the last suggestion of setting up a helper dependency bot with zero reliance on additional services, commercial or not:
2. If you're on Linux, wrap your package managers into bubblewrap, which is a lightweight sandbox that will block access to almost all of your system, including sensitive files like ~/.ssh, and prevent anything running under it from escalating privileges. It's used by flatpak and Steam. A fully working & slightly improved version was posted here:
I posted the original here, but it was somewhat broken because some flags were sorted incorrectly (mea culpa). I still prefer using a separate cache directory instead of sharing the "global" ~/.cache because sensitive information might also end up there.
3. Setup renovate or any similar bot to introduce artificial delays into your supply chain, but also to fast-track fixes for publicly known vulnerabilities. This suggestion caused some unhappiness in the previous discussion for some reason — I really don't care which service you're using, this is not an ad, just setup something to track your dependencies because you will forget it. You can fully self-host it, I don't use their commercial offering — never has, don't plan to.
4. For those truly paranoid or working on very juicy targets, you can always stick your work into a virtual machine, keeping secrets out of there, maybe with one virtual machine per project.
garblegarble · 6m ago
Bubblewrap seems excellent for Linux uses - on macOS, it seems like sandbox-exec could do some (all?) of what bubblewrap does on Linux - although I don't see much in the way of documentation on writing sandbox policies
Edit: yes, I've started attempting to write a policy, but the quality of errors is very poor
righthand · 1h ago
Here is an issue from 2013 where developers are asking to fix the package signing issue. Gone fully ignored because doing so was “too hard”: https://github.com/npm/npm/pull/4016
thombles · 1h ago
I think if somebody wants to see library distribution channels tightened up they need to be very specific about what they would like to see changed and why it would be better, since it would appear that the status quo is serving what people actually want - being able to create and upload packages and update them when you want.
> But right now there are still no signed dependencies and nothing stopping people using AI agents, or just plain old scripts, from creating thousands of junk or namesquatting repositories.
This is as close as we get in this particular piece. So what's the alternative here exactly - do we want uploaders to sign up with Microsoft accounts? Some sort of developer vetting process? A curated lib store? I'm sure everybody will be thrilled if Microsoft does that to the JS ecosystem. (/s) I'm not seeing a great deal of difference between having someone's NPM creds and having someone's signing key. Let's make things better but let's also be precise, please.
lukan · 1h ago
We treat code repositories as public infrastructure, but we don't want to pay for it, so corporations run them, with their profit interest in mind. This is the fundamental conflict, that I see.
And one solution, more non profits as organisations behind them.
cube00 · 1h ago
> But right now there are still no signed dependencies
Considering these attacks are stealing API tokens by running code on developer's machines; I don't see how signing helps, attackers will just steal the private keys and sign their malware with those.
deevus · 1h ago
Could they detect code running from a new IP address or location and ask for a 2FA code?
cube00 · 1h ago
postinstall is running on the developer's machine, from an endpoint security perspective, it's the actual developer performing the malicious actions, their machine, their IP address and their location.
izacus · 8m ago
What are you talking about, NPM keeps having issues that "status quo" of other platforms doesn't.
1oooqooq · 1h ago
funny how npm is the exact same model as maven, gopkg, cpan, pip, mix, cargo, and a million others.
but only npm started with a desire to monetize it (well, npm and docker hub) and in its desire for control didn't implement (or allowed the community to implement) basic higiene.
lupusreal · 1h ago
The beatings will continue until JS dev culture reforms.
The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.
SaaS products don't enforce good security - I've seen some internally that don't have MFA or EntraID integration because they simply don't have those as features (mostly legacy systems these days, but they still exist).
I'm also an open-source author (I have the most used bit.ly library on npm - and have had demands and requests too), and I'm the only person you can publicly see on our [company github](https://github.com/ikea) - there's reasons for this - but not every company is leeching, rather there is simply no other alternative.
A lot of the spread of Shai-Hulud is due to s having overly broad credentials on NPM, GitHub and elsewhere. It's not that NPM doesn't support scoped credentials, it's that developers don't want to deal with it so it's not the default. There's no reason why, for example, a developer needs a live credential to publish their package when they're just hacking on code.
This is related to the `curl | bash` pattern. Projects like NPM want to make it easy to get started and hard to reach a failure case so they sacrifice well-known security practices during the growth phase.
Security things will get hacked on later, but again it will cause all kinds of problems because the ecosystem wasn't built for it.
I'd erase that part entirely, as it is not true, from my point of view. My day, as has every other person's day, has exactly 24 hours. As an employee, part of that time is dedicated to my employer. In return, I receive financial compensation. It's up to them to decide how they want to spend the resources they acquired. So yes, each and every company could, in theory, contribute back to Open Source.
But as there is no price tag attached to Open Source, there is also no incentive. In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible.
It is not just that. In a well functioning theoretical free market, no one is going to have time either. The margins are supposed to end up being tight and the competition is supposed to weed out economic inefficiency. Voluntary pro-social behavior is a competitive disadvantage and an economic inefficiency. So, by design, the companies end up not "having time for that".
You need a world that allows for inefficiency and rewards pro-social behavior. That is not the world where we are living in currently.
So companies’ profit motives contribute to this mess not just through the exploitation of open source labor (as you describe) but through externalizing security costs as well.
It’s my take that over the past ~ decade a lot of these companies have been making things a lot better, Windows even requires secure boot these days as well.
That’s the path out of this mess: not just trying to catch it on NPM but moving sensitive data into OS-enforced sandboxes (e.g. Mac containers) so every process you start can’t just read a file and get keys, and using sandboxing features in package managers themselves to restrict when new installs can run code and what they can do (e.g. changing the granularity from “can read any file accessible to the user” to “can read a configuration file at this location and data files selected by the user”), and tracking capability changes (“the leftpad update says it needs ~/.aws in this update?”).
We need to do that long-term but it’s a ton of work since it breaks the general model of how programs work we’ve used for most the last century.
Secure Enclave = store the encryption keys to media in a place where you can't get them
Secure Boot = first step towards remote attestation so they can remotely verify you haven't modified your system to bypass the above
Advertising rules the world.
Is there such a thing as secure hardware that can prevent supply chain attacks (by enabling higher layers to guarantee security) and secure hardware that prevents copying data (by enabling higher layers to guarantee security)?
People who work on permissively licensed software are donating their time to these Fortune 500 companies. It hardly seems fair to call the companies leeches for accepting these freely given donations.
It’s also ok to release paid free software, or closed software, restrictive licenses, commercial licenses, and sell support contracts. It’s a choice.
There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t open source and you have brought dishonor to your family.
This implies some kind of fairness/moral contract in a license like MIT. There is none. It’s the closest thing to donating code to the public domain, and entirely voluntary.
There are plenty of standard licenses with similar clauses restricting commercial use, no need to create a custom one.
But indeed, the truth is that a restrictive license will massively reduce the project’s audience. And that is a perfectly fine choice to make.
The license tells you what you are legally allowed to do. It doesn’t supersede basic concepts of fairness.
The average person would say that if you directly make millions of someone else’s work, the fair thing to do is to pay that person back in some way.
Calling someone a leech is just saying that they aren’t following the the accusers model of fairness. That’s all. There’s no legal definition.
We say things like “my company screwed me over when they fired me right before my RSUs vested” despite that being perfectly legal.
It is not “their” work anymore (IP rights discussions aside) once they published with an unrestricted license. That’s the point. You do it expecting nothing in return, and do it willingly. Expecting “fairness” is a misunderstanding of the whole spirit of it.
It comes about because “work” is overloaded to mean both the activity of creating and the product/result of that activity.
As a bonus maybe you can get some proprietary software open sourced too.
I think there are a lot of high profile opensource projects which are either run by corpos (like React) or have a lot of full time employees submitting code (Linux). But there’s an insanely long tail of opensource projects on npm, cargo, homebrew etc which are created by volunteers. Or by people scraping by on the occasional donation.
Most of the Linux foundation projects, which includes Node are volunteers. Most of the Apache foundation software is from volunteers. Most NPM packages are from volunteers. OpenSSL is volunteers.
There is also a big difference between the developers who are employees on salary versus those that receive enough donations to work in open source full time.
The survey found that specifically linux code is dominated by people who are paid for it.
> Most of the Apache foundation software is from volunteers.
Large Apache project specifically are backed by companies per Apache rules. Each project must have at least three active backing companies. They contribute the most of the code.
Yes the kernel code, but the Linux Foundation projects (mentioned in the comment you quote and reply to) are MUCH more than the kernel.
See the list on https://www.linuxfoundation.org/projects
Not a lot of applications being maintained by altruists, but look under the hood in Linux/GNU/BSD and you fill find a lot of volunteers motivated by something other than money.
I think there are very few projects that do not accept support in any form.
For a lot of single developers that's not a thing they're ready or able to do. Those that can, usually have companies established as a revenue source for their OSS project.
Can you say more about this?
Most people doing this work, both in person and online, are extremely sensitive about this. It’s a hard reality to accept that if this free software went away most people doing the work wouldn’t be able to qualify their income in any significant way to their employer.
With just a bit of retraining those engineers that could not be productive without a ton of npm packages could ship an iPhone app written in Swift.
JS’ standard library is abysmal.
Also, smaller package managers tend to learn from these attacks on npm, and by the time the malware authors try to use similar types of attacks on them the registries already have mitigations in place.
Ruby has had signed gems since v2 [2].
These aren't a panacea. But they do mean an effort has been made.
npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4]
I don't think it's fair to compare npm to the others.
[0] https://docs.pypi.org/attestations/producing-attestations/
[1] https://docs.pypi.org/trusted-publishers/
[2] https://docs.ruby-lang.org/en/master/Gem/Security.html
[3] https://github.com/npm/npm/pull/4016
[4] https://github.com/node-forward/discussions/issues/29
https://docs.npmjs.com/trusted-publishers
https://docs.npmjs.com/generating-provenance-statements
Trusted Publishing is relatively new - GA-ed in July https://github.blog/changelog/2025-07-31-npm-trusted-publish...
No comments yet
Microsoft isn’t any better steward than the original teams.
This issue has happened Plenty under Microsoft’s ownership.
I reckon that the ecosystem would have been much healthier if NPM had not been kept running without the care it requires.
Would love to see some default-secure package management / repo options. Even a 24 hour delayed mirror would be better than than what we have today.
find . -name package.json -not -path "/node_modules/" -exec sh -c ' for pkg; do lock="$(dirname "$pkg")/package-lock.json" [ -f "$lock" ] || continue tmp="$(mktemp)" jq --argfile lock "$lock" \ ".dependencies |= with_entries(.value = $lock.dependencies[.key].version) | .devDependencies |= with_entries(.value = $lock.dependencies[.key].version // $lock.devDependencies[.key].version)" \ "$pkg" > "$tmp" && mv "$tmp" "$pkg" done ' sh {} +
What does this actually achieve?
sure there are other ways for the package maintainer to notice they were pwned, but often they will not notice.
https://github.com/pnpm/pnpm/issues/9921
1. Switch to pnpm, it's not only faster and more space efficient, but also disables post-install scripts by default. Very few packages actually need those to function, most use it for spam and analytics. When you install packages into the project for the first time, it tells you what post-install scripts were skipped, and tells you how to whitelist only those you need. In most projects I don't enable any, and everything works fine. The "worst" projects required allowing two scripts, out of a couple dozen or so.
They also added this recently, which lets you introduce delays for new versions when updating packages. Combined with `pnpm audit`, I think it can replace the last suggestion of setting up a helper dependency bot with zero reliance on additional services, commercial or not:
https://pnpm.io/settings#minimumreleaseage
2. If you're on Linux, wrap your package managers into bubblewrap, which is a lightweight sandbox that will block access to almost all of your system, including sensitive files like ~/.ssh, and prevent anything running under it from escalating privileges. It's used by flatpak and Steam. A fully working & slightly improved version was posted here:
https://news.ycombinator.com/item?id=45271988
I posted the original here, but it was somewhat broken because some flags were sorted incorrectly (mea culpa). I still prefer using a separate cache directory instead of sharing the "global" ~/.cache because sensitive information might also end up there.
https://news.ycombinator.com/item?id=45041798
3. Setup renovate or any similar bot to introduce artificial delays into your supply chain, but also to fast-track fixes for publicly known vulnerabilities. This suggestion caused some unhappiness in the previous discussion for some reason — I really don't care which service you're using, this is not an ad, just setup something to track your dependencies because you will forget it. You can fully self-host it, I don't use their commercial offering — never has, don't plan to.
https://docs.renovatebot.com/configuration-options/#minimumr...
https://docs.renovatebot.com/presets-default/#enablevulnerab...
4. For those truly paranoid or working on very juicy targets, you can always stick your work into a virtual machine, keeping secrets out of there, maybe with one virtual machine per project.
Edit: yes, I've started attempting to write a policy, but the quality of errors is very poor
> But right now there are still no signed dependencies and nothing stopping people using AI agents, or just plain old scripts, from creating thousands of junk or namesquatting repositories.
This is as close as we get in this particular piece. So what's the alternative here exactly - do we want uploaders to sign up with Microsoft accounts? Some sort of developer vetting process? A curated lib store? I'm sure everybody will be thrilled if Microsoft does that to the JS ecosystem. (/s) I'm not seeing a great deal of difference between having someone's NPM creds and having someone's signing key. Let's make things better but let's also be precise, please.
Considering these attacks are stealing API tokens by running code on developer's machines; I don't see how signing helps, attackers will just steal the private keys and sign their malware with those.
but only npm started with a desire to monetize it (well, npm and docker hub) and in its desire for control didn't implement (or allowed the community to implement) basic higiene.