PyPI现已支持项目归档功能

作者：Facundo Tuesca
发布日期：2025年1月30日
标签：工程实践、开源、软件供应链

PyPI现已支持将项目标记为归档状态。项目维护者可通过归档功能明确告知用户：该项目将不再接收任何更新。

项目归档是软件供应链安全拼图中的关键一环：通过公开归档状态，PyPI使下游用户能够更明智地决策依赖包的选择。特别需要注意的是，项目归档明确传递出"不再提供安全修复或持续维护"的信号。

得益于这一明确信号，下游用户无需再依赖项目活跃度或维护状态的启发式判断，即可更好地决策是否限制或迁移对特定软件包的使用。这将形成良性双重效应：下游用户能更清晰掌握供应链状态，而上游维护者也能减少来自上游的冗余维护信息请求。

此项工作是我们在PyPI及更广泛的Python打包生态中持续推动供应链安全改进的延续。关于我们先前工作的更多信息，可参考以下历史文章：

• 2024年11月：《PyPI上的新一代签名：证明机制》
• 2023年11月：《我们对PyPI的审计报告》
• 2023年5月：《可信发布：打包安全的新标杆》
• 2022年11月：《Python中的ABI兼容性：究竟有多难？》
• 2019年6月：《2019年正确实现双因素认证》

项目归档仅仅是个开始：我们还在研究更多由维护者控制的项目状态类型，以及增强PyPI功能以改善处理项目"生命周期"时的上下游体验。敬请关注相关进展！

状态标记的重要性

在PyPI上标记项目状态的能力是长期存在的功能需求。这对于已废弃、无人维护、功能完备、已弃用等项目尤其重要——维护者需要正确设置用户对未来更新甚至使用认可的期望。

随之而来的有趣问题是：应该支持哪些状态？其语义如何？理想情况下，项目应具有单一"主要"状态，但某些状态在语义上重叠（如"废弃"和"无人维护"），而有些状态并不互斥（项目可能同时处于"功能完备"和"无人维护"状态）。

PyPI的问题跟踪器上正在公开讨论应该添加哪些状态。作为第一步，业界共识是"归档"状态非常有用且语义清晰，因此成为首个添加的状态。

如何归档项目

项目所有者可通过导航至项目设置页面，向下滚动至末尾部分进行归档操作：

该界面明确告知所有者归档的语义（不再期待更新），并建议通过最终版本发布为用户提供更多上下文信息。

项目归档后，用户将在项目主页面看到以下通知：

最重要的是，项目所有者随时可以取消归档。

关键区别：项目归档与撤回(yanking)或彻底删除不同。已归档项目永远不会被删除，且与撤回项目不同，默认情况下仍可被解析。PyPI也永远不会基于归档状态删除或清理项目：归档功能纯粹是为了让项目维护者能够向下游用户传达项目状态。

技术实现内幕

在底层，维护者控制的项目状态是PyPI最近添加的更大功能——项目隔离(quarantine)——的特化实现。得益于为隔离功能开发的LifecycleStatus模型和状态机，我们能够快速扩展PyPI的项目状态以包含新的"已归档"状态。我们预期未来添加新状态也会同样简便！

关于项目隔离的更多信息可在PyPI博客上查看。

未来发展方向

项目归档状态当前已在PyPI网络界面记录和展示。这对人类决策是否使用（或停用）某个软件包非常有用，但尚未立即帮助安装程序（如pip和uv）在依赖项被归档时向开发者发出警报。

换句话说：此功能有助于用户，但尚未支持机器可读场景。这正是我们正在努力的方向！

“已归档"状态也并非包装状态的终极解决方案：如上所述，还存在许多其他状态（“已弃用”、“功能完备"等）需要项目维护者以一致的方式表达。既然我们已经通过"已归档"状态建立了实现蓝图，我们也将继续研究这些状态。

致谢

我们要感谢PyPI管理员和维护者在开发过程中审查我们的工作并提供宝贵反馈。特别感谢Mike Fiedler（作为PyPI安全工程师）和Dustin Ingram（作为PyPI维护管理员）付出的时间和考虑。

此功能的开发是我们由Alpha-Omega资助的PyPI和Python打包持续工作的一部分。Alpha-Omega的使命是通过催化最关键开源软件项目和生态系统的可持续安全改进来保护社会。

分享本文： [Twitter] [LinkedIn] [GitHub] [Mastodon] [Hacker News]

页面内容
近期文章
《使用Deptective调查您的依赖项》
《做好准备，AIxCC评分轮正式开始！》
《让智能合约超越私钥风险》
《Go解析器中意想不到的安全隐患》
《评审Silence Laboratories首批DKLs23库的收获》
© 2025 Trail of Bits.
使用Hugo和Mainroad主题生成。