PyPI现在支持归档项目 - The Trail of Bits博客
Facundo Tuesca
2025年1月30日
engineering-practice, open-source, supply-chain
PyPI现在支持将项目标记为已归档。项目所有者可以归档其项目,以告知用户该项目预计不再接收任何更新。
项目归档是供应链安全大局中的一环:通过公开归档状态,PyPI使下游消费者能够更明智地决定依赖哪些软件包。特别是,归档项目明确表示该项目无意进行未来的安全修复或持续维护。
得益于这一信号,下游消费者可以更好地决定是否限制或迁移对特定软件包的使用,而无需依赖关于项目活动或维护状态的启发式方法。这产生了良性的双重效应:下游对其供应链状态有更清晰的了解,而上游应收到更少分散注意力的、多余的维护信息请求。
这项工作是我们在PyPI以及更广泛的Python打包领域持续改进供应链安全的一部分。有关我们之前工作的更多信息,请查看我们早期的一些文章:
- 2024年11月:证明:PyPI上的新一代签名
- 2023年11月:我们对PyPI的审计
- 2023年5月:可信发布:打包安全的新基准
- 2022年11月:Python中的ABI兼容性:能有多难?
- 2019年6月:2019年正确实施双因素认证
最后,项目归档只是开始:我们还在研究其他维护者控制的项目状态,以及额外的PyPI功能,以改善处理项目“生命周期”时的上游和下游体验。敬请关注这些方面的进展!
为什么状态重要
在PyPI上标记项目状态的能力是一个长期存在的功能请求。这适用于被废弃、无人维护、功能完成、已弃用等项目,维护者希望正确设置用户对预期未来更新甚至使用认可的期望。
随之出现的一个有趣问题是:应该支持哪些状态,它们的语义是什么?理想情况下,项目应有一个单一的“主要”状态,但其中一些状态在语义上重叠(如“废弃”和“无人维护”),而其他状态并不互斥(一个项目可以同时是功能完成和无人维护)。
在PyPI的问题跟踪器上有一个关于应该添加哪些状态的开放讨论。作为第一步,大家一致认为“归档”是有用的,并且有足够清晰的语义,成为第一个添加的状态。
归档项目
项目所有者可以通过导航到项目的设置页面并向下滚动到末尾的以下部分来归档项目:
图1:归档项目
这让所有者了解语义(预计不再有更新),并建议通过最终发布为用户提供更多背景信息。
归档项目后,用户将在项目的主要PyPI页面上看到以下通知:
图2:项目已归档
最后,项目所有者可以在需要时随时取消归档项目。
重要的是:项目归档与撤回或完全删除不同。归档的项目永远不会被删除,并且与撤回的项目不同,默认情况下仍可解析。PyPI也永远不会基于归档状态删除或修剪项目:归档仅旨在使项目维护者能够将其项目状态传达给下游消费者。
幕后机制
在幕后,维护者控制的项目状态是最近添加到PyPI的一个更大功能的特化:项目隔离。得益于为隔离功能开发的生命周期状态模型和状态机,我们能够快速扩展PyPI的项目状态以包括新的“归档”状态。我们预计未来的状态添加也会同样容易!
有关项目隔离的更多信息,请参阅PyPI博客。
下一步是什么?
项目归档目前记录并在PyPI的Web界面上显示。这对于人类决定是否使用(或停止使用)软件包非常有用,但并不能立即帮助安装程序(如pip和uv)在依赖项变为归档时提醒开发人员。
换句话说:此功能将帮助用户,但尚未帮助机器可读的情况。这是我们正在努力的方向!
“归档”状态也不是打包状态的终极解决方案:如上所述,还有许多其他状态(“已弃用”、“功能完成”等)项目维护者希望以一致的方式表达。既然我们有了通过“归档”状态实现这一目标的蓝图,我们也将研究这些状态。
致谢
我们要感谢PyPI管理员和维护者在开发过程中审查我们的工作并提供宝贵的反馈。特别感谢Mike Fiedler(作为PyPI的安全与安全工程师)和Dustin Ingram(作为PyPI的维护者管理员之一)付出的时间和考虑。
我们对此功能的开发是我们由Alpha-Omega资助的PyPI和Python打包持续工作的一部分。Alpha-Omega的使命是通过催化对最关键的开源软件项目和生态系统的可持续安全改进来保护社会。
如果您喜欢这篇文章,请分享: Twitter LinkedIn GitHub Mastodon Hacker News
页面内容
为什么状态重要
归档项目
幕后机制
下一步是什么?
致谢
近期文章
- 使用Deptective调查您的依赖项
- 系好安全带,Buttercup,AIxCC的评分回合正在进行中!
- 使您的智能合约超越私钥风险
- Go解析器中意想不到的安全隐患
- 我们审查Silence Laboratories首批DKLs23库的收获
© 2025 Trail of Bits.
使用Hugo和Mainroad主题生成。