摘要

  • PyPI 说明：从项目中移除用户，不会移除该用户可能登记过的 Trusted Publishers。
  • 人员角色、CI 发布配置、短期上传令牌和单个文件的溯源分别回答不同问题。
  • 完整的离场记录要把这些状态并列保存，不能让一张名单替代另一张名单。

项目离场常被写成一个已完成的动作：账号删除，风险关闭。PyPI 的 Trusted Publishing 安全说明给出了更准确的边界。移除项目用户，不会同步删除该用户可能登记的 Trusted Publishers；因此，维护者离场时应审查所有 Trusted Publishers。

这不是对任何项目的怀疑。它不表示离开的人一定登记了发布者，也不表示保留的配置有风险，更不表示发生过发布。它只指出两份记录不能互相篡改。协作者列表证明的是人的项目角色改变；它不证明哪些 CI 身份仍被项目接受为发布身份。

PyPI 的角色划分使差别变得具体：组织中的 Maintainer 可以上传发布物，Owner 可以管理项目和协作者。Trusted Publishing 则处理另一件事：某个 CI 服务的特定 OpenID Connect 配置，能否换取一个面向该项目、寿命很短的上传令牌。短期令牌减少长期凭据暴露，却不会把 CI 配置自动改写为人员角色变更的结果。

所以至少要分开四句话。“协作者已移除”是账户事实；“发布路径已撤销”需要逐一检查 Trusted Publisher；“该路径未发布文件”需要事件记录；“此文件由某一身份发布”可由该文件的发布证明与溯源支持。它们可以同时成立，但任何一句都不能自动证明其余几句。

PyPI Publish Attestation 的价值也正来自这个限度。它可说明某一特定分发文件通过 Trusted Publisher 上传，并显示使用的身份；Integrity API 可取得指定项目、版本和文件的溯源。它们记录的是一个已命名的文件，而不是一次完整离场，也不证明旧协作者当前控制某个工作流，更不评价代码是否值得信任。PyPI 明确指出，证明可以显示包来自何处，不能单独回答应否信任该身份或代码。

真正的治理风险是用一个档案顶替另一个。移除账号的工单容易被保存；Trusted Publisher 的配置和 CI 权限可能各在不同控制面。日后只剩工单时，读者往往会误以为它回答了“当时有哪些发布者、谁复核过、哪些被保留或撤销、后续发布使用何种身份”等问题。

Daniel Kade 建议保留一份有限的离场关联记录：项目、角色变动、某一时点的发布者清单、安全粒度下的身份约束、负责复核者、每项发布者的保留/修改/移除决定，以及此后文件溯源的独立观察。它不要求公开密钥或工作流细节。其作用是让权限变更的范围可复查，而不是把正常离场写成事故。

来源

  1. PyPI — Trusted Publishers 安全模型
  2. PyPI — 使用 Trusted Publisher 发布
  3. PyPI — 组织账户的角色和实体
  4. PyPI Publish Attestation v1
  5. PyPI — 证明的安全模型
  6. PyPI Integrity API