要約

  • PyPIは、プロジェクトから利用者を削除しても、その利用者が登録したTrusted Publisherは削除されないと明記する。
  • 協力者の役割、CIの公開設定、短期トークン、個別ファイルの来歴は別々の事実を示す。
  • 退任時の記録は、それらを結びつけて残すべきで、ひとつの画面を全体の証拠にしてはならない。

共同管理者の削除は、しばしば完了の印として扱われる。PyPIのTrusted Publishingに関する安全性の説明は、その印に限界を付ける。利用者をPyPIプロジェクトから外しても、その人が登録したTrusted Publisherは自動では消えない。だからPyPIは、メンテナーのオフボーディングで全Trusted Publisherを確認するよう求めている。

ここから、誰かが不正をしたとは導けない。退任者が公開者を登録していたとも、残った設定が危険だとも、公開物が出たとも分からない。分かるのは、人的な権限表とCI公開の身元表が同じ台帳ではないということだ。名前を消した記録は役割変更の証拠であり、どの自動身元がなお受け入れられるかの証拠ではない。

PyPIの組織ロールでも境界は明確である。Maintainerはリリースをアップロードでき、Ownerはプロジェクトと共同作業者を管理できる。Trusted Publishingは別の問いを扱う。特定のCIサービス設定がOpenID Connectの身元を使い、当該プロジェクトだけに短期間有効なアップロード権限を得られるかという問いである。短命の権限は長期秘密の露出を小さくするが、CI設定を人の削除に連動して書き換えるわけではない。

従って、事実は分けて書く必要がある。「共同作業者を外した」はアカウントの事実。「公開経路を取り消した」は各Trusted Publisherの確認を要する。「その経路で公開されなかった」はイベントの記録を要する。「この配布物はこの身元で公開された」は、公開アテステーションと来歴で限定的に確かめられる。一つの出来事で全部が真になることはあっても、どれか一つが残りを証明するわけではない。

PyPI Publish Attestationは、特定の配布物がTrusted Publisherを通じてアップロードされ、どの身元が使われたかを示し得る。Integrity APIは、指定したプロジェクト、版、ファイルについて来歴を返す。それはファイルについての観測であって、退任手続全体の議事録でも、元利用者が今のワークフローを操作している証明でもない。PyPI自身も、アテステーションは由来を示せても、その身元やコードを信頼すべきかは決めないと説明する。

実務で起きやすいのは記録の取り違えである。アカウント削除のチケットは見つけやすい一方、公開者設定とCI権限は別の管理面にある。後からチケットだけを見た人は、当時の公開者一覧、確認者、残置・変更・削除の判断、後続ファイルの身元まで答えていると思い込みやすい。

Daniel Kadeが勧めるのは、秘密を公表しない限定的な結合記録である。プロジェクト、役割変更、時点付きTrusted Publisher一覧、安全な粒度の身元制約、確認責任者、各設定の保持・変更・削除判断を結ぶ。以後のファイル来歴は別の観測として添える。目的は通常の退任を事故に見せることではなく、どの権限状態がどこまで確認されたかを検証可能にすることである。

情報源

  1. PyPI — Trusted Publishersのセキュリティモデル
  2. PyPI — Trusted Publisherで公開する
  3. PyPI — 組織アカウントのロール
  4. PyPI Publish Attestation v1
  5. PyPI — アテステーションのセキュリティモデル
  6. PyPI Integrity API