据 calpaterson.com 报道，目前为了防范供应链攻击而日益流行的“依赖包冷却期”（dependency cooldowns）机制存在根本性缺陷，因为这种做法实际上是在利用其他开发者的“痛苦与损失”。
随着包管理器越来越多地采用延迟更新新版本软件的策略，批评人士认为这种做法制造了“搭便车”问题。该策略的核心逻辑在于：寄希望于在恶意更新被撤回之前，那些没有设置冷却期的用户能率先发现问题。
该媒体报道称：“依赖包冷却期机制是通过‘搭便车’来运作的，其代价是其他人的痛苦与损失。这一计划的核心在于，寄希望于那些‘不够聪明’、没有配置冷却期的人，能够充当新发布软件包的免费、无意识的测试员。”
除了伦理层面的争议，这种做法在碎片化的 Python 生态系统中也难以全面推行。目前，Python 至少使用了八种不同的包管理器，每种管理器和项目都需要进行单独的手动配置才能发挥作用。
即便是在配置正确的项目中，漏洞依然存在。只要在特定项目配置之外运行单个命令（例如手动执行 `pip install`），就可能绕过已建立的保护机制，使开发者面临黑客攻击的风险。
建立中央上传队列的必要性
专家建议，与其依赖去中心化的冷却机制，不如通过“上传队列”将延迟环节转移到中央依赖服务器上。这种方式可以将软件包的“发布”与“分发”过程分离。
通过建立上传队列，像 npm 或 PyPI 这样的中央索引库可以运行自动化的安全扫描，展示变更内容的公开差异对比（diff），并在代码进入公共领域之前，设置专门的公开测试期。
这种模式目前已在 Debian 项目中得到应用，它能将负担从个人开发者和包管理器身上卸下。此外，通过确保未经授权的变更在广泛分发前都必须在队列中接受检查，该模式还能降低因发布凭证被盗而导致的风险。
