PyPI、リリースから14日後の新規ファイルアップロードを拒否

PyPIは、トークンや配布ワークフローが乗っ取られても安定した既存リリースが汚染されないよう、公開後 14日を過ぎたリリース への新規ファイルアップロードをブロックする
現時点で実際の悪用事例は確認されていないが、攻撃者がその可能性を知らなかったことを除けば、攻撃を防ぐ 技術的な障壁は存在しなかった
上位15,000パッケージを調査した結果、リリースから14日後に Python 3.14 向け cp314 ホイールを追加したプロジェクトは 56件 にすぎなかった
既存リリースに新しい Python バージョン対応を追加していたプロジェクトは、今後 次のバージョンをリリースする必要があり、PyCon US 2026 Packaging Summit でもこれを受け入れ可能な方針と判断した
まだリリースの open / closed 状態を定義・確認する API はないため、この動作に依存すべきではなく、今後 PEP 694 の Upload 2.0 API と Staged Previews が関連するセマンティクスを定める予定

古いリリースを閉じる理由

PyPIの変更は、古く安定したリリースに新しいファイルを追加する経路を遮断する
- プロジェクトの公開トークンやワークフローが侵害されても、既存リリースの一部だけが悪意あるファイルに置き換えられる状況を防ぐ
- リリース内に侵害されたファイルとそうでないファイルが混在する曖昧な状態を防ぎ、PyPI管理者の後始末も減らす
議論は PEP 740 Digital Attestations の作業中だった 2024年1月に開始され、2026年3月に再開された
- きっかけは LiteLLM と Telnyx のサプライチェーン侵害で、両プロジェクトが使っていた Trivy GitHub Action の変更可能な参照（mutable reference）が原因だった
一部のプロジェクトが、すでに公開済みのリリースに新しい Python バージョン対応ファイルを追加していたため、初期の議論はいったん中断された
- 変更の影響を把握するため、PyPIデータベースで古いリリースにファイルを追加したプロジェクトを経過日数ごとに調査した
- 上位15,000パッケージの cp314 ホイールを別途確認した結果、14日後に Python 3.14 対応ホイールを公開したプロジェクトは56件だった

PyCon US 2026 Packaging Summit では、新しい Python バージョンをサポートする際に 次のバージョンへ上げるよう求めても受け入れ可能だ という大まかな合意が形成された
調査データと合意をもとに Warehouse パッチが進められ、2026年7月8日にマージ された
現在の制限は、まだ安定したインターフェースとは見なせない
- 「これ以上新しいファイルを受け付けないリリース」の定義は確定しておらず、状態を確認する API もない
- PEP 694 が Upload 2.0 API と Staged Previews を標準化した後、リリースを open または closed として扱うセマンティクスが整備される予定