Trusted Publishingをパッケージの信頼シグナルと見なすべきではない

 (blog.yossarian.net)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • Trusted Publishing における「信頼」は、パッケージを人間が信頼してよいという意味ではなく、CI/CD のような外部の マシンアイデンティティ とパッケージインデックスの間にあるアップロード認証関係を指す
  • PyPI の実装は OIDC フェデレーション 上で動作し、長期 API トークンの代わりに、短命でスコープの狭い公開用認証情報を発行することで、長期かつ過剰権限の認証情報の露出を減らす
  • PyPI が 2023 年に公開した後、npm、RubyGems、crates.io、NuGet などにも広がったが、データモデルの複雑さ、OIDC プロバイダーごとの処理、CI/CD 侵害の可能性は残っている
  • PyPI は Trusted Publishing の状態をプロジェクトページの 緑のチェックマーク で強調せず、ファイル詳細の単純な Yes/No メタデータとしてのみ表示し、安全性シグナルだと誤解される余地を減らしている
  • Trusted Publishing と PyPI の attestations は、アップロード認証やマシンアイデンティティに基づく署名の有無を示すだけであり、そのアイデンティティ自体を別途信頼しない限り、パッケージの安全性や品質は判断できない

Trusted Publishing が扱う信頼の範囲

  • Trusted Publishing は、人間にパッケージを信頼しろと伝える機能ではなく、マシン間の信頼 を扱う認証方式である
  • Trusted Publishing を、人間が信頼できるかどうかの問題として捉えると、カテゴリがずれてしまう
  • 重要なのは、CI/CD ワークフローのような外部マシンアイデンティティと、パッケージインデックス上のプロジェクトアイデンティティとの間に、アップロード認証のための信頼関係を確立することにある

PyPI の Trusted Publishing の構造

  • 「Trusted Publishing」は、PyPI が OpenID Connect フェデレーション上の認証方式を説明する際に使う用語である
  • PyPI はこれを 2023 年に公開し、その後 npm、RubyGems、crates.io、NuGet なども採用した
  • 出発点となった問題は 2 つある
    • 長期認証情報 であるインデックス API トークンは、安全に管理するのが難しく、利用者が最小権限や有効期限を設定しにくいため、過剰権限になりやすい
    • 多くの利用者は CI/CD プラットフォームに入れるために認証情報を作成しており、CI/CD プラットフォーム側も OIDC を通じて特定のマシンアイデンティティの制御を証明する仕組みを持っている
  • 利用者はパッケージインデックスに、CI/CD のマシンアイデンティティである Trusted Publisher を一度登録し、CI/CD がアイデンティティトークンを提示すると、インデックスがそれを検証して、短命でスコープの狭い公開用認証情報を発行する

利点と残る制約

  • 短命で自己スコープ化される認証情報という方式は、PyPI 利用者にとって大きな成功を収めたアプローチと評価されている
    • 利用者は、不要なときに認証情報を自分で管理しなくてよい方式を好む
    • 大規模オープンソースプロジェクトや企業は、公開権限が個人メンテナーではなく ソースアイデンティティ に結び付く性質を好む
  • Trusted Publishing にも構造的な複雑さは残っている
    • PyPI の「pending publishers」は、まだ存在しないプロジェクトの問題を解決するが、データモデルを複雑にし、通常の Trusted Publishing より利用者にとって分かりにくい
    • OIDC プロバイダーは、共通 claim の一部以外にも claim set にさまざまな値を入れられるため、インデックス側は各プロバイダー固有の形式を個別に処理しなければならない
    • このため、マシンアイデンティティは OIDC IdP 間で相互に置き換え可能ではなく、PyPI が新しい Trusted Publishing プロバイダーをゆっくり追加している理由の一つにもなっている
  • CI/CD ワークフローが侵害されると、攻撃者は Trusted Publishing の認証情報や、その元になる OIDC ID トークンを漏えいさせる可能性がある
    • これは長期認証情報がワークフロー内にある場合と似ているが、Trusted Publishing の認証情報は同じスコープ・寿命のリスクを持たない
    • PyPI は、pull_request_target のように容易に悪用され得るトリガーに該当するマシンアイデンティティに対してはトークン交換を拒否し、CI/CD 侵害リスクを緩和している

パッケージの信頼シグナルではない理由

  • Trusted Publishing は 認証方法 にすぎず、そのパッケージが安全か、高品質か、使う価値があるかについての情報は与えない
  • PyPI は公開インデックスであり、誰でもアップロードでき、誰でも Trusted Publisher を使ってアップロードできる
    • Trusted Publisher を使っても、マルウェアや脆弱なコードをアップロードできる
    • この点では、PyPI の別のアップロード認証方法である API トークンと同じである
  • PyPI では Trusted Publishing は必須ではなく、今後も必須にはできない
    • 利用者に Trusted Publishing を強制することは、エンジニアリング上実現不可能であり、技術的・社会的にも望ましくない
    • Trusted Publishing は常に選択肢の一つである

PyPI UI が誤解を減らす方法

  • PyPI は、利用者が Trusted Publishing の状態をパッケージの信頼シグナルだと誤解しないよう注意している
  • プロジェクトページには、Trusted Publishing の状態を示す 緑のチェックマーク はない
  • ユーザー管理下にあることを示す緑のチェック表示は、PyPI がパッケージ本体と同じ出所から来たと証明できるリンクに対してのみ使われる
  • 検証済み URL は、検証時点でその URL が PyPI パッケージ所有者の管理下にあったことを示すだけであり、URL やプロジェクトに追加の安全性があることを意味しない
  • 特定ファイルの Trusted Publishing 状態は、ファイル詳細で単純な Yes/No 値として表示される
    • ファイルメタデータ領域は、利用者の信頼判断に重要な情報であるかのようにはレンダリングされない
    • アップロードクライアントの user agent から来た JSON blob も適切にはレンダリングしない

attestations との区別

  • この論点は、PyPI の attestations とは別である
  • attestations も現在は OIDC マシンアイデンティティを使うが、信頼シグナル ではない
  • attestation はマシンアイデンティティ上の署名に近いが、PyPI には誰でもアップロードできるため、誰でも自分が管理するマシンアイデンティティで署名できる
  • Trusted Publisher があるからといって attestation が必ず存在するわけではなく、attestation があるからといって最終利用者が特定のアイデンティティを信頼してよいことも意味しない
  • PyPI の attestation 信頼性モデルも、この点を文書化している

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Lobste.rsのコメント

  • 良い記事。Trusted Publishing と 証明（attestation） は、それぞれ異なる障害モードに対して異なる保証を提供しており、どちらも大半のユーザーが言うところの信頼とは別物である

  • Trusted Publishing が可能になったのは、この15年間で多くのオープンソースプロジェクトが、メーリングリスト、Git リポジトリ、バグトラッカー、ビルドサーバーといった セルフホスト から 中央集権的な forge へ移行してきたためである
    いまや中央集権的な forge の欠点がより明白になり、プロジェクトは再びセルフホストを検討しつつある
    2010年代には利便性とソーシャルネットワーク効果がプロジェクトを中央集権的な forge へ押しやったが、今では Trusted Publishing を含め、プロジェクトをそこに縛り付ける要因がはるかに増えている
    権威を疑え — 分散化を促進せよ
    — "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

    • Trusted Publishing には ロックイン はない。PyPI が連携できるホストを含め、いつでも別の認証方式を使える
      フェデレーション認証方式をロックインの一形態と呼ぶのには、やや皮肉がある
    • セルフホストは実際のところ、ほとんど常に少数派の嗜好に近かった。SourceForge の目的は、まさにその負担を肩代わりすることだった
      ほぼ同時期の25年ほど前には ASF もあったが、ASF にはガバナンスの負担も大きかった。その前には GNU プロジェクトがあり、自由ソフトウェアの理念をより強調していた一方で、体系的なプロジェクトホスティングサービスにはあまり重点を置いていなかった。GNU は、自由ソフトウェアプロジェクトにどのようなサービスが必要かという明確な概念ができる以前から存在していたためである
      1990年代の自由ソフトウェアプロジェクトは、通常は大学のタイムシェアリングサービスや友人のコロケーションサーバー上で運営されていた。たとえば PuTTY や、ASF 以前の Apache httpd が置かれていた Hyperreal.org のようなものだ
      自前のインフラを正当化できるほど大きくなるプロジェクトはまれで、安価なホスティングも比較的最近になってようやく可能になった
    • セルフホストの Forgejo で Trusted Publishing ができない理由はあるのだろうか？ あるなら、自分が何か見落としている気がする