解禁禁止(embargo)リリースの調整方法

Gitユーザーを重大な脆弱性から保護するために、通常のメンテナンスリリースのように修正バージョンをリリースするだけではありません。 代わりに、リリースをパッケージャーと調整し、リリース日まで修正を解禁禁止(embargo)します。 そうすることで、ユーザーは、実行しているオペレーティングシステムやディストリビューションに関係なく、リリース日にアップグレードする機会を得ます。

The git-security mailing list

脆弱性と、分析と、修正案の責任ある開示と、解禁禁止リリースの調整は、すべて、 <git-security@googlegroups.com> の git-security メーリング・リストで行われます。

この文脈での「解禁禁止」(embargo)という用語は、脆弱性に関する情報が秘密にされ、知る必要がある場合にのみ共有される期間を指します。これは、悪用される可能性のある攻撃経路に気付く悪意の行為者から Git のユーザーを保護するために必要です。 「解禁禁止の解除」(Lifting the embargo)とは、脆弱性を修正したバージョンを公開することを指します。

git-security メーリング・リストの対象者

<git-security@googlegroups.com> に電子メールを送信することで、 誰でも git-security メーリング・リストに連絡できます。 ただし、アーカイブは公開されておらず、購読メンバーのみがアクセスできます。

購読メンバーは数十名です。脆弱性への対処に関して信頼されているコア Git 開発者と、利害関係者(stakeholders)(Git のセキュリティ脆弱性の影響を受ける製品の所有者など)です。

報告された問題の重大度の評価(報告がセキュリティ関連であるか、あるいはパブリック・メーリング・リストにリダイレクトできるかどうかの決定を含む)や、問題を修正する方法や、情報開示のタイムラインの決定や、優先順位と要件の調整などの議論が中心です。

Communications

もし、あなたが利害関係者(stakeholder)なら、議論に細心の注意を払うことをお勧めします。なぜなら、あなたの関心とは無関係に見えるような活発な会話の中に、適切な情報が埋もれているかもしれないからです。たとえば、パッチの 1 つにおけるコード・コメントの形式や、複数の個別の脆弱性に対する修正を同一の解禁禁止リリースに統合するかどうかについて議論している途中で、暫定的なタイムラインが合意される可能性があります。ほとんどのメール・スレッドは通常、合意や評価やタイムラインを伝達するために特別に構造化されているわけではありません。

Typical timeline

  • 潜在的な脆弱性が git-security メーリング・リストに報告されます。

  • git-security リストのメンバーは、報告された潜在的な脆弱性の重大度の初期評価を行うために議論を開始します。私達は数日以内に議論を開始するようにしたいです。

  • 議論の結果、解禁禁止を正当化するほど重大ではないという合意に達した場合、 その報告は公開 Git メーリング・リストにリダイレクトされます。 これにて、報告者による git-security リストとの対話は終了します。

  • 解禁禁止に値するほど重大であると判断された場合は、脆弱性に対処する方法に関する数々のアイデアが提示されます。

  • 通常その頃に、 Git メンテナーまたはその代表者は、 GitHub の git/git リポジトリにセキュリティ勧告の草案を公開します(詳細下記)。

  • コードレビューは、状況に応じてさまざまな場所で実行できます。これらは、git-security リストでインラインに送信されるパッチ群、またはセキュリティ勧告のドラフトに関連付けられた GitHub のプライベート・フォーク、または git/cabal リポジトリです。

  • 修正に取り組んでいる貢献者は、 パッチを git-security リストに(元のスレッドとインラインで)送信することから始めることを検討する必要があります。パッチには元の報告者だけでなくすべての購読者がアクセスできるようにするためです。

  • レビューが一段落し、 そして、 そのパッチがゴールに近づいていることにレビュー関係者全員が同意すると、 Git メンテナなどがリリース日とサービス対象のリリース・トレインを決定します。 どのバージョンにバックポート修正が必要かに関する決定は、報告者と、パッチに取り組んだ貢献者と、利害関係者(stakeholders)からの意見に基づいて行われます。 サイトの管理者は、自分たちがホスティングしているリポジトリのいずれかを介して、与えられた問題が悪用されているかどうかを分析したいと思うかもしれないし、バイナリ・パッケージャは、例えば、自分たちの製品が脆弱性に対して適切にパッチが適用されていることを確認したいと思うかもしれません。

  • Git コミュニティは、さまざまなバイナリ・パッケージャーの特定のタイムライン要求に対応するために最善を尽くしていますが、問題の性質により、リリース・スケジュールを引き伸ばすのは不可能になる可能性があります。 緊急とみなされる修正については、 開示とリリースのタイムラインを短縮することが Git ユーザー・コミュニティにとって最善の利益となる可能性があり、パッケージ作成者はそれに対応する必要があるかもしれません。

  • その後、修正を含むブランチが git/cabal リポジトリにプッシュされます。

  • タグが Git メンテナによって作成され、同一のリポジトリにプッシュされます。

  • Git for Windows、 Git for macOS、 BSD、 Debian などのメンテナは、 Git メンテナが作成したタグに基づいて、 対応するリリース物を準備します。

  • さまざまなバイナリ・パッケージャーによって準備されたリリース物は、 git-security リストへのメールを通じて、解禁禁止下にある利害関係者(stakeholders)に提供できます。

  • リリースの 1 週間前に、 関連情報が記載されたメールが <distros@vs.openwall.org> (下記参照)に送信されます。 このリストは、 オープンソース・プロジェクトの解禁禁止リリースを、 Linux や他の OS のすべての主要ディストリビューションの利害関係者(stakeholders)に、事前に発表するために使用されます。

  • その後、 公開日前に、 広報の準備が行われます。 これには、 ブログ投稿や、 Git および Git for Windows メーリング・リストへのメールが含まれます。

  • リリース当日、 太平洋標準時(PST,UTC-0800)の午前 10 時頃、 Git メンテナはタグと master ブランチをパブリック・リポジトリにプッシュし、 その後、 告知メールを送信します。

  • タグがプッシュされると、Git for Windows のメンテナは対応するタグを公開し、関連するリリース物(Git for Windows インストーラー、 Portable Git、 MinGit など) を含む GitHub リリースを作成します。

  • その後、 Git for Windows のリリースは、 公開 Git や、 Git for Windows メーリング・リストへのメール や、 ツイートを通じて発表されます。

  • Linux やその他のプラットフォームのディストリビューション・パッケージャーについても同様です。 リリースは、 優先チャネル(preferred channels)を通じて発表されます。

  • <oss-security@lists.openwall.org> 宛てのメール(詳細下記)が、 <distros@vs.openwall.org> 宛てのメールのフォローアップとして送信され、脆弱性が詳細に説明され、 多くの場合、悪用の概念実証も含まれます。

注意: Git プロジェクトはスケジュールについての保証しませんが、 Git ユーザーの安全を確保するため、解禁禁止(embargoes)を合理的に短くすることを目指しています。

Opening a Security Advisory draft

最初のステップは、 open an advisory です。 技術的には、これは必要ありません。 ただし、 これは CVE 番号を取得する最も便利な方法であり、 修正に協力するために使用できる、それに関連付けられたプライベート・リポジトリを提供します。

Notifying the Linux distributions

リリース日の最大2週間前に、 <distros@vs.openwall.org> に通知を送信する必要があります。 できれば、リリース日の7日以内に通知を送信する必要があります。 これはほとんどの(すべての？)Linuxディストリビューションに到達します。 以下の例と、 here にあるこのメーリングリストのガイドラインを参照してください。

バージョンが公開されたら、それに関するメモを oss-security に送信します。 例として、 the v2.24.1 mail を参照してください。 Here が彼らのガイドラインです。

oss-security へのメールは、功績を説明し、報告者に称賛を与える必要があります。セキュリティ研究者は、その貴重なサービスに対する称賛をあまり受けておらず、社会的な称賛が各組織からの支払い維持するのに大いに役立ちます。

技術的には、どのような功績でも7日間ま説明を遅らせることができますが、通常はすぐにそれを控えて説明しています。

礼儀として、関係者がそれらの 統合/バックポート を処理できるように、通常、Gitバンドル(メーリングリストは .bundle 添付ファイルをドロップするため .tar.xz として) を）distros@ にメールで添付します。 このバンドルは通常、以下のようなコマンドを使用して作成されます:

git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle

distros@vs.openwall.org へのメール例

To: distros@vs.openwall.org
Cc: git-security@googlegroups.com, <other people involved in the report/fix>
Subject: [vs] Upcoming Git security fix release

Team,

The Git project will release new versions on <date> at 10am Pacific Time or
soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
it being dropped) which you can fetch into a clone of
https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,
containing the tags for versions <versions>.

You can verify with `git tag -v <tag>` that the versions were signed by
the Git maintainer, using the same GPG key as e.g. v2.24.0.

Please use these tags to prepare `git` packages for your various
distributions, using the appropriate tagged versions. The added test cases
help verify the correctness.

The addressed issues are:

<list of CVEs with a short description, typically copy/pasted from Git's
release notes, usually demo exploit(s), too>

Credit for finding the vulnerability goes to <reporter>, credit for fixing
it goes to <developer>.

Thanks,
<name>

oss-security@lists.openwall.com へのメール例

To: oss-security@lists.openwall.com
Cc: git-security@googlegroups.com, <other people involved in the report/fix>
Subject: git: <copy from security advisory>

Team,

The Git project released new versions on <date>, addressing <CVE>.

All supported platforms are affected in one way or another, and all Git
versions all the way back to <version> are affected. The fixed versions are:
<versions>.

Link to the announcement: <link to lore.kernel.org/git>

We highly recommend to upgrade.

The addressed issues are:
* <list of CVEs and their explanations, along with demo exploits>

Credit for finding the vulnerability goes to <reporter>, credit for fixing
it goes to <developer>.

Thanks,
<name>