Dependency cooldowns turn you into a free-rider

A trend that feels safe — until you look closer

It has been reported that dependency cooldowns are suddenly in vogue, touted as an easy mitigation for supply‑chain attacks: wait N days after a package is released before you adopt it, and let the early adopters catch any nastiness. Sounds sensible on the surface. It has also been reported that most supply‑chain compromises are detected within a few days, so the math seems to work. But wait — what are we really doing when we ask everyone to sit back and let someone else get burned first?

The moral and practical hole at the centre

Here’s the ugly bit: cooldowns work by free‑riding on the pain of others. If you delay, you bank on other teams acting as unpaid, inadvertent beta testers who will notice — and publicize — a compromised release. Allegedly, even a single personal pip install outside a project’s config could have been enough to compromise some users recently, showing how easy it is to bypass your own safeguards. Is that a policy you want to scale across an ecosystem? It’s not just inefficient — it’s ethically fraught. And practically, cooldowns multiply friction: every package manager has to adopt its own flavor, every project must configure a cooldown, and accidental workarounds are trivial.

Do the hard thing once: centralized upload queues

The alternative is blunt but cleaner: move the wait to the publisher side. An upload queue on central indexes would separate publication from distribution — uploads sit in a short holding pattern while automated scanners run, public diffs are generated, and volunteer testers can opt in. Upload queues aren’t theoretical; Debian has long used them. Central action means one policy, one place to run checks, and fewer ways to shoot yourself in the foot. In short: if we want to stop outsourcing security to the unlucky few, don’t make every downstream project improvise the same half‑baked solution.

Sources: calpaterson.com, Lobsters