'Open Source Registries Don't Have Enough Money To Implement Basic Security' (theregister.com) 24
Google and Microsoft contributed $5 million to launch Alpha-Omega in 2022 — a Linux Foundation project to help secure the open source supply chain. But its co-founder Michael Winser warns that open source registries are in financial peril, reports The Register, since they're still relying on non-continuous funding from grants and donations.
And it's not just because bandwidth is expensive, he said at this year's FOSDEM. "The problem is they don't have enough money to spend on the very security features that we all desperately need..." In a follow-up LinkedIn exchange after this article had posted, Winser estimated it could cost $5 million to $8 million a year to run a major registry the size of Crates.io, which gets about 125 billion downloads a year. And this number wouldn't include any substantial bandwidth and infrastructure donations (Like Fastly's for Crates.io). Adding to that bill is the growing cost of identifying malware, the proliferation of which has been amplified through the use of AI and scripts. These repositories have detected 845,000 malware packages from 2019 to January 2025 (the vast majority of those nasty packages came to npm)...
In some cases benevolent parties can cover [bandwidth] bills: Python's PyPI registry bandwidth needs for shipping copies of its 700,000+ packages (amounting to 747PB annually at a sustained rate of 189 Gbps) are underwritten by Fastly, for instance. Otherwise, the project would have to pony up about $1.8 million a month. Yet the costs Winser was most concerned about are not bandwidth or hosting; they are the security features needed to ensure the integrity of containers and packages. Alpha-Omega underwrites a "distressingly" large amount of security work around registries, he said. It's distressing because if Alpha-Omega itself were to miss a funding round, a lot of registries would be screwed. Alpha-Omega's recipients include the Python Software Foundation, Rust Foundation, Eclipse Foundation, OpenJS Foundation for Node.js and jQuery, and Ruby Central.
Donations and memberships certainly help defray costs. Volunteers do a lot of what otherwise would be very expensive work. And there are grants about...Winser did not offer a solution, though he suggested the key is to convince the corporate bean counters to consider paid registries as "a normal cost of doing business and have it show up in their opex as opposed to their [open source program office] donation budget."
The dilemma was summed up succinctly by the anonymous Slashdot reader who submitted this story.
"Free beer is great. Securing the keg costs money!"
And it's not just because bandwidth is expensive, he said at this year's FOSDEM. "The problem is they don't have enough money to spend on the very security features that we all desperately need..." In a follow-up LinkedIn exchange after this article had posted, Winser estimated it could cost $5 million to $8 million a year to run a major registry the size of Crates.io, which gets about 125 billion downloads a year. And this number wouldn't include any substantial bandwidth and infrastructure donations (Like Fastly's for Crates.io). Adding to that bill is the growing cost of identifying malware, the proliferation of which has been amplified through the use of AI and scripts. These repositories have detected 845,000 malware packages from 2019 to January 2025 (the vast majority of those nasty packages came to npm)...
In some cases benevolent parties can cover [bandwidth] bills: Python's PyPI registry bandwidth needs for shipping copies of its 700,000+ packages (amounting to 747PB annually at a sustained rate of 189 Gbps) are underwritten by Fastly, for instance. Otherwise, the project would have to pony up about $1.8 million a month. Yet the costs Winser was most concerned about are not bandwidth or hosting; they are the security features needed to ensure the integrity of containers and packages. Alpha-Omega underwrites a "distressingly" large amount of security work around registries, he said. It's distressing because if Alpha-Omega itself were to miss a funding round, a lot of registries would be screwed. Alpha-Omega's recipients include the Python Software Foundation, Rust Foundation, Eclipse Foundation, OpenJS Foundation for Node.js and jQuery, and Ruby Central.
Donations and memberships certainly help defray costs. Volunteers do a lot of what otherwise would be very expensive work. And there are grants about...Winser did not offer a solution, though he suggested the key is to convince the corporate bean counters to consider paid registries as "a normal cost of doing business and have it show up in their opex as opposed to their [open source program office] donation budget."
The dilemma was summed up succinctly by the anonymous Slashdot reader who submitted this story.
"Free beer is great. Securing the keg costs money!"
Let's put it in perspective (Score:5, Insightful)
*Sigh* Such Pre-2026 Thinking (Score:5, Funny)
Stand aside, dinosaurs, we're in 2026 now! All you have to do is spin up an AI agent or two and give them admin credentials. Tell them to secure the registries. Tell them to think *deeply*. Tell them to make no mistakes. Done.
Now was that so hard?
Re: (Score:1)
hilarious
Use BitTorrent for downloads (Score:5, Interesting)
Re: (Score:3)
One idea to reduce costs is use BitTorrent for distribution of the packages.
Web site hosts only a torrent file.
Everyone has to download via the torrent file. If nobody is seeding.... well then bad luck.
If somebody wants a URL for the package manager, they will be required to download from torrent and set up their own local mirror.
Yep, package distribution via peer to peer would happen if those "grants" dried up.
There is every incentive to never have such a system even pop up for the companies selling centralized data access.
Re: (Score:2)
And f*cking caches. Why does every CI pipeline re-download packages all the time? If I were running PyPi, users who download the same package every hour would be blacklisted fast. Just because people are lazy they are producing huge costs. Fine if they can pay their own bandwidth, but that accumulates on the other side.
Re: (Score:2)
There is HTTP seeding to cover when there are no other seeds. Internet Archive uses it, although most of the time their torrents are broken anyway for other reasons.
One interesting feature of using BitTorrent is that it allows anyone to help distribute packages with zero effort on the repo operator's part. They just join the swam and seed. I think it would need a security upgrade though - BitTorrent's hashing isn't really security grade.
Well it's the job of the distribution (Score:4, Interesting)
The main problem is that "Registries" make the problem of dependencies seem easy. Dependencies are a problem, you trust in code you didn't write. That's why in older environments those dependencies either are managed by your distribution (which will do some minor amount of checking) or installing them is some effort. (though not that much)
This effectively deters you from using dependencies unless it _really_ makes sense. You install a dependency because you want to speak a complex protocol or you need some highly optimized algorithm. You don't use a dependency for "leftpad".
Having "self service" registries is not a solution for this. It only lowers the burden to depend on code.
Re: (Score:2)
It would be a lot less of an issue if apps were sandboxed by default. Android does that, for example, so even if code is malicious it will need to string together multiple exploits, or ask the user for permissions, before it can do much more than show them some ads.
People used to say it was crazy that a web browser downloaded code from random websites and executed it. At least the browser is running said code in a sandbox, and the browser process itself is in another sandbox. I suppose repos aren't random,
sandboxing is no solution (Score:2)
Sandboxing is no solution since software actually needs to do stuff.
You cannot contain malware that way, and mobile platforms are a great example where this fails. Any app can just bully its user into giving it the permissions it wants to have.
Re: (Score:2)
A lot of apps would benefit from not having certain permissions. Some don't need internet access, some don't need filesystem access (outside their own sandboxed storage).
Re: (Score:2)
Yes, but first of all, how are you going to do that on a module basis for programming languages? Second has there ever been an instance of this actually preventing malware?
I mean look at mobile devices. Those are the most disease riddled devices a normal person has. Even apps you use to access services you pay for are full of third party tracking malware.
It's a concept that sounds nice in theory, and does have _some_ security benefit, but it's by far not sufficient to reign in malware.
Re: (Score:2)
Languages don't need support. The calls to e.g. open() just fail if they have not requested the relevant permission first.
Of course it has prevented malware. Ransomware can't encrypt your files if it doesn't have access to your files, can it? Not without chaining together exploits to escape the sandbox, which is much harder and much less common.
Re: (Score:2)
Well you do need language support, as in many languages you have no protection between components. So while you might not be able to directly open a file, you can get the rest of the program to open a file for you.
Also things like, for example a text-editor, would be rather pointless if they couldn't open and modify your files. If they can do that, they can also encrypt them easily.
Re: (Score:2)
I have a couple of text editors on my phone that don't have any external file access. They only use their own files and databases, with cloud sync.
Re: (Score:2)
"People used to say it was crazy that a web browser downloaded code from random websites and executed it."
I still say that's crazy. Especially the practice of *linking* to external libraries and packages. If my website needs some functions from a library or framework I'm at least going to be downloading the version that works for me and host it myself.
Linking to someone else's packages, that can change out from under you without you even knowing about it, seems the height of lunacy.
Charge per download (Score:2)
50 cents per download for example, maybe 25 cents. Unlimited for donors.
Is that a bad idea?
Re: (Score:2)
How large donation?
If your CI pipeline downloads the package 10 times a day and the download is worth 25 cent, then the donation would have to be large to cover the costs the same way. If you want to sell access, a blanket label "Donor" cannot be a flatrate.
Bloat, anyone? (Score:4, Insightful)
This targets the wrong people (Score:1)
It seems, that the parties involved were unable to fulfill that level and rather removed it than having to admit that they are not up to date with their processes.
No
Lacking standard libraries (Score:2)
This way or another, reviewing a registry with thousands of free uploads is hard to manage. And do you want to give any guarantees on your basic review? And on checking the supply chain?
The problem is, that many more "modern" programming languages rely on external projects for a lot of stuff that should either be in the standard library or be implemented in the project itself. Nobody can control a dependency tree with 100+ small to medium sized projects. Why do I need third-party code for a http request? Th