Dependency cooldowns make you a free rider

Dependency cooldowns are an approach where you don't accept a new version immediately but wait N days before adopting it. This takes advantage of the fact that supply chain attacks are usually discovered within a few days, but in practice it relies on a free-rider structure where other people get hurt first.

This approach may be somewhat advantageous for an individual, but it shifts costs onto the ecosystem as a whole. Moreover, in environments like Python where multiple package managers exist, each tool must support it separately, and the configuration has to be repeated for every project, creating a heavy management burden. It's also easy to accidentally bypass the configuration.

The alternative is not a cooldown per project, but an upload queue on a central dependency server. Instead of distributing a package immediately after it's published, you make it wait for a certain period. During this period, you can:

• Run internal lint and automated security checks
• Show a public diff based on the built package
• Distribute only to beta testers who have explicitly opted in
• Send advance notifications to maintainers

This model is similar to Debian's upload queue. Debian has a 2 to 10 day waiting period after upload before something moves to testing. The author believes language-specific package indexes should likewise separate publication from distribution.

The benefits of an upload queue aren't limited to security. Because time passes before a release is made public, it reduces the power of release credentials, and it also eliminates the unnecessary surprise of new versions suddenly appearing. Sending maintainers a notification like "Release 2.4.1 has entered the upload queue" also helps with attack detection.

This logic becomes even stronger in AI/LLM environments. The author considers markdown to effectively behave like an executable file format. In structures like Agent Skills, where downloading a markdown file changes an LLM's behavior, supply chain attacks and prompt contamination become more dangerous. Public memory systems for AI agents, like Soapstones, are effectively markdown package managers too, so the same problem arises.

So the author argues that a double upload queue is needed on the AI side. One review by admins/moderators for security, and a second approval by the agent owner. This is to prevent uploads of secrets or the injection of malicious phrases like "Disregard that!"

On the cost issue, the author believes large package indexes aren't actually completely impoverished. Like Debian's security team, exceptions can be handled, and for commercial projects, expedited review could be offered as a paid service to cross-subsidize security operating costs. Ultimately, a cooldown that's reasonable for an individual can be a reckless default at the community level, so the author concludes that a centralized upload queue is a better solution than distributed cooldowns.