現在の形では、信頼できる公開は限られたユースケースにしか適用されません。サポートは少数のCIプロバイダーに限定されていて、新しいパッケージの初回公開には使えず、公開時に必須の2FAなどの強制メカニズムもまだ提供されていません。これらの制約から、メンテナグループは信頼できる公開を普遍的なアップグレードとして扱うことに対して慎重になっています。特に影響の大きいパッケージや重要なパッケージについてはそうです。これは厳密には正確ではありません。PyPIのために信頼できる公開を設計したとき、OIDC IdP（通常はCIプロバイダー）全体に対して汎用的に設計しましたし、新しいプロジェクトを信頼できる公開を通じて作成するための配慮も明示的に含めました（これを「保留中」のパブリッシャーと呼びました）。後の信頼できる公開技術の採用者全員がこれを採用したわけではないのは、残念で理解できることだと思います（パッケージの存在に関するデータモデルや仮定が複雑になるため）。ここでの多くの問題は、GitHub側が自ら引き起こしていると思います。通常のAPI認証情報を完全に削除する決定は非常に攻撃的に感じますし、信頼できる公開の実装とは全く関係ありません。この二つを同じキャンペーンで結びつけることで、ユーザーや統合者にとって不必要に混乱を招いているようです。

私は非常に多く使われているnpmパッケージをメンテナンスしていて、この状況には本当に神経を使っています。最近のリリースでは、数十のパッケージの中で、手動でpackage-lockやpackage.jsonの変更を読み、すべての依存関係の変更を確認していました。幸い、私たちのコアライブラリには外部依存関係がありませんが、ツールにはたくさんあります。信頼できるパブリッシャーに移行するか、数人のチームメンバーに2FAでローカルに公開させるか、厳しい選択を迫られました。私たちは、何年もレビュー手順を伴う自動化プロセスを持っていたので、信頼できるパブリッシャーを選びましたが、ハッキングの可能性がまだあることは理解しています。だから、今はどのPRにも非常に慎重になっています。信頼できるパブリッシャーを有効にするのは、たくさんのパッケージがあって本当に大変でした。私たちが望んでいるのは、信頼できるパブリッシャーを使いながら、CIベースの公開設定を続けられることです。ただし、その際には人間による2FAのステップが必要です。でも、それは完全な解決策の一部に過ぎません。HITL（人間が介在するプロセス）は、悪意のあるコードの拡散を遅らせることしか保証されていません。実際には、妥協された依存関係からプロジェクトを守ることはできず、広めるのを防ぐこともできません。これらすべては、依然として人間の手に委ねられています。私たちは、依存関係をより良くロックダウンし、分析するためのツールや、公開前にパッケージを分析するためのツールが必要です。また、CIを実行する前にサードパーティのPRを分析し、サンドボックス化するためのより良いツールも欲しいです。今はHITLがあるけど、テストを実行する前に各PRを手動で調査しなければなりません。

ちょっと明確にしておくと、「信頼できる公開」とは逆のベンダーロックインの一種を意味しますか？それに使えるのは一部のCIシステムだけです。

npmが単にCLIを同時に更新していれば、こんなに混乱はなかったでしょう。今でも2FAを使って公開することができないのは、彼らのCLIがそれに対応できないからです。

公開に2FAを要求したり、信頼できる公開を使うことで、この問題の大多数を防げるはずです。唯一の難しい点は、信頼できる公開を使用しているときに、自分のプルリクエストを承認できないようにすることです。それは2FAを要求することに戻るべきです。