simple

Posted Sep 23, 2025 16:05 UTC (Tue) by cen (subscriber, #170575)
Parent article: Open Infrastructure is Not Free: A Joint Statement on Sustainable Stewardship

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.