|
|
Subscribe / Log in / New account

Open Infrastructure is Not Free: A Joint Statement on Sustainable Stewardship

The Open Source Security Foundation (OpenSSF) has put together a joint statement from many of the public package repositories for various languages about the need for assistance in maintaining these commons. Services such as PyPI for Python, crates.io for Rust, and many others are working together to try to find ways to sustain these services in the face of challenges from "automated CI systems, large-scale dependency scanners, and ephemeral container builds" all downloading enormous amounts of package data, coupled with the rise of generative and agentic AI "driving a further explosion of machine-driven, often wasteful automated usage, compounding the existing challenges". It is not a crisis, yet, they say, but it is headed in that direction.
Despite serving billions (perhaps even trillions) of downloads each month (largely driven by commercial-scale consumption), many of these services are funded by a small group of benefactors. Sometimes they are supported by commercial vendors, such as Sonatype (Maven Central), GitHub (npm) or Microsoft (NuGet). At other times, they are supported by nonprofit foundations that rely on grants, donations, and sponsorships to cover their maintenance, operation, and staffing.

Regardless of the operating model, the pattern remains the same: a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that generate demand and extract economic value, consume these services without contributing to their sustainability.



to post comments

Missing a link?

Posted Sep 23, 2025 15:49 UTC (Tue) by Kamiccolo (subscriber, #95159) [Link] (1 responses)

Full statement (open letter?) from the OpenSSF:
https://openssf.org/blog/2025/09/23/open-infrastructure-i...

Missing a link?

Posted Sep 23, 2025 15:54 UTC (Tue) by jake (editor, #205) [Link]

oops ... i meant to put that link in the blurb, of course ... now it's there ...

thanks,

jake

simple

Posted Sep 23, 2025 16:05 UTC (Tue) by cen (subscriber, #170575) [Link] (6 responses)

Add rate limits and see how fast each dev sets up a local cache mirror. Problem solved. Docker hub actually started rate limiting pretty aggressively and we fixed the issues on the first failed pipeline.. unless you force the issue, nobody will care.

simple

Posted Sep 23, 2025 17:07 UTC (Tue) by yodermk (subscriber, #3803) [Link] (5 responses)

Yep. I've long thought it is positively insane how many times CI pipelines download the same thing, and no one seems to care.

simple

Posted Sep 23, 2025 19:23 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

On the other hand caching across builds is non-trivial especially in CI settings. Amount of instructions to give to build kit just to save the cache is insane.

I also wish language runtimes would demand populated local caches instead of automatically downloading things by default so at least not using local cache would take more efforts than not.

Mirror security

Posted Sep 23, 2025 19:31 UTC (Tue) by fraetor (subscriber, #161147) [Link] (2 responses)

How many of these language specific package repositories sign their package metadata? The big risk with not downloading from the original source is that the package could be replaced with a different version by the mirror, but if the packages have signed metadata this risk could be minimised.

I guess you would probably want a signed and timestamped index that contains package hashes that is only valid for a few hours, to avoid being vulnerable to getting served an old version of a package. Or perhaps I'm overcomplicating it, and the metadata should always query the source repository, and only the package data should be mirrored.

If we can trust it to be secure, then perhaps CI systems could inject an environment variable with an alternative repository URL to use, transparent to users of the CI system.

Mirror security

Posted Sep 23, 2025 20:02 UTC (Tue) by NAR (subscriber, #1313) [Link] (1 responses)

to avoid being vulnerable to getting served an old version of a package

I think for build reproducibility (and to avoid breaking changes) some environments do prefer to download the same (old) version and not the latest and greatest.

Mirror security

Posted Sep 23, 2025 21:07 UTC (Tue) by fraetor (subscriber, #161147) [Link]

If you know what version you require (and ideally its hash) then you don't need to query the index in the same way.

I'm more talking about when you request the latest version of a well known package, an attacker may want to make the "latest" version appear to be an old one, so they can take advantage of security issues that have since been fixed, and would be able to provide a valid signature because that package _was_ legitimately served by the repository, just before the vulnerability was fixed.

simple

Posted Sep 23, 2025 21:10 UTC (Tue) by ballombe (subscriber, #9523) [Link]

Indeed, I am a big fan of the CI concept, but the way CI is implemented nowadays is totally disgusting.
It seems like developers now have lost all their sysadmin skill.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds